8000 Create notes-2024-02-05.md · unicode-org/message-format-wg@0a57a50 · GitHub
[go: up one dir, main page]

Skip to content

Commit 0a57a50

Browse files
authored
Create notes-2024-02-05.md
1 parent 889e539 commit 0a57a50

File tree

1 file changed

+145
-0
lines changed

1 file changed

+145
-0
lines changed

meetings/2024/notes-2024-02-05.md

Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
# 5 February 2024 | MessageFormat Working Group Regular Teleconference
2+
3+
### Attendees
4+
Addison Phillips - Unicode (APP) - chair
5+
Eemeli Aro - Mozilla (EAO)
6+
Staś Małolepszy - Google (STA)
7+
Elango Cheran - Google (ECH)
8+
Mihai Niță - Google (MIH)
9+
Matt Radbourne - Bloomberg (MRR)
10+
Simon Clark - Oracle (SCA)
11+
12+
Scribe: (SCA)
13+
14+
## Topic: Action Item Review
15+
~~MIH and STA, please work on documenting the use-cases for options on markup close:~~
16+
17+
MIH considers it done. One comment pending in github. ID-able closing spans useful for handling android and ios markup.
18+
19+
APP - closing id on spannables has corollary in XLIFF
20+
21+
STA - consider not disallowing it, and there are potentially compelling use cases.
22+
23+
EAO & APP - worth tabling discussions until we have examples
24+
25+
Further discussion to happen on issue thread
26+
27+
- [ ] APP, add warning about * (#619)
28+
29+
No action taken yet
30+
31+
## Info Share
32+
33+
Ujjwal and EAO presented at FOSDEM. Records should be available soon.
34+
35+
ECH - virtual open house being led by Addison coming up. Invite family and friends! https://blog.unicode.org/2024/01/new-event-on-february-20-virtual-open.html
36+
37+
## Topic: Progressing to Done
38+
39+
The main blockers appear to be the following:
40+
- ~~Beautification of the syntax discussion~~
41+
- ~~What’s in a name? (Does NCName fix our woes? Go to UAX31? what?)~~
42+
- ~~Quoting~~
43+
- ~~Format-to-Parts~~
44+
- ~~Spannables~~
45+
- ~~Expression Attributes~~
46+
- Registry and default functions
47+
- Implementation and testing
48+
49+
Schedule:
50+
1. No new LDML45 issues after 15 January.
51+
2. All LDML45 issues resolved by end of F2F. Balloting alpha spec to occur 15 February.
52+
3. Beta spec and registry by 11 March.
53+
4. Can make limited changes thereafter, for issues discovered by implementers.
54+
5. Release 10 April as part of LDML45
55+
56+
## Topic: Testing
57+
MRR and ECH have been talking about testing strategy. Code in repo is a good starting point.
58+
59+
MRR - start with testing against EAO’s implementation.
60+
61+
MRR - proposing using YAML as format for test cases. Makes multiline message more clear and readable. Transpiled to JSON before testing.
62+
63+
## Topic: F2F Planning
64+
Set up for a successful week next week. MOstly balloting the hardening of the spec.
65+
66+
EAO: do we talk about integer, ordinal, plural, date, time? Now?
67+
68+
APP - wants to make testing a large part of f2f discussion
69+
70+
EAO - implementation is coming along. Date and Time not in yet, but coming.
71+
72+
MIH - implementation is coming slowly.
73+
74+
75+
## Topic: MF1 formatters to not support
76+
In #565 @aphillips proposes that we not support the following functionality that is in ICU MF1.
77+
spellout (spells out numbers)
78+
duration (formats long values as a time, that is, 123456 => 34:17:36) (who uses this?!?)
79+
choice (deprecated by MF1)
80+
number skeletons, date skeletons (we previously discussed that these could be icu:skeleton i.e. NOT in the default registry)
81+
82+
Discussion:
83+
84+
EAO: offset on plural selection best done as an ICU extension - proposal. Reason: because it’s messy
85+
Skeletons are compact way of defining representations. ECMA script uses “option bags” - are we considering switching.
86+
87+
MIH skeletons are a registry thing - not dependent on spec
88+
89+
ECH - if we set a
90+
91+
APP number skeletons are a fairly new thing and still half baked. Date skeletons are more useful and mature.
92+
93+
EAO : prefers mf2 not be opinionated. Set proposal later.
94+
95+
EAO : others should be left out because of the data size they bring in.
96+
97+
Consensus: Do not include any of these in the LDML 45 release.
98+
99+
## Topic: Active PR review
100+
101+
#621
102+
Describe Number selection fully
103+
104+
APP working on contents in design doc. Exact matching section still evolving.
105+
106+
## Topic: Open Issue Review
107+
https://github.com/unicode-org/message-format-wg/issues
108+
109+
Currently we have 28 open (was 29 last time).
110+
- 2 are resolved-candidate and proposed for close.
111+
- 5 are Agenda+ and proposed for discussion.
112+
- 12 are Future (nor for this release)
113+
- 14 are LDML45
114+
- 2 require release triage (#598, #561)
115+
116+
117+
## Topic: AOB?
118+
119+
EAO: discussion on aliasing: PR# 570 - are we keeping or dropping the aliases.
120+
121+
APP- not currently refer to or implemented as aliases. We should decide what goes in as basic functions.
122+
123+
APP - https://github.com/unicode-org/message-format-wg/pull/570#issuecomment-1859252553 . thinks it should be possible to get just date or just time without reverting to a bag of options.
124+
125+
STA - may be a good ergonomics improvement. Saving keystrokes is not a good reason to increase API surface area.
126+
127+
APP- good usability improvement that thinks people will appreciate. MF1 has date (all purpose) and time (rarely used)
128+
129+
STA - instinct is to test hypothesis that people want it. Release without it and see if people complain.
130+
131+
EAO - would be fine with tweak - datetime, date, and time sounds fine. Useful and ergonomic.
132+
133+
APP - step back from EAO’s PR, not in right form. Follow APP’s integer/number description in number PR. Ultimately name does not matter, but we should have the discussion of what options to allow and disallow in each case.
134+
135+
MIH - don’t want to repeat MF1. if you call date, then time options are disallowed. Cannot force it to show a time
136+
137+
STA - concerned we create a slight diversion from what we consider canonical. Datetime has datestyle and timesyle options. Time should not have a timestyle option, it should just be style. Introduces risk of future collision, or inconsistency. We are coupling ourselves to ECMA standards. If we are not going to change option names, then that is maybe ok.Worried about introducing style that is contextual.
138+
139+
MIH - “{$foo :time year:numeric month:full}” - get empty string? Error?
140+
141+
MIH - I’ve seen developers using “{...date…}, {...time…}” in MF1, hard-coding the order of the fields, and the separator between them. Sure, it’s localizable, but what translators will do will not work for all locales (think languages used in a lot of countries, but translated only once, like fr, es, ar, en)
142+
143+
APP - proposal: write a date/time formatting doc. Include date and time for now as separate things. We can debate once the PR is open.
144+
145+
EAO - current PR has style= options, does not allow year, month, etc.

0 commit comments

Comments
 (0)
0