Re: Japanese input in an English environment
At 20 Aug 2002 23:07:01 +0900,
> Is there any possibility of extending multilingualization to more
> programs? I would like to have everything work like emacs and allow
> mixing of languages, since I'm working on being bilingual. I would
> like things under linux to work kinda like Mac OS X or Windows, with a
> default language, but allow for other languages to show up, and for a
> decent unified input method.
Unfortunately, for Japanese users and developers, support of
singly Japanese has more priority than multilingual, because
Japanese monolingual environment is yet poor. Of course there
are much more people who need Japanese support than people who
need bilingual support of Japanese and another language.
International input is one of the most difficult fields in i18n.
It is because ...
(1) XIM (X Input Method) protocol is difficult to understand.
(2) XIM can be used only from softwares which supports XIM, unlike XKB.
(3) XIM is required only by east Asian languages, which causes
lack of active developers who understand XIM, write patches
for various softwares in the world, send them developers in the
world, and explain the patches and persuade to adopt the patches.
It also causes developers in the world (outside east Asia) to
tend not to be interested in XIM.
(4) Even though it is true that there are a certain amount of softwares
which support XIM, there are few softwares which support switching
To solve these problems, modern widget sets like GTK and Qt supports
XIM. By using XIM-supported widgets, general developers can be free
from studying XIM. However, the problem is that these sets have
non-XIM-supporting version of widgets (and, even more, non-fontset-
supporting version of widgets)! Novice developers may choose these
non-internationalized widgets! Note that Xaw is also internationalized.
For bilingual or multilingual input, emacs or xemacs-mule has been
the only solution for a long time. However, recently, there are
several softwares which support multilingual input, such as:
yudit ... Unicode editor with its own multilingual input mechanism
mlterm ... terminal emulator which can switch multiple XIM servers
Gnome2 ... I heard that this can switch multiple XIM servers.
For example, to input Japanese and Korean in mlterm,
LANG=ja_JP.eucJP kinput2 &
LANG=ko_KR.eucKR ami &
LANG=(your favorite locale, probably UTF-8 locale) mlterm &
And then you can choose XIM server from mlterm's menu.
Please note XIM is (so far) only for east Asian languages. You can
input other languages by changing XKB mapping using setxkbmap command.
(Thus, switching XIM is needed only to input two or more of east
> The switching locales just to input a specific language is not very
> efficient, and a very localization-internationalization way of doing
I agree. Technically, XIM clients can call setlocale() only when
it connects to an XIM server. mlterm uses this technique to support
multiple XIM servers. But, you know, this is an information for
Anyway, I think it is a bad idea that each software has its own
unique mechanism for multilingual input, because users will have
to remember how to use each of these mechanism. There should be
some unified way for multilingual input.
Though I am not very familiar, there is IIIMF Project which
develops a new mechanism for multilingual input.
I hope this project will solve problems around multilingual input.
The problem is that IIIMF seems to need Li18nux's version of libX11,
not XFree86's one.
> I know there is a lot of work to be done, and I'm interested in
> helping doing it. But I don't know exactly what's involved. I know
> it's probably going to be a big undertaking. But I would like to try.
Fantastic! I think the best way is to promote IIIMF project.
However, I think IIIMF is a long-term solution which won't be
available soon. For short-term solution, I can think about an
XIM proxy server which can connect to various XIM servers.
Please search "ximswitch" which was a part of Kondara Linux
> First, the underlying framework just doesn't support m17n. Locales
> are l10n. Sure, you can mix English and Japanese, but what if I want
> to mix Japanese and Arabic? So an underlying framework needs to be
> made. Maybe it could just be something like a UTF-8 locale that has
> all the characters we need.
Character set is only one aspect of this problem. Yes, you are right,
I think UTF-8 is the best choice for mixture of Japanese and Arabic
and, in future, all of us should use UTF-8. However, each language
has its own special problem. Input method, doublewidth, Han Unification,
special line-breaking algorithm, and so on for Japanese. BiDi, shaping,
and so on for Arabic.
> Second are fonts, both for console and for X. I think for things to
> really work, Linux needs some Free fonts that include as many glyphs
> from as many languages as possible.
> Third, would be to get all the major programs to us these fonts and
> the framework.
Right, but I think it is better to prepare some framework or library
to supply multilingualization, because we can never hope all developers
in the world will study multiligualization. We have to prepare
development environment which novice developes cannot develop non-
> Finally, there would need to be a unified input method for everything.
> Even if this was tied either to something like XIM, or to GNOME/KDE,
> it would be useful, and make things easier for all of us.
Tomohiro KUBOTA <firstname.lastname@example.org>
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/