Skip to content

Commit 9448040

Browse files
aphillipsaphillips
authored
Create notes-2025-06-23.md
1 parent 73fc2cf commit 9448040

File tree

1 file changed

+197
-0
lines changed

1 file changed

+197
-0
lines changed

‎meetings/2025/notes-2025-06-23.md‎

Lines changed: 197 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,197 @@
1+
# 23 June 2025 | MessageFormat Working Group Teleconference
2+
3+
Attendees:
4+
5+
- Addison Phillips \- Unicode (APP) \- chair
6+
- Mihai Niță \- Google (MIH)
7+
- Tim Chevalier \- Igalia (TIM)
8+
- Eemeli Aro \- Mozilla (EAO)
9+
- Richard Gibson \- OpenJSF (RGN)
10+
- Shane Carr \- Google (SFC)
11+
12+
13+
14+
**Scribe:** MIH
15+
16+
17+
## Topic: Info Share, Project Planning
18+
19+
Addison is seeking a new chair for the Working Group.
20+
21+
## Topic: PR Review
22+
23+
*Timeboxed review of items ready for merge.*
24+
25+
| PR | Description | Recommendation |
26+
| ----- | ----- | ----- |
27+
| \#1081 | Clarifications to resolved value section | Discuss |
28+
| \#1080 | Implement the simplified pattern select mechanism | Discuss |
29+
| \#1078 | Define time zone values and conversions | Discuss |
30+
| \#1077 | Include :datetime, :date, and :time with style options only | Discuss, Merge |
31+
| \#1076 | Make expErrors use an array (and only an array) | Discuss, Merge |
32+
| \#1068 | Design document for percent formatting | Merge |
33+
| \#1067 | Semantic skeletons design | Discuss |
34+
35+
36+
37+
## Topic: Issue review
38+
39+
[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
40+
41+
Currently we have 26 open (was 25 last time).
42+
43+
* 18 are tagged for 48
44+
* 3 are tagged “Future”
45+
* 10 are `Preview-Feedback`
46+
* 1 is tagged Feedback
47+
* 2 are `resolve-candidate` and proposed for close.
48+
* 2 are `Agenda+` and proposed for discussion (see below)
49+
* 1 is `PR-Needed` and needs a pull request
50+
* 0 are ballots
51+
52+
| Issue | Description | Recommendation |
53+
| ----- | ----- | ----- |
54+
| \#866 | CLDR semantic datetime skeleton spec is nearly ready and MF2 should use it | Discuss |
55+
| \#978 | Interoperability concerns and normative-optional features | Discuss |
56+
57+
## PR
58+
59+
### \#1080 Implement the simplified pattern select mechanism
60+
61+
APP: Most comments resolved, a few minor ones resolved. Can be offline.
62+
I feel a bit nervous. No proof that it produces the same result. I see Mark’s diction about “best”.
63+
And I am afraid that might change the result.
64+
65+
EAO: it does not
66+
67+
TIM: the old one was also not proved. This one is simpler.
68+
69+
SFC: it is easier to have the steps high level instead of the exact ... (?)
70+
71+
EAO: no intention to change the JS API.
72+
73+
MIH ... Missed a taking notes on a big chunk of the discussion, as I also participated.
74+
75+
APP: we are not changing what the selection does.
76+
77+
EAO: this is an editorial change, not a spec change, since we want it to do the exact same thing
78+
79+
MIH: if at implementation we find differences from the old algorithm we consider them bugs and we will update this
80+
81+
### \#1081 Clarifications to resolved value section
82+
83+
APP: bikeshed the name?
84+
85+
MIH: I am not very excited about “unwrap” as a name
86+
87+
### \#1078 Define time zone values and conversions
88+
89+
### \#1077 Include :datetime, :date, and :time with style options only
90+
91+
### \#1082 Syntax for semantic datetime field sets and options
92+
93+
EAO: anyone can have an example or use case for formatting a date and a time zone, but without a time.
94+
95+
APP: can’t think of a good example
96+
97+
EAO: so we don’t need to support timezone on a `:date`
98+
99+
MIH: … lost a lot of the discussion, sorry :-(
100+
101+
MIH: I don’t understand why the joining 1077 and 1082?
102+
103+
### \#1068 Design document for percent formatting
104+
105+
APP: I proposed balloting.
106+
107+
EAO: ICU4X requiring that the unit can be “sliced” in data
108+
Is that the ICU4X position, or SFC position?
109+
110+
APP: it is possible that we choose a design that does not imply units. But we will need to attack the units too at some point.
111+
So it is possible that we split the percent off. And if we put it in unit then we must solve that problem,
112+
113+
SFC: the only ICU4X position is the document that we shared at the beginning of the year, about data slicing. And that was only addressing the existing functions. So unit was not included at the time.
114+
So everything I said recent are my positions, not the ICU4X TC.
115+
116+
SFC: my position here is that if percent formatting requires `:unit` then it has to be sliceable.
117+
118+
EAO: can we request the ICU4X TC to review the currency and percent as they are proposed now in MF?
119+
120+
APP: yes, we can formally ask for a review / thoughts / design commentary.
121+
MF should be somewhat neutral about how implementations are done.
122+
We should not forgo our ability to do good or smart things because of ICU4X. But we should listen to what they have to say.
123+
Unit has to be resolvable before runtime. That might be a challenge for the implementation of `:unit`.
124+
125+
EAO: my understanding percentage format requires “lees knowledge” than formatting units in general.
126+
127+
APP: Mark would probably say that there are many categories of units. Some are straightforward, like “length”, but some are less obvious.
128+
And if that ends up affecting how you write the placeholder as a developer is not friendly
129+
130+
SFC: I understand you would want an opinion of the ICU4X TC, but the general position is quite clear.
131+
Currency and percentage are also affected by this problem.
132+
The crux of the matter is the result depending on info is only available at runtime.
133+
Link: affects the binary size. Different from load.
134+
If it is something in the message string it can be sliced.
135+
136+
SFC: currency, if we don’t use long / full forms, is relatively compact.
137+
138+
SFC: if you are using units with percent that is small enough, and can be handled if it is in the message itself. A measure as input is the big problem for data slicing and linking.
139+
140+
EAO: from the TC would be nice to hear what units would be fine to include or not.
141+
We have a desire to have the unit formatting left to the variable being formatted.
142+
What are the “buckets” acceptable to ICU4X.
143+
If you want bickets, you come with the buckets, or we should come with them?
144+
145+
EAO: and the other one is currency formatting. What would be the ICU4X position for the long form?
146+
How to express that in a way that users understand.
147+
148+
SFC: those requests are clear and reasonable.
149+
But because of vacations and what not we are unlikely to get answers in the next few weeks.
150+
At the beginning of Q3 is more likely.
151+
152+
SFC: would help to see the results from balloting.
153+
List all options, with pros and cons, and send them for a ballot.
154+
That would allow us to get it in CLDR 48\.
155+
156+
EAO: it is vital to find out what buckets we end up with.
157+
If :unit is a catch all it would be weird to have a :percent as a standalone.
158+
But if we have buckets then the percent will end up in one of these buckets.
159+
So I would not want, in that case, to also have a percent on `:number`
160+
161+
APP: I hear you about needing a ballot
162+
163+
EAO: I don’t object to a non-binding ballot
164+
165+
SFC: percent is not a category. The bucket for percent would be “portion”, I will need to double-check.
166+
Includes per million, per billion, and so on, not just percent.
167+
As long as we can figure out from analyzing the message what unit will be used it’s OK.
168+
169+
EAO: if ICU4X says that some amount of bucketing is fine I am good to go with that.
170+
So would be ICU4X ok with SOME bucketing? As an official position.
171+
172+
SFC: we can list pros and cons. Depends on the needs of our consumers.
173+
MF has probably a better feel on what the users need.
174+
175+
SFC: the way we implement unit formatting is based on these categories based slicing.
176+
They are also sliced by length.
177+
That’s what we have in the branch, and this is probably what we will land.
178+
One unit per bucket is probably too granular. We would need to add buckets all the time.
179+
We don’t want to do that for each CLDR release.
180+
So category \+ length is what we will end up.
181+
182+
MIH: wanted to say that we cannot have per unit slicing not only because inconvenient to add buckets all the time. In android i can have a preference as a system setting for something like imperial units. Can’t know when building the app if i prefer miles or km. cannot be too granular. Need some kind of bucketing. Separate function per bucket. Feels undiscoverable. Suppose the same for many buckets names. Some are hard to imagine.
183+
184+
APP: something similar. CLDR / ICU4X / MF should be a “big happy family” and need to work nicely together. We should harmonize across.
185+
186+
SFC: CLDR had these buckets for years. Not used for slicing, but existed for years.
187+
188+
EAO: can we get a list of all of these buckets? To see if they work as function names.
189+
190+
MIH: acceleration, angle, area, concentr, consumption, digital, duration, electric, energy, force, frequency, graphics, length, light, magnetic, mass, power, pressure, proportion, speed, temperature, torque,
191+
192+
### \#1076 Make expErrors use an array (and only an array)
193+
194+
MIH: sorry, I didn’t implement the change from “Bad Operand” to “Bad Option”
195+
196+
EAO: My concerns are separate from this. I might file an issue or PR. We lack a clear differentiator, or maybe update the test suite, to check that we differentiate between formatting and selection errors.
197+

0 commit comments

Comments
 (0)