search

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
595 stars 56 forks source link

MessageFormat 2 support #698

Open eemeli opened 1 week ago

eemeli commented 1 week ago

As discussed at W3C TPAC on 2024-09-26.

The MessageFormat 2.0 spec is reaching its finalization as a part of Unicode Technical Standard #35, with initial implementations included in ICU4C and ICU4J, as well as a JS library. Once it's published, this will be the first and so far only actual well specified standard for message formatting.

It would be very interesting to make MF2 available for web extension authors as an alternative to the current custom message format, in particular as doing so would enable support for messages that vary depending on plural cases, gender, and other variables (see #639).

It's possible to introduce MF2 as a non-breaking change by requiring a property either in manifest.json (such as "message_format": "mf2") or in each messages.json (such as "@@format": "mf2") to opt into the new format. The latter option may be easier for localization tooling to work with, as it ensures that handling a messages.json file does not require additional information beyond the locale included in the filename.

Support for MF2 as a message syntax does not necessitate any changes in the developer-facing getMessage() or __MSG_ APIs. While MF2 (and in particular, the upcoming Intl.MessageFormat API) also allow for user-definable custom functions as well as formatting to non-string targets, these should not be introduced at least until the corresponding TC39 proposal is further along, to ensure that there is no divergence.

Separately from the message format, work on a corresponding localization resource format is likely to take longer to concretize as a standard, and should not be considered as a blocker for MF2 adoption within messages.json. It's possible for such a format to be adopted later, in particular if/when support for it is introduced more deeply into browsers.

oliverdunk commented 1 week ago

As mentioned, we discussed this during in-person meetings at TPAC. We are supportive of expanding the syntax for the browser.i18n.getMessage API. MF2 looks like the best candidate for this - we are waiting for this specification to be finalized and will then continue discussions.