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

[Zhe Su]

Thank you. committed.

On Sat, 26 Jun 2004 16:26:26 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> Hi James,
> 
> At Sat, 26 Jun 2004 14:22:45 +0800,
> suzhe at tsinghua.org.cn wrote:
> >
> > Hi,
> >   Changes have been committed into CVS HEAD, please try.
> 
> Following combination on FreeBSD 5.2-CURRENT is both worked
> properly for uim-anthy.
> 
> LC_ALL=ja_JP.eucJP gedit
> LC_ALL=C gedit
> 
> Although FreeBSD is recently going to support UTF-8 locales, I
> have not try it yet.
> 
> In addition, a small fix is required to compile the HEAD. See
> attached patch.
> 
> Thank you for the work.
> 
> 
> 
> > 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
> 
> 
> 
> tmp.diff - 1K
> noname - 1K Download 
>