Localization completely broken in IOS apps

[rolfbjarne]

From @nevse on Mon, 16 Jan 2023 08:09:54 GMT

Description

It's impossible to add more than one additional language to an ios app.

Localization resx files are ignored for 2 and more additional languages when an ios app was built in release and run on device.

I created a simple app, source code available here. It contains three resx files (Resources/MyLocalization.resx, Resources/MyLocalization.de.resx, Resource/MyLocailzation.es.resx) which I use to obtain the localized string "MyString" in the following way:

        Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture = new CultureInfo("de");
        CultureStringLabel.Text = resourceManager.GetString("MyString");

It works fine when I build my app in release for an iphone simulator, but it doesn't work when I build it in release for a real device. It works only for one additional resx file.

Steps to Reproduce

1. create an app from the default template: dotnet new maui
2. add three buttons and create handlers for them

 <ScrollView>
      <VerticalStackLayout
          Spacing="25"
          Padding="30,0"
          VerticalOptions="Center">

          <Button Text="Set Eng Culture" Clicked="OnSetEngCulture" />
          <Button Text="Set De Culture" Clicked="OnSetDeCulture" />
          <Button Text="Set Es Culture" Clicked="OnSetEsCulture" />
          <Label x:Name="CultureStringLabel" />
      </VerticalStackLayout>
  </ScrollView>

private void OnSetEngCulture(object sender, EventArgs e)
{
      Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
      CultureStringLabel.Text = resourceManager.GetString("MyString");
}
private void OnSetDeCulture(object sender, EventArgs e)
{
Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture = new CultureInfo("de");
      CultureStringLabel.Text = resourceManager.GetString("MyString");
  }
  private void OnSetEsCulture(object sender, EventArgs e)
  {
      Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture = new CultureInfo("es");
      CultureStringLabel.Text = resourceManager.GetString("MyString");
  }

3. build the app in release and run on the real iphone device

Press each button - you should see different strings (string from eng, string from de, string from es).

Press "Set Eng Culture" to see "string from eng".
Press "Set De Culture" you should see the "string from de", but this string is "string from eng". It's wrong behaviour.
Press "Set Es Culture" to see "string from es".

Link to public reproduction project repository

https://github.com/nevse/maui-tests-iosreleaselocalization

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

ios 16

Did you find any workaround?

No response

Relevant log output

No response

Copied from original issue dotnet/maui#12684

[rolfbjarne]

From @jfversluis on Mon, 16 Jan 2023 13:02:44 GMT

Is this maybe related or the same as #16847?

@rolfbjarne ?

[rolfbjarne]

From @rolfbjarne on Mon, 16 Jan 2023 13:52:28 GMT

Is this maybe related or the same as xamarin/xamarin-macios#16847?

@rolfbjarne ?

No, this is something different, and I can reproduce it.

Add this to the project file to work around it:

<PropertyGroup>
    <EnableAssemblyILStripping>false</EnableAssemblyILStripping>
</PropertyGroup>

[rolfbjarne]

Something like this might fix it: https://gist.github.com/rolfbjarne/f0d54b7db1f4c402b5605780c2be7452 (needs tests too).

[rolfbjarne]

This might be a dup of #17009 / #14841.

[softlion]

@rolfbjarne Is this one related too dotnet/maui#13456 ?

[rolfbjarne]

@softlion if the workaround above works, then it is.

[softlion]

@softlion if the workaround above works, then it is.

The workaround does fix the issue with the translations.
TY !

, but breaks the grouped CollectionView (which is perfectly working without the workaround). The collectionview appears correctly the 1st time it is opened, but after a child page is opened and closed, the main page displays a broken collectionview with tons of funky group headers instead of a few group and a bunch of normal items. Very very curious breaking.

Without the workaround the collectionview has no such issue.

[rolfbjarne]

@softlion if the workaround above works, then it is.

The workaround does fix the issue with the translations, but breaks the grouped CollectionView (which is perfectly working without the workaround). The collectionview appears correctly the 1st time it is opened, but after a child page is opened and closed, the main page displays a broken collectionview with tons of funky group headers instead of a few group and a bunch of normal items. Very very curious breaking.

Without the workaround the collectionview has no such issue.

That's indeed a very strange break, because the work around turns off an optimization only done in release builds (this means that the workaround is effectively in place for debug builds, which I assume are working fine?).

I'm inclined to believe something else is going on.

[softlion]

@softlion if the workaround above works, then it is.

The workaround does fix the issue with the translations, but breaks the grouped CollectionView (which is perfectly working without the workaround). The collectionview appears correctly the 1st time it is opened, but after a child page is opened and closed, the main page displays a broken collectionview with tons of funky group headers instead of a few group and a bunch of normal items. Very very curious breaking.
Without the workaround the collectionview has no such issue.

That's indeed a very strange break, because the work around turns off an optimization only done in release builds (this means that the workaround is effectively in place for debug builds, which I assume are working fine?).

I'm inclined to believe something else is going on.

You are right. It's something else.

[SoftArea-srl]

I have the same issue described by @nevse
The work around mentioned here does not work for me. Tested with real device iPhone 12 iOS 16.4.

[rolfbjarne]

I have the same issue described by @nevse The work around mentioned here does not work for me. Tested with real device iPhone 12 iOS 16.4.

If the workaround doesn't work, something else is happening. Please file a new issue with a test project and we'll figure out what's going on.

[divil5000]

It is unbelievable that this isn't the highest-priority item on Microsoft's agenda right now. They are basically saying that localised apps cannot be built using the latest and greatest .net 6/7 for iOS. Localised apps includes all major international apps.

[softlion]

It is unbelievable that this isn't the highest-priority item on Microsoft's agenda right now. They are basically saying that localised apps cannot be built using the latest and greatest .net 6/7 for iOS. Localised apps includes all major international apps.

Fixed in .net8, not backported to the "legacy" .net7 because of fear of breaking changes.
I don't know who is in charge of those rules, but it is time to switch minds.

[marwalsch]

System.Globalization.CultureInfo.DefaultThreadCurrentCulture still doesn't work properly on .NET 8. Is this a separate issue?

[rolfbjarne]

@marwalsch yes, that's a separate issue. Please file it in the dotnet/runtime repository.