On Tuesday, May 11, 2004 6:59 PM, Philippe Verdy va escriure:
> From: "Carl W. Brown" <[EMAIL PROTECTED]>
>> Expats break the locale model anyway. The problem is that we use
>> country as both a language modifier and a location.
>
> From past comments I read here, it is understood now that locale
> identifiers used to select languages contain a country/territory code
> only as a legacy way to select language variants.
I disagree. You are seeing the locale identifiers just in the context of
language tagging. It is not its primary use, nor is it the historical one,
neither the most proeminent.
Main usage for locale ids nowadays is to resume all the i18n settings in an
environnement. And certainly i18n settings depends on the language, but also
on the territory you are in. When you cross the border between Italy and
Slovenia, or between Ontario and New York, the most striking difference is
not the orthography or the pitch, but rather the coins.
Then, main variations within a language have been historically identified
with countries. This might be related to the common practice from States to
affirm its independance by drawings laws on this respect. It might also be
related to the current state of orthographies between both sides of Atlantic
Ocean for some important languages (and even more when we consider the
situation 20 years ago.)
Whether this perception is correct as "first tie", or if it should be
replaced by another (which one?), I cannot say. What is certain is that it
is not universal.
Now, the two points (locale identifiers characterizes language and
territory, and languages are usually partitioned with territory information)
did interfere during the last decade (certainly RFC 1766 and 3066 might be
related to this process.) Carl's point, and I believe he is correct, is just
that these two meanings should NOT be mixed. And that when we spoke about
locales, the relevant one is the first one (the part you snipped.)
> This code is meant
> to designate the language variant as spoken in that area, but not for
> identifying a location.
I am very sorry, but if in
LANG=fr; LC_MONETARY=es_ES
you consider that _ES above is a language variant of Spanish Castilian as
different from Hispanoamerican, you are deeply wrong.
> However the set of variables in POSIX is not rich enough or tweaked,
> because a single LC_ALL variable can override all these variables.
You are completely distording the model here.
The normal setting is as above: LANG, then LC_xxx where LANG is inadequate.
LC_ALL is an alternative way, that allows a _supplementary_ level. This is
very useful when you have to temporarily override the setting (please
remember that POSIX is initially console-oriented), because this way you can
with not too much keystrokes specify a desired behaviour for a given action,
like it
LC_ALL=POSIX cc myStrangeProgram.c
> This means that all settings what can be defined in a locale must be
> definable with the same identifier.
No, it does not _mean_ that. No obligation here.
Anyway, the general way to implement the standard C setlocale() is just
that, an identifier (not even human-readable, that is not its point) that
groups all settings.
If a Taiwanese sets in .profile
LC_ALL=zh_TW; export LC_ALL
and then complains the locale model is wrong, everybody, you included, will
tell him that what is primarly wrong is her setting.
> Now a good question is: can all settings in locales be selective
> enough to allow specifying correctly the possible values.
Define "possible": are you writing about the set of already described
locales? (the only useful, as Carl wrote, en_GU is essentially non-existent;
same for 0x180c)
Or about all the potential possible values, including pro_QQ for Occitan as
used within the Chancellery of Toulouse?
> Is the POSIX syntax enough for them?
Since it exists an extension to it in ISO/IEC TR 14652, answer here is
probably no.
Antoine
