Create notes-2024-04-08.md

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

@@ -0,0 +1,217 @@
+# 8 April 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Tim Chevalier - Igalia (TIM)
+- Elango Cheran - Google (ECH)
+- Mihai Niță - Google (MIH)
+- Matt Radbourne - Bloomberg (MRR)
+
+Scribe: MRR
+
+## Topic: Getting to Done
+
+Key dates:
+28 February: CLDR-TC approval (milestone 45-alpha)
+13 March: last ICU check-in
+27 March: last specification change (milestone 45-beta)
+10 April: CLDR release (milestone ldml-45)
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+|  PR  |                       Description                      |              Recommendation             |
+|:----:|:------------------------------------------------------:|:---------------------------------------:|
+| #762 | Remove registry.dtd and registry.xml from Tech Preview | Merge                                   |
+| #761 | Tests for invalid number literals                      | Merge                                   |
+| #760 | Remove expected output from date/time formatter tests  | Merge (but discuss)                     |
+| #757 | Tech Preview Blog Post                                 | Merge                                   |
+| #755 | [DESIGN] Effect of selectors on placeholders           | Not ready                               |
+| #754 | [DESIGN] Bidi usability                                | Merge                                   |
+| #753 | Add design doc on function composition                 | LDML46                                  |
+| #744 | Fix design doc                                         | Merge (approved, waiting on bearfriend) |
+| #743 | Collapse all escape sequence rules into one            | LDML46                                  |
+| #728 | Add "resolved values" section to formatting            | LDML46                                  |
+| #704 | Address #703: make syntax/data model fallback clear    | LDML46                                  |
+| #673 | Fix whitespace conformance to match UAX31              | LDML46                                  |
+| #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                                  |
+
+
+762
+APP: Any comments/objection to merge? [No]
+
+761
+APP: Richard Gibson said we should test invalid number literals.
+
+MR: What is the situation with the message-format-wg tests vs the conformance tests? [Which is the source of truth?]
+
+APP: Need to do - Error classification, ensure there’s tests for mustards. Thought needs to go into the function registry. I commented on an issue from Tim about testing against CLDR.
+
+MIH: Inside Google, when we update tests, what I found useful is, rather than testing against the raw string, we can (1) give a list of possible results or (2) regular expressions. Relaxing it proves that we can get something more useful.
+
+EAO: Space for up to 3 different test suites. First, we want a test suite to be part of our work - we’ll want to iterate on this - match the tests to the spec.
+Second - conformance test suite, which has an expectation that tests the exact behavior compared to ICU.
+For our test suite, what might be useful is to have a definition of one or more functions used for testing - something dumb that echos it’s options out so we can determine that the function was called in the right sort of way.
+
+ECH: Decouple implementation-specific details. We can have a fake implementation formatter. MRR and I have talked about having a shared schema for the tests. We should get that nailed down soon.
+The conformance project people got feedback from Mark and others - there’s not one single truth for formatting. There are things we can test independent of ICU - It’s maybe a separate set of tests.
+
+APP: There’s a call for us to think about design. I share MIH’s pain - you have to say which version of ICU/CLDR. We need to be careful - when we say conformance, our conformance needs to be performance agnostic. Circling back, can we merge these tests.
+
+EAO: What is in the test directory describes how the JSON files are consumed.
+
+TIM: A temp solution could be, rather than having a simple ‘exp’ field. That would be a way to package the tests in one place.
+
+MRR: Feeling like the work I’m doing on the schema might be wasting a lot of time. Working on something that could come later. Working on things I haven’t shared and kind of being redone for the WG repo. If we sync those up, could be dropped into conformance repo with exact same schema.
+
+EAO: We have one set of spec tests in the WG repository that is not dependent on the specific behaviour - not on specific outputs. And the ICU conformance tests to copy the WG tests and expand on those tests to get complete conformance with ICU.
+
+APP: Can I merge this?
+
+ECH: There’s not a lot of data-driven testing data. We need to generate that and CLDR will be the place that we’re going to drop it. To be consistent, it would be nice to have.
+
+APP: We have to be careful to separate ICU/CLDR from MessageFormat.
+
+EAO: Possible action item. Are there any changes?
+
+MRR: [Minor]
+
+APP: We have some gnarly things to iron out that will have an impact on testing.
+
+EAO: Any objection to me adding functions so that tests can use those functions, rather than depend on ICU. I’ll submit a PR - it’s be easier to argue over a technically specific thing
+
+760
+APP: Any objections to removing datetime? [None] Anything else to say before I merge, TIM?
+
+TIM: Did you have ideas about how to store the ideas. They’re in git history.
+
+EAO: That’s a use-case for switching to YAML.
+
+ECH: Disagree
+
+APP: Merge this? [Merged]
+
+757
+APP: Thank you for comments so far.
+
+755
+APP: I started to work on this. Needs more work. You’re welcome to look.
+
+754
+APP: I think we’ve boiled the ocean as much as we can. I’d like to merge the design document - it’s still as proposed.
+
+EAO: A couple of discussions are ongoing in that PR that will get lost if we merge it:
+LRI/SRI pair - there’s a conversation on that.
+Newlines within message syntax that could potentially terminate an LRI block - if you’ve got a $rightToLeft. It’s going to parse the whole paragraph as right-to-left.
+
+AP: Assuming we don’t say the base directionality.
+
+MIH: If we try to protect against malevolent controls, they can put things in the literal string itself, the options functions, all kinds of places. We can have some guidelines in general but, total prevention I doubt can be done here.
+
+EAO: I bet we could do a lot if we allowed the isolation of everything that could do that. That’s not too many things. If we just allow, the overall direction can be set.
+
+APP: Our syntax is LTR - it permits the isolating of controls, it does not require it. You can still write a confusing looking message. We give people the tools to make bi-di survivable. My design doc helps and I’m open to ways to make it even more strong. Requiring people to work with invisible controls is something that we’d like people to avoid doing.
+
+EAO: Two things: We should make it explicit that the syntax should be rendered as LTR. That would clarify matters in a bunch of cases. It describes what we allow in terms of isolation.
+I think we should isolate everything -the complexity of that is not too much. We could also allow LRI in certain places. All of this is predicated that in most of the places this is going to be rendered, the support is good and we should use markers because of editor concerns. This should be forward looking. I think isolation works in all the browsers and electron. I have not tested Eclipse or InteliJ. I’d rather work for the future we’re going to have, rather than patching and making things messy.
+
+MIH: I promise you VSCode is a disaster. They draw directly on canvas and other crappy stuff - it’s bad for bi-di.
+
+EAO: Are you saying RTL markers might work but RTL isolation won’t?
+
+APP: There are specific cases where the marks are helpful - in trailing position, where marks help restore directionality. If you do isolates, the entire string is a neutral character.
+
+EAO: That means that we’re rendering syntax in a RTL context.
+
+EAO: I would like us to be able to have LTR isolation within expressions. Effectively a new line resets the isolation.
+
+APP: You’re suggesting a few more changes and then we merge?
+
+EAO: If the discussions are too much to conclude in the PR, include the gist of the discussions within the design doc. If we just merge this, the discussions in the current PR are [marked as]concluded but I don’t think they _are_ finished.
+
+744
+APP: Waiting on the agreement to be signed. If this isn’t done, I’ll make a new PR. We’ve already agreed that we want to do it.
+
+## Topic: Issue review
+
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 56 open (was 53 last time).
+14 are Preview-Feedback
+0 are resolve-candidate and proposed for close.
+1 is Agenda+ and proposed for discussion.
+29 are Future or LDML46
+9 are LDML45
+
+| Issue |                  Description                  |         Recommendation         |
+|:-----:|:---------------------------------------------:|:------------------------------:|
+| #706  | We needs a list of possible error codes       | Discuss                        |
+| #626  | Fix “function resolution” to handle selectors | Discuss (propose moving to 46) |
+| #589  | Consider forbidding pass-through .local       | Discuss (propose reject)       |
+
+
+589
+APP: I proposed previously killing it about 3 weeks ago. You were semi in agreement with doing that? I didn’t want to step on it if we were only vaguely in agreement.
+
+EAO: My issue is that the syntax (without an annotation) it looks like nothing is happening except an assignment of A=B. We don’t have a need for passthrough so we could just forbid it. If nobody thinks this is valuable, we’re not going to die on this hill or anything. We’re likely going to end up in a place where it doesn’t really matter - implementations are going to do sensible things. It _could_ lead to surprising behavior for a user.
+
+MIH: I would keep it for when we discussed how things are resolved - interaction with locales and anything like that.
+
+APP: Unmark it as 45? OK.
+
+626
+APP: My proposal is that we’re not going to fix this now and we should move it to 46. Are we good with that? OK, that’s done.
+
+706
+APP: I want to triage this. I don’t think we’re going to fix this just now. Assign to 46? OK.
+
+### TC39
+EAO: https://github.com/tc39/proposal-intl-messageformat/issues/49
+Got pushback on DSL. Proposal was to move forward without it. Got pushback from Google on moving forward without the DSL. They can’t commit to it and aren’t sure about the syntax.
+
+APP: I understand. We need to make this a success. I think there is a further conversation to be had to show the standard is viable. We can then push on TC39 to do something with it. It’s a chicken and egg - people will be creating workarounds. We want the workaround people are using to be MF2.
+
+EAO: The implicit communication from TC39 has reversed its course.
+
+MIH: The situation is nuanced. Shane tracked down docs from meetings from 2 years ago saying that they want the syntax - they didn’t change communication. I understand it’s annoying.
+
+EAO: Shane included a link in the issue.
+
+ECH: I want to make sure this conversation includes the wider context - not “Google I18n said this - TC39 said that”. It just takes a little bit more time. As we all know, we were compromising on things to get things in for CLDR45 - there are more discussions to be had. The discussion in the issue does a better job of explaining why contributing something to the ecosystem before the standard is set could be damaging. Let’s stick to discussing the technical things.
+
+EAO: I’m not trying to blame Shane or the Google i18n team. I’d like to standardize this including the syntax. Some in TG1 of TC39 don’t want the syntax to be in, hence the ‘stuck’ expression I’m using in the issue.
+
+ECH: It depends on things being settled within the working group here. It needs to land. I think it just takes more time than a few weeks. I don’t want to pre-characterize the effort.
+
+APP: The standards process at ECMA takes time. That doesn’t mean that we can’t finish our work - if we do a good job with the tech preview for the fall, we can have something really solid. I think that we can resolve the technical challenges and show success.
+
+EAO: Effectively what I’m trying to show, in addition to us finalizing our work here, there’s this added concern “we need to see around a dozen org make significant use in production” [reads from GitHub issue]. The Intl MessageFormat proposal has this additional requirement to advance to stage 2 for TC39. Anything that TC39 says is not restricting what we can achieve in this WG. After our work here is done, we need to get this spec to be adopted by industry and then it can be adopted by JavaScript, rather than it being standardized in JavaScript and then getting the industry to use it. Our work needs to stand on it’s own merits here - I hope it does.
+
+### HTML
+APP: I’m going to create a release, just like I did with alpha. I need to talk to Louis and Mark about the mechanics of maintaining the HTML. I also hope to dress it a little bit. I need to find out the expectation. I hope to work on `main` for 46 and 45 live in the published LDML spec.
+
+MIH: People playing with ICU in 2 months from now are going to see a different thing.
+
+APP: LDML part 9 will be stable.
+
+MIH: Also the spec file and data model file.
+
+EAO: In the short term, you can use permalinks. There’s a whole load of work that you’re (APP) going to do but there are places where we’re referring to terms that have changed from singular to plural etc. Are we eating the cost of having to do this work twice by having it totally separate, or do we want to de-duplicate?
+
+APP: I plan to use tooling. I’m lazy enough that I don’t want to do it twice.
+
+MIH: What do we think about a subfolder `releases/45`?
+
+ECH: I think you’re overcomplicating it. You can just create a GitHub release.
+
+APP: Bear in mind our spec can be published as part of TR35. The data files will be in the source.
+
+EAO: The short-term fix is that we create a tag. We can later decide if we want a branch etc. [The tag] will retain permanence going forward.
+
+APP: I’ll keep everyone updated as we’re going through this.
+
+### AOB?