From: Philippe Verdy (firstname.lastname@example.org)
Date: Tue May 11 2004 - 11:59:19 CDT
From: "Carl W. Brown" <email@example.com>
> Expats break the locale model anyway. The problem is that we use country as
> both a language modifier and a location. Thus a Brazilian community in the
> US can not pick pt_BR as a language and US as a territory.
From past comments I read here, it is understood now that locale identifiers
used to select languages contain a country/territory code only as a legacy way
to select language variants. This code is meant to designate the language
variant as spoken in that area, but not for identifying a location.
So a user that prefers Traditional Chinese will set its locale to zh_TW even if
that user is not in Taiwan. For timezones and currencies, the locale needs
another spacialized setting. In POSIX, the main locale specifier is not enough:
LANG selects the language, but for all other areas (currency and legal
commercial constraints, time and number formats, time zone and so on) there are
separate locale identifiers (TZ, LC_TIME, LC_MONETARY, LC_NUMBER...). This seems
good and allows various combinations to match what is needed in user's
However the set of variables in POSIX is not rich enough or tweaked, because a
single LC_ALL variable can override all these variables. This means that all
settings what can be defined in a locale must be definable with the same
Java defines one unique main locale that plays the role of the POSIX LANG
setting. Any other specialized locale settings however may be set as needed by
creating other instances of the Locale object.
Now a good question is: can all settings in locales be selective enough to allow
specifying correctly the possible values. Is the POSIX syntax enough for them?
Apparently no for the timezone setting (TZ) which has almost always used
distinct locale identifiers.
This archive was generated by hypermail 2.1.5 : Tue May 11 2004 - 11:59:43 CDT