Support conditional spans of text

[grhoten]

Is your feature request related to a problem? Please describe.
There should be a generic way to handle conditionals. When getting words into grammatical agreement, word choice can depend on the grammatical properties and values of other words.

Issue #21 goes into a discussion about ranges that is similar to ICU ChoiceFormat. It seems like shorthand to needing a more complete conditional handling. Issue #31 goes into detecting grammatical category values (grammemes), but you need to act upon a given value. A translator may need to choose a different verb or adjective depending on the noun inserted into a message.

Describe the solution you'd like
I'll try to avoid using the XML or UEL syntax that I'm used to using in the solution description. I'll just state what should be considered.

• "if then {show span}". An alternative is to have a span of text just have a condition for being shown.
• "if then {show span} else {show other span}". An alternative is to have a list of text spans, and each span that has a condition on it. The first span that has a conditional that evaluates to true is chosen, and there must be a default span at the end. The alternative would be easier for else-if statements.
• The <, >, <=, >=, == (not assignment), !=, && (and), || (or) should be supported
• Comparisons should be against numbers and strings. Though perhaps it's best to just do equals for strings so that you can compare against the gender, grammatical number or other grammatical category values of the string.
• Switch statements so that you can compare against masculine, feminine, neuter, and unknown. ICU gender format isn't generic enough.
• If a variable is null or invalid, a span of text is omitted.
• If a span of text is chosen to be shown, allow it to be detected as being selected to allow for grammatical agreement later in a sentence. This is helpful for split verbs, which have been known to be used for German and Cantonese.

Describe why your solution should shape the standard
This is a way to get words to agree with each other. The several message formatting options from ICU don't have the same syntax. It would be better if it were consistent for handling conditionals to ease the learning curve.

Additional context or examples
#21
ICU ChoiceFormat
ICU PluralFormat
ICU GenderFormat

[Fleker]

I recently learned about Google's Common Expression Language spec which has a number of comparison behaviors based around the input being an expression as a string.

Would it make sense to design this syntax to provide a list of potential messages and their conditions, and then pick the first one that meets the criteria?

{{ conditional <-
  {{ "gender == masculine" <- "Masculine" }}
  {{ "gender == feminine" <- "Feminine" }}
  {{ "Unknown" }}  ( No conditional makes this the default )
}}

I would also want to make sure the input types for these conditionals can be dynamically defined by the application, ie.

{{ conditional <-
  {{ "weather.temp < 0" <- "Brr it is cold" }}
  {{ "It is not cold" }}
}}

[grhoten]

@Fleker yeah that's the basic concept. Though I'm more familiar with UEL syntax or just XML syntax.

[Fleker]

I just made up the syntax, mainly to capture the spirit of the idea and certain requirements like handling application-specific structured data.

[mihnita]

I really don't think that we should try to stay away from converting this into a "Turing complete language"

Yes, it's powerful, and (as developers) was all like that.
But I can promise you that no translation tool will support this properly, and no translator will be able to use it :-)

If XLIFF is not well supported, the chances for this being supported are slim to none...

[aphillips]

Translating this issue into the current state of MFv2 (and asking for @grhoten to correct me if I'm wrong), I think this is a request to add some selector functions to the registry beyond simple string equality, for example:

:lt for "less-than", :gt for "greater-than", etc.

Most of this issue appears to be have been addressed by the creation of the match statement, but the functions provided by the default registry is a current topic.

[aphillips]

As mentioned in today's telecon (2023-09-18), closing old requirements issues.