Create notes-2025-02-10.md

aphillips · web-flow · commit 12ffb9b55192 · 2025-02-10T11:53:34.000-08:00
diff --git a/meetings/2025/notes-2025-02-10.md b/meetings/2025/notes-2025-02-10.md
@@ -0,0 +1,236 @@
+# 10 February 2025 | MessageFormat Working Group Teleconference
+
+Attendees:
+
+- Addison Phillips \- Unicode (APP) \- chair  
+- Eemeli Aro \- Mozilla (EAO)  
+- Mihai Nita \- Google (MIH)  
+- Mark Davis \- Google (MED)  
+- Shane Carr \- Google (SFC)  
+- Matt Radbourne \- Igalia (MRR)
+
+
+**Scribe:** MED, MRR
+**Previous Scribe:** MIH
+
+
+## Topic: Info Share, Project Planning
+
+EAO: Ujjwal and I presented on MF2 at FOSDEM. Will add a link.  
+[https://fosdem.org/2025/schedule/event/fosdem-2025-5561-solving-the-world-s-localization-problems/](https://fosdem.org/2025/schedule/event/fosdem-2025-5561-solving-the-world-s-localization-problems/)
+
+## Topic: PR Review
+
+*Timeboxed review of items ready for merge.*
+
+| PR | Description | Recommendation |
+| ----- | ----- | ----- |
+| \#1000 | Fix bad links to cldr-smoke | Merge (fast track) // approved |
+| \#999 | Remove “coercion” from :string tests | Merge // approved |
+| \#996 | Add missing “literal” specifier for key equality | Merge // approved |
+| \#990 | Allow name-char as first character of unquoted | Discuss |
+| \#989 | Simplify syntax character definitions | Merge // approved |
+| \#988 | Add :percent | Change to remove option |
+| \#983 | Drop reference to “registry” | Merge // approved |
+| \#923 | Test schema ‘src’ property | Close PR |
+
+String Issue:  
+MED: if an implementation doesn’t convert datatypes, then it is a problem.  
+APP: will raise _Bad Operand_ error, so it is specified. Same as other functions
+
+Percent:
+
+EAO: would rather have scaling as a thing. :math is the right place. Shane expressed concern that values other than power of 10 is a performance issue. Would be more readable. Doing in math would limit the transformations that other functions would be doing. Could be used in selection also.  
+APP: percent formatting is MF1 functionality. Percents less common than most formatters, but more common than others. Be a shorthand for people used to finding percent. Math: would be cautious about arbitrary values; just limit to current need. Keep from having all the math operators. Need to explicitly address the scaling, and specify which of the two methods is used.  
+EAO: exponent function on math would be good; like that direction. :unit:meter would work for units? (scribe doesn’t understand).   
+MIHi: not really well defined; code freeze is EOW. Shouldn’t use math for this stuff. Have seen MF1 do horrible things (select on error code to get 500 messages).  
+APP: hive off as math or as other function. Scaling function?  
+EAO: have percent as supported :unit. One way to advance. We don’t know the right approach. Ok to have initial PR to take away the percent option on.  
+MED: everything is making more complications rather than less.   
+APP: remove percent from number and digit. :unit is capable of doing it. Would consider a percent function. Consider exponent (or equivalent).  
+MIH: remove percent from ICU.  
+EAO: take out the thing that is a mistake.  
+APP: if we added any other solution, those would need to be proposed.   
+EAO: Change 988 into just removing the percent option from functions. Agreed to fast track since we approved.
+
+Drop reference to “registry”  
+APP Merge, and handle RECOMMENDED, etc comments in separate PR.  
+Agreed to merge.
+
+Test schema ‘src’ property  
+MRR: current PR is to bring things in sync. (and have something we aren’t happy with) And then change conformance.  
+MIH: anything that can sometimes be a string, sometimes an array is a problem for strongly typed languages. Ether alway an array, or have two fields: string and string\[\]. Exactly one would be null.  
+APP: Leave as a string. Up to test software to check for | and break apart.  
+MRR: Mihai and time having a last conversation.  
+Leave as is for now. Close the PR.
+
+## Topic: Schedule, possibility of not being final in v47
+
+*There is some pushback from the ICU-TC to making our spec final in v47. Reserving some time to discuss the status of this.*
+
+ICU has not had the time to do the API review. Is nervous about making Part 9 Final Candidate
+
+Proposal 1: (MF) Part 9 stays in Final Candidate  
+Proposal 2: part of Part 9 stays in Final Candidate, main part is stable (= no backwards compatibility breakage, can deprecate)
+
+MIH: Unhappy with ‘everything is a string’ \- no numeric types. Even EAO was bothered when parsing a JSON. I feel it’s completely unnatural.
+
+EAO: Do you mean everything we parse out of the syntax to be a string.  
+MIH: Not only that, I could still optimize things (store internally as a number). We started specifying extra stuff \- e.g. selection is done on strings.
+
+EAO: String is either the catch-all thing, or it’s a literal. Whatever happens within or between functions, we do not restrict those to strings.
+
+MIH: The trouble is that functions are scalable. We add more and more functions. If we say that max decimals=2, it’s the function’s job to parse. It’s unnatural. It’s better to say ‘its parsed as something that’s a numeric type in your language’.
+
+Mark \- repeating from email:
+
+Stabilizing the main part was discussed in the ICU meeting today. I'll summarize the points of concern, but look for the ICU members to expand/clarify.
+
+1. People are not worried about the syntax being stabilized, but they are worried about the semantics of the main part.  
+2. An example is function chaining, where it could be problematic in strongly-typed languages.  
+3. A Javascript implementation doesn't help, because it isn't a strongly-typed language.
+
+Our hard date is Feb 26 to decide where to have the Final Candidate label.
+
+Markus: Plus, being sufficiently explicit about what's a string, what's a number, what's a date/time object, etc.  
+The semantics need to be clear, the test cases need to reflect that, and IMO C++/Java/Rust/... implementations should not be overly burdened with having to have code all over the place for detecting type mismatches and converting. For example, if something works with a number, then pass a number, don't force every layer and MF2 function to convert from or to strings.
+
+APP: The function handler can do whatever it feels like. We’re not going to change that because there are plent of reasons why we chose a typeless model. You’re right that people will think of those strings as numbers. How the implementation handles is not our business. If you just turn it \[string\] into the number, that’s totally fine. I dont see why we would not stabilize our spec. We should be changing it now before the ink is dry.
+
+EAO: We go further than that \- minimum fraction digits, where it’s most relevant. We define ‘small digit’ \[or similar\] in the ABNF/function document, I believe we give sufficient information. We do not give this permission at the syntax level, but at thef’number’ function implementation.
+
+(digit size option: https://github.com/unicode-org/message-format-wg/blob/main/spec/functions/number.md\#digit-size-options)
+
+MED: I strongly disagree with MIH. A function can say ‘this is a string, I can deal with it as a string’ or it is really up to the function. It’s a little bit misleading to have in the literal definition, that we have the unquoted literals contain the syntax for numbers. I don’t see any reason to hold off on saying that the main part is stable and leaving the function part in final candidate. I’d like to see a good reason for us to say why the main part could not be stable.
+
+APP: The other possibility is that we intend to operate the default function set… we should ensure we have a way to promote portions of the default function set to stable. I’m OK with us not promoting it in 47\. But with string/number/etc, and we can promote them, we should figure out how that works so people can understand the status.
+
+EAO: The clearest way would be to mark most of the functions as proposed and mark the rest as final.
+
+MED: In one case, we’d say the whole thing is proposed, in the other case, we’d say the whole function section is final candidate. FC is a bit stronger than proposed.
+
+APP: In our function set, we’d say the text of that section is under a certain stability. We’d have proposed around all the things not yet final.
+
+MED: Let me see and MIH is on board. It sounds like we’ve stabilized everything but the function section. It doesn’t mean we cant change wording/explanations/encourage/discourage.
+
+EAO: To be explicit, my understanding includes the data interchange model. That’s been more stable than the syntax in the last year or two.
+
+APP: It’s not normative.
+
+EAO: It becomes more useful as we stabilize unless there are specific things in the data model requiring change. But I’m not aware of others proposing data model changes.
+
+MED: All of the major subheads failed to appear in the contents and nobody noticed. If we look at it… I’m trying to move the ball and I’m not sure that’s part of it because it’s not normative.
+
+EAO: I’m saying it should be in part 9 as non-normative.
+
+MED: Nobody is saying remove it. \[Reads MF2 data model definition\].
+
+EAO: I’d be happy to remove the DTD. I’m not aware of anyone parsing anything at all with that model.
+
+APP: Make a proposal. We say ‘future changes…’ \[missed\]
+
+MED: We’d be stabilizing the data model representation. It’s really an interchange representation. Forgetting those words gives the wrong impression.
+
+MIH: ICU has the current data model marked as draft. We should keep it public in draft. I hope that’s public and visible for people to use and give feedback. I’d be reluctant to remove it.
+
+MED: I don’t think anyone is proposing to remove that. EAO is proposing to remove the DTD.
+
+EAO: Does ICU use the DTD.
+
+MIH: No.
+
+EAO: I’ll remove that and change the title to what MED was asking for.
+
+APP: Put in a PR to argue the wording.
+
+\[SFC joined\]
+
+MED: Do we have a sum-up of what we’re doing
+
+APP: Ask CLDR TC to finalize our spec in v47 and in return, we will prepare a function set in a way that we’re not prematurely stabilizing these.
+
+MED: ICU is going to be looking for the functions to at least be proposed in 47\. They’re the most nervous about those and they’ve undergone the most changes. I think the recommendation is to make part 9 stabilized and **the functions to be in ‘proposed’ except for the cases where everyone agrees they are to be stable.** The other part of that is the data interchange needs some wording fixes, and we’re going to do that.
+
+EAO: I do believe that if we need to select a subset as ‘final’ that subset is :string, :number and :integer.
+
+APP: I agree with that.
+
+EAO: That’s presuming removing the style percent thing is approved.
+
+MED: Any qualms about integer MIH.
+
+MIH: No, they’ll object to not having date.
+
+APP: It is proposed. That doesn’t mean we can't implement it as written.
+
+MED: That’s really a dispute between ICU and ICU4X, not CLDR.
+
+APP: Any objection to the proposal?
+
+SFC: Sounds reasonable but I’d like to see it written down. I’ve complained that the spec is ‘stable’/’proposed’ and this is another level.
+
+APP: No, this will be operating under our stability policy. Just the functions would be proposed except the functions that we agree as a group.
+
+MED: Next steps are to take this to CLDR and inform ICU and ICU4X. Luckily we’ve got two people here. Then I think we can work towards ICU and ICU4X being comfortable with :string, :number and :integer. SFC, can you take this to the ICU4X team. Especially if I have a reminder.
+
+APP: I can remind you.
+
+MED: SFC, MIH can you also take this to the ICU team.
+
+MIH: OK.
+
+APP: If you discuss with a TC, can you also invite me?
+
+EAO: And me.
+
+SFC: This week, the ICU4X meeting is in CET.
+
+MED: The hard deadline is 26th. We want to discuss this week.
+
+SFC: We can look at a special slot if that doesn’t work.
+
+EAO: ARe you taking the action to mark the functions as required?
+
+APP: Yes.
+
+EAO: I’ll file a couple of data model text PRs, and the style percent thing we can drop?
+
+MED/APP: Yes
+
+SFC: I assume that means we’ll replace it with we-don’t-know-what yet?
+
+EAO: Yes.
+
+## Topic: Semantic skeletons (\#866)
+
+*Shane has requested that we review how to include semantic date/time skeletons in 47*
+
+## Topic: Handling the `*` key vs. literal key value `*` (\#996)
+
+*Mihai raised the issue that the fallback key is not distinct from its literal representation. Eemeli created a PR to address it. Conversation has ensued.*
+
+## Topic: Unquoted Literal Syntax (\#[724](https://github.com/unicode-org/message-format-wg/issues/724))
+
+## Topic: Issue review
+
+[https://github.com/unicode-org/message-format-wg/issues](https://github.com/unicode-org/message-format-wg/issues)
+
+Currently we have 38 open (was 36 last time).
+
+* 21 are tagged for 47  
+* 3 are tagged “Seek-Feedback-in-Preview”  
+* 6 are tagged “Future”  
+* 14 are `Preview-Feedback`  
+* 1 is `resolve-candidate` and proposed for close.  
+* 4 are `Agenda+` and proposed for discussion (see below)  
+* 0 are ballots
+
+| Issue | Description | Recommendation |
+| ----- | ----- | ----- |
+| [935](https://github.com/unicode-org/message-format-wg/issues/935) | Well-formed vs. valid (particularly [https://github.com/unicode-org/message-format-wg/issues/935\#issuecomment-2529306693](https://github.com/unicode-org/message-format-wg/issues/935#issuecomment-2529306693))  | Discuss |
+| [724](https://github.com/unicode-org/message-format-wg/issues/724) | Message Format Unquoted Literals | Discuss |
+| \#865 | TC39-TG5 user study | Discuss |
+| \#866 | CLDR semantic datetime skeleton spec is nearly ready and MF2 should use it | Discuss |
+|  |  |  |
+|  |  |  |
+
