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

[moving from public-i18n-core@ to www-international@ as per i18n WG
decision]

> we weren't sure that including that information in each event was the
right approach

The only alternative way of exposing the information (of which I am aware)
is in a global object, and that has built-in problems:
- the shortcomings of limiting the global object to the keyboard are quite
serious and obvious.
- it is unclear how information about different input devices, which could
be active simultaneously, can be combined without losing precision or
utility in a single global object, as described in my previous message.

Is the cost of exposing this information in each event truly any more
prohibitive than indicating the event source, which is already part of the
spec?

> There are a couple paths forward at this point

As you expected, I would prefer to try my luck with the Last Call process
:-) Is there anything I need to do in order to choose this option? Will the
last call WD review take place on www-dom@?

Aharon

On Fri, Aug 27, 2010 at 8:56 PM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Aharon-
>
> We discussed this in a recent telcon, and while we like the idea of
> exposing the keyboard language and see the use cases, we weren't sure that
> including that information in each event was the right approach; there is
> some question also as to how accurate and useful this will be in practice,
> for the reasons you cited before.  Considering that there were also
> legitimate concerns about privacy, we think that this needs more discussion
> before including it in a spec.
>
> Logistically, we want to move forward to Last Call for the DOM3 Events spec
> right away; we have spent the last few months polishing up the existing
> features, rather than adding new features.
>
> There are a couple paths forward at this point:
>
> 1) Consider including this in another spec which may be a better fit; there
> is a proposed spec which deals with keyboard state, giving content authors
> access to a list of all the keys that are currently pressed; one use case
> for this is where the keyboard is being used for non-text uses like game
> controls;
>
> 2) Raise this as a Last Call issue on the DOM3 Events spec, and have more
> discussion and endorsement on the idea during the period of the Last Call WD
> review, over the next 6 weeks; if there is sufficient support and consensus
> on the specific mechanism, I will be happy to add it to the spec.
>
> I expect that you will favor the second option, because it means that this
> functionality will make it into a spec (and Recommendation) sooner, but I
> wanted to present both options to you.
>
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>
> Aharon (Vladimir) Lanin wrote (on 8/5/10 2:47 AM):
>
>> If the proposed (some global object).currentInputModeLocale refers to
>> the speech recognition software during a speech event and to handwriting
>> recognition software during a handwriting event and to the keyboard
>> during a keyboard event, then what does it refer to outside the scope of
>> any event, or during some event unrelated to text?
>>
>> Perhaps it should then be redefined as .lastInputLocale, indicating the
>> locale of the last text input device to have generated input. But then
>> if the last txt event was due to a paste operation, would it become
>> null? If yes, then the input locale is no longer available outside the
>> scope of events until the next time there is input. And if no, then
>> during the paste's text event its value would be misleading (it has
>> nothing to do with the pasted text). I guess it could become null during
>> the paste text event, and then go back to the last non-null value after
>> the event is over, but this is getting a little complicated. What's
>> wrong with putting the value right in the event?
>>
>> Mind you, I agree that having the input locale available outside the
>> scope of events would indeed be useful. Perhaps (some global
>> object).lastInputLocale should be made available in addition to
>> inputLocale in the events. It would get updated on every text and
>> keyboard event with a non-null inputlocale.
>>
>> Aharon
>>
>> On Wed, Aug 4, 2010 at 9:45 PM, Olli Pettay <Olli.Pettay@helsinki.fi
>> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>>
>>
>> http://lists.w3.org/Archives/Public/public-i18n-core/2010JulSep/0092.html
>>
>>    So does the inputModeLocale (or whatever to call it) really need to be
>>    in the events?
>>    Could for example navigator object have .currentInputModeLocale.
>>    With that a text processor could try to guess the default language even
>>    before user starts to type and show that to user.
>>
>>    During the events dispatched because of speech input for example,
>>    currentInputModeLocale would point to the "currentInputModeLocale",
>>    which is the locale for speech. Same with keyboards.
>>    So the main difference would be just that the default locale would be
>>    available even before any input has happened.
>>
>>
>>
>>    -Olli
>>
>>    PS. DOM 3 Events discussion happens in www-dom@w3.org
>>    <mailto:www-dom@w3.org>.
>>
>>        For some reason I can't even subscribe to
>>    public-i18n-core@w3.org <mailto:public-i18n-core@w3.org>
>>
>>