8000 Create notes-2025-02-24.md · unicode-org/message-format-wg@943479b · GitHub
[go: up one dir, main page]
Skip to content

Commit 943479b

Browse files
aphillipsaphillips
authored
Create notes-2025-02-24.md
1 parent b35fb7d commit 943479b

File tree

1 file changed

+265
-0
lines changed

1 file changed

+265
-0
lines changed

‎meetings/2025/notes-2025-02-24.md

Lines changed: 265 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,265 @@
1+
# 24 February 2025 | MessageFormat Working Group Teleconference
2+
3+
Attendees:
4+
5+
- Addison Phillips \- Unicode (APP) \- chair
6+
- Eemeli Aro \- Mozilla (EAO)
7+
- Mark Davis \- Google (MED)
8+
- Mihai Nita \- Google (MIH)
9+
- Richard Gibson \- OpenJSF (RGN)
10+
- Tim Chevalier \- Igalia (TIM)
11+
12+
**Scribe:** MIH
13+
14+
## Topic: Info Share, Project Planning
15+
16+
Check out: [https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html\#Contents](https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#Contents)
17+
18+
MED: I’ve attended the TC39 research results on the tests they did with engineers and translators.
19+
No big problems.
20+
Devs had some problems with select because it works differently than other prog languages.
21+
Translators had problems with writing some kind of messages. But they usually use some kind of “IDE”.
22+
23+
## Topic: PR Review
24+
25+
*Timeboxed review of items ready for merge.*
26+
27+
| PR | Description | Recommendation |
28+
| ----- | ----- | ----- |
29+
| \#1011 | Require prioritizing syntax and data model errors | Defer to 48 |
30+
31+
APP: we have one single PR. Let’s hold it for 48.
32+
33+
MED: if tag it then it’s OK. Or wait a couple if weeks for the integration.
34+
35+
## Topic: LDML47 Final Release
36+
37+
*After a flurry of activity, the final release was created. Let’s briefly review the changes that were made using fast-tracking and other strategies.*
38+
39+
APP: last week we did a lot of things.
40+
One of the bigger changes was the wording in the stability policy. Not making any valid message be not valid (“not valid” instead of “invalid”).
41+
42+
MED: we need to do some work in 48\. There are some bad things that can happen with custom functions.
43+
So there is not a sense of stability in the function area.
44+
45+
APP: in fact there might also be some instability in that area. Custom functions use namespaces. Where in theory they might still conflict.
46+
47+
EAO: we need to make explicit that markup you are also expected to use some kind of namespace.
48+
49+
MED: markup and attributes are kind of fuzzy
50+
51+
EAO: they were before, but not now.
52+
53+
APP: in the body of the spec.
54+
55+
EAO: this clarification has happened. In case someone has concerns with us reserving the “empty namespace” for ourselves.
56+
57+
APP: see here [https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html\#reserved-identifier](https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#reserved-identifier)
58+
\> Use a namespace in a custom identifier to identify a function that is not a default function or when defining a custom option for a default function.
59+
60+
APP: it’s a note, not normative.
61+
62+
MED: and that’s what we need to fix for 48
63+
64+
APP: we added a few options and defined some terms
65+
66+
EAO: “expression resolution” and “string value of a literal” also got defined.
67+
68+
MED: makes the wording more understandable. Not a normative change.
69+
70+
## Topic: LDML47 Issues
71+
72+
*Some issues have LDML47 labels.*
73+
[*https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue%20state%3Aopen%20label%3ALDML47*](https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue%20state%3Aopen%20label%3ALDML47)
74+
75+
[*https://github.com/unicode-org/message-format-wg/blob/main/docs/checklist-for-pourover-creation.md*](https://github.com/unicode-org/message-format-wg/blob/main/docs/checklist-for-pourover-creation.md)
76+
77+
## Topic: Issue review
78+
79+
[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
80+
81+
Currently we have 39 open (was 40 last time).
82+
83+
* 6 are tagged for 47
84+
* 20 are tagged for 48
85+
* 3 are tagged “Seek-Feedback-in-Preview”
86+
* 5 are tagged “Future”
87+
* 17 are `Preview-Feedback`
88+
* 6 are `resolve-candidate` and proposed for close.
89+
* 2 are `Agenda+` and proposed for discussion (see below)
90+
* 0 are ballots
91+
92+
| Issue | Description | Recommendation |
93+
| ----- | ----- | ----- |
94+
| [724](https://github.com/unicode-org/message-format-wg/issues/724) | Rationalize name-char | Agenda+, Resolve-candidate (\#1008) |
95+
| \#866 | CLDR semantic datetime skeleton spec is nearly ready and MF2 should use it | Agenda+, Discuss |
96+
| \#1033 | Stability policy conflict with allowing all identifiers | LDML47, Discuss |
97+
| \#993 | Update test schema to make expErrors “array” only | Discuss, resolve-candidate |
98+
| \#997, \#1004 | spec/bidi “overreaching”, bidi test cases | Discuss |
99+
| \#1005 | Test checking the markup arguments | Discuss |
100+
101+
## 1033 Stability policy conflict with allowing all identifiers
102+
103+
Close, open a new one
104+
105+
## Fix spec details for pourover to v47 (and future) \#1001
106+
107+
APP: I’ve done most of that work
108+
109+
## #724 Rationalize name-char
110+
111+
Landed
112+
113+
## #993 Update test schema to make expErrors “array” only
114+
115+
APP: I think we’ve done something in that space.
116+
117+
EAO: we decided not to take the PR
118+
119+
```json
120+
"expErrors": true
121+
"expErrors": \[{ "type": "unknown-function" }\]
122+
"expErrors": \[{ "type": "unknown-function" }, { "type": "bad-selector" }\]
123+
```
124+
125+
MED: move to 48
126+
There is test data that is part of LDML, so it is part of the release.
127+
Not normative, but part of the release.
128+
129+
## TC39-TG2 would like to see completion of the TG5 study \#865
130+
131+
MED: It happened, all good
132+
133+
## \[FEEDBACK\] Rationalize name-char \#724
134+
135+
PR: Rationalize name-char \#1008
136+
137+
## #997, #1004 spec/bidi “overreaching”, bidi test cases
138+
139+
MIH: Can be improved in two areas. We describe one algorithm on how to add bidi control chars, and call that “Default”. Which is a bit confusing when you read the tests. When you see default, it means “I have a list of 5 options and default points to one of them.” In this case, it doesn’t point to one of them, it’s “you applied the algorithm we call Default”, which is a bit unreadable. I think it would be nice to have a name for that thing other than “Default”. That’s one of the things.
140+
141+
EAO: As an alternative, we could require this to be the default algorithm when formatting to a concatenated string.
142+
143+
MIH: That’s the second issue. The first issue is the naming itself.
144+
145+
APP: You are required to provide that specific one. You can optionally provide others.
146+
147+
MIH: I understand. My only issue is with the naming itself. For instance, when you format a date or time, you can say “with calendar default” and that maps to medium.
148+
149+
APP: We’re open to naming suggestions.
150+
151+
MIH: Maybe it’s nitpicking. The other part is that the spec right now doesn’t say what the default behavior is. Doesn’t say “you have to apply the default algorithm or you don’t apply anything.” Right now it’s implementation-specific. It would be beneficial to say that by default, implementations should apply this algorithm if not otherwise specified, or not apply the algorithm. By saying “whatever you want” we have inconsistent behaviors between implementations, for no good reason.
152+
153+
APP: You are required to implement it, can implement a different strategy if you feel like it, or one that does nothing. We don’t require anything else. That was a discussion we had when creating it, which was to allow –
154+
155+
MIH: My proposal is, can we say that all implementations must implement this algorithm and, by default, apply it unless the developer opts out? That way, two implementations will behave the same if I don’t specify the bidi algorithm.
156+
157+
EAO: The intended result of the current language is to enable a user to use an implementation in order to get the same behavior that they’ll get from a different implementation. The current language does not require that they get something closer to that behavior by default. I would be fine with requiring the default algorithm to be the default algorithm for formatting to a concatenated string. I also note that we don’t require an implementation to call this what we call the “Default” algorithm. An implementation does not need to call it that, e.g. if they use a different default. I support MIH’s suggestion to require this as a default for concatenated strings.
158+
159+
APP: And do we want to rename it?
160+
161+
MIH: If we have a good name idea
162+
163+
EAO: If we require the default to be the default, I think it’s OK to call it the default.
164+
165+
MIH: I don’t have a better idea for the name, but it helps if “Default” is the default.
166+
167+
APP: Recording that, we’ll make a PR for 48\.
168+
169+
## #1005 Test checking the markup arguments
170+
171+
APP: also MIH’s
172+
173+
MIH: the test forbid `` `u:dir` `` and `` `u:locale` ``
174+
175+
APP: you could say that dir and lang in html options.
176+
177+
EAO: when we target something like html they tend to support properties on element tags like dir and lang
178+
The capability is there.
179+
Since we don’t process markup, we only include it in output.
180+
181+
No conceivable need for u:dir and u:locale in any markup we know.
182+
183+
APP: I also have a question about \`u:id\`
184+
Maybe we should study this carefully.
185+
186+
MIH: since we are agnostic about markup, and we don’t say what it should do / should not do, and I have free reign, then don’t tell me not to use u:locale or u:dir
187+
188+
EAO: my JS implementation is the only one doing something with markup
189+
190+
APP: u:locale is now draft because of ICU4X. And u:dir is a “should”
191+
192+
APP: we should probably compare technical arguments. A design doc.
193+
It is not urgent.
194+
195+
MIH: I am not pushing for make it non-error for 47
196+
197+
EAO: we can make it non-error later and we don’t break the stability policy.
198+
If we make it non-error now, and change to error later, we break that policy.
199+
200+
APP: I added a few candidates to close
201+
202+
## #1029
203+
204+
This can be rendered without vertical bars
205+
206+
```
207+
{#button}Submit{/button} or {#img alt=|Cancel| /}.
208+
{#button}Submit{/button} or {#img alt=Cancel /}.
209+
```
210+
211+
Might give the impression that the html quotation marks are the same as the vertical pipe character.
212+
213+
RGN: actually this is exactly how html works. Can be with and without quotes
214+
215+
APP: so you want some examples without the \``` |` ``
216+
217+
MED: yes
218+
219+
EAO: the “always quotes” rule is good for localization.
220+
221+
MIH: all localization tools that I know don’t care about quotes or not. That is not what determines localizability.
222+
223+
## Should we really be using `` `{{pattern}}` `` and `` `|literal|` `` delimiters? \#602
224+
225+
EAO: Delete
226+
227+
APP: do we have anything else?
228+
229+
EAO: Goals and deliverables
230+
XLIFF
231+
232+
MIH: a machine readable description of functions
233+
For tooling and localization.
234+
235+
APP: I can imagine first a description of such a machine readable format.
236+
Then such a file describing our own functions and options.
237+
Then tooling, which we might do or not.
238+
239+
APP: I think we should update our deliverables list.
240+
Look maybe at more functions.
241+
242+
EAO: we also considered a list formatter.
243+
244+
MED: we should look at more formatters and have them namespaced
245+
246+
EAO: so we have a desire to spend more time on defining functions.
247+
And a “function-interface description language”
248+
249+
APP: a function description format is in the cards.
250+
251+
MED: even the functions we can split into milestones.
252+
253+
EAO: defined some un-name-spaced attributes, and what they mean.
254+
255+
MED: we should be able to define markup, so we need to reserve some kind of namespaces for no.
256+
Another example: translate=no
257+
258+
APP: need to draft an updated set of goals
259+
260+
EAO: are dropping the XLIFF mapping?
261+
262+
APP: I think it is still a potential target.
263+
264+
MIH: in XLIFF
265+
[https://docs.oasis-open.org/xliff/xliff-core/v2.2/csd01/xliff-extended-v2.2-csd01-part2.html\#plural\_gender\_select\_module](https://docs.oasis-open.org/xliff/xliff-core/v2.2/csd01/xliff-extended-v2.2-csd01-part2.html#plural_gender_select_module)

0 commit comments

Comments
 (0)
0