Allow constraints on arguments

[macchiati]

Translation pipeline software need to be able to expand (or contract) the possible options for plural and ordinal rules based on the locale. The worst case expansion of plurals is pretty bad: with some locales for two plural selectors, 36 variant messages may be needed.

The number of expansions can be significantly reduced if the translation software can be informed as to constraints on the input arguments.

Examples: There are locales where:

• the 'other' category cannot be triggered if the argument can only be an integer.
• the 'zero' category cannot be triggered if the argument ≥ 1.
• the 'one' category wouldn't be triggered if there is a literal 1.

Cf. https://cldr-smoke.unicode.org/staging-dev/charts/43/supplemental/language_plural_rules.html

If we had some kind of syntax in MF whereby the developer can communicate this kind of information to the translation software, it would help to reduce translation costs.

Given the schedule, this might not be a feature for MF2.0, but should be kept in the queue. Here is a straw-man proposal (not that I'd necessarily recommend this particular syntax):

limit $peopleInGroup {> 1, integral}

match {$peopleInGroup :number} when other {There are $peopleInGroup people in the group, including you.}

// It wouldn't need the 'one' case in English, or in other locales where it only triggers on integers ≤ 1

[eemeli]

I ended up thinking about this in the context of #425 and #427, by wondering whether we ought to have a shorthand like :integer baked in as a default formatter for the really common case of handling whole number values -- it's much more common than formatting non-integral values, but :number minimumFractionDigits=0 is far too much of a mouthful to be used all that often.

But as @macchiati mentions above, integers are by no means the only constraint that we might apply to values. And at runtime, we do need the ability to deal with e.g. non-integer values, so the prime consumers of a directive like limit would be translators and their tooling. To me this suggests that a decent solution would be to define a semantic comment specification for messages and their arguments, as @zbraniecki proposed in #53.

Such a spec would not need to be a part of the MF 2.0 release, but it could also help resolve some of the tooling-related concerns regarding e.g. un-annotated value treatment in selectors.

@aphillips I added a resolve-candidate label recently to issue #233 as I believe we've determined not to work on this within the MessageFormat WG. A semantic comments spec is a requirement for the MessageResource WG work, but I thought I'd check: Should we reconsider defining it here, or is it outside our scope? AFAIK, no such message semantic comment spec exists, and its utility would not be limited to any one specific resource format.

[aphillips]

@macchiati

I think this isn't as helpful as it at first appears? Providing some value assertion guidance to the translation processor will reduce some explosions for some locales, but it won't greatly reduce the overall matrix size for most locales. It'll be an "advanced" feature and, since it provides no utility to the developer (and not much reduction in translator effort), probably not widely used. I'd add that it will also mean that the resulting translated resources will vary in shape, making it harder for humans to see if a given resource is "complete" or not. It's also "another thing that can go wrong only at runtime", i.e. it becomes an assertion error if $peopleInGroup turns out to be 1 sometime.

--

@eemeli

I ended up thinking about this in the context of https://github.com/unicode-org/message-format-wg/issues/425 and https://github.com/unicode-org/message-format-wg/issues/427, by wondering whether we ought to have a shorthand like :integer baked in as a default formatter for the really common case of handling whole number values -- it's much more common than formatting non-integral values, but :number minimumFractionDigits=0 is far too much of a mouthful to be used all that often.

I think this is mixing things together. Having an integer formatter is a super common thing to want to do, even if the argument is a float or double "in real life". That's not a constraint, it's formatting instructions. Having shorthands for common operations makes everyone's life easier. We can still have limit or constraint indications separately, but we can make messages in which the semantic intent of the formatting is clear to everyone:

; which would you rather type? translate?
{There are {$count :number maxFractionDigits=0} items}
{There are {$count :integer} items}

Resource formats should provide comments and translator annotation capabilities, but we excluded them from the message pattern syntax because comments at runtime would just be discarded--the existence in MFv2 would be solely to "patch" every containing format everywhere that doesn't provide comments--and because in-message markup (such as term identification) can also be part of a resource format's serialization scheme.

In short, I agree that we previously agreed about #233 and thus the resolve-candidate label.

[aphillips]

I'm keeping this as Future for now, although there has been no traffic on it since last July.

[aphillips]

@macchiati Would you prefer that we (a) mark this as resolve-candidate (i.e. close it) or (b) keep this issue for future consideration (post-46.1)? Implementation of this would require an additional keyword, the appetite for which I would guess is limited at present.

[macchiati]

I'm fine either way

On Tue, Sep 10, 2024, 16:30 Addison Phillips @.***> wrote:

@macchiati https://github.com/macchiati Would you prefer that we (a) mark this as resolve-candidate (i.e. close it) or (b) keep this issue for future consideration (post-46.1)? Implementation of this would require an additional keyword, the appetite for which I would guess is limited at present.

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/message-format-wg/issues/376#issuecomment-2342334247, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMFCAUZSMZHPMPEFTWTZV56INAVCNFSM6AAAAAAWZMU5DGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBSGMZTIMRUG4 . You are receiving this because you were mentioned.Message ID: @.***>

[aphillips]

Based on that response, I'm closing this. Reopen in the Future if interested. (Future > 46.1)