Re: non-ASCII characters in /etc/locales.alias ?
Hi,
At Wed, 16 Jan 2002 18:49:24 -0500,
Glenn Maynard wrote:
> That applies to all system textfiles (/etc, /usr/include).
Right. I think this is a matter of course.
> 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.)
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".
> > (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.
---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
Reply to: