Add 2025-07-21 meeting notes

Author: eemeli

meetings/2025/notes-2025-07-21.md

@@ -0,0 +1,192 @@
+# 21 July 2025 | MessageFormat Working Group Teleconference
+
+Attendees:
+
+- Eemeli Aro \- Mozilla (EAO)
+- Addison Phillips \- Unicode (APP)
+- Mihai Niță \- Google (MIH)
+- Tim Chevalier \- Igalia (TIM)
+- Shane Carr \- Google (SFC)
+
+**Scribe:** APP  
+**Previous Scribe:** TIM
+
+## Previous Actions
+
+- TIM to update \#1084
+
+EAO: has been fiddled with and now looks good. Okay to merge?  
+(silence)
+
+(APP pushes the button)
+
+- EAO to update \#1068 to move current proposed solution to a candidate, so that the design doc can be merged as “proposed”. See discussion below about introducing a `:percent` function.
+
+(merged)
+
+- EAO to email the WG about stepping up as chair, and if not opposed, take the proposal to the CLDR-TC.
+- MIH and others to review \#1083, hopefully to merge next week.
+- MIH and SFC to consider proposing an alternative to the `hour12=true|false` option.
+- MIH to review whether \#1005 is still relevant
+
+## Topic: PR Review
+
+_Timeboxed review of items ready for merge._
+
+| PR     | Description                            | Recommendation |
+| ------ | -------------------------------------- | -------------- |
+| \#1084 | Fix contradiction in markup resolution | Merge          |
+| \#1068 | Design document for percent formatting | Merge          |
+
+| PR     | Description                                                 | Recommendation                 |
+| ------ | ----------------------------------------------------------- | ------------------------------ |
+| \#1078 | Define time zone values and conversions                     | Discuss                        |
+| \#1083 | Include :date, :datetime, and :time with minimal options    | Discuss                        |
+| \#1077 | Include :datetime, :date, and :time with style options only | Superseded by \#1083 (Close??) |
+| \#1067 | Semantic skeletons design                                   | Discuss                        |
+
+## Design document for percent formatting ([**\#1068**](https://github.com/unicode-org/message-format-wg/pull/1068))
+
+EAO: As we’ve discussed, now just lists possibilities without choosing one. Okay to merge and talk about percent formatting?
+
+APP: feel like we could choose a winner but okay to merge
+
+EAO: I have previously been pushing back on a dedicated :percent function. Changing mind a bit. Propose as next step, to effectively come up with a more specific proposal for :percent and go from there. That PR could be adding the :percent function text while also moding the design doc.
+
+## Include :date, :datetime, and :time with minimal options ([**\#1083**](https://github.com/unicode-org/message-format-wg/pull/1083))
+
+EAO: As discussed, looking at 1083, which is adding date/datetime/time options, keeping in draft and aligning with discussion. We gave this last week to review and then check if okay to merge. Has to stay draft while semantic skeletons in tech preview
+
+APP: doesn’t have to
+
+EAO: well..noooo, but…
+
+EAO: any objection to merging
+
+MIH: the hour12 I’d still like to discuss
+
+EAO: it’s outside this PR though.
+
+MIH: I’m okay with that.
+
+TIM: no objections
+
+(merged)
+
+(closed 1077\)
+
+EAO: we’ll need at least one more PR on time/timezone. Hour12 seems like a user preference.
+
+APP: applications want to have a knob for hour12, not have to mess with the locale identifier
+
+MIH: agree
+
+EAO: need a PR for it still. Have time zone discussion, possible hour12 discussion, and literalness of calendar and hour12
+
+APP: think there’s more work, but wish date/time non-draft core functionality
+
+EAO: going ahead of semantic skeletons…
+
+MIH: don’t think we can take out of draft for 48\. The spec for semantic skeletons isn’t out. Implement in date formatter before messageformat.
+
+APP: getting the core out seems important for adoption
+
+EAO: could consider advancing the functions out of draft but without any options, like a minimum viable product.
+
+## Define time zone values and conversions ([**\#1078**](https://github.com/unicode-org/message-format-wg/pull/1078))
+
+EAO: let’s talk about time zone \#1078
+
+APP: would add ‘or offset’
+
+EAO: done
+
+(merged)
+
+## Semantic skeletons design (\#1067)
+
+EAO: Tim, you have an open comment on timePrecision. Is that satisfied by current draft text.
+
+TIM: searching…
+
+MIH: would rather not push this. Last comments are from 21 May. wouldn’t rush it. Tag for next session?
+
+APP: okay to put in because not final?
+
+MIH: don’t think we need to rush it. Been dormant for a few months.
+
+EAO: discussions have gone past the state of the PR. more difficult to land now and then advance? Can we merge this. Got a chat comment to merge this from TIM. Good to merge?
+
+(silence)
+
+(merged)
+
+EAO: at zero PRs
+
+APP: not at zero issues 🙂
+
+## Requirements for CLDR 48
+
+EAO: when we do have to freeze to meet 48 with impl?
+
+MIH: code freeze is september, soon the better
+
+EAO: two weeks as target for freeze. MIH, skipping next week?
+
+MIH: maybe
+
+EAO: next week is also TC39, so Richard and I might miss. Could maybe do a short call, like 30 minutes. Can aim to lock for 48 in 2 weeks. Should figure out what we need for 48\. Identify for date/time and limit hour12 and calendar from having variables. Are we okay not having percent formatting except as draft? Or do we think we could have :percent in the next meeting?
+
+APP: seems wishful. Can spec branch for 48\. Also website.
+
+EAO: can wait.
+
+SFC: merge date/time/datetime? Is there a status:
+
+EAO: draft
+
+SFC: can bikeshed option names?
+
+EAO: yes. Need at least one PR to discuss/land. Hour12 or nother name. Limit hour12/calendar to literal values? Any other specific things that need to be included in 48?
+
+SFC: hour12 vs. hc seems like a topic that is still open
+
+MIH: hour12 should be a runtime. Have to put in the message itself. Have to create same message twice.
+
+APP: could use a .match
+
+EAO: SFC in a comment, from 4x perspective because hour12 has a data loading impact.
+
+SFC: hourCycle is something we can handle. Hour12 we don’t support at all
+
+(discussion of whether that’s correct impact)
+
+EAO: so calendar only literal? Is there a case
+
+MIH: same argument as cycle? Do I really want to send for translation the same message for translation?
+
+SFC: allowing hourcycle to be done in the locale is before message is instantiate. Some in message, in locale, or in input. Timezone can be in input. Hc can be the middle one.
+
+APP: that’s datetimeformatter.
+
+SFC: two modes. Fixed calendar and any calendar. If from locale or input variable. If you hardcoded it in message, could use fixed calendar.
+
+EAO: not converging on a solution here. Maybe one or two PRs on this?
+
+MIH: probably move forward if 2 discussions. Hour12 seems easier to support. While calendar… bigger data chunks.
+
+SFC: agree on separating. Two concerns here. One is how do we constrain the variables. Also impacts ECMA. bikeshedding shape of the options. Separate discussions is good.
+
+APP: usability is important too. Think two tracks.
+
+EAO: need to consider both slicing an use. Cost of implementing hc is a multiplier of 2\. Option of calendar is 12-ish calendars with a bunch of data. Feels rarer.
+
+EAO: two discussion and then naming of hour12 is the third discussion.
+
+APP: optional functionality??
+
+MIH: maybe? Don’t think it’s needed. Can excluded from data slide.
+
+APP: have to consider which calendar option values are required. Gregorian, but not… “Mayan Traditional”, eh?
+
+EAO: no meeting next week.