Skip to content

Commit 530e63b

Browse files
aphillipsaphillips
authored
Create notes-2024-10-28.md
1 parent 1baac19 commit 530e63b

File tree

1 file changed

+259
-0
lines changed

1 file changed

+259
-0
lines changed

‎meetings/2024/notes-2024-10-28.md‎

Lines changed: 259 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,259 @@
1+
# 28 October 2024 | 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+
- Richard Gibson - OpenJSF (RGN)
9+
- Staś Małolepszy - Google (STA)
10+
- Harmit Goswami - Mozilla (HGO)
11+
- Luca Casonato - unaffiliated (LCA)
12+
- Matt Radbourne - Bloomberg (MRR)
13+
14+
**Scribe:** HGO
15+
16+
17+
To request that the chair add an *issue* to the agenda, add the label `Agenda+` To request that the chair add an agenda item, send email to the message-format-wg group email.
18+
19+
## [**Agenda**](https://github.com/unicode-org/message-format-wg/wiki#agenda)
20+
21+
22+
## Topic: Info Share
23+
24+
- \[APP\]: did a presentation at UTW last week, went pretty well, there will be a recording
25+
26+
## Topic: Schedule for Release
27+
28+
## Topic: \`resolve-candidate\`
29+
30+
*The following issues are proposed for resolve:*
31+
(none this week)
32+
33+
34+
### Topic: various bidirectional PRs (\#919, \#917)
35+
36+
*Let’s discuss the implementation of bidi and details thereof.*
37+
38+
### Topic: Clarify eager vs. lazy evaluation (\#901)
39+
40+
*This PR exposes the problem of function handlers that might evaluate differently in different parts of a message, e.g. “getCurrentSystemTime”. Tim did revise the text. Let’s discuss.*
41+
42+
- \[APP\]: STA you were interested in discussing this. TIM, this was your PR
43+
- \[TIM\]: My current PR talks about two things: implementations should not create function handlers that change state outside of MessageFormat, and if you have states which depend on external states, give a warning. I see comments from APP but have not yet addressed them
44+
- \[APP\]: Any thoughts? (none)
45+
- \[STA\]: Can we get an overview of what triggered these changes?
46+
- \[TIM\]: I filed an issue some time ago about clarifying spec, not sure what brought it up since it was months ago so sadly I don’t have a good answer. It wasn’t an implementation thing, just from looking at the spec and thinking about implications
47+
- \[APP\]: The first thing is non-controversial, then the question becomes about evaluation patterns. Is having such a strict requirement on evaluation a hindrance on users rather than making MessageFormatter reliable?
48+
- \[MIH\]: As an implementer, I think it’s fine as is. By that I mean “as proposed”
49+
- \[APP\]: If you want to make those edits and if anyone has comments on those edits, please do so before the next meeting
50+
- \[TIM\]: Sure
51+
52+
### Topic: Fix fallback value definition and use (\#903, \#920)
53+
54+
*We discussed (and merged) 903 last week. This is the fallout.*
55+
56+
- \[APP\]: I created a PR this morning to address the fallout. I expect no one has looked it over yet, but any topics to discuss? It basically says order of evaluation doesn’t matter
57+
- \[MIH\]: I think it’s small and non-controversial enough that I’m fine with it right now
58+
59+
### Topic: Add a :number offset option (\#701)
60+
61+
*Mark proposed adding an \`offset\` option to \`:number\` for parity with MF1. We discussed including this last week, but need a PR.*
62+
63+
- \[APP\]: I tried to work on this, but you need to go through all places with an operand and number selector. I didn’t create a PR, anyone want to take over?
64+
- \[MIH\]: I can take it\!
65+
66+
### Topic: Currency and Unit Formatting (\#838, \#908, \#915)
67+
68+
*Last week we discussed separating functions. Addison has proposed the currency function. Unit remains to be done. We need to consider whether to make these standard or optional.*
69+
70+
- \[APP\]: The proposal at UTW to keep them separate seemed to be well-received. Is this what we want, is \#915 correct, and should these be required or optional for implementations? Units cannot be required because not everyone has units, so it seems like it should be optional
71+
- \[MIH\]: By this time, most implementations should have a way to deal with currencies? I like to have them separate from number formatter, but I'm not so sure about percentage.
72+
- \[APP\]: Operand for percent would be a number operator
73+
- \[MIH\]: Right, so that feels more like a number formatter thing. Currency doesn’t feel like that
74+
- \[TIM\]: What would happen if you compose that with other functions? Not sure if the behavior is intuitive
75+
- \[APP\]: Multiply by 100? Dunno
76+
- \[TIM\]: As it is, all options get merged together, so whatever consumes all options gets formatted as a percent
77+
- \[APP\]: And what about currency, should it be standard/required, or optional?
78+
- \[MIH\]: I’m split because you would need to burden everyone to carry all types of currencies, but if some systems are too small to carry them, then you won’t have anything ever. Nothing will be standard anymore. I’m tempted to say required
79+
- \[APP\]: In the proposal, I did some things that are different from number. For example, i made fraction digits work differently. The default value is auto, so if currency is USD you get 2, for example. I included an option None for fraction digits, if you want to format a currency and omit a fraction part. EAO suggested fraction digits equals 0 since that’s the same thing
80+
- \[MIH\]: I don’t think it's the same thing. The number formatter will, for example, drop decimals if it’s an integer. If you set it 0, I understand you truncate the decimal and throw them away, which isn’t the same thing as None
81+
ICU: `` `NumberFormatter.TrailingZeroDisplay.HIDE_IF_WHOLE` ``
82+
[https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/number/NumberFormatter.TrailingZeroDisplay.html](https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/number/NumberFormatter.TrailingZeroDisplay.html)
83+
- \[APP\]: I think this is called suppressive zero. Any objections to this model? (none)
84+
- \[APP\]: The other thing I did was currency display. CLDR has a bunch of different things, and you need to get access to those things. For example, the Turkish Lira has a new symbol, but the old symbol is still used, so you need access to the new symbol. Same thing with Yen. I went to ICU and gathered the options for currency symbol display, and they’re narrow, short, formal, variant, and to that I added auto, which is the default, meaning ‘choose the symbol that makes the most sense here’. EAO said to have all of them, I said you could map the ones you need. CLDR seems to use all of these things
85+
- \[MIH\]: This sounds reasonable from what you described. I still haven’t read the full PR yet.
86+
- \[APP\]: I need people to lean into this PR. If this is the direction we want to talk, I propose we close EAO’s attempt, which is \#903 (no objections)
87+
88+
### Topic: Numeric Selection (\#842, \#859)
89+
90+
*Addison has updated the design doc to include a proposal for non-integer serialization. Let’s discuss. Let’s make a decision about rejecting (or accepting) \#842*
91+
92+
- \[APP\]: I created a key structure which is deterministic for numeric values. It doesn’t include scientific notation, so if you want to match a number exact, you need to type a number exactly. Very large and small values near the boundaries of scientific notation’s capabilities are very hard to specify
93+
- \[MIH\]: I really don’t like this direction, comparing them as strings. I think they should be numeric values, as ICU does
94+
- \[APP\]: This isn’t as much about how the comparison works, but rather how you specify the key.
95+
- \[MIH\]: To me it feels like both. We went through the trouble of making this things behave as numbers, so I think they should behave as numbers
96+
- \[APP\]: What you’re suggesting is certain keys parse into numeric values
97+
- \[MIH\]: I want it to be if it looks like a number it should be a number, like JSON
98+
- \[APP\]: We went through that trouble since people want to work with numeric values in a reasonable way
99+
- \[MIH\]: Right, so they think of them as numeric values. I don’t think it’s reasonable that 0.00 is not equal to 0\. As a programmer, if the number of sig figs was relevant, I’d expect it to be compared as a string.
100+
- \[APP\]: (in chat)
101+
102+
```
103+
.input {$num :number maximumFractionDigits=2 minimumFractionDigits=2}
104+
.match $num
105+
0 {{This does not match}}
106+
0.00 {{This matches the value 0}}
107+
0.0 {{This does not match}}
108+
0.000 {{This does not match}}
109+
```
110+
111+
- \[MIH\]: Yes, any programming language would throw an error if, for example, all these cases were in a switch-case (error: case appears more than once)
112+
- \[TIM\]: I think every implementation needs a number parser to handle digit-sized arguments. I don’t think it’s a new problem, rather an existing requirement
113+
- \[MIH\]: You said it may be a precision problem with some languages, which I agree. But especially in this case with exact matches, I don’t think I often see people comparing with more than two decimals
114+
- \[APP\]: The problem is with how we write the keys. How can we write the keys so people know which are valid, etc. Forget the comparisons for a second. Since we don’t have types, we go into the implementation parser
115+
- \[MIH\]: I think we invent pipes\! \[APP\]: Not with four weeks left..
116+
- \[MIH\]: I think we kind of have them already though
117+
- \[APP\]: I’m open to suggestions here because I’m worried we’ll be stuck with only integer exact matches, which is what we have right now in the spec
118+
- \[MIH\]: But that’s part of the number function right? So even if we come back 6 months later and say you can also now compare floats, it still uses the number formatter
119+
- \[TIM\]: Is that true? I thought the built in functions were part of the spec but not custom registries
120+
- \[APP\]: Standard built in functions are required to be implemented the way we say, else they are not compliant with MF2
121+
- \[APP\]: Is there a consensus we don’t solve this for 2.0?
122+
- \[TIM\]: I think it’s reasonable to not solve right now, but come back to it based on feedback assuming backwards compatibility
123+
- \[APP\]: Should we work in implementations from doing implementation defined stuff?
124+
- \[MIH\]: I wouldn’t since we want to be compliant with ICU
125+
- \[APP\]: So then consensus that we’re gonna leave things for now and ask again in preview? I want it solved (no objections)
126+
- \[MIH\]: I’m really curious on the feedback for this
127+
- \[LCA\]: My thinking is that it’s okay to postpone. I agree with Mihai, so I think we try to find a solution that doesn’t involve string values. But postponing seems fine to me for now
128+
129+
### Topic: Link to messageformat.dev (\#913)
130+
131+
*Group member Luca has made a lovely site. Tim suggests we link to it. Let’s discuss how to handle supporting materials that do not belong to Unicode.*
132+
133+
- \[APP\]: I really like the work you’ve done LCA\! My only concern is Unicode doesn’t own it, so I think we need to link in an editorial/recommendation way, not in a ‘normative’ way
134+
- \[LCA\]: I just had a similar discussion with EGO on the PR to ICU User Guide, and I mentioned there I’m fine with giving up control of the website to Unicode since I care more about providing help to users than ownership. I have a meeting scheduled next week to discuss how to transfer ownership.
135+
- \[APP\]: Awesome, thank you\! Any objections to putting this in the README now? (none)
136+
- \[TIM\]: I can add text saying it’s unofficial or unauthoritative or something
137+
- \[APP\]: I can fasttrack if you do that
138+
- \[LCA\]: Also consider that we need to keep the ‘nonauthoritative’ tag even once ownership is transferred. I also want to give a huge thanks to TIM for helping a ton with documentation\!
139+
140+
## ** Topic: PR Review**
141+
142+
*Timeboxed review of items ready for merge.*
143+
144+
| PR | Description | Recommendation |
145+
| ----- | ----- | ----- |
146+
| \#920 | Define ‘option resolution’ and require order to be insignificant | Discuss |
147+
| \#919 | Do not initialize function context direction from message direction | Discuss, Merge |
148+
| \#917 | Fix tests for bidirectional isolation | Discuss, Merge |
149+
| \#915 | Implement :currency function in default registry | Discuss |
150+
| \#913 | Add link to messageformat.dev to README file | Discuss |
151+
| \#911 | Define locale options for :datetime :date and :time | Discuss |
152+
| \#908 | Define currency and unit formatting | Reject |
153+
| \#903 | Fix fallback value definition and use | Discuss |
154+
| \#901 | Clarify note about eager vs. lazy evaluation | Discuss, Merge |
155+
| \#859 | \[DESIGN\] Number selection design refinements | Discuss, Agenda+ |
156+
| \#842 | Match numbers numerically | Discuss (Reject) |
157+
| \#584 | Add new terms to glossary | Discuss |
158+
159+
### Topic: \#917
160+
161+
- \[APP\]: Anyone have a chance to look at EAO’s PR? (no)
162+
- \[APP\]: Comparing to \#919, this is a very simple change. I could be convinced that by default it's the base directionality of the message, though.
163+
- \[APP\]: It’s tricky since you can’t introspect the string you’re inserting into
164+
- \[MIH\]: Can’t you use the locale?
165+
- \[APP\]: Generally, yes, or we use the string’s metadata. EAO’s assertion is that if it comes to you empty, compute from the locale
166+
- \[MIH\]: There could be cases where you’re inserting a date into a R-to-L language, so the entire message’s directionality should be considered.
167+
168+
### Topic: \#919
169+
170+
- \[APP\]: EAO proposed in \#911 to add date/time locale options, which override values in locale (calendar, numbering system, etc). Timezone is important but not actually locale information
171+
- \[MIH\]: When I saw this in ECMAScript, I didn’t know how to think about it. If you have the information in both places, which wins?
172+
- \[APP\]: An option would win. How do you feel about hour-12 vs hour-cycle?
173+
- \[MIH\]: I don’t like the true/false thing. I’m okay with merging the other two, but an auto thing might be nice
174+
- \[APP\]: It’s auto if not specified
175+
- \[MIH\]: In skeletons, I see people getting this wrong a lot. ICU came up with a hack but it’s a mess in general, not sure if it’s helping or hurting. If we go with this and accept these options, I’m fine with booleans, but I don’t know how to feel about these specific things being options
176+
- \[APP\]: He has them as ‘may’. I think ‘timezone’ is important. Let’s make comments on this PR to discuss further.
177+
- \[MIH\]: When I proposed a registry, I think I took the options from ECMAScript
178+
179+
## Topic: Issue review
180+
181+
[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
182+
183+
Currently we have 34 open (was 41 last time).
184+
185+
* 2 are (late for) LDML46
186+
* 10 are for 46.1
187+
* 7 are `Preview-Feedback`
188+
* 1 is `resolve-candidate` and proposed for close.
189+
* 1 is `Agenda+` and proposed for discussion.
190+
* None are ballots
191+
192+
| Issue | Description | Recommendation |
193+
| ----- | ----- | ----- |
194+
| \#865 | TC39-TG2 would like to see completion of the TG5 study | |
195+
| | | |
196+
197+
## ** Topic: Design Status Review**
198+
199+
| Doc | Description | Status |
200+
| ----- | ----- | ----- |
201+
| bidi-usability | Manage bidi isolation | Accepted |
202+
| dataflow-composability | Data Flow for Composable Functions | Proposed |
203+
| function-composition-part-1 | Function Composition | Obsolete |
204+
| maintaining-registry | Maintaining the function registry | Proposed, Discuss |
205+
| number-selection | Define how selection on numbers happens | Revision Proposed, Discuss |
206+
| selection-declaration | Define what effect (if any) the annotation of a selector has on subsequence placeholders | Proposed, Discuss (Agenda+) |
207+
| beauty-contest | Choose between syntax options | Obsolete |
208+
| selection-matching-options | Selection Matching Options (ballot) | Obsolete |
209+
| syntax-exploration-2 | Balloting of the revised syntax used in the Tech Preview | Obsolete |
210+
| variants | A collection of message examples which require a branching logic to handle grammatical variations | Obsolete |
211+
| formatted-parts | Define how format-to-parts works | Rejected |
212+
| quoted-literals | Document the rationale for including quoted literals in MF and for choosing the | as the quote symbol | Accepted |
213+
| builtin-registry-capabilities | Tech Preview default registry definition | Accepted |
214+
| code-mode-introducer | Choose the pattern for complex messages | Accepted |
215+
| data-driven-tests | Capture the planned approach for the test suite | Accepted |
216+
| default-registry-and-mf1-compatibility | Default Registry and MF1 Compatibility | Accepted |
217+
| delimiting-variant-patterns | Delimiting of Patterns in Complex Messages (Ballot) | Accepted |
218+
| error-handling | Decide whether and what implementations do after a runtime error | Accepted |
219+
| exact-match-selector-options | Choose the name for the “exact match” selector function (this is \`:string\`) | Accepted |
220+
| expression-attributes | Define how attributes may be attached to expressions | Accepted |
221+
| open-close-placeholders | Describe the use cases and requirements for placeholders that enclose parts of a pattern | Accepted |
222+
| overriding-extending-namespacing | Defines how externally-authored functions can appear in a message; how externally authored options can appear; and effect of namespacing | Accepted |
223+
| pattern-exterior-whitespace | Specify how whitespace inside of a pattern (at the start/end) works | Accepted |
224+
| string-selection-formatting | Define how selection and formatting of string values takes place. | Accepted |
225+
| variable-mutability | Describe how variables are named and how externally passed variables and internally defined variables interact | Accepted |
226+
227+
## ** Topic: AOB?**
228+
229+
- \[APP\]: After today we have 3 weeks left, check for remaining issues!
230+
231+
—
232+
#### Chat
233+
234+
You
235+
9:23 AM
236+
[https://docs.google.com/document/d/1S2OqVVRfuCYUGfvc49PpoNedUgTTcedmCzzv5GrUmWM/edit](https://docs.google.com/document/d/1S2OqVVRfuCYUGfvc49PpoNedUgTTcedmCzzv5GrUmWM/edit)
237+
*keep*Pinned
238+
Luca Casonato
239+
9:48 AM
240+
I agree with Mihai
241+
Mihai ⦅U⦆ Niță
242+
9:55 AM
243+
[https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/number/NumberFormatter.TrailingZeroDisplay.html](https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/com/ibm/icu/number/NumberFormatter.TrailingZeroDisplay.html)
244+
You
245+
10:08 AM
246+
\> .input {$num :number maximumFractionDigits=2 minimumFractionDigits=2} \> .match $num \> 0 {{This does not match}} \> 0.00 {{This matches the value 0}} \> 0.0 {{This does not match}} \> 0.000 {{This does not match}}
247+
Luca Casonato
248+
10:08 AM
249+
I agree with Mihai - compare by string is confusing for number literals
250+
You
251+
10:14 AM
252+
The exact behavior of exact literal match is currently only well defined for non-zero-filled integer values. Functions that use fraction digits or significant digits might work in specific implementation-defined ways. Users should avoid depending on these types of keys in message selection in this release.
253+
You
254+
10:28 AM
255+
[https://github.com/unicode-org/message-format-wg/issues/918\#issuecomment-2440226860](https://github.com/unicode-org/message-format-wg/issues/918#issuecomment-2440226860)
256+
You
257+
10:38 AM
258+
// the nu extension key requests a numbering system, e.g. Chinese decimal console.log(new Intl.NumberFormat("zh-Hans-CN-u-nu-hanidec").format(number)); // 一二三,四五六.七八九
259+
MessageFormat Working Group teleconference

0 commit comments

Comments
 (0)