[whatwg] Localisation of form fields

[Ian Hickson]

On Thu, 12 Jan 2012, Schalk Neethling wrote:
> 
> Is there a way to specify the locale input type=daye should use or does 
> it simply use the current locale? If so, does it choose the server 
> locale or the user locale?

It should use the user's locale for input (as determined by the user 
agent), and should always be transmitted over the wire using the fixed 
format described in the spec.

If we add author-level control for this kind of thing, it should be in 
CSS, since it is presentational.


On Thu, 12 Jan 2012, Schalk Neethling wrote:
> 
> There will need to be a js, or server side function if js is not 
> available, function that converts whatever you get to the format you 
> require/expact. I was just curious what the default behavior would be 
> for the input element and, whether there would be a way to indicate 
> which format you wish returned.

The format you get will always be the same (the format described in the 
spec). That's independent of what the user sees.


On Thu, 12 Jan 2012, Schalk Neethling wrote:
>
> Ok, so reading some of the discussion, maybe being more precise with our 
> html lang= would help or, is this not inherited down the chain so, when 
> declaring input type=date, one needs to specify lang=en-US?
> 
> Will that have the desired effect as described earlier in the thread?

On Thu, 12 Jan 2012, Cameron Heavon-Jones wrote:
> 
> No, the current state is that the user's preferred locale will always be 
> used for localization.
> 
> If the language resolution algorithm was being used you would be able to 
> define it through the lang attribute or through http headers.
> 
> If you want to have specific localization you will have to roll your 
> own, you could still define the language on the attribute but you would 
> need to perform the formatting yourself using javascript.

This is currently correct. We may one day add a locale="" attribute or 
some such.


On Fri, 20 Jan 2012, Markus Ernst wrote:
> 
> Use case for using User's preferred locale:
>
> - The user is viewing a website in a foreign language, using his/her own 
> computer.
> 
> Use case for using the element's language:
>
> - The user is viewing a website in his/her own language, but using a 
> computer in an internet café in a foreign country (where (s)he might not 
> even be able to change the language settings of the browser).
> 
> This makes me think, if UAs could be encouraged to invent some kind of 
> UI for per-session overriding the localisation settings of both UA and 
> website content.

That's not necessarily a bad idea, but I don't know what we can do to 
encourage it.


On Fri, 27 Jan 2012, Bronislav KluÄ~Mka wrote:
>
> we are currently discussing localization in form fields, but that may 
> result in some unfortunate behavior if implemented alone, because data 
> will be displayed in localized representation in form fields but not in 
> HTML - server can translate text, but not localize data, since it has no 
> idea about local settings (language is not enough) and when data are 
> inserted into HTML on UA side using scripting, the problem is the same.
> 
> Suggestion
> 1/ output element
> output element should follow similar logic for presentation as form fields
> there is an example of output usage
> http://dev.w3.org/html5/spec/the-output-element.html#the-output-element
> <form onsubmit="return false" oninput="o.value = a.valueAsNumber +
> b.valueAsNumber">
> <input name=a type=number step=any> +
> <input name=b type=number step=any> =
> <output name=o></output>
> </form>
> but imagine full stop as thousands separator, comma as decimal , inserting
> 12.135,5 + 4.125,6 would result in 16261.1 (Number is fine, presentation
> confusing)
> so output element should follow presentation form of the forms as well

I agree. I think, though, that that's really something for the CSS layer 
first. We can define all manner of data types and how they should be 
localised, but without rendering-level support, it's not especially useful.


> 2/ FormatSettings object
> [Constructor(),
>  Constructor(DOMString locale),
>  Constructor(FormatSettings locale),
> ]
> interface FormatSettings {
>    attribute DOMString CurrencyString;
>    attribute Number CurrencyFormat;
>    attribute Number CurrencyDecimals;
>    attribute DOMString ThousandSeparator;
>    attribute DOMString DecimalSeparator;
>    attribute DOMString DateSeparator;
>    attribute DOMString TimeSeparator;
>    attribute DOMString ShortDateFormat;
>    attribute DOMString LongDateFormat;
>    attribute DOMString TimeAMString;
>    attribute DOMString TimePMString;
>    attribute DOMString ShortTimeFormat;
>    attribute DOMString LongTimeFormat;
>    attribute Array ShortMonthNames;
>    attribute Array LongMonthNames;
>    attribute Array ShortDayNames;
>    attribute Array LongDayNames;
>    attribute bool DaylightSavingTime;
>    attribute Number TimeZoneOffset;
> 
>    DOMString format (String input, Array data)
> 
>    Number CurrencyAsNumber (DOMString value)
>    Number StringAsNumber (DOMString value)
>    Date StringAsDate (DOMString value)
> 
>   [and probably set of constants representing different types of error
> regarding formatting and data sanitation]
> }

What does the JS library space look like on this front? Is this something 
that's done at all?

I agree that it makes sense to let Web pages style text to fit the user's 
locale, but I don't think we should do it at the JS level if we can help 
it. In particular, having the JS level have to explicitly use the 
TimeSeparator for example seems like asking the authors to do too much 
minutiae that could be taken care of at a higher level (CSS).


On Fri, 27 Jan 2012, TAMURA, Kent wrote:
>
> Form control presentations and ECMA Globalization API should be 
> synchronized. We might need HTMLInputElement::numberFormat to set/get a 
> Globalization.NumberFormat object.
> 
> http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts

Looks like that proposal has the issue well in hand...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'