Correct invalid universal locale names#122877
Conversation
These probably don't matter for anything. According to the comments in locale.alias, univ and universal apply to HPUX 9.x. But the "en_US.utf" values are obviously incorrect, and invalid in glibc. Debian has been carrying this patch since around Python 2.4. Either it should be upstream, or it should be dropped from Debian. Looking into this leads to bpo-20087, which temporarily fixed this before, as part of a larger cleanup in the migration to glibc 2.24 locales. That was reverted. The invalid value itself comes from xfree86, as far as I can tell. It appeared in 1999 [0] and were corrected in 2000 [1]. locale.py was written in-between and cribbed the broken values [2]. [0]: https://gitlab.freedesktop.org/ajax/xfree86/-/commit/16664e079de9938a4354e94c5c5afe5476bbaa98#8c0c2f24be5c75f99e8d6e55aa310736636d2584_10_480 [1]: https://gitlab.freedesktop.org/ajax/xfree86/-/commit/40f478e907f33fc56633bb16f7a6756314d0c10d?page=3#8c0c2f24be5c75f99e8d6e55aa310736636d2584_496_496 [2]: 5431bc3
4dc4c88 to
5a3fd6c
Compare
malemburg
left a comment
There was a problem hiding this comment.
Yes, this is fine. Thank you.
|
Do we need an issue # and NEWS entry for this ? |
|
This data is generated from the I think that we can replace "univ" and "universal" with "univ.utf8" and "universal.utf8@ucs4". We can also use opportunity to update the rest of the mapping. I have created issue #64286. |
|
#129647 includes also this change. |
|
Thanks @serhiy-storchaka! We can close this, then. |
|
Regeneration of the mappings from a more up-to-date X11 file would, of course, also be good, but since the current X11 file does not include those old lowercase names, they would not get updated via the script, AFAIR. |
|
Looking at @serhiy-storchaka new ticket, the old entries would get removed, which is probably fine as well. |
|
I removed them manually before using |
These probably don't matter for anything. According to the comments in locale.alias, univ and universal apply to HPUX 9.x.
But the "en_US.utf" values are obviously incorrect, and invalid in glibc. Debian has been carrying this patch since around Python 2.4. Either it should be upstream, or it should be dropped from Debian.
Looking into this leads to bpo-20087, which temporarily fixed this before, as part of a larger cleanup in the migration to glibc 2.24 locales. That was reverted.
The invalid value itself comes from xfree86, as far as I can tell. It appeared in 1999 0 and were corrected in 2000 1. locale.py was written in-between and cribbed the broken values 2.