Skip to content

Commit 24cb113

Browse files
aphillipsaphillips
authored
Create notes-2024-11-04.md
1 parent 642b611 commit 24cb113

File tree

1 file changed

+324
-0
lines changed

1 file changed

+324
-0
lines changed

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

Lines changed: 324 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,324 @@
1+
# 4 November 2024 | MessageFormat Working Group Teleconference
2+
3+
4+
### Attendees
5+
6+
- Addison Phillips \- Unicode (APP) \- chair
7+
- Mihai Niță \- Google (MIH)
8+
- Elango Cheran \- Google (ECH)
9+
- Tim Chevalier \- Igalia (TIM)
10+
- Michael Coblenz \- UC San Diego (MJC)
11+
- Richard Gibson \- OpenJSF (RGN)
12+
- Shun Kashiwa \- UC San Diego (Shun)
13+
- Harmit Goswami \- Mozilla (HGO)
14+
- Mark Davis \- Google (MED)
15+
-
16+
17+
18+
**Scribe:** ECH
19+
20+
21+
## [**Agenda**](https://github.com/unicode-org/message-format-wg/wiki#agenda)
22+
23+
24+
## Topic: Info Share
25+
26+
-
27+
28+
## Topic: Schedule for Release
29+
30+
## **Topic: `resolve-candidate`**
31+
32+
*The following issues are proposed for resolve:*
33+
34+
- #895 (UTF-16 unpaired)
35+
- #589 Consider forbidding pass-through .local
36+
- #578 Question about grammatical case
37+
- #130 Dynamic References
38+
39+
APP: For #895, are there any objections. We had objections to the permissability of unpaired surrogates.
40+
41+
MED: I think that objecting to unpaired surrogates in the message is fine, but unpaired surrogates in the parameters is–
42+
43+
APP: There is nothing we can do to prevent that.
44+
45+
MED: I have no objection to the usage of unpaired surrogates in text or in the rest of the message.
46+
47+
APP: So can we kill the object?
48+
49+
MIH: \+1
50+
51+
APP: On the topic of #589, can we reject the objection. I think we have already handled this in function composition.
52+
53+
MED: It needs other functions / options to be alive.
54+
55+
APP: This one is disallowing multiple assignments of a variable in the context as locals. I show that there are times where you do want to have multiple different formats of the same thing.
56+
57+
MED: Okay, then I oppose the change.
58+
59+
ECH: I agree with MED.
60+
61+
APP: Next is #578.
62+
63+
MIH: I think we can drop this for any version. It requires access to the message resource bundle.
64+
65+
MED: The think I don’t like is that it has the old static variables problem. You can predict what this thing is going to be.
66+
67+
APP: Do we want to keep it around, or close it?
68+
69+
MIH: For me, let’s close.
70+
71+
MED: Agreed, and we can always open a new one.
72+
73+
## **Topic: Agenda+ Topics**
74+
75+
### Topic: TG5 user survey (#865)
76+
77+
*The ECMA TG5 folks want to discuss their upcoming user survey on our behalf. 15 minutes timeboxed.*
78+
79+
Link to [presentation slides](https://docs.google.com/presentation/d/12ZXMBLTB3k6S9YNBkW3gA8VBHMc4_4xQlIRP41nxcKU/edit?usp=sharing)
80+
81+
Shun: We’ve been interested in conducting this user study, both related to the TC39 TG5 user study, but also as a language study. I would like to gather your thoughts.
82+
83+
Shun: We have a user feedback survey. We would like to conduct user studies for two groups: translators and software engineers. Think-aloud study is about hearing the thinking. Maybe the task is to read something in Figma and write some code. For translators, rather than ask them to create MF2 messages from scratch, we instead given them a MF2 message in English and ask them to translate it.
84+
85+
Shun: Some tasks can be to ask both groups whether a given MF2 message is a valid message. We would like to use [messageformat.dev](https://messageformat.dev) as a resource to teach participants about MF2 syntax.
86+
87+
Shun: For software engineers, we will provide expect output from a message and ask them to construct a message that could generate them.
88+
89+
MED: When they run the programs, will you capture what they have at that point? It will be interesting to see what they had at that point.
90+
91+
Shun: Yes, we’ll record the session. It will be interesting to have that data.
92+
93+
Shun: For the timeline, we were thinking about developing the infrastructure and recruiting participants in early November. And then conduct the studies in mid to late November.
94+
95+
Shun: We have a few questions in our Discussion slide that we’d like to hear your feedback on.
96+
97+
MED: We know that a lot of people use MF1. It would be useful to see how they do with the MF2 syntax \_compared\_ to the MF1 syntax. Even though it would make the study longer, it would be interesting to see if MF2 is harder, the same, or easier than MF1. I would expect them to find it approximately the same except when they have multiple selectors, but my expectations are not what’s important, and you want to go deeper than that anyways.
98+
99+
APP: I would second that, but instead say “How would you solve this problem?” because not everyone uses MF1. So if we can understand what developers would have done, and how they compare MF2 to that, that would be valuable.
100+
101+
MED: If you have a blind study, and the participants have never seen either one, what would they experience?
102+
103+
MIH: It’s a bit of a caution – it would be nice to give them context on areas to focus on, like: trimming spaces. These are topics that were tricky for us. We argued a lot. The highest priority when breaking ties was about avoiding i18n mistakes, even if it made other aspects less convenient, more clunky, etc. I don’t know how to test for that and find ways to avoid those mistakes.
104+
105+
APP: I think it’s interesting to look at the function set. For example, I saw a string match function using a gender string, but maybe there should be a gender function.
106+
107+
MJC: I want to ask about the quantity of study that you’re proposing. Comparing MF1 and MF2 would be that. Quantitative studies to compare things are a lot more expensive and time consuming to run. My main focus about MF2 is about expressiveness. Are there specific questions when comparing with MF1 that people would want to see?
108+
109+
APP: MF2 is valuable as a competitor to other clunky primitive ways that people are stuck using currently to provide i18n-ized strings like `String.format()`, etc. I’m not so interested in a comparison with MF1 since MF1 is not as interesting.
110+
111+
MED: That’s a good point, APP. It would be good to have some comparisons with MF1. As MIH, we want to remove the broken glass and not have people shoot themselves in the foot.
112+
113+
Shun: I appreciate the feedback,
114+
115+
ECH: I want to emphasize the i18n focus part of the design, but at the same time, if there are important I18N aspects of the design we make sure that we tease out how people perceive that. If they see that certain designs will help/hurt or if they recognize it at all. When I saw previous iteration, when it comes to things we had discussions on, wrt ease of use, do they help/hurt ability to author correct messages. More interesting than just the formatting function. If they know the right option for getting fraction digits. Getting that right not interest. We had discussion of syntax.
116+
117+
MED: That’s a very good point. It reminds me of when I will give programming problems in interviews to see ohw people will tackle things. I will tell them at the beginning that I don’t care about syntax errors because IDes will catch them. What matters is whether they have the conceptual ideas to solve the problem. We’re not testing specifics of the syntax, but more of the concepts.
118+
119+
APP: Shun, any parting thoughts or questions?
120+
121+
Shun: I don’t think so. We will try to incorporate the feedback as much as possible. If you all have any leads to recruiting translators, that would be greatly appreciated. Recruiting translators is difficult for us, whereas we can get undergraduate CS students to participate as software engineers.
122+
123+
MED: I think getting translators won’t be hard. Translators tend to use tooling.
124+
125+
Shun: What do you mean tooling?
126+
127+
MED: Most translators use CAT tools and other UI tools to do translation, in practice. For example, in their UI, placeholders will be represented as a “chip” / “pill” indivisible widget in the UIs that they use. But they don’t write by hand. So I don’t see as much value from the translators.
128+
129+
MIH: Based on what MED said, would it be interesting to not ask them to write the syntax, but instead just focus on comprehension?
130+
131+
Shun: I think that’s interesting to focus on comprehension, although I think that there’s value in looking at the syntax, too.
132+
133+
APP: If anyone has sources for translators, please pass it along to Shun.
134+
135+
Shun: Here is my email: _redacted_
136+
137+
APP: Thanks for your work on this.
138+
139+
Shun: Thanks. I’ve a lot of time on this, so thanks for having me.
140+
141+
### Topic: various bidirectional PRs (#919, #917)
142+
143+
*Let’s discuss the implementation of bidi and details thereof.*
144+
145+
APP: I could see the base direction message being set by the message locale.
146+
147+
MIH: It’s either undefined or empty.
148+
149+
MIH: I’m tempted to go with the locale.
150+
151+
APP: This change is to the expression. So an expression inside of a message. So by default, we use FSI instead of RLI or LRI. Again, the locale of the formatter could influence it.
152+
153+
MIH: Is this necessary, or will the algorithm do nothing?
154+
155+
APP: The algorithm won’t do nothing. The algorithm will necessarily do something.
156+
157+
MIH: I’m not sure that it’s an improvement.
158+
159+
### Topic: Clarify eager vs. lazy evaluation (#901)
160+
161+
*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.*
162+
163+
### Topic: Add a :number offset option (#701)
164+
165+
*Mark proposed adding an `offset` option to `:number` for parity with MF1. We discussed including this last week, but need a PR. Mihai is creating the PR. \=\> **REGRETS :-( Busy week, didn’t do it.***
166+
167+
APP: One of the things we have to do is refactor everything about a registry to be about functions. Before that refactoring, we have to merge all of the changes to the registry. One thing that will have to change is that we have an algorithm for selection on numbers, and it now needs to take into account the offset value.
168+
169+
MIH: It’s weird in MF currently. The selection is done on the value itself, but the display depends on the offset value.
170+
171+
APP: Any objections? No objections heard.
172+
173+
### Topic: Currency and Unit Formatting (#838, #908, #915, #922)
174+
175+
*Last week we discussed separating functions. Addison has proposed the currency function and separately the unit function. Percent was left as part of :number/:integer The unit function may be too immature for 46.1.*
176+
177+
MED: I don’t think it is too immature; it’s close right now and just needs a little work. I’ll try to make the first ½ hour.
178+
179+
APP: I wrote a unit proposal as an optional function. My proposal is that we leave units for after CLDR v46.1. I’m open to taking it in v46.1 if we are in agreement.
180+
181+
APP: Does anyone have comments on #915 about currency function that would stop us from including a currency function?
182+
183+
APP: EAO had a concern about the currency display set, which I made complete, as compared to ICU’s NumberFormatter. His other concern was about SimpleNumber.
184+
185+
MED: I don’t like EAO’s reply that everything that MessageFormat does has be supported by Intl.NumberFormat. That’s too strong of a claim.
186+
187+
APP: So far, we haven’t made any option values optional, we’ve only made option keys being present or not optional.
188+
189+
MED: It doesn’t do what it says. It reduces interoperability in terms of results, but it increases the interoperability of passing a message and being able to accept it, which I think is important.
190+
191+
APP: That is my impression as well.
192+
193+
MED: We can add a note saying that value can be aliased.
194+
195+
APP: My experience is that if there is a currency symbol development underway, ex: the Turkish Lira symbol is used a lot, and maybe I want to use the variant symbol in other cases, now I can’t combine them. I think there is evolution going on. If we don’t provide the full list of keywords, you would be prevented from doing things.
196+
197+
MED: We could provide an optional currency display variant that provides the things not in Intl.NumberFormat. We can provide either option. But I think the alias option is a more powerful approach for the future.
198+
199+
APP: Does anyone disagree with the direction that MED and I seem to be going?
200+
201+
MIH: \+1
202+
203+
Others: no objection
204+
205+
APP: Regarding units, should we put it in, or keep it later for CLDR v47+?
206+
207+
MED: I don’t think we should include units until we know about there being usage. But if we put it in now, we can get feedback. Thus, the Intl.NumberFormat argument doesn’t hold.
208+
209+
APP: I also don’t want to put in a feature that is deprecated at birth.
210+
211+
MED: Well, you need the unit and you need the usage.
212+
213+
APP: Is there anything funky about selection?
214+
215+
MED: You have the same issues with fractions and currencies and numbers as you would with units.
216+
217+
APP: Does ordinal matter?
218+
219+
MED: Does the “3rd dollar” or “3rd kilometer” make sense? Maybe it does. But we don’t have support for it. I think it does make sense, but not now.
220+
221+
APP: I can take it out and add a note.
222+
223+
MED: Yes, for currencies, ordinal does not apply. We can add it back in later when we understand it more fully.
224+
225+
MIH: I agree with MED that having `` `usage` `` is very useful. What about we put it at the end of the line? I’m not saying that we put it in CLDR v46, but we leave it for later, and we can shave this yak then. I don’t want to spend time on this if it delays work on mandatory things.
226+
227+
Others: no objection
228+
229+
### Topic: Numeric Selection (#842, #859)
230+
231+
*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*
232+
233+
APP: EAO’s proposal in #842 is to match numbers that are fractions in a certain way. My proposal says to use a string-based comparison (number serialization based). An alternative is to leave fractional exact match somewhat undefined in 2.0.
234+
235+
MIH: I’m happy to just stick with matching on integers, and forgoing fractions completely. Or else we compare numerical values like we do in programming languages, which gets into the details of floats and doubles.
236+
237+
APP: I expect that options apply. Then we have to map on them so that the digits match. How do you guarantee that maximum fractional digits yields in something matching.
238+
239+
MIH: I don’t care about the trailing digits. It’s weird to see a value like `1.00` and yet it doesn’t match `=1`.
240+
241+
MIH: I don’t see a use case. The current plural works. You can say `1.00 dollars` works today. It works by the magic of plural keyword selection using the plural rules.
242+
243+
APP: We’re defining exact matches here.
244+
245+
MIH: Exactly. I don’t see a good use case for matching on precise fractional values here. I see the value of matching on the numerical value. And if at some point someone really comes with a use case for string-like match we can add a syntax like |=1.00|, and that would be a string match. It is in the `` `:number` `` functions spec, not the spec proper. And it would be backward compatible.
246+
247+
ECH: For number formatting, 1 and 1.00 are different and caught by plural rules. For exact matches, I don’t think I can think of a use-case that makes sense. Precision of a fractional value is usually not done by matching precise values but instead by bucket or range of values. It doesn’t mean there couldn’t still be a valid use-case, but I don’t think we should assume/move on things until we are sure.
248+
249+
APP: Does anyone object to my inclusion of this text and just calling it an option?
250+
251+
ECH: Sounds good
252+
253+
APP: Okay, will merge.
254+
255+
## **Topic: PR Review**
256+
257+
*Timeboxed review of items ready for merge.*
258+
259+
| PR | Description | Recommendation |
260+
| ----- | ----- | ----- |
261+
| #922 | Implement :unit as OPTIONAL in the registry | Discuss, defer to 47? |
262+
| #919 | Do not initialize function context direction from message direction | Discuss, Merge |
263+
| #917 | Fix tests for bidirectional isolation | Discuss, Merge |
264+
| #915 | Implement :currency function in default registry | Discuss |
265+
| #911 | Define locale options for :datetime :date and :time | Discuss |
266+
| #908 | Define currency and unit formatting | Reject |
267+
| #903 | Fix fallback value definition and use | Discuss |
268+
| #901 | Clarify note about eager vs. lazy evaluation | Discuss, Merge |
269+
| #859 | [DESIGN] Number selection design refinements | Discuss, Merge, Agenda+ |
270+
| #842 | Match numbers numerically | Discuss (Reject) |
271+
| #584 | Add new terms to glossary | Discuss |
272+
273+
## Topic: Issue review
274+
275+
[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
276+
277+
Currently we have 32 open (was 34 last time).
278+
279+
* 2 are (late for) LDML46
280+
* 10 are for 46.1
281+
* 8 are `Preview-Feedback`
282+
* 4 are `resolve-candidate` and proposed for close.
283+
* 1 is `Agenda+` and proposed for discussion.
284+
* None are ballots
285+
286+
| Issue | Description | Recommendation |
287+
| ----- | ----- | ----- |
288+
| #865 | TC39-TG2 would like to see completion of the TG5 study | |
289+
| | | |
290+
291+
## **Topic: Design Status Review**
292+
293+
| Doc | Description | Status |
294+
| ----- | ----- | ----- |
295+
| bidi-usability | Manage bidi isolation | Accepted |
296+
| dataflow-composability | Data Flow for Composable Functions | Proposed |
297+
| function-composition-part-1 | Function Composition | Obsolete |
298+
| maintaining-registry | Maintaining the function registry | Proposed, Discuss |
299+
| number-selection | Define how selection on numbers happens | Revision Proposed, Discuss |
300+
| selection-declaration | Define what effect (if any) the annotation of a selector has on subsequence placeholders | Proposed, Discuss (Agenda+) |
301+
| beauty-contest | Choose between syntax options | Obsolete |
302+
| selection-matching-options | Selection Matching Options (ballot) | Obsolete |
303+
| syntax-exploration-2 | Balloting of the revised syntax used in the Tech Preview | Obsolete |
304+
| variants | A collection of message examples which require a branching logic to handle grammatical variations | Obsolete |
305+
| formatted-parts | Define how format-to-parts works | Rejected |
306+
| quoted-literals | Document the rationale for including quoted literals in MF and for choosing the | as the quote symbol | Accepted |
307+
| builtin-registry-capabilities | Tech Preview default registry definition | Accepted |
308+
| code-mode-introducer | Choose the pattern for complex messages | Accepted |
309+
| data-driven-tests | Capture the planned approach for the test suite | Accepted |
310+
| default-registry-and-mf1-compatibility | Default Registry and MF1 Compatibility | Accepted |
311+
| delimiting-variant-patterns | Delimiting of Patterns in Complex Messages (Ballot) | Accepted |
312+
| error-handling | Decide whether and what implementations do after a runtime error | Accepted |
313+
| exact-match-selector-options | Choose the name for the “exact match” selector function (this is `:string`) | Accepted |
314+
| expression-attributes | Define how attributes may be attached to expressions | Accepted |
315+
| open-close-placeholders | Describe the use cases and requirements for placeholders that enclose parts of a pattern | Accepted |
316+
| overriding-extending-namespacing | Defines how externally-authored functions can appear in a message; how externally authored options can appear; and effect of namespacing | Accepted |
317+
| pattern-exterior-whitespace | Specify how whitespace inside of a pattern (at the start/end) works | Accepted |
318+
| string-selection-formatting | Define how selection and formatting of string values takes place. | Accepted |
319+
| variable-mutability | Describe how variables are named and how externally passed variables and internally defined variables interact | Accepted |
320+
321+
## **Topic: AOB?**
322+
323+
- [APP]: After today we have 3 weeks left, check for remaining issues\!
324+

0 commit comments

Comments
 (0)