[iOS] Set CurrentCulture locale to specific format based on system default when possible

[matouskozak]

Problem Description

On iOS (and other apple mobile platforms), we are taking the system default culture and using it inside .NET as CultureInfo.CurrentCulture.

Currently, the system default culture is truncated into neutral culture format (only language). This behavior was set in #104071, where we had an incorrect assumption that other ICU platforms also return just neutral locale name. However, that isn't true because the ICU uloc_getBaseName

runtime/src/native/libs/System.Globalization.Native/pal_locale.c

Line 232 in 117c4ab

uloc_getBaseName(defaultLocale, localeNameBuffer, ULOC_FULLNAME_CAPACITY, &status);

only strips collation information as described in https://github.com/unicode-org/icu/blob/d9d09db2a7167eea2b5749836ef32cdd45303fdd/icu4c/source/common/unicode/uloc.h#L948.

The problem of using all Apple's system default locales is that some of the retrieved identifiers are not part of https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Globalization/IcuLocaleData.cs (e.g., en-CZ), causing the culture LCID number to be 0x1000 (LOCALE_CUSTOM_UNSPECIFIED). This can cause issues where the default CultureInfo.CurrentCulture causes crashes when using certain CultureInfo APIs that accept LCID instead of culture name, such as,

runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/CultureInfo.cs

Line 993 in 94c356d

public static CultureInfo GetCultureInfo(int culture)

used by e.g. SqlString.

Proposed Change

This PR reverts the previous change and preserves the full (specific = language-region) culture locale format when the retrieved locale is part of IcuLocaleData.cs. Upon retrieving the system locale name, we verify that the culture name is part of the ICU data and if not, we use the parent culture (neutral) instead.

A test was added to CurrentCultureTests to assert that the default CultureInfo.CurrentCulture is never a custom type.

Previous behavior (.net 9):

Apple system culture	CurrentCulture
en-US	en
en-CZ	en

New behavior:

Apple system culture	CurrentCulture
en-US	en-US
en-CZ	en

---

This PR addresses the following issues:

• .NET 9 iOS / HybridGlobalization: currency symbols / currency names not available #108958
• Wrong result from CultureInfo.CurrentCulture.Name in iOS #110680
• System.Globalization.RegionInfo.CurrentRegion returns blank values on Maui #110704

[dotnet-policy-service]

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

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

Files not reviewed (1)

• src/native/libs/System.Globalization.Native/pal_locale.m: Language not supported

[matouskozak]

/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[vitek-karas]

Do we know what this was done before?
The PR description should be updated to describe this - what we did before (has that) and why, and what we're changing it to (and why it's OK to change given the previous reasoning).

[matouskozak]

Indeed, I was trying this PR to see which test suit breaks if we switch to specific name because there are other dependencies such as SqlStrings that were previously affected. I'll update the issue description when I finalize the code changes.

Brief history what I found:

• The switch to neutral locale names was done in [ios][HybridGlobalization] Fix default culture  #104071
• In that PR, there was an assumption that our ICU also returns just neutral locale name. However, that isn't true as the ICU uloc_getBaseName

  runtime/src/native/libs/System.Globalization.Native/pal_locale.c

  Line 232 in 117c4ab

  uloc_getBaseName(defaultLocale, localeNameBuffer, ULOC_FULLNAME_CAPACITY, &status);

  only strips collation information as described in https://github.com/unicode-org/icu/blob/d9d09db2a7167eea2b5749836ef32cdd45303fdd/icu4c/source/common/unicode/uloc.h#L948.
• The problem with using Apple's system default locale is that if it's not part of https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Globalization/IcuLocaleData.cs (e.g., en-CZ), the culture LCID number is 0x1000 (LOCALE_CUSTOM_UNSPECIFIED). While it seems that using LCID number to create new cultures is not recommended and using culture name is preferred, e.g., SqlString implementation still relies on using it, thus when LCID doesn't match with valid culture it causes failures when using some CultureInfo APIs, e.g.,

  runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/CultureInfo.cs

  Line 993 in 94c356d

  public static CultureInfo GetCultureInfo(int culture)

---

I'll try to make a middle way out of this, where we use system locale if it's recognized by .NET, otherwise we use parent culture which is neutral.

[matouskozak]

/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[matouskozak]

/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[tarekgh]

I don't think we need to fix this. We encourage users to move away from LCIDs. Any users still using LCID should start migrating to use culture names instead. The change here is trying to work around the issue of using the parent which may benefit using the LCID but it can cause other issues when requesting any region-specific data from current culture.

This issue is not specific to iOS or mobile platforms. This can occur on Windows for example doing CultureInfo.CurrentCulture = new CultureInfo("en-AE");. Whoever is using LCID needs to fix their code and start using culture names or they need to make their code tolerant when getting custom LCID values.

Last, if IcuLocaleData.cs missing any data, we can try to update it as needed.

[matouskozak]

Any users still using LCID should start migrating to use culture names instead.

@tarekgh I know that using LCID is not recommended. What I was trying to work around here by using the parent is that any default culture set by .NET would be compatible with all .NET libraries code. We are currently relying on LCID inside SqlString codebase, causing failures if LCID is custom culture.

Note, this PR not only does the fallback to parent culture but also fixes the behavior that we didn't return specific system culture. I can remove the parent culture workaround and disable the failing tests until the affected library code migrates from LCID. However, because we need to backport this fix to .NET 9, we could be risking a breaking change to some customers using e.g., SqlStrings.

[tarekgh]

What I was trying to work around here by using the parent is that any default culture set by .NET would be compatible with all .NET libraries code. We are currently relying on LCID inside SqlString codebase, causing failures if LCID is custom culture.

I think the right thing to do is have SqlString get fixed. Either they migrate to use the culture name or to be tolerant to do the fallback themselves. As I mentioned, this issue is not specific to iOS. What happens if someone sets en-AE as a default culture on Windows? They will run into the exact same problem. Also, your fix can cause some different problems. Like someone is using the CurrentCulture name to create a RegionInfo object. If you are using the parent (which most likely be a neutral culture, RegionInfo creation will throw exception.

but also fixes the behavior that we didn't return specific system culture.

I am fine with the change in pal_locale.m if other reviewers see this is a correct fix.