On Sat, Sep 02, 2000 at 10:50:25AM -0800, Doug Ewell wrote:
> Keld Jørn Simonsen <keld@dkuug.dk> wrote:
>
> >> The standard for two-letter language codes is ISO 639-1. There is
> >> also an ISO 639-2 (actually, there are two variants) that specifies
> >> three-letter language codes.
> >
> > Well, ISO 639-1 does not exist, yet. It is rather ISO 639 that is
> > being used.
>
> I may have been using the term too loosely. But I did visit the home
> page of the ISO 639 Joint Advisory Committee, which had this to say:
> <http://lcweb.loc.gov/standards/iso639-2/iso639jac.html>
>
> "The ISO 639/Joint Advisory Committee (ISO 639/JAC) has been established
> to advise both the ISO 639-1/RA Registration Authority and the ISO
> 639-2/RA Registration Authority..."
>
> I also visited <http://www.loc.gov/standards/iso639-2/criteria1.html>
> which describes "[t]he following criteria for defining new languages in
> ISO 639-1" and refers many other times to ISO 639-1. So if I am using
> the term loosely, then others in a higher position of authority than me
> are doing so as well. :-)
They are preparing for the new 639-1. I think 639-1 just passed
the DIS vote, thus just having one more ballot to go: the FDIS ballot.
> >> [The POSIX locale model] 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?
>
> I had several in mind while I was writing this. One that I know has
> been mentioned on this list is that if you are in a Euro country, such
> as France, your fr_FR locale is not sufficient to specify the use of
> the Euro currency symbol. A separate "fr_FR_Euro" locale would be
> needed. This would pose a problem if you needed to switch back and
> forth, and in any case the standard fr_FR locale will certainly not
> automatically update itself from FRF to EUR on 2002-01-01.
You can always extend the POSIX syntax yourself.
Anyway the problem with the Euro is taken care of in DTR 14652.
And it can automatically update itself to EUR on 2002-07-01,
or whenever.
> (This may not be a problem if people simply ignore the locale's currency
> symbol. I have never really understood why currency symbols are part of
> a locale anyway, POSIX or otherwise. It is naïve to think one will
> never need to express currency values in any unit except one's local
> default.)
That is what locales are for, to display local defaults (amongst
other things). So C/POSIX monetary information is primarily for
displaying local currency.
> Another example is that my preferred date format (2000-09-02) and time
> format (23:59) are not supported by a default en_US locale, so I would
> have to invent my own locale to handle this.
You can just take another locale with these values and set then as
your LC_TIME value. They are readily available eg on linux systems.
> I am a Windows user and hardly ever deal directly with POSIX systems,
> so this is based on my understanding of the model rather than real-world
> experience. Flame-free corrections and amplifications are welcomed.
Likewise, I am a happy Linux user, and do not know too much on
windows. But the locale concept is a C invention, and Windows
also have this concept, as also documented in recent mailings here.
As said, the POSIX/C locale model is extensible.
Anyway I do not think I can make my own locales under Windows?
You can do this under some POSIX systems, eg Linux, and it is all
documented in open standards.
I think that none of your examples warrant your harsh original comments.
Kind regards
keld
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:13 EDT