Re: Locale-based forms in HTML pages

I just added some exploratory tests for number formats at 

I believe that only Firefox supports the behaviour at the moment.

Things to note:

- hint: fr and de and ar produce a result

- if you use ar or ar-OM, you get arabic-indic digits, however if you 
use ar-MA you get European digits (which is good)

- if you use de or de-DE you get a comma for a decimal separator, 
however if you use de-CH you get a period (which i think is also good), 
however you don't seem to get any thousands separators - which perhaps 
helps with the Swiss situation where currency format is different from 
general numbers in that respect

- if you use fr or de you can type in 1'234,56 or 1 234,56 or 1234,56 
and the browser stores 1234.56

- if you use fr and type in 1003,5 it stores 1003.5 (all fine so far). 
If you type in
 1003.5 it stores 1003.5
This is a slight surprise, but you can see the logic that was followed, 
especially when
 100.35 gives 100.35
 10.035 gives 10035
However, a security issue lurks here. In Oman prices are quoted to 3 
decimal places, eg. 1.003 rials.  Set the lang attribute to ar-OM and 
type in ١٫٠٠٣ and you get 1.003 (which is fine), but type in ١.٠٠٣ like 
we just did for fr, and you get 1003, which is not at all the same thing!


On 15/10/2014 18:27, Richard Ishida wrote:
> Recently, a Blink intent to implement was published. It proposes that in
> HTML the form control UI should respect lang attribute values, instead
> of the browser UI locale. This feature will be applied to submit, reset,
> number, date, datetime-local, month, time, week input types, and so on.
>   It would involve both:
> a. production of translated text for controls, such as 'Submit' on buttons
> b. automatic presentation of data formats, such as date, time, numbers,
> etc, per locale information relevant to the content of the page.
> The i18n WG is using a wiki page to capture and consolidate thinking on
> any issues associated with this. On the face of it seems like a good
> idea, however, there is a concern that there may be some security and
> usability issues. We would like to explore this and capture anything
> that needs to be addressed.
> An initial draft of the page can be found at:

Received on Wednesday, 15 October 2014 22:07:11 UTC