From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu May 13 2004 - 17:36:00 CDT
From: "Mark Davis" <mark.davis@jtcsv.com>
> So if one's locale definition includes something like: language=sh-Cryl-YU
plus
> currency=EUR plus timezone=GMT, then that is clearly something far different
> than just language.
May be you meant language=sh-Cyrl-YU, which however was never used and will
never be used like this since "sh" was deprecated long before script codes were
defined for Cyrillic. So it would be probably: LANG=sh-YU or simply LANG=sh for
the legacy language written first in Cyrillic.
Today you would set LANG=sr-SR or just LANG=sr mostly for Cyrillic, even even
Latin is also used today (if you need the precision then LANG=sr-Cyrl-SR or
simply LANG=sr-Cyrl.
There's a way to create such compound locale ids orthogonal to language settings
by using an attributed syntax:
LANG="sr-Cyrl-sr;TZ=GMT;LC_CURRENCY=EUR"
It could be a good idea to keep POSIX names for these extra orthogonal
attributes...
The above line would set a complete locale-ID, starting by a required language
ID and optional attrbiutes for other settings.
The only problem is that there's currently no support in many programs or
libraries to support the attributed syntax to specify a resource search path
(for example when locating the appropriate resource to use with the correct
currency or timezone).
However, it can be emulated on top of Locale resource class loaders (by
considering that attributes are handled as overrides for named resources that
would be searched within the default language-ID assigned to the locale-ID.)
In Java, one would create such a locale like this:
Locale loc = new Locale("sr-Cyrl-sr);
loc.put("TZ", "GMT");
loc.put("LC_CURRENCY"; "EUR");
but the following would not work for now, although it would be the correct way
to build a locale instance with a complete locale-ID:
Locale loc = new Locale("sr-Cyrl-sr;TZ=GMT;LC_CURRENCY=EUR");
So all we can create is this object:
Locale loc = new Locale("sr-Cyrl-sr);
which will work but will not reference correctly the other settings. This would
require some rework to make either the Locale class implement the Properties
interface, or to supplement the ResourcesBundle class to allow setting such
overrides. So it seems that the "Locale" class in Java does not cover correctly
all what can be defined and selected in a Locale. A more meaningful name for
this class should have been "LanguageID".
This archive was generated by hypermail 2.1.5 : Thu May 13 2004 - 17:37:04 CDT