Currency Formatter

[sffc]

This issue is to track all work needed for currency formatting in ICU4X.

Some high-level design notes:

• We want to build on top of FixedDecimal and FixedDecimalFormat
• We should be as modular as possible
• We should build this system to be extensible to future features such as Compact Currency ("$1M") and Global Currency ("$1 USD")
• The currency influences the rounding of the FixedDecimal, so this needs to be built into the API somehow
• I think it probably makes sense to make a class called CurrencyFormat, but we may want to explore other alternatives

Links:

• Example CLDR data: https://github.com/unicode-org/cldr/blob/7e8aabbe77bd6e24fd06462aa223f893682f6161/common/main/de.xml#L5919
• Jira ticket to discuss changes to the data: https://unicode-org.atlassian.net/browse/CLDR-14336
• Design doc for those changes: https://docs.google.com/document/d/15TTjG7EDMsuzMjldLPhOAsl9Lgu3zpN1xlG9ZMLYPyE/edit#
• UTS 35 spec: https://unicode.org/reports/tr35/tr35-numbers.html#Currencies
• ECMA-402: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat

[sffc]

Re-assigning the macro issue for currency formatting to @eggrobin for the 1.1 milestone. This is Q3/Q4 material.

[sffc]

We still need to establish the data model for currency formatter.

There are two aspects of a data model:

1. What data is stored in what keys and what locales?
2. Within each individual key, what is the zerovec structure?

There are many ways to do this, all with pros and cons.

@younies @Manishearth

[sffc]

Discussion:

• @robertbastian - Can we realistically put the currency in the key? There are new currencies all the time.
• @robertbastian - On commerce sites, you don't control at build time which currency to load.
• @sffc - For apps that require one currency at a time, we can do auto-slicing if the call sites are CurrencyFormatter::<USD>. Not sure if currencies are more like calendars (which are in the key) or collations (which are in the locale).
• @robertbastian - I think making this code-driven is a bad i18n practice.
• @sffc - There are lots of interesting way to slice currency data. Maybe we can drop display names that are for rarely used currencies. Perhaps we want to give that power to datagen, not locking us into the code approach.
• @Manishearth - Over time we're going to need configurable datagen. So this seems like a feature that is good to have. I'm a bit sad if this isn't automatic, but it's probably the right decision to make it variable.
• @echeran - We shouldn't create extra sophistication until we have solid justification that static typing is a common, priority use case that justifies the cost.
• @sffc - I've heard a lot of solid arguments about making this data-driven rather than static-type-driven.
• @robertbastian - We should use this opportunity to improve datagen for other things as well, like calendars
• @younies - I think for units, we're not going to be able to use static keys. It would be nice for currency and measurement units to be similar in this aspect.
• @Manishearth - Not everyone is ready for a library update to add a currency.

Conclusion: make the set of currencies data-driven.

[sffc]

A few ways to encode it at lookup time:

1. Use a Unicode extension keyword: ar-u-cu-usd
2. Use a private use subtag: en-x-eur
3. Add an extra path segment: en/eur or eur/en

Reasons to favor option 3: This shouldn't be controllable by the user locale, so option 1 is out. Option 2 is a bit tricky/confusing if the user locale has a -x and we drop it.

To set option 3, we add a setter to DataLocale that sets the separate metadata field. Suggested naming:

• set_prefix
• set_content
• set_content_locale
• set_content_type
• set_content_version
• set_content_style
• set_runtime
• set_style
• set_keyword
• set_version
• set_kind
• set_criterion
• set_property
• set_field
• set_extra_field
• set_aux
• set_auxiliary
• set_aux_field
• set_auxiliary_field
• set_auxiliary_key
• set_intermediate
• set_intermediate_key

Tentative decision: set_auxiliary_key. Make it hidden initially.

Additional thought from @robertbastian: en-NZ should fall back to en-ZZ so that we don't get US currency symbols implicitly.