Re: proposal: add input/keyboard locale to text and keyboard events [ISSUE-119]

Hi, Aharon, Addison-

Thanks for the input.  I've added this as a Last Call comment in our 
issue tracker as ISSUE-119 [1].  We will continue this discussion during 
LC on the www-dom list and in our telcons, and will report back our 
conclusions soon.

I'd be very interested in feedback from the other browser vendors on 
this matter.  It doesn't seem very onerous to me to add it, and I've 
heard multiple reports that it could be useful.

[1] http://www.w3.org/2008/webapps/track/issues/119

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Phillips, Addison wrote (on 9/4/10 2:46 PM):
> Dear DOM WG,
>
> I am writing on behalf of the Internationalization WG. During our
> weekly teleconference this week I was actioned [1] with asking you to
> consider including this proposal in your upcoming last call document,
> perhaps noting it as an "at risk" feature. Our concern is that, if
> you were to accept it as a Last Call comment, you would then need to
> undergo a revision and further last call. It would be easier to
> remove an at risk feature.
>
> We feel sufficiently strong about the use cases for this (again
> noting the very real limitations on the information provided by the
> "input locale") to think your WG should seriously consider adding it.
> A separate document suggesting this would be untimely and probably
> face low adoption, so that solution seems unappealing.
>
> Although we did not discuss it in this week's meeting and thus did
> not include this in my action item, I think it useful to convey that
> a number of our WG members previously expressed that the privacy
> issue raised, when considered in the larger context of DOM events, is
> perhaps not very realistic. Input locale/keyboard would come in an
> event that exposes information such as the IP address of the user,
> their language preferences, cookies, and other identifying
> information units that are probably better sources of fingerprinting
> and profiling. Further, unlike many of these items, the "keyboard"
> used can often be altered by the user (this message was typed with a
> "Japanese input locale").
>
> I any case, please reconsider whether to include this item in your
> last call document. Failing that, we will consider sending it to you
> as a last call comment. I18N WG members may also be interested in
> discussing this with your WG, either via email or via teleconference
> should there be further interest in this discussion.
>
> Thanks,
>
> Addison (for Internationalization WG)
>
> [1] http://www.w3.org/2010/09/01-core-minutes.html#action01
>
> Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N,
> IETF IRI WGs)
>
> Internationalization is not a feature. It is an architecture.
>
>> -----Original Message----- From: public-i18n-core-request@w3.org
>> [mailto:public-i18n-core- request@w3.org] On Behalf Of Doug
>> Schepers Sent: Friday, August 27, 2010 10:56 AM To: Aharon
>> (Vladimir) Lanin Cc: Olli@pettay.fi; DOM public list;
>> public-i18n-core@w3.org Subject: Re: proposal: add input/keyboard
>> locale to text and keyboard events
>>
>> 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>
>>

Received on Friday, 10 September 2010 08:55:14 UTC