Add 2025-08-11 meeting notes

Author: eemeli

meetings/2025/notes-2025-08-11.md

@@ -0,0 +1,175 @@
+# 11 August 2025 | MessageFormat Working Group Teleconference
+
+Attendees:
+
+- Eemeli Aro \- Mozilla (EAO)
+- Mihai Niță \- Google (MIH)
+- Tim Chevalier \- Igalia (TIM)
+- Shane Carr \- Google (SFC)
+- Richard Gibson \- OpenJSF (RGN)
+
+**Scribe:** MIH
+
+## Mark dataflow-composability design doc as obsolete (PR \#1092)
+
+EAO: Should have merged this a while ago
+Thumbs up from more people.
+Submitted
+
+## Preparations for LDML 48 release (PR \#1096)
+
+EAO: editorial fixes
+This includes scripts that will generate and publish the rendered version of the spec.
+
+MIH: would have been nice to separate the scripts from the spec differences
+
+MIH: also nice to not have PRs showing up over the week-end and submit on Monday. Some people might want to have a week-end 🙂
+
+Thumbs up from more people.
+Submitted
+
+This is where the rendered spec is now published: [https://unicode-org.github.io/message-format-wg/](https://unicode-org.github.io/message-format-wg/)
+
+## Add :percent (PR \#1094)
+
+_Our primary focus will be on seeing if we can land PR \#1094, adding :percent as a draft function. At this week's meeting, this was identified as the only remaining change we're considering for inclusion in the LDML 48 version of the spec._
+
+SFC: I reviewed it before other comments and changes, not after. But fine with the direction.
+
+MIH: same as SFC, read it before changes. No blocker from me.
+
+TIM: OK to merge.
+
+Thumbs up from more people.
+Submitted
+
+## LDML 48
+
+_Anything else blocking publication?_
+
+EAO: do we have any blockers for 48?
+
+SFC: the :percent and :datetime are both draft, right
+
+EAO: are semantic skeletons getting out of tech preview in LDML 48?
+
+SFC: it is in icu4x, I might push in that direction. But I didn’t have it on my agenda to do.
+
+EAO: we can’t really push semantic skeletons out of draft in MF2 if it is not out of tech preview in LDML
+
+SFC: I will put it on the CLDR agenda
+
+## Looking Forwards
+
+_We need to start looking forwards, and plan our work beyond the LDML 48 release. We have an updated list of [goals](https://github.com/unicode-org/message-format-wg/blob/main/docs/goals.md), and I think it's time to start doing something about these two in particular:_
+
+- _Define a standard vocabulary for expression attributes and message properties/metadata, to enable better interoperation between translation tools and platforms._
+- _Incubate and support working groups or interest groups that promote adoption of Unicode MessageFormat, such as the proposed working group to develop a standard message resource format, i.e. a new file format for bundles or collections of messages._
+
+_We do of course also need to improve our documentation site and fill out the default function set, but we ought to look beyond those as well._
+
+[https://github.com/unicode-org/message-format-wg/blob/main/docs/goals.md](https://github.com/unicode-org/message-format-wg/blob/main/docs/goals.md)
+
+EAO: What are we going to do next?
+I mentioned a few in the email.
+
+### Machine readable function description
+
+MIH: machine readable function description to be consumed by linters, IDEs, CAT tools
+
+EAO: I have something similar to do for Mozilla, updating tools to parse and validate message sources into a data model.
+Another person that expressed interest was Luca (LCA).
+So there is some opportunity here.
+We ought to figure out a time for EAO / LCA / MIH to get together and decide how to go ahead about that.
+TIM, do you have any interest in this?
+
+TIM: not for now
+
+### Vocabulary for Attributes
+
+EAO: figuring out attributes
+We now allow them in placeholders and markup.
+But the empty namespace is reserved.
+Would be really useful to define some basic meanings that can be used.
+
+EAO: preliminary message bundle work: [https://github.com/eemeli/message-resource-wg/issues/19](https://github.com/eemeli/message-resource-wg/issues/19)
+Message and expression level attributes.
+That connects with validation and linting.
+Attributes like “example”.
+
+MIH: I think most of these attributes belong outside the message, in the “wrapper” (storage)
+
+EAO: for the vast majority of cases I would agree.
+
+MIH: for translator access to attributes: hidden, read-only, enum, free-form, maybe regexp. Relevant for leveraging or not.
+In my mind this kind of stuff belongs in the machine readable function description.
+If this changes per message, probably still outside the message, not inside (think structured comments, or XML attributes, or other existing mechanisms)
+
+EAO: we can collect use cases, then we decide where they belong.
+
+### XLIFF Mapping
+
+MIH: XLIFF mapping, but in a way that is backward compatible with existing CAT tools (that understand XLIFF, but know nothing about MF2).
+
+EAO: I have something in the JS implementation, might be worth taking a look.
+
+### Maintain and develop the documentation
+
+EAO: maintaining doc, links to examples, implementations, etc.
+Can we find some bandwidth to improve things here?
+Hopefully each of us can find a bit of time to
+
+EAO: adoption, promotion
+
+### Compatibility with MF1
+
+EAO: The people in the room working on ICU, can you take a look at this?
+
+MIH: I will
+But not the next week or two :-)
+Most likely after ICU 78 release.
+
+EAO: create individual issues for everything missing, so that we can close them as we solve them.
+
+### Message resource format incubation
+
+EAO: I have a strong interest in this.
+
+MIH: I have little interest in this. Most likely belongs somewhere like ECMAScript or W3C, or in some tech stack that does not have such a format.
+If the result of that is “amazing” then some other tech stacks will adopt it.
+
+EAO: maybe IETF?
+
+RGN: they would probably not care
+
+MIH: Another option might be OASIS, which had a lot of work done in the l10n standards space (XLIFF, TMX, word counting).
+This is where XLIFF is: [https://github.com/oasis-tcs/xliff-xliff-22](https://github.com/oasis-tcs/xliff-xliff-22)
+
+RGN: maybe ECMA?
+
+### Action Items
+
+ALL: Update the documentation site: [https://github.com/unicode-org/messageformat.dev](https://github.com/unicode-org/messageformat.dev)
+
+MIH:
+
+- Send an email to the XLIFF TC, ask if there is interest in a file format, and mapping MF2 to XLIFF, CC EAO
+- Add links to mapping for HTML, Java Properties, and Windows .RC
+  - MIH: faulty memory, was not about Windows RC files, was about gettext .po files:
+    - XLIFF 1.2 Representation Guide for Java Resource Bundles:
+      [https://docs.oasis-open.org/xliff/v1.2/xliff-profile-java/xliff-profile-java-v1.2.html](https://docs.oasis-open.org/xliff/v1.2/xliff-profile-java/xliff-profile-java-v1.2.html)
+    - XLIFF 1.2 Representation Guide for Gettext PO:
+      [https://docs.oasis-open.org/xliff/v1.2/xliff-profile-po/xliff-profile-po-1.2.html](https://docs.oasis-open.org/xliff/v1.2/xliff-profile-po/xliff-profile-po-1.2.html)
+    - XLIFF 1.2 Representation Guide for HTML:
+      [https://docs.oasis-open.org/xliff/v1.2/xliff-profile-html/xliff-profile-html-1.2.html](https://docs.oasis-open.org/xliff/v1.2/xliff-profile-html/xliff-profile-html-1.2.html)
+- Update the ICU4J implementation
+
+TIM: Update the ICU4C implementation
+
+EAO:
+
+- Cancel the meetings scheduled for 2025-08-18 and 2025-09-01
+- Submit spec for inclusion in LDML 48
+- Coordinate with MIH & LCA on initial requirements for machine readable registry definition
+- File PR adding preliminary attribute/metadata definitions
+- File PR adding message resource explainer for its incubation