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

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<mailto: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> [mailto: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<mailto:public-i18n-core@w3.org>; public-i18n-core-request@w3.org<mailto: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