As Andrey A. Chernov wrote:

> I.e. theoretically right now we can reduce locale names to two
> components (language and territory) since we have in -current (but
> not in -stable) nl_langinfo(CODESET), but not to one component
> (language) since there is no standard function to get territory.

I thought of two components, like ru_RU, en_US, or de_DE.  AFAICT,
that's the common practice i've seen in the other Unices.

> But then we need to rewrite all old programs which parse LANG
> directly to use nl_langinfo(CODESET).

I didn't know that programs parse the name of the locale directly, i
always thought they just use the contents of files pointed to by this
name (under /usr/share/locale/), i. e. the actual local name would be
opaque to the application.

Do you have an example of a program parsing the name?  I can't imagine
right now who does it and why...

Apart from that, those old applications would fall over the locale
name change anyway (e. g. they expect "de_DE.ISO_8859-1" but find
"de_DE.ISO8859-1" which they are not prepared to handle), so that's
really a good reason to introduce the lang_TERRITORY shorthands by the
same time (i'm speaking of -current only!).

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to