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

> 2010/9/14 Aharon (Vladimir) Lanin <aharon@google.com<mailto:aharon@google.com?Subject=Re%3A%20proposal%3A%20add%20input%2Fkeyboard%20locale%20to%20text%20and%20keyboard%20events%20%5BISSUE-119%5D&In-Reply-To=%253CAANLkTinRgy4NrS59v6jS70XtiV1m%3DzowRa63KPHMNTwP%40mail.gmail.com%253E&References=%253CAANLkTinRgy4NrS59v6jS70XtiV1m%3DzowRa63KPHMNTwP%40mail.gmail.com%253E>>:

>> 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.
>
> Actually, there's a good argument for not exposing inputLocale outside
> of text/keyboard events. If it is required that the user interact with
> the page before exposing locale, then this reduces the ability to
> fingerprint the user.
>
> / Jonas

An additional use case would be spell-checker or auto-complete language detection heuristics. We've done a lot of work to better support international keyboards and IMEs. This API would give better context to such input and likely has a variety of use cases we haven't even identified.

I prefer the implementation of an always available API (though, I think document.inputLocale makes more sense). It seems to me that the user is likely to change his/her language settings at a much slower rate than that of the firing of textInput or the keyboard events. For many uses that I can think of, if the locale is only surfaced through these events, then you will end up having to cache the value and check for changes at each input event. This seems like a lot of extra work when you could just be notified of changes (which probably aren't that frequent).

Further, some usage of locale is more likely to be reactionary to *changes* in the current setting rather than at the time of input. Consider my example of auto-complete. If a user switches his/her input language, the site would have to wait for input from the user in order to react to the change. If rather the page was notified at the moment of language change, then the page might have extra time before the user's input to fetch data that might be useful for that specific language (e.g.,  language-specific auto-completions).

I also think we should not consider pasting clipboard data as an unknown locale. Outside of the web browser, pasted data would be considered with whatever the user's current input locale settings are. I don't believe there's a reliable method for determining the locale of the data in the clipboard (correct me, if I'm wrong). Not changing inputLocale to null (or undefined) when data is pasted allows for the locale of pasted data to be handled by the user via changing their input locale. Restated:  only the user's explicit changes to input locale (via keyboard shortcuts, IME, speech/handwriting recognition tools, etc.) result in a change to inputLocale.

I'd imagine it somewhat like this:

On the document (or arguably, the window):
     inputLocale  of type DOMString, readonly
          A BCP-47 language tag [2] representing the input locale as last set by the user. When the underlying platform does not expose this information, the value should be "Unidentified".

As a new event:
          Type: inputLocaleChange
          Interface: Event
          Sync/Async:   Sync
          Bubbles: Yes
          Target: Element
          Cancelable: No
          Default action: none

--Jacob

[1] http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0119.html
[2] http://en.wikipedia.org/wiki/BCP_47