Longman responded:
> Character set, collation rules and monetary information belong to
> different categories of the locales and can be controlled
> independently. So it is not true that one have to accept all the
> settings in a single locale. It is possible to choose the desired parts
> from different locales to meet one's need.
>
> Instead of defining a funny locale like fr_EU.iso8859-15, one can
> define a fr_FR.iso8859-15@Euro variant that use Euro as the currency and
> set LC_MONETARY environment variable to fr_FR.iso8859-15@Euro to pick up
> this part.
So then where do I get the Euro for German or Italian or Greek formatted
data, or for my multilingual environment? Or what if I need to keep
the Lira for my Italian formatted data at the same time? Environment
variables are the wrong technology for dealing with these issues.
I take your point that not every setting difference needs to be
expressed in a single locale, and that the model allows you to pick
and choose settings from different parts of different locales. But
I still contend this is heading towards chaos (and is, indeed, already
chaotic across platforms). And how are clear choices systematically
passed up to users, when even the implementors are confused about
these locales and their definitions?
>
> Better still, we may consider extending the current monetary definition
> to handle the more than one currency case in a single country.
How about more than one language in a single country? How about
more than one character set for a single language? How about more
than one collation for a single language, or vice versa?
>
> This problem is not unique to POSIX compliance systems. Other non-POSIX
> systems have to solve the same problem.
Agreed. But I'd be happier if the last sentence of your first paragraph
read, instead:
It is possible to choose the desired behavior to meet one's need.
--Ken
>
> -Longman
>
>
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT