unicode-org · aphillips · Jun 17, 2023 · Jun 6, 2023 · Jun 6, 2023 · Jun 6, 2023
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -0,0 +1,29 @@
+# Contributing to this project
+
+## Joining the Working Group
+
+We are looking for participation from software developers, localization engineers and others with experience 
+in Internationalization (I18N) and Localization (L10N). If you wish to contribute to this work, please review
+the information on the Contributor License Agreement below. In addition, you should:
+
+1. Apply to join our [mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+2. Watch this repository (use the "Watch" button in the upper right corner)
+
+<!-- boilerplate follows - do not edit -->
+## Contributor License Agreement
+
+In order to contribute to this project, the Unicode Consortium must have on file a Contributor License Agreement (CLA) covering your contributions, either an individual or a corporate CLA. Pull Requests will not be merged until the correct CLA is signed. Which version needs to be signed depends on who owns the contribution being made: you as the individual making the contribution or your employer. _It is your responsibility to determine whether your contribution is owned by your employer._ Please review [The Unicode Consortium Intellectual Property, Licensing, and Technical Contribution Policies][policies] for further guidance on which CLA to sign, as well as other information and guidelines regarding the Consortium’s licensing and technical contribution policies and procedures.
+
+- **Individual CLA**: If you have determined that the Individual CLA is appropriate, just open a Pull Request and you will have the opportunity to click to accept the Individual CLA.
+
+- **Corporate CLA**: If you have determined that a Corporate CLA is appropriate, please check the [public list of Corporate CLAs][unicode-corporate-clas] that the Consortium has on file. If your employer has already signed a CLA, then just open a Pull Request and you will have the opportunity to click that your employer has already signed a CLA. If your employer has not already signed a CLA, you will need to arrange for your employer to sign the Corporate CLA, as described in [How to Sign a Unicode CLA][signing].
+
+Unless otherwise noted in the LICENSE file, this project is released under the free and open-source [Unicode License][unicode-license], also known as Unicode, Inc. License Agreement - Data Files and Software.
+
+SPDX-License-Identifier: Unicode-DFS-2016
+
+
+[policies]: https://www.unicode.org/policies/licensing_policy.html
+[unicode-corporate-clas]: https://www.unicode.org/policies/corporate-cla-list/
+[signing]: https://www.unicode.org/policies/licensing_policy.html#signing
+[unicode-license]: https://www.unicode.org/license.txt
diff --git a/LICENSE b/LICENSE
@@ -1,10 +1,7 @@
 UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
 
-In addition to the definitions provided in the Terms of Use at
-https://www.unicode.org/copyright.html, Unicode Data Files ("Data Files")
-includes all data files and any associated documentation provided in this
-repository, and Unicode Software ("Software") includes all software provided
-in this repository.
+See Terms of Use <https://www.unicode.org/copyright.html>
+for definitions of Unicode Inc.’s Data Files and Software.
 
 NOTICE TO USER: Carefully read the following legal agreement.
 BY DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING UNICODE INC.'S
@@ -16,7 +13,7 @@ THE DATA FILES OR SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright © 1991-2021 Unicode, Inc. All rights reserved.
+Copyright © 1991-2023 Unicode, Inc. All rights reserved.
 Distributed under the Terms of Use in https://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining

diff --git a/README.md b/README.md
@@ -13,6 +13,7 @@ The Message Format Working Group (MFWG) is tasked with developing an industry st
 ## MessageFormat 2 Draft Syntax
 
 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).
 
 Messages can be simple strings:
 
@@ -65,14 +66,17 @@ We invite feedback about the current syntax draft, as well as the real-life use-
 * General questions and thoughts → [post a discussion thread](https://github.com/unicode-org/message-format-wg/discussions).
 * Actionable feedback (bugs, feature requests) → [file a new issue](https://github.com/unicode-org/message-format-wg/issues).
 
-## Contributing
+## Participation
 
-- [Decision Making Process](docs/decision-process.md)
-- [Contributing to the Meeting Agenda](docs/contributing-to-agenda.md)
-- [Chair Group](docs/chair-group.md)
-- [Glossary](docs/glossary-and-resources.md)
+To join in:
 
-We are open to professionals in the i18n/l10n industry to participate in our working group!  To join:
+1. Review [CONTRIBUTING.md](./CONTRIBUTING.md)
+2. Apply to join our [mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+3. Watch this repository (use the "Watch" button in the upper right corner)
+
+## Copyright & Licenses
+
+Copyright © 1991-2023 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](./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.
 
-1. Apply to join our [mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
-2. Watch this repository (use the "Watch" button in the upper right corner)
diff --git a/meetings/agenda.md b/meetings/agenda.md
@@ -39,46 +39,73 @@ The next call will be Monday 19 June 2023.
 ## Homework
 
 
-
 ## Agenda
 
 To request that the chair add an _issue_ to the agenda, add the label `Agenda+`
 To request that the chair add an agenda item, send email to the message-format-wg group email.
 
-***Date: 2023-06-05***
 
 ### Topic: Agenda Review
 
-### Topic: Info Share
 
+### Topic: Info Share
+* Presentation this week (Thursday) at the Unicode CLDR thingy.
 
 ### Topic: Action Item Review
 
 
-### Topic: Active PR review
+## Topic: Active PR review
+
+Discussion of active PRs. We will merge or reject them in the call.
+
+The recommendation "discuss" is to ensure there is WG consensus before merging. The recommendation "merge with edits" is to merge once existing comments have been addressed.
 
 Discussion of active PRs. We will merge or reject them in the call.
 
 | PR   | Description | Recommendation |
 |------|-------------|----------------|
 | #315 | Bidi support | Discuss (see below) |
+| #381 | Clarify variable declarations may override previous ones | Merge |
+| #387 | Fix dangling mention of `nmtoken` | Merge |
+| #388 | Change the "pattern selection" text | Discuss |
+| #389 | Make pattern selection example 3 clearer | Discuss |
 
 
 * The recommendation "discuss" is to ensure there is WG consensus before merging. The recommendation "merge with edits" is to merge once existing comments have been addressed.
 
+## Topic: Bidi support
+https://github.com/unicode-org/message-format-wg/pull/315 
+Discussion of bidirectional text support and specifically how to handle auto-isolation of placeables.
+
+## Topic: Pattern Selection text
+https://github.com/unicode-org/message-format-wg/pull/388
+The above PR changes the wording related to patterns selection to use a different approach. This is based on a comment Addison made on PR#385.
+
+## Topic: Make pattern selection example 3 clearer
+https://github.com/unicode-org/message-format-wg/pull/389
+Editorial changes to make this example easier to understand. (Taken from comments on PR #385)
+
+## Topic: Open Issue Review
 
-### Topic: AOB?
+* https://github.com/unicode-org/message-format-wg/issues
 
----
+Currently we have 90 open.
 
-## Proposed for Future (or if time permits)
+Here is the "Top 10 List":
 
+| Issue | Status | Description | Chair's Recommendation |
+|-------|--------|-------------|----------------|
+| (#259)[https://github.com/unicode-org/message-format-wg/issues/259] | resolve-candidate | Don't allow whitespace everywhere | close |
+| (#248)[https://github.com/unicode-org/message-format-wg/issues/248] | resolve-candidate | Naming things | close |
+| (#378)[https://github.com/unicode-org/message-format-wg/issues/378] | blocker-candidate | reserve sigils for private use | proceed to PR |
+| (#356)[https://github.com/unicode-org/message-format-wg/issues/356] | blocker-candidate | clarify that standalone markup is permitted | resolve-candidate | close? addressed by ABNF changes |
+| (#351)[https://github.com/unicode-org/message-format-wg/issues/351] | resolve-candidate | replace first-match with best-match | close (accepted) |
+| (#346)[https://github.com/unicode-org/message-format-wg/issues/346] | resolve-candidate | consider escaping by doubling special | close (stale) |
+| (#299)[https://github.com/unicode-org/message-format-wg/issues/299] | blocker-candidate | when do we evaluate the local variables? | discuss (related to other discussions) |
+| (#298)[https://github.com/unicode-org/message-format-wg/issues/298] | blocker-candidate | should custom functions override standard ones? | discuss |
+| (#292)[https://github.com/unicode-org/message-format-wg/issues/292] | resolve-candidate | resolving type when chaining local variables | close (MF doesn't have types or interpret values) |
+| (#272)[https://github.com/unicode-org/message-format-wg/issues/272] | blocker-candidate | decide on formatting to something other than text | discuss (important!) |
 
-### Topic: (Discussion) Guidance needed for dealing with selector explosions
-* Requested by: STA
-* https://github.com/unicode-org/message-format-wg/discussions/323
 
-### Topic: Defining MF1 compatibility
-* Requested by: EAO
+## Topic: AOB?
 
-_Eemeli requested this in our previous call (2023-03-06) and we have discussed this in various issues._
diff --git a/spec/README.md b/spec/README.md
@@ -6,37 +6,20 @@
    1. [Conformance](#conformance)
    1. [Terminology and Conventions](#terminology-and-conventions)
 1. [Syntax](syntax.md)
-   1. [Design Goals](syntax.md#design-goals)
-   1. [Design Restrictions](syntax.md#design-restrictions)
-   1. [Overview & Examples](syntax.md#overview--examples)
-   1. [Simple Messages](syntax.md#simple-messages)
-   1. [Simple Placeholders](syntax.md#simple-placeholders)
-   1. [Formatting Functions](syntax.md#formatting-functions)
-   1. [Markup Elements](syntax.md#markup-elements)
-   1. [Selection](syntax.md#selection)
-   1. [Local Variables](syntax.md#local-variables)
-   1. [Complex Messages](syntax.md#complex-messages)
-1. [Productions](syntax.md#productions)
-   1. [Message](syntax.md#message)
-   1. [Variable Declarations](syntax.md#variable-declarations)
-   1. [Selectors](syntax.md#selectors)
-   1. [Variants](syntax.md#variants)
-   1. [Patterns](syntax.md#patterns)
-   1. [Placeholders](syntax.md#placeholders)
-   1. [Expressions](syntax.md#expressions)
-   1. [Markup Elements](syntax.md#markup-elements)
-1. [Tokens](syntax.md#tokens)
-   1. [Text](syntax.md#text)
-   1. [Names](syntax.md#names)
-   1. [Quoted Strings](syntax.md#quoted-strings)
-   1. [Escape Sequences](syntax.md#escape-sequences)
-   1. [Whitespace](syntax.md#whitespace)
-1. [Complete EBNF](syntax.md#complete-ebnf)
+   1. [Productions](syntax.md#productions)
+   1. [Tokens](syntax.md#tokens)
+   1. [`message.abnf`](message.abnf)
+1. [Registry](registry.md)
+   1. [`registry.dtd`](registry.dtd)
 1. [Formatting](formatting.md)
 
 ## Introduction
 
-One of the challenges in adapting software to work for users with different languages and cultures is the need for ***dynamic messages***. Whenever a user interface needs to present data as part of a larger string, that data needs to be formatted (and the message may need to be altered) to make it culturally accepted and grammatically correct.
+One of the challenges in adapting software to work for
+users with different languages and cultures is the need for **_dynamic messages_**.
+Whenever a user interface needs to present data as part of a larger string,
+that data needs to be formatted (and the message may need to be altered)
+to make it culturally accepted and grammatically correct.
 
 For example, if your US English interface has a message like:
 
@@ -50,20 +33,29 @@ Or Japanese:
 
 > あなたのアイテムは 2023 年 4 月 3 日に 1,023 回閲覧されました。
 
-This specification defines the data model, syntax, processing, and conformance requirements for the next generation of _dynamic messages_. It is intended for adoption by programming languages and APIs. This will enable the integration of existing internationalization APIs (such as the date and number formats shown above), grammatical matching (such as plurals or genders), as well as user-defined formats and message selectors.
+This specification defines the
+data model, syntax, processing, and conformance requirements
+for the next generation of _dynamic messages_.
+It is intended for adoption by programming languages and APIs.
+This will enable the integration of
+existing internationalization APIs (such as the date and number formats shown above),
+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,
+henceforth called ICU MessageFormat 1.0.
 
 ### Conformance
 
-Everything in this specification is normative except for: sections marked 
-as non-normative, all authoring guidelines, diagrams, examples, and notes.
+Everything in this specification is normative except for:
+sections marked as non-normative,
+all authoring guidelines, diagrams, examples, and notes.
 
-The key words `MAY`, `MUST`, `MUST NOT`, `OPTIONAL`, `RECOMMENDED`, 
-`SHOULD`, and `SHOULD NOT` in this document are to be interpreted as 
-described in BCP 14 [RFC2119] [RFC8174]. 
+The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED,
+SHOULD, and SHOULD NOT in this document are to be interpreted as
+described in BCP 14 [RFC2119] [RFC8174].
 
 ### Terminology and Conventions
 
-When a term is defined in this document, it is marked like ***this***. When
-a term is referenced in this document it is marked like _this_.
+When a term is defined in this document, it is marked like **_this_**.
+When a term is referenced in this document it is marked like _this_.