Support for plural selectors for a range of numbers

[eemeli]

The pluralisation rules for ranges of numbers are different from the pluralisation rules of e.g. the last value of the range. For an example in English, consider "0-1 items". In general, the plural category of a range may depend on the plural categories of both the start and end values of the range.

Describe the solution you'd like
MessageFormat 2 should allow for number ranges to be properly pluralised.

Describe why your solution should shape the standard
Unlike cardinal and ordinal plurals, range plurals depend on two inputs rather than one. This needs to be accounted for as we're designing the data model and everything that depends on it.

Additional context or examples
These rules are included in the CLDR supplemental data for at least a subset of the languages for which cardinal rules are available. I'm currently working on a polyfill for a proposed JS API for selecting plural ranges (tc39/proposal-intl-numberformat-v3#16).

[aphillips]

Note that the numbers in the range can also be either cardinal or ordinal. Would this also apply to date/time ranges (is there a separate issue for that)?

[eemeli]

Do ordinal and date/time ranges affect the pluralisation of their surrounding content in some languages? And is that data available somewhere? AFAIK, the only current source of such data is the CLDR, which only includes cardinal plural ranges.

If we can show support for cardinal range plurals, I'm relatively confident that any other range plurals could also be accounted for.

[aphillips]

I suspect that this issue is either (a) addressed by WG decisions that would allow such a selector to be implemented using the registry or (b) not addressed because it should be considered a request to add such a selector to the "standard registry" (should we decide to implement one). Adding resolve-candidate to consider the above.

[stasm]

IIRC, the key part of the original request was this:

Unlike cardinal and ordinal plurals, range plurals depend on two inputs rather than one. This needs to be accounted for as we're designing the data model and everything that depends on it.

Back in the day we were considering n-ary functions, like so:

{$start $end :range option=value}

In the end, we settled on not allowing more than one positional arguments to functions. Some notes:

1. Most container data types can be usually handled with custom container structures ($myRangeObject):

   {$myRangeObject :range option=value}
   {$users :listfmt shift=1 ...}
   

2. Tuples of known arity can be additionally usually handled with standalone functions and additional named options:

   {:range start=$start end=$end option=value}
   

3. AFAIUI, it's not currently possible to collect a number of variables into a new list, but (1) and (2) are likely enough for a large majority of use-cases:

   {$user1 $user2 $user3 :listfmt ...} // Currently not possible.
   

[aphillips]

@stasm noted:

AFAIUI, it's not currently possible to collect a number of variables into a new list, but (1) and (2) are likely enough for a large majority of use-cases:

Making a "new something" is the work of let. So a couple of ways one could make such lists:

let $somelist = {:list-making-function item1=$foo item2=$bar item3=$baz ... $itemN=$moo}
...
let $somelist = {:list $foo}
let $somelist = {$somelist :list-append $bar}

In most cases, though, lists or such are built by the caller rather than mutated or collected inside the message.

[aphillips]

Retitled to avoid conflict with similarly named (but distinct) #21.

[macchiati]

We haven't gathered the information for ordinal ranges (eg "The 1st - 4th items"), which is an oversight. @eemeli would you mind making a feature request for CLDR, since you pointed it out?
https://github.com/unicode-org/cldr/blob/main/docs/requesting_changes.md#how-to-file-a-ticket