[whatwg] Decimal comma in numeric input

[John Tamplin]

On Thu, Apr 14, 2011 at 7:23 AM, Jukka K. Korpela <jkorpela at cs.tut.fi>wrote:
>
> I think the main problem is triggering the decimal separator mode (or
>> the order of numeric day and month for that matter) on the UI locale
>> rather than the locale of the page,
>>
>
> Well that's certainly at least _one_ of the problems. And we might ask
> whether a browser should use the _system_ settings, as they should probably
> be expected to best reflect the user's real preferences.


The entire web application, which includes both client and server-side code,
must have the same idea about what locale the user is using.  If the app
provides a drop-down box or preference setting to choose a different locale,
as most localized apps do, the web browser has to be using the same locale
for any native locale processing it uses.  Otherwise, you run a serious risk
of having incorrect data -- if a user types "10,000" in a field when they
think they are using a locale with a comma as the decimal separator, does
the app receive that as 10000 or 10.000?  If the app is running in en-US
because the user requested it or their system locale isn't supported by the
app, and the browser sends "10.000" as the value because the system locale
is "de", then that is a problem.


>  Thus, it would be safer to compute the language of the input element,
>>
>
> In practical terms, no. We know that authors generally fail to specify the
> content language or have it mis-specified (typically, as English
> irrespective of the real language) by authoring software.


If you can't rely on getting the locale the app is running in, then apps are
not going to be able to use any fancy features and will continue to
implement their own localization since they can't rely on the browser
getting it right.

-- 
John A. Tamplin
Software Engineer (GWT), Google