-
-
Notifications
You must be signed in to change notification settings - Fork 34
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
216 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,216 @@ | ||
| # 30 September 2024 | MessageFormat Working Group Teleconference | ||
|
|
||
| ### Attendees | ||
|
|
||
| - Addison Phillips - Unicode (APP) - chair | ||
| - Eemeli Aro - Mozilla (EAO) | ||
| - Elango Cheran - Google (ECH) | ||
| - Mihai Niță - Google (MIH) | ||
| - Richard Gibson - OpenJSF (RGN) | ||
| - Tim Chevalier - Igalia (TIM) | ||
| - | ||
|
|
||
| **Scribe:** EAO | ||
|
|
||
| ## Topic: Info Share | ||
|
|
||
| ### TPAC Fallout | ||
|
|
||
| APP: Physically present for half the conference; remoted in for the latter due to a cold. | ||
|
|
||
| EAO: I filed [this issue](https://github.com/w3c/webextensions/issues/698) after talking to webextension CG, which has FF, WK, Chrome support for adopting MF2 as soon as we adopt. Kind of discussed a year ago. Had an hour to present to them. Reception was very positive. Solves a real problem. Issue has more details about what’s involved, and what the state of play is… I think notes have been published if more interested. | ||
|
|
||
| … otherwise had good conversations with interesting people. Github, tiktok, others. Tiktok is potentially interesting, more than any other in US/EU, they have development in Chinese. Probably dealing somehow with sourcing in Chinese and then getting translate. Maybe hacking at it? Interesting problem? Dunno, hope to find out more. Will share. | ||
|
|
||
| EAO: Mention JS implementation is up to date with spec. Maybe missing a minor detail. NPM was down. Will update it. | ||
|
|
||
| ECH: program for UTW is now available. At least a couple sessions. Slots available. [https://www.unicode.org/events/utw/2024/](https://www.unicode.org/events/utw/2024/) | ||
|
|
||
| ### LDML 46 tag, branch, publication status | ||
|
|
||
| APP: Updated as of last week. | ||
|
|
||
| ## Topic: LDML46 and Beyond | ||
|
|
||
| - Review by ICU-TC and CLDR-TC | ||
| - Final work | ||
|
|
||
| APP: Obviously we’re not finishing tech preview quite yet. Mark has mooted finishing our work this calendar year, and proposed a 46.1 release for MF 2.0 (e.g. 20 Nov). Both ICU & CLDR committees have expressed interest in reviewing the spec. Somewhat worried about receiving comments after finishing the work, rather than before. Approval for a 46.1 release is not certain, though. | ||
|
|
||
| EAO: Reminds me of TG5 work. Ought to connect or addison, you, with the guy organizing the user study. | ||
|
|
||
| ECH: there was a meeting on wednesday. Did they talk survey? | ||
|
|
||
| EAO: I was there, yes, discussed survey and next steps. Gathering questions of content. Mentioned what APP proposed. Left on me to chase up. ECH, shall I include you? | ||
|
|
||
| ECH: Yes, that sounds good. | ||
|
|
||
| ## Topic: PR Review | ||
|
|
||
| *Timeboxed review of items ready for merge.* | ||
|
|
||
| | PR | Description | Recommendation | | ||
| | ----- | ----- | ----- | | ||
| | 859 | \[DESIGN\] Number selection design refinements | Merge (Proposed) | | ||
| | 846 | Add Unicode Registry definition | Discuss (634) | | ||
| | 842 | Match numbers numerically | Discuss (Reject) | | ||
| | 823 | Define function composition for :number and :integer values | Discuss | | ||
| | 814 | Define function composition for date/time values | Discuss | | ||
| | 806 | DESIGN: Add alternative designs to the design doc on function composition | Discuss | | ||
| | 799 | Unify input and local declarations in model | Discuss | | ||
| | 798 | Define function composition for :string values | Discuss | | ||
| | 728 | Add "resolved values" section to formatting | Blocked by 806 and 798 | | ||
| | 646 | Update spec as if PR 645 were accepted | Discuss | | ||
| | 584 | Add new terms to glossary | Discuss | | ||
|
|
||
| 859 | ||
|
|
||
| APP: Action on me to write some prose describing how this should happen. | ||
|
|
||
| 842 | ||
|
|
||
| APP: Leaving open while 859 is in flight. | ||
|
|
||
| ### Number Selection | ||
|
|
||
|
|
||
|
|
||
| ### Resolved Value Implementation | ||
|
|
||
| From [2024-09-10 call](https://github.com/unicode-org/message-format-wg/blob/main/meetings/2024/notes-2024-09-10.md): quote: | ||
|
|
||
| > CONSENSUS: | ||
| > | ||
| > * A function MUST define its resolved value. The resolved value MAY be different from the value of the operand of the > function. It MAY be an implementation specific type. It is not required to be the same type as the operand. | ||
| > | ||
| > * A function MUST define its resolved options. The resolved options MAY be different from the options of the function. | ||
| APP: Any concerns or objections? Is this still our consensus? | ||
|
|
||
| …: \[tumbleweed\] | ||
|
|
||
| ECH: Do we define “resolved value” in the spec? | ||
|
|
||
| EAO: It would be added by PR 728. | ||
|
|
||
| EAO: We should have a better place in the spec for providing these instructions to function authors. | ||
|
|
||
| APP: Maybe in the syntax’s function definition? | ||
|
|
||
| EAO: Would be more appropriately under “resolved value” in formatting, if we introduce that. | ||
|
|
||
| EAO: With this consensus, could we look again at 728 today, or later? | ||
|
|
||
| MIH: Add this for next week’s agenda? | ||
|
|
||
| APP: A solid read-through makes sense before considering it. | ||
|
|
||
| EAO: I’ll update 728 to include the above consensus for review during this week & approval next week. | ||
|
|
||
| #### 823 | ||
|
|
||
| … | ||
|
|
||
| MIH: We should not include currencies and units in :number formatting. | ||
|
|
||
| APP: Functions should say what they use, what they consume, what they emit. | ||
|
|
||
| MIH: Also add options. Are we being too specific? | ||
|
|
||
| EAO: With the proposed :string, :number, and :integer we’re covering this whole spectrum, as :string eats everything, :number passes everything through, and :integer filters out a few specific named options. | ||
|
|
||
| MIH: We should be lax with the restrictions we impose. | ||
|
|
||
| APP: A function should be specific about its side effects. | ||
|
|
||
| MIH: Worried about nailing this down for :number and :integer. | ||
|
|
||
| EAO: \[reads changes from PR\] | ||
|
|
||
| … | ||
|
|
||
| APP: Will review the PR again. | ||
|
|
||
| ## Topic: Issue review | ||
|
|
||
| [https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues) | ||
|
|
||
| Currently we have 49 open (was 50 last time). | ||
|
|
||
| * 3 are (late for) LDML46 | ||
| * 15 are for 46.1 | ||
| * 14 are `Preview-Feedback` | ||
| * 4 are `resolve-candidate` and proposed for close. | ||
| * 4 are `Agenda+` and proposed for discussion. | ||
| * None are ballots | ||
|
|
||
| | Issue | Description | Recommendation | | ||
| | ----- | ----- | ----- | | ||
| | 865 | TC39-TG2 would like to see completion of the TG5 study | Discuss, Agenda+ | | ||
| | 847 | [Conformance with UAX 31 & UTS 55](https://github.com/unicode-org/message-format-wg/issues/847) | Discuss, Agenda+ | | ||
| | 650 | Extra spaces in markup | Discuss, Agenda+ | | ||
| | 895 | The standard as is right now is unfriendly / unusual for tech stacks that are "native utf-16" | Discuss, Agenda+ | | ||
| | 837, 721, 650, 635 | (resolve candidates) | Close | | ||
|
|
||
| ### 847 | ||
|
|
||
| EAO: We should have Someone™ check if we’re now conformant. | ||
|
|
||
| APP: After discussion with Robin Berjon, we may be conformant now. I’ll do a check-through. | ||
|
|
||
| ### 650 | ||
|
|
||
| APP: Are you satisfied with the resolution, after our prior discussions? | ||
|
|
||
| MIH: It’s just an eyesore, if you ask me. HTML does not allow spaces before the tag identifier. The / is not a sigil like the others. It logically attaches to the {}, not the identifier. | ||
|
|
||
| EAO: For me, the analogy with HTML/XML breaks because we introduced options on closing markup, \`{/foo opt=bar}\`. | ||
|
|
||
| EAO: At the moment, the syntax uses sigils \`$ : / @\` as prefixes to the subsequent part of code, and allows whitespace (including newlines) quite liberally. Breaking this balance seems unnecessary. | ||
|
|
||
| … | ||
|
|
||
| MIH: Ok, let’s close it. | ||
|
|
||
| APP: We could ballot this. | ||
|
|
||
| … | ||
|
|
||
| MIH: I’m fine to let it be. | ||
|
|
||
| TIM: No issues implementing spec as is, no strong opinions on usability. | ||
|
|
||
| RGN: Does not look like a significant benefit or hindrance for usability. | ||
|
|
||
| ## Topic: Design Status Review | ||
|
|
||
| | Doc | Description | Status | | ||
| | ----- | ----- | ----- | | ||
| | bidi-usability | Manage bidi isolation | Accepted | | ||
| | dataflow-composability | Data Flow for Composable Functions | Proposed | | ||
| | function-composition-part-1 | Function Composition | Proposed | | ||
| | maintaining-registry | Maintaining the function registry | Proposed, Discuss | | ||
| | number-selection | Define how selection on numbers happens | Revision Proposed, Discuss | | ||
| | selection-declaration | Define what effect (if any) the annotation of a selector has on subsequence placeholders | Proposed, Discuss (Agenda+) | | ||
| | beauty-contest | Choose between syntax options | Obsolete | | ||
| | selection-matching-options | Selection Matching Options (ballot) | Obsolete | | ||
| | syntax-exploration-2 | Balloting of the revised syntax used in the Tech Preview | Obsolete | | ||
| | variants | A collection of message examples which require a branching logic to handle grammatical variations | Obsolete | | ||
| | formatted-parts | Define how format-to-parts works | Rejected | | ||
| | quoted-literals | Document the rationale for including quoted literals in MF and for choosing the | as the quote symbol | Accepted | | ||
| | builtin-registry-capabilities | Tech Preview default registry definition | Accepted | | ||
| | code-mode-introducer | Choose the pattern for complex messages | Accepted | | ||
| | data-driven-tests | Capture the planned approach for the test suite | Accepted | | ||
| | default-registry-and-mf1-compatibility | Default Registry and MF1 Compatibility | Accepted | | ||
| | delimiting-variant-patterns | Delimiting of Patterns in Complex Messages (Ballot) | Accepted | | ||
| | error-handling | Decide whether and what implementations do after a runtime error | Accepted | | ||
| | exact-match-selector-options | Choose the name for the “exact match” selector function (this is \`:string\`) | Accepted | | ||
| | expression-attributes | Define how attributes may be attached to expressions | Accepted | | ||
| | open-close-placeholders | Describe the use cases and requirements for placeholders that enclose parts of a pattern | Accepted | | ||
| | overriding-extending-namespacing | Defines how externally-authored functions can appear in a message; how externally authored options can appear; and effect of namespacing | Accepted | | ||
| | pattern-exterior-whitespace | Specify how whitespace inside of a pattern (at the start/end) works | Accepted | | ||
| | string-selection-formatting | Define how selection and formatting of string values takes place. | Accepted | | ||
| | variable-mutability | Describe how variables are named and how externally passed variables and internally defined variables interact | Accepted | | ||
|
|
||
| ## Topic: AOB? | ||
|
|