From: Philippe Verdy (email@example.com)
Date: Fri Apr 23 2004 - 05:58:12 EDT
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 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
This archive was generated by hypermail 2.1.5 : Fri Apr 23 2004 - 06:34:11 EDT