Marc-Andre Lemburg added the comment: On 09.03.2017 08:15, Benjamin Peterson wrote: > > "eo_XX" is just something that appears in the X11 locale.alias file. My > change doesn't add that; it was already there. (for Esperanto, which I > suppose explains the "XX")
Yes, I know. That was an example of a bug in the X.org list. > Most of the changes you identify the glibc aliases taking precedence over the > X11 ones. e.g., glibc has "fi_FI ISO-8859-1" while the X11 locale list has > "fi_FI.ISO8859-15". That seems correct to me as far as the intent of this > change is concerned. No, it's not correct. ISO-8859-1 is the older version of Latin-1 without the Euro sign. ISO8859-15 adds it. > How do you propose to pick and choose what we use from the X11 locale alias > list? We have to go through the list one by one to check whether the mapping update makes sense and is correct. This will be difficult in a few cases where the glibc mapping switches to UTF-8 from an ISO encoding. We'll have to find evidence that this change does indeed make sense. My take on this is that the X.org folks know better than the glibc folks, since the former have to deal with end users that rely on the locale settings a lot more than applications using glibc for getting an initial locale setting right. Also note that you are parsing the SUPPORTED file from glibc (in slightly processed form): https://github.com/bminor/glibc/blob/master/localedata/SUPPORTED This file does not provide a locale alias mapping as the routine in makelocalealias.py suggests. Instead it's a list of locales to install by default: https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/localedata/Makefile In glibc you can define both the locale and the encoding separately when creating a locale using localedef and the file simply provides the default parameters to pass to this tool. As such, I don't see how you can derive a default alias meaning from the file. It's simply an indication of what glibc would have installed in case it were installed from source, but that's hardly ever the case. On today's systems only a bare subset of locales is installed and more added as necessary, so you rarely have all the locales defined in SUPPORTED installed on a system. So the file doesn't even provide a hint at what could be installed on the system ("locale -a" gives you that list). Here's the history: https://github.com/bminor/glibc/commits/master/localedata/SUPPORTED It's merely a list of additions and removals from the default set. Nothing more. It does provide a list of known and supported locales, but no usable or authoritative encoding information (locales are defined using Unicode, so the encoding is a parameter and not predefined). Overall, I believe the file is pretty useless to use as basis for an alias table providing encoding information. It may provide some ideas for corrections, but should not override the X.org one by default. On the other hand, you have the local.alias master file: https://cgit.freedesktop.org/xorg/lib/libX11/tree/nls/locale.alias.pre together with the history of why changes were made and when. This is an authoritative resource and people are making changes against it from the user perspective. I'd suggest to make the override optional in makelocalealias.py via a command line switch and to use this for manually adding or fixing X.org entries. If you absolutely want to parse the glibc file per default as well, please only let it add new entries, not override existing ones. As we've seen in the patch, those overrides need to be carefully reviewed. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20087> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
