Welcome to the home page for the MessageFormat Working Group, a subgroup of the Unicode CLDR-TC.
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.
The MessageFormat 2 specification is a new part of the LDML specification. This specification is initially released as a "Tech Preview", which means that the stability policy is not in effect and feedback from users and implementers might result in changes to the syntax, data model, functions, or other normative aspects of MessageFormat 2. Such changes are expected to be minor and, to the extent possible, to be compatible with what is defined in the Tech Preview.
The MFWG welcomes any and all feedback, including bugs reports, implementation reports, success stories, feature requests, requests for clarification, or anything that would be helpful in stabilizing the specification and promoting widespread adoption.
The MFWG specifically requests feedback on the following issues:
- How best to define value resolution #678
- How to perform non-integer exact number selection #675
- Whether
markup
should support additional spaces #650 - Whether "attribute-like" behavior is needed and what form it should take #642
- Whether to relax constraints on complex message start #610
- Whether omitting the
*
variant key should be permitted #603
Software needs to construct messages that incorporate various pieces of information. The complexities of the world's languages make this challenging. MessageFormat 2 defines the data model, syntax, processing, and conformance requirements for the next generation of dynamic messages. It is intended for adoption by programming languages, software libraries, and software localization tooling. It enables the integration of internationalization APIs (such as date or number formats), and grammatical matching (such as plurals or genders). It is extensible, allowing software developers to create formatting or message selection logic that add on to the core capabilities. Its data model provides a means of representing existing syntaxes, thus enabling gradual adoption by users of older formatting systems.
The goal is to allow developers and translators to create natural-sounding, grammatically-correct, user interfaces that can appear in any language and support the needs of diverse cultures.
The current specification starts here and may have changed since the publication of the Tech Preview version. The Tech Preview specification is here (link to follow).
The current draft syntax for defining messages can be found in spec/syntax.md. The syntax is formally described in ABNF.
Messages can be simple strings:
Hello, world!
Messages can interpolate arguments:
Hello {$user}!
Messages can transform those arguments using formatting functions. Functions can optionally take options:
Today is {$date :datetime}
Today is {$date :datetime weekday=long}.
Messages can use a selector to choose between different variants, which correspond to the grammatical (or other) requirements of the language:
.match {$count :integer}
0 {{You have no notifications.}}
one {{You have {$count} notification.}}
* {{You have {$count} notifications.}}
Messages can annotate arguments with formatting instructions or assign local values for use in the formatted message:
.input {$date :datetime weekday=long month=medium day=short}
.local $numPigs = {$pigs :integer}
{{On {$date} you had this many pigs: {$numPigs}}}
The message syntax supports using multiple selectors and other features to build complex messages. It is designed so that implementations can extend the set of functions or their options using the same syntax. Implementations may even support users creating their own functions.
See more examples and the formal definition of the grammar in spec/syntax.md.
The Working Group continues to address feedback
and develop portions of the specification not completed for the LDML45 Tech Preview release.
The main
branch of this repository contains changes implemented since the technical preview.
Implementers should be aware of the following normative changes during the tech preview period:
- (list to be updated during tech preview)
(The working group expects that ICU75 will include both Java and C/C++ implementations of the tech preview specification)
- Java:
com.ibm.icu.message2
, part of ICU 72 released in October 2022, is a tech preview implementation of the MessageFormat 2 syntax, together with a formatting API. See the ICU User Guide for examples and a quickstart guide. - JavaScript:
messageformat
4.0 implements the MessageFormat 2 syntax, together with a polyfill of the runtime API proposed for ECMA-402.
Technical Preview Feedback: file an issue here
We invite feedback about the current syntax draft, as well as the real-life use-cases, requirements, tooling, runtime APIs, localization workflows, and other topics.
- General questions and thoughts → post a discussion thread.
- Actionable feedback (bugs, feature requests) → file a new issue.
To join in:
- Review CONTRIBUTING.md
- Apply to join our mailing list
- Watch this repository (use the "Watch" button in the upper right corner)
Copyright © 2019-2024 Unicode, Inc. Unicode and the Unicode Logo are registered trademarks of Unicode, Inc. in the United States and other countries.
The project is released under LICENSE.
A CLA is required to contribute to this project - please refer to the CONTRIBUTING.md file (or start a Pull Request) for more information.