[issue5815] locale.getdefaultlocale() missing corner case

2013-11-12 Thread Mike FABIAN
Mike FABIAN added the comment: Serhiy While normalize can return sd...@devanagari.utf-8, _parse_localename() Serhiy should be able correctly parse it. But if normalize returns sd...@devanagari.utf-8, isn’t that quite useless because it is a locale name which does not actually work in glibc

[issue5815] locale.getdefaultlocale() missing corner case

2013-11-10 Thread Mike FABIAN
Mike FABIAN added the comment: Serhiy, in your patch you seem to have special treatment for the devanagari modifier: +# Devanagari modifier placed before encoding. +return code, modifier.split('.')[1] Probably because of 'ks_in@devanagari

[issue5815] locale.getdefaultlocale() missing corner case

2013-11-10 Thread Mike FABIAN
Mike FABIAN added the comment: Serhiy The /usr/share/X11/locale/locale.alias file in Ubuntu 12.04 LTS Serhiy contains ks...@devanagari.utf-8 and sd...@devanagari.utf-8 Serhiy entities. Yes, I know, that’s why I wrote that the Python code inherited this mistake from X.org. Serhiy While

[issue5815] locale.getdefaultlocale() missing corner case

2013-11-10 Thread Mike FABIAN
Mike FABIAN added the comment: In glibc, sd...@devanagari.utf-8 is an invalid locale name, only sd_IN.UTF-8@devanagari is valid: mfabian@ari:~ $ LC_ALL=sd_IN.UTF-8@devanagari locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=sd...@devanagari.utf-8 locale charmap locale: Cannot set LC_CTYPE to default

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

2013-11-09 Thread Mike FABIAN
New submission from Mike FABIAN: Originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1024667 I found that Serbian translations in Latin do not work when the locale name is written as sr_RS.UTF-8@latin (one gets the cyrillic translations instead), but they *do* work when

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

2013-11-09 Thread Mike FABIAN
Mike FABIAN added the comment: The problem turns out to be caused by a problem in normalizing the locale name, see the output of this test program: mfabian@ari:~ $ cat ~/tmp/mike-test.py #!/usr/bin/python2 import sys import os import locale import encodings import encodings.aliases

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

2013-11-09 Thread Mike FABIAN
Mike FABIAN added the comment: A simple fix for that problem could look like this: mfabian@ari:~ $ diff -u /usr/lib64/python2.7/locale.py.orig /usr/lib64/python2.7/locale.py --- /usr/lib64/python2.7/locale.py.orig 2013-11-09 09:08:24.807331535 +0100 +++ /usr/lib64/python2.7/locale.py 2013

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

2013-11-09 Thread Mike FABIAN
Mike FABIAN added the comment: in locale.py, the comment above “locale_alias = {” says: # Note that the normalize() function which uses this tables # removes '_' and '-' characters from the encoding part of the # locale name before doing the lookup. This saves a lot of # space in the table

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

2013-11-09 Thread Mike FABIAN
Mike FABIAN added the comment: I think the patch I attach here is a better fix than the patch in http://bugs.python.org/msg202469 because it makes the normalize() function behave more logical overall, with this patch, my test program prints: mfabian@ari:/local/mfabian/src/cpython (2.7-mike

[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin

2013-11-09 Thread Mike FABIAN
Mike FABIAN added the comment: The patch http://bugs.python.org/file32552/0001-Issue-19534-fix-normalize-in-locale.py-to-make-it-wo.patch is against the current HEAD of the 2.7 branch, but Python 3.3 has exactly the same problem, the same patch fixes it for python 3.3 as well