Repository navigation
Add support for glibc supported locales #64278
Description
| BPO | 20079 |
|---|---|
| Nosy | @malemburg, @loewis, @vstinner, @berkerpeksag, @serhiy-storchaka |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2014-10-19.21:06:13.487>
created_at = <Date 2013-12-27.10:12:27.573>
labels = ['type-feature', 'library']
title = 'Add support for glibc supported locales'
updated_at = <Date 2014-10-19.21:06:13.486>
user = 'https://github.com/serhiy-storchaka'bugs.python.org fields:
activity = <Date 2014-10-19.21:06:13.486>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2014-10-19.21:06:13.487>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2013-12-27.10:12:27.573>
creator = 'serhiy.storchaka'
dependencies = []
files = ['33278']
hgrepos = []
issue_num = 20079
keywords = ['patch']
message_count = 18.0
messages = ['206987', '206988', '228058', '228061', '228067', '228112', '228117', '228125', '228178', '228184', '228186', '228187', '228188', '228189', '228190', '228192', '228194', '229242']
nosy_count = 7.0
nosy_names = ['lemburg', 'loewis', 'vstinner', 'Arfrever', 'python-dev', 'berker.peksag', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue20079'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']
Activity
serhiy-storchaka commentedon Dec 27, 2013
Proposed patch adds to locale alias table the mappings for locales supported in recent glibc (v 2.18). It also modifies the makelocalealias.py script so that it parses the SUPPORTED file from glibc sources and supports command line options for source paths.
serhiy-storchaka commentedon Dec 27, 2013
Totally added 100 new mappings.
malemburg commentedon Oct 1, 2014
Thanks, Serhiy.
The patch looks good, except for one nit: the makelocalealias.py normaly also generates a list of changes and these are put at the top of the locale_alias dictionary.
Could you add that as well ?
serhiy-storchaka commentedon Oct 1, 2014
The makelocalealias.py generates only a list of removes and updates, not additions.
I recommend first apply bpo-20076, it will eliminate most additions.
malemburg commentedon Oct 1, 2014
On 01.10.2014 09:52, Serhiy Storchaka wrote:
Ah, ok.
Agreed. Please apply both patches.
Thanks,
Marc-Andre Lemburg
eGenix.com
serhiy-storchaka commentedon Oct 1, 2014
Oh, sorry, bpo-20076 doesn't eliminate additions in this issue, but vice verse this issue eliminates some additions of bpo-20076. So this patch should be applied first.
python-dev commentedon Oct 1, 2014
New changeset 810542d07b4e by Serhiy Storchaka in branch 'default':
Issue bpo-20079: Added locales supported in glibc 2.18 to locale alias table.
https://hg.python.org/cpython/rev/810542d07b4e
New changeset 00e4190b308f by Serhiy Storchaka in branch '3.4':
Issue bpo-20079: Added locales supported in glibc 2.18 to locale alias table.
https://hg.python.org/cpython/rev/00e4190b308f
New changeset 3bc5edbbadae by Serhiy Storchaka in branch '2.7':
Issue bpo-20079: Added locales supported in glibc 2.18 to locale alias table.
https://hg.python.org/cpython/rev/3bc5edbbadae
serhiy-storchaka commentedon Oct 1, 2014
Thank you for your review Marc-Andre.
See also related bpo-20087.
python-dev commentedon Oct 2, 2014
New changeset 5502a82fb103 by Serhiy Storchaka in branch 'default':
Issue bpo-20079: makelocalealias.py now supports installed SUPPORTED file,
https://hg.python.org/cpython/rev/5502a82fb103
New changeset 4a19ce6c6e0c by Serhiy Storchaka in branch '2.7':
Issue bpo-20079: Updated alias mapping to glibc 2.19 SUPPORTED file.
https://hg.python.org/cpython/rev/4a19ce6c6e0c
New changeset e9aaefa3f2eb by Serhiy Storchaka in branch '3.4':
Issue bpo-20079: Updated alias mapping to glibc 2.19 SUPPORTED file.
https://hg.python.org/cpython/rev/e9aaefa3f2eb
New changeset 994a694ab71c by Serhiy Storchaka in branch 'default':
Issue bpo-20079: Updated alias mapping to glibc 2.19 SUPPORTED file.
https://hg.python.org/cpython/rev/994a694ab71c
vstinner commentedon Oct 2, 2014
A lot of buildbot failed. Example:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/2692/steps/test/logs/stdio
======================================================================
FAIL: test_valencia_modifier (test.test_locale.NormalizeTest)
----------------------------------------------------------------------
Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_locale.py", line 428, in test_valencia_modifier self.check('ca_ES@valencia', 'ca_ES.ISO8859-1@valencia') File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_locale.py", line 370, in check self.assertEqual(locale.normalize(localename), expected, msg=localename) AssertionError: 'ca_ES.ISO8859-15@valencia' != 'ca_ES.ISO8859-1@valencia' - ca_ES.ISO8859-15@valencia ? - + ca_ES.ISO8859-1@valencia : ca_ES@valenciamalemburg commentedon Oct 2, 2014
On 02.10.2014 10:24, STINNER Victor wrote:
> Traceback (most recent call last): > File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_locale.py", line 428, in test_valencia_modifier > self.check('ca_ES@valencia', 'ca_ES.ISO8859-1@valencia') > File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_locale.py", line 370, in check > self.assertEqual(locale.normalize(localename), expected, msg=localename) > AssertionError: 'ca_ES.ISO8859-15@valencia' != 'ca_ES.ISO8859-1@valencia' > - ca_ES.ISO8859-15@valencia > ? - > + ca_ES.ISO8859-1@valencia > : ca_ES@valenciaI guess the test have to be adjusted as well :-)
What I don't understand is why the above case failed. That mapping
wasn't changed by the patch, AFAICT.
python-dev commentedon Oct 2, 2014
New changeset 7ce459fc57b9 by Serhiy Storchaka in branch '2.7':
Issue bpo-20079: Fixed tests.
https://hg.python.org/cpython/rev/7ce459fc57b9
New changeset 8c5555dea138 by Serhiy Storchaka in branch '3.4':
Issue bpo-20079: Fixed tests.
https://hg.python.org/cpython/rev/8c5555dea138
New changeset 433048fd4206 by Serhiy Storchaka in branch 'default':
Issue bpo-20079: Fixed tests.
https://hg.python.org/cpython/rev/433048fd4206
malemburg commentedon Oct 2, 2014
On 02.10.2014 10:38, Marc-Andre Lemburg wrote:
Ah, the change is in the second patch round you applied, which
is not on the ticket as separate patch file.
Reviewing that, I think this change need to be documented
(in the comment above the table) and also researched a bit:
+ 'kk_kz': 'kk_KZ.RK1048',
serhiy-storchaka commentedon Oct 2, 2014
Oh, sorry. I should be more careful.
Test failed due to mismatch between glibc and X11 locale.alias (bpo-20087). In X11 locale.alias ca_ES is mapped to ca_ES.ISO8859-1, and in glibc 2.19 it is mapped to ca_ES.ISO8859-15. ca_ES@valencia exists only in glibc SUPPORTED file and was added in the last commit (due to mismatch with ca_ES).
serhiy-storchaka commentedon Oct 2, 2014
The 'kk_kz' was added just, in the first commit of this issue (which was based on glibc 2.18 data). No changes to previous Python versions, only addition.
serhiy-storchaka commentedon Oct 2, 2014
Hmm, no, both aliases are from glibc SUPPORTED file:
ca_ES.UTF-8 UTF-8
ca_ES ISO-8859-1
ca_ES@euro ISO-8859-15
ca_ES.UTF-8@valencia UTF-8
ca_ES@valencia ISO-8859-15
malemburg commentedon Oct 2, 2014
On 02.10.2014 11:13, Serhiy Storchaka wrote:
See the comment in
https://sourceware.org/bugzilla/attachment.cgi?id=966
"The point of having
% a separate locale is only for PO translations, which have a lot of social
% support and are very appreciated by the Valencian-speaking community."
Since it's a new locale, they simply used the Latin-1 version with Euro
symbol to start with, which is a good move. Most of Europe is stuck
with having ISO-8859-1 as default, which does not include the Euro
symbol. Then again: most Unix installations use UTF-8 nowadays anyway.
serhiy-storchaka commentedon Oct 13, 2014
I think there is nothing more to do here and the issue can be closed.