8000 Create notes-2024-01-22.md · unicode-org/message-format-wg@08e7793 · GitHub
[go: up one dir, main page]
Skip to content

Commit 08e7793

Browse files
aphillipsaphillips
authored
Create notes-2024-01-22.md
1 parent 24f33d6 commit 08e7793

File tree

1 file changed

+194
-0
lines changed

1 file changed

+194
-0
lines changed

‎meetings/2024/notes-2024-01-22.md

Lines changed: 194 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,194 @@
1+
# 22 January 2024 | MessageFormat Working Group Regular Teleconference
2+
3+
### Attendees
4+
- Addison Phillips - Unicode (APP) - chair
5+
- Ujjwal Sharma - Igalia (USA)
6+
- Staś Małolepszy - Google (STA)
7+
- Eemeli Aro - Mozilla (EAO)
8+
- Mihai Niță - Google (MIH)
9+
- Tim Chevalier - Igalia (TIM)
10+
- Matt Radbourne - Bloomberg (MRR)
11+
- Zibi Braniecki - Amazon (ZBI)
12+
13+
Scribe: STA
14+
15+
16+
## Topic: Action Item Review
17+
~~Set up F2F calls for 12-15 February (APP)~~
18+
~~Set up calls about registry format (APP)~~
19+
> Happening Thursday, January 25, at 10a PST, 7p CET.
20+
~~Set up call with EAO about bidi (APP)~~
21+
22+
## Info Share
23+
24+
APP: MFWG (Virtual) Open House will be February 22
25+
26+
## Topic: Progressing to Done
27+
28+
The main blockers appear to be the following:
29+
- ~~Beautification of the syntax discussion~~
30+
- ~~What’s in a name? (Does NCName fix our woes? Go to UAX31? what?)~~
31+
- ~~Quoting~~
32+
- ~~Format-to-Parts~~
33+
- ~~Spannables~~
34+
- ~~Expression Attributes~~
35+
- Registry and default functions
36+
- Implementation and testing
37+
38+
39+
Schedule:
40+
1. No new LDML45 issues after 15 January.
41+
2. All LDML45 issues resolved by end of F2F. Balloting alpha spec to occur 15 February.
42+
3. Beta spec and registry by 11 March.
43+
4. Can make limited changes thereafter, for issues discovered by implementers.
44+
5. Release 10 April as part of LDML45
45+
46+
## Topic: Pattern Initial Whitespace (#610)
47+
48+
Should we support whitespace before a complex message start? With what effect on simple messages?
49+
50+
EAO: The message doesn't look broken.
51+
52+
STA:
53+
54+
USA: Is this a JavaScript-specific problem? Does https://github.com/tc39/proposal-string-dedent fix it?
55+
56+
ECH: I'm strongly opposed to this issue. It's rehashing the discussion about pattern external whitespace that we had.
57+
58+
APP: I also missed it. I think the lookahead could work. It's going to be slightly more complex, because we need to scan for .keywords AND {{. Is it worth it?
59+
60+
MIH: I think it is a problem. People will be puzzled. I don't think trimming leading whitespace is the only solution. We could re-consider a complex message introducer marker, for example: {!}
61+
62+
STA:
63+
64+
EAO: I'm kind of OK with not doing anything here. It means that messages embedded in code are not our first priority. We're effectively saying: please use a resource format.
65+
66+
APP: I don't want to undo the whitespace discussion if we don't need to. but also, I'm sensitive to the lived experience of our users. Can we keep it unchanged for now, and see what the tech preview feedback brings?
67+
68+
ECH: If reopening pattern external whitespace is on the table, why not consider the pre-Seville syntax? We've reached a delicate balance of design tradeoffs. If feedback tells us it's a problem, then fixing this one issue will result in losing the balance. Need to be careful. (This is STA's interpretation of ECH's comment; I didn't manage to record it verbatim in the notes.)
69+
70+
STA: Do we have a label for issues that we want to listen to feedback about?
71+
72+
APP: I'll create one. (`Seek-Feedback-in-Preview` is the label)
73+
74+
EAO: Request to implementors: consider adding telemetry to discover such issues.
75+
76+
TIM: Not aware of any such functionality.
77+
78+
MIH: Another way: assign a very specific error code or error message, so that people can use it to report.
79+
80+
EAO: We could go further: agree on an error naming scheme, so that we can collect feedback across implementations.
81+
82+
## Topic: Modifying Our Goals
83+
84+
@macchiati is working on sending out a call for review to the wider CLDR and Unicode Member community. As part of that, he and I started to revise some of our documentation. In #609, we modify a number of our documented goals. Are we cool with these changes?
85+
86+
STA: The new wording is mostly about grammar, while the previous one hinted at other reasons for multiple variants. I guess that's OK; it doesn't mean we're removing custom functions.
87+
88+
APP: Any objection to merging? (silence) Merged.
89+
90+
## Topic: Testing
91+
92+
Elango would like to talk about contributions to Data Driven Tests, for example https://unicode-org.github.io/conformance/
93+
94+
We need to build our test suite.
95+
96+
@eemeli has brought us some starter tests. They are helpful, but incomplete. Let's discuss our testing approach and get volunteers to ensure we build a hearty test suite.
97+
98+
ECH: Data-driven testing (aka conformance). A tool for testing i18n libraries: for given input, produce the expected output. It also includes generated dashboards which show different libraries (dart, icu4c, icu4j, icu4x, node) x intl features: collation, lang_names, likely_subtags, number_fmt. One of the objectives for Q1 is to add a new row: MF2. We also categorize test results: pass, fail, error. (Clicks through one of the charts.) You can drill into all aggregated results and see individual errors.
99+
100+
APP: Are there specific formats that can be fed into this?
101+
102+
ECH: There's a schema for input ("test") and output ("results"): https://github.com/unicode-org/conformance/tree/main/schema/number_format
103+
104+
EAO: How does my PR of tests match this? How do you define the canonical result?
105+
106+
ECH: At some point you need to choose what's authoritative. ICU is deployed pretty much everywhere; icu4c is the starting point.
107+
108+
EAO: So this is a test suite for testing conformance with icu4c?
109+
110+
ECH: No, it's more about the best practice for i18n.
111+
112+
APP: Each section of the spec should have tests, so that implementations can say: I'm conformant.
113+
114+
APP: MRR, looking forward to your PR.
115+
116+
MRR: I think it's going to be a duplicated effort. The test runner does something similar, the schemas are similar.
117+
118+
APP: MRR's schema is still something that would be needed in Unicode's conformance tests. And that work hasn't started yet.
119+
120+
EAO: Is it possible to manually provide the expected result of formatting functions?
121+
122+
STA: Skimming [the design doc on tests](https://github.com/unicode-org/message-format-wg/blob/main/exploration/data-driven-tests.md), we explicitly considered Unicode Conformance as an inspiration. I guess MRR's schemas are probably similar?
123+
124+
MRR: Yes, it was an inspiration. There's also a test runner.
125+
126+
APP: Let's get our house in order first; let's consider conformance later. MRR, please coordinate with ECH and EAO.
127+
128+
## Topic: Allow Options on Closing Markup Placeholders
129+
130+
We need to close this topic, which is the last material ABNF change under consideration.
131+
132+
EAO: I'd like to see an example of a message which would benefit from this.
133+
134+
MIH: I have some examples, but haven't documented them: ANSI escapes, RTF. I feel uneasy not supporting this just because of XML.
135+
136+
APP: We need to freeze the ABNF. Let's decide next week. MIH and STA, please work on documenting the use-cases.
137+
138+
## Topic: A name other than :number for plural selection
139+
140+
@mihnita filed #605 about the default selector behavior of :number (which is identical to :plural). Do we want to revisit that decision?
141+
142+
APP: Dropping the selector (provided the variable has been annotated with a :number before) works and is more convenient. Also consistent with other selectors work.
143+
144+
MIH: Which other format functions also select?
145+
146+
APP: :string does. In the future, presumably datetimes?
147+
148+
MIH: And that would be the same problem then, what does it mean to match on a date? Which part of it would the matching involve?
149+
150+
MIH: Matching on a :number is ambiguous: it's not clear that 12 matches on "many". Why wouldn't it format to a string and do a string equality test?
151+
152+
APP: Is there an appetite for this change? (silence)
153+
154+
STA: Mihai's proposal makes usage of function clear: one for formatting, the other for selecting. Currently, :number does both, :plural only selects. It's thus a matter of personal preference whether
155+
156+
157+
## Topic: Active PR review
158+
Discussion of active PRs. We will merge or reject them in the call.
159+
160+
| PR | Description | Recommendation |
161+
|:----:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------:|
162+
| #609 | Update repo documentation including README and goals | Discuss |
163+
| #604 | Add a JSON test suite APP confirmed with Unicode's legal team that it's OK to merge this. EAO: GWR requested to remove the old XML-based tests. |
164+
| #584 | Add new terms to glossary | Future |
165+
| #582 | Allow options on closing markup placeholders | Discuss |
166+
| #570 | Add :date and :time aliases | Discuss |
167+
| #560 | Add a <matchSignature> for :number together with :ordinal and :plural aliases | Discuss |
168+
| #558 | Add <when> to help select the right <match> | Future (separate call pending) |
169+
170+
* #604
171+
APP: anyone want to keep them? (silence)
172+
173+
EAO: I'll remove them in this PR. EAO: requesting other people contribute. Right now, they're written with ECMA402 in mind.
174+
175+
TIM: I've got additional tests in icu4c.
176+
177+
MIH: Similar story about icu4j. Will contribute.
178+
179+
MIH: Should we first look at the XML tests that we want to remove? Maybe there's something in there?
180+
181+
MRR: Almost ready with data-drive test format, YAML schema + test runner with integrates with EAO's polyfill.
182+
183+
EAO: Would prefer to first remove them, then possibly re-add in the conforming format.
184+
185+
STA, ECH: Agreed.
186+
187+
RESOLVED: Merge after EAO removes the XML-based files.
188+
189+
190+
191+
## Topic: AOB?
192+
193+
Next time: * variants
194+
Next time: https://github.com/unicode-org/message-format-wg/blob/main/exploration/default-registry-and-mf1-compatibility.md

0 commit comments

Comments
 (0)
0