Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Internationalisation, setlocale()
Message-ID: <16587@haddock.ima.isc.com>
Date: 2 May 90 16:06:34 GMT
References: <11071@cbmvax.commodore.com>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 23

In article <11071@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: [paraphrased --kwzh]
>[How should locale information be organized?  The monetary information is
>usually specific to a country, while the collating information is specific to
>a language.  A country may have multiple languages, or a language may span
>multiple countries.]

Seems like the locale name ought to mention both the country and the language,
e.g. "usa-english".  There would be ample opportunity for the data to be
linked%: usa-english/LC_COLLATE could be the same as uk-english/LC_COLLATE and
can-english/LC_COLLATE, and likewise can-english/LC_MONETARY could be linked
to can-french/LC_MONETARY.

It would also be reasonable to support incompletely defined locales, e.g.
"english" could be a valid local name when used in conjunction with LC_COLLATE
but invalid for LC_MONETARY (and hence invalid for LC_ALL).

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
________
% The likely UNIX implementation is as a bunch of directories with cross-
  linked files.  An alternate scheme, less specific to quirks of UNIX, is to
  have a single index file where a key like "usa-english/LC_COLLATE" is paired
  with a file name containing the data.  I mention this to demonstrate that my
  use of the word "link" need not imply a property of the filesystem.