Re: proposal: add input/keyboard locale to text and keyboard events [ISSUE-119]

Something a lot like this was suggested by Olli Pettay during discussions on
public-i18n-core (
http://lists.w3.org/Archives/Public/public-i18n-core/2010JulSep/0094.html).
The thing to remember, though, is that we want to handle not just keyboard
events, but also IMEs, handwriting recognition, etc. This does not work very
well with a global object. Here is how Olli suggested to deal with that:

> So does the inputModeLocale (or whatever to call it) really need to be
> in the events?
> Could for example navigator object have .currentInputModeLocale.
> With that a text processor could try to guess the default language even
> before user starts to type and show that to user.

> During the events dispatched because of speech input for example,
> currentInputModeLocale would point to the "currentInputModeLocale",
> which is the locale for speech. Same with keyboards.
> So the main difference would be just that the default locale would be
> available even before any input has happened.

Here is my response (
http://lists.w3.org/Archives/Public/public-i18n-core/2010JulSep/0095.html):

If the proposed (some global object).currentInputModeLocale refers to the
speech recognition software during a speech event and to handwriting
recognition software during a handwriting event and to the keyboard during a
keyboard event, then what does it refer to outside the scope of any event,
or during some event unrelated to text?

Perhaps it should then be redefined as .lastInputLocale, indicating the
locale of the last text input device to have generated input. But then if
the last text event was due to a paste operation, would it become null? If
yes, then the input locale is no longer available outside the scope of
events until the next time there is input. And if no, then during the
paste's text event its value would be misleading (it has nothing to do with
the pasted text). I guess it could become null during the paste text event,
and then go back to the last non-null value after the event is over, but
this is getting a little complicated.

What's wrong with putting the value right in the event, where the is no
possible ambiguity?

Mind you, I agree that having the input locale available outside the scope
of events would indeed be useful too. Perhaps (some global
object).lastInputLocale should be made available in addition to inputLocale
in the events. It would get updated on every text and keyboard event with a
non-null inputlocale.

Aharon

On Tue, Sep 14, 2010 at 8:29 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Tue, 14 Sep 2010 07:12:16 +0200, Hironori Bono (坊野 博典) <
> hbono@google.com> wrote:
>
>> [...]
>>
>
> So given this, wouldn't it make much more sense to have an extension on
> window.navigator, if we decide to do this?
>
> I.e.
>
>  window.navigator.keyboardLocale
>
> or some such.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>