You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, locale.getlocale() does not support locales with @-modifiers. If the current locale has an @-modifier, it will be silently dropped in the locale.getlocale() result. For example, ca_ES.utf8@valencia will result in ('ca_ES', 'UTF-8'), sr_RS.utf8@latin -- ('sr_RS', 'UTF-8'), uz_UZ.utf8@cyrillic -- ('uz_UZ', 'UTF-8'). They are different locales! The @euro modifier, the only one that handled specially, is also removed, even if locales with and without @euro can be different locales, and @euro affects collation in some locales. And for the el_gr@euro locale it returns wrong encoding ISO8859-15 (the correct encoding for this locale on Linux is ISO8859-7).
Accordingly, locale.setlocale() does not support @-modifiers if the locale is specified as a language code/encoding pair. It is supported if specify locale as string, but then the purpose of the wrapper is lost.
The only way to support @-modifiers in the format compatible with this functions is to include it in the language code. So locale.getlocale() will return ('ca_ES@valencia', 'UTF-8') for locale ca_ES.utf8@valencia, and passing ('ca_ES@valencia', 'UTF-8') to locale.setlocale() will set locale to ca_ES.utf8@valencia. This is mildly breaking change, but it is better to get error in program that do not expect @ in the locale.getlocale() result than get a wrong result for that locale.
Activity
gh-137729: Fix support for locales with @-modifiers (GH-137253)
pythongh-137729: Fix support for locales with @-modifiers (pythonGH-1…