[whatwg] Localisation of form fields

On 4.5.2012 23:17, Ian Hickson wrote:
> 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).
>
I can see you are pushing for CSS because of presentation level, but
1/ you need to display currency or number, what would you do?
<span style="format-type: number; format-decimal-separator: 
',';">123.22</span>
something like that? I can see that, but would be better something like
<data role=number value=123.22 style="format-type: number; 
format-decimal-separator: ',';" />
<data role=currency value=2.22 char=$ style="format-type: number; 
format-decimal-separator: ','; format-currency-format: 2" />
this could enhance machine processing capabilities.
Nothing to do with JS API, you just brought me back to this already 
discussed element.
We are discussing making data information universal (one data, several 
localization).

2/ I would only assume that libraries for large, international projects 
do contain such functionality, but there's no way to get the settings 
from underlying OS.

3/ I would prefer moving with JS first, you can create display by 
applying FormatSettings.format function (to get CSS functionality) but 
it can give you additional functionality as well (FormatSettings 
functions). Or essentially create both CSS and JS together as 
complementary functionality.


Brona

Received on Monday, 7 May 2012 01:32:08 UTC