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

Document why MessageFormat needs a successor #49

Closed
stasm opened this issue Feb 17, 2020 · 3 comments
Closed

Document why MessageFormat needs a successor #49

stasm opened this issue Feb 17, 2020 · 3 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@stasm
Copy link
Collaborator

stasm commented Feb 17, 2020

The group's charter has a few hints but I think it would be valuable to document the shortcomings of MessageFormat, and the reasons why we think it needs a successor.

The Message Format Working Group (MFWG) is tasked with developing an industry standard for the representation of localizable message strings to be a successor to ICU MessageFormat. MFWG will recommend how to remove redundancies, make the syntax more usable, and support more complex features, such as gender, inflections, and speech. MFWG will also consider the integration of the new standard with programming environments, including, but not limited to, ICU, DOM, and ECMAScript, and with localization platform interchange. The output of MFWG will be a specification for the new syntax, which is expected to be on track to become a Unicode Technical Standard.

@romulocintra romulocintra added the documentation Improvements or additions to documentation label Feb 18, 2020
This was referenced Feb 24, 2020
@romulocintra
Copy link
Collaborator

@mihnita just assigned you this issue :)

@zbraniecki
Copy link
Member

@mihnita I'd be interested in supporting you in this. My angle is two fold:

  1. I was involved in the evaluation of MessageFormat for Mozilla needs, which resulted in Fluent
  2. I wrote the Fluent vs MessageFormat comparison

In particular, I'm aware that (2) is not precise and in multiple places overstates the shortcomings of MF, so I'd like to correct that as part of work on this document.

@romulocintra
Copy link
Collaborator

Closed By #84

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

4 participants