Intent to Implement: Form controls respecting |lang| attribute value

[TAMURA, Kent]

Contact emails
tk...@chromium.org

Spec
https://html.spec.whatwg.org/multipage/dom.html#the-lang-and-xml:lang-attributes
"User agents may use the element's language to determine proper processing or rendering (e.g. in the selection of appropriate fonts or pronunciations, for dictionary selection, or for the user interfaces of form controls such as date pickers)."

Summary
Form control UI should respect |lang| attribute values, instead of the browser UI locale.
e.g.
<div><input type="submit" lang="en-US"><input type="submit" lang="ja-JP"></div>
should show two buttons in different languages on a single page, like [Submit] [送信]

This feature will be applied to submit, reset, number, date, datetime-local, month, time, week input types, and so on.

Motivation
http://crbug.com/141169
https://bugs.webkit.org/show_bug.cgi?id=11008

Web authors want to show a page content in consistent locale. They can't control UI locale of some form control types at all now.

Compatibility Risk
Medium.
No browsers have such behavior AFAIK.  Desktop Firefox does this only for <input type=number>.
This feature won't affect web application compatibility.  However it will affect users.

* Concerns
If a user uses a web application in unfamiliar language, he/she sees form controls in his/her familiar language now, but he/she will see form controls in the unfamiliar language with this feature.

Supporting this feature in <input type=number> would be confusing. It's hard for users to know what's the expected decimal separator for <input type="number lang="fr" step="0.01"> or <input type="number" lang="en" step="0.01">

We're not sure if this feature should affect calendar picker popup for date/time input types.  If we assume the calendar picker is similar to <select> popup or alert(), the calendar picker should respect lang attribute values.  If calendar picker is a part of the browser UI, we should show calendar picker in the browser UI locale for consistent browser UI.

Ongoing technical constraints
We need to support to load multiple sets of translated strings at the same time. This would add some code complexity to Chromium.  Blink changes would not be so large.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.

OWP launch tracking bug?
Not filed yet.

Link to entry on the feature dashboard
Not created yet.

Requesting approval to ship?
No.
This feature should be implemented behind a runtime flag.


I'm not 100% sure that we should do this or not because of the concerns section.  Any comments are welcome.


--
TAMURA Kent
Software Engineer, Google

[Takayoshi Kochi]

What specifically can't be done with CSS :lang() selector?

Sounds like changing the label for submit button can be done with it.

--
Takayoshi Kochi

[TAMURA, Kent]

With :lang(), we need to embed all of translated strings in the UA stylesheet. It has some drawbacks.

The following stuff would be lang-aware:

 - Default button labels

 - Number format

 - Date/time format

 - Calendar picker content

The first one might be represented by CSS, however others can't.

[Anne van Kesteren]

On Tue, Sep 30, 2014 at 4:16 AM, TAMURA, Kent <tk...@chromium.org> wrote:
> I'm not 100% sure that we should do this or not because of the concerns
> section. Any comments are welcome.

It seems very exciting to me. This is one of the reasons authors avoid
native controls. It might make sense to support a special lang=""
value to get the old behavior back, though I'm not sure what that
value should be.


--
https://annevankesteren.nl/

[Mounir Lamouri]

I guess they could set lang to navigator.languages[0] if they want the
control to have the user's preferred language.

-- Mounir

[Anne van Kesteren]

On Tue, Sep 30, 2014 at 1:24 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> I guess they could set lang to navigator.languages[0] if they want the
> control to have the user's preferred language.

Ah yeah, there's at least an imperative solution.


--
https://annevankesteren.nl/

[Simon Pieters]

On Tue, 30 Sep 2014 13:15:44 +0200, Anne van Kesteren <ann...@annevk.nl>
wrote:

The empty string?

--
Simon Pieters
Opera Software

[Simon Pieters]

On Tue, 30 Sep 2014 04:16:00 +0200, TAMURA, Kent <tk...@chromium.org>
wrote:

> * Concerns
> If a user uses a web application in unfamiliar language, he/she sees form
> controls in his/her familiar language now, but he/she will see form
> controls in the unfamiliar language with this feature.

I think it's not uncommon that pages have the wrong language tag (e.g.
lang="en" is common for non-English). But I don't know how common it is
for such pages to use the affected form controls. Has this been considered?

[Simon Pieters]

Very uncertain data but might serve as existence proof anyway:

https://github.com/search?l=html&q="lang+en"+input+"type+submit"+%28búsqueda+OR+nombre+OR+contraseña%29+NOT+value&ref=searchresults&type=Code&utf8=✓

vs

https://github.com/search?l=html&q="lang+en"+input+"type+submit"+%28búsqueda+OR+nombre+OR+contraseña%29&ref=searchresults&type=Code&utf8=✓

Out of ~ half a million Spanish pages with a submit button that declare
lang="en", ~2% do not have a value attribute anywhere.

[Mounir Lamouri]

I would expect the empty string to be ignored and a parent lang
attribute to be used, if any.

-- Mounir

[Anne van Kesteren]

On Wed, Oct 1, 2014 at 10:50 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> I would expect the empty string to be ignored and a parent lang
> attribute to be used, if any.

That would be an incorrect implementation of the lang attribute.


--
https://annevankesteren.nl/

[Mounir Lamouri]

On Wed, 1 Oct 2014, at 18:52, Anne van Kesteren wrote:
> On Wed, Oct 1, 2014 at 10:50 AM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
> > I would expect the empty string to be ignored and a parent lang
> > attribute to be used, if any.
>
> That would be an incorrect implementation of the lang attribute.

You're right. It would be nice if the platform had a consistent
behaviour with regards to empty string in attributes that expect to
contain a string.

-- Mounir

[TAMURA, Kent]

Thank you for the data.

It's a good point. There are a lot of pages with wrong lang attribute value.

First , I should add a UseCounter to get how many page views will be affected by this feature, and investigate a ratio of wrong lang attribute values if possible.

[add...@amazon.com]

The W3C Internationalization working group has taken an interest in this thread and discussed it in our last two teleconferences (including today at http://www.w3.org/2014/10/09-i18n-minutes.html#item06). (This reply is with my chair hat on)

In general, we think this is a great thing. However, there are a number of issues (some mentioned by others below or in your concerns section) that we think need to be worked through. To that end we're establishing a wiki page to document recommendations from the I18N community and I've been tasked (I18N-ACTION-351 http://www.w3.org/International/track/actions/351) with alerting you to our interest/activity.

[Jungshik Shin (신정식, 申政湜)]

I'm  glad to hear that we intend to implement this.  Needless to say, there are some details to iron out. 

BTW,  I filed this FR before ( http://crbug.com/232955 ) that I've just duped to the new crbug mentioned in this thread ( http://crbug.com/141169). Now that Blink, Firefox and new IE all have implemented EcmaScript I18N API, the implementation may utilize that (if they wish to).

Jungshik 

[TAMURA, Kent]

ok, I have data.

 - view% of pages with |lang| attributes

 - view% of pages with |lang| attributes of which values are not equal to the browser UI language

 - view% of <input type=submit> without |value| attribute

   I think <input type=submit> is the most popular affected form control.

 - view% of pages of which content and |lang| attribute doesn't match.

  Collected by the translation feature of Google Chrome.  Typical error is lang=en generated by CMS.

Result:

* The feature will affect <input type=submit> in 0.064% page views.

* The feature will show <input type=submit> in wrong language (typically English) in 0.026% page views.

My impression is that the feature won't have much impact anyway.

[Simon Pieters]

On Wed, 25 Feb 2015 10:03:58 +0100, TAMURA, Kent <tk...@chromium.org>
wrote:

> ok, I have data.
> - view% of pages with |lang| attributes
> - view% of pages with |lang| attributes of which values are not equal
> to
> the browser UI language
> - view% of <input type=submit> without |value| attribute
> I think <input type=submit> is the most popular affected form
> control.
> - view% of pages of which content and |lang| attribute doesn't match.
> Collected by the translation feature of Google Chrome. Typical error
> is
> lang=en generated by CMS.
>
> Result:
> * The feature will affect <input type=submit> in 0.064% page views.
> * The feature will show <input type=submit> in wrong language (typically
> English) in 0.026% page views.

Great, thanks.

0.026% page views with wrong-language buttons maybe we can get away with.
Doing this might improve lang usage on the Web over time.

OTOH, of the page views affected, 40% will be broken. For non-English
users, I guess it is higher.

> My impression is that the feature won't have much impact anyway.
>