[whatwg] Decimal comma in numeric input
Jukka K. Korpela
jkorpela at cs.tut.fi
Thu Apr 14 09:40:19 PDT 2011
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
> 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
>> 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
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.
More information about the whatwg