Skip to content

Commit ba754d3

Browse files
aphillipsaphillips
authored
Create notes-2024-11-18.md
1 parent 42daa20 commit ba754d3

File tree

1 file changed

+331
-0
lines changed

1 file changed

+331
-0
lines changed

‎meetings/2024/notes-2024-11-18.md‎

Lines changed: 331 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,331 @@
1+
# 18 November 2024 | MessageFormat Working Group Teleconference
2+
3+
4+
### Attendees
5+
6+
- Addison Phillips \- Unicode (APP) \- chair
7+
- Mihai Niță \- Google (MIH)
8+
- Eemeli Aro \- Mozilla (EAO)
9+
- Tim Chevalier \- Igalia (TIM)
10+
- Elango Cheran \- Google (ECH)
11+
- Richard Gibson \- OpenJSF (RGN)
12+
- Matt Radbourne \- Bloomberg (MRR)
13+
- Harmit Goswami \- Mozilla (HGO)
14+
- Mark Davis \- Google (MED)
15+
16+
17+
**Scribe:** ECH
18+
19+
20+
## [**Agenda**](https://github.com/unicode-org/message-format-wg/wiki#agenda)
21+
22+
## Topic: Info Share
23+
24+
### Topic: PR Review
25+
26+
*Merge what is mergeable. Close what is closeable.*
27+
28+
### Topic: Issue Review
29+
30+
*Review 46.1 issue list.*
31+
32+
### Are we done?
33+
34+
*Call to submit MessageFormat 2.0 for balloting by the working group. If approved in next week’s call, the resulting specification would be (hopefully) approved by CLDR-TC for publication in v46.1 and made final in v47 in the spring. This is the last chance to discuss if we have accomplished our goals.*
35+
36+
MED: Are we basically ready to go to review and balloting.
37+
38+
APP: We have a few issues to fast track. There is a cleanup PR to update versions and make a statement about CLDR v46.1 and its maturity. That PR will be the sweeping up of broken glass, and should be editorial. Once all of that is merged, that is what we send to CLDR-TC. I would like to ballot this as a WG. According to our schedule, I would like to complete this by the next time we have a call. That suggests that we finish all of our merging and cleanup work by Wednesday (2 days). There is no point to do any of that if we’re not ready. Does anybody here think we’re not ready?
39+
40+
APP: No objections heard. I think our WG consensus is, “Here is MF2.0” once we get those few small PRs finished up.
41+
42+
MED: Send that around to ICU and ICU4X.
43+
44+
APP: The ballot will be sent to MFWG.
45+
46+
MED: And then that will be conveyed to the CLDR-TC.
47+
48+
APP: Yes.
49+
50+
### Topic: Cleanup
51+
52+
*There is a need for an end-to-end cleanup of the spec (removing Tech Preview comments from v45, addressing minor editorial issues). The chair proposes to make a PR to accomplish this before labeling the official release candidate and producing HTML in the LDML spec. Let’s discuss the logistics of this.*
53+
54+
### Topic: Resolving :math or offset (#932)
55+
56+
*The chair merged #932 in spite of Mihai’s unresolved comment. We need to consider if changes to :math should be made or the function reverted in favor of e.g. an \`offset\` option. PR link: [view it on GitHub](https://github.com/unicode-org/message-format-wg/pull/932#issuecomment-2480160980)*
57+
58+
### Topic: Unit Formatting (#922)
59+
60+
*Last week we discussed taking :unit as optional if our work was done. Propose merging it.*
61+
62+
## **Topic: PR Review**
63+
64+
*Timeboxed review of items ready for merge.*
65+
66+
| PR | Description | Recommendation |
67+
| ----- | ----- | ----- |
68+
| #945 | Internationalize :math example | Merge |
69+
| #944 | Address “implementation-defined” literal and type values | Discuss, Merge |
70+
| #943 | Rename :currency option currencySign as sign | Discuss, Reject |
71+
| #942 | Always apply isolation when u:dir is set | Discuss, Merge |
72+
| #941 | Linkify stability policy | Merge |
73+
| #940 | Add tests for :currency | Merge |
74+
| #939 | Drop exp value for :number tests with bad option values | Merge |
75+
| #923 | Test schema: allow src property to either be a string or array of strings | Discuss, Merge |
76+
| #922 | Implement :unit as OPTIONAL in the registry | Merge |
77+
| #911 | Define locale options for :datetime :date and :time | Discuss, Merge |
78+
| #584 | Add new terms to glossary | Reject |
79+
80+
### #945 Internationalize :math example
81+
82+
APP: I opened this to fix the plural example to use the \`ONE\` category instead of \`=1\` as is proper i18n practice. Any objections? No.
83+
84+
### #944 Address “implementation-defined” literal and type values
85+
86+
APP: The title is no longer accurate. Any objections
87+
88+
### #943 Rename :currency option currencySign as sign
89+
90+
APP: EAO and I discussed how the option name might be confused with the sign display might be confusing. MIH, you weighed in as saying “symbol” might be good.
91+
92+
APP: To clarify, the id
93+
94+
ECH: is this already called a symbol in ICU?
95+
96+
MIH: Yes.
97+
98+
ECH: And “sign” typically refers to the plus or minus. The ICU NumberFormatter API is the newer
99+
100+
EAO: The PR comes from matching the JS option that is relevant. Hearing that ICU does not have separate options
101+
102+
### #942 Always apply isolation when u:dir is set
103+
104+
APP: I think this is the right thing to do because it forces isolation and respect the \`u:dir\` value.
105+
106+
EAO: One small exception. You can give the value \`inherit\`. If the text direction is LTR and teh placeholder is LTR, then with \`inherit\`, the isolation is left out.
107+
108+
EAO: This also requires implementers to retain in the Resolved Value what the directionality of that placeholder or expression is.
109+
110+
MIH: I don’t understand because EAO previously insisted that Resolve Values may not have a string. If there isn’t necessarily a string, how do we have a direction?
111+
112+
APP: Let me ask this a different way. Do any of our implementations not have a default Bidi direction strategy?
113+
114+
MED: There was a proposal some time ago about the depth of the Bidi level. At the time of writing the spec, we thought that 16 was a reasonable limit of depth. In HTML, in practice, the depth level has exceeded that limit to an extent we didn’t predict.
115+
FYI “maximum explicit level of 125”
116+
117+
EAO: I don’t know if other implementations have implemented MF2’s default Bidi strategy. When getting to implement them, I noticed some oddities about them. If we don’t preemptively apply the UAX 9’s P2 rule, then we end up with isolation. What that means is that we still need to track whether \`u:dir\` was set on a placeholder.
118+
119+
MED: I think it’s fine to say, “always apply isolation when \`u:dir\` is set, but implementations can differ in how they achieve that”, and then we are covered.
120+
121+
MIH: We keep listing the Unicode control characters for Bidi, but in HTML, W3C recommends that we use spans with attributes. So it’s not just about control characters.
122+
123+
APP: To your point, MIH, that is about markup strategies, but this discussion topic is about default direction strategies. Implementations should have the ability to ignore that. I propose that we do not merge this PR.
124+
125+
EAO: Can we merge the PR?
126+
127+
APP: The PR won’t make your life worse, and perhaps a little better.
128+
129+
MED: I have no objection to merging, and we can come back and tweak this later if need to.
130+
131+
### #941 Linkify stability policy
132+
133+
APP: Just an editorial change. Linkifies the stability policy, which I should have done before. It clarifies that Markdown is normative, and whether notes are normative. MED, do you think a formal statement is necessary.
134+
135+
MED: I felt like it went better in that section of the document because it’s talking about what you can do with function and options and option values.
136+
137+
APP: The one thing materially different is that you actually mention operands. Do you think we need to mention that as something we might deprecate?
138+
139+
MED: No, I don’t think we need to. It’s really functions, options, and option values. If I wrote operands, I was mistaken.
140+
141+
EAO: The thing in the list is already fine. Since this PR already says important content is already normative. If we want to add that, then remove the list item since it’s a duplicate.
142+
143+
MED: Okay, looking at it, then we don’t need to add the change.
144+
145+
APP: Oaky, so can I merge it as it is?
146+
147+
### #940 Add tests for :currency
148+
149+
APP: MIH and others have approved this. Any objections? None heard.
150+
151+
### #939 Drop exp value for :number tests with bad option values
152+
153+
APP: Any thoughts from TIM or MRR?
154+
155+
MED: This looks good to me.
156+
157+
MIH: On the Java side of ICU, the way you format messages is you set a flag on how to handle errors when creating the formatter. So you have to set that ahead of time.
158+
159+
APP: Except that doesn’t work for our tests since we allow people to choose how they implement that, and we make the tests support either choice.
160+
161+
MIH: Okay.
162+
163+
### #923 Test schema: allow src property to either be a string or array of strings
164+
165+
### #922 Implement :unit as OPTIONAL in the registry
166+
167+
MIH: Are there locales that depend on the unit and the formatting thing.
168+
169+
MED: For gender, sometimes the definiteness does matter.
170+
171+
APP: Is that something that we specify as a caution in the documentation?
172+
173+
MED: Yes.
174+
175+
EAO: Commenting on what MIH says, when you have a match on \`:unit\`, then matching is numeric. But if there’s a gendered unit, then it depends. Overall, I don’t think the PR is not ready today. It might be ready in a couple of weeks, but not now. And that’s okay since we can include this in a later version of the spec so that I can have time to work on it.
176+
177+
APP: It’s still an optional function currently.
178+
179+
MED: It might be useful to get it in to a draft spec so that get people beta testing.
180+
181+
EAO: I would like more time to work on it, and I want to respect the stability policy, too.
182+
183+
MED: What you’re calling for is no references to external specs, which seems like a very drastic change this late in the game.
184+
185+
APP: I agree that it’s trickier. I think that we would want to ensure interoperability by providing a baseline and without pointing at other standards. We don’t want to allow people to just use any such string for the identifiers. I realize that we are coming in hot with this \- we are looking at this a lot at the last minute.
186+
187+
EAO: If we state that the stability policy does not apply to \`:unit\` and we don’t have the \`SHOULD\` language for the options of \`:unit\`, then I would be okay including this in time for v46.1 because I would still want to change it in the future.
188+
189+
MED: I think that would work. Anyone opposed?
190+
191+
APP: That sounds okay. We don’t need to make a change here. I still want to break it out. In a separate doc.
192+
193+
### #911 Define locale options for :datetime :date and :time
194+
195+
EAO: It feels like the discussion of “valid” and “well formatted” are not yet decided. So I don’t think it’s ready to merge. We can include the optional options.
196+
197+
APP: I feel strongly about time zone options should be included. We have a WG consensus to make the hour display option as hour12.
198+
199+
MED: We can look at how CLDR does this.
200+
201+
APP: I have opinions about that, so we should discuss this.
202+
203+
APP: We should make that a separate thing. I think that calendar and numbering system are not that controversial. Making those optional seems reasonable. The problem is resolving the well formed vs. valid conversation. We should have 3 PRs for those three parts.
204+
205+
MED: I wonder about a PR defining the calendar and numbering system.
206+
207+
APP: When it comes to numbering systems, there are a few that are defined. I would prefer that we point to an existing spec that defines them rather than trying to list them ourselves.
208+
209+
MED: What we have not done is put the ABNF in there, but we can for the 46.1 timeframe.
210+
211+
APP: We agree we should do something, and that we should put it in \`formatting.md\` because that’s where the formatting options belong. And we should specify normative behaviors.
212+
213+
MIH: I agree that we shouldn’t put the exact description of the identifiers here. I agree with EAO that you should explain what the identifiers are.
214+
215+
EAO: I agree that we should not try to create ABNF for things we don’t control, like IANA time zone identifiers.
216+
217+
EAO: The question is when should a function blow up with an unsupported option or value, and when does it blow up on an unsupported operation. The latter has an unlimited number of possibilities.
218+
219+
APP: What I want to stay away from is that people feel like they have to have the list and keep it updated.
220+
221+
MED: That discussion belongs in the other document about “what do you with options, and do you have to support them all?”
222+
223+
APP: We will make those 3 PRs. One will have hour12 and date time override options. I will make the one about time zone options because I feel strongly about that. And the PR about numbering system and calendar, someone can create that and put that in.
224+
225+
### #584 Add new terms to glossary
226+
227+
APP: It’s been open for a while. My suggestion is that we close this and suggest changes to documentation in the future. Any objections? None heard.
228+
229+
## Topic: Issue review
230+
231+
[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
232+
233+
Currently we have 31 open (was 30 last time).
234+
235+
* 13 are tagged for 46.1 (3 are blocker-candidate)
236+
* 6 are tagged for 47
237+
* 4 are tagged “Seek-Feedback-in-Preview”
238+
* 5 are tagged “Future”
239+
* 6 are `Preview-Feedback`
240+
* 8 are `resolve-candidate` and proposed for close.
241+
* 3 are `Agenda+` and proposed for discussion.
242+
* None are ballots
243+
244+
| Issue | Description | Recommendation |
245+
| ----- | ----- | ----- |
246+
| #937 | Clarify boilerplate about operand and resolved value | Agenda+ |
247+
| #936 | Add short timezone identifies | Agenda+ |
248+
| #935 | Well-formed vs. valid | Agenda+ |
249+
| #847 | Conformance with UAX31 and UTS55 | Blocker-candidate |
250+
| #843 | Create complete tests for syntax | Blocker-candidate |
251+
| #838 | Unit and currency formatting should be supported | Blocker-candidate, Resolve (waiting on #922) |
252+
| #916 | Default functions should manage their own directionality | Resolve |
253+
| #856 | Update CLDR test data | Resolve |
254+
| #819 | \[FEEDBACK\] semantic diff between local and input | Resolve |
255+
| #818 | \[FEEDBACK\] reuse of :function between annotation and output | Resolve |
256+
| #724 | \[FEEDBACK\] MF unquoted literals | Resolve |
257+
| #680 | Restrict literals for :date and :time | Resolve |
258+
| #663 | Provide structure in the registry for distinguishing types of options | Resolve |
259+
260+
### #916 Default functions should manage their own directionality
261+
262+
APP: EAO and I had a long discussion and agreed to not make a change.
263+
264+
EAO: I agree. You explained that the language that we already have includes spillover.
265+
266+
### #856 Update CLDR test data
267+
268+
APP: At one point in time, we depended on CLDR data. But we have modified our tests not to. Unless I’m reading that wrong?
269+
270+
TIM: I thought the issue was to merge the tests in the MFWG repo to upstream the test data to CLDR, since CLDR is the source of truth.
271+
272+
APP: Is there a task?
273+
274+
TIM: Someone should create a PR on CLDR to update the test data.
275+
276+
ECH: I can do that.
277+
278+
### #838 Unit and currency formatting should be supported
279+
280+
APP: Are we fine with closing it?
281+
282+
EAO: I would be fine to close it.
283+
284+
MED: Yes, same.
285+
286+
### #937 Clarify boilerplate about operand and resolved value
287+
288+
MED: This seems too big to take up now.
289+
290+
### #936 Add short timezone identifies
291+
292+
APP: Should I defer this to CLDR v47? It will go with the PR on time zones.
293+
294+
MED: Yes, it should go with the PR on time zones.
295+
296+
### #935
297+
298+
MED: Let’s leave this open. It might change radically.
299+
300+
### #931
301+
302+
APP: This depends on me. It goes in before we have a final spec. I will leave that for now.
303+
304+
### #889
305+
306+
APP: This is about how to minimize the default serialization for messages. It will be a bit of work to produce. I don’t think it’s strictly necessary to ship in v46.1.
307+
308+
APP: I have tagged that for v47.
309+
310+
### #866 Semantic skeletons
311+
312+
APP: Do we actually have time to fit this in?
313+
314+
MED: This isn’t quite ready.
315+
316+
APP: Yes, let’s defer to v47.
317+
318+
### #847
319+
320+
APP: I haven’t reviewed this. I think we are conformant now.
321+
322+
### #842 Create complete tests for syntax
323+
324+
APP: I think this is relatively done now. Is this complete?
325+
326+
TIM: I think this is close enough, even though nothing is going to be complete.
327+
328+
## **Topic: AOB?**
329+
330+
-
331+

0 commit comments

Comments
 (0)