Create notes-2024-09-30.md

Author: aphillips

meetings/2024/notes-2024-09-30.md

@@ -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?
+