What settings to include for range formatting?

[sffc]

ICU4J has a number of settings for range formatting:

https://unicode-org.github.io/icu-docs/apidoc/released/icu4j/com/ibm/icu/number/NumberRangeFormatterSettings.html

collapse

Sets the aggressiveness of "collapsing" fields across the range separator. Possible values:

• ALL: "3-5K miles"
• UNIT: "3K - 5K miles"
• NONE: "3K miles - 5K miles"
• AUTO: usually UNIT or NONE, depending on the locale and formatter settings

The default value is AUTO.

identityFallback

Sets the behavior when the two sides of the range are the same. This could happen if the same two numbers are passed to the formatRange function, or if different numbers are passed to the function but they become the same after rounding rules are applied. Possible values:

• SINGLE_VALUE: "5 miles"
• APPROXIMATELY_OR_SINGLE_VALUE: "~5 miles" or "5 miles", depending on whether the number was the same before rounding was applied
• APPROXIMATELY: "~5 miles"
• RANGE: "5-5 miles" (with collapse=UNIT)

The default value is APPROXIMATELY.

Do we want to add those options to ECMA-402, or just stick with the defaults?

@romulocintra

[littledan]

I can understand why someone might want to play with collapse, but I don't really have much of a sense of whether such manipulations make sense across locales (given the existing locale-dependent variation in how AUTO works). Do we have any experience we can build on from ICU's users?

I'm having trouble understanding when you'd want to mess with identityFallback. Does anyone have a use case in mind? Approximately SGTM.

[sffc]

FYI: with AUTO in ICU, the decision on whether to collapse prefixes/suffixes could depend on the locale, but also on the symbols. For example:

• $3 - $5
• 3 - 5 CHF

However, an implementation could choose to use different results:

• $3 - 5
• 3 CHF - 5 CHF

[sffc]

Tentative conclusion from 402 meeting:

• Use AUTO as the default for collapse, and don't include it in the options bag. Wait for specific user demand for other options in the future. Write the spec in a way such that it's easy to implement AUTO without ICU's heuristic.
• Use SINGLE_VALUE as the default for identityFallback, and also don't include it in the options bag. This is the behavior for identity fallback in Intl.DateTimeFormat. Consider adding approximately as a new NumberFormat-wide option, either in this proposal or a follow-on proposal.

[sffc]

Relevant CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-11431

[sffc]

I would like to consider a world in which we have signDisplay: "approximately". Here is what the semantics could look like here:

let nf = new Intl.NumberFormat("en" /* , { signDisplay: "auto" } */);
nf.format(-3);  // "-3"
nf.format(3);  // "3"
nf.formatRange(3, 5);  // "3 – 5"
nf.formatRange(3, 3);  // "~3"

let nf = new Intl.NumberFormat("en", { signDisplay: "approximately" });
nf.format(-3);  // RangeError
nf.format(3);  // "~3"
nf.formatRange(3, 5);  // "3 – 5"
nf.formatRange(3, 3);  // "~3"

let nf = new Intl.NumberFormat("en", { signDisplay: "negative" });
nf.format(-3);  // "-3"
nf.format(3);  // "3"
nf.formatRange(3, 5);  // "3 – 5"
nf.formatRange(3, 3);  // "3"

In this frame of reference, I think it might be okay to allow APPROXIMATELY to be the default identity fallback behavior in formatRange.

See also #10 and #17

[septs]

I think it needs to be with https://github.com/tc39/proposal-Number.range having the same opening and closing interval semantics
CC @Jack-Works

[Jack-Works]

@septs intl range doesn't have same semantics with programmatic number range.
When you say "0 to 100" you're definitely including 100 but when you creating a range for programmatic use, you may want to exclude the bound.

[sffc]

I don't believe there is anything actionable remaining on this ticket. We decided in #6 (comment) to not bubble up the two range formatting options from ICU. Discussion on the approximately sign is covered in #10. I will therefore close this issue.