Handling other vs. * for plural selectors

[eemeli]

This thread of conversation between @aphillips, @macchiati and myself was started in #320, and it went a bit off-topic, so splitting it off to here.

---

Originally posted by @aphillips in #320 (comment):

@macchiati I agree with @eemeli here in that MF can only specify MF-level requirements. What you're talking about is internal to a specific (if important) selector, namely the plural one. At this level, I think we're handling it correctly by requiring the fallback be present (missing fallback error) and allowing for selector-internal errors. What you're describing is not an error. PluralFormat has always resolved keywords using plural rules and then fallen back to other (* in our case) when no matching key is found. I don't know what others teach, but I always teach developers to write =0, one, and other in English (with special care that one doesn't mean =1) and let the translators handle target languages.

The potential instability of plural rules between versions is super annoying, if understandable. Such changes should be as absolutely rare as possible because of how localization automation works. Even if translation systems update their CLDR data (and indeed assuming they consume this data) with alacrity, existing resources and translation memories make for long term quality control issues for everyone involved, plus the need to retrain linguists, engineers, and others.

Note that the elimination of a rule doesn't hurt anything (except storage) but addition of a rule (as was done recently with French, with the addition of many) is a huge pain in the ass [I am not arguing that it shouldn't have been done].

---

Originally posted by @macchiati in #320 (comment):

I can see the reasoning. We'll want to make sure to educate people that *
(for plurals, ordinals) is the same as 'other' in MF1.0, and that 'other'
must never occur.

As to additional categories in plural rules, I fully understand — we avoid
it unless the preponderance of evidence is compelling. It is a very painful
process to update, although if the new value is split off from 'other',
then it is far less painful.

---

Originally posted by @eemeli in #320 (comment):

[...] We'll want to make sure to educate people that * (for plurals, ordinals) is the same as 'other' in MF1.0, and that 'other' must never occur.

This isn't actually quite so clear-cut. In MF1, other fulfills two different roles for plurals:

• A category to explicitly choose when appropriate.
• A fallback category when none of the others apply e.g. due to bad input.

In MF2, it's possible to mirror this structure by using * instead of other, but it's also possible to separate the two by using both other and *. For example, I could imagine something like this being occasionally useful:

match {$count :plural}
when one {You have {$count} new message}
when other {You have {$count} new messages}
when * {Message count not available}

Here, the other case is in no way special from the MF2 point of view, and it's only up to the :plural function to consider it anything special, and to figure out matching for e.g. a non-numeric $count. Those details are currently considered to be an implementation decision.

---

Originally posted by @aphillips in #320 (comment):

@eemeli I can't find the discussion the group had previously about other vs. * or I'd refer this conversation to that issue. I suspect we should take this to an issue for discussion rather than here (as it's off topic here).

I happen to think that we should choose between other and * and not have both, if for no other reason than that it adds a bunch of permutation cases to plurals (and other selectors) and that it impacts the ability of tooling to generate all of the necessary cases from plural rules.

For error cases (and this might be on topic here??) perhaps we should add an optional else to the syntax (to allow the developer to override the default error handling):

match {$count :plural}
when =0 {You have no new messages}
when one {You have {$count} new message}
when * {You have {$count} new messages}
else {Message count not available}

---

Originally posted by @macchiati in #320 (comment):

I don't find the use case you present very motivating. That is, in
production software we would never want to expose your 3rd message to
users.

match {$count :plural}
when one {You have {$count} new message}
when other {You have {$count} new messages}
when * {Message count not available}

The 'other' case is special in the plural rules, in that it encompasses all
numbers that don't match the other categories, and always occurs in every
locale. So the problem lies in that if a programmer ever writes the
following, m3 will never appear.

when one male {m1}
when other * {m2}
when * * {m3}

Moreover, our translation software has to know what the plural categories
are and how they work, because otherwise it can't flesh out the
appropriate cases for each locale, for them to be translated. So it will
know that Arabic, for example, will need 6 plural categories, not just the
2 for English. And some other languages will only have 'other'.

The same would be true for other selectors, like grammatical case, that
have to be expanded (or contracted) depending on the software. So while the
MF2.0 spec in theory doesn't need to treat these specially, any non-trivial
translation pipeline will need to.

[eemeli]

@aphillips:
I happen to think that we should choose between other and * and not have both, if for no other reason than that it adds a bunch of permutation cases to plurals (and other selectors) and that it impacts the ability of tooling to generate all of the necessary cases from plural rules.

From the core MF2 spec point of view, * is clearly better than other, because the former is not a valid Literal, and therefore can be treated differently in the syntax than any of the non-default/fallback keys.

From the plural selector point of view, the question then becomes whether to ever match other, because the required * would be handled by the core engine, rather than the selector. This is related to two relevant issues:

1. The core MF2 spec does not know anything at all about plurals, and does not define their behaviour in any way.
2. We really need the selection logic text in the spec to align our language around selection.

@aphillips:
For error cases (and this might be on topic here??) perhaps we should add an optional else to the syntax (to allow the developer to override the default error handling):

match {$count :plural}
when =0 {You have no new messages}
when one {You have {$count} new message}
when * {You have {$count} new messages}
else {Message count not available}

Alternatively, we could make the when * selector optional, if we know that the variants before it are exhaustive, and in that case consider it to be the error-handling case. For instance, if via the function registry we can determine that when one and when other together account for all the valid choices in the source language, then we know that the when * variant will only be reached when some failure has occurred, and it's fulfilling the role of else as presented above.

@macchiati:
The 'other' case is special in the plural rules, in that it encompasses all numbers that don't match the other categories, and always occurs in every locale. So the problem lies in that if a programmer ever writes the following, m3 will never appear.

when one male {m1}
when other * {m2}
when * * {m3}

What if the source language is Polish, which uses other for fractional numbers and many as the common fallback category?

Moreover, our translation software has to know what the plural categories are and how they work, because otherwise it can't flesh out the appropriate cases for each locale, for them to be translated. So it will know that Arabic, for example, will need 6 plural categories, not just the 2 for English. And some other languages will only have 'other'.

The same would be true for other selectors, like grammatical case, that have to be expanded (or contracted) depending on the software. So while the MF2.0 spec in theory doesn't need to treat these specially, any non-trivial translation pipeline will need to.

Agreed. This is why the definition of the function registry is important, as it needs to be able to provide the data needed by said translation software.

[eemeli]

A second thread of related conversation from #320:

---

Originally posted by @aphillips in #320 (comment):

This is better normative language, but leaves open what happens if (for example) there is no catch-all.

We should probably have a name for the catch-all, such as "default"

I'm not sure I agree with the intent, since it does not allow the selector to do anything except select *, even when the error is otherwise recoverable. The example I gave in our call was a plural selector with an unselected typo, e.g.:

match {$myValue :number}
when 0 {Nope, no wildebeest here}
when one {You have {$myValue} wildebeest}
when fwe {You have {$myValue} wildebeest} // "few" is misspelled
when many {You have {$myValue} many wildebeest}
when * {My you have a lot of wildebeest!}

There's an argument to be made that this selector is toast since you can't be sure that the selection will do the right thing.

Perhaps what we should do (at least for now) is say something like:

When an error occurs within a Selector, the Selector must return a valid message. Selectors may define specific error handling behavior. Returning the default value (*) is recommended

Side note: we should start to be careful with our 2119 keyword usage, because these become conformance criteria.

---

Originally posted by @eemeli in #320 (comment):

It sounds like this is really about the dual role played by the * variant, as it's covering a specific case as well as being a fallback. To cover that concern, we do still allow for e.g. other to still be used as a keyword. Altering a bit your example above to do that:

match {$myValue :number}
when 0 {Nope, no wildebeest here}
when one {You have {$myValue} wildebeest}
when fwe {You have {$myValue} wildebeest} // "few" is misspelled
when many {You have {$myValue} many wildebeest}
when other {My you have a lot of wildebeest!}
when * {Your wildebeest count: {$myValue}}

In most cases, that's probably overkill, but we do allow for it in the spec by falling back to * if we don't know any better.

I would presume that that message should raise a validation error during some build step, but during formatting/runtime it would not be considered an error for any numeric $myValue.

---

Originally posted by @aphillips in #320 (comment):

My first reaction is that it would be a parse error, but actually, that would require MessageFormatter to understand what the selector expects/produces. fwe is syntactically valid and a different selector (say the old SelectFormat) might match/produce a result against the "typo" that plural doesn't.

I'm not wild about having both other and *. We're making this complicated to write for developers and harder to understand for human translators. Your illustration of the difference is very good, though.

---

Originally posted by @mihnita in #320 (comment):

we do still allow for e.g. other

I don't think this is allowed.

The keys are either strings that are matched "as is" (like select in MF1), or special keywords that are function specific. And those would be defined in the function registry.

So other is allowed, but it does not have any special meaning (like catch all)

I would expect that the registration of plural and ordinal will allow for zero, one, two, few, many. But not other, the * will play that role.

---

Originally posted by @stasm in #320 (comment):

I would expect that the registration of plural and ordinal will allow for zero, one, two, few, many. But not other, the * will play that role.

In some Slavic languages other is used specifically for fractions, and thus is not suitable to be used as a generic fallback, which AFAIUI should be grammatically correct for any value of the number.

---

Originally posted by @aphillips in #320 (comment):

other is overloaded for those languages--it is the fallback, but it was also assigned a grammatical purpose (as a workaround). In those languages, one of the defined keywords other than other captures all of the integer cases. In the current Intl.PluralRules and Java/ICU implementation, if the pattern isn't localized into the language (or the localizers forget a keyword), the other rule captures values that would match few, many and so forth.

We could allow separate generic (*) fallback and a defined keyword fallback (other) at the cost of having to modify existing implementation. Would developers and translators understand what to do?

---

Originally posted by @macchiati in #320 (comment):

Yes, the 'other' category serves two roles, and it is not the most neutral
one for some languages, due to misunderstandings about the nature of the
rules back when they were first derived in consultation with the native
speakers. The plural rules are spec'ed such that 'other' is the ultimate
fallback (whatever its semantics), and unfortunately it would be far too
disruptive to change the rules for those languages at this point. (There is
a already a CLDR ticket to add extra information.)

The main purpose for 'other' as fallback is when a new category is added.
It works best when the new category is 'carved out' of the other category.
For example, if 'many' is added, then an old translation still works
(though not optimally). In the message below, 'many' falls back to the
message variant Mc.
[one] Ma
[two] Mb
[other] Mc

It would be possible to use it to reduce the data size, but that was a side
effect, not a goal. Eg with the following the '[two]' variant can be
removed.
[one] Ma
[two] Mc
[other] Mc

With MF2.0 the selection logic is a bit different — with the selections all
combined — and on reflection I think it does make sense to have both * and
other. The last case below would match [female one] and so on, ie, any
combination that doesn't match otherwise.
[male one]
[female other]
[* *]

When you do have the case where all the selection values are already
covered, eg for English:
[one] Ma
[other] Mb
[*] Mc

Then the last message would never be reached.

[zbraniecki]

My first reaction is that it would be a parse error,

I think it should be possible for CAT tools to retrieve meta information about functions and recognize that plural has a closed set of allowed categories and fwe is not one of them - then it can warn about the mistake. (I wouldn't make it a parse or runtime error).

Separately, there's a concern I have about the examples we use in this conversation.

match {$myValue :number}
when 0 {Nope, no wildebeest here}
when one {You have {$myValue} wildebeest}
when fwe {You have {$myValue} wildebeest} // "few" is misspelled
when many {You have {$myValue} many wildebeest}
when * {My you have a lot of wildebeest!}

The above example (taken from Eeemli comment above) uses three different sentence structures - one for zero, one for countable number, and one for uncountable.
It may seem like a nuance, but I think we do it all a lot as we discuss the selectors and I think the best practice is to not do that.

In other words, "You have a lot of wildbeest" is not a variant of "You have { $count } many wildbeest" - it is a separate, different, sentence. Same goes for "You have no wildbeest".

The pattern of such use of selector is something we noticed engineers try to do with Fluent a lot, and we worked hard to decompose the plural selector from parametrized-meta-message (term I coined just now to label the flawed concept).
Let's analyze a different scenario of such abuse:

match {$sessionCount :number}
when 0 {Create an account}
when * {Log in to your account}

This is an extreme, but we encountered cases like this. What happens here is that the developer is attracted to cluster two separate messages under a single localization id contract and parametrize it based on a variable.

The concept feels very very similar to the plural case so it's easy to understand why people would be confused. Especially that often for plural cases developers want to have a different message for when the value of a variable is zero.

But in principle, from the architectural perspective, I want to make a strong case that those two scenarios are very different, and I would be excited if we managed to make this distinction better noticable by encouraging proper use and discouraging improper.

To help myself evaluate which scenario I have in mind I use a litmus test - in a language without plurals, would I still want to have those two variants?
Let's examine the following example:

match {$emailCount :number}
when 0 {You have no emails}
when one {You have {$emailCount} unread email}
when * {You have {$emailCount} unread emails}

In a language without grammatical feature of plural rules I would still want to have a selector here, just for:

match {$emailCount :number}
when 0 {You have no emails}
when * {You have {$emailCount} unread emails} // In this language this variant fits all possible values of $emailCount

That's a warning sign! I am not really using the selector to correctly build grammatical forms of a single message, I am clustering two messages - one for 0 and a different one for all other values - and the latter one requires plural rules.

Instead, I believe we should have two messages here:

email-notice-none = You have no emails

email-notice-some =
    match {$emailCount :number}
    when one {You have {$emailCount} unread email}
    when * {You have {$emailCount} unread emails}

and then in a language without plurals, I'd write

email-notice-none = You have no emails

email-notice-some = You have {$emailCount} unread emails

I think it is even more visible when we consider a different grammatical feature, one that doesn't exist in English.

The reason developers are abusing selectors is because from their perspective it is convenient to create a single localization id contract for the UI element, bind it, and then control which message is displayed by the same variable as the message itself uses to select its variant.

This brings me back to #118 although in a slightly different formulation. Instead of focusing on multi-message UI elements, we can discuss multi-variant UI elements (do not confuse with multi-variant messages) - which are elements that may have multiple messages depending on a variable.

A common example is a button that, when abuses l10n selectors, has the following message:

log-in-out-button =
    match {$sessionSet}
    when True {Log In}
    when False {Log out}

We saw it in Firefox many times for the reasons I laid out above.

My conclusion is that we should try to provide support for good developer experience for such scenarios and make it architecturally separate from selectors.
I assume that such solution would be implemented on the bindings level, but I also assume that some aspects of either MF2 or MessageResource standard may help design the solution so that bindings can operate on the groups of messages that are selectively used by a single UI element easy to recognize.
(for example, some meta-information could be useful for a localizer to know that those 2-3-4 messages are displayed interchangeably in a single UI element depending on a state of some variable).

[zbraniecki]

Now, with my previous separation in mind, I think it'll be easier to discuss other vs *.

We have two concepts here:

1. We want to allow for a variant that encapsulates "everything not specified before" (catch-all)
2. We want to allow for a variant that encapsulates "use this variant in case of a problem" (error scenario)

In previous conversations we concluded that in many cases those two use cases are effectively the same and the same variant is the correct one for both.
What I felt we did not agree on is that in some cases a different variant is correct for those two cases.

I am not yet confident, but I start to suspect that the only cases where those two scenarios are not using the same variant are when the message is conflating the two concepts I described above.
In other words, where it should be two or three messages.

@aphillips also brought up this example:

match {$count :plural}
when =0 {You have no new messages}
when one {You have {$count} new message}
when * {You have {$count} new messages}
else {Message count not available}

I consider this to be an anti-pattern. The else variant conveys less meaning to the reader than partially resolved variant one and *. As I stated above, I believe that variant =0 should be a separate message.

Variant else cannot be a separate message because in @aphillips model it is to be useful only if a message cannot be resolved. In theory we could design the API so that it can fail, and then ask bindings to react to failure by loading a different message which would be the one that now is in the else case.
But I think this is unnecessary.

From the perspective of end user Message count is not available is a pleasant UI but a bad UX. It communicates nothing. You have { $count } new messages - unresolved - communicates something. A reader can deduct that there are some new messages, and we just don't know how many.

Therefore I suggest that this should be:

msg-count { // imaginary message group associated with an UI element
  zero = You have no new messages
  some =
    match {$count :plural}
    when one {You have {$count} new message}
    when * {You have {$count} new messages} // variant used for catch-all and error scenario
}

[eemeli]

I rather like the none/some distinction that @zbraniecki makes above, esp. for cases like

match {$sessionCount :number}
when 0 {Create an account}
when * {Log in to your account}

where it's clear that this ought to be two different messages.

I'm not convinced, however, that categorically splitting off a "none" message always makes sense. For instance, I would keep something like this together as one message:

match {$count :number maximumFractionDigits=0}
when 0 {You have no new messages}
when 1 {You have one new message}
when * {You have {$count} new messages}

Here, the shape and role of the formatted message can be considered independent of the $count, with 0 and 1 values it's just formatted a little differently.

One interesting question raised by this sort of none/some distinction or explicit 0 and 1 cases is how to take something like the second example above, and to determine what categories to generate from that to a translator working in Arabic or Latvian.

Arabic plural categories includes zero with a rule n = 0 and one with a rule n = 1, plus four others. Can we detect the exact match of the English 0 and Arabic zero, and the English 1 and Arabic one, and just use those: zero, one, ..., *.

Latvian includes zero for n % 10 = 0 and some other cases, one for n % 10 = 1 and some other cases, plus other. Can we detect that the English 0 is a subset of the Latvian zero, and similarly 1 of one, and present the translator with five entries to fill: 0, 1, zero, one, and *?

Then, considering the slightly more generic case, could/should we allow for conditions like "$count is always a positive integer and at least 2" to be expressible in a useful form? In many locales, that would allow for a message depending on $count to avoid a selector altogether, while still requiring it in some.

And finally, that then brings back the question of allowing for some separation of specifically wanting to format the message in the other category vs. using a fallback * variant: What should happen if we allow for a condition as above to be used for translation, but that's then violated at runtime? Do we really need to duplicate the logic in the message as well as the calling code, or could we use something like this?

let $int = {$count :integer min=2}
match {$int}
when other {You have {$int} new messages}
when * {New message count: {$count}}

Here, :integer is matching other if its argument $count fulfills its expectations, and formats as an integer. But if $count is something else like 1, the * variant gets selected instead, and the raw value is used in the formatting.

[aphillips]

There is and always has been a difference between explicit values (0, 1, 42) and named values (zero, one, two, few, many, and other) in plurals. The values 0 and zero can co-exist in a message pattern because they can fire for different reasons. The value 0 supersedes zero when both match. This allows one to write messages where the named rule fires for various values and special messages fire for specific (explicit) values.

When I teach developers to write plurals, I always start with =0, one, other in English and then explain why =0 is special. I generally chide developers not to write when one {You have one message} (or even when 1 {You have one message}) but rather to write when one {You have {$int} message} and then write a custom message for the value 1 if-and-only-if it is needed, e.g. when 1 {You have only one chance remaining before you are locked out of the system}

Mark calls out that it would be effectively impossible to change the use of other in plurals at this point in time and note that Intl.PluralRules already exposes other (but not *) as well. I can see other and * being distinct in some cases, but I don't want to force developers to have to write English source resources like:

match {$int}
when 0 {You have no messages}
when one {You have {$int} message}
when other {You have {$int} messages}
when * {You have {$int} messages}  // there is no reason to go subject:predicate here; this can never fire anyway

[macchiati]

I firmly agree with Addision on the semantic and usage difference between 1 and one, etc.

I agree with Zibi in that overloading plurals for completely different messages is a complete misuse. But "you have no books" and "you have 0 books" are not a misuse. They are simply alternative expressions with essentially the same semantics.

In any event, the way plural categories work is really out of scope for this group.

As to Addison's other note:

…I don't want to force developers to have to write English source resources like:
…

I agree that it would be better for users to not require [when *] in that case, because that is purely redundant message variant, because 'other' is defined by the selector to be a 'catch all'.

If a selector doesn't have such a catch-all, then * should be required. For example, take a basic unbounded string selector for match {$someString}
when tom { ...}
when harry { ...}
when * { ...} // gets invoked when none of the other cases trigger

I think we could handle Addison's scenario with something like the following rules (terminology can of course be changed)

1. Each Selector may declare a catch-all value. That value must be stable over time. [Example, 'other' for the plural selector]
2. To be well-formed, a message must have a selection condition that matches every possible input. [call that an catch-all condition]

Condition #2 is satisfied by a condition with all asterisks, such as [when * ... *], or a condition where any of those * values are replaced by the catch-all value for its selector. Example: suppose we have two selectors

match {$foo :number} {$fii :string}

A sufficient catch-all selection condition would be either
when other * {...}
or
when * * {...}

[eemeli]

Example: suppose we have two selectors

match {$foo :number} {$fii :string}

A sufficient catch-all selection condition would be either
when other * {...}
or
when * * {...}

The current syntax spec requires that "At least one variant's keys must all be equal to the catch-all key (*)."

Do we want to consider relaxing this to allow for when other * to act as a similar fallback guarantor? As we've rather studiously avoided any special-casing at this level for numbers/plurals, the form of the spec language would probably be something like allowing for a function registry entry to define a list of keys that exhaust the possible options, i.e. [ 'other' ] for plurals or [ 'true', 'false' ] for booleans.

To give another example, I would think that allowing for the above with plurals would also make it possible for something like this to be valid:

match {$open :boolean}
when true {The door is open.}
when false {The door is closed.}

I think I'd be ok with this?

[aphillips]

Do we want to consider relaxing this to allow for when other * to act as a similar fallback guarantor? As we've rather studiously avoided any special-casing at this level for numbers/plurals, the form of the spec language would probably be something like allowing for a function registry entry to define a list of keys that exhaust the possible options, i.e. [ 'other' ] for plurals or [ 'true', 'false' ] for booleans.

I think we do not want to relax this for the reason you give: it requires internal knowledge of each and every Selector's behavior. It will make tooling complicated and pattern validation potentially less portable. Note that this was my argument for making other the * keyword originally (not because we love it but because of backwards compatibility). Revisit?

[duerst]

Do we want to consider relaxing this to allow for when other * to act as a similar fallback guarantor? As we've rather studiously avoided any special-casing at this level for numbers/plurals, the form of the spec language would probably be something like allowing for a function registry entry to define a list of keys that exhaust the possible options, i.e. [ 'other' ] for plurals or [ 'true', 'false' ] for booleans.

I think we do not want to relax this for the reason you give: it requires internal knowledge of each and every Selector's behavior. It will make tooling complicated and pattern validation potentially less portable. Note that this was my argument for making other the * keyword originally (not because we love it but because of backwards compatibility). Revisit?

There may be an additional consideration here: In some programming languages (e.g. Java), you can guarantee that you only get a boolean. But in others (JavaScript, Ruby,...), the programming language can't guarantee it,

[duerst]

Mark wrote:

I agree with Zibi in that overloading plurals for completely different messages is a complete misuse. But "you have no books" and "you have 0 books" are not a misuse. They are simply alternative expressions with essentially the same semantics.

I fully agree. There may also be the point that selectors without a 0/zero alternative may raise concerns somewhere in the localization flow, around quality control. It may be difficult to check whether a 0 case cannot exist at all, whether it's covered in a totally separate message, or whether it got forgotten or lost.

[The fact that 0 often looks slightly different ("no",...) can be attributed to the fact that most languages got into contact with the 0 in positional number notation rather late, and probably saw the use of a freestanding 0 (as opposed to 0 in larger numbers such as 1024 and so) even later. Also, in many languages, it's usual to write e.g. numbers up to 10 in words in the middle of a sentence. At least that's what I was thought in grade school. Using numerals starting from 1 probably came up with computers.]

[macchiati]

👍

…

On Wed, Jan 25, 2023, 12:14 Eemeli Aro ***@***.***> wrote: Example: suppose we have two selectors match {$foo :number} {$fii :string} A sufficient catch-all selection condition would be either when other * {...} *or* when * * {...} The current syntax spec requires <https://github.com/unicode-org/message-format-wg/blob/main/spec/syntax.md#variants> that "At least one variant's keys must all be equal to the catch-all key ( *)." Do we want to consider relaxing this to allow for when other * to act as a similar fallback guarantor? As we've rather studiously avoided any special-casing at this level for numbers/plurals, the form of the spec language would probably be something like allowing for a function registry entry to define a list of keys that exhaust the possible options, i.e. [ 'other' ] for plurals or [ 'true', 'false' ] for booleans. To give another example, I would think that allowing for the above with plurals would also make it possible for something like this to be valid: match {$open :boolean} when true {The door is open.} when false {The door is closed.} I think I'd be ok with this? — Reply to this email directly, view it on GitHub <#322 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMEY5CW2MNZ5YKQ66L3WUGCRHANCNFSM6AAAAAATQYQFKA> . You are receiving this because you were mentioned.Message ID: <unicode-org/message-format-wg/repo-discussions/322/comments/4781449@ github.com>