Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MessageFormat 2 support #698

Open
eemeli opened this issue Sep 26, 2024 · 1 comment
Open

MessageFormat 2 support #698

eemeli opened this issue Sep 26, 2024 · 1 comment
Labels
supportive: chrome Supportive from Chrome supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari topic: localization

Comments

@eemeli
Copy link

eemeli commented Sep 26, 2024

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.

@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Sep 26, 2024
@oliverdunk oliverdunk added supportive: chrome Supportive from Chrome and removed needs-triage: chrome Chrome needs to assess this issue for the first time labels Sep 27, 2024
@xeenon xeenon added supportive: safari Supportive from Safari and removed needs-triage: safari Safari needs to assess this issue for the first time labels Sep 27, 2024
@Rob--W Rob--W added supportive: firefox Supportive from Firefox and removed needs-triage: firefox Firefox needs to assess this issue for the first time labels Sep 27, 2024
@oliverdunk
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
supportive: chrome Supportive from Chrome supportive: firefox Supportive from Firefox supportive: safari Supportive from Safari topic: localization
Projects
None yet
Development

No branches or pull requests

5 participants