Align with ECMA402 Intl.NumberFormat

[zbraniecki]

This API is much needed for a lot of intl and l10n operations, thank you for writing it!

As for how to shape the public API I would recommend to look at the work of ECMA402 TC39 group (esp. the new revision being worked on by Shane Carr). ECMA402 designed the API based on experience of what worked and what didn't in ICU API and in result is a cleaner and more modern approach but guided by the same intl experts who designed ICU before.

Aligning this API with it would give us comparable feature set between JS, Python and Rust (and personally, give me an easy way to plug into fluent-rs ;))

[bcmyers]

@zbraniecki - It's definitely worth thinking about this, as I agree having a public API that is familiar between JS, Python and Rust is a great idea. After a tiny bit of googling, I came across this, which I believe is the TC39 proposal you're referring to. Question: In addition to this link, what other links / resources can you think of that are important for me to read / digest as we think about this issue? Any materials / links you can provide in order to point me in the right direction would be very welcome. Thanks!

In summary, what do you recommend I read to start getting my head around this issue?

[zbraniecki]

After a tiny bit of googling, I came across this, which I believe is the TC39 proposal you're referring to.

Yes! :)

In addition to this link, what other links / resources can you think of that are important for me to read / digest as we think about this issue?

You can read the outline of the current NumberFormat on MDN, which I think is a very well designed API (I promise I had nothing to do with it, I started championing ECMA402 when this API was done :)). The second revision is bringing more features and aligns it better with the modern ICU API, but is really not that big of a change.

You can read the whole spec, but I doubt it to be worth when discussing the API design. What I think matters is that:

• we ensure that there's a locale fallbacking similar to how Intl allows you to pass a list of locales and negotiates the best locale for you
• we support, even in a very basic way BCP47 for locales (it's ok to support only subset of it like language/script/region for now, and skip the unicode extensions parsing, but we'll likely want to add it later once UNIC's Locale stabilizes)
• we ensure that there's an option bag with similar options for precision and grouping of the output.

For now, it's totally ok to skip all notations, units, currencies etc, but I'd recommend designing the option bag to be aligned with what ECMA402 does to allow for future extensions to add the other options. This will ensure that this crate is handling a good spec for number formatting, can be extended to units, and will work well with unicode extensions keys.

To be clear, I'm specifically suggestion not adding features right now. Your crate does what it should do, and it's a great start! I'm only advocating to align the API you have currently to be closer to what ECMA402 does so that adding features in the future can be done by just adding options, without having to deal with inconsistencies.

For example, when designing the API for intl-pluralrules we shaped it after Intl.PluralRules in ECMA402 - https://docs.rs/intl_pluralrules/1.0.2/intl_pluralrules/

let pr = new Intl.PluralRules("de", {type: "cardinal"});
pr.select(5);

let pr = IntlPluralRules::create("de", PluralRuleType::CARDINAL)?;
pr.select(5);

There are missing pieces that I'll want to add to intl-pluralrules:

• option bag with minimum/maximum*Digits and type instead of just type
• locale list instead of a single locale
• locale negotiation against available locales
• support for unicode extension keys from locales

The last 3 will likely come when we merge it into UNIC and handle Locale API, but the first one is something that can be added earlier and will help with pluralization of units like 1.5 which in some languages is different from 1.50. I'd recommend you doing the same :)