Nested Selectors Sub-Group proposal

[zbraniecki]

Our exploration of data model ramifications led our Work Group to a strongly visible realization on challenges and tradeoffs around nested vs top level selectors.

The main arguments for disallowing nested selectors seem to be around complexity of such feature, and interoperability with existing localization tooling and vendor ecosystems.
The main arguments for allowing nested selectors seem to be around flexibility, support for complex scenarios and future-opportunities.

Mihai and I brainstormed how to move forward with recognition of that status.
Mihai wrote about avenues forward here: #103 (comment)

From my understanding (2) is what Mihai sides with, while (3) is where I see myself.

From this brainstorm came the following suggestion:

We (Mihai and Zibi) suggest forming an informal sub-group of MessageFormat 2.0 Work Group devoted to the exploration of a Nested Selection data model on top of the work performed by MF2.0 WG.

Such sub-group would be tasked with continuous monitoring of the work the main Work Group is doing for easy inclusion of the nested selectors.

The group would in result validate two hypothesis:

• Algorithmic conversion from nested to top level is possible and doesn’t bring limitations that would make such conversion lossy
• The output of MF2.0 Work Group can be extended to support nested selectors (in other words, no data model, API or syntax decision implicitly blocked nested selectors to be possible to be added)

In particular (2) is crucial here. The sub group would inform the MF2.0 WG on the consequences of the various decisions on ability to add nested selection. If the sub-group were to come to the main Work Group and notify us on such consequence, MF2.0 WG would still be free to make such a decision, but it would be an informed decision, rather than implicit lock-in.

If successful, the result of the sub-group work would be:

• A set of tools, APIs, data model, and syntax that extends MF 2.0 output to support nested selection
• Recommendation on auxiliary features and facets of features that would be valuable for nested selectors (meta information, syntax decisions, format algorithms etc.)
• If the WG will over time decide that nested selection is the right call, the sub-group’s work should make such extension smooth
• Alternatively, as the WG work progresses, the sub-group may come to main WG with a conclusion that nested selectors are no longer necessary as all the needs of nested selectors stakeholders have been met with the feature set of MF 2.0 proposal
• Finally, if we release MF2.0 without nested selection, but later the industry were to eventually decide to add nested selection, it would be MF 2.1, rather than MF 3.0 level of change.

In all scenarios, the nested selector sub-group would inform the main Work Group and secure the future extension for MF based on the perceived need, and validate hypotheses around it.

In practice, it would free the main Work Group to rely on the sub group to prevent unexpectedly blocking ourselves from being able to add nested selectors, while allowing the work to result in something that can easily be extended to support nested selection if the claim strengthens over time, or not, if the claim weakens.

How does it sound to you?

[mihnita]

LGTM.
I think this is an excellent summary.
Zibi managed to accurately capture the gist of our one hour meeting, thank you!

[ray007]

I find the word "nesting" here quite confusing.
Nesting for me means one group within another, not several sequential groups one after the other.

[zbraniecki]

Nesting for me means one group within another, not several sequential groups one after the other.

Correct. And that's the term I intended to use here.

When talking about this subjected, in the past, we used three types of examples:

• Internal selector

key =  Here is { SELECTOR()  ->
  [variant1] rest of the sentence.
 *[variant2] another variant of the rest of the sentence.
}

• Multiple internal selectors

key =  Here is { SELECTOR()  ->
   [variant1] something
 *[variant2] something else
} and yet another { SELECTOR() ->
   [variant1] something.
  *[variant2] something else.
}

• Nested selector

key =  Here is { SELECTOR()  ->
   [variant1] part of the sentence which { SELECTOR() ->
        [variant1] depends
       *[variant2] doesn't depend
     } on a nested selector.
 *[variant2] something else
}

but internally, all three depend on the same addition to the data model - placeholder can be a selector.

[eemeli]

As an observation, here's how the above example messages could be expressed using message-level selectors and message references, using some made-up syntax that's hopefully clear enough:

• Internal selector

key = SELECTOR() ->
  [variant1] Here is rest of the sentence.
 *[variant2] Here is another variant of the rest of the sentence.

• Multiple internal selectors

key = Here is { REF(foo) } and yet another { REF(foo) }
foo = SELECTOR() ->
  [variant1] something
 *[variant2] something else

• Nested selector

key = SELECTOR() ->
  [variant1] Here is part of the sentence which { REF(foo) } on a nested selector.
 *[variant2] Here is something else
foo = SELECTOR() ->
  [variant1] depends
 *[variant2] doesn't depend

And that, to me, suggests that the case for internal or nested selectors in the data model needs to be particularly strong, should we also support message-level selectors and references: those features allow for a simple, lossless 1:1 mapping with internal and nested selectors when converting to or from e.g. syntax that supports them.

[DavidFatDavidF]

I second @eemeli
The example use cases seem to be covered by message referencing alright

Technically:

We don't want all the flexibility that internal selectors bring. We only want to be as flexible as to guarantee translatability.

1. External selectors only guarantee translatability
2. Message referencing is better than silent unmanaged concatenation. With some best practices (such as that only complete messages should be references) can be made to guarantee translatability.
3. Internal selectors allow for non-translatable (non-translatable=impossible to create a grammatically correct target message in languages of certain morphological complexity) constructs. We likely won't be able to express such constructs using 1. To express such constructs using 2. should be if not impossible/forbidden, then inadvisable and discouraged (by linters or similar). 

Organizationally:

I don't think this issue warrants creating more organizational structure. If some people such as @zbraniecki want to informally assign themselves as extensibility watchdog, let them do it. I think this can be managed as an open issue. But I'd oppose creation of a standing subgroup that would potentially have some sort of veto power WRT the parent group.