[SCIM] BUG: locale dependency of SCIM's gtk2-immodule

[James Su]

Hi,
  Changes have been committed into CVS HEAD, please try.

Regards
James Su

YamaKen wrote:

>At Sat, 26 Jun 2004 13:02:36 +0800,
>james.su at gmail.com wrote:
>  
>
>>Ok, agree with you. I'll let gtk2 immodule use only UTF-8.
>>
>>Thank you very much.
>>
>>James Su
>>    
>>
>
>I'll check it on my environment once modified. Thanks for quick
>response.
>
>And also Thanks for well-detailed explanation, Ken.
>
>  
>
>>On Fri, 25 Jun 2004 22:01:04 -0700, Ken Deeter
>><ktdeeter at alumni.princeton.edu> wrote:
>>    
>>
>>>Hello,
>>>
>>>      
>>>
>>>>Hi,
>>>>  Using IMEngines which do not support EUC-JP encoding in gtk2 apps
>>>>under ja_JP.eucJP locale makes no sense, because the client can not
>>>>store the content into file, even it uses UTF-8 as internal encoding.
>>>>
>>>>        
>>>>
>>>Actually I don't think this is correct. Gtk2 apps always store internal
>>>strings as utf-8, regardless of the locale encoding. That is why there
>>>are those glib functions to convert from and to the locale encoding. For
>>>example, even if you start gedit in ja_JP.eucJP, you can still input non
>>>japanese languages just fine (uim has some chinese input methods that
>>>are all available in the gtk2 app's input method selection context
>>>menu). When you try to save it, gedit will complain that euc-JP does not
>>>cover all the unicode codepoints in the file, but the user needs to be
>>>aware of that if he wants to save in eucJP anyways.
>>>
>>>gtk2 applications are even known to assume filenames to be in utf-8,
>>>unless you set the G_BROKEN_FILENAMES env variable. So allowing
>>>non-japanese non-eucJP engines for a gtk2 app running in ja_JP.eucJP
>>>DOES make sense.
>>>
>>>      
>>>
>>>>  If you can not use uim-anthy under ja_JP.eucJP locale with the
>>>>original SCIM code, there must be a bug in src/scim_utility.cpp.
>>>>
>>>>        
>>>>
>>>Its working for me under ja_JP.eucJP.
>>>
>>>The standard is "ja_JP.EUC-JP", but many systems still use ja_JP.eucJP,
>>>partially because many old Japanese programs hard code it that way. If
>>>it is just a matter of adding one more string to try, I think it is not
>>>too much trouble to add a check for ja_JP.eucJP, because it is still
>>>used so widely. The slight non-standardness of the code would be worth
>>>it, considering all the user headaches you could save.
>>>
>>>Actually, many programs do not work so well in ja_JP.UTF-8 yet. I think
>>>kinput2 and sylpeed (gtk1-based) are some of them.. and the x core
>>>fonts (non-xft) have some issues with unicode encoding, so people tend
>>>to just stick with eucJP because its easier to get to work.
>>>      
>>>
>
>-------------------------------
>YamaKen  yamaken at bp.iij4u.or.jp
>
>_______________________________________________
>scim mailing list
>scim at freedesktop.org
>http://freedesktop.org/mailman/listinfo/scim
>
>  
>