Hi,
From: Jungshik Shin <[EMAIL PROTECTED]> Subject: Re: supporting XIM Date: Thu, 27 Mar 2003 18:38:51 -0500 (EST)
That's not a problem at all because there are Korean, Japanese...
and Chinese input modules that can coexist with other input
modules and be switched to and from each other. With them, you
don't need to use XIM.
One point: Many Japanese texts include Alphabets, so Japanese people
want to input not only Hiragana, Katakana, Kanji, and Numerics but
also Alphabets. I imagine Korean people want, too. In such a case,
switching between Alphabet (no conversion mode) and conversion mode
has to be achieved by simple key typing like Shift + Space.
There are two switchings involved here. One is the intra-module mode/level switching and the other is inter-module switching.
What you want for Japanese (and correctly guessed Koreans also need) can be easily
achieved by the intra-module mode swtiching method of a single gtk2 input module.
For instance, all 5 modules included in imhangul Korean gtk2 input modul
suite interpret 'shift-space' as the toggle switch between Korean and English
input modes and 'F9' for Hangul-to-Hanja conversion. I don't see any reason
the same cannot be done for Japanese gtk2 input modules. I believe
there's nothing in gtk2 input moduel framework that prevents a
single input module from supporting multiple 'modes' (or levels) that can be switched
around if necessary.
As for inter-module switching, I guess some more work is necessary. It seems like the only way to switch to another input module is through pop-up menu that can be 'summoned' by right-clicking. However, combined with KDE keyboard switcher (I got to know that gnome2 has a similar utilitiy) that appears to be a simple wrapper over xsetkeymap, you don't have to right-click very often, I believe.
Another point: I want to purge all non-internationalized softwares.
Today, internationalization (such as Japanese character support) is
regarded as a special "feature".
However, I think that non-supportingI agree and think most, if not all, people on this list agree, too. Thanks to
of internationalization should be regarded as a bug which is as severe
a lot of smart people from all over the world including a lot of contributors
like you from Japan, free/open source communitiy has taken several,
if not a lot more, huge steps forward in terms of I18N during
the last few years. Back in 1998, when I read Drepper's paper
on I18N in glibc, the problem appeared to be overwhelming. As lately
as 1999/2000, KDE team mixed up L10N and I18N and claimed that
KDE 1 supports CJK while all it actually had was translated messages
in CJK. Now look what we have. gtk2/gnome 2/pango, KDE3/qt, glibc2,
XFree86, Xft/fontconfig, freetype, _NET_WM extension, ICU, Perl 5.8,
xterm/mlterm, vim, yudit, Omega/Lambda, many others I forgot to mention
means users have freedom to choose. Such a freedom of choice must not
be a priviledge of English-speaking (or European-languages-speaking)
people. Do you have any idea to solve this problem?
No question about that. What do we have to do? Well, just as we have done so far, I think we have to keep working as well and as hard as we can. I think I18N-awareness and I18N-mind are now widespread among developers worldwide and I'm not worried as much about CJ(K) as you're. However, we still need to go a long way to (fully) support complex scripts of South Asia, SouthEast Asia, SouthWest Asia (Middle East) , Korea(Hangul is a complex script) and Europe/Africa/North America(yes, Europe ! Latin/Greek/Cyrillic alphabets are complex, too !!)
Of course several Japanese companies are competing in Input Method area on Windows. These companies are researching for better input methods -- larger and better-tuned dictionaries with newly coined words and phrases, better grammartical and semantic analyzers, and so on so on. I imagine this area is one of areas where Open Source people cannot compete with commercial softwares by full-time developer teams.
As some linguists observed, Japanese writing system seems to offer a number
of fascinating opportunities for linguists/computer programmers to put their
mature and immature ideas to test.
How about Korean?In case of Korean, conversion to Hanja(Chinese characters) is not such a important issue
as in Japan. Simple dictionary based word and character look-up appears to be sufficient
for most Korean users because they rarely use Hanja. As for Hangul input(putting
aside pre-1933 orthography Korean for the moment), there are two major keyboard layouts
(like qwerty vs dvorak) with a few variants, but the situation has been stable for more than a
decade. In other words, there doesn't seem to be much room for innovation because
Korean input is not much more complex than input of Latin/Greek/Cyrillic alphabet-based
scripts.
Cheers,
Jungshik
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
