Re: [tlug] Re: Japanese under Linux

[dstibbe <dstibbe@example.com>]

Tobias Diedrich wrote:

>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.
>  
>
Why doesn't that make sense? I want all encodings to be UTF-8 so it 
would make sense to specify it as ja_JP.UTF-8 instead of ja_JP.eucJP. It 
is just that some'thing' has to be japanese in order for my kniput2 to 
work . Preferrably I'd set no locales to ja_JP at all, but then my 
kinput2 won't accept japanese chars :S

>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
>  
>
kterm doesn't seem to have a problem with it at all.