@Pike, @zbraniecki -- this is an early version of the change I'd like to propose. @Pike will recognize ideas from our brainstorming session a few week ago.

I think there are still some things missing here. One is handling completely blank lines. I'd like to get your feedback at this stage. Let me know what you think, thanks!

Lastly, quoted patterns are only available inside of placeables and cannot be
used directly as values.

Does it remove the ability to use quoted patterns in order to get significant trailing/leading white spaces?

Does it remove the ability to use quoted patterns in order to get significant trailing/leading white spaces?

Just a little bit. In #22 I'd like to define all backslash-escapes and allow escaping leading and trailing whitespace either explicitly or through Unicode escapes.

Do you think it's a common enough use-case that we should give it better support?

Idk, we can ask @Flod. But I know that from the readability principle perspective:

key = "  Value"

is a very clear way to say - I want key to have this value and those two whitespaces in front are meaningful.
Using unicode escapes or backslashes to annotate the same is a departure from that principle.

I'll look into the actual diff here in more detail, but regarding the leading/trailing whitespace, just one \ should suffice?

key = \     Value

would easily denote " Value".

Trailing whitespace is more tricky, as it's hard to distinguish "" from "\ ".

That said, on this particular aspect, my experience is that we rarely see leading or trailing whitespace in strings. In particular, if we would, we might want to make whitespace around = significant, wouldn't we?

is there any particular reason to remove the quote-delimited strings?

If it's just for simplicity, we could ensure we don't lock ourselves out of this solution and keep it in a sleeve in case a use case pops up later.

I would be OK forbidding quoted strings in placeables: { "foo" } as well as changing the syntax of named-argument to only allow a single unquoted word as value.

While I agree that key = " Value" is really clear, it's also a bit confusing as a localizer looking directly at the FTL file.

First thought when put in front of this: are these quotes going to show up in the product? Should I replace these with prettier/proper double quotes?

If the expectation is for localizers to work in tools, and for those who don't to be smart enough to be familiar with the syntax, I think that's a good choice.

Escaping the leading whitespace seems more confusing to me. Also reminds me of multiline properties, even if it's leading and not trailing.

P.S. sadly flod was taken when I signed up to GH, so you pinged a random inactive user, but I'm watching this project these days

On the actual diff, there are a few edgecases still.

AFAICT, there can be one empty line, but only one at a time in a message body?

key = value

  .attr = attribute

is ok, but

key  = value


 .attr = attribute

isn't?

Also, there are a few cases where EOF is probably OK instead of NL?

I personally would also like to see

key = 
    Some lengthy content here that doesn't have a = at the
    beginning.

While thinking of EOF, I also noticed that the grammar doesn't allow for leading whitespace-only lines.

I updated the PR to address @Pike's feedback. (Thanks for the help!)

I kept the quoted strings, but with a change to their semantics: they can only be simple strings right now which means they must not contain any placeables. They can be used as values to named-arguments and as literals in placeables.

The latter is useful for providing a way to unambiguously encode leading and trailing white-space into a value:

foo = { "" }       Foo       { "" }

Leading and trailing white-space will be vary rare—in fact we should actively discourage it. This approach makes it possible but doesn't optimize the syntax for it in any way.