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

Greetings Aharon,

This is just for your information.

If I recall correctly, TISGetInputSourceProperty() returns the
language name (such as "us", "he", etc.) on Mac OS 10.5 or later.

  TISInputSourceRef source = TISCopyCurrentKeyboardInputSource();
  CFArrayRef languages = (CFArrayRef)TISGetInputSourceProperty(source,
kTISPropertyInputSourceLanguages);
  CFStringRef name = (CFStringRef)CFArrayGetValueAtIndex(0, languages);

(*1) http://developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html

On Windows, GetKeyboardLayout() (*1) returns the ID of the keyboard
layout (such as 0x0409 "US", 0x040d "HE", etc.) of the current thread
as listed in the following snippet. We need to convert this ID to
BCP-47 name, though.

  HKL layout = GetKeyboardLayout(GetCurrentThreadId());

(*2) http://msdn.microsoft.com/en-us/library/ms646296(VS.85).aspx

As noted by Andrew, Linux does not have standard keyboard APIs. (Can
we assume X and XKB?)

I wish this information helps you.

Regards,

Hironori Bono
E-mail: hbono@google.com

On Mon, Sep 13, 2010 at 11:10 PM, Aharon (Vladimir) Lanin
<aharon@google.com> wrote:
> The short answer is that I do not really know.
> However, a few minutes Googling it for Windows got me
> to GetKeyboardLayout and WM_INPUTLANGCHANGE, 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.
>>
>
>

Received on Tuesday, 14 September 2010 05:12:47 UTC