From: Mark Davis (mark.davis@jtcsv.com)
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.
See:
...
http://www.ietf.org/internet-drafts/draft-phillips-langtags-02.txt
http://www.ietf.org/internet-drafts/draft-phillips-langtags-02.pdf
It is also available in HTML format on my private website here:
http://www.inter-locale.com/ID/draft-phillips-langtags-02.html
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
understand.
Best Regards,
Addison
Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
----- Original Message -----
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: "Unicode List" <unicode@unicode.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
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.
>
>
>
This archive was generated by hypermail 2.1.5 : Fri Apr 23 2004 - 10:30:13 EDT