Re: non-ASCII characters in /etc/locales.alias ?
On Thu, Jan 17, 2002 at 09:29:55AM +0900, Tomohiro KUBOTA wrote:
> > If wanting to have native-language tags for existing locales is wanted here,
> > then making an exception for locale.alias is arguable, but it should
> > probably be UTF-8, not ISO-8859-1. (Either way, programs using it will
> > need to know to convert it to the current locale's charset.)
> Usage of UTF-8 will be adopted when all of us will use UTF-8 in future.
> (However, not now.)
> > 日本語 ja_JP.ISO-2022-JP
> Hmm, I think it is not useful because we cannot input Japanese character
> unless configuring Japanese locale. It is just "the key for this locked
> box is inside the box" situation. (Usage of ISO-8859-1 character before
> definition of locale is also this situation.)
If you're in en_US.UTF-8, and an application wants to display a list of
available character sets, you can display it. I'm not sure what the
main goal of this list is; for selecting locales (eg. LC_CTYPE), you're
Well, unless you're in a Japanese-capable charset. (en_US.UTF-8 isn't a
Japanese locale, but I can enter 日本語.)
You can have multiple aliases for a single locale, as is already done
bokmal and french. This seems to mess up
, to do both: use the ASCII version when it's your only
In any event, it *is* probably best to stick with plain old 7-bit ASCII
for this file.
> One addition, we usually use ja_JP.eucJP locale. ja_JP.ISO-2022-JP
> is not supported by GNU libc 2.2 because ISO-2022-JP is "stateful".
Sure; it's just an example.
> > > (If you edit /etc/locale.alias with multibyte-capable editor in
> > > multibyte locales, the 8bit "undefined" characters will be probably
> > > broken. I feel this difficulty of editing when I translated Debian
> > > webpage templates with "slices". To avoid destroying the Debian web
> > > files, I have to use non-locale-supporting and 8bit editors. However,
> > > to edit Japanese, I have to use 8bit-clean and multibyte-clean editor.)
> > Why do you need an 8-bit-clean editor to edit Japanese? If you're
> > editing textfiles, in most locales, you're almost never going to be
> > 8-bit-clean (ie. I wouldn't expect an editor in UTF-8 to maintain
> > invalid UTF-8 sequences.)
> We need 8-bit-clean editor because EUC-JP is 8bit encoding.
So you need an EUC-JP-capable editor. Why does that imply you have to
use an editor that doesn't support locales ("non-locale-supporting ...
editors") to edit Debian files? If you're editing a file that's not
EUC-JP, just tell your editor that. Much easier than using different
editors (which seems to be what you said.)