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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo