Create notes-2020-11-16.md

Meeting  notes : https://docs.google.com/document/d/1dOp0e9_qWYgVNEwfQ2LRSm9Qty-ChSmdQmwW2ljSYcI/edit

Close #129

Author: romulocintra

meetings/2020/notes-2020-11-16.md

@@ -0,0 +1,202 @@
+#### November 16th Meeting Attendees:
+- Romulo Cintra - CaixaBank (RCA)
+- Nicolas Bouvrette - Expedia (NIC)
+- Staś Małolepszy - Google (STA)
+- Nicolas Bouvrette - Expedia (NIC)
+- Mihai Nita (MIH)
+- Elango Cheran - Google (ECH)
+- Luke Swartz - Google (LHS)
+- Richard Gibson - OpenJSF (RGN)
+- David Filip - ADAPT Centre @ Trinity College Dublin (DAF)
+- Colin Sprague - DocuSign (CLS)
+- Eemeli Aro - OpenJSF (EAO)
+- George Rhoten - Apple (GWR)
+- Standa Rygal - Expedia (STR)
+- Zibi Braniecki - Mozilla (ZBI)
+
+## MessageFormat Working Group Contacts: 
+
+- [Mailing list](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg)
+
+
+## Next Meeting
+
+December 14, 10am PDT (6pm GMT)
+
+## Agenda
+- [ Agenda on Github ](https://github.com/unicode-org/message-format-wg/issues/129)
+
+Easy way to volunteer to participate in Chair Group :  [Link](https://github.com/unicode-org/message-format-wg/pull/70)
+
+We should go ahead and get started
+ 
+### Moderator : Romulo Cintra
+ 
+### Chair Group Announcements
+ 
+STA: Current proposal is to use Github "labels" to describe the broad type / topic of the issue. Ex: organization, documentation, requirements.  Github "milestones" feature to be used to track work that is due, so we will use for the work to be done by the next monthly meeting. If work gets pushed from one milestone to the next, then it is an indication that something needs to be adjusted (blockers, task scope).  Lastly, Github offers "project boards". Let's experiment and use them in any way we see fit.  Task forces seem like a good fit, but even other uses and short-term (1-2 weeks) uses of project boards would be good, too.
+
+RCA: This is about organization, so let's see how it goes.
+
+STA: The Chair Group wanted to keep things simple for now.
+
+RCA: New feature in TCQ called "check temperature".
+
+### Present Message References and "Context Data" for Message References
+
+[Slides](https://docs.google.com/presentation/d/19fxGJuFcGRwQiWYlppsOmNhyK8wxG6ZeMtrHeAmf8vI)
+
+STA: I tried to extract the takeaways from the 3 meetings of the task force (for issue #103) that we discussed. I took the liberty of coming up with examples that we didn't discuss. If the examples are not representative, let me know as it comes up.  The choice is between "in-message" (aka "internal") selectors as we currently have in ICU MessageFormat, and "top-level" (aka "message-level") selectors.  As we focused, there were 3 main themes: compatibility, expressive power, and friendliness towards different actors.  Compatibility - there are a lot of tools that may not be willing to adapt to a new way of doing things. Expressive power - questions of verbosity and ability to round-trip.  Friendliness - the most subjective, and how amenable it is to translators and whether they can understand what happens at the boundaries of nested messages with internal selectors.  
+
+Compatibility - verbosity - shows Slide 4 (nested messages / internal selectors) and Slide 5 (expanded message group using message-level selectors). Chair Group found the message-level selector form to be more expressive, for lack of a better word, and it would work well for existing tools, and from my personal experience, well for translators, too.  The examples in Slide 2 are too small to reveal as much difference as the examples in Slide 4 vs Slide 5 in this regard.  
+
+The concern about verbosity comes up for a message with multiple internal selectors with multiple options.  Slide 6 has an example.
+
+Mini-consensus - see Slide 7.  We can allow message message references. We can allow each of the internal messages to be a separate top-level message whose translations are included by id in the original message. The major argument for having this feature is because that developers work around the lack of this feature anyways. They do have shortcomings - it creates dependencies and the possibility of cyclic dependencies, it requires including context of other message translations, etc.  It also requires some coordination between the "parent message" and "child message".  The child message needs to be able to receive the context of the parent message.  In Slide 10, we see an example. We have to consider that the child message can use a runtime variable that depends on any parent messages. The parent message has to pass values for all variables that the child message needs. So there is still complexity here, we have just moved it around.
+
+This leads to the other mini-consensus (slide 12) which is to pass parameters to the messages that are referenced.  Slide 13 has example.  The parameter/variable name must match, and we need a way to validate the values passed. This effectively creates a public API.  In the example, we have an enumerated type, and we might want to ensure that the supplied value exists in the supported value set in the child message.  Maybe the child message can report back on any exceptions.
+
+When it comes to validation, there could be different places where the valid values can be defined, perhaps in a layer-like way.  There could be a MFWG described standard, there could be a public open-source maintained standard, and there could be a developer/org-specific set of defined values.
+
+MIH: To address whether we have explicitly defined parameters or not, in the case of the example on Slide 10, the count=$restaurantCount can be any value.  But when it comes to grammatical case, we should be explicit because there is a known finite set of grammatical cases.
+
+NIC: Looking at the example in Slide 10, maybe the syntax is more verbose than internal selectors for nested messages.  Maybe we can reduce this?  The example in Slide 11 has a lot more parameters.
+
+EAO: Before we get to the discussion that we are currently in, we should first discuss whether we want to proceed with the consensii (the 2 consensuses) from the chair group.
+
+MIH: There is no localizable text in the placeholder, and I can think of ways for existing l10n tools to support this. I would say that there is less friction in this style than the current standard.
+
+DAF: We keep sinking into the detailed discussion, and what EAO said before is a good point of order. We should decide on the consensi first before going into details.
+
+RCA: Using my moderator's prerogative, I think the main goal of today's meeting is to discuss the consensus and come to a conclusion about that.
+
+DAF: I agree with MIH about using registries as a solution for enumerated values with a known finite set of values (ex: grammatical case). As STA mentioned, there’d be three levels (standard, registry, and user customization)
+
+LHS: Are we discussing a syntax or a data model? I agree with NIC that the example uses slightly more verbose syntax, but syntax is a separate problem from the data model problem.
+
+STR: I want to be clear on what the working group agrees on.  Does this mean that internal selectors would be removed from the standard?
+
+EAO: We did not reach a consensus on that topic, but it would be an obvious next step to decide.
+
+STA: This segues well with the topic that ZIB wanted to talk about as the next top-level meeting agenda item.
+
+ECH: I just want to point out again that there is a difference in verbosity vs. easy vs. simplicity.  The question of verbose or concise is not the same easy / difficult, and that is not an indication of simplicity. In fact, making things simple is all about taking apart separate things that do not belong together, and so when you take things apart, you create more things. Having more things to deal with might look more verbose or not convenient, but it may still be simpler.  In our case, we have nested messages with internal selectors where their translations depend on each other and the context of the top-level message, and rewriting using message-level selectors through an Cartesian product expansion, creates more patterns, but that verbosity is actually simplicity in action. Just a reminder so that we don't confuse verbosity and difficulty with complexity.
+
+ZIB: I'm a little concerned about moving forward with voting on consensii without discussing the issue of dynamic references.  In slide 8, imagine instead of `term-pool`, you would pass the name of a referenced message as an argument. For the message `description`, you call it by specifying `$feature1` is set to `"term-pool"`. Dynamic references are similar to concatenation of translated nested message, in that if you don't allow it, people will still find a way to do it.
+
+STA: Is any of this blocking the current proposal to vote on consensii.
+
+ZIB: Is there any reason to reject this idea upfront?  If not, is there an argument, are there any arguments against this idea, or is it compatible with what we are proposing? I was just concerned at the pace of proposals.
+
+LHS: Would you pass arguments along with these message id name values for dynamic message references?
+
+ZIB: I can discuss separately from this meeting. We have some use of this in Fluent, and I just want to make sure that we consider that upfront.
+
+STA: In my mind, dynamic references can be made possible by what we're discussing in this meeting. Obviously, more research is needed. But first, we need message references, before we can discuss dynamic message references.
+
+ZIB: If the group thinks that this is a cascading / layered-on feature on top of and separate to what we're talking about, then I'm okay with that. But if we're talking about registries and static typing, then we should also consider this feature, too.
+
+RCA: Let's decide what our next steps are. I think we can decide on the consensii so that we can move forward.
+
+ZIB: Can we check the temperature on the dynamic message references?
+
+EAO: Separate problem.
+
+GRH: Separate problem, but highly relevant.
+
+MIH: I don't see this as a blocker, but rather, a specialization of passing parameters for message references.
+
+EAO: Some of the examples could be resolved by using top-level selectors, which means that the problems can be resolved and still maintain the benefits of static checking, etc.  As for a next step for dynamic message references, take a list of examples that we've looked at and come up with examples that illustrate when the dynamic references are strictly necessary.
+
+GRH: We've tried to ban dynamic references from our codebase more than once, but developers still bring it back. We should keep a space open for discussing it.  Translators complain that it becomes a black box that causes problems. So it's a tough problem. 
+
+MIH: I agree with GRH. And that it's orthogonal to the current topic.
+
+DAF: I agree with GRH and MIH that blackboxes are going against empowering the translator, 
+Dynamic references seem orthogonal to the topic and not blocked if we approve the two task force consensi. Going forward there should probably be an option, either translator passes parameters to the API or the black box becomes gray and tells the translator what it is (for instance what is it’s intended case etc.)
+
+RCA: Should we start voting on the 2 consensi proposed from the Chair Group?  And that the points brought up can be discussed separately later?
+
+The first item: should we include message references in the data model?  Does anyone disagree?
+
+After waiting, it looks like there is no opposition, so there is consensus on that part.
+
+The second item: should we pass parameters to the message being referenced and validate them?  Does anyone disagree?
+
+After waiting, it looks like there is no opposition, so there is consensus there too.
+
+RCA: Let's move to the next topic, although we only have 20 minutes left. We can see how much progress we can make. STA, I see that you have comments on message glossaries.
+
+STA: How do I share the doc?  Should I share using the working group email list?
+
+RCA: Just drop the link here for now.
+You will need to request access:
+https://docs.google.com/presentation/d/19fxGJuFcGRwQiWYlppsOmNhyK8wxG6ZeMtrHeAmf8vI
+
+### Present on whether we need internal selectors given message-level selectors and message references
+
+MIH: The main concern was whether the lack of inclusion of internal selectors in the standard (data model) now would cause problems with supporting internal selectors in the future. ZIB was the main advocate for this concern, and after talking with ZIB, for which the notes are summarized well in [issue 127](https://github.com/unicode-org/message-format-wg/issues/127), we can have a group of people who are keeping watch for changes that might cause problems for this functionality.
+
+ZIB: That sounds like a good summary so far.
+
+MIH: The next topic is whether we should have a separate sub-group for doing this or not.
+
+RCA: As a group, do you think we need to create a subgroup for this kind of task, or is there a different kind of model for observing or watching whether there is an anti-pattern introduced.
+
+EAO: I think we are ready to resolve this issue and say that message-level selectors mean that we do not need internal selectors and move on, without needing a group to further decide.
+
+DAF: I agree with EAO, and I don't think we need to create extra structure. People should feel free to take it upon themselves to raise concerns as they come up.
+
+STA: If we end up with a situation where, in a year from now, we decide that we need 
+
+ZIB: I don't agree with EAO that we're ready. Let's not assume that we've properly explored it, investigated it, and explained it.  I spent a lot of time with MIH discussing it, but using arguments that were explicitly rejected in the proposal with careful consideration and explanation. So I would ask for more diligence from others in responding. To STA, the situation where having 2 competing proposals would be bad, but we haven't even decided whether in such a scenario, they would even be solving the same problem. I would ultimately listen to the group, but I think these claims seem confident.
+
+DAF: In the issue #127, I didn't see any use cases that would be addressed with internal selectors. Responses under #127 show that the listed use cases would be solved with message-level selectors with message referencing.  I think top-level only selectors guarantee translatability, but allowing internal selectors doesn't. If the group doesn't have any special rights, then I am okay with an informal group, but I also think we're ready to decide on whether to allow internal selectors. I am opposed to forming a formal group.
+
+RCA: It's been a year since the start of MFWG, so happy birthday to the group. In our group, we want to continue ensuring that all voices are counted.  ZIB, it seems that not everyone has had a chance to evaluate the proposal, based on the few comments left on the GH issue 127, so maybe this means we can still bring this up for consideration in a future meeting.
+
+EAO: I can't claim to have 20 years of i18n experience, but I have 7 or 8 years of experience, but I feel fairly certain that anything that can be done with internal selectors can be represented using message level selectors.
+
+STR: The claim that messages with internal selectors are not translatable does not match with my experience. It took time to train up the translators, but after time, the messages were easy to translate, so it is possible. The message-level reference approach seem more problematic for translatability, since it brings up the concerns of concatenation in the messages, for example, in the Translation Memories.
+
+RCA: If there are use cases not yet represented, we should add it to issue 119.
+
+MIH: My 2 cents, yes some of us do have 20 years of experience, or at least I do, but I can still be proven wrong. So I think there is value in having watchdogs to point out where we can be wrong. And specifically, I talked with ZIB to understand and address the concerns better.
+
+DAF: My point is not that internal selectors cannot be translated in general, but that a solution with internal selection cannot *guarantee* translatability. It routinely creates situations where translators cannot form a grammatical sentence for all possible cases.
+
+MIH: Regarding the idea of unwittingly setting ourselves up for teh need for a MF v3 by unintended consequences of our decisions, the point of this watchdog group is to prevent such a situation, so that any changes might only need a (backwards-compatibility, non-breaking) change in a version "2.1".
+
+STA: In this discussion of a hypothetical 3.0, maybe we can be strategic about what features we want to support now versus later. And if there are features that are so good that we need 3.0 but are breaking, then we can discuss them for a later context, maybe if it's even 10 years from now.
+
+NIC: Well, what about 2.1, and 2.2, etc.?
+
+RCA: Yes, we need to decide on 2.0 first. This sounds like a topic for deciding a roadmap.
+
+EAO: For a discussion of 3.0, we have to consider that JS.Intl will support 2.0, and if there is a breaking change, that will cause problems due to JS.Intl's necessity to always be backwards compatible.
+
+MIH: Yes, and this is a big concern that came up when I talked with ZIB.
+
+DAF: This is similar to how we designed other specs to have a stable core and allow uncertain features to live in modules that can be deprecated if necessary.
+
+EAO: I would prefer MF v2 to be opinionated rather than trying to deal with the model of a lean core with modules.
+
+MIH: What about the idea of registries for defining valid values, is that ok in teh JavaScript world?
+
+EAO: We already do that with CLDR, but I'm talking about the idea of including features in the spec or not.
+
+STA: I think your idea of gathering use cases is good.
+
+EAO: I think it would help a lot to specify the cases in order to better explain what is or isn't possible.
+
+STA: I was thinking about the example at the top of issue #103, written both with nested messages + internal selectors, and with message-level selectors.  I think that as a principle, we should adopt the message-level selector approach first. I am okay with the level of verbosity that it creates.  But then I notice if you translate this in my native Polish, the verb "liked" must decline/conjugate based on the noun subject "friends". So you cannot just have a message reference to a separate message for "friends" that is completely independent of the rest of the parent message -- the parent message needs to know about return value of the child message.
+
+EAO: I don't know if you realize it, but our consensus is about the data model, and that therefore does not prevent writing it in a syntax that uses internal selectors.
+
+DAF: I don't think that deciding the syntax should be a part of the group, and frankly, I don't mind whichever syntax that someone uses, and that syntax can use internal selectors if they want to.
+
+MIH: This is why I have been a proponent of a data model. Syntaxes vary, JS has one type that uses its native data literals, there is ICU MessageFormat, and there is Fluent, but you can always read one syntax in and write out another syntax if you need to, so long as they all adhere to the same data model.
+
+EAO: Would there be any need to create tooling to convert from other syntaxes (like getText, etc) to the MF v2.  Is there any prior art of such a converter having been created?
+
+MIH: I think XLIFF could serve as the common representation interchange format. That is what we do in the l10n world.