RE: proposal: add input/keyboard locale to text and keyboard events

Hi been monitoring this thread, and wonder about its universality.

On Wed, July 21, 2010 03:20, Phillips, Addison wrote:
> (laughs) Which is why I wanted inputLocale. That is a precise term
> and we can enumerate that it refers to the current input method, not the
> language of the input data.

The easiest thing to detect is the current input locale. Which has been
pointed out says nothing about what IME or keyboard layout is in use at
the time, nor which languages are being used.

And it assumes you can distinguish between different input methods (and
I'm not sure that can be done in any extensible or meaningful way).

I suspect that best case scenario is that you may be able to do something
with keyboard layouts that ship with MacOS and Windows.

Hate to think of what all the various input frameworks available on Linux
would mean.

But when you start to get to alternative input frameworks and custom IMEs
and keyboard layouts on MacOS and Windows ....

How will you tell if the detected input method is what is actually being
used? Is KMD or Vanilla or inKey or Keymagic or ... being used on top of
the default OS input framework?

At any one time up to 80 percent of the keyboard layouts or input method
editors I have installed on my workstations do not ship with the OS
(whether I'm talking about Windows, Linux or the MacOS).

The rationale behind adding the features sounds good, but as they say the
devil is in the detail.

I'm concerned that its implementation may become another barrier minority
languages will have to try to overcome.

Andrew



-- 
Andrew Cunningham
Research and Development Coordinator
Vicnet
State Library of Victoria
Australia

andrewc@vicnet.net.au

Received on Wednesday, 21 July 2010 01:37:09 UTC