[Tutor] locale.set/getlocale asymmetry
eryksun at gmail.com
Thu Feb 21 07:33:14 CET 2013
On Wed, Feb 20, 2013 at 3:56 PM, Albert-Jan Roskam <fomcl at yahoo.com> wrote:
> Ah, I always wondered about that. So getdefaultlocale() always returns
> the same as getlocale() on Linux?
On Linux, getdefaultlocale looks for the locale name in environment
variables (LC_ALL, LC_CTYPE, LANG, and LANGUAGE), with a default of
'C', and parses the name with _parse_localename. It can't use
setlocale(LC_ALL, '') because that would actually set the default
getlocale() returns the parsed locale for the current LC_CTYPE config,
not the system default locale.
> So basically, the locale specification may differ:
> [A] between OS families (Unix, Windows, ...)
> [B] between OS versions (Windows XP, Windows 7, ...)?
For a GUI application, your toolkit may have tools to abstract away
platform details. For example Qt QLocale:
>>> # set API v1 QString for this example
... import sip; sip.setapi('QString', 1)
>>> from PyQt4.QtCore import QLocale, QString
> One additional question: when is it REALLY necessary to specify a
> locale variant modifier, e.g. en_US.cp1252 at euro, or perhaps the
> more eccentric nl_NL.cp874 at preeuro (dutch locale, thai/latin codepage ;-)
It's for clowns like me to do this:
>>> setlocale(LC_ALL, 'en_US.UTF-8 at yadnom')
'en_US.UTF-8 at yadnom'
On Debian Linux, I copied the original en_US to
/usr/local/share/i18n/locales/en_US at yadnom, modified the LC_TIME
config, updated /etc/locale.gen, and ran the locale-gen script to
More seriously, a system administrator may have a good reason to
create a modified locale for LC_MESSAGES, etc, so I guess you should
ask sys admins if/how they use this.
More information about the Tutor