Create #130-2021-01-11.md

meetings/task-force/#130-2021-01-11.md

@@ -0,0 +1,166 @@
+## Executive summary ([Original Doc](https://docs.google.com/document/d/1P7qhnxUDUpD5AKpcQp_nfIYj2ZBDoXS8YspmN3eV3f8/edit#))
+Executive summary
+
+Participants:
+RCA: Romulo Cintra
+NIC: Nicolas Bouvrette - Expedia
+EAO: Eemeli Aro - OpenJSF
+DLM: Daniel Minor - Mozilla
+STA: Staś Małolepszy - Google
+ZBI: Zibi Braniecki - Mozilla
+DAF: David Filip - Huawei, OASIS XLIFF TC
+ECH: Elango Cheran - Google
+GWR: George Rhoten - Apple
+MIH: Mihai Nita
+
+
+There is a general consensus around supporting dynamic references. There are some valid use cases to support, we probably can't prevent people from working around dynamic references, and by supporting them we “gain back” some control (conformance levels, lint, etc.). This can simplify messages that could otherwise have thousands of related static messages, but it brings along the risk of extra complexity and indirection. There are concerns about testing & validation -- ex: what happens at word boundaries, agreement between selector name, context completeness checking. Conformance levels with regards to this feature depend on the capability to switch off dynamic- and static message referencing. 
+
+We agree to pause meetings of this particular task force for issue #130 until we have progress on the data model that requires clarifying these details.
+
+
+
+Approval Stamps for Executive Summary
+ECH
+RCA
+STA
+MIH
+DAF
+NIC
+
+
+Minutes
+
+ZBI: Summary of dynamic selectors. Previously, we wanted to provide a design for developers to communicate to translators. Challenges at Mozilla happen at build time, developers don't know what messages they want to reference from another -- it is a runtime decision. Workarounds are messy, proposal is dynamic references -- have references to another message within a message that are only resolved at runtime. Avoids previous errors from workarounds of string concatenation and different fallback (locale?) of 2 different message patterns.
+
+EAO: My summary is that we are about to reach a consensus about using top-level selectors, and regardless of what we decide regarding dynamic references, the top-level selectors enable a way (albeit ugly) of enabling dynamic references. A decision here on dynamic references might influence the top-level selectors design.
+
+ZBI: I encourage everyone to explore how lack of dynamic references affect runtime bindings (ex: Qt bindings). But otherwise, this is a good summary.
+
+NIC: Can I ask about the example provided in #130, it seems like you could have explicit messages that would solve the problem.
+
+ZBI: Look at the case where you reference 4 monsters and 5 devices, then you get a combinatorial expansion of 20 combinations. Developers try to create ugly workarounds.
+
+Is there anyone opposing the proposal?
+
+STA: I don't want to sounds opposing, but I want to raise some red flags, and raise the idea of the registry. With message references, we have the API that is effectively created by the message, which includes the name of the selector. If you provide the wrong selector name, the message will break, as has happened in Fluent, and you could use static analysis somehow to catch them. But you could also create a registry of defined names and values for selectors, and the developers can override the registry to customize that to their specific needs. I hope we can talk about this because not having a registry creates a dangerous solution.
+
+ZBI: Every solution has its soft spots, so any solution should address this problem, and I hope 
+
+DAF: The dynamic references create the same problem as internal selectors for translators (localization), but they address the same problem. The difference is the time at which they are resolved (compile/build time, runtime). But I don't think the standard should define when these references are resolved. I do like the conversation about checking, validation, etc. I think these problems can be avoided by not using message references, but I think we are moving in the right direction.
+
+STA: I wonder how we can prevent the use of message references. Maybe the child (referenced) messages are written in some special syntax or data model so that they are easier to check and verify.
+
+RCA: Are suggesting something like we have in CSS, like mixins, which have a certain syntax?
+
+STA: I'm not sure mixins are the right analogy. Maybe plural rules are an example, where you have a certain standard set of keywords to use. I think it is worth exploring how references to "terms" (referenced/child messages) are created so that there is a limited way to construct them, and they would live in the app-specific registry, not the global/shared one (ex: CLDR-like).
+
+EAO: I think that would add an unnecessary level of complexity to the data model without providing any real benefit to actual use cases. And it would impact actual use cases. It limits the scope of what can be included into a message. I think it would cause some of the workarounds that we're trying to solve.
+
+STA: That's why I would like to experiment with it. Limiting in a smart way, like you said, might be beneficial. We could have controls on what terms can be edited or not, by whom.
+
+EAO: I think there are solutions that provide the functionality that we want without restricting what messages are allowed to be referenced by other messages.
+
+STA: Another question, if there is a message that is really long, if we should recommend to developers that they split the message into sub-messages that are contained within a container message.
+
+EAO: I think the complexity of the message is discovered not by translators but by developers writing the message. The complexity is not a function of the length of the message.
+
+RCA: As a standard, we should provide guidance for both developers and translators. Do you agree?
+
+EAO: I think so, they are clearly very different people.
+
+RCA: What I mean is that I don't want to overstep into areas that standards shouldn't by doing so.
+
+STA: I could be recommendations or guidelines, and we are in a good position because we are thinking a lot about how things should work.
+
+RCA: I am thinking about this because we are talking about linting rules, which could come from the guidelines.
+
+ZBI: The way I see it is that, if we have a concern of the flexibility that we are providing can be abused (low quality translation or user experience), our guidelines should maximize the chance that they are testable. I think this is what DAF is recommending us to focus on. I think we should invest in tooling to help us.
+
+DAF: I want to agree here, we need to construct examples that show the problem. The example currently in #130 is actually a bad example, it uses a verb, and verbs often need to be parameterized and localized separately. I support the general idea of flexibility, but we should have best practices that are testable.
+
+NIC: I agree with DAF. There is a huge implication with supporting references correctly - does this require the right tooling, how does it affect translation memory?
+
+ZBI: Is this example here a better example? https://github.com/projectfluent/fluent/issues/80 
+
+NIC: It brings up the question of what is the limit on the number of static strings before you resort to message references.
+
+EAO: This sounds like a linter rule that should be configurable but have a default. Different projects will have different thresholds.
+
+STA: I have a general comment on how I would like messages to reference nouns as opposed to verbs. Even if there are a thousand permutations, and you need to know all the possible permutations, it's not as open-ended as if you have dynamic references where you don't know what to expect. I strongly recommend only using nouns as message references, but I don't know how to enforce that.
+
+RCA: I agree with STA, it is an interesting point-of-view. I don't know how we scope the variables. EAO mentioned something interesting, what happens when a variable changes in an uncontrolled way, what happens to the inheritance of messages using the variable?
+
+EAO: It shouldn't be that hard to write tooling that does checking to verify whether messages and references are broken.
+
+RCA: True, but this is adding some complexity, and it 
+
+NIC: I'm also worried about tooling because existing tooling around current MessageFormat is so bad that I do not want to give it to linguists and translators.
+
+ZBI: I think since the beginning of this group, we've been dancing around worrying about avoiding mistakes of the past. Instead, we can think ahead to writing good tooling and creating a good community around it, for example cargo clippy for Rust has its own dedicated community for implementing linting rules. What we are talking about with linters should be a system that can be easily turned off if users don't want them.
+
+STA: That gets back to what NIC was saying, and maybe we should have tiers of support. GWR, can you remind us of how Siri supports dynamic references?
+
+GWR: There would be a separate file shared across all messages for referenced messages/child messages/terms. If a message is too complex to be written that way, you can have selectors that allow for edge cases, in addition to things like the usual singular / plural split. That allows you create a "phrase" that gets used within in other messages. Then we allow a family of messages, which is like a namespace, but that is discouraged because it does not support the context of the message it is used within, ex: it allows for sentence fragments that are hard to include.
+
+If a language is pretty regular, definite vs indefinite, singular vs plural, then you don't have to encode each of the specific combinations.
+
+NIC: Is that similar to a lexicon?
+
+GWR: It's like a highly structured lexicon. For example, in the Fluent#80 example with bone-dragon, you have to describe what it looks like as singular vs plural, if it's definite or indefinite article.
+
+DAF: The capabilities that GWR describe should be features that describe the context. We should make the context capable of completeness tests. I see this as a local instance of the registry at various levels. 
+
+To STA, who mentioned limiting references to just nouns, it is hard to tell what parts of speech are sometimes ("stop the steal" - is "steal" a noun or a verb?). I think the standard should be limited at the standard level, it should only be limited at the linter level.
+
+That is similar to what ZBI and EAO about supporting checking in the linter.
+
+ZBI: I was a little bit confused by your last sentence. It seems like linting is not going to be limited by the data model. The linting that we will need to work with will need to support dynamic & non-dynamic references.
+
+DAF: I think we misunderstand each other. A level 0 data model would not have references, so a linter that doesn't support message references would use that corresponding data model. I don't think the standard can enforce checks of specific lifecycle stage (static-time vs compile-time) of message reference resolution.
+
+EAO: Yes, it is possible to differentiate between dynamic and non-dynamic references, so long as we design a data model that support it. I have a proposed data model in issue #130.
+
+DAF: Okay, so then we can have a switch to select between them in the linter.
+
+EAO: That's a separate detailed implementation discussion, I don't want to sidetrack from dynamic references. If there is a linter check to validate references, then we should have a notion of dynamic references, which then requires us to update the data model to support representing that information.
+
+DAF: I think the standard describes all 3 levels, but then there could be a conformance statement (from a checker), but the levels could be described in the standard.
+
+RCA: I don't understand what the levels mean about what kind of support we provide or not, but I don't see how the linter 
+
+DAF: There could be a combination of features that go together that cannot be easily checked independently by a linter.
+
+EAO: What I think I am understanding from DAF is that he is looking for ways for people to start supporting MF 2.0 without requiring them to support all of it. I like that idea, even though it is a different discussion than dynamic references.
+
+RCA: What are the takeaways from this meeting.
+
+STA: This is interesting, the more complex the data model gets, the more ways to break it there will be, so there will be more work needed to be put in to the linter to help people use it in the best ways.
+
+RCA: How do we go about working on a linter.  We can start working on this now, starting from 0; or we can have this in mind as we continue designing the data model; or do we want to clarify using more examples about what is needed?
+
+EAO: I think it is too early to start defining levels of the data model.
+
+DAF: I agree. But from the point of view of this problem of messages references, we could say the levels are: no message references, message-level references, and message-level + dynamic references.
+
+STA: Does it matter to distinguish between dynamic and message-level references?
+
+DAF: EAO said that his data model can differentiate them, and I take him at his word. If we have a data model that can support it, then why not support it?
+
+STA: Maybe a next step that I can take is to document those concerns that apply to both message-level references and dynamic references.
+
+RCA: Should we keep this task force running to discuss dynamic references, or can we do this offline until we have more to discuss.
+
+DAF: I think we are in agreement here, and I vote to putting this to sleep until we get there. I think we can resume once we have more clarity on the data model.
+
+RCA: That was what I was trying to say.
+
+DAF: Let's make a summary for the plenary.
+
+STA: What I take away from this meeting is that there is not a big difference between implementing regular references, and go ahead and work on the data model.
+
+ZBI: One difference we encountered with dynamic references is that without them, there were people trying to resolve regular references at build time, but dynamic references can be used in such compile/build-time systems. It's important to at least discuss early on to avoid those friction points. Either DAF and EAO mentioned it in chat, that List Formatting can affect the type of arguments that you pass in. But we can discuss that when we discuss the details of that after deciding whether and how to distinguish dynamic references.
+
+
+
+