Re: Common Locale Data Repository Project

From: Mark Davis (
Date: Fri Apr 23 2004 - 09:58:18 EDT

  • Next message: Jon Hanna: "RE: [OT] Even viruses are now i18n!"

    You are talking about Locale IDs. There is currently work underway on an RFC to
    replace 3066 (this is referenced by UTS #35), and one of the features is
    stability -- even where the ISO standards are not.



    It is also available in HTML format on my private website here:

    I will also be posting our issues list with resolutions and a link to the recent
    presentation by Mark and myself at the Unicode conference on that site.

    This version contains a few changes based on discussion on this list, notably it
    more closely defines the rules for using UN M49 identifiers to resolve
    ambiguity. It also contains semi-substantial wordsmithing in section 2 which is
    not substantive, but which does make the rules (we think) clearer and easier to

    Best Regards,


    ► शिष्यादिच्छेत्पराजयम् ◄

    ----- Original Message -----
    From: "Philippe Verdy" <>
    To: "Unicode List" <>
    Sent: Fri, 2004 Apr 23 02:58
    Subject: Re: Common Locale Data Repository Project

    > From: "Antoine Leca" <>
    > > > And even if a section isn't scoped specifically in terms of a
    > > > Unix-derived platform, it may specify requirements that are explicitly
    > > > related to Unix implementations (e.g. that base libraries must support
    > > > POSIX i18n environment variables).
    > >
    > > Again, where is it said that CLDR require any form of "base libraries", much
    > > less one that support POSIX variables?
    > POSIX variables are normally part of most implementations of languages
    > on Windows and MacOS too.
    > It's true that Windows and MacOS has deprecated the use of environment
    > for system-wide configuration or user settings, but this does not mean that
    > environment cannot be emulated within a program by a support library. This is
    > already happening in Java when it is started on Windows.
    > What is needed in fact is the support of an API in POSIX, but not a particular
    > system feature. The Java Locale class for example is a minimum implementation
    > API to support POSIX locales. But it could become more rich later.
    > In fact if ISO 3066 is later standardized, the designation and use of locales
    > could become its own API supporting standard identifiers. In fact the exact
    > syntax of compound locale identifiers appears to me just as a parsable
    > serialization of a more complete LocaleID object. On Windows and MacOS these
    > identifiers can be translated to/from native system identifiers. With the CLDR
    > data, this mapping of locale ids could become more documented and more stable.
    > I think that the CLDR database is extremely important for software
    > implementations, because it avoids some caveats that come from other unstable
    > standards such as ISO 3166 and ISO 639.
    > But as this CLDR data will still need to adapt itself to new changes in ISO
    > (countries and territories will probably continue to change their status, may
    > merge or split...) and ISO 639 (some new languages may become standardized),
    > what is needed is another level of abstraction to allow accessing to locale
    > using older identifiers using some standardized locale resolution algorithm.
    > Java has such a basic algorithm, which is a bit richer in ICU; if this
    > should be tunable by user-settings or by a program, these tunings that control
    > locale resolution should be documented as well (notably when mapping from a
    > locale identifier supported on one system onto another locale identifier on
    > another system, when the localization resources are not completely identical
    > between those systems).
    > What can ease the interchange of locale-sensitive data and methods is the
    > standardization of a common data encoding (Unicode), common values (CLDR
    > identifiers). So I approve the migration from to
    > will ease the interoperability of systems and interchange of internationalized
    > data.

    This archive was generated by hypermail 2.1.5 : Fri Apr 23 2004 - 10:30:13 EDT