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

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