l10n of <input type=number>, and a useful pref for localizers

[Jonathan Watt]

Hi,

The implementation of HTML5's <input type=number> (a number spinner form
control) is scheduled for release in v29. There is l10n support built in now
(except in Firefox Mobile and Firefox OS, which don't yet have ICU built in) is
it would be great if you guys could test it out and report any bugs, CC'ing me
please:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Core%20%26%20HTML

The locale sources for the input are, in order of priority:

1) a 'lang'/'xml:lang' attribute on the input element or nearest ancestor

2) the page's HTTP Content-Language, either via a <meta> tag or the HTTP
headers

3) the locale of the application

Localization happens in two directions:

A) parsing a localized number string that the user types in

B) formatting the internal number to the user's locale for display to
the user when the number is set/changes in some other way

In both cases we check the first locale source and try to do the localization
using that locale. If that fails we try the next locale source. And so on.

I should also say a few things about the grouping separator(s) (the "thousands
separator" in most locales).

The parser will accept numbers both with or without the grouping separator, but
the grouping separator must be in the correct location or else there will be a
parse error. So, for example, if the user types in "123.456,78" and we're using
the locale "de" then the parser will succeed and return the value 123456.78. If
on the other hand they type "12.3456,78" there will be a parse error because the
"." is in a bad position.

The formatter will by default insert grouping separator characters using the
locale's grouping separator(s) when formatting numbers. If most users using that
locale would prefer not to see/use grouping separators then localizers have a
pref available to them to stop the formatter from inserting grouping separator
characters. If the boolean pref dom.forms.number.grouping is set to true the
formatter will insert grouping separator characters. If the pref is set to false
it will not.

Regards,
Jonathan

[Axel Hecht]

I'd rather not have localizers play with the pref. We should first
figure out if this is an actual problem.

Downsides of using the pref directly:

Easy to get wrong, and not really patrolled by technical review.
Also, doesn't work at all in multi-locale builds.

If we really need to make this locale-dependent, we should do so
explicitly, by making it a localized pref that falls back sanely for
mistranslations.

Axel

[Jonathan Watt]

On 12/02/2014 13:01, Axel Hecht wrote:
> I'd rather not have localizers play with the pref. We should first
> figure out if this is an actual problem.
>
> Downsides of using the pref directly:
>
> Easy to get wrong, and not really patrolled by technical review.
> Also, doesn't work at all in multi-locale builds.
>
> If we really need to make this locale-dependent, we should do so
> explicitly, by making it a localized pref that falls back sanely for
> mistranslations.

I'm not sure how that would be different, but I'm happy to assume that's the
correct course of action. I did get feedback from some of my early users that
the grouping separator would be undesirable for their locale (I think it was
Hebrew). Anyway, hopefully the feedback from localizers here will allow us to
make a decision one way or the other fairly soon.

Jonathan

[Axel Hecht]

Thinking about it, given that page-locale comes first, should this
rather be a list of locale codes for which we don't do what ICU
suggests? Or some pref("dom.forms.number.grouping.disable.he", true)?

Axel

[Jonathan Watt]

ICU doesn't suggest anything. It uses grouping separators for all locales and
leaves it up to the user to tell it to stop using the grouping separators if
that's what they want. That pref suggestion would seem fine to me.

[Jesper Kristensen]

Den 12-02-2014 13:31Jonathan Watt skrev:
> The locale sources for the input are, in order of priority:
>
> 1) a 'lang'/'xml:lang' attribute on the input element or nearest ancestor
>
> 2) the page's HTTP Content-Language, either via a <meta> tag or the HTTP
> headers
>
> 3) the locale of the application
>

Why is the browser locale not the first priority? I thought one of the
major points of <input type=number>, <input type=datetime> and so on was
that it would automatically follow the user's locale and time zone.

[Robert Kaiser]

Jesper Kristensen schrieb:

The locale specified for the input field needs to be the highest
priority, otherwise you'd have an English page with values printed as
"756,000.00" suddenly have the number input in a different format, which
would be *very* confusing.

KaiRo

[Sebastian Hengst]

Hi localizers,

the grouping separator has been disabled by default, see
https://bugzilla.mozilla.org/show_bug.cgi?id=974175#c8

Cheers,
Sebastian

-------- Original-Nachricht --------
Betreff: l10n of <input type=number>, and a useful pref for localizers
Von: Jonathan Watt <jw...@jwatt.org>
An: dev-...@lists.mozilla.org
Datum: 2014-02-12 13:31

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>