Create notes-2024-05-13.md

unicode-org · May 13, 2024 · 4a6c24e · 4a6c24e
1 parent 60c1b1f
commit 4a6c24e
Showing 1 changed file with 226 additions and 0 deletions.
diff --git a/meetings/2024/notes-2024-05-13.md b/meetings/2024/notes-2024-05-13.md
@@ -0,0 +1,226 @@
+# 13 May 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Elango Cheran - Google (ECH)
+- Mihai Niță - Google (MIH)
+- Ujjwal Sharma - Igalia (USA)
+- Tim Chevalier - Igalia (TIM)
+- Steven Loomis - Code Hive Tx, LLC / Bloomberg (SRL)
+- Matt Radbourne - Bloomberg (MRR)
+
+Scribe: USA, TIM, ECH
+
+## Topic: Info Share
+
+TIM: Posted a link to the blog post in the Unicode Slack.
+
+## Topic: Tech Preview
+
+APP: Task list still pending, will try to get it done this week.
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+|  PR  |                         Description                         |              Recommendation             |
+|:----:|:-----------------------------------------------------------:|:---------------------------------------:|
+| #781 | Simplify source bidi isolation rules                        | Discuss (Merge)                         |
+| #780 | [DESIGN] Contextual options in the `u:` namespace           | Discuss                                 |
+| #774 | Refactor errors, adding section for Message Function Errors | Discuss                                 |
+| #769 | Add test:number and test:plural function definitions        | Discuss                                 |
+| #753 | Add design doc on function composition                      | Discuss                                 |
+| #744 | Fix design doc                                              | Merge (approved, waiting on bearfriend) |
+| #743 | Collapse all escape sequence rules into one                 | Discuss                                 |
+| #728 | Add "resolved values" section to formatting                 | Discuss                                 |
+| #673 | Fix whitespace conformance to match UAX31                   | Discuss; related to 781                 |
+| #646 | Update spec as if PR #645 were accepted                     | Depends on 645                          |
+| #645 | Add design doc for dataflow for composability               | Merge design doc to enable discussion   |
+| #634 | Design doc to capture registry maintenance                  | Discuss                                 |
+| #584 | Add new terms to glossary                                   | Discuss                                 |
+| #558 | Add <when> to help select the right <match>                 | Depends on registry changes             |
+| #646 | Update spec as if PR #645 were accepted                     | LDML46                                  |
+| #645 | Add design doc for dataflow for composability               | LDML46                                  |
+| #634 | Design doc to capture registry maintenance                  | LDML46                                  |
+| #584 | Add new terms to glossary                                   | LDML46                                  |
+| #558 | Add <when> to help select the right <match>                 | LDML46                                  |
+
+
+### #781
+
+APP: I think apart from minor textual things, it’s ready to merge. We should still have a discussion regarding which design direction to pick.
+
+EAO: Still concerned about the question of how a namespaced identifier would be handled in RTL mode.
+
+APP: We can have a discussion about how “name” works but realistically we need the same effect where the name token can be isolated in a decent way. Saw your feedback issue. 
+
+APP: #673 also plays in here, but that’s a topic for another week. Any concerns against the currently proposed design for bidi?
+
+### #780
+
+APP: As a design doc, it’s ready although IIUC it has the “accepted” status. I propose we skip over this and come back to this one.
+
+### #774
+
+APP: We considered giving another look, in the interim it got approvals by me and Tim, anyone opposed to it?
+
+### #769
+
+No comments, merged with consensus.
+
+### #753
+
+Approved by Elango and Mark, Eemeli and Addison made comments. Tim saw Mihai’s comments but didn’t have a chance to respond just yet, is planning to address outstanding comments. 
+
+MIH: Not happy with the current resolved value since there’s a lot of disparate things in there. Like TIM’s direction. See both changes in conflict. We’ve been hurt before by opening big cans of worms.
+
+APP: We have a problem with resolved value. TIM’s document is useful it outlines requirements. Have a mental model of things we would want to happen but not 100% sure that this describes but don’t see TIM’s doc as a barrier.
+
+EAO: See this as challenging of an environment, don’t have a strong opinion on the subject.
+
+TIM: There’s no proposed design, just the context to set up a discussion for a proposed design.
+
+EAO: If we better described how stuff works around `:number` and `:integer` then this would be better defined.
+
+APP: We have a bunch of examples of things we’d like to see work.
+
+MIH: Still wondering if we’re focusing on the correct problem. How do you chain unrelated functions? I’m not interested in the uncommon case where you slightly tweak how a certain thing is formatted vs the more common case where two disparate formatters are put together.
+
+EAO: that sort of transforms are achievable at least theoretically and we should better define what happens when they’re put together.
+
+STA: Quick comment but I think a lot of these rules regarding merging/transforming can be offloaded to the authors of functions. If two formatters are supposed to be strung together it should be the responsibility of the function authors to ensure that it works.
+
+EAO: I agree with Stas, but we’re the authors of :number, :string and others. I would prefer having time for reviewing this once before it’s merged. I’m fine with it being done async once I’ve approved it.
+
+### #744
+
+SRL: Ideally, it’s good to wait on reviewing until the CLA is signed.
+
+### #743
+
+Was blocked on STA’s review, finally was reviewed and objections were dropped.
+
+STA: While I mentioned I was leaning against this change, I didn’t mean to block it but happy to see that both of these approaches are consistent and have prior art. Allowing for any character to work in its escaped form would be taking things too far. I think this is a reasonable compromise.
+
+EAO: This is effectively another place where we could be lenient on input and strict on output. If escapes come up unexpectedly, there’s only one reasonable assumption about author’s intent. If we allow for that, we probably should include spec text that says if you’re working with MF2 syntax, you should only escape required characters. When you’re writing MF2, you don’t get penalized for not knowing you’re supposed to escape this here. When you’re reading it, you only see escapes that are contextually appropriate.
+
+MIH: I think the change improves things, but don’t think it solves it. Rules are still not consistent. We allow escapes but don’t require them everywhere. I still have to deal with the mental model where here, I must do this, and here, I must do this other thing. Yes, I can escape these things in all places, but if I don’t, I’m forced to escape things depending on context, so the rules are not consistent.
+
+APP: I think you might be looking at this upside down. Today we only allow and require escapes in places where the syntax would otherwise be broken. This provides an affordance for less well-educated human users who accidentally escape things because they don’t understand the rules. The risk of that is that you then get into the multiple escape thing that we’ve avoided with our syntax as much as we can, where the serialization wrapper around the message inserts even more escapes. That would be an argument for not adding this. I’m willing to take it as an affordance for translators and developers who use this. MIH, does that mean you don’t object to merging this?
+
+MIH: I don’t object, but I don’t think it’s solving the problem completely. I can make a PR. Requiring escaping in all conditions. If I have foo bar in a message itself, or if I have it in a literal that is an option to a formatter and that thing is localizable, it’s going to mean the same string in two places, in the message and the option, must be escaped differently. The rules requiring you to do the escaping are different. So the safe thing the user will do is to always escape.
+
+APP: Doesn’t this fix that?
+
+MIH: Partially; it tells you that you’re allowed to. It would be nicer to say the rules are the same everywhere and this is what you must escape everywhere. Escape the pipe even in plain messages, escape curlies even in literals. That would make the rules consistent.
+
+EAO: Is this directly changing the spec or adding a design doc?
+
+APP: Changing the spec
+
+EAO: I would be very happy to hopefully merge this and separately have the follow-on conversation that MIH wants us to have.
+
+STA: My opinions here are not very strong; I think requiring those escapes everywhere would be going too far. This would be a thing that generates WTFs for people. They write literals and know they’re delimiting them with vertical bars and for some reason have to escape curly braces. I don’t think it will be very common. The same content will travel from literals to patterns – distinct use cases, not a lot of localizable content in literals as option values. Not what they are for. Current PR is reasonable compromise that optimizes for some convenience. People can do it, but they don’t have to.
+
+APP: I propose we merge, but I suggest we immediately propose the note text that EAO mentioned before, to make sure that it’s clear what we’ve done.
+
+EAO: That seems highly correlating to the discussion on how to handle bidi in the source. Those are close to each other in spirit at least, in what they’re doing. Happy to file a separate PR adding a note about emitting syntax with these potential escapes.
+
+APP: Can we merge? I will merge this. 
+
+### #728
+
+APP: Resolved values in formatting – EAO’s PR. A bunch of discussion, no approvals. Are we ready to discuss this?
+
+EAO: I think we ought to resolve that the meta-discussion here, which is what Tim’s design doc is set up for, and from there kind of work to how we want to define what is currently “resolved value” in the spec. My proposal would be to work through the specific examples of what the interactions that are available between the default registry functions for how to approach/add a solution for this.
+
+APP: So we should package all of the resolved value stuff into a conversation that’s pending?
+
+EAO: Yes
+
+### #673
+
+APP: Whitespace to match UAX31. Semi-blocked behind a discussion of bidi or related to that, since it’s fixing whitespace handling. Skip over that.
+
+### #646
+
+Depends on 645
+
+### #645
+
+Composability
+
+### #634
+
+APP: My work on the registry maintenance spec. Haven’t gotten it to “Done” but have done some more work on it, so that’s not yet ready. Happy to get comments or suggestions. Bottom two PRs are not ready for discussion.
+
+EAO: What happened with my PR moving design docs around?
+
+APP: We discussed and – one or two meetings ago? 
+
+STA: I proposed making a table rather than moving everything around
+
+EAO: You mentioned previously adding the design docs to the agenda. Should we go through the design docs now instead of going through the issues?
+
+## Topic: Issue review
+Let’s close all of the issues
+https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue+is%3Aopen+label%3ALDML45
+
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 60 open (was 55 last time).
+14 are Preview-Feedback
+0 are resolve-candidate and proposed for close.
+3 are Agenda+ and proposed for discussion.
+
+
+### #738?
+
+EAO: Filed it as implementer feedback.
+
+### #786
+
+EAO: Don’t care which way we go really, it could even be in TypeScript format. We just need to make sure some of our requirements are catered to for instance if the type of a certain thing is an annotation or an expression.
+
+ECH: I’m trying to understand how to understand what we have vs. the proposed change. In what cases would the UnsupportedExpression be useful, as we have it?
+
+APP: It would matter only if we decide later on to unreserve a keyword.
+
+TIM: There’s some differences already between the three implementations’ data models. Perhaps we can come back to this later once we have some feedback on other issues and consider them together in context.
+
+ECH: This is tagged as feedback. Since I was only asking for background info to understand the change, I agree with waiting for more time to consider feedback.
+
+
+### #782
+
+EAO: The next step here would be for someone to propose a spec change.
+
+EAO: If the change is a radical departure from our current design then we’d need a design doc for this, otherwise we can just do a spec change directly. Basically if we go back on the assumption that we always have a fallback result and a specific view on error handling.
+
+APP: While this is an integral part of the design but it isn’t something that’s always been front and center. Let’s see how MIH’s PR works out.
+
+MIH: Yes, the PR won’t undo months of discussion.
+
+EAO: For instance having two endpoints with different strictness levels would be perfectly fine but changing the default behavior drastically should be done via a design doc.
+
+ECH: There was a lot of feedback from the ICU-TC and it’s all fairly similar in that the current spec text is too strict and the constraints need to be relaxed.
+
+EAO: To reiterate: I’m happy with whatever you proposed, just request that we have a more detailed design doc instead in case there’s a major change.
+
+APP: Agreed, let’s do a design doc so we can contextualize this decision better.
+
+ECH: Process related: when do we decide when a design doc is in order. I don’t believe we’re really consistent about this.
+
+EAO gives the example of the encapsulation design doc. Having all of that information well organized helps a lot.
+
+MIH: Fine making a PR, it’s not a big departure from the status quo.
+
+EAO: Noting that the current PR also modifies the expression attributes PR by removing the runtime impact.
+
+STA: This might be a good moment to ask everyone to check out the discussion I posted.
+
+EAO: It might be better if we point to the issue in the discussion.
+
+https://github.com/unicode-org/message-format-wg/blob/main/exploration/expression-attributes.md 
+
+https://github.com/unicode-org/message-format-wg/discussions/513
+