[whatwg] Decimal comma in numeric input

[John Tamplin]

On Thu, Apr 14, 2011 at 12:40 PM, Jukka K. Korpela <jkorpela at cs.tut.fi>wrote:

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

Ok, if you want to say that some apps don't have a server component or that
some apps translate to a global format when sending to the server, that is
fine.  However, it doesn't change the fact that the part running on the
client has to know what locale the user is using when interacting with it,
and needs to be able to control that rather than using whatever the user's
OS is set to.

For example, imagine a translation application that will show messages in a
source locale and allow the user to edit translations in a different locale.
 Clearly, the OS is only going to be running in one locale, so if the
application relies on the browser which relies on the OS for the locale then
it cannot possibly localize the parts of the app appropriate for each of
these locales.


> 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 they don't cover the case of what should happen, then either the
implementors implement it the same correct way by chance or the feature
can't actually be used by apps that care about localizaiton.

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


Some examples:

   - amazon.com is US English (at least from a US IP address, I don't know
   if they remap it based on other things, but they definitely don't use
   Accept-Language to choose).  At the bottom of the page is a list of links to
   other localized versions of the site, like amazon.fr, amazon.it, etc.  I
   don't see any persistent settings for your account.
   - cnn.com is similar, ignores Accept-Language and lists links to a few
   localized sites at the bottom of the page
   - bbc.co.uk is similar, ignoring Accept-Language and providing a large
   list of locales to choose from in the body of the page
   - google.com defaults to Accept-Language or IP-based geolocation if you
   don't have a preference, provides a link to the English version for
   non-English sites, and allows setting a persistent preference if you are
   logged in.  Note that the list of supported languages includes many not
   likely to be supported by the OS.
   - yahoo.com has only an "international" link which then takes you to a
   large list of localized versions of the site to choose from

So if the OS/browser support is sufficient, why do most sites roll their
own?


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


Setting it in the system allows you to choose from the locales that the OS
or browser supports.  That set of locales can be very different from the set
of locales supported by a given application.  If a user's OS is set for
Estonian and my app doesn't support that, how do I know which of the locales
I do support would be the best option for the user?  What if the OS doesn't
support a locale that my application does support, do I just not allow the
user to select it?  What about the common case where the OS/browser idea of
localization is insufficient, such as most not supporting BCP47 language
tags, so I can't say I want to read in Cyrillic (sr-Cyrl) or Latin
(sr-Latn)?  Maybe one day the support will be there that allows this, but
right now if you care about it you have to localize it yourself.


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


Ideally, the browser would provide sufficient localization support that apps
could use it   Until then, for any features like <input type="number"> to be
usable, there has to be a way to tell the input element what locale the app
is actually running in.  Previously in this thread, you suggested that there
should not be such a mechanism and that instead should be based on the
user's OS settings.  All of the examples above would lead to incorrect
behavior any time the user was running one of those apps in a different
locale than the OS setting, which means that those apps can't rely on
browser behavior and have to supply their own number parsing/formatting.


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

Users in affected locales might disagree with you, but I agree that
poorly-localized UIs should be avoided.  The question is how to make it
easier to write properly localized apps, and I suggest half-baked browser
facilities are not the answer.


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

The percentage of plain HTML pages is dropping dramatically, but even then
when the form is posted to a server, the server has to know how that data
was processed.


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


Ok, so you are suggesting that browsers should never provide localization
facilities and apps should continue to roll their own?  I suppose that is a
viable position, but it means that each app reinvents the wheel each time
and requires additional code to be downloaded and executed.

To me, the ideal solution is that the browser provides a localization API
similar to what ICU provides, and the apps running in the browser make use
of that rather than recreating it.

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