- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Tue, 29 Jan 2019 07:31:55 +0000
- To: Wayne Kinsella <mpkmy2c@gmail.com>, "www-international@w3.org" <www-international@w3.org>
Hello Wayne, On 2019/01/29 06:07, Wayne Kinsella wrote: > Hello, > The native input types in browsers still all seem to use the OS locale. > Looked like Chromium talked about fixing this ( > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/QpEoCwU0Ttg) > some years back, and the w3c agreed - > https://www.w3.org/International/wiki/Locale-based_forms. > > This does not appear to have been implemented. > > That being the case, what is the current advice for forms? > - just use the native controls and accept their limitations? > or > - create your own controls/widgets to replicate the native behavior, but in > a way that gives you (the developer) control over the locale? > Thanks, > w I think it depends a lot on the circumstances. First, the difference only turns up for multilingual/multilocale people. How many there are, and therefore to what extent it makes sense to support them, may depend a lot on your target audience. The end of the Google Groups thread shows some general numbers, and I think these numbers were the reason this proposal was abandoned on the browser side. Also, for many types of data (e.g. dates), what's most important is that it's ambiguous. If I see "Jan 2019, 29th", then I'm sure what date is that this refers to, even though the field order (Month Year Day) is one that's not used anywhere around the world as far as I'm aware of. In addition, some people have preferences for (for them) uniform representations even in different language contexts, whereas others prefer to see the formatting that matches the surrounding language and locale. Regards, Martin.
Received on Tuesday, 29 January 2019 07:32:21 UTC