Kenneth Whistler wrote:
>> My assumption is that these
>> systems could support the Euro by supplying additional Latin-0 based (or
UTF-8
>> based) POSIX locales - say fr_EU.iso8859-0 or *fr_EU.UTF-8.
>
> Hoo boy. Just what we need. I realize that defenders of the POSIX locale model
> (and maintainers of software based on it) will have to come up with some
> such solutions. But isn't it becoming obvious by now that good
> internationalization design for software doesn't tie all aspects of
> localizable differences in behavior to single locale constructs,
> expecting all correct behavior to be defined there?
>
> Definition of currencies and the topology of their usage across software
> to define both monetary ratios and localizable currency formatting rules
> are *different* from character sets used for data conversion. They are
> *different* from collation rules. They are *different* from language
> identity. Anybody with a ounce of object-oriented design background can
> see that such things don't belong together in properly designed classes.
> Or for that matter, any background in table normalization in databases
> would suggest that tracking such things separately and then doing virtual
> "joins" from separate tables to define particular combinations of
> language, character set, collation, and local formatting behavior, would
> make more sense than trying to create separate entries in one table for
> all possible combinations--which is where the locale model leads.
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.
Better still, we may consider extending the current monetary definition
to handle the more than one currency case in a single country.
This problem is not unique to POSIX compliance systems. Other non-POSIX
systems have to solve the same problem.
-Longman
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT