From: Mark Davis (firstname.lastname@example.org)
Date: Fri Apr 23 2004 - 09:58:18 EDT
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
► शिष्यादिच्छेत्पराजयम् ◄
----- Original Message -----
From: "Philippe Verdy" <email@example.com>
To: "Unicode List" <firstname.lastname@example.org>
Sent: Fri, 2004 Apr 23 02:58
Subject: Re: Common Locale Data Repository Project
> From: "Antoine Leca" <Antoine10646@leca-marti.org>
> > > 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 OpenI18n.org to Unicode.org
> will ease the interoperability of systems and interchange of internationalized
This archive was generated by hypermail 2.1.5 : Fri Apr 23 2004 - 10:30:13 EDT