You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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=<Date2013-12-26.19:24:04.296>created_at=<Date2013-12-19.19:42:08.692>labels= ['type-bug', 'library']
title='Fixed support for Indian locales'updated_at=<Date2013-12-26.19:24:04.295>user='https://github.com/serhiy-storchaka'
So they will start working once platforms adopt the new
glibc versions.
The @-modifier is applied to the locale, not the encoding, because
the locale uses a different script, as opposed to limiting itself
to part of an encoding. This looks reasonable, even though I'm
not sure it conforms to standards.
Since all this is still very much in flux, perhaps we ought
to wait a bit more and let the dust settle ?!
After applying the patch Python supports all ks_IN and sd_IN locales.
Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string formatting used for
numbers is different with the modifier.
If you keep the modifiers, but move them to the end of the locale
string you should get the correct behavior, e.g.
Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string formatting used for
numbers is different with the modifier.
All the @-modifiers except euro are applied to the locale, not the encoding.
And Python removes all the @-modifiers, e.g. latin and cyrillic which specify
the script.
If you keep the modifiers, but move them to the end of the locale
string you should get the correct behavior, e.g.
'sd': 'sd_IN@devanagari.UTF-8',
'sd': 'sd_IN.UTF-8@devanagari',
(modulo perhaps the spelling of "UTF-8")
Recent the locale.alias file changes these entities:
> Well, yes, but only because you are removing the @-modifiers. I don't
> think that's correct, since e.g. the string formatting used for
> numbers is different with the modifier.
All the @-modifiers except euro are applied to the locale, not the encoding.
And Python removes all the @-modifiers, e.g. latin and cyrillic which specify
the script.
That's not quite correct. The modifiers are used to determine the
correct mapping, so you'll often find them on the left side, but
not necessarily on the right side.
There are several cases where the modifiers are kept around,
since they have implications on the way number or dates are
formatted.
For the Indian "devanagari" locales we have to keep them,
because the locale formatting of number and dates depends
on them.
> If you keep the modifiers, but move them to the end of the locale
> string you should get the correct behavior, e.g.
>
> - 'sd': 'sd_IN@devanagari.UTF-8',
> + 'sd': 'sd_IN.UTF-8@devanagari',
>
> (modulo perhaps the spelling of "UTF-8")
Recent the locale.alias file changes these entities:
So my example is wrong with the new locale.alias file. Instead,
sd will map directly to sd_IN.UTF-8.
Still, I think the makelocalalias.py script should correct
the non-standard locale names from sd_IN@devanagari.UTF-8
to sd_IN.UTF-8@devanagari in order to match the output
of "locale -a".
Activity
serhiy-storchaka commentedon Dec 19, 2013
The locales alias table contains invalid entries for devanagari modifiers (see bpo-5815):
Here is a patch which fixes aliases for these locales.
malemburg commentedon Dec 20, 2013
On 20.12.2013 12:19, Serhiy Storchaka wrote:
See my message on bpo-20034:
There is some recent activity in glibc related to these. Here's a
patch that adds the sd_IN@devanagari locale to glibc:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/sd_IN@devanagari.diff?cvsroot=glibc&r1=NONE&r2=1.1
So they will start working once platforms adopt the new
glibc versions.
The @-modifier is applied to the locale, not the encoding, because
the locale uses a different script, as opposed to limiting itself
to part of an encoding. This looks reasonable, even though I'm
not sure it conforms to standards.
Since all this is still very much in flux, perhaps we ought
to wait a bit more and let the dust settle ?!
serhiy-storchaka commentedon Dec 20, 2013
Ubuntu 12.04 supports Kashmiri and Sindhi locales (requires language-pack-sd-base and language-pack-sd-base packages).
Current Python doesn't support all of these locales:
After applying the patch Python supports all ks_IN and sd_IN locales.
malemburg commentedon Dec 20, 2013
On 20.12.2013 15:55, Serhiy Storchaka wrote:
Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string formatting used for
numbers is different with the modifier.
If you keep the modifiers, but move them to the end of the locale
string you should get the correct behavior, e.g.
+ 'sd': 'sd_IN.UTF-8@devanagari',
(modulo perhaps the spelling of "UTF-8")
serhiy-storchaka commentedon Dec 20, 2013
All the @-modifiers except euro are applied to the locale, not the encoding.
And Python removes all the @-modifiers, e.g. latin and cyrillic which specify
the script.
Recent the locale.alias file changes these entities:
sd: sd_IN.UTF-8
sd_IN.utf8: sd_IN.UTF-8
sd@devanagari: sd_IN@devanagari.UTF-8
sd_IN@devanagari: sd_IN@devanagari.UTF-8
sd_IN@devanagari.utf8: sd_IN@devanagari.UTF-8
malemburg commentedon Dec 20, 2013
On 20.12.2013 16:24, Serhiy Storchaka wrote:
That's not quite correct. The modifiers are used to determine the
correct mapping, so you'll often find them on the left side, but
not necessarily on the right side.
There are several cases where the modifiers are kept around,
since they have implications on the way number or dates are
formatted.
For the Indian "devanagari" locales we have to keep them,
because the locale formatting of number and dates depends
on them.
I'm not sure I can parse this comment :-)
Looking at bpo-20034 I think we are saying that the new updated
local.alias file contains these entries:
sd: sd_IN.UTF-8
sd_IN.utf8: sd_IN.UTF-8
sd@devanagari: sd_IN@devanagari.UTF-8
sd_IN@devanagari: sd_IN@devanagari.UTF-8
sd_IN@devanagari.utf8: sd_IN@devanagari.UTF-8
So my example is wrong with the new locale.alias file. Instead,
sd will map directly to sd_IN.UTF-8.
Still, I think the makelocalalias.py script should correct
the non-standard locale names from sd_IN@devanagari.UTF-8
to sd_IN.UTF-8@devanagari in order to match the output
of "locale -a".
serhiy-storchaka commentedon Dec 20, 2013
Updated patch to tip. The makelocalalias.py script now corrects
the non-standard locale names.
serhiy-storchaka commentedon Dec 26, 2013
Could you please make a decision about last patch, Marc-Andre?
malemburg commentedon Dec 26, 2013
On 26.12.2013 19:59, Serhiy Storchaka wrote:
Looks good. Thanks, Serhiy.
python-dev commentedon Dec 26, 2013
New changeset aad582f717da by Serhiy Storchaka in branch '2.7':
Issue bpo-20027: Fixed locale aliases for devanagari locales.
http://hg.python.org/cpython/rev/aad582f717da
New changeset 7615c009e925 by Serhiy Storchaka in branch '3.3':
Issue bpo-20027: Fixed locale aliases for devanagari locales.
http://hg.python.org/cpython/rev/7615c009e925
New changeset fff3f28733b4 by Serhiy Storchaka in branch 'default':
Issue bpo-20027: Fixed locale aliases for devanagari locales.
http://hg.python.org/cpython/rev/fff3f28733b4