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
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
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&g
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
'k
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
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:
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
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:
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
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 the
10 matches
Mail list logo
