[whatwg] Decimal comma in numeric input

[Jukka K. Korpela]

John Tamplin wrote:

> The entire web application, which includes both client and
> server-side code, must have the same idea about what locale the user
> is using.

Well, HTML(5) is not just about client-server applications. It’s also about 
offline applications and about the bulk of web and intranet content that 
cannot be characterized as “applications” in any significant meaning.

Moreover, part of the very idea of client-server model is that the client 
can handle user interaction in the user’s preferred locale and generally the 
way that suits the user, whereas the server-side processing and storage can 
use globalized format of data. The server can remain totally ignorant of the 
user interaction; it just gets and send data in a global well-defined 
format, which may be almost or completely unreadable to humans, or at least 
odd-looking to most, like ISO 8601 date and time, language codes, or real 
numbers in binary format.

New input types like "color", "date", and "number" are interesting steps 
towards allowing localized user interfaces with strictly defined and 
controlled interfaces to server-side and client-side processing of data. But 
they are perhaps not quite _conscious_ steps, and they are relatively 
limited, and they are (probably intentionally) silent about most 
localization issues.

> If the app provides a drop-down box or preference setting
> to choose a different locale, as most localized apps do,

Do they? Is that a good move, as opposite to using one centralized set of 
settings in the user's system? How many times am I actually supposed to tell 
my preferred language, country, currency, decimal separator, and so on, when 
using different applications? Localization is far more than choosing a 
locale from a dropdown, or at least it should be to be genuinely useful.

> the web browser has to be using the same locale for any native locale
> processing it uses

I’m not sure I follow you here. If an application is used via a web browser, 
then according to your words the application normally provides its own 
locale selection. Are you now saying that a web browser should somehow try 
to access such choices and turn them into its own choices. I was confused, 
and I am getting more and more confused.

> 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?

That was the issue I raised, and I don’t see how it would vanish according 
to the approach to selecting a locale.

> 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.

Independently of the ways in which some software decides to use some locale 
settings, there is the problem that the user does not what to enter when he 
needs to enter a number with a decimal part. I think non-localized UIs 
(e.g., UIs that always use full stop as decimal separator) are definitely 
better than poorly-localized UIs.

>> 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.

They can hardly expect browsers to get it right now or in the near future, 
as there isn’t even any definition for what is right. And there is 
considerable conceptual confusion too – you seem to imply that the language 
of the input element is the same as the locale some application is running 
in.

Most forms in HTML documents aren’t part of any “application” with some 
localization features. It’s just a form, and the page has some language 
(though usually detectable only by analyzing the content), and it’s used in 
a browser that has some user interface language (language of menus, error 
messages etc.) and little localization outside that. The best approximation 
of what is generally most natural for the user is in the settings of the 
underlying system. But users can’t and won’t really expect web pages to 
apply those settings (usually just silently accepted by the user) to, say, 
their methods of input for decimal numbers.

What I’m saying is, I guess, that HTML specifications should _discourage_ 
browsers from setting up localized methods for numeric input. It's different 
with calendars for example. When using an English-language page, I’m quite 
prepared to seeing a calendar with English month names, but I would not be 
too surprised at seeing Finnish month names (when using a Finnish version of 
an OS _and_ a browser), even though it may look somewhat messy. And a 
calendar _needs_ to have language-specific information, with month names and 
names for days of the week at least.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/