Two improvements for the locale aliasing engine

[ssegvic]

BPO	12964
Nosy	@malemburg, @vstinner, @bitdancer

^{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 = None
closed_at = None
created_at = <Date 2011-09-12.12:41:26.825>
labels = ['type-feature', 'library', 'OS-windows']
title = 'Two improvements for the locale aliasing engine'
updated_at = <Date 2014-02-03.18:35:17.738>
user = 'https://bugs.python.org/ssegvic'

bugs.python.org fields:

activity = <Date 2014-02-03.18:35:17.738>
actor = 'BreamoreBoy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'Windows']
creation = <Date 2011-09-12.12:41:26.825>
creator = 'ssegvic'
dependencies = []
files = []
hgrepos = []
issue_num = 12964
keywords = []
message_count = 3.0
messages = ['143902', '185922', '185923']
nosy_count = 4.0
nosy_names = ['lemburg', 'vstinner', 'r.david.murray', 'ssegvic']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue12964'
versions = ['Python 3.3']

[ssegvic]

Hi,

There appears to be some space for improvement
regarding the stable implementation
of the Python locale aliasing engine.

Sometimes, one wishes to be able
to override the default system locale.
For instance, it would be nice that a program
supposed to sort people according to national rules
would be able to run correctly even when the system
does not default to the national locale.

Judging from the Python manuals and
provided the desired national locale is installed,
this should be doable in at least the following two ways:

import locale
ianaLanguageSubtag='en'       # the desired national locale
locale.setlocale(locale.LC_ALL,
  (ianaLanguageSubtag, locale.getpreferredencoding())) #(1)
locale.setlocale(locale.LC_ALL,
  locale.normalize(ianaLanguageSubtag))                #(2)

For a quicker reference, this is
the relevant part of the manual:
http://docs.python.org/release/3.2/library/locale.html
'''
locale.setlocale(category, locale=None)
...
If (the locale) is a tuple, it is converted
to a string using the locale aliasing engine.
...
'''

The locale aliasing engine binds
the IANA language subtags to POSIX locales.
Its effects can be directly observed
through locale.normalize:
>>> import locale
>>> locale.normalize('hr')
'hr_HR.ISO8859-2'
>>> locale.normalize('en')
'en_US.ISO8859-1'

My first objection concerns the Windows behaviour
of the calls (1) and (2) above.
Both of the two calls *do not work* since Windows
does not recognize strings such as 'en_US.ISO8859-1'.
Instead, Windows provides their own locale nomenclature:
http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.80%29.aspx
Consequently, the following *works*:

locale.setlocale(locale.LC_ALL, 'English_United States.1252')

IMHO this issue should be fixed, perhaps by providing
an alternate definition of the locale alias dictionary
(locale.locale_alias).

My second objection concerns the behaviour on Linux,
where the call (1) above always works,
while (2) in some cases might not work.
It happens that the call (2)
requests an outdated 8-bit encoding
although UTF8 has obtained a world-wide acceptance.
The call shall result in a locale error
whenever the desired national locale
is present only in the UTF8 variant.

This might be fixed by changing the encodings
in the locale.locale_alias from 8-bit variants to UTF8.
Note however that the problem could be circumvented
by issuing the call (1), so this would be
less important than the Windows fix proposed above.

Source code references:
.../Python-3.2.2/Lib/locale.py
locale.locale_alias
locale.normalize
locale.setlocale

comp.lang.python discussion:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/3591d496cf108ad2#

Cheers,

Sinisa

[BreamoreBoy]

From msg143902 "Both of the two calls *do not work* since Windows
does not recognize strings such as 'en_US.ISO8859-1'." so how can this be an enhancement?

But anyway bpo-10466 talks about the same thing, could this be closed as a duplicate?

[bitdancer]

I believe Martin is working on a proposal that will solve the windows issue, but it may be quite some time before that happens.

Yes, the windows issue is essentially a dup, but the linux issue is different.

As for your question, fixing the Windows issue is definitely an enhancement, since it requires mapping (or providing, as Martin proposes) the standard locale names on Windows, which is a service that currently doesn't exist. The linux issue might be a bug...we sometimes update alias tables in maintenance release.