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

I do see the uses of [some global object].inputLocale and a change event
associated with it. However, I am not sure how exactly it is supposed to be
defined when there is more than one input method active, though. Can it be
left ambiguous?

Because it would be ambiguous - and incorrect for input events generated via
a secondary input method - I would still prefer to have [text and keyboard
event].inputLocale even if [some global object].inputLocale were available.

And I would certainly want to have [text and keyboard
event].inputLocale if [some global object].inputLocale does not make into
the standard either due to its ambiguity or because of the fingerprinting
concern.

So, my bottom line is that I want at least one, and preferably both of [some
global object].inputLocale and [text and keyboard event].inputLocale to be
adopted. I think it would be a real shame if neither got in because we could
not decide which one is better.

Aharon

On Wed, Oct 6, 2010 at 2:16 AM, Jacob Rossi <jrossi@microsoft.com> wrote:

>  > 2010/9/14 Aharon (Vladimir) Lanin <aharon@google.com <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
>