Support for plural range selectors

[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

[eemeli]

✅ https://unicode-org.atlassian.net/browse/CLDR-16814

[aphillips]

Removing resolved-candidate because this appears to be a request for plural selectors for ranges.

[stasm]

It is already possible to imagine a selector function which can select variants based on two inputs, passed in either as a container object ($myRangeObject) or given as two options (start= and end=).

match {$myRangeObject :range option=value} ...
match {:range start=$start end=$end option=value} ...

Is this issue about adding such selector to the set of the built-in ones? Or something else?

[aphillips]

@stasm I agree that this issue is unclear and that it is possible to imagine a selector such a you describe.

@mihnita I think that the only thing that could be in-scope here is if someone thinks that a range selector or range plural should be in the default registry (or if we think that :number or :plural should support ranges). If that isn't what is being requested--if this is just a thought experiment about what someone might want to write in an implementation or custom registry, I think we can safely close it. Agree?

[stasm]

Oh, only now did I see that the issue is from October 2020. For some reason I thought it was a much more recent one; probably because of the recent activity. @eemeli Do you think we can close it given now?

[eemeli]

I'd be ok with closing this. I still think we ought to support multiple positional arguments, but I don't think it's important enough to argue about at this time.

@aphillips, if you agree please close this. I do note that you've recently mentioned functions like :gt that would benefit from that as well; as is, I suppose you've been considering syntax like

{$foo :gt other=$bar}

for them?

[aphillips]

(as individual contributor)

@eemeli that's what I had in mind, as well as synonyms like :

{:function arg1=$a arg2=$b ... argN=$x}

{:function args=$someArray}

---

{:chair hat=ON}

Okay, closing.

In order to support multiple positional arguments, a syntax proposal would need to be made... and we'd have the additional problem of validating placeholders with n arguments (where n > 1). If you want to make such a proposal, please do so by creating a new issue and filling the new issue template. To save time, please make a full proposal 😉

[mihnita]

+1 with closing.

Even with the current (one year old) ICU4J implementation it is possible to implement and register plural-like selectors that work on ranges, lists, all kind of other things.