-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix calling NLS with Cultures has alternative sort names #61992
Fix calling NLS with Cultures has alternative sort names #61992
Conversation
Tagging subscribers to this area: @tarekgh, @safern Issue DetailsIn .NET 6.0 and when running on Windows, we have switched to cl NLS to get some properties which are not available with ICU. CultureInfo.TextInfo.ANSICodePage is a good example of that. When we are calling NLS in such cases we use the internal culture name stored in
|
@safern could you please help reviewing this one? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, makes sense!
I logged the issue for the unrelated CI failure. |
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1517839642 |
Fixes #61977
In .NET 6.0 and when running on Windows, we have switched to call NLS to get some properties which are not available with ICU. CultureInfo.TextInfo.ANSICodePage is a good example of that. When we are calling NLS in such cases we use the internal culture name stored in
_sWindowsName
. The problem here is when using cultures which have alternative sorts (e.g.es-ES_tradnl
) such names will be stored ases_ES@collation=tradnl
to be used when calling ICU too. If this name is used with NLS, the calls will fail. The fix here is to use the name that works with Windows which is stored in the fieldsRealName
instead. On NLS mode, _sWindowsName is same as _sRealName so this change shouldn't affect this mode.