Fix Turkish casing on Android by deriving it from the locale name by MsfPablo · Pull Request #132001 · dotnet/runtime

MsfPablo · 2026-08-07T13:37:00Z

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

MsfPablo · 2026-08-07T13:37:00Z

Fixes#106560

Root cause

TextInfo.NeedsTurkishCasing (src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.Icu.cs) decides whether to use ChangeCaseTurkish by probing collation:

returnCultureInfo.GetCultureInfo(localeName).CompareInfo.Compare("\u0131","I",CompareOptions.IgnoreCase)==0;

On Android the runtime loads the platform's system ICU (libicuuc.so/libicui18n.so), which does not provide the collation tailoring this probe depends on. The probe therefore returns false for tr-TR, IcuChangeCase falls through to the non-Turkish ChangeCase, and "i".ToUpper(tr-TR) yields I (U+0049) rather than İ (U+0130).

The same collation gap is already acknowledged in the test suite, which skips the 'ı' vs 'I'CurrentCultureIgnoreCase cases on Android with a pointer to this issue (src/libraries/System.Runtime/tests/System.Runtime.Tests/System/CharTests.cs:178).

Fix

Derive the flag from the locale's language subtag instead. ICU itself applies the dotted/dotless i rules to exactly the tr and az languages (ucase.cpp treats both as LOC_TURKISH), so this is equivalent to the collation probe on platforms where the probe worked, while being independent of the collation data actually shipped by the host.

Testing

Not verified on a device — I do not have an Android emulator/runtime build available here, so this is based on source analysis. Casing behaviour on other platforms should be unchanged, since tr/az are the only languages for which CLDR collates U+0131 equal to I under IgnoreCase. The disabled casing assertions referencing #106560 would be the natural way to validate this on CI; I left them untouched, as the Compare-based assertions in CharTests exercise collation rather than casing and are not fixed by this change.

Note: @murathanoktem mentioned on the issue that they were investigating. Happy to close this in favour of their PR — I am posting it because I had the root cause isolated.

TextInfo.NeedsTurkishCasing detected the Turkish dotted/dotless i casing rules by probing whether the culture collates U+0131 equal to 'I' under IgnoreCase. On Android the system ICU does not provide the collation data that probe depends on, so the check returned false for tr-TR and casing silently fell back to the non-Turkish path, making i.ToUpper() yield 'I' instead of U+0130. Fixesdotnet#106560

azure-pipelines · 2026-08-07T13:37:41Z

Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-08-07T13:39:31Z

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

MsfPablo · 2026-08-07T13:39:33Z

Closing as duplicate — superseded by #132002, which includes the same fix plus the regression test.

github-actionsBot added the area-System.Globalization label Aug 7, 2026