Re: Common Locale Data Repository Project

From: Philippe Verdy (
Date: Fri Apr 23 2004 - 05:58:12 EDT

  • Next message: Hideki Hiura - "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 supported
    on Windows and MacOS too.
    It's true that Windows and MacOS has deprecated the use of environment variables
    for system-wide configuration or user settings, but this does not mean that this
    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 3166
    (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 data
    using older identifiers using some standardized locale resolution algorithm.
    Java has such a basic algorithm, which is a bit richer in ICU; if this algorithm
    should be tunable by user-settings or by a program, these tunings that control a
    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 locale
    identifiers). So I approve the migration from to which
    will ease the interoperability of systems and interchange of internationalized

    This archive was generated by hypermail 2.1.5 : Fri Apr 23 2004 - 06:34:11 EDT