[tlug] Re: Japanese under Linux

[Tobias Diedrich <ranma@example.com>]

dstibbe wrote:

> That did 'm . My settings are now :
> 
> export LANG=en_US.UTF-8
> export LANGUAGE=en_US.UTF-8
> export LC_CTYPE=ja_JP.UTF-8
> export LC_MESSAGE=en_US
> export XMODIFIERS='@example.com=kinput2'
> kinput2 -canna&

If you set LANG to en_US.UTF-8 then setting LC_CTYPE to ja_JP.UTF-8
doesn't make sense (since the encoding already is UTF-8).
Setting LC_MESSAGES to en_US is also redundant in this case.

The LANGUAGE variable is a GNU extension and overrides LC_MESSAGES even
if LC_ALL is set.  It is mostly useful for specifying fallback
languages like this:
LANGUAGE="zh_TW.UTF-8:ja_JP.UTF-8:de_DE.UTF-8"
Then gettext will first look for zh_TW translations, then for ja_JP,
then for de_DE and will use untranslated strings only if no translation
was found for any of these.

> I chose UTF-8 instead of euc. Which brings me to another question . Why
> is everybody always choosing for  Extended Unix Code instead of UTF-8 ?
>  Wouldn't it help compatibility more if it was UTF-8 instead of EUC ?

Some programs still don't work well with UTF-8 (e.g. kterm doesn't
support UTF8 AFAIK) and if euc-jp suffices for you, then it's reasonable
to choose that.  Of course for multilingual environments utf8 is
preferreable.

-- 
Tobias						PGP: http://9ac7e0bc.2ya.com
He said he hadn't had a byte in three days.
I had a short, so I split it with him.