Help us design future Intl API!

[Zibi Braniecki]

Hi Gaia devs!

I've been lately analyzing our Firefox OS core apps looking for examples of code that could and should be clustered into Intl API (separate from L10n API[1]).

Current revision of Intl API gives us three objects that you all should be using (I'll write more about it soon, once we land IntlHelper[2]):
- DateTimeFormat
- NumberFormat
- Collator

But the underlying library that we are using for that has a powerful database called CLDR that has much, much more. We'd like to tap into those resources based on what Gaia UI's could use now.

The first set of features that we're thinking about are:

1) Plural Forms

We're currently storing them in l20n.js and it takes a lot of space. It would be nice to have Intl.PluralForm API.

2) Timezone names

For our Settings/FTU we could just retrieve list of timezones in a given locale without having to ask our localizers to translate 100 names.

3) Units

The whole "5 KB", "35 °C", "15 KB/s" or even "5/101" should be handled by Intl.

4) Relative dates/times

We have a mock in l10n_date, but CLDR has much more for things like "2 minutes ago", "in 5 seconds", "yesterday" etc. (more examples in french: [3])

5) List formatting

This will eventually be part of localization, but it can be handled by Intl

["John", "Mary", "Jim"] => "John, Mary and Jim"

6) startDay

Which day of the week is first in a given locale

7) DateTime tokens order

day/month/year vs. month/day/year - for datetime picker

---

There are more items like that, but we think they may wait. So we want to start by implementing those things in our local mozIntl library and switch Firefox OS to use them. At the same time we'll be working with other vendors through Ecma on standardization of those bits and eventually we'll push them into Intl API.

You can read a fairly hectic list of items that we'd like to elevate from CLDR here: https://l20n.etherpad.mozilla.org/mozintl

My question for you is - do you see in your code more examples of things that should be unified under mozIntl and potentially exposed in Intl API.
I can imagine lots of things related to Calendar, and I see some bits in Clock, but I don't know all the issues in all apps so would love to get feedback.

zb.


[1] The line between Intl and L10n is blurry, but roughly you can think of it this way - localization is everything where we work with a custom message in a given language and we want this message to be translated into a different language. Intl is where we have a piece of data - like 5 kb, or a date, or a number, and we need to operate on it - maybe format it, maybe sort it etc.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1191011
[3] http://www.unicode.org/cldr/charts/27/summary/fr.html#5453

[Ahmed Nefzaoui]

From my experience, calendar's week start day is a neat little detail that would be nice to store somewhere like mozIntl. We have for example some regions and countries where the first day of the week is Saturday while in others it's Monday. Being able to pull those using an API would be better than adding manual hacks and exceptions to apps that depend on such a piece of information.
The way I see us pulling such an information from an API is not by country name but instead by "language-country", eg. ar-TN (Arabic - Tunisia) would return Monday as first day of week while ar-EG (Arabic - Egypt) would return Saturday.

And one more thing.

I'm not sure about those ones but would you consider:
1- telephone format
2- International phone/country codes
possible being part of the Intl library?

Thanks!
Ahmed

> Date: Tue, 15 Sep 2015 21:39:19 -0700
> Subject: Help us design future Intl API!
> From: zbigniew....@gmail.com
> To: mozilla-...@lists.mozilla.org

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

[Guillaume Marty]

I like this proposal and some of these items are already covered by CLDR. List formatting is one of them (though the English uses the Oxford comma).

Another useful set of data is the list of countries/regions and languages localised. I think both sets are in CLDR too.

--

Guillaume Marty
@g_marty
http://gu.illau.me

[Zibi Braniecki]

On Wednesday, September 16, 2015 at 1:18:22 AM UTC-7, Ahmed Nefzaoui wrote:
> From my experience, calendar's week start day is a neat little detail that would be nice to store somewhere like mozIntl.

Excellent news! Not only we are talking about doing that in mozIntl, but we also see interest from other vendors to add it to Intl API! :)

> I'm not sure about those ones but would you consider:
> 1- telephone format

Cool! Adding to my list :)

> 2- International phone/country codes

Not sure about that. It seems to me less of an Intl and more of a generic database, since it doesn't change depending on the language.

Thanks!
zb.

[Zibi Braniecki]

On Wednesday, September 16, 2015 at 2:23:14 AM UTC-7, Guillaume Marty wrote:
> I like this proposal and some of these items are already covered by CLDR. List formatting is one of them (though the English uses the Oxford comma).

Haha. Yes! I've been designing it around CLDR because we have access to it.

> Another useful set of data is the list of countries/regions and languages localised. I think both sets are in CLDR too.

They are. The problem here is that it's a very long list and storing all that data for all locales may increase the size of Intl API beyond of what some of our partners may be interested in (and, quite frankly, some of our projects - see Firefox for Android which still doesn't have Intl API), so there may be some pushback.
We may be able to add it to mozIntl.

Do you have a use case for those? I'm not sure if I know where we would need that right now.

zb.

[Julien Wajsberg]

Le 16/09/2015 23:29, Zibi Braniecki a écrit :
> On Wednesday, September 16, 2015 at 1:18:22 AM UTC-7, Ahmed Nefzaoui wrote:

>> From my experience, calendar's week start day is a neat little detail that would be nice to store somewhere like mozIntl.

> Excellent news! Not only we are talking about doing that in mozIntl, but we also see interest from other vendors to add it to Intl API! :)
>

>> I'm not sure about those ones but would you consider:
>> 1- telephone format

> Cool! Adding to my list :)

But this should not work like the other Intl features we have currently.

I don't think we want any telephone format to change according to your
locale, but rather according to which country the phone number belongs
to. So if it has an international prefix, we should rather force the
locale that corresponds to this prefix than use the current user locale.

For example, a french phone number is usually written as: "+33 1 23 45
67 89".
But US phone numbers are usually written as "+1 (123) 456 7890".

I don't think we want the french number to be written "+33 (1) 234
56789" in US locale. BTW this could mean to an unexperienced reader that
the "1" could be omitted when we're in this area, which is not true in
France.

Just like I don't think we want the US number to be written "+1 12 34 56
78 90".
(although in that case it's arguable).

What we usually want is that the telephone format be automatically
chosen depending on either the phone number international prefix if
present, or default to the locale-specific format (that should not be
enforced on all phone numbers).



Same goes for address formats BTW.

[Zibi Braniecki]

On Thursday, September 17, 2015 at 2:42:53 AM UTC-7, Julien Wajsberg wrote:
> But this should not work like the other Intl features we have currently.
>
> I don't think we want any telephone format to change according to your
> locale, but rather according to which country the phone number belongs
> to. So if it has an international prefix, we should rather force the
> locale that corresponds to this prefix than use the current user locale.

That would indicate that it's not a good Intl material.

I wasn't aware how we may want to format numbers and initially thought that we will want to format all numbers to the local formatting.

If we want to keep them according to their country prefix formatting, then I don't think it belongs to Intl.

zb.

[Stéphane Roucheray]

For late arrival notice of messages in SMS app[1] we need to format a duration It is related to dates/times but is more like a number formatting. Ex:
* 1000 => can be '1s' or '1 second'
* 60000 => can be '60s' or '1min'
* 61000 => can be '61s' or '1 minute and 1 second' or even just '1 minute' (in case you want a simplified version of the exact duration)

Would it make sense to have it in Intl API ?

> 3) Units
>
> The whole "5 KB", "35 °C", "15 KB/s" or even "5/101" should be handled by Intl.
>
> 4) Relative dates/times
>
> We have a mock in l10n_date, but CLDR has much more for things like "2 minutes ago", "in 5 seconds", "yesterday" etc. (more examples in french: [3])

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1037620

[Zibi Braniecki]

On Monday, September 21, 2015 at 10:21:50 AM UTC-7, Stéphane Roucheray wrote:
> For late arrival notice of messages in SMS app[1] we need to format a duration It is related to dates/times but is more like a number formatting. Ex:
> * 1000 => can be '1s' or '1 second'
> * 60000 => can be '60s' or '1min'
> * 61000 => can be '61s' or '1 minute and 1 second' or even just '1 minute' (in case you want a simplified version of the exact duration)
>
> Would it make sense to have it in Intl API ?

Totally!

In fact, if you look at the top its there as 4) and we already started specifying it [0]

I don't know if non-relative duration is available in CLDR for us ("5s" vs "5s ago" and "in 5s"), but I hope it will be. We will want to shim it ASAP into shared/js/moz_intl.js and you'll be able to use that.

zb.


[0] https://github.com/tc39/ecma402/issues/35