This has allowed me to identify a relatively small number of features that are likely to be available in MF2, but which are not currently available in Fluent. Some of these have previously been discussed here:
80
230
Others I could not find prior discussions for:
Allowing any literal values as variant keys
Explicitly setting the available variables for message references, as is done for term references
The representation of MF2 markup elements
In addition to the above, there are some Fluent features that are not supported in MF2:
Giving more than one positional argument to a custom function
Attributes on messages
While message and term references are not supported in the MF2 syntax, they are achievable via custom MF2 functions
The work on MF2 is ongoing, but we're approaching a decent understanding of the eventual shape of messages in its 2.0 edition. It is therefore getting more and more interesting to minimize any friction between Fluent and MF2, and to think about releasing a 1.1 version of the Fluent syntax that would allow for the representation of all or nearly all possible MF2 messages, while continuing to parse all valid Fluent 1.0 messages with their current meaning.
In addition to desirable new Fluent language features, this would make it easier for tooling (such as Pontoon) to provide a unified editing/translating experience for Fluent and MF2 messages with fewer gotchas and corner cases that depend on the underlying message format.
This issue is not intended to cover the discussion on all such differences, but to act as a collection point for enumerating them and considering whether it makes sense in the first place to develop Fluent in this direction. If that is desirable, separate conversations on each of those issues should follow.
While working on a JS runtime implementation for the upcoming MessageFormat 2 syntax, I've also put together a two-way Fluent/MF2 compatibility package.
This has allowed me to identify a relatively small number of features that are likely to be available in MF2, but which are not currently available in Fluent. Some of these have previously been discussed here:
80
230
Others I could not find prior discussions for:
In addition to the above, there are some Fluent features that are not supported in MF2:
The work on MF2 is ongoing, but we're approaching a decent understanding of the eventual shape of messages in its 2.0 edition. It is therefore getting more and more interesting to minimize any friction between Fluent and MF2, and to think about releasing a 1.1 version of the Fluent syntax that would allow for the representation of all or nearly all possible MF2 messages, while continuing to parse all valid Fluent 1.0 messages with their current meaning.
In addition to desirable new Fluent language features, this would make it easier for tooling (such as Pontoon) to provide a unified editing/translating experience for Fluent and MF2 messages with fewer gotchas and corner cases that depend on the underlying message format.
This issue is not intended to cover the discussion on all such differences, but to act as a collection point for enumerating them and considering whether it makes sense in the first place to develop Fluent in this direction. If that is desirable, separate conversations on each of those issues should follow.