From: "Carl W. Brown" <[EMAIL PROTECTED]> > 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 environment. 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 identifier. 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.