Internationalisation, setlocale()

Morten Hastrup morten at modulex.dk
Wed May 9 19:01:51 AEST 1990


barr at frog.UUCP (Chris Barr) writes:

>In article <11071 at cbmvax.commodore.com>, valentin at cbmvax.commodore.com (Valentin Pepelea) writes:

>> The ANSI C function setlocale() allows the programmer to set the locale to
>> be used in localised functions. As examples we are given
>> 
>> /usr/lib/locale/german/LC_MESSAGES/		contains message catalogues
>>                       /LC_COLLATE               collation (sorting) information
>>                       /LC_TIME                  time & date information
>>                       /LC_NUMERIC               number format infomation
>>                       /LC_MONETARY              monetary symbol & format info
>> 
>> But this is rather confusing. While messages and collation information varies
>> according to language, time format and monetary information is country specific.
>> So how are locale directories supposed to be organised?

>Name directories for BOTH country and language.  
>Files which are the same for different 'locales' might be linked, e.g. messages 
>in switz_french & canada_french.
>e.g.:
> /usr/lib/locale/switz_german/
> /usr/lib/locale/switz_french/
> /usr/lib/locale/canada_french/
> /usr/lib/locale/canada_english/

You might be right, but why organise it this way when ther is no recommenda-
tion on this field. I have tryed to find some in X/OPEN Portability Guide.
Besides, other companies/people ( Digital f.x. ) organise the locales this way:

	/usr/lib/intln/646/ENG_GB.646	/* English ISO646 */
	                  /GER_DE.646	/* German ISO646 */
	/usr/lib/intln/8859/ENG_GB.8859	/* English ISO8859-1 */
                           /GER_DE.8859	/* German ISO8859-1 */

They also use the environment variable INTLINFO to specify this directory-
structure (e.i. INTLINFO = /usr/lib/intln/%c/%L). The dafault path is 
/usr/lib/intln.

I could not find INTLINFO in X/OPEN, so I would like to hear from other about
simular variables (And of course YOUR opinion on this field overall).

How do you avoid comflicts between your own locale and locales that belongs to
another application (I know ideel that they should be the same, but you never
know).

--
Morten Hastrup			<morten at modulex.dk>
A/S MODULEX			Phone:    +45 44 53 30 11
Lyskaer 15			Telefax:  +45 44 53 30 74
DK-2730 Herlev
Denmark



More information about the Comp.lang.c mailing list