>What we really need is an input method toolkit, or wizard, that would
>enable a non-sophisticated user to develop input methods for their
>favorite languages. Not to play OS-favorites, but Mule emacs does
>have a framework for entering new input methods (called quail), and
>while it does not look to be a trivial task, it certainly seems like
>something I would investigate if I were sufficiently interested in a
>certain unsupported language.
>
>As far as I can tell, there is a certainly degree of functionality
>which would permit input methods for most of the world's languages to
>be specified. With all of the slick programming aids that are being
>developed for the Windows environments, something for designing input
>methods would be extraordinarily useful.
The programmability of emacs (which is now more-or-less rejoined with
mule) opens up a general opportunity for the provision of new input
methods, and lots have been provided. You might take a look at Wnn (a
server-based kana-to-kanji conversion system) as an alternative
framework to quail, for instance, which seems to be especially well
suited to dictionary-based entry in a networked environment.
In the Windows case, you might look at the "Tavultesoft Keyboard
Manager," which is available (I think for free) from SIL. It offers a
fairly general programming environment specifically oriented towards
creating keyboard input methods, with a lot of examples and a decent
manual. I found it fairly easy to use.
Neither of these offers much help to non-programmers. There may well
be other systems that do; as you say, at least for simple problems,
it ought to be possible to make an easy-to-use tool for designing
and storing input methods. I've seen a French (Canadian?) system
for the Mac that seems to be of this type, though I don't know
much about its capabilities and limitations.
This topic is actually relevant to unicode, I think, even though
keyboard input methods in general are not.
The whole currently tangled problem of character codes, code pages,
fonts and so forth makes even the use of keyboard entry systems
tricky. Dealing with these issues on any one platform is full of
unexpected pitfalls, in my experience, and managing things across
platforms and past interactions with other software is worse. I'm not
sure that a user-friendly GUI for designing input methods would be of
much general value, at least for dealing with very different kinds of
character sets, unless these other problems were handled.
Unicode seems to be a necessary but not sufficient condition for
providing a general solution. It's frustrating that the other
components of a solution -- including actual implementations of full
Unicode-based display, editing and printing capabilities -- are so
slow in coming.
-Mark Liberman
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:36 EDT