Create notes-2024-08-26.md

meetings/2024/notes-2024-08-26.md

@@ -0,0 +1,151 @@
+# 26 August 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Elango Cheran - Google (ECH)
+- Mihai Niță - Google (MIH)
+- Mark Davis - Google (MED)
+- Richard Gibson - OpenJSF (RGN)
+
+* Scribe: ECH
+
+## Agenda
+MED: The final date for the spec is Sept 25. Last time it was delayed a bit. This time, we need to not update the spec past Sept 25 in ways that would make ICU4C and ICU4J implementations invalid.
+
+APP: Yes, and regarding deadlines, we either need to make faster progress, or we will slip into next spring.
+
+MED: One question for MIH is how much have the changes in the spec so far affected ICU?
+
+MIH: I haven’t tried to implement them as they happened.
+
+MED: You’re caught up, right?
+
+MIH: No, not yet. We have a PR for ICU4C and updated ICU4J to make the shared MF2 tests all pass, which helps, but we’re not there yet.
+
+EAO: Even if we don’t get out of Technical Preview for LDML 46, we should still get out a release. I have updated the JS implementation to the current version of the spec. I’ve added changes to the tests.
+
+APP: A thing that I’m concerned about is that some of the things that are coming soon might have impact. Some will make changes to whitespace or Bidi controls. That may not have major impact but we need to make sure the details work. Other things may have more impact like how we deal with selectors and related declarations.
+I promise to set up meetings instead of having face to face meetings. We have to come to a call of whether we’re exiting Tech Preview for CLDR 46 or not.
+
+EAO: As a comment from the work I did is that the biggest changes I’ve made are reification of attributes. Also, changing the data model representation of options as a mapping. Duplicate options and attribute usage are called errors, but they can’t show up in the data model, so I call them “syntax errors”.
+
+MED: For things where we previously disallowed things to be allowed is much easier to do for implementers, because old messages are still valid.
+
+APP: Dates are coming up. 
+
+## Topic: Info Share
+
+ECH: Glad we’re talking about testing, feedback. Another thing I mentioned before is conformance testing. Hasn’t been brought up. Did some improvements. Lot of concern because setup wasn’t good before. TEsting the tests we had. Testing against ICU74… surprise! There are going to be errors. Still some things to resolve. Link to dashboard to see the green-ness:
+
+https://unicode-org.github.io/conformance/
+
+EAO: On Dec 13 I will be talking with the Finnish National Committee to talk about how Finnish gets represented in CLDR, and whether it works for Finnish. There could be similar entities out there.
+
+### #863 Add tests for pattern selection
+
+EAO: There is somewhere in the spec where a lowercase “should” should be a capital SHOULD or MUST.
+
+MED: I want to say that it should be a capital SHOULD. The reason that it cannot be a capital MUST is that we do have to adjust plural rules. An example is that we realized recently that pluralization for French changes for compact notation when you get up into the millions. Also, there is a change for Wolof that we had to do.
+
+EAO: I am also in favor of making the recommendation be a capital SHOULD. We should separate the SHOULD recommendations back to MUST recommendations.
+
+APP: Let’s have a PR for that. Any objection to merging this PR, and then we can make followup 
+
+### #862 Miscellaneous test fixes
+
+## Topic: Disallow “whitespace or special char” prefixed `.` in reserved-statement’s body (#840)
+RGN: I would like to see a more significant change to be made, if we are to make a change.
+
+EAO: I would like to see a small change, and move from there.
+
+APP: I don’t understand the change because it moves part of `nameChar` to `name`, and maybe `nameChar` is used somewhere else apart from `name`. What’s the benefit here?
+
+RGN: There is a description of the benefit in the commentary of the Markdown. The approximate motivation is to recover in a parse error, such that the statement body should not be so broad that something that is truncated should not be a reserved truncated statement.
+
+MIH: I’m not against it, but it seems wrong to tinker with small things here and there. We are changing one production in the grammar in reserved statements, and redefine what reserved means. How often are we going to see this? I think we put too much emphasis on the whole reserved thing, and it feels like busy work.
+
+APP: I think the purpose is that if we ever added another keyword, we want to recognize the end of the statement. The purpose of reserved statements is to have it be possible to `.foo` and see that even when that statement is broken, we could still proceed to the `.match` and see that it was valid. If this PR helps us with that, I think it’s useful.
+
+EAO: This happens in practice when you’re editing a message. It creates a bad user experience for an author of a message using tools. A further step from this proposal is if we don’t allow whitespace to show up in a statement, it allows up to drop the requirement for a ___ statement to end in an expression.
+
+MIH: I think 
+
+APP: I think we need to study it more as a group. 
+
+ECH: Just observing that the discussion makes it sound like we’re over optimization based on future use cases that we haven’t seen.
+
+RGN: I think this has relevance to more than just syntax highlighting during editing. Reserved statement syntax affects which declarations would be valid in the future.
+
+https://github.com/unicode-org/message-format-wg/issues/547
+
+The change in this PR seems to address at least one bullet point from that issue (`.strict true .local $var = {|val|}`), which gives me more confidence that it is a step in the right direction.
+
+APP: One thing to note is that our grammar says that it is consistent with `ncName`, although this change would make that not true.
+
+MIH: The fact that this change fixes an issue that RGN brought up a while ago by accident makes me worried that it’s breaking something by accident because we’re just tinkering.
+
+EAO: This PR doesn’t relax the requirement of having an expression at the end of a reserved statement. So what it does is intentional, and what RGN wants would be a further change.
+
+APP: Let’s study this seriously and discuss next week.
+
+## Topic: Selection-declaration (#824)
+_Discuss the design options seeking WG consensus. Timeboxed to 15 minutes or will go to ballot._
+
+https://github.com/unicode-org/message-format-wg/blob/main/exploration/selection-declaration.md 
+
+MED: I put in a comment that I think could solve the problem. https://github.com/unicode-org/message-format-wg/pull/824#discussion_r1731496159 It would put in a restriction that would make EAO’s `$count` work right.
+
+APP: We don’t have a selector for `:date` or `:person`. It’s possible that they would want to produce different 
+
+MED: It could happen more often, but it affects a relatively small percentage of cases.
+
+APP: I’ve been saying that we would ballot this a few weeks in a row without doing it. MED, I should check if your alternative is not already covered. If you want the alternative to include that proposal, please make a PR to the design doc. And then we can ballot this next week, but we need to ballot it because this is an important issue.
+
+## Topic: Bidi design (#811)
+_Bidi and whitespace options need to be discussed in light of the design document._
+
+https://github.com/unicode-org/message-format-wg/blob/main/exploration/bidi-usability.md
+
+APP: We merged this design document so that you all could read it. This has a lot of impact if we go down this path.
+
+EAO: I still think that we should have `name` be isolated. It would have the same effect that some of the parts of this PR would have. I would like to get input from other implementers.
+
+APP: I thought a lot about the implementation aspect and also people editing, including translators and message authors. Bidi controls are invisible. Moving curly brackets around that cause the controls to do funky unexpected things. My proposal is to make the Bidi controls and strong markers optional for super loose isolation. Parsers that parse messages would just ignoring things because they’re ignorable syntactically. It allows mirrored symbols to be unpaired. And messages could be tightly wrapped. I’m open to getting feedback, but I don’t want to make our syntax so fiddly because they need to work with Bidi things that they don’t understand.
+
+EAO: I’m concerned that we can get the right behavior without having isolation. For example, in a RTL context, interspersing a placeholder that has RTL content, I don’t see how we can get that to work right without isolation. Within `name` and identifiers, I can see high value for allowing just maybe the RTL mark, then that ensures the LTR doesn’t bleed to the end.
+
+APP: You would put that at the end because the `$` sign is already strongly LTR. I agree, that is an area where we have vagueness. Another thing is to have key lists because what you see in visual order may not be what is written in logical order, so we have to be careful.
+
+EAO: I would like the LTR mark to be in the `name` construct and not all the places where `name` shows up.
+
+APP: NFC doesn’t interact with that.
+
+MIH: It really feels like we are micro optimizing, but I’m not sure for what. I expect translators to use professional tools to edit messages. It might be useful only once in a while where someone uses a text editor to fix stuff. It feels like we’re designing a programming language and worry about what happens if people edit their source code in Notepad. No one edits code in Notepad. When it comes to inserting the marks, we don’t know how it will negatively affect messages. And lastly, we cannot say “I think it works” without trying it because there are lots of text editors that don’t support Bidi correctly.
+
+EAO: Look at #847 to see why we are considering things as a corner case. I think we should be conformant with UAX 31 and UTS 55.
+
+MIH: I already understand what we’re trying to do. If we try to follow specs, then we should make our text reflect that we introduce a feature to solve which statement in which spec, but not because we feel like it or think it would be good.
+
+APP: I think we should be conformant with Unicode specs. There are some things whitespace-wise that come to the front. I pushed the Bidi discussion because that issue is not covered by that.
+
+## Topic: Standard, Optional, and Unicode Namespace Function Set maintenance (#634) [was “registry maintenance”]
+_This is the function registry maintenance procedure design. Let’s review with an eye towards using as a template for other work._
+
+https://github.com/unicode-org/message-format-wg/pull/634
+
+APP: Based on last week’s discussion where we would move from “registries” to specifications of “standard” and “optional” functions.
+
+EAO: This is leading to spec language where we need labels on functions and options. I would like feedback from others on that. APP, you proposed `accepted`, `released`, and `deprecated`. Some iteration on names would be helpful.
+
+ECH: Why not reuse the terms that ICU uses for APIs?
+
+APP: I pulled that from somewhere that seemed reasonable, but I’m happy to match what ICU does, which sounds reasonable.
+
+EAO: I would be very happy to reuse something else as a starting point. Can you find a link to the ICU API states and add it to the PR.
+
+
+
+## Topic: AOB?
+
+(discussion of process)