It turns out that the LCIDToLocaleName API, which is used inside CultureInfo, can return incorrect names for transient language identifiers:
0x2000 - LOCALE_TRANSIENT_KEYBOARD1
0x2400 - LOCALE_TRANSIENT_KEYBOARD2
0x2800 - LOCALE_TRANSIENT_KEYBOARD3
0x2C00 - LOCALE_TRANSIENT_KEYBOARD4
For example, it returns "nqo-GN" and "jv-Java-ID" instead of the language tags "nqo" and "jv-Java" (as seen in the Get-WinUserLanguageList PowerShell cmdlet). In this case, both languages mapped to the same transient language identifier.
Consider add parent culture check into CultureData GetCultureData(int culture, bool bUseUserOverride) to look at the parent language if it has the same language identifier as we requested and use parent in such cases:
if (IsCustomCultureId(retVal.LCID) && PInvoke.LocaleNameToLCID(retVal.ParentName, 0) == culture)
{
retVal = GetCultureData(culture.ParentName, bUseUserOverride);
}
Found this bug when testing dotnet/winforms#8573
It turns out that the LCIDToLocaleName API, which is used inside CultureInfo, can return incorrect names for transient language identifiers:
0x2000- LOCALE_TRANSIENT_KEYBOARD10x2400- LOCALE_TRANSIENT_KEYBOARD20x2800- LOCALE_TRANSIENT_KEYBOARD30x2C00- LOCALE_TRANSIENT_KEYBOARD4For example, it returns "nqo-GN" and "jv-Java-ID" instead of the language tags "nqo" and "jv-Java" (as seen in the Get-WinUserLanguageList PowerShell cmdlet). In this case, both languages mapped to the same transient language identifier.
Consider add parent culture check into CultureData GetCultureData(int culture, bool bUseUserOverride) to look at the parent language if it has the same language identifier as we requested and use parent in such cases:
Found this bug when testing dotnet/winforms#8573