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
'eo_XX.ISO8859-3' does not exist on Fedora 29 or Debian Stretch. The only Esperanto locales that exists are 'eo' and 'eo.utf8'. Even so, locale.py defines the Esperanto locales as follows:
eo_EO used to exist on Debian in the early 2000s, and eo_XX on some other distributions. Since glibc 2.24 upstreamed Esperanto, however, it has been 'eo[.utf8]'.
I'm not sure whether 'eo_eo', 'eo_us' and/or 'eo_xx' should be removed as keys, but 'eo' should have 'eo.UTF-8' as value.
Esperanto locales were indeed fixed in gh-422 but then reverted in gh-713. According to gh-64286, this is because CPython uses X11 names from locale.alias instead of GLibc aliases and both alternatives lead to bugs.
Activity
carmenbianca commentedon Nov 4, 2018
See the following script:
'eo_XX.ISO8859-3' does not exist on Fedora 29 or Debian Stretch. The only Esperanto locales that exists are 'eo' and 'eo.utf8'. Even so, locale.py defines the Esperanto locales as follows:
eo_EO used to exist on Debian in the early 2000s, and eo_XX on some other distributions. Since glibc 2.24 upstreamed Esperanto, however, it has been 'eo[.utf8]'.
I'm not sure whether 'eo_eo', 'eo_us' and/or 'eo_xx' should be removed as keys, but 'eo' should have 'eo.UTF-8' as value.
arhadthedev commentedon Feb 13, 2023
Esperanto locales were indeed fixed in gh-422 but then reverted in gh-713. According to gh-64286, this is because CPython uses X11 names from
locale.aliasinstead of GLibc aliases and both alternatives lead to bugs.