Pick a delimiter for literals other than the double quote

[stasm]

@markusicu wrote in #230 (comment):

Speaking of literals, don't enclose them in quotes. One of the stated goals here is to make messages usable as string literals in programming languages. Enclose literals in parentheses {... {(5) :number} books} or angle brackets {... {<5> :number} books} or pairs of pipe symbols {... {|5| :number} books} or similar.

[stasm]

I like this suggestion a lot. It's a simple change that can have a significant impact on how easy it will be to embed translations in code or other containers.

Parentheses look good to me ({(5) :number}), although as a non-native English speaker, I wonder if there's a strong connotation to negative numbers here? If there is, then a pair of pipes would get my vote instead. I don't think we need directional delimiters here (i.e. separate open and close ones) like I recommend we have for patterns. Literals are usually short and already enclosed in a placeholder (which has its own delimiters) or are outside patterns (when used as variant keys).

Using the current EBNF to visualize the options:

{$foo :func}
{$bar :func}
    (a key with spaces) (another one) [Some text with an interpolated {(123) :number} literal.]
    |a key with spaces| |another one| [Some text with an interpolated {|123| :number} literal.]
    _ [Default foo]

[aphillips]

If we encode @stasm's example to a string it becomes gibberish:

"{$foo :func}\n{$bar :func}\n    (a key with spaces) (another one) [Some text...]\n    (a key with spaces) (another one) [etc.]"

The discussion of a syntax without consideration for the serialization form makes me nervous that we'll have to embed our nifty new syntax in an impenetrable layer of syntactic goo from any eventual resource format. Maybe we should reconsider and just "bite the bullet" to define the "source format", which can then be consumed/compiled into a runtime format? Thinking of MFv2 as "a pattern string" makes my head hurt 😵

I think the only things missing currently are a way to identify the "resource key" (pattern identifier) and the outsides of the MFv2 structure.

[zbraniecki]

@aphillips I am aligned with you that we should draft the "MF2 Resource" proposal before we freeze MF2 Message Format.

The list of items to consider for resource is (brain dump) - pattern identifier, recover from broken message mechanism, groupings, group and resource level meta information.

[stasm]

I formatted my example for readability, but I think it's realistic to assume that many translations will be formatted on a single line when embedded into a generic container. That's why I was against making the newline a syntax-significant character in MF2.

My example also has long variant keys with spaces to demonstrate what they would look like with delimiters, but the EBNF allows bare variant keys too. I think a more realistic example would be this:

"{$foo :func} {$bar :func} one one [Some text...] one few [etc.]"

There's #251 about making the preamble with selectors stand out more from the rest of the message, but otherwise I think this is actually pretty minimal. Do you think a special-purpose resource format can improve this significantly?

[eemeli]

I added #265 to continue the discussion on developing a resource syntax in parallel.

Regarding the original topic and the related #245, we should keep in mind the potential of using escaped literals as a way of signaling non-translatability, so a message could include e.g.

Text with {"untranslatable term"}.

in addition to

Text with {"42" :number}.

Furthermore, the syntax currently also uses quotes for option values:

Text with {$var :func foo="value with spaces"}.

With the alternatives suggested by @markusicu, those would look like this:

Text with {(untranslatable term)}.
Text with {(42) :number}.
Text with {$var :func foo=(value with spaces)}.

Text with {<untranslatable term>}.
Text with {<42> :number}.
Text with {$var :func foo=<value with spaces>}.

Text with {|untranslatable term|}.
Text with {|42| :number}.
Text with {$var :func foo=|value with spaces|}.

Whichever option we pick, I would think that it should be the same for each of the above use cases.

[stasm]

Re. angle brackets, I have another concern on top of the need to escape them in XML containers. Consider the examples from above:

Text with {<untranslatable term>}.
Text with {<42> :number}.
Text with {$var :func foo=<value with spaces>}.

Am I the only one to whom the <angle bracketed literals> look like unofficial placeholders that are used in docs or in chat between users? I don't know how to call them right; it's like a second derivative templating used when explaining how a DSL works.