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

The short answer is that I do not really know.

However, a few minutes Googling it for Windows got me to
GetKeyboardLayout<http://msdn.microsoft.com/en-us/library/ms646296(v=VS.85).aspx>
 and WM_INPUTLANGCHANGE<http://msdn.microsoft.com/en-us/library/ms632629(v=VS.85).aspx>,
which certainly sound useful.

Andrew Cunningham has expressed doubts that Linux exposes this kind of
information in any unified way, given the various input frameworks available
there. I have no idea one way or the other.

Aharon

On Sun, Sep 12, 2010 at 6:03 PM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Aharon-
>
> Just as a data point, can you tell us a bit about the underlying OS support
> for generating this information?  Is it supported on all major desktop
> platforms (Linux, Windows, MacOS), and on major mobile platforms?  Do you
> know the specific names of the platform methods to access this info?
>
> How much of a burden on implementations would it be to retrieve this
> information for each spawned event?  Do the platforms tell the
> implementation when this is changed, so that there could be a default value
> plugged into the event, rather than queried each time it's needed?
>
> Thanks-
> -Doug
>
> Aharon (Vladimir) Lanin wrote (on 9/12/10 11:11 AM):
>
>   From what I can see, the message with the exact language of the
>> proposal
>> (http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0075.html) hasn't
>> been
>> referenced for issue 119. It's as follows:
>>
>> Proposal: An additional property in the TextEvent and KeyboardEvent
>> DOM3 interfaces to indicate the locale of the keyboard or other input
>> device using which the input was generated. When this is unknown (e.g.
>> when the input method is paste, or when the implementation can not
>> obtain this information from the underlying platform), the property
>> should be null (or perhaps undefined, whichever conforms to DOM3
>> conventions better).
>>
>> Here is a draft for the documentation of the new event attributes,
>> striving to conform in style to
>>
>> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-textevents
>>
>> In TextEvent:
>>
>> inputLocale of type DOMString, readonly
>>     A BCP-47 tag indicating the locale for which the origin of the
>> event (whether keyboard, IME, handwriting recognition software, or other
>> input mode) is configured, e.g. "en-US". May be null [undefined?]
>> when inapplicable or unknown, e.g. for pasted text or when this
>> information is not exposed by the underlying platform.
>>
>> Note: inputLocale does not necessarily indicate the locale of the
>> data or the context in which it is being entered. For example, a French
>> user often may not switch to an English keyboard when typing English, in
>> which case the inputLocale will still indicate French, even though the
>> data is actually English.
>>
>> In KeyboardEvent:
>>
>> inputLocale of type DOMString, readonly
>>     A BCP-47 tag indicating the locale for which the keyboard used
>> to generate the event is configured, e.g. en-US. May be null
>> [undefined?] when unknown, e.g. when this information is not exposed by
>> the underlying platform.
>>
>> Note: inputLocale does not necessarily indicate the locale of the
>> text that the user may be keying in. For example, a French user often
>> may not switch to an English keyboard when typing English, in which
>> case the inputLocale will still indicate French. Nor can it be used to
>> definitively calculate the "physical" or "virtual" key associated
>> with the event, or the character printed on that key.
>>
>
>