Add ordinal and spellout styles in NumberFormatter about proposal-intl-numberformat-v3

[sffc]

Related:

• tc39/ecma402#494
• tc39/ecma402#95

[sffc]

CC @romulocintra

Intl.NumberFormat has options that are decimal-specific. For example, how would you format the following?

• { style: "ordinal", notation: "compact" }
• { style: "ordinal", useGrouping: true }

[Bx1]

* `{ style: "ordinal", notation: "compact" }`

For English (compact long, depends on rounding):

• 3 → 3rd
• 1003 → 1000th
• 2018 → 2000th
• 1234567 → 120000th

For English (compact short, depends on rounding):

• 3 → 3rd
• 1003 → 1Kth (thousandth)
• 2018 → 2Kth (thousandth)
• 1234567 → 1Mth (millionth)

* `{ style: "ordinal", useGrouping: true }`

For English:

• 3 → 3rd
• 1003 → 1,003rd
• 2018 → 2,018th

BUT,

sincerely, I think current spec for NumberFormat is... bad (unclear, tricky, complex, not optimized, etc.). I think everything which is connected to any numbers is tossed and mixed in one bag -- called Intl.NumberFormat.

My opinion is that Intl.NumberFormat should be divided.

My proposal is as follows:

1. We have classes:

• Intl.NumberFormat
• Intl.CurrencyFormat
• Intl.MeasurementFormat
• Intl.NumeralFormat (name from Numeral part of speech, to force that this is a language formatter)

2. We have one, single class to format number (Intl.NumberFormat). With style, grouping, maximumSignificantDigits, rounding and other options strictly connected to mathematical, abstract idea of numbers.

3. Following classes (Intl.CurrencyFormat, Intl.MeasurementFormat, Intl.NumeralFormat) have their own formatting options. For example Intl.CurrencyFormat should have current currency, currencySign, currencyDisplay, etc. On the other hand Intl.MeasurementFormat should have current unit, unitDisplay, signDisplay, etc. Current style called style: percent should be used as unit, so it must be formatted by Intl.MeasurementFormat.

4. Classes Intl.CurrencyFormat, Intl.MeasurementFormat, Intl.NumeralFormat have attribute called numberFormatter which should be an instance of Intl.NumberFormat class. This numberFormatter will be delegated to "construct" value of the number, and container class will be designed to "construct" result (eg. currency number) from this formatted number and their own settings. It can be initially required that NumberFormat has the same Locale as "container class" like CurrencyFormat.

const measurementFormatter = new Intl.MeasurementFormat('en-US', { unit: 'meter' });
const numberFormatter = new Intl.NumberFormat('en-US', { signDisplay: 'never', notation: 'engineering' });
measurementFormatter.numberFormatter = numberFormatter;
measurementFormatter.format(11);

5. The last class (Intl.NumeralFormat) should be used to format numbers into numerals (ordinal, spell-out, etc.). It should also
   have own settings. For example: ordinal numbers can be formatted shortly as "3." or "3rd", but it also can be spelled-out as "third".

This composition would reduce weird complexity from current NumberFormat and would enable developing new features.

[sffc]

Thanks for the feedback.

The all-in-one design for NumberFormat is intentional, because most of the same settings are used in all of the style options. The combination of style and notation allows for powerful combinations with a minimal learning curve.

For example, the difference between Intl.NumberFormat("en", { style: "unit", unit: "meter" }) and Intl.UnitFormat("en", { unit: "meter" }) is largely one of taste.

It's possible that we could have gone the direction of separate formatters, but the very first version of ECMA-402 already had "currency" and "percent" as style options, so when we added "unit" more recently, it only made sense to continue the trend.

I agree that the spec is complex. I would like it to be less complex, but that will require some changes to how we deal with locale data (tc39/ecma402#210).

{ style: "ordinal", notation: "compact" }

Actually I think "1 thousandth" makes sense here for long. For short, "1 Kth" might be acceptable.

[Bx1]

Thanks for your feedback too. Thanks for your commitment in this project.

I hope these ideas would help to improve future web development (for web clients developers and browser developers).

[sffc]

I'm going to close this issue as out of scope for this proposal, because this proposal is already at Stage 2 and adding the RBNF dependency is too big of a change. However, I have seen broad support for this feature, so I hope it can be actioned in an upcoming release of ECMA-402. Follow this thread for updates:

tc39/ecma402#494