While working on Clock app localization I tried to start using Intl.NumberFormat to format numbers. When one uses a number as part of a localization string, he cannot unfortunately pass a formatted number because in non-arabic numerical systems such numbers will never get formatted for plural form macros. Example: var formatter = Intl.NumberFormat('ar'); var elem = document.getElementById('x'); elem.setAttributes('data-l10n-args', JSON.stringify({emailCount: formatter.format(1)}); This will turn emailCount into a non-number and l20n's plural macro will turn it into "other". Instead, we should pass an integer, and l20n should resolve it on output.

Stas, what do you think? I think it would be natural to use Intl API for that and get numbers converted on output (we also don't want BDI characters in that scenario I believe). I think we will want to keep a NumberFormat object and reset it on languagechange.

I'm still not entirely clear on the future role of macros in l20n for such scenarios. My understanding was that we'd pass an integer and let the localizer use a formatting macro where they need it. This gives the most control possible to the localizer. Would like to make the formatting automatic instead?

(In reply to Staś Małolepszy :stas from comment #2) > Would like to make the formatting automatic instead? I meant to ask: 'would you like…' of course.

> Would you like to make the formatting automatic instead? Yes. I think I'd like the number formatting to happen automatically when the variable type is an integer. Since we don't have macros, and we will not have them in 2.5 (and I'm not sure if we'll get them in 2.5.Next), I'd prefer to get something working now. The best way for a developer to tell us that the variable is a number is to pass it as an integer. If it's an integer and its supposed to be displayed it should be displayed in the right language. It's not HTML specific, all platforms should receive numbers formatted to match the strings. "You have 5 unread emails" should never have strings translated and number not. My thinking is that we should first start formatting all integer variables on concatenation and then maybe start requiring that plural macro accepts only integers (to avoid a scenario where a dev passes a string, we cast it for plural, but don't format on output). Once we get global macros, we can start letting localizers format the formatter - specify options for NumberFormat. But for now, let's just make it work for simple numbers. What do you think?

OK, that sounds good. Thanks for providing more detail!

Comment on attachment 8666995 [details] pull request r=me with comments left on github.

Commit: https://github.com/l20n/l20n.js/commit/e2e07f6c20dc8e3d3bcd7e40a9759fffde2de214