Rebranding to Unicode MessageFormat

README.md

@@ -12,12 +12,16 @@ while providing a framework for increasingly complex features, such as gender, i
 Our goal is to provide an interoperable syntax, message data model, and associated processing that is
 capable of being adopted by any presentation framework or programming environement.
 
-## MessageFormat 2
+## The Unicode MessageFormat Standard
 
-The [MessageFormat 2 specification](./spec/) has been approved by the CLDR Technical Committee
-and is now a stable part of
-the [LDML](https://www.unicode.org/reports/tr35/) specification.
-It is now recommended for implementation and adoption.
+The [Unicode MessageFormat Standard](./spec/) is a stable part of CLDR.
+It was approved by the CLDR Technical Committee
+and is recommended for implementation and adoption.
+The normative version of the specification is published as a part of [TR35](https://www.unicode.org/reports/tr35/).
+This repository contains the editor's copy.
+
+**Unicode MessageFormat** is sometimes referred to as _MessageFormat 2.0_,
+since it replaces earlier message formatting capabilities built into ICU.
 
 Some _default functions_ and items in the `u:` namespace are still in Draft status.
 Feedback from users and implementers might result in changes to these capabilities.

spec/README.md

@@ -1,13 +1,13 @@
-# MessageFormat 2.0 Specification
+# The Unicode MessageFormat Standard
 
 > [!IMPORTANT]
 > This page is not a part of the specification and is not normative.
 
-## What is MessageFormat 2?
+## What is Unicode MessageFormat?
 
 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
+_Unicode MessageFormat_ 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),
@@ -17,6 +17,10 @@ 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.
 
+During its development, _Unicode MessageFormat_ was known as "MessageFormat 2.0",
+since the specification supersedes earlier message formatting capabilities
+such as those developed in the [ICU](https://icu.unicode.org) project.
+
 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.
 

spec/appendices.md

@@ -2,7 +2,7 @@
 
 ### Security Considerations
 
-MessageFormat _patterns_ are meant to allow a _message_ to include any string value
+Unicode MessageFormat _patterns_ are meant to allow a _message_ to include any string value
 which users might normally wish to use in their environment.
 Programming languages and other environments vary in what characters are permitted
 to appear in a valid string.
@@ -45,7 +45,7 @@ In addition, end-users need to be aware of the risks involved.
 
 ### Acknowledgements
 
-Special thanks to the following people for their contributions to making MessageFormat 2.0.
+Special thanks to the following people for their contributions to making the Unicode MessageFormat Standard.
 The following people contributed to our github repo and are listed in order by contribution size:
 
 Addison Phillips, 

spec/data-model/README.md

@@ -1,33 +1,33 @@
 ## Interchange Data Model
 
-This section defines a data model representation of MessageFormat 2 _messages_.
+This section defines a data model representation of Unicode MessageFormat _messages_.
 
 Implementations are not required to use this data model for their internal representation of messages.
 Neither are they required to provide an interface that accepts or produces
 representations of this data model.
 
 The major reason this specification provides a data model is to allow interchange of 
 the logical representation of a _message_ between different implementations.
-This includes mapping legacy formatting syntaxes (such as MessageFormat 1)
-to a MessageFormat 2 implementation.
+This includes mapping legacy formatting syntaxes (such as ICU MessageFormat)
+to a Unicode MessageFormat implementation.
 Another use would be in converting to or from translation formats without 
 the need to continually parse and serialize all or part of a message.
 
 Implementations that expose APIs supporting the production, consumption, or transformation of a
 _message_ as a data structure are encouraged to use this data model.
 
 This data model provides these capabilities:
-- any MessageFormat 2.0 message can be parsed into this representation
+- any Unicode MessageFormat _message_ can be parsed into this representation
 - this data model representation can be serialized as a well-formed
-MessageFormat 2.0 message
-- parsing a MessageFormat 2.0 message into a data model representation
+  Unicode MessageFormat _message_
+- parsing a Unicode MessageFormat _message_ into a data model representation
   and then serializing it results in an equivalently functional message
 
 This data model might also be used to:
-- parse a non-MessageFormat 2 message into a data model
-  (and therefore re-serialize it as MessageFormat 2).
+- parse non Unicode MessageFormat messages into a data model
+  (and therefore re-serialize it as Unicode MessageFormat).
   Note that this depends on compatibility between the two syntaxes.
-- re-serialize a MessageFormat 2 message into some other format
+- re-serialize a Unicode MessageFormat _message_ into some other format
   including (but not limited to) other formatting syntaxes
   or translation formats.
 
@@ -43,7 +43,7 @@ declarations, options, and attributes to be optional rather than required proper
 
 > [!IMPORTANT]
 > The data model uses the field name `name` to denote various interface identifiers.
-> In the MessageFormat 2 [syntax](/spec/syntax.md), the source for these `name` fields
+> In the Unicode MessageFormat [syntax](/spec/syntax.md), the source for these `name` fields
 > sometimes uses the production `identifier`.
 > This happens when the named item, such as a _function_, supports namespacing.
 
@@ -100,7 +100,7 @@ interface LocalDeclaration {
 In a `SelectMessage`,
 the `keys` and `value` of each _variant_ are represented as an array of `Variant`.
 For the `CatchallKey`, a string `value` may be provided to retain an identifier.
-This is always `'*'` in MessageFormat 2 syntax, but may vary in other formats.
+This is always `'*'` in the Unicode MessageFormat syntax, but may vary in other formats.
 
 ```ts
 interface Variant {

spec/functions/datetime.md

@@ -234,7 +234,7 @@ When the offset is not present, implementations SHOULD use a floating time type
 For more information, see [Working with Timezones](https://w3c.github.io/timezone).
 
 > [!IMPORTANT]
-> The [ABNF](/spec/message.abnf) and [syntax](/spec/syntax.md) of MF2
+> The [ABNF](/spec/message.abnf) and [syntax](/spec/syntax.md) of Unicode MessageFormat
 > do not formally define date/time literals.
 > This means that a _message_ can be syntactically valid but produce
 > a _Bad Operand_ error at runtime.

spec/intro.md

@@ -1,4 +1,4 @@
-# MessageFormat 2.0 Specification
+# The Unicode MessageFormat Standard Specification
 
 ## Table of Contents
 
@@ -46,8 +46,7 @@ existing internationalization APIs (such as the date and number formats shown ab
 grammatical matching (such as plurals or genders),
 as well as user-defined formats and message selectors.
 
-The document is the successor to ICU MessageFormat,
-henceforth called ICU MessageFormat 1.0.
+The document is the successor to ICU MessageFormat.
 
 ### Conformance
 

test/schemas/v0/tests.schema.json

@@ -1,8 +1,8 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://raw.githubusercontent.com/unicode-org/message-format-wg/main/test/schemas/v0/tests.schema.json",
-  "title": "MessageFormat 2 data-driven tests",
-  "description": "The main schema for MessageFormat 2 test data.",
+  "title": "Unicode MessageFormat data-driven tests",
+  "description": "The main schema for Unicode MessageFormat test data.",
   "type": "object",
   "additionalProperties": false,
   "required": [
@@ -185,7 +185,7 @@
       "type": "string"
     },
     "src": {
-      "description": "The MF2 syntax source.",
+      "description": "The message source in the Unicode MessageFormat syntax.",
       "type": "string"
     },
     "bidiIsolation": {