Skip to content

Commit b19ecf2

Browse files
aphillipsaphillips
authored
Create notes-2024-05-20.md
1 parent 76a676c commit b19ecf2

File tree

1 file changed

+307
-0
lines changed

1 file changed

+307
-0
lines changed

‎meetings/2024/notes-2024-05-20.md‎

Lines changed: 307 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,307 @@
1+
# 20 May 2024 | MessageFormat Working Group Teleconference
2+
3+
### Attendees
4+
- Addison Phillips - Unicode (APP) - chair
5+
- Eemeli Aro - Mozilla (EAO)
6+
- Elango Cheran - Google (ECH)
7+
- Matt Radbourne - Bloomberg (MRR)
8+
- Mihai Niță - Google (MIH)
9+
- Richard Gibson - OpenJSF (RGN)
10+
- Tim Chevalier - Igalia (TIM)
11+
12+
13+
Scribe: MIH
14+
15+
## Topic: Info Share
16+
17+
MIH: had discussions last week with TIM and ECH and SFC about how to improved format to parts in ICU. ICU exposes the internals. It gets annotated with things that come from DateFormat class. Tells you how the formatter is implemented. Working on design for ICU
18+
Will write a design document for ICU, to change the format-to-parts (to not expose implementation)
19+
Next 5 weeks vacation, might still join some meetings but not sure which ones
20+
21+
MIH: have 4-5 weeks of vacation
22+
23+
ECH: proposing a change to ICU? Wasn’t sure that was the conclusion.
24+
25+
MIH: cannot change ICU without being approved. Changes public APIs
26+
27+
ECH: didn’t get that from last week’s discussion.
28+
29+
MIH: can discuss. Talked to Shane after that…
30+
31+
APP: Do we need to revisit design on how formatToParts works?
32+
33+
TIM: It might be helpful to have more in the spec about hwat parts are. I find myself thinking about what the polyfill for formatToParts produces. It would be nice to have in the spec so that I don’t have to guess.
34+
35+
APP: That is good. So it would be helpful to have a design doc. My experience is that you want to have access to the parts, or the container, and do stuff on it. At Amazon, we make the different parts of a currency display differently to the user, and we need to know the parts of the currency to do that.
36+
37+
EAO: We had a formatToParts proposal that was previously rejected. Someone else will need to revive that. I am happy to add to the ECMA proposal based on that decision.
38+
39+
MIH: what ICU does and what the ECMAScript proposal is are incompatible. So putting anything in the spec manes one or the other are incompatible. And ICU finalized the format-to-parts style changed and was refactored in 2019.
40+
41+
MIH: I really don’t think that we can put them in the spec because it will need to be different in ECMAScript vs. ICU4C and ICU4J vs. other implementations and languages.
42+
43+
APP: That was where we got stuck with the previous proposal.
44+
45+
EAO: discussing with ECMAScript I changed my mind and we tend to agree to have a format-to-parts that is data only (no classes, methods, etc)
46+
47+
TIM: need more info in the spec on what “parts” are.
48+
49+
APP: maybe a design doc
50+
You often want to have access to parts, to query them.
51+
So that you can make various parts with different styles. You want to read the various fields, not only content, but also order.
52+
53+
APP: phone call with Mark Davis. Where to put the work for a storage format (message resources).
54+
You might all be interested, but there might be a whole collection of people. So not under MF. Next step is to go to CLDR and ask for permission.
55+
56+
EAO: I need this thing. Lack of clarity is this belongs under CLDR, or a clear signal that this does not belong under CLDR. I’m interested in driving this forward.
57+
58+
APP: my observations is that the people who need convincing are the CLDR TC. Many people wrote resource formats. But having a standard one has value, and Unicode is a good place to do that.
59+
60+
ECH: kind of curious about that, if we have to work on it. Will that affect the work we do on MF2? Which is not done yet. We have implementations, we need to get feedback, act on it, etc.
61+
That has to happen, and if we start this soon it will get in the way of what we have to do in MF2.
62+
63+
APP: I will not permit that work to interfere with this process. Except for occasional info sharing we will not talk about it, except info-sharing. I suspect it is a container.
64+
65+
EAO: until now the resource format was not too often
66+
(MIH: I didn’t capture this well in notes, but the idea is that work there was on and off?)
67+
68+
APP: should propose to CLDR, and get a group to collaborate with you.
69+
70+
EAO: is Mark Davis under the impression that this group also has resources under its purview?
71+
72+
APP: no-one has much experience with it, it is for the TC to take on.
73+
Maybe this is super-meta: this is some work, we think it belongs under CLDR TC.
74+
75+
EAO: should it be under MF WG, or under a separate group. I think this question needs an answer. Am I asking them for a different group? Or the same group, with a different line of work?
76+
77+
APP: can be light-weight (“just create a repo”), or not.
78+
79+
EAO: look at the existing repo. I will write a one-pager, share, and present.
80+
## Topic: Tech Preview
81+
82+
83+
## Topic: PR Review
84+
Timeboxed review of items ready for merge.
85+
86+
| PR | Description | Recommendation |
87+
|:----:|:-----------------------------------------------------------------:|:---------------------------------------:|
88+
| #795 | Fix #782: give implementations more flexibility in error handling | Discuss |
89+
| #794 | Update readme with list of normative changes during TP | Merge |
90+
| #793 | Recommend not escaping all the things | Merge |
91+
| #792 | [DESIGN] Add user stories / build-out expression attributes | Discuss (Merge) |
92+
| #791 | Update design docs and their status | Merge |
93+
| #780 | [DESIGN] Contextual options in the `u:` namespace | Discuss |
94+
| #753 | Add design doc on function composition | Discuss |
95+
| #744 | Fix design doc | Merge (approved, waiting on bearfriend) |
96+
| #728 | Add "resolved values" section to formatting | Discuss |
97+
| #673 | Fix whitespace conformance to match UAX31 | Discuss; related to 781 |
98+
| #646 | Update spec as if PR #645 were accepted | Depends on 645 |
99+
| #645 | Add design doc for dataflow for composability | Merge design doc to enable discussion |
100+
| #634 | Design doc to capture registry maintenance | Discuss |
101+
| #616 | Add docs/design etc. | Discuss (Reject?) |
102+
| #584 | Add new terms to glossary | Discuss |
103+
| #558 | Add <when> to help select the right <match> | Depends on registry changes |
104+
105+
106+
107+
### 795: Fix #782: give implementations more flexibility in error handling #795
108+
109+
EAO: need a design document to capture pros and cons
110+
111+
ECH: also feedback to the tech preview
112+
113+
APP: must be a way to discover the errors if they happen, without saying how.
114+
No case to get neither string, nor error.
115+
116+
EAO: must be able to get a fallback representation of a message even if there are errors. And important to detect errors.
117+
118+
There are 2 MUST statements, too connected.
119+
120+
APP: must have a signal. You may or may not provide the formatting fallback.
121+
And these are somehow separable.
122+
123+
EAO: In the issue there is a Rust idea of having 2 calls, one will fallback to string, another fails.
124+
125+
MIH: totally fine to have a way to return a string, or return an error.
126+
We should not force both.
127+
128+
APP: What happens in ICU? If an error happens, do you get the proposed string back?
129+
130+
MIH: No. In ICU, when you get an error, you don’t get the string back. And we shouldn’t force them to do what they aren’t set up to do. Windows APIs are also like that. They don’t return a value when they get an error. It’s fine for implementations to try to be as strict as they can, but we are not in a position to force them to.
131+
132+
EAO: should be possible to use MF2 in situations where there are layers of implementation.
133+
134+
MIH: Win / MacOS / Android already have APIs that format messages, and they either throw, or return fallback. Not both. And the decision about what to do was done years ago.
135+
We should not force them to change what they do.
136+
137+
EAO: the existing behavior of some systems is that they either return fallback, or throw, and when throw there is no way to return a fallback string.
138+
139+
APP: who to write a design document
140+
141+
ECH: if short, I’m OK to do it
142+
143+
ACTION ITEM: ECH, write design document
144+
145+
#794: Update readme with list of normative changes during TP #794
146+
147+
MERGED
148+
149+
### 793: Recommend not escaping all the things #793
150+
151+
MERGED
152+
153+
### 792: [DESIGN] Add user stories / build-out of the expression attributes #792
154+
155+
APP: Design document on expression attributes
156+
Hope will help us with the discussion on expression attributes.
157+
Anyone wants to discuss it now?
158+
159+
MERGED
160+
161+
### 791: Update design docs and their status #791
162+
163+
MERGED
164+
165+
### 780: Add design doc for contextual options #780
166+
167+
APP: the one with `u:` options.
168+
Should this be in the expression attributes design?
169+
170+
EAO: expression attributes as they are designed as a solution centric approach. We worked backwards to the use cases.
171+
This separates the use cases better, then proposes two different solutions.
172+
Indeed both.
173+
174+
ECH: I don’t understand why we need two.
175+
176+
APP: it is fine the have one design document with two solutions proposed. So we can merge this one, and the doc with expression attributes, or namespaced “global actions”
177+
178+
MIH: Do we still need expression attributes?
179+
180+
APP: see my design document, that we just merged. @locale should be attribute because the dev should do something about it, to override the default.
181+
182+
MIH: I really don’t see the distinction. If I’m formatting a number, and you don’t give me the number of decimals, then I will give the default. I will honor the value if given. For me, it’s really the same thing.
183+
184+
EAO: If we end up not including expression attributes
185+
Will need to define some kind of “pass-through” function so that options can be added to a function without saying what they are exactly.
186+
187+
APP: do we want to consider the two design documents together (`:u` and expression attributes)
188+
189+
EAO: I’m fine to rewrite that doc as a section of the other document.
190+
191+
ECH: I think these are the same problem.
192+
193+
EAO: at meta level I think we should focus on the problem, not the solution.
194+
For me Impact on formatting or not is a big differentiator.
195+
I’m fine to merge this doc in the one about expression attributes.
196+
197+
APP: anything else
198+
199+
## 753: Add design doc on function composition #753
200+
201+
EAO: Anything happened since last meeting?
202+
203+
TIM: did some minor changes based on APPs comments.
204+
205+
APP: merge?
206+
207+
MERGED
208+
209+
### 728: Add Resolved Values section to formatting #728
210+
211+
EAO: my thought is that it is probably easier to proceed.
212+
213+
APP: I have proposal 645(?) and would suggest to merge this document so that we can work towards a discussion.
214+
Would we be OK to merge 645
215+
216+
### 645: [DESIGN] dataflow for composability (#515) #645
217+
218+
TIM: 645 might need some rework, since ??? was merged (and there is duplicate information).
219+
220+
EAO: we should move to more concrete from generic.
221+
Add something to the registry on how stuff works, and iterate from there.
222+
As a design document that does not propose anything I’m OK to merge.
223+
224+
EAO: I will take an action and propose a way for functions to interact.
225+
We could argue about small specific things, then we can go and fix the general with what we learn.
226+
227+
APP: I don’t disagree.
228+
229+
EAO: we can all make small changes.
230+
231+
APP: I think we should merge this doc. Was good to clarify certain things.
232+
233+
ECH: I’m tempted to take it.
234+
235+
TIM: fine to merge and do some updates after (in the list of 733 (or 743?)
236+
237+
MERGED. Then updates by TIM
238+
239+
240+
## Topic: Design Status Review
241+
242+
| Doc | Description | Status |
243+
|:--------------------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------:|:-----------------:|
244+
| beauty-contest | Choose between syntax options | Closed - obsolete |
245+
| bidi-usability | Manage bidi isolation | Proposed |
246+
| builtin-registry-capabilities | Tech Preview default registry definition | Accepted |
247+
| code-mode-introducer | Choose the pattern for complex messages | Accepted (*) |
248+
| data-driven-tests | Capture the planned approach for the test suite | Proposed |
249+
| default-registry-and-mf1-compatibility | Define the functions necessary for the tech preview | Accepted |
250+
| delimiting-variant-patterns | Balloting of complex message handling | Accepted |
251+
| exact-match-selector-options | Choose the name for the “exact match” selector function (this is `:string`) | Accepted |
252+
| expression-attributes | Define how attributes may be attached to expressions | Proposed |
253+
| formatted-parts | Define how format-to-parts works | NOT accepted |
254+
| number-selection | Define how selection on numbers happens | Accepted |
255+
| open-close-placeholders | Describe the use cases and requirements for placeholders that enclose parts of a pattern | Accepted |
256+
| overriding-extending-namespacing | Defines how externally-authored functions can appear in a message; how externally authored options can appear; and effect of namespacing | Accepted |
257+
| pattern-exterior-whitespace | Specify how whitespace inside of a pattern (at the start/end) works | Accepted |
258+
| quoted-literals | Document the rationale for including quoted literals in MF and for choosing the \| as the quote symbol | Accepted (*) |
259+
| selection-declaration | Define what effect (if any) the annotation of a selector has on subsequence placeholders | Proposed |
260+
| selection-matching-options | Discussion doc used in choosing the type of matching used | Obsolete |
261+
| string-selection-formatting | Define how selection and formatting of string values takes place. | Accepted |
262+
| syntax-exploration-2 | Balloting of the revised syntax used in the Tech Preview | Obsolete |
263+
| variable-mutability | Describe how variables are named and how externally passed variables and internally defined variables interact | Accepted |
264+
| variants | A collection of message examples which require a branching logic to handle grammatical variations | Obsolete |
265+
266+
267+
## Topic: AOB?
268+
269+
270+
###
271+
272+
We cancel next week (U.S. holiday)
273+
274+
275+
276+
### Chatlog
277+
278+
You
279+
9:21 AM
280+
https://docs.google.com/document/d/1aCVvXPfkXIBNOueTiFBNftCXI4LcwaQgSq12qRPLnx0/edit
281+
keepPinned
282+
Tim Chevalier
283+
9:39 AM
284+
1 sec
285+
You
286+
10:11 AM
287+
https://github.com/unicode-org/message-format-wg/blob/main/exploration/expression-attributes.md#user-story-formatting-context-override
288+
Mihai ⦅U⦆ Niță
289+
10:29 AM
290+
I also have my own mental model :-)
291+
Mihai ⦅U⦆ Niță
292+
10:34 AM
293+
sorry, what number is this? (for the meeting notes)
294+
You
295+
10:35 AM
296+
not a number, scroll down
297+
Tim Chevalier
298+
10:35 AM
299+
it's the "Topic: Design Status Review" heading
300+
Mihai ⦅U⦆ Niță
301+
10:35 AM
302+
got you, thanks
303+
Mihai ⦅U⦆ Niță
304+
10:36 AM
305+
happy with skip (considering that I am in vacation :-)
306+
MessageFormat Working Group teleconference
307+

0 commit comments

Comments
 (0)