What grouping strategies to include?

[sffc]

The proposal currently includes the following 4 grouping strategies, based on the list from ICU:

• "never" (false): do not display grouping separators.
• "min2": display grouping separators when there are at least 2 digits in a group; for example, "1000" (first group too small) and "10,000" (now there are at least 2 digits in that group).
• "auto" (default): display grouping separators based on the locale preference, which may also be dependent on the currency. Most locales prefer to use grouping separators.
• "always" (true): display grouping separators even if the locale prefers otherwise.

@jswalden asked if there could be additional options added. Could you clarify?

[ray007]

I assume "always" would be the equivalent to UNUM_GROUPING_ON_ALIGNED?
What about UNUM_GROUPING_THOUSANDS?

[sffc]

I assume "always" would be the equivalent to UNUM_GROUPING_ON_ALIGNED?

Correct

What about UNUM_GROUPING_THOUSANDS?

It's not clear whether having that option in ICU is good i18n practices. The use cases for turning grouping on and off are known, but it's not clear what the use cases are of overriding the grouping sizes themselves with Western defaults.

[littledan]

Would min2 mean that 1_000_000 is displayed as "1000,000"? Is this appropriate in any locale?

For en-IN, would it make sense to give a choice between lakh/crore grouping and Western-style grouping? (Or is Western-style grouping never ever appropriate in that locale?)

@sffc You mention a possible Western bias with the possible "thousands" option. Can you say anything more about how/whether non-Western locales tend to handle this sort of case?

[littledan]

For en-IN, would it make sense to give a choice between lakh/crore grouping and Western-style grouping? (Or is Western-style grouping never ever appropriate in that locale?)

I chatted with @ryzokuken ; sounds like the answer is "no".

[jswalden]

I think the "additional options" I was thinking of, were basically targeting the "min2" case, so I think min2 may cover it. I'm thinking of patterns I'd seen in CLDR for more specialization, but at least the ones I saw were dealing with the min2 case.

[FrankYFTang]

Just FYI Peter Edberg [email protected] point out to me about Spanish locale using min2:

REAL ACADEMIA ESPAÑOLA (Spanish language authority) specifies that numbers in the range 1000-9999 should not have a thousands separator, see section 2a) in the following:
https://www.rae.es/dpd/números
(that also specifies using space rather than period for thousands separator, but that is more recent change that is not yet reflected in common usage).

[littledan]

Would min2 mean that 1_000_000 is displayed as "1000,000"? Is this appropriate in any locale?

Note, @sffc clarified in the April 2020 ECMA-402 call that min2 just affects numbers in the 1000-9999 range, so the answer to my question would be "no, it would have two grouping separators in a locale like en-US."

[ray007]

Maybe the setting should be "minimum number of digits to start grouping".

[littledan]

@ray007 Do you have a use case for where 4 or 5 is not the answer?

[ertw]

Hello, I am trying to understand if the proposed grouping: "always" option satisfies my needs.

I work in es-CL and es-MX. I would like to use Intl.NumberFormat to format MXP and CLP currencies. In Mexico, 1000 pesos should be displayed as "$1,000", while in Chile, 1000 pesos should be displayed as "$1.000". This actually used to work in Node 10, but has since been "fixed" to properly adhere to the Unicode CLDR standard, along with Firefox & Chrome.

example:

Intl.NumberFormat('es-CL', { style: 'currency', currency: 'CLP' }).format(1000)
# result: $1000, this is bad because there is no thousands separator
Intl.NumberFormat('es-CL', { style: 'currency', currency: 'CLP' }).format(10000)
# result: $10.000, this is good

As you can see, I get the correct unit grouping on a 5 digit number, but not on a 4 digit number. The reason for this is that these locales inherit from es, which is defined by Unicode more or less in accordance with the Spanish Royal Academy. The Academy mentions that 4-digit numbers should not use unit separators. This is not really correct in Latin America (or Spain as far as I know), which means that I cannot use Intl.NumberFormat in my application. I have written to the Academy of the Mexican Language, and confirmed with them that including or not including a unit separator are both correct, and that furthermore including a unit separator is correct per the Mexican Accounting Association. Because both formats are technically correct, I'm just looking for a way to have a little more control of how Intl.NumberFormat groups currencies so that I can use it, rather than using my own code with is likely buggier.

So in summary, can I force a unit separation in a currency formatter even if the minimum grouping number defined in the locale has not been reached?

[ertw]

For what it's worth, I'm hoping my specific grouping issue will be solved in the next Unicode CLDR update. Regardless, I also think that giving more grouping options to end users will make the internationalization functions more useful, and being able to override locale defaults is an important part of this.

[sffc]

I would like to seek consensus on the following:

• useGrouping:
  • false: do not display grouping separators.
  • "min2": display grouping separators when there are at least 2 digits in a group; for example, "1000" (first group too small) and "10,000" (now there are at least 2 digits in that group).
  • "auto": display grouping separators based on the locale preference, which may also be dependent on the currency. Most locales prefer to use grouping separators.
  • "always": display grouping separators even if the locale prefers otherwise.
  • true: alias for "always"
  • undefined (default): alias for "auto"

[sffc]

TG2 2020-10-08: Adopt the behavior stated above, with resolvedOptions returning false or one of the three strings.

[sffc]

2020-10-08 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2020-10-08.md#what-grouping-strategies-to-include-3

[justingrant]

FYI, on the Temporal side we're planning to use strings 'never' and 'always' instead of boolean false and true, in addition to an 'auto' option. This aligns with Intl.NumberFormat's signDisplay option.