Keld Jørn Simonsen wrote:
> On Fri, Sep 01, 2000 at 08:11:02PM -0800, Doug Ewell wrote:
> > POSIX locale names are also formed from 639-1 language codes and 3166-1
> > country codes. Unlike in RFC 1766, the elements are separated by an
> > underscore rather than a hyphen. POSIX uses this language/country code
> > to represent not only the language and local dialect, but all the
> > attributes of a locale setting, such as decimal separator, thousands
> > separator, currency symbol, default date format, etc. It is widely
> > regarded as inadequate for covering even a reasonable subset of locale
> > possibilities.
> However, this is the methodology that everybody uses, inclusive
> Microsoft (viz. another email here) and what RFC 1766 is modelled after.
> It works well for the programs I am using. What are the problems that you
> percieve here?
That is pretty closed, isn't it? When you are outside of the supported
areas, you are alone with pretty specific tools like localedef or the Locale
system of the JDK (the one that you cannot easily modify without having
a lot of problem while upgrading)? And as Sean explained, this is even
almost impossible with MS.
How can I express that I speak a dialect of Catalan (Valencian), where verbs
are conjugated in a slightly different way (very important for spell checkers)?
I am sure Acadians or some Chinese users share the same kind of problems.
Why am I forced to explain the relevant country when I want to select some
collation order? (this turns to ridiculous in MS for Arabic and Spanish; even
if it does not include a "es_US" locale...) And of course, if you're living
abroad, you're stuck, as explained above (I know POSIX has a solution with
the hierarchy of variables LANG then LC_xxx then LC_ALL or something like that).
How can I express that my present locale, "ca-FR-EURO" (Java/ICU way, but it is
unknown from the JDK) is the same as the (<<standard>>) "ca-ES-EURO" ?
Why can't they merge as "ca-EU"?...
I regard this as a try out to specify in a discrete way informations that are
fuzzy in nature. Very difficult to achieve, IMHO.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:13 EDT