fluent-syntax - explicitly add newline character in multiline strings

[hkasemir]

Would be nice if this were treated as in markdown that you can make a multiline string and the whitespace is only converted to a newline explicitly, for example by adding a blank line,
so for example

message = Loki is a simple micro-blogging
    app written entirely in <i>HTML5</i>.
    It uses FTL to implement localization.

currently results in "value": "Loki is a simple micro-blogging\napp written entirely in <i>HTML5</i>.\nIt uses FTL to implement localization."

But might be better if it resulted in "value": "Loki is a simple micro-blogging app written entirely in <i>HTML5</i>. It uses FTL to implement localization."

and perhaps

message = Loki is a simple micro-blogging
    app written entirely in <i>HTML5</i>.

    It uses FTL to implement localization.

could result in "value": "Loki is a simple micro-blogging app written entirely in <i>HTML5</i>.\nIt uses FTL to implement localization."

Just a thought, would be happy to hear other ideas, but currently I can imagine developers wanting to keep line-width down for file aesthetics, and not necessarily realizing they are introducing newlines.

[stasm]

This is almost exactly what @flodolo and I talked about just a week ago. Also CC'ing @Pike.

I think however that the AST should not be affected so that we can serialize back to what the localizer typed exactly, including the line break after micro-blogging in the example so that the whole thing is serialized as a multi-line block. The blank line to new line logic would happen in the runtime.

[flodolo]

I was also talking with @Pike about it. Before that discussion, I was thinking that the Markdown approach is good enough for us: a new line is not a \n. a new line + an empty line is.

I'm not so sure about that anymore. Maybe a new line in the file should actually map to a new line in the string, and we only need to find a way to have multiline strings for line readability (i.e. equivalent of backslash in .properties).

[hkasemir]

Yea, I filed the issue because I saw your conversation about it in #l20n, and I was a little surprised - I didn't realize that organizing a string into multiple lines had the effect of introducing \n characters. My thought is that if that was its effect on me, then it's not unlikely that it could happen to other devs, so I figured it would be good to make an explicit decision, and include whatever is decided in the docs so there aren't any hidden side-effects to multiline strings.

[Gregoor]

I second that. Was just surprised by a bunch of linebreaks in our strings. To me @flodolo's idea makes most sense. In any case it should imo be more explicit.

[stasm]

The discussion about this continued in the spec repo in projectfluent/fluent#122 (comment) and in projectfluent/fluent#162. The decision was to preserve the newlines as part of the translation content, and to also preserve the indentation of multilline translations (after removing the indent shared by all lines). By preserving as much information about the whitespace formatting as possible, it's possible to implement various newline-normalization schemes on top of FluentBundle. In particular, the bindings packages like @fluent/react and @fluent/dom could implement their own methods for handling newlines in translations.

The above decision was made in mid-2018, and shipped in Syntax 0.8. After the 1.0 release in April 2019, the syntax is now stable.