Re: non-ASCII characters in /etc/locales.alias ?
At Thu, 24 Jan 2002 17:54:10 -0500,
Glenn Maynard wrote:
> > > It's impossible to tell if it can be displayed in the current locale.
> > > Like Tomohiro said earlier, the ISO-8859-1 sequences are valid in other
> > > charsets; they'll just display as junk. Perhaps don't display *any*
> > > aliases with 8-bit characters?
> > And also, there is a possibility that ISO-8859-1 bytes are
> > invalid in other encodings.
> That was the original point: to not display locale aliases that can't be
> displayed in the current locale. This simply can't be done reliably.
This is possible if we limit the environment is GNU libc.
The current locale can be obtained by nl_langinfo(CODESET).
And, the "locale" utility is shipped with GNU libc distribution,
it is possible for GNU "locale" utility to use nl_langinfo()
without sacrifying portability.
However, I prefer that "locale -a" doesn't display 8bit
locale names at all, than "locale -a" displays 8bit locale
names in ISO-8859-1 locales (or locales where 0xe5 and
0xe7 are valid codepoints).
> We could even assume locale.alias is ISO-8859-1--so long as no more
> stupid aliases are added, this is reasonable--but that wouldn't gain us
> anything. We do *not* want to convert them to the current locale and
> display them "properly"--then a user might copy-and-paste these names
> into their environment, which wouldn't work (they'd be in the old
Now, if we were hope, "properly" would mean "don't convert locale
names by regarding them as characters, but keep the same byte
sequence". 0xe5 and 0xe7 might be Cyrillic, Greek, Arab, Hebrew,
Thai, or other characters according to locales.
Anyway, "locale -a" should not display 8bit locale names at all.
It is the simplest and cleanest idea. It is also friendly for
newbie users, because it can avoid new users to wrongly use such
bad locale names.
Tomohiro KUBOTA <email@example.com>
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/