Variants: should variant keys be delimited, too?

[mihnita]

[mihnita]

Comments migrated from the slides

---

Slides comment, Addison Phillips (@aphillips), 8:21 AM Apr 21

I agree with the bullet points below. I think those issues make this close to a non-starter for me. The problems with whitespace management and getting translators/tools to do the right things here seem like a huge distraction.

Question: is there a reason not to delimit both keys and patterns? In my prototype I delimit keys with [ ] and patterns with double-quotes (i.e. traditional string syntax). Maybe that's too much markup, but maybe we can find a balance?

---

Slides comment, Eemeli Aro (@eemeli), 9:29 AM Apr 21

Too much markup is the reason we didn't consider this to any great extent: Once one of the two is delimited, the other one doesn't need to be. We are not proposing "quotes" as delimiters as our sense is that they're even more common than [brackets], leading to even more escaping. Also, many container formats (such as JSON) use "quotes" as their own value delimiters, meaning that the in-message quotes would themselves need to be escaped.

As with all things MF2, everything is of course still possible. If/once we pick one of the options given here as a starting point, it should become much easier to talk about individual fixes/improvements to that.

---

Slides comment, Elango Cheran (@echeran), 12:53 PM Apr 21

+1 to Addison's question about delimiting both keys and patterns in a selection message.

[echeran]

Related to #257

[markusicu]

In a message with selectors, there are basically

• variable definitions
• selector specifications
• key-pattern pairs where the key is a list of selection literals

There can be multiple selectors.

It should be visually obvious what's what. Therefore, the list of selector specifications should be delimited, as should be each list of key literals. For such lists, developers will find [] not too surprising.

Inside a list of key literals, each literal may or may not need delimiters. We should allow literals with spaces, which means that we need to at least allow delimited key literals. And assuming that the literals are space-separated, it would be best to use per-literal delimiters that visually show the start & end of each literal. Between that and trying to avoid <>'" I think the best choice is [(ab c) (d ef) (g h)].

[stasm]

Do we need delimiters enclosing each/some of the components that @markusicu listed, or perhaps separators between them?

Let's consider the following message written in the current develop syntax:

$hostName = {$host :person firstName=long}
{$host :gender} {$count :plural}
    female 1 [{$hostName} created her party of one.]
    female * [{$hostName} created her party of {$count}.]
    male 1 [{$hostName} created his party of one.]
    male * [{$hostName} created his party of {$count}.]
    * 1 [{$hostName} created their party of one.]
    * * [{$hostName} created their party of {$count}.]

@markusicu proposed the following syntax:

$hostName = {$host :person firstName=long}
[{$host :gender} {$count :plural}]
    [female 1] {{$hostName} created her party of one.}
    [female *] {{$hostName} created her party of {$count}.}
    [male 1] {{$hostName} created his party of one.}
    [male *] {{$hostName} created his party of {$count}.}
    [* 1] {{$hostName} created their party of one.}
    [* *] {{$hostName} created their party of {$count}.}

(#255 is tightly coupled with this issue, unfortunately.)

Would it help if we separated selectors and keys, rather than delimit them? For example:

$hostName = {$host :person firstName=long}
{$host :gender}?
{$count :plural}?
    = female 1 [{$hostName} created her party of one.]
    = female * [{$hostName} created her party of {$count}.]
    = male 1 [{$hostName} created his party of one.]
    = male * [{$hostName} created his party of {$count}.]
    = * 1 [{$hostName} created their party of one.]
    = * * [{$hostName} created their party of {$count}.]

[stasm]

Or perhaps even put the equals sign = in front of each variant key, except the catch-all *?

$hostName = {$host :person firstName=long}
{$host :gender}?
{$count :plural}?
    =female =1 [{$hostName} created her party of one.]
    =female * [{$hostName} created her party of {$count}.]
    =male =1 [{$hostName} created his party of one.]
    =male * [{$hostName} created his party of {$count}.]
    * =1 [{$hostName} created their party of one.]
    * * [{$hostName} created their party of {$count}.]

{$arg :func}? {$arg :func}?
    =(multiword key) =1 [An example of multiword keys]
    * =(another one) [...which require parens to delimit them]
    * * [The default variant]

[macchiati]

Separators feel more natural, eg:

{$host :gender}?
{$count :plural}?
female, 1 [{$hostName} created her party of one.]
female, * [{$hostName} created her party of {$count}.]

Perhaps even

{$host :gender}?
{$count :plural}?
female, 1, [{$hostName} created her party of one.]
female, *, [{$hostName} created her party of {$count}.]

If we wanted to make it more distinctive when single line, then a separator between keys+variant might be useful.

{$host :gender}? {$count :plural}? @ female, 1, [{$hostName} created her party of one.] @ female, *, [{$hostName} created her party of {$count}.]

[markusicu]

This seems to be expanding into multiple sub-questions...

• I find separator punctuation like the comma between multiple keys redundant, because we would likely allow white space following the comma, so then why not just use white space as the separator. Note that in the placeholder syntax we also just use white space, rather than the commas in ICU MessageFormat.
• Each single key needs to allow delimiters, so that a key literal can contain spaces and other syntax characters. It looks like we generally settled on (paren the ses) for delimiting literals.
• The syntax should be easy to parse by a program, as well as visually by a human. For these reasons, the compromise syntax proposes to enclose both selector lists and key lists in [square brackets]. @aphillips said that in his prototype he also encloses key lists in [square brackets].
• I do agree that there is some redundancy in delimiting both patterns and key lists. I just think it helps with clarity/readability.
• Lots of other things are possible but probably harder to parse or read.
• In particular, the question mark as a suffix is not good. It should be clear within a character or two whether we are looking at the first or last selector.
• I suppose you could have one token like ?? that starts a selector list, at the start of the message or after optional variable definitions. Not sure that that would be sufficiently clear and readable.
• Enclosing the [list of selectors] in one pair of delimiters makes it clear that they are one list/group, and are parallel with the key list in each variant. If we just had a per-selector syntax that said "this is a selector" then developers might be tempted to intermingle them with variable definitions.
• Of the alternatives I see, the one from Stas with one = sign starting each variant, instead of enclosing the variant's key list, might be ok. (The version with an = prefix for each key looks a bit too cluttered.)
• If there is no explicit syntax for ending a selector list (such as the ] of an enclosing pair), then there should definitely be some syntax ([ to start a key list or = to start a variant etc.) to clearly indicate the start of the first variant, or else we get ambiguous parsing of key literals.

[mihnita]

In particular, the question mark as a suffix is not good. It should be clear within a character or two whether we are looking at the first or last selector.

++100 to this.

Something at the start would be a lot more readable for the user (and probably easier to parse)

I would be fine with harder to parse if it makes life better for the human user.

As a human reading:

{? $foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4}
{? $bar :gender}

is friendlier than

{$foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4}?
{$bar :gender}?

In the first case I can instantly see "ah, two selectors!"
In the second case I have to scan to the end of possibly long, uneven lines, maybe with line breaks.

[macchiati]

I'm happy with the approach of syntax that groups the selectors together, and groups the keys together, such as: [selectors] [keyList1] {message} [keyList2] {message} ... I think it is quite clear what is going on. And for readability, the writer would always have the option to make a variable definition out of a long selector, eg $count = {$foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4} $gender = {$bar :gender} [$count $gender] [one female] {message-variant1} [one male] {message-variant2} [one *] {message-variant3} One could have different syntax for the selectors vs the keys for clarity, eg the following, but I'm not sure that is necessary. $count = {$foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4} $gender = {$bar :gender} [[$count $gender]] [one female] {message-variant1} [one male] {message-variant2} [one *] {message-variant3} I'm not fond of the postfix notation, because as Mihai notes, you have to read into the line to see what the role is. If people really couldn't live with a grouping notation like [...], a prefix notation would be better than a postfix notation. And I'm not fond of ?, because a lot of people will associate it with either regex notation or the conditional notations like x = a ? b : c; I could also live with a separator character before the selectors, and a separator character before each list of keys: either the same for each or different, eg. @ and : below (though I have no particular attachment to those two choices). $count = {$foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4} $gender = {$bar :gender} @$count $gender : one female{message-variant1} : one male{message-variant2} : one * {message-variant3} In the literal text in the message variants, we really need to minimize the number of characters that have to be escaped, and try to use syntax characters that are very infrequently used in real messages. So {, }, and \ are great. Outside of literal text in message variants, there is more freedom. But I'm happy with just going with Markus's suggestion for [...]

…

On Wed, Jun 8, 2022 at 4:32 PM Mihai Nita ***@***.***> wrote: In particular, the question mark as a suffix is not good. It should be clear within a character or two whether we are looking at the first or last selector. ++100 to this. Something at the start would be a lot more readable for the user (and probably easier to parse) I would be fine with harder to parse if it makes life better for the human user. As a human reading: {? $foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4} {? $bar :gender} is friendlier than {$foo :number offset=2 rounding=up minFractionalDigits=2 maxFractionalDigits=4}? {$bar :gender}? In the first case I can instantly see "ah, two selectors!" In the second case I have to scan to the end of possibly long, uneven lines, maybe with line breaks. — Reply to this email directly, view it on GitHub <#253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMDGQXMIESVHOLNAEQ3VOEURBANCNFSM5VWCWTSA> . You are receiving this because you commented.Message ID: ***@***.***>