Discussion thread for code mode introducer

[aphillips]

This is where you can freely discuss technical issues related to the ballot in #525

[eemeli]

Out of interest, I went and looked at the frequencies with which the sigils suggested for Option D .~@&%# show up as first characters in the Mozilla and Android message corpuses, when followed by some a-z characters. Some observations:

• Full Stop U+002E . In Android, there are two messages in one file that do not include an initial . in English, but do in some translations start as .vcf. One other Android message also starts with .vcf in English.

• Tilde U+007E ~ No messages found starting with ~[a-z].

• Commercial At U+0040 @ Numerous hits for both Android and Mozilla. In the former, it's a special reference operator. In the latter, mostly in messages referring to CSS.

• Ampersand U+0026 & Numerous hits for both Android and Mozilla, mostly as it's an HTML/XML entity introducer.

• Percent Sign U+0025 % On both, numerous hits for the printf variables %s and %d in particular. When looking for % followed by at least two a-z characters, a few hits in both conjugating %s variables with suffices, mostly in Uzbek. Many hits in Mozilla due to some systems supporting %varname% placeholders. All instances are due to placeholder syntax, which is different in MF2.

• Number Sign U+0023 # Many hits on Android with RGB colors like #ffff00, and some on Mozilla for hashtags like #espacios-mozfest-2022.

So if going this way, I think . and ~ are the reasonable candidates to consider. @ shows up a bit too often, & is used for HTML entities, and % has rather established usage as a variable placeholder introducer. # is surprisingly common, and is used as a line comment introducer in too many host formats.

One negative for ~ is that on some keyboards (at least Italian) it's not necessarily directly available at all.

If we go with ., we may want to require escaping it only if it's followed by at least four a-z characters. This would avoid the likely most common conflict with .abc three-letter file extensions, while allowing later potential expansion of the supported commands beyond input/local/match.

[aphillips]

In #521 @macchiati made this comment, which I copy here for visibility and because I am closing that thread. Note that @duerst also made a comment about non-ASCII there, which I'm not moving over.

---

It seems to me that there is a higher-level breakdown, where 'special sequence' below is a sequence of one or more ASCII punctuation/symbol characters.

Alpha: mark the start of a complex message with a special sequence, and either the end of the declarations or the the end of the complex message with a special sequence (Option A, F)

Beta: mark the start of a complex message with a special sequence (Option B, C, E)

Gamma: mark start of each keyword that starts statements with a special sequence (Option D)

Personally, I don't think either Alpha or Gamma add much value; and the key to Beta is to pick a sequence that is distinctive, doesn't collide with any other sequence, and very unlikely to start a simple message (thus probably a multi character sequence of symbols instead of a single symbol.

• By the way, we'd have a lot more choices for these if we considered non-ASCII — §§ would be a nice separator.

[aphillips]

@macchiati I think that's one way one could break down the options.

I think your "Alpha" would be more succinctly put as: "enclose all or part of a complex message with a special sequence". There's nothing wrong with this (many many syntaxes feature enclosure--our own syntax encloses both patterns and expressions [placeholders] already). But my feeling here is that the enclosure is one layer too many.

My preference for "Gamma" (option D) is precisely that it adds nothing to the syntax. One has to learn the keywords anyway: ours are just spelled funny. It's easy to understand because there's only one concept.

I could be okay with "Beta", but the challenge (as Mark points out) is finding the right sequence. My concern would be that I don't see what the value is to the user with B/C/E (except, of course, that the message parses correctly). It's a piece of extra gunk that we require everyone to type in order to serve the parser.

@stasm Proposed option F, which is a preamble syntax, and he's expressed in teleconference (and elsewhere) that it's still underdeveloped as a proposal. I like the idea of having a conceptual model for messages that make it easier to manage the code and patterns. I also like the idea of getting rid of when.

On the other hand, I don't see how the preamble concept works by dividing match from the variant map. The unknown arity of match was cited as a reason to delimit the match statement, but with a LL(1) or LL(2) parser, we're not seeking the close marker and the key syntax does just as good a job of closing the arity. The expressions in a match are already chock full of sigils, so adding noise to that line feels painful:

{% match {$numUsers :plural} {$numDogs :plural} {$activity :select} %}  <- is this last token adding anything?
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

I think it's useful to spend time writing messages in a syntax to get a feel for it. Thinking about message in the abstract doesn't tell me much finger knowledge or "feel" of the syntax compared to trying to do different things.

[eemeli]

On the other hand, I don't see how the preamble concept works by dividing match from the variant map. The unknown arity of match was cited as a reason to delimit the match statement, but with a LL(1) or LL(2) parser, we're not seeking the close marker and the key syntax does just as good a job of closing the arity. The expressions in a match are already chock full of sigils, so adding noise to that line feels painful:

{% match {$numUsers :plural} {$numDogs :plural} {$activity :select} %}  <- is this last token adding anything?
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

My preference would be to use multiple match statements where they're necessary, with one selector per statement. That way, we could also drop the braces from the selector. Using a D-ish syntax, the message above could look like this:

.match $numUsers :plural
.match $numDogs :plural
.match $activity :select
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

A vast majority of messages with selectors will only ever have one selector; for those, this change would let us get rid of one {} pair. For messages with multiple selectors, this would make it clearer what is being matched.

[stasm]

Option F proposes to shift from thinking about match as a statement which continues onto the variants. Our current syntax is deeply rooted in this concept: it's a switch-case in disguise. I don't think it's bad at all, but I like that F introduces something new conceptually, and it's appealing to me.

I see F as a solution to the problem of having all this additional stuff that we want to decorate the message with. Selectors, input, locals... where do we put it all? We only have the message itself to work with, so it needs to be in-band.

Instead of solving this through nesting (text → code → text), F solves it with the preamble (text → code; text). The preamble is where we declare inputs, locals, and selectors.

It's a bit as if the message was a map with a semantic comment:

/*
 * @input $count :number
 * @match $count :plural
 */
{
   one: "One thing"
   default: "Many things"
}

---

On the other hand, I don't see how the preamble concept works by dividing match from the variant map. The unknown arity of match was cited as a reason to delimit the match statement, but with a LL(1) or LL(2) parser, we're not seeking the close marker and the key syntax does just as good a job of closing the arity.

You're right, parsers will do fine without an explicit closing delimiter for the preamble; that's how it works right now after all. I meant that the closing delimiter can help people understand how the message is structured.

On a related note, I'm not fond of the fact that both input and local have the arity of 1, but match has >1. I filed #527.

[stasm]

My first preference is for F, but I also see benefits to A which I'd like to make sure we don't omit.

The closing }} of A doesn't add value as long as we're only considering a single message. However, looking at the larger picture, the closing delimiter would be very useful for designing the resource format.

key-simple = A simple message
key-complex = {{
    input {$count :number}
    match {$count :plural}
    when one {{One thing}}
    when * {{Many things}}
}}
another-key = {{ {{Pattern}} }}

We'd need to figure out the exact syntax and whitespace handling for simple messages (perhaps wrap them in {{ ... }}, same as variant patterns?). This, in turn, would imply that we can't use {{ ... }} for message delimiters. We could look for a different double sigil, like {% ... %}, but I think that we could also win a lot by combining A with D:

key-simple = A simple message
key-complex = {
    .input {$count :number}
    .match {$count :plural}
    one {{One thing}}
    * {{Many things}}
}
another-key = { {{Pattern}} }

This way we could use a single brace, followed by a .keyword or a quoted pattern, as the code-mode introducer. Single curlies are universally recognized as block delimiters. Furthermore, the simple/complex duality is also a concept familiar to many developers. For example, JavaScript functions can be spelled as () => value or as function() { return value; }.

[eemeli]

The closing }} of A doesn't add value as long as we're only considering a single message. However, looking at the larger picture, the closing delimiter would be very useful for designing the resource format.

Actually, it's the other way around. Consider for instance this YAML representation of your example:

key-simple: A simple message
key-complex: '{{
    input {$count :number}
    match {$count :plural}
    when one {{One thing}}
    when * {{Many things}}
}}'
another-key: '{{ {{Pattern}} }}'

First of all, many such formats consider {} as mapping keys, in particular when it's used as the first character of a string: This is why the second and third messages need quotes.

Second, that's actually invalid YAML. Can you see the error?

[stasm]

First of all, many such formats consider {} as mapping keys, in particular when it's used as the first character of a string: This is why the second and third messages need quotes.

Can you give a few other examples, besides YAML?

Second, that's actually invalid YAML. Can you see the error?

I don't know YAML well enough to be good at parsing it visually.

[aphillips]

@stasm mentioned:

You're right, parsers will do fine without an explicit closing delimiter for the preamble; that's how it works right now after all. I meant that the closing delimiter can help people understand how the message is structured.

Totally. For me, people's "association" between match and the flock of variants is what is kind of important.

@eemeli suggested:

.match $numUsers :plural
.match $numDogs :plural
.match $activity :select
0 * * {{Nobody did anything with their dogs}}
* * * {{Everyone did everything with their dogs}}

What I don't like about this is that the match statements are laid out vertically while the keys are horizontal. It is also tempting to reorder the match statements, which would break the selector (significantly change its meaning)

I agree with @stasm that match is just a kind of switch/case statement (perhaps in a tuxedo??). I don't think that's a bad thing, in that the keys can be visually aligned with the selectors or are at least easily paired up

[eemeli]

First of all, many such formats consider {} as mapping keys, in particular when it's used as the first character of a string: This is why the second and third messages need quotes.

Can you give a few other examples, besides YAML?

At least some JSONC variants and Hjson will allow for some messages to go unquoted, but will require quotes if they start with {.

Second, that's actually invalid YAML. Can you see the error?

I don't know YAML well enough to be good at parsing it visually.

The error is that the last line of the key-complex value is not sufficiently indented. In a block-map, all lines of a value need to be at least one space more indented than their parent key. If our syntax ends up with {...} around it, this will make embedding MF2 messages in YAML a pretty bad experience because people have a natural tendency to align the closing brace with the same level of indentation.

This is effectively one of the corner-cases of YAML, and it will not be caught by all YAML processors. The way that e.g. the syntax highlighter here doesn't catch the error will make the experience even worse.

[gibson042]

Furthermore, the simple/complex duality is also a concept familiar to many developers. For example, JavaScript functions can be spelled as () => value or as function() { return value; }.

I consider this a bad pattern that should be avoided rather than emulated—even being familiar with it, I can't tell you how many times I've been burned when converting => val into => { key: val, key2: val2 } (which is invalid) or => { key: val } (which is valid but interprets key as labeling the expression statement val inside a brace-wrapped function body, producing an unintentional undefined result rather than a single-member object). Incidentally, this is illustrative of what I mean by "iteration hazard", and part of why I am uncomfortable with "simple message" as distinct from "complex message" (rather than being merely a degenerate case thereof).

[echeran]

Furthermore, the simple/complex duality is also a concept familiar to many developers. For example, JavaScript functions can be spelled as () => value or as function() { return value; }.

I consider this a bad pattern that should be avoided rather than emulated—even being familiar with it, I can't tell you how many times I've been burned when converting => val into => { key: val, key2: val2 } (which is invalid) or => { key: val } ... this is illustrative of what I mean by "iteration hazard" ...

I don't have as strong an intuition for the set of options for the question at hand, but the illustration of this point makes me elevate Option A to be an equal first choice because it allows one to write messages in a way that avoids that problem. I don't think Option F allows for a "simple message" pattern to be a degenerate subset of a "complex message".

Option D still seems like a good first choice since it strikes the best compromise for the new requirement set as of the last 2 months. The caveats of the escaping that it requires for a simple message are the narrowest.

@stasm

It's a bit as if the message was a map with a semantic comment:

/*
 * @input $count :number
 * @match $count :plural
 */
{
   one: "One thing"
   default: "Many things"
}

Oof. This example makes me shudder. I still think of our syntax as describing the input data to the API. I know we've made affordances for declarations, which I can rationalize as the "refactoring" of repetitive data, and it seems fine to me. I can still squint and look at it sideways and call it data. I don't want us going any further along the cliche of unwittingly recreating a Yet Another Micro Language.

If the /* ... *@key ... *@key ...*/ represents a map of info, then we can be concise by finding inspiration from data literal syntax. But I would prefer if we don't find inspiration from optional comment syntax in order to represent those declarations, which are necessary to understanding a message pattern. Definitely would be a footgun, even if built with good intentions.

[gibson042]

I don't have as strong an intuition for the set of options for the question at hand, but the illustration of this point makes me elevate Option A to be an equal first choice because it allows one to write messages in a way that avoids that problem. I don't think Option F allows for a "simple message" pattern to be a degenerate subset of a "complex message".

The thing is, none of the options allow for that.

(B) ^Use a sigil (C) ^^Use a double-sigil (E) {^} Use a magic sequence at the start

These options are fundamentally the same, and e.g. removing the prefix from a complex message results in dramatically different treatment of the remainder (such as interpreting input {$var} as a pattern rather than the declaration that it would be after the prefix).

(F) {% Use a preamble with %} {{Patterns to follow}} (D) Use keywords with the sigil . on the front, e.g. .input or .local

These options are slightly different, but suffer from the same flaw—consider {%input {$var} match {$var}%} when * {{Pattern}} (F) or .input {$var} when * {{Pattern}} (D) producing "Pattern" vs. when * {{Pattern}} (either F or D) producing something like "when * {{Pattern}}".

(A) {{Use pattern quotes for messages}}

Same issue again, with the added complexity that the result of unwrapping {{…}} isn't even guaranteed to be interpreted as a simple message because {{…}} is itself valid inside the doubled braces (e.g., {{{{Pattern}}}} is a complex message containing only a pattern representing "Pattern" while {{Pattern}} is an invalid complex message, and {{{{input {$var}}}}} is a complex message containing only a pattern representing "input …" while {{input {$var}}} is a possibly invalid complex message containing only an input declaration.

[stasm]

@gibson042:

I consider this a bad pattern that should be avoided rather than emulated—even being familiar with it, I can't tell you how many times I've been burned when converting => val into => { key: val, key2: val2 } (which is invalid) or => { key: val } (which is valid but interprets key as labeling the expression statement val inside a brace-wrapped function body, producing an unintentional undefined result rather than a single-member object). Incidentally, this is illustrative of what I mean by "iteration hazard", and part of why I am uncomfortable with "simple message" as distinct from "complex message" (rather than being merely a degenerate case thereof).

I didn't mean to trigger the discussion about simple messages with my original comment. I was only advocating for considering wrapping messages in single curly braces, in combination with dot-prefixed .keywords, as opposed to {{ }} or other syntax.

I agree that we should be mindful of iteration hazards of text-first mode. I filed #512 which I think would be a good place to continue this topic.

[stasm]

@echeran

Oof. This example makes me shudder. I still think of our syntax as describing the input data to the API. I know we've made affordances for declarations, which I can rationalize as the "refactoring" of repetitive data, and it seems fine to me. I can still squint and look at it sideways and call it data. I don't want us going any further along the cliche of unwittingly recreating a Yet Another Micro Language.

If the /* ... *@key ... *@key ...*/ represents a map of info, [...]

What I meant by "the message is a map with a semantic comment", was that it's a map of variant keys to variant patterns, and that declarations are extra metadata which describes how to handle this map. The actual data that we encode is the translation content; multiple patterns keyed on some CLDR categories for the most part.

[aphillips]

@gibson042

These options are slightly different, but suffer from the same flaw—consider {%input {$var} match {$var}%} when * {{Pattern}} (F) or .input {$var} when * {{Pattern}} (D) producing "Pattern" vs. when * {{Pattern}} (either F or D) producing something like "when * {{Pattern}}".

I don't understand this statement? The when * is part of the match statement. The selected pattern is "Pattern" in each of these instances, not "when {{Pattern}}". If I want a pattern that says `when {{Pattern}}, I have to escape the{{and}}` because that has special meaning.

These options (B/C/E) are fundamentally the same, and e.g. removing the prefix from a complex message results in dramatically different treatment of the remainder

That's correct: they are variations on the magic starter sigil theme and the difference between them is basically trying to find the right tension between the need to escape the starter sequence and the need for people to type an elaborate (and otherwise non-functional) starter.

--

I think your fundamental argument is that we should start in code mode? If so, I'm not sure that's very useful to a conversation about how to switch from (starting in) text mode to code mode.

If our syntax choice were different, we might have different choices here. But this is our syntax. If we don't like {{...}} around the whole message, we need to change it here and move on.

-- @stasm

I have the idea that there is something conceptually to "F", but I haven't seen a compelling and understandable syntax emerging from it. Ease of authoring and ease of understanding is maybe the most fundamental thing to me.

It occurs to me that the problem with (F) is that the enclosing gorp (as with (A)) does nothing except provide an opportunity for syntax errors. And it is conceptually hard for the average user because the match and when belong together. I think (D) actually can be your preamble if you write it without the permitted extra whitespace (particularly if we adopt your suggestion of making when into--yikes a sigil--square brackets):

.input {$var :foo option=bar}.match {$var}{$var}[[* *]] {{I am a lovely pattern.}}

Anyway, I took (F) out of my vote today because I don't see how to make it into a compact, clean syntax.

[gibson042]

I think your fundamental argument is that we should start in code mode?

No, my fundamental argument is that "simple message" should be a degenerate case of "complex message" (having no declarations or matcher) rather than a distinct grammar—and that can be achieved with a decision to start in code mode (e.g. by requiring patterns to always be quoted) or to start in text mode (e.g. with a sigil to indicate a declaration or match).

If so, I'm not sure that's very useful to a conversation about how to switch from (starting in) text mode to code mode.

Agreed, which is why I have not voted. But I felt it important to emphasize that no option on the ballot addresses this issue.

[stasm]

@aphillips:

And it is conceptually hard for the average user because the match and when belong together.

They feel like they belong together because we've been equating match...when with switch...case. We've looked at it for the past 1.5 years and got used to it. I got used to it as well, and to be fair, I don't think there's anything terribly wrong with it. However, my point with F is that this isn't the only way of thinking about variants, and that F may actually be better. If you start from patterns--which are the most important data in the message--and work your way up (patterns → keys → selectors), I think you'll agree that another way of thinking about a message is that it is a map of patterns. F attempts to make that more visible.

I think (D) actually can be your preamble if you write it without the permitted extra whitespace (particularly if we adopt your suggestion of making when into--yikes a sigil--square brackets):

.input {$var :foo option=bar}.match {$var}{$var}[[* *]] {{I am a lovely pattern.}}

I think the square brackets do help, but what's jarring to me about this example is that it looks like weird text, maybe some instruction that shouldn't even be sent for translation but accidentally was, but it doesn't (to me) look like part of the message's syntax. I think that the text-first mode comes with a promise: it's all text and always text, unless it's wrapped in brackets. B, C, and D (and E to some extent) break that promise.

---

This is why I've been thinking out loud whether it wouldn't be best to combine A and D:

{.input {$count :number} .match {$count :plural} * {{I am a lovely pattern.}}}

[aphillips]

@gibson042 noted:

No, my fundamental argument is that "simple message" should be a degenerate case of "complex message" (having no declarations or matcher) rather than a distinct grammar—and that can be achieved with a decision to start in code mode (e.g. by requiring patterns to always be quoted) or to start in text mode (e.g. with a sigil to indicate a declaration or match).

Starting in text mode with a sigil for declaration or match is option D, no? I mean, I see what you're saying, which is that you'd like to have unquoted patterns (so the degenerate form is a simple message), but isn't that the syntax decision we just made? That could only work if we quoted the variant keys, a la:

.match {$var} {$var}
[[one one]] {{I am a quoted pattern}}
[[* *]] I am an unquoted pattern with all of the trimming issues we previously faced

I think we either need to put changes like this out of scope ("disagree and commit") or recognize we have a kind of "failure mode" for this project.

FWIW, I did offer up the syntax choice in the UTW presentation after showing the whitespace trimming options including multiline. Sadly the recording of the presentation was somehow lost. But the result was effectively a 50/50 split of the room (people on this thread were in the room, so it's not just me saying that's what happened)

---

@stasm suggested:

This is why I've been thinking out loud whether it wouldn't be best to combine A and D:

What does the external decoration of {/} buy users? Notice that it is confusable with simple messages that start with a placeholder. You have to discard whitespace until you see . (code), $ (text mode variable), : (text mode function), { (quoting a pattern) or one of the private-use or reserved starts to know what the message is. If we go with Option A doubled {{ to avoid this, why not just embrace A (what does D add to it)?

[eemeli]

I have a request for people sharing complex message examples in this thread: The vast majority of real-world complex messages will only ever have one selector, with 2-3 variants. Unless there's a specific need to use a differently shaped complex message, could the examples used to determine the appearance of complex messages prefer that shape over others, so that we do not unduly favour edge cases in our decisionmaking?

[stasm]

@aphillips:

This is why I've been thinking out loud whether it wouldn't be best to combine A and D:

What does the external decoration of {/} buy users?

I'm uneasy about the bare .keywords. I tend to think that given the text-first mode, they look like, well, text. I'd be more comfortable with some wrapping somewhere to indicate that we're in code mode.

That said, I can see how and why .keywords work, as a sort of a procedural markup with control words. See SCRIPT and GML for reference :)

I acknowledge that the closing } in particular isn't very useful. I think most editors will probably handle it anyways (although perhaps not inside string literals?), so I'm not too worried about it. What I think it brings is the familiar mental model of simple vs. complex messages analogous to single statement vs. block of statements in many programming languages.

Notice that it is confusable with simple messages that start with a placeholder. You have to discard whitespace until you see . (code), $ (text mode variable), : (text mode function), { (quoting a pattern) or one of the private-use or reserved starts to know what the message is.

Yep, I'm not very happy about it, but it's all doable, and frankly, not all that worse than having to recognize \.[a-z]{4,} as a special non-text sequence?

I'm also not fond of the fact that A is sort of saying: in our text-first syntax, you can have a message that's effectively a single placeholder and nothing else, and then inside that placeholder you can have extra logic. It sounds so close to MF1's nested selectors that I'm worried that people will keep attempting to nest variants long after we're done with MF2.

If we go with Option A doubled {{ to avoid this, why not just embrace A (what does D add to it)?

None of us enjoys A's closing }}}}.

---

To sum up, I'm not fond of either option. I dislike bare .keywords because they look like text; I dislike {^} because it looks like a placeholder followed by text; and I dislike A's {{ ... }} because it looks like a placeholder with logic, which can have text around it.

We haven't had much time to iterate and discuss this, and I'm not overly confident in my vote. I think allowing ourselves to use [[ ... ]], at the cost of having to escape [[ in text, could open up new opportunities.

Fundamentally, I think we should first find the syntax for expressing the map of variant keys and variant patterns, and only then think about where and how to put declarations.

[aphillips]

@stasm noted:

We haven't had much time to iterate and discuss this, and I'm not overly confident in my vote. I think allowing ourselves to use [[ ... ]], at the cost of having to escape [[ in text, could open up new opportunities.

(chair hat OFF)

If you mean [[...]] for keys instead of when, we wouldn't have to escape them in our current syntax (they'd only be exposed if patterns were unquoted--they only have "key meaning" in code mode after a .match). I know I just suggested unquoting patterns in response to @gibson042's comments--but only to see if that's what he's trying to say!

Fundamentally, I think we should first find the syntax for expressing the map of variant keys and variant patterns, and only then think about where and how to put declarations.

I think this would be a conversation about the structure of the match/when statement and can be separated from the question "how did I get into code?". This is because variants are always contained in code.

It occurs to me that some of this discussion stems from our being an "in-a-string" format. We solved this in PUFF (and Fluent, etc.) by using document structure to literally make keys be keys and values values. If we were a file format, we wouldn't be having this conversation!

I think it is interesting that a pattern cannot start a message unless there is no code. This makes options like (C) possible.

So: I like D because it takes away special knowledge and extra typing. Once you've typed the keyword (with its dot) you're just in code mode. But I could accept most of the other proposals.

--

(chair hat ON)

only a few hours left to vote. I look forward to our discussion Monday!

[duerst]

I'm sorry I missed the deadline. But for YAML, options B/C/D, and in particular sigils '.', '>', and '~' are clearly better than the others.

[aphillips]

@duerst Do you want to submit a vote?

[gibson042]

No, my fundamental argument is that "simple message" should be a degenerate case of "complex message" (having no declarations or matcher) rather than a distinct grammar—and that can be achieved with a decision to start in code mode (e.g. by requiring patterns to always be quoted) or to start in text mode (e.g. with a sigil to indicate a declaration or match).

Starting in text mode with a sigil for declaration or match is option D, no?

@aphillips Yes, but that is not sufficient on its own to fulfill the property I am espousing. I don't have any particular attachment to sigil-prefixed keywords or even to starting in code mode vs. text mode, I have an attachment to simplicity of message structure so tool creators and developers and translators are subject to a minimum count of new concepts, friction, and surprise.

I mean, I see what you're saying, which is that you'd like to have unquoted patterns (so the degenerate form is a simple message)

I don't care about unquoted patterns for their own sake; they're just necessary to fulfill the property I care about if the format starts in text mode. The problem right now is that patterns must be quoted in a complex message and must not be quoted in a simple one.

but isn't that the syntax decision we just made?

The recent decisions have been made in isolation—start in code mode vs. text mode, trim pattern whitespace or not, require vs. support vs. prohibit quoting in complex messages—and AFAICT all have assumed the very bifurcation that I find problematic, and which only #512 seems to even touch on.

I think we either need to put changes like this out of scope ("disagree and commit") or recognize we have a kind of "failure mode" for this project.

This thread is definitely not the right scope. I hope #512 is, although it's currently framed as "document" rather than "decide" and I don't even know if the aspects I'm complaining about were discussed in Seville. But if they were/are discussed and ultimately rejected by the group, then I will comfortably disagree and commit.

[duerst]

@duerst Do you want to submit a vote?

Done. But as I'm late, no need to count. Also, what matters for YAML isn't so much the grammatical structure (which is the main issue being voted on) but the exact choice of introductory character. BTW. some of the options are specific about the introductory character ("the sigil ."), while others are not ("use a sigil"), which may skew the ballot a bit (although I don't think it will create too much of a skew).

[aphillips]

I counted all of the votes, even the late ones, since this particular ballot is input to a technical debate. (FWIW, none of the late votes changed the outcome)

[macchiati]

@duerst Is YAML widely used as a format for resource bundle files?

[aphillips]

(chair hat ON) 🎩

In the 2023-11-20 call the WG consensus was to adopt Option D (sigil introducer) using the . as the sigil. There is also a consensus to drop the keyword when from the syntax. An open issue is whether to decorate keys, e.g. a choice between the following pair (or variants thereof) with the top item being what we'll start with:

.match {$var :function}
one {{pattern}}
* {{pattern}}

vs.

.match {$var :function}
[one] {{pattern}}
[*] {{pattern}}

Closing this issue.

[duerst]

@macchiati

Is YAML widely used as a format for resource bundle files?

All I know is that it's used for resources in Ruby on Rails, and that Ruby on Rails is a widely used web application framework.

YAML's advantages are that it introduces very little visual clutter, and it allows data representations even closer to programs than JSON. The disadvantages are that it can be quite brittle, and that some features have serious security problems.