Create notes-2024-08-05.md

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

@@ -0,0 +1,240 @@
+# 05 August 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Elango Cheran - Google (ECH) - acting chair
+- Mihai Niță - Google (MIH)
+- Eemeli Aro - Mozilla (EAO)
+- Matt Radbourne - Bloomberg (MRR)
+- Tim Chevalier - Igalia (TIM)
+- Richard Gibson - OpenJSF (RGN)
+
+Scribe: TIM
+
+## Topic: Info Share
+
+### Feedback
+
+ECH: Discussion in TG5… We want feedback from translators, who we have the least input from, as far as stakeholder groups. My mgmt can’t fund some of the extra work, hoping to get more people to step up.
+
+EAO: At Mozilla I’m working on changing the internal representation in Pontoon to use MF2 or a variant of it. We’ll be using the same database representation of messages for messages from all formats. Makes the most sense to use a single representation. Hoping to get some translator feedback that way. Will take some months until all of it is aligned.
+
+MIH: That’s really nice. You mean using MF2 syntax or data model?
+
+EAO: Stored in something similar to the MF2 syntax. Data model needs to be represented somehow and the syntax can handle that. There’s a Mozilla all-hands next week and during that, one of the things we want to talk about is how we represent messages to our translators. When we’re presenting them in the Pontoon UI. For example: does it really make sense for us to use the curly brace syntax for open/close? Does it make sense to use the vertical bar for literal quotes? We have to decide by next week what the MF2-ish syntax is that we’ll be presenting to our localizers. Then we have to figure out if that’s the representation we’re going to use in the back-end, or will it be pure MF2.
+
+MIH: Most systems I’m familiar with store something like a data model and show the translator something totally separate from the original format. You have boxes for placeholders, but don’t see quotes and curlies and pipes and stuff like that.
+
+EAO: We’ll see how it goes.
+
+ECH: When I’ve talked with Mihai, he’s mentioned l10n tooling – in the GUI, what’s presented to translators is widgets or chips that represent pieces of the message. The syntactic things we’ve talked about are not even visible. There’s a lot of constraints that help the translator through the UI. Something to consider, furthering this point. The other thing on the topic of feedback is there’s issue 805 that Addison filed to ask the W3C TAG for feedback. There was agreement to more formally get feedback from the ICU TC, maybe ICU4X TC… those are other avenues for soliciting feedback.
+
+MIH: Example: ​​https://multifarious.filkin.com/2012/09/10/working_with_tags/
+
+## Topic: Tech Preview
+
+Let’s review the Task List:
+
+https://github.com/unicode-org/message-format-wg/wiki/Things-That-Need-Doing
+
+Action: APP: make sure links are present
+
+## Topic: Balloting of: leading whitespace
+… and related issues dealing with escaping ., whitespace in reserved-statement (#840), etc.
+
+EAO: Balloting options seem pretty clear. Have we concluded we’ll allow leading whitespace and can we close the issue and file a PR with the syntax change?
+
+ECH: I have opinions at a meta-level. I’m OK with making the decision, but I want to have a discussion and I want Addison to be here for it. It speaks to how we make decisions and what the basis is, what principles are we holding to or not? I really want Addison to be here for that discussion. 
+
+EAO: When you say “the discussion” you mean the meta-discussion you mentioned in the comment thread for this, not the specific discussion about this change to the syntax?
+
+ECH: There’s a local maximum type of discussion we’re having. In that sense, the outcome of the ballot I’m totally fine with. As we design things in general in a more global sense, how do we know that when we create a design doc, it’s not going to be overturned by a simple vote of a handful of people sometime down the road?
+
+EAO: Just to make sure we’re on the same page, we’re agreed to make this syntax change but you’ll put on the agenda of a future meeting to talk more about the meta-level of the topic that concerns you?
+
+ECH: Yes.
+
+TIM: This is more for the discussion later, is it a bad thing that we overturned a previous decision? We made the decision previously, and now we have a new person coming in with fresh eyes and a new perspective. Isn’t this the system working in a healthy way?
+
+MIH: Certain discussions when we made them, we discussed them for weeks and voted with a big number of people. We said we knew people were going to trip over it, but there were good reasons for it. It’s not like somebody said it was ugly and we saw the light. Also happened with simple messages being in single brackets. When we voted, we knew it would be controversial. So that’s not so much it.
+
+MRR: If we’ve got stuff documented, summarized enough, we should be able to re-ask the same questions and provide a quick answer. If it’s clear what the trade-offs are, we should be able to say “thank you for asking, here’s the documentation that summarizes that decision.” Hopefully that should be enough to be able to ask the same question multiple times without opening any cans of worms.
+
+MIH: I would say we should not discuss this now.
+
+ECH: Let’s table this for now
+
+## Topic: Selection-declaration (#824)
+
+EAO: I’m interested in us resolving this situation. Are we doing something and if so, what? 824 is the PR I filed, which is suggesting one specific approach among the ones previously identified. I’m interested in hearing other people’s opinions on how we should proceed – the way I proposed or one of the other choices? The brief version is that right now, the expression you have in the .match line has no effect on placeholders. So if you have, for example, a :number selector on a variable, possibly with a bag of options, we don’t check or make sure or lead the user into using the same set of options, or the same formatter, within the results. This means that even in some of our examples (maybe not now, they may have been fixed) we were doing a .match on a number with minimumFractionDigits but in the body, we weren’t formatting the value as a number. The original issue was that the syntax leads developers to write messages that look good, but don’t work the way they expect. We ended up with a design doc enumerating various possibilities. Haven’t really discussed which option to go with from here. The specific option I proposed is the only one where I can see us making stuff simpler rather than more complicated. It would mean the .match line just has one or multiple variables, and they would need to be declared previously in order for it to work. It would simplify the syntax but add a requirement of needing a declaration for a selector. Having that declaration would also mean that the value you’re matching on ends up for sure being available for formatting. It would help make sure that the same variable is being formatted and matched on.
+
+ECH: At the risk of not having a 100% fully formed opinion, this is appealing to me. The reason is the principle we talk about with number formatting; it’s the idea that at least in the case of numbers, we know we have to do formatting first before we can do selection. Mark brought up a lot of examples in his description there. Based on that principle, it’s all the more important that if we’re going to have a certain format that we’re selecting upon, that we use that in the patterns that might use that selector. We have to be consistent. This helps guarantee that consistency, so I think that’s good.
+
+MIH: I’m fine with the change. Works more like an `.input`. The main thing is how we decide to go about it. Same rules as before, as in it’s immutable, stuff like that? Do we combine arguments? I’m for the idea, we just have to be very careful.
+Example:
+```
+.match {$foo :number minFractionalDigits=2}
+one {{This is {$foo :number maxFractionalDigits=3}}} // Problem? What happens here?
+* {{This is {$foo}}} // This is ok, we use “$foo as declared”
+```
+
+TIM: I’m fine to reuse the same variable that’s being used in a match and add options. It’s fine to use the same variable again and add more modifiers to it. If you do, then presumably you know what you’re doing.
+
+EAO: The problem that we’re solving for is that when you have a message that has a `.match` on `$foo :number` and then options, you have no .input or .local declarations, then in each pattern, you have a `$foo` and it looks like what’s being formatted in the match, but it’s not. Seems like a really easy mistake to make. 
+
+ECH: Is what you’re saying in addition to what’s being proposed?
+
+TIM: I was restating what is proposed. I like what is being proposed. It should work as before, and I like the fact that there is this one local change to the syntax.
+
+ECH: Is anyone opposed to accepting the changes on the design doc in 824? So far it sounds like there’s general agreement.
+
+EAO: One thing to note is that PR is currently also changing the status of this design doc to be “Accepted”. It does sound like what we’re doing here, but I want to make sure people are explicitly aware of this.
+
+MIH: I would really like to read the design doc again carefully to look for whether there’s any drawback in behavior. Basically, what happens inside the message if I override some parameters. I want to be sure there’s no space for weird side effects.
+
+EAO: Just to describe the change that’s being proposed, it would be that the behavioral changes, where we currently have .match expressions, you would not be allowed to have any annotations on those. It’s not changing anything about what happens in placeholders.
+
+MIH: So this would always require an .input?
+
+EAO: The change here makes it so that where we currently allow annotations on .match expressions, we would not allow them going forward. If you want to select on a numerical variable, you would need to have a .input for it. 
+
+TIM: Either an `.input` or a `.local`, right?
+
+MIH: That’s not what I imagined
+
+[...]
+
+TIM: could somebody share their screen and show the PR?
+
+(ECH shares screen)
+
+MIH: I wouldn’t change this to Approved. I’m not happy to force people to declare stuff always.
+
+EAO: Of the other proposed alternatives, do you have one you think would be better?
+
+MIH: I have to review the alternatives again. It’s one of the ones already proposed, but I have to check which one.
+
+EAO: Asking people to review this has been something that Addison’s been asking for the past few weeks. Given that people seem to have challenges in finding time for this, I think it would be appropriate to spend the next 15-20 minutes reviewing the alternatives.
+
+ECH: Do you want to timebox 15 minutes and see how we do?
+
+EAO: Let’s take 5 minutes to read the doc and then continue
+
+ECH: Now that we’ve read, have opinions changed?
+
+MIH: None of the options. 
+
+ECH: One of the options was to do nothing –
+
+MIH: The closest option is “Allow immutable input declarative selectors” The wording. We say “immutable input” and then we say it’s not an error to redeclare a variable in scope. What I would like is this option, but it behaves exactly as if you have an .input. [...]
+
+EAO: Of the available ones, that’s not horrible, but my question is, why do we need to save characters and not just have a literal .input for the input behavior? Why double up what’s happening in a .match and make that line effectively do even more complicated stuff?
+
+MIH: The reason why I’m thinking – because you often want to do selection on stuff that doesn’t show in the message. For instance, when you do selection on an ordinal type of thing, you don’t necessarily show it – there’s no “format as ordinal” in ICU. Or if you select on gender, or grammatical case. That thing doesn’t show in the message. So to be forced to say .input $foo genderOfUser etc., only to do a .match on it, it feels wasteful. I only want to do selection on it.
+
+ECH: Mihai: I think part of the motivation for this change is to enforce a good practice, to ensure that the user isn’t making unintended mistakes. How are we going to address that with the option that you mentioned? Do we say it’s a documentation thing, are you saying we should not try to enforce that? How do you weigh those trade-offs?
+
+EAO: The other concern I have with making the .match do input – you mentioned gender selection, which currently does not exist. Let’s suppose somebody writes a gender selector as a custom function, and it works on some data structure, like a Person data structure. Then the problem is that all of a sudden, if you’re formatting that Person, in the body of the message in a placeholder, that person is no longer a Person, it’s a gender thing, because the match expression has had the side effect of making it a gender thing. That, I think, would be very confusing.
+
+MIH: I would have to see the example. (Same example from above)
+Example:
+```
+.match {$foo :number minFractionalDigits=2}
+one {{This is {$foo :number maxFractionalDigits=3}}} // Problem? What happens here?
+* {{This is {$foo}}} // This is ok, we use “$foo as declared”
+```
+…If I understand the argument about the gender thing, if I declare – if you force me to declare an input on a Person… it’s the same thing. Behavior is exactly as if you take the stuff in match and make it an input before that. If that’s a problem, the current proposal which says you might declare an input is the problem. It’s the same thing with different syntax.
+
+EAO: I added to the chat an example of the error-ful situation that I think that approach can lead to, where we have a match with a person and then do a gender match, and then in a placeholder we’re doing a different operation on the input. Not saying you have to have an input, you have to have a declaration. With a match that only affects variables, the reasonable thing would be to have a local you use for the match, then work directly with the person in the placeholder.
+
+```
+.match {$person :x:gender}
+* {{Hello, {$person :x:name}}}
+```
+
+MIH: 
+```
+.input {$person :x:gender}
+.match {$person}
+* {{Hello, {$person :x:name}}}
+```
+Is it okay to do that?
+
+EAO: There you’re also making the person into a gender thing. 
+
+MIH: The one I just put there, isn’t that what’s in the proposal in the document right now?
+
+EAO: It’s not a syntax or a data model error, it’s a logical error that I’m talking about.
+
+MIH: The proposed behavior is just different syntax. Basically .match works like an input. 
+
+EAO: I think I’m hearing agreement, I just want to make sure. I think the answer to your question, Mihai, is yes – the example does match the document. The idea that you can add formatting options in the pattern is up to the person authoring the message. We presume you know what you’re doing. Eemeli said it’s a logical error, but that’s on the user
+
+MIH: The message Eemeli typed right before me, and the one I put below, they are functionally the same. I think the second one is the current proposed document. I don’t understand the argument why the second one is good.
+
+TIM: Actually, the two messages are different. In one case, the gender of a person is bound to the variable `$person` even though that is a strange choice of names for a variable. In the other case, `$person` remains immutable and represents the full person object.
+
+EAO: So the overall error case that I think needs to be addressed is when we have a – when we want to do the selection on one aspect of an input value, and we want to do the formatting on a different aspect of the same input value. Here, the example of a “person” object of some description is the input value. Then we want to make the selection based on the gender of the person. We want to do the formatting on a different aspect thereof. This is, I think, a relatively large proportion of the cases for which the cost of having a separate declaration would show up. It’s quite relevant for us to consider this. This is what I think the syntax should drive the user to do:
+
+```
+.local $g={$p :X:gender}
+.match $g
+* {{Hello, {$p :X:name}}}
+```
+My concern is that if we have a syntax where the .match does an implicit input annotation, then we end up in a situation where it’s not obvious when looking at a message like this… in the placeholder, that person is going to be not a person, but rather the output of the gender annotation, which is a different thing, presumably.
+
+MIH: I agree with you, but I understand that the current proposal is “you should use .input” - isn’t that the same thing?
+
+EAO: You have to use a declaration – the implication here is that you have to use a .local. If it’s in the hidden behavior of the .match, then it’s not at all obvious to the developer that there’s a secret behavior here.
+
+MIH: Is the match equivalent to a hidden local or a hidden input? Right now it’s unclear if it’s anything.
+
+EAO: Actually right now, it’s quite clear that it’s neither of those things. My proposed solution would be for it to not have any annotation, just have it be a variable reference.
+
+MIH: I agree with you that there’s no ambiguity. If I force you to declare something, there’s no ambiguity anymore. I agree there’s more typing. Where I don’t understand your statement is, is “this is relatively rare.” If I force you to do a declaration every time, that’s for every single .match, it’s not rare.
+
+EAO: For numbers that are being selected on and then often used in the formatting, this is exactly what we want developers to do. We want them to declare an input or local and then use it in both of these places. My claim is that this holds for a vast majority of the things developers will want to be matching on. But they will want to be able to use the same value in a placeholder. Yes, there are cases where it’s not so. 
+
+MIH: They’re not rare; only plurals want to show the same thing inside. The select in MessageFormat is not the same at all. It’s like a switch on an enum. I don’t think it’s rare at all.
+
+EAO: Would you happen to have any numbers for this? How often do you need to use a select vs. a plural or selectordinal?
+
+MIH: I don’t have numbers, I searched at some point but I don’t have them now. I don’t think they are rare.
+
+EAO: I think we need to solve the thing for numbers. I think the solution ought to work at least at a decent level for all sorts of things. Therefore, I’m proposing the thing that does less magic rather than more.
+
+MIH: I would tend to disagree that we have to solve it for numbers – we have to look at the whole thing. If we fix it for numbers, we break it for something else, then…
+
+EAO: We’re not breaking it. It’s just that in those cases we require the declaration to be explicit rather than implicit. It also simplifies the syntax by getting rid of the curly braces around the things on the .match line.
+
+ECH: I think this was a good discussion; is this enough? Do we want to take a look at this and decide next week?
+
+EAO: It would be really great to get some of these views and possibly views from people other than those who have been vocal here recorded on the PR itself, so we could advance this. It has been waiting for weeks. It would be great if we could advance this asynchronously. 
+
+MIH: I can get numbers as far as how many plurals/selects/selectordinals we have.
+
+EAO: I will as well.
+
+ECH: So the action is to add comments to the PR?
+
+## Topic: PR Review
+
+Key discussions today should focus on:
+
+- Selection declarations (#824)
+- Function composition (#823, #814, #728, #646, #846)
+- Registry management (#634, #838)
+- Whitespace/bidi handling (#811, #673)
+- Contextual options or expression attributes (#780)
+
+## Topic: Issue review
+
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 64 open (was 62 last time).
+- 18 are Preview-Feedback
+- 0 are resolve-candidate and proposed for close.
+- 1 is Agenda+ and proposed for discussion.
+- 1 is a ballot
+
+## Topic: AOB?
+
+