Syntax 0.8 RFC2 until October 25

Fluent
#1

We’re making progress on the Syntax 0.8 milestone and I’d like to invite everyone to share their opinions on the features planned for this release. 0.8 is likely the last milestone before 1.0 RC. We don’t plan to make any breaking syntax changes after it.

You can track the status of this milestone on the project board on GitHub. Let’s have a closer look at the individual issues in this milestone.

  • We’d like to allow localizers to format their multiline translations such that indentation is preserved where it matters (#162 ). This will be useful for using HTML markup in the translations, as well for plugging Fluent into environments which care about indentation (e.g. Markdown). There’s a proposal to use a logic similar to that of Python’s textwrap.dedent() utility which hopefully is the right answer. Thank you!

  • We’ve discovered a couple of limitations in the design of VariantLists. I submitted a new idea which could supersede VariantLists (or complement them): Parameterized Terms, also known as Macros (#176). I’m looking for feedback on the proposed syntax, resolution logic, as well as examples of use-cases which are better served with VariantLists.

  • If macros turn out to be hard to add or if we choose to keep VariantLists, we’ll need to fix their limitations. That’s #187 and #188.

  • For both VariantLists and macros, we’re looking for use-cases for allowing variants on Term attributes: #189.

  • There are a number of issues related to removing support for certain characters in TextElements and/or in StringLiterals. #123 is about removing backslash escape sequences from TextElements (they would continue to wokr in StringLiterals: e.g. {"\u00A0"}). #186 proposes to forbid the literal closing brace, } in TextElements, which would be symmetric to how the opening brace, { is already a special char because it opens a Placeable. #182 is about forbidding C1 control characters from both TextElements and StringLiterals. C0 are already forbidden.

  • Lastly, there are two minor improvements to how the spec defines how broken entities should be parsed as Junk: #184 and #185.

I’d love to open these discussions up to a wider audience. We’re in the last stretch of the syntax work before 1.0. If you want to have an impact on how Fluent 1.0 works and what it looks like, please give your feedback here or on GitHub before Friday, October 26. On Friday, we’ll conduct a triage session and decide which issues may advance and land, and which ones may need more time given the feedback received.

Fluent Syntax 0.7 has been published
Syntax 0.8 RFC3 until November 4
#2

The conversations around TextElements are tricky to understand. I know that it took myself several attempts, and I also took half an hour to describe the impact of 123 to flod on our 1-1.

I think these issues have multiple dimensions, but only surface one or two. 123 in particular comes with

  • lexical specification of the syntax
  • expected behavior of TextElement
  • expected behavior of StringLiteral
  • role of TextElement vs StringLiteral
  • future roles of StringLiteral in scenarios of relaxation of Variant names

I think this issue needs more clarity on the impact it has to users of Fluent, but I’m not sure how to get there.

Any suggestions?

#3

Thanks for the feedback, @Pike. It’s true that there are a number of things to consider at the same time. I’ll post a summary in #123 taking into account the dimensions you listed.

#4

As we discuss the 0.8 features and the details crystallize, sometimes it’s useful to fork the conversations into new issues. Here’s a quick summary of 3 new issues which were added to the 0.8 milestone:

  • A proposal to change the syntax of named arguments of call expressions from name: value to $name = value (#192). It doubles down on the = as the operator for defining things (messages, attributes, arguments). It also synergizes well with the macros proposal from above.

  • A proposal to allow more (or fewer) than exactly 4 hex digits in Unicode escape sequences (#194).

  • A discussion about how to specify the expected behavior of escape sequences in the runtime, and whether they should have their own nodes in the AST (#195).

#5

Thanks to everyone who participated in this RFC. With your help, we were able to move forward with a number of proposals. Today I’ve opened a third RFC period to gather more feedback on issues with open questions.