W3C home > Mailing lists > Public > www-international@w3.org > July to September 2010

Re: Proposal: Input Method Editor API

From: 신정식 <jshin1987+w3@gmail.com>
Date: Tue, 21 Sep 2010 22:10:00 -0700
Message-ID: <AANLkTimPNH8LQ2WmaRoJd_3Uk5a1m6KVt=ZYwCXtgUPF@mail.gmail.com>
To: Hironori Bono (坊野 博典) <hbono@google.com>
Cc: Ed <ed.trager@gmail.com>, www-international@w3.org
Thanks a lot for proposing this.

2010/9/21 Hironori Bono (坊野 博典) <hbono@google.com>

> Greetings Ed,
> Thank you for your great feedback.
> On Tue, Sep 21, 2010 at 1:03 PM, Ed <ed.trager@gmail.com> wrote:
> > (1) I have a question:  What if the IME is itself written in Javascript?
> >
> > I ask this because your proposal appears to assume that the IME is an
> > operating-system-based IME.  Often that is the case, of course.
> > However, one should also consider the possibility of a
> > Javascript-based IME in which the controlling IME code and data both
> > originate from a network URL resource (I have been working on exactly
> > such a Javascript-based IME system).
> In my honest opinion, I would love to make this API cover
> JavaScript-based IMEs as well as system IMEs, i.e. web applications
> can control JavaScript-based IMEs with this IME API as well as they
> can control system IMEs with it. Nevertheless, I need help to figure
> out this API is good for JavaScript-based IMEs because I'm a browser
> engineer and do not have so much knowledge about JavaScript-based
> IMEs.

A few Firefox extensions implementing IMEs:

FireInput : https://addons.mozilla.org/en-US/firefox/addon/5420

KitSune (Japanese): https://addons.mozilla.org/en-US/firefox/addon/14082/
Sogou Cloud Input (Chinese):

 I haven't look at the internals, but I guess they're not purely
Javascript-based, but nonetheless they can give some insights.

> > In any case, it makes a lot of sense to me to be able to control an
> > IME as your document suggests.
> Thank you so much for this encouraging comment.
> > (2)  Secondly, a comment:  The "informational" part of your document
> > suggests that IMEs are just for Chinese, Japanese, and Korean.  While
> > IMEs are of course critical for those scripts, there are additional
> > use cases where an "IME" of one sort or another is quite useful, so
> > you might consider mentioning some non-CJK use cases.
> It makes sense. I will add some non-CJK use cases (including yours) in
> the next version.

In addition to what's mentioned by others (transliteration-based IMEs,
unicode character input), an input method can be used even for English. It's
commonly found on mobile phones, but ibus (the most widely used IM framework
on Linux these days) has a module for an ispell-based Englsih input method.

Also, Thai input usually relies on IME. It's kinda simple automata and
similar to Korean IME (minus Chinese character input support).


> Regards,
> Hironori Bono
> E-mail: hbono@google.com
Received on Wednesday, 22 September 2010 05:10:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:31 UTC