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

[Ken Deeter]

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.

Ken