Regression: Norwegian localization no longer works in iOS with .NET 9

[dotMorten]

Description

When having localized resources in your application, and one of them is norwegian no, the resource lookup no longer works and falls back to english. This behavior is only observed on net9.0-ios, and not on Windows and Android or in net8.0-ios.

Reproduction Steps

1. Open and run the following sample on iOS:
   MauiApp12.zip

2. Notice that the button says "Language is English". Repeat on Android and Windows or downgrade the iOS target to .NET 8 and notice the output is now correctly "Language is Norwegian".

Expected behavior

Norwegian resources are correctly looked up.

Actual behavior

Resources not found and falls back to the default english resource.

Regression?

Yes

Known Workarounds

No response

Configuration

.NET 9.0.101, ios-arm64 with iOS 18.2 as well as on iOS17.5

Other information

Looking at the generated NO culture this is what I'm seeing which is likely the cause of it:

var no = new System.Globalization.CultureInfo("no");
Debug.WriteLine(no.TwoLetterISOLanguageName); // return "nb" on net9.0-iOS, "no" on  net9.0-Android and net8.0-ios
Debug.WriteLine(no.Name); // return "nb" on net9.0-iOS, "no" on  net9.0-Android and net8.0-ios

Looks like in 8.0, dotnet linked its own fork of ICU into every ios app, and in 9.0, you use system libraries as much as possible instead: #80689

I'm guessing this is the root of the problem.

Might also be related to: #110680
Also related:

• https://learn.microsoft.com/en-us/answers/questions/1848600/icu-update-nb-no-to-no-no-locale-id-change-net-fra
• https://icu.unicode.org/design/norwegian-locales-changes-in-v39

This is a pretty big regression for our localized libraries that we ship to other developers.

[ivanpovazan]

/cc: @matouskozak

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @ivanpovazan, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

[dotMorten]

@ivanpovazan Since this is a pretty big regression breaking localization, is there a reason it's pushed off to the next release?

[steveisok]

@ivanpovazan Since this is a pretty big regression breaking localization, is there a reason it's pushed off to the next release?

We'll typically set the milestone for the next release as way to track active work. A separate backport decision is made when the change goes in.

[ivanpovazan]

@dotMorten, as @steveisok said, it is being marked with 10.0.0 milestone just to annotate that we are actively working on it. Once the fix gets merged to main, we consider backporting it to the servicing releases depending on when/where the regression started occurring. Thank you for understanding.

[ivanpovazan]

As noted, in .NET 9 we use system libraries for globalization support on iOS platforms.

In case of no our code paths essentially end up calling:

NSLocale *currentLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"no"];
const char* value = [currentLocale.localeIdentifier UTF8String];

which returns nb.

The same behavior has been verified with plain Objective-C app in Xcode targeting MacOS and iOS platforms, which implies the behavior is imposed by Apple.

I opened a feedback ticket to apple: https://feedbackassistant.apple.com/feedback/16512787

In the meantime, @dotMorten is it feasible for you to add nb resource as well to your app as a workaround?