External Selectors - Consensus Summary

[romulocintra]

Is your feature request related to a problem? Please describe.
In order to get consensus for External selectors we need a summarized text for all pros/cons and agreements we are getting the consensus. Having those ideias from last meeting the responsible for this tasks would prepare a concise paragraph/text/bullet points describing the context and decisions.

[romulocintra]

@stasm @zbraniecki friendly reminder for next meeting, we said that before we vote we would write down a short summary about the consensus. In any case will be added to the next meeting agenda

cc @echeran

[eemeli]

In case @stasm or @zbraniecki don't get around to it, here's a draft of the consensii that I believe we've reached on this topic:

---

Consensus 1:
Allow for selectors to select a case depending on the value of one or more input arguments.

Discussion:
This is a prerequisite for top-level selectors to be able to represent complex messages, without requiring those messages to be split up in an unergonomic manner. This is an extension or relaxation of what's allowed in MessageFromat 1.

While message references make it technically possible for the data model to represent multi-argument selectors otherwise, this requires the use of n²-1 artificial "messages", where n is the number of arguments. This is not desirable.

---

Consensus 2:
Only allow for selectors at the top level of a message.

Discussion:
Requiring selectors to only be available at the top level is a good way of helping to maintain the translatability of messages, as well as otherwise guiding MessageFormat 2 users towards good practices.

After an in-depth exploration of the problem space, we have determined that while selectors are a necessary feature of MessageFormat, it is not necessary for them to be available within the body of a message, or directly within a case of a parent selector.

All identified use cases of such constructions may be cleanly represented using a top-level selector that may use more than one input argument to select among a set of messages. Furthermore, we may enable complete reversibility of message transformations to and from languages such as MessageFormat 1 and Fluent by using message references.

[stasm]

Thanks, @eemeli, this looks great. @zbraniecki and I met on Friday to discuss this too, and Zibi then wrote down the following summary:

MessageFormat Work Group evaluated two possible approaches to message variant selection models:

• A top-level model ("external selector") in which a message may contain a single selector over multiple variants of the message value.
• A nested model ("internal selector") in which a value of the message may contain selectors as placeholders allowing for an arbitrary number of nested selectors in a single message.

After consideration the group concluded that the concepts of message references and message selectors are interconnected, and message references allow for encoding the same data as nested selectors.

Due to perceived complexity of the nested selector model, which would put significant burden on the quality assurance, tooling and pose a challenge for Translation Management Systems, the group decided to advance the top-level model together with message references feature. It is our belief that this model will allow for an equally complete set of features at lower complexity cost.

The group recognizes that the nested selection model may yet yield value that may justify the added complexity. In result the group will attempt to design the MessageFormat 2.0 standard with an intent to preserve an ability for the standard to be extended to support nested selection in future revisions.

I think Eemeli's proposal does a good job of capturing the actual points of agreement, while Zibi's is a good executive summary of the discussion we've had. I suggest we go with the wording proposed by Eemeli. It also explicitly mentions the ability to select on more than one input argument.

OTOH, I know that it was important for Zibi that we not ban internal selectors right away, in case of a change of heart in the future. I wonder -- is it generally implied that we're willing to revisit past decision in light of new arguments, or do you think it's worth calling this out here explicitly?

[zbraniecki]

I think that assumption that were willing to revisit a decision in the light of new evidence is implicit.

In this case my focus is different. I believe it is important to explicitly recognize that while we decided not to include nested selectors, we recognize that it is a big feature that provides significant potential value and since the use of it has not been sufficiently explored by any localization system we made our decision without ability to evaluate in-field experience and value of that feature.
At the same time this feature is easy to lock ourselves out of, which would be undesirable.
In result our decision should be reversible via a future extension and we as a group should put effort in trying not to lock the standard out of such future option.

I think this is substantially different from a regular "in light of new evidence we may revisit" in that:

*) It's not about us revisiting. It's about trying not to block some other work group in the future out of the ability to extend the result of our work with the feature
*) It communicates to future readers that we made our decision based on little in field experience and our position has been based on theoritcal cost analysis which led us to our conclusion. That's different from having past in field experience motivating us to reject a feature.
*) I'd like us to recognize that we will put effort to avoid locking the standard out of the future extension. In other words, i believe that when evaluating choices in the coming months, if one of the options results in blocking this feature, it should count toward other choices that don't block this feature to be added in the future.

I believe those points are significantly different from what you described.

[zbraniecki]

To illustrate my point with an example: i see this analogous to a scenario where CSS work group decides to not include variables in CSS 1.0 but recognizes the potential value and therefore documents an intent to try to design CSS 1.0 in such a way that would not block future addition of variables in following revisions.

[zbraniecki]

Draft of the follow-up consensuses:

Consensus 5:

Top Level Selectors together with Message References provides the same value as Nested Selectors at a lower cost.

Discussion:

Nested Selectors provides capabilities that may be useful in avoiding variant permutation explosion in edge cases, but the use of them has not been evaluated in production localization systems to date.
The group believes that the known value of this feature can be sufficiently covered by the combination of Message References and Top Level Selection features and together provide sufficient feature set at a lower cost to the ecosystem than Nested Selectors would do.

Consensus 6:

The group will attempt to avoid blocking addition of Nested Selectors in the future revisions of the standard.

Discussion:

The cost analysis of Nested Selectors feature was performed in the absence of the sufficient in-field experience of use in production systems. In result, the group's decision to reject the feature is based on the lack of sufficient known value that would require them, which the group recognizes may change in the future.
In result, it is the intent of the group to attempt to design Message Format 2.0 in such a way, that wouldn't block future revisions of the standard to be extended with Nested Selectors feature.