From: "Antoine Leca" <[EMAIL PROTECTED]> > > 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 OpenI18n.org to Unicode.org which will ease the interoperability of systems and interchange of internationalized data.
