TODO: add tests.

But I wanted to unblock the splitting of the registry in separate files.
Plus, the wording is the the part that might be controversial.
The tests, not so much.

If the option is available on :number, it should also be on :integer.

OTOH, if it only supports whole number values, it might make sense to only allow on :integer; I'm not aware of any use case for it having been presented for non-integer values.

I also submitted #927 as the text around resolved value should be clarified.

Good catch, thank you.

I added the option to :integer

About removing it from :number, I am split.

I can't imagine a use case for non-int with offset.

BUT I have two reasons to keep it:

One is that ICU supports it.

You can pass a non-int argument and get "Alice, Bob, and 3.142 other guests".
You can also pass a non-int offset, and works.
And you can pass a negative offset (integer or not) and works.

I cannot imagine a use case for any of these...

The second reason I kept it was that I suspect that some devs would not be too careful about :number and :integer.
So functionally they would only pass integral values, but do the formatting and selection with :number.

But I am fine to say: no, we don't support any of this.
We only support 0 or positive integers for offset, and only only support offset on :integer.

Adding them later would be backward compatible.

Summarizing the questions:

• should we support fractional and / or negative offsets?
• should we support offset on :number?
• should we support offset in ordinal mode?
• what to do with offset in the resolved options?

Thinking about this some more, I think copying the MF1 plural offset option seems like the wrong thing to do: We are not restricted in the number of functions that are available, or the number of selectors. Considering the canonical example case for offset, slightly modified to use one rather than =2:

{num_guests, plural, offset:1
=0    {{host} does not give a party.}
=1    {{host} invites {guest} to their party.}
one   {{host} invites {guest} and # other person to their party.}
other {{host} invites {guest} and # other people to their party.}}

I think one reason why the docs example doesn't use this formulation is that it showcases the weirdness of having the =1 and one operate on different values.

For MF2, yes, we could copy the structure directly, but that would retain the weirdness, and the reliance on looking up what actually happens with offset: Is it added or subtracted? Does it affect the exact value selection? Does it affect the # formatting?

Wouldn't it be easier to read if we separated the behaviour into another function and used two variables? As in:

.input {$num_guests :integer}
.local $num_other_guests = {$num_guests :math subtract=1}
.match $num_guests $num_other_guests
0 *   {{{$host} does not give a party.}}
1 *   {{{$host} invites {$guest} to their party.}}
* one {{{$host} invites {$guest} and {$num_other_guests} other person to their party.}}
* *   {{{$host} invites {$guest} and {$num_other_guests} other people to their party.}}

Would that not be much clearer about what each value is, what is being selected, and what is being formatted?

The proposed :math wouldn't need to support any other option than subtract to start with, and other operations could be added if and as use cases for them are presented.

@eemeli I had the same thought. Assigning a local integer and using the bog standard :integer selector feels like a cleaner way to implement this.

FWIW, since the primary use case is alleged to be working with lists, that suggests that the :list function will need helpers or options for accessing list items, list size, etc. An offset option might make sense with .local remaining = {$guestList :list-size offset=2}

FWIW, since the primary use case is alleged to be working with lists, that suggests that the :list function will need helpers or options for accessing list items, list size, etc. An offset option might make sense with .local remaining = {$guestList :list-size offset=2}

In that case as well my preference would be to not overload a :list-size function with an offset option, but to have something separate like :math subtract that would make it explicitly clear to a translator whether the "offset" was being subtracted or added to the size.

I think it is a good ideal to handle the problem with a separate function. Moreover, it very much helps with clarity if we divide functions into two kinds:

• functions whose options only affect formatting and selection (:number, :string)
• functions whose options may produce a different 'core' value, like :math subtract=3 or :case type=uppercase

Moreover, it very much helps with clarity if we divide functions into two kinds:

Introducing non-selector/non-formatting functions does produce some complexity, since we require annotation in certain instances and implementations would have to check the type of function.

BTW "different 'core' value" has a name: "resolved value".

There are many obvious kinds of functions that could live here (cf. text-transform in CSS). Some of these are kind of like formatters ({$var :text-transform type=uppercase} selects and formats like :string, but with an uppercase transform, right?) while others would be problematic (:math wants :number/:integer/etc to do the formatting and probably doesn't want to directly be a selector)

I used the term 'core value' specifically because it is not the same as the resolved value.

.local $a = {123 :number style=decimal}
and
.local $b = {123 :number style=percent}

These have different resolved values because they have different options. See https://github.com/unicode-org/message-format-wg/blob/main/spec/formatting.md#:~:text=While%20this%20specification%20does%20not%20require%20it

I agree with pulling offset= out of :number, because it makes the delineation between the different kinds of functions much cleaner. For a function that only selects or formats or both, composition can be very simple: override the options. That is, given:

.local $x = {literal :osfFunction1 option1=ov1 option2=ov2}
.local $y = {$x :osfFunction1 option1=other option3=ov3}

.local $z = {literal :osfFunction1 option1=other option2=ov2 option3=ov3}

The $y and $z would have exactly the same resolved value. That is then a very predictable and understandable model for users. It doesn't shut out having other kinds of functions, like :math, that have more complicated composition, eg in the following $y1 and $z1 would have the same resolved values, which is not just a simple "override the options" model.

.local $x1 = {3 :math subtract=1}
.local $y1 = {$x1  :math subtract=1}

.local $z1 = {$x1  :math subtract=2}

Introducing non-selector/non-formatting functions does produce some complexity, since we require annotation in certain instances and implementations would have to check the type of function.

I think "quite on the contrary"
Knowing the type of function helps (some) implementations.
The same way a type system makes certain programming languages less error-prone.

This is similar to the distinction between formatter functions and selector functions.
Which (I've always maintained) are different animals.

Replacing with :math. Thanks for working on this, @mihnita !!