Create notes-2024-04-15.md

Author: aphillips

meetings/2024/notes-2024-04-15.md

@@ -0,0 +1,128 @@
+# 15 April 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Mihai Niță - Google (MIH)
+- Matt Radbourne - Bloomberg (MRR)
+- Richard Gibson - OpenJSF (RGN)
+- Staś Małolepszy - Google (STA)
+
+Scribe: MIH
+
+## Topic: Tech Preview
+
+LDML45-Tech-Preview branch and release created
+
+APP: Branch created, LDML45
+We can continue working on main.
+Post-preview work: plan and schedule. Will try to have a proposal for next time.
+
+## Topic: Planning for v46 work
+We have much to do…
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+|  PR  |                      Description                     |              Recommendation             |
+|:----:|:----------------------------------------------------:|:---------------------------------------:|
+| #769 | Add test:number and test:plural function definitions | Discuss                                 |
+| #768 | Provide link to MDN for options and their values     | Discuss                                 |
+| #767 | Add new test schema                                  | Discuss                                 |
+| #765 | Linkify the specification                            | Merge (non-normative)                   |
+| #757 | Tech Preview Blog Post                               | Merge                                   |
+| #755 | [DESIGN] Effect of selectors on placeholders         | Discuss                                 |
+| #754 | [DESIGN] Bidi usability                              | Merge                                   |
+| #753 | Add design doc on function composition               | LDML46                                  |
+| #744 | Fix design doc                                       | Merge (approved, waiting on bearfriend) |
+| #743 | Collapse all escape sequence rules into one          | LDML46                                  |
+| #728 | Add "resolved values" section to formatting          | LDML46                                  |
+| #704 | Address #703: make syntax/data model fallback clear  | LDML46                                  |
+| #673 | Fix whitespace conformance to match UAX31            | LDML46                                  |
+| #646 | Update spec as if PR #645 were accepted              | LDML46                                  |
+| #645 | Add design doc for dataflow for composability        | LDML46                                  |
+| #634 | Design doc to capture registry maintenance           | LDML46                                  |
+| #584 | Add new terms to glossary                            | LDML46                                  |
+| #558 | Add <when> to help select the right <match>          | LDML46                                  |
+
+
+### 765: script to linkify the spec
+
+AAP: Thanks to Eemeli
+Merged.
+
+### 754: [DESIGN] Bidi usability
+
+EAO: my mental model is that this is going to be use exclusively by tools
+Would be good to know how various editors handle these markers.
+
+APP: I confirm that this is most commonly for tooling.
+Using string directional markers are there for the messages to render properly, but these markers don’t show in code, selector, etc.
+
+MIH: talking about cat tools, most will extract the text from around the placeholders. May impact text editors, and review tools
+
+EAO: are still many cat tools that are not browser based?
+
+MIH: yes
+
+MIH: there are still a lot of problems in browser based tools. Browser based does not mean bidi is handled properly.
+
+### Testing
+
+APP: Thanks Mat for the schema (Add new test schema #767)
+And EAO (Add test:number and test:plural function definitions #769)
+
+EAO: My PR is not to test the number result, but that the implementation predictably produces digit 1 and one. Testing selection, not exact result.
+Same, we want to test behavior for correct / incorrect values for options (min/max Fractional, etc.)
+
+So not to test :number, but that the implementation does the right thing for complicated options.
+
+APP: we can create special tests for these.
+But also good to provide the ability for apps to test the behavior of the standard registry.
+For that we expect to be able to describe the existing result we expect.
+Any application would also test that the exact string is correct.
+
+EAO: Follow-up after the 2 PRs landed
+Expected value can be specified in several ways. MF, or calling with the real formatting.
+
+APP: what i would suggest is to rename things to avoid confusion.
+Like test-number-selection.
+
+MIH: added some comments to the PR. don’t have to depend on the formatter. Don’t test against real CLDR data. Maybe a regex, e.g. `*Mar*2024*` not test exact results. Was in my feedback.
+Basically tests that the implementation passes the proper params to the underlying formatter, and are honored.
+
+### PR 767: Add new test schema #767
+
+EAO: how do we version the schema?
+So that we don’t get locked in.
+
+But we can also version the paths, so that we can make changes later.
+
+MRR: my thinking was the latter (path).
+
+EAO: do we support BOTH “exp” and “error” at the same time.
+
+MRR: yes, both.
+
+EAO: we should not make the expected string mandatory.
+
+MIH: we need to be able to tell if something failed, even if we don’t specify the exact errors, or exp string.
+We have (had some weeks ago?) a file with input only, and all expected to fail, but the only indication of the fact that they fail was the file name.
+
+MRR: comment from MIH: split into sub-groups
+
+MRR: will land “as is” and reiterate.
+
+### Provide a link to MDN for options and their values #768
+
+APP: Squash and merge
+
+---
+
+EAO: would appreciate if we aim for an in person meeting in Anaheim (TPAC, 23-27 September)
+
+APP: walk in that meeting “close to done”
+
+APP: stake down for a face-to-face
+
+