On Fri, 6 Dec 2002, Maiorana, Jason wrote: > thanks for the tips, but what I really wanted was use japanese/other > languages > input methods, but not be in a ja_JP locale. (just the default local > en_US.UTF-8) > (Also I was hoping it could be done in an application that was already > running, > for example I would start off in VIQR, then maybe do some korean input, > then > switch to XIM/kinput2/canna, all in the original gedit window...)
You're talking about two different things here. One is XIM and the other is gtk2 input modules. Gtk2 input module mechanism (that you bring up by 'right-clicking' in gtk2 input widget area) lets you do what you want. It also supports XIM as one of supported 'modules'. Under en_US.UTF-8 locale, XIM selected is (unless XMODIFIERS is set to @im......) the default built-in XIM which is Compose mechanism. Compose mechanism is pretty powerful for alphabetic scripts although it's not so useful for Japanese and Chinese. > im curious why I would set the LC_CYPTE to ja_JP.UTF-8, > why would that be any different than en_US.UTF-8 when the > LANG is en_US.UTF-8. I'm not worried about japanese collation > i'd prefer to use a default "unicode collation". Unfortunately, most XIM servers are written in such a way that they can only be launched under a certain locale. However, gtk2 input module mechanism can be used to achieve what you want( switching between any number of different input modules in any UTF-8 locale). Somebody has to write (a) gtk2 input module(s) for Japanese (if it hasn't been written yet. There are a very powerful set of Korean input modules for gtk2 all based on U+1100 Hangul Jamos alone) Then, you can use it regardless of the locale you're in. This is great as long as you use gtk2 applications. For non-gtk2 applications, it doesn't work, though and there's still a need to write a 'wrapper XIM' server that lets users to invoke multiple XIM servers at will. There are a couple of projects going on in that direction. There's also a 'next generation input protocol' for X11 and other platforms. (look around http://www.li18nux.org). You can find more details in XFree86 I18N mailing list archive. > Im curious, why do you suggest that kinput2 should be run with > eucJP as its startup encoding? Does it have bugs if that is not the > case? I guess kinput2 was written that way. That was also the case of Korean input method Ami without my patch. Because launched under ko_KR.EUC-KR, it can't be used to input the full repertoire of Hangul syllables in Unicode, I patched it to be launchable under under ko_KR.UTF-8 locale. Jungshik -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
