W3C home > Mailing lists > Public > public-i18n-core@w3.org > July to September 2010

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

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Tue, 20 Jul 2010 16:21:55 +0300
Message-ID: <AANLkTilvWKzrnoiIUpQ0_RPYcnbn8_FoOG0smed-l45S@mail.gmail.com>
To: "Phillips, Addison" <addison@lab126.com>
Cc: Matitiahu Allouche <matial@il.ibm.com>, Richard Ishida <ishida@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
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
>
Received on Tuesday, 20 July 2010 13:22:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 July 2010 13:22:50 GMT