Re: TR35

From: Philippe Verdy (
Date: Thu May 13 2004 - 17:36:00 CDT

  • Next message: Philippe Verdy: "Re: TR35"

    From: "Mark Davis" <>
    > So if one's locale definition includes something like: language=sh-Cryl-YU
    > 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:


    It could be a good idea to keep POSIX names for these extra orthogonal
    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