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
http://www.sax.de/~joerg/ 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
