Skip to content

Prepare front-door for Tech Preview #697

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.

Sign up for GitHub

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

Merged
merged 9 commits into from
Mar 1, 2024
Merged

Prepare front-door for Tech Preview #697

Changes from 3 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
b48c4b3
Prepare front-door for Tech Preview
aphillips Feb 29, 2024
1758cd7
Update README.md
aphillips Feb 29, 2024
e205df4
address comments
aphillips Feb 29, 2024
d308f32
Update README.md
aphillips Feb 29, 2024
b688e0c
Update README.md
aphillips Feb 29, 2024
be799ef
Update README.md
aphillips Feb 29, 2024
c720a6a
Update README.md
aphillips Mar 1, 2024
a0c258b
Remove distracting link
aphillips Mar 1, 2024
8136c3f
Add sentence on data model
eemeli Mar 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 44 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,48 @@ The Message Format Working Group (MFWG) is tasked with developing an industry st
- [Goals and Non-Goals](docs/goals.md)
- [Record of Consensus Decisions](docs/consensus_decisions.md)

## MessageFormat 2 Draft Syntax
## MessageFormat 2 Technical Preview

The MessageFormat 2 specification was accepted by the CLDR-TC on 2024-02-28
as a new part of the LDML specification.
This specification is being 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 to perform non-integer exact number selection [#675](https://github.com/unicode-org/message-format-wg/issues/675)
- Whether `markup` should support additional spaces [#650](https://github.com/unicode-org/message-format-wg/issues/650)
- Whether "attribute-like" behavior is needed and what form it should take [#642](https://github.com/unicode-org/message-format-wg/issues/642)
- Whether to relax constraints on complex message start [#610](https://github.com/unicode-org/message-format-wg/issues/610)
- Whether omitting the `*` variant key should be permitted [#603](https://github.com/unicode-org/message-format-wg/issues/603)
Copy link
Collaborator

@gibson042 gibson042 Mar 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per recent discussions, I think we also care about feedback on the resolved value details (#678), and I personally would also like feedback on the desirability of syntax divergence between simple and complex messages (which is more general than #610 in its current form, cf. #610 (comment) and its outbound link tree). I guess the latter might be #512?

Copy link
Member Author

@aphillips aphillips Mar 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this. The list here consists strictly of items tagged with "seek feedback" label. I agree with most of your observations and will add some details shortly.

I personally would also like feedback on the desirability of syntax divergence between simple and complex messages (which is more general than #610 in its current form, cf. #610 (comment) and its outbound link tree). I guess the latter might be #512?

I think these are details of the syntax? Wouldn't feedback about the syntax in general work better? How intuitive (or unintuitive) it is to use, whether simple-vs-complex is easy to grok, etc.

Copy link
Collaborator

@gibson042 gibson042 Mar 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these are details of the syntax? Wouldn't feedback about the syntax in general work better? How intuitive (or unintuitive) it is to use, whether simple-vs-complex is easy to grok, etc.

Yes, but we should have specific prompts to get specific feedback.

Copy link
Member Author

@aphillips aphillips Mar 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always happy to get suggestions 😸


## What is MessageFormat 2?

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.
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.

## MessageFormat 2 Specification and Syntax

The current specification starts [here](spec/README.md) and may have changed since the publication
of the Tech Preview version.
The Tech Preview specification is [here](tr35-messageformat.md) (link to follow).

The current draft syntax for defining messages can be found in [spec/syntax.md](./spec/syntax.md).
The syntax is formally described in [ABNF](spec/message.abnf).
Expand Down Expand Up @@ -59,6 +100,8 @@ See more examples and the formal definition of the grammar in [spec/syntax.md](.

## Sharing Feedback

Technical Preview Feedback: [file an issue here](https://github.com/unicode-org/message-format-wg/issues/new?labels=Preview-Feedback&projects=&template=tech-preview-feedback.md&title=%5BFEEDBACK%5D+)

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](https://github.com/unicode-org/message-format-wg/discussions).
Expand Down