Contact emailstk...@chromium.orgSpechttps://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)."
SummaryForm 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.
Motivationhttp://crbug.com/141169https://bugs.webkit.org/show_bug.cgi?id=11008Web 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 RiskMedium.
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 constraintsWe 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 dashboardNot 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