- From: Andrew Cunningham <andrewc@vicnet.net.au>
- Date: Wed, 21 Jul 2010 11:36:31 +1000
- To: "Phillips, Addison" <addison@lab126.com>
- Cc: "Aharon Lanin" <aharon@google.com>, "Matitiahu Allouche" <matial@il.ibm.com>, "Richard Ishida" <ishida@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
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