Re: proposal: add input/keyboard locale to text and keyboard events

Except that keyboardLocale doesn't work for the text event, which could be
generated by all sorts of input methods: keyboard, IME, handwriting, paste,
drop, etc.

On Tue, Jul 20, 2010 at 6:34 PM, Phillips, Addison <addison@lab126.com>wrote:

>  I could live with “keyboardLocale”.
>
>
>
> Addison Phillips
>
> Globalization Architect (Lab126)
>
> Chair (W3C I18N, IETF IRI WGs)
>
>
>
> Internationalization is not a feature.
>
> It is an architecture.
>
>
>
> *From:* Aharon (Vladimir) Lanin [mailto:aharon@google.com]
> *Sent:* Tuesday, July 20, 2010 6:22 AM
> *To:* Phillips, Addison
> *Cc:* Matitiahu Allouche; Richard Ishida; public-i18n-core@w3.org
>
> *Subject:* Re: proposal: add input/keyboard locale to text and keyboard
> events
>
>
>
> Regarding the attributes' name (or names), I believe calling them
> inputLocale would foster the precise misconception I am trying to address in
> the note. It is indeed the locale of the keyboard (or other input device)
> configuration, as controlled by the operating system - and not of the input
> text. While the keyboard (or keyboard configuration) locale is usually also
> the locale of the typed text, it does not have to be. A counterexample is
> given in the note: it is perfectly possible to type English text while using
> a French keyboard (and even a Hebrew keyboard, if all-uppercase text is good
> enough). The "input" in "inputLocale" is too easily taken to mean the input
> text.
>
> I agree that inputModeLocale (based on the inputMode attribute name already
> present in the text event) is a bit clunky. However, I can't think of a
> better name.
>
> As for using the same name for both events, it's a good idea in principle,
> but while inputModeLocale made some sense in the text event, which already
> has inputMode, I am afraid it would be completely incomprehensible in the
> keyboard events. We can consider any new name suggestions for both events.
>
> Regarding the "unknown" value, null is the normal value used in such cases
> in script APIs. I strongly object to using a special string value for it.
>
> Aharon
>
> On Mon, Jul 19, 2010 at 7:16 PM, Phillips, Addison <addison@lab126.com>
> wrote:
>
> I agree that the attributes should have the same name.
>
>
>
> I would tend to call it “inputLocale”. It is not the keyboard’s locale (the
> keyboard is a bit of hardware and the keys on it can be remapped).
>
>
>
> I don’t agree with returning a string for the unknown case. I would return
> null, since checking nullity is easy and it conveys the state quite well:
> there is no value assigned. It is also consistent with other key event
> values (which can be null).
>
>
>
> Addison Phillips
>
> Globalization Architect (Lab126)
>
> Chair (W3C I18N, IETF IRI WGs)
>
>
>
> Internationalization is not a feature.
>
> It is an architecture.
>
>
>
> *From:* public-i18n-core-request@w3.org [mailto:
> public-i18n-core-request@w3.org] *On Behalf Of *Matitiahu Allouche
> *Sent:* Sunday, July 18, 2010 4:48 AM
> *To:* Aharon (Vladimir) Lanin
> *Cc:* Richard Ishida; public-i18n-core@w3.org;
> public-i18n-core-request@w3.org
> *Subject:* Re: proposal: add input/keyboard locale to text and keyboard
> events
>
>
>
> Aharon Lanin proposed to add the following event properties:
> <quote>
> In TextEvent:
>
> inputModeLocale of type DOMString, readonly
>     A code indicating the locale of the input mode (e.g. keyboard, IME,
> handrwriting, etc.) that was used to generate the event, e.g. en-US. May be
> null when unknown or inapplicable, e.g. for dropped or pasted text.
>
>     Note: inputModeLocale does not necessarily indicate the locale of the
> data or the context in which it is being entered. For example, a French user
> may not switch to an English keyboard when typing English, in which case the
> inputModeLocale will still indicate French.
>
> In KeyboardEvent:
>
> keyboardLocale of type DOMString, readonly
>     A code indicating the locale of the keyboard configuration that was
> used to generate the event, e.g. en-US.
>
>     Note: keyboardLocale 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
> keyboardLocale 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.
> </quote>
>
> 1) Since it seems that the same type of information will be reported for
> both events, is there a good reason to have different names for the
> properties?  Since inputModeLocale is more general than keyboardLocale, it
> can be used for both.
>
> 2) For more homogeneity, I suggest that unknown or inapplicable situations
> return an empty string, or even a string which characterizes the type of
> situation, like "!!-unknown" or "!!-notext".
>
>
> Shalom (Regards),  Mati
>           Bidi Architect
>           Globalization Center Of Competency - Bidirectional Scripts
>           IBM Israel
>
>
>