Re: Locale-based forms in HTML pages

A couple of thoughts:

* BCP47 leans towards the shortest meaningful language tag, while locale
support tends to require longer language tags including more subtags. A
minimum would be language and region/country subtags. But for a range of
languages, just the language subtag is sufficient for language mark up but
to properly specify locale you may need language, country, script and
variant subtags to correctly distinguish locale requirements.

* For generated content, there needs to be some way to specify the locale
of the content being ingested. It may not match the language of the page or
locale of the page.

* The reality is that only a limited number of locales will be supported by
a vendor, so:
    a) there needs to be an API allowing web developers to successfully use
an unimplemented language; and
    b) a way for developers to specify locale fallback if the necessary
locale is not supported. I can think of some languages where locale
fallback may differ based on audience, i.e. Dinka fallback if Dinka locale
is not available, may be to Arabic, Swahili or English depending on the
audience.


A.

On 16 October 2014 09:06, Richard Ishida <ishida@w3.org> wrote:

> I just added some exploratory tests for number formats at
>
> http://www.w3.org/International/tests/test-incubator/locales-in-forms/
> numbers.html
>
> 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
> and
>         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!
>
> ri
>
>
>
>
> 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:
>> https://www.w3.org/International/wiki/Locale-based_forms
>>
>
>
>


-- 
Andrew Cunningham
Senior Project Manager, Research and Development
Vicnet
State Library of Victoria
Australia

andrewc@vicnet.net.au
lang.support@gmail.com