Create notes-2024-07-29.md

Author: aphillips

meetings/2024/notes-2024-07-29.md

@@ -0,0 +1,152 @@
+# 29 July 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Luca Casonato - Deno (LCA)
+- Mihai Niță - Google (MIH)
+- Eemeli Aro - Mozilla (EAO)
+- Tim Chevalier - Igalia (TIM)
+- Elango Cheran - Google (ECH)
+- Matt Radbourne - Bloomberg (MRR)
+- Richard Gibson - OpenJSF (RGN)
+
+
+Scribe: ECH
+
+## Topic: Info Share
+
+## Participation
+
+Discussion of “delegates.md” and a reminder of how participation works.
+
+APP: The document is stale. A lot of people mentioned are not active members, and current active members are not reflected. So I want to move that information elsewhere and get rid of the document. After referring with the legal department, people whose employers are not Unicode members need to be invited as invited experts. So I am inviting you LCA, and thank you for signing the Unicode CLA. I will update documents accordingly.
+
+## 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: F2F Survey and planning (#835)
+
+https://github.com/unicode-org/message-format-wg/issues/835
+
+APP: Thanks for participating in the survey. No one said that tey didn’t want a F2F. A couple of people suggested that the F2F should happen in the Ba Area.
+
+EAO: If we end up in the Bay Area, I should be able to attend if it is close in time to the Unicode Technical Workshop.
+
+APP: The UTW is Oct 22-23. I am nervous about CLDR’s release date is remarkably close to that. At that point, we should be stabilizing the spec release. Do we want to wait that long?
+
+EAO: W
+
+APP: Are people interested in a virtual F2F? We had that earlier in the year. It would happen presumably in September, not too late in September. Maybe the week of Sept 16? That is the week prior to TPAC.
+
+EAO: That wouldn’t work for me.
+
+ECH: Virtual works for me, as well as meeting in the Bay Area any time.
+
+APP: I’ll put a plan together for a virtual event for multiple days on the week of Sept 9.
+
+## Topic: Leading whitespace on complex patterns (#809)
+
+https://github.com/unicode-org/message-format-wg/issues/809
+
+APP: I think this is related to Bidi.
+
+LCA: I ran into this when implementing a Rust parser for MF. I ran into the problem when embedding a multiline pattern in a test, and it took me a long time to realize that it was because there was whitespace before the pattern. EAO also had this problem. This suggests that the problem may be experienced by others in the future.
+
+The proposed solution is to allow whitespace at the beginning, and if the whitespace is followed by anything except a dot or a curly brace is interpreted as meaningful. Otherwise, the whitespace gets trimmed. This does require an unbounded look ahead.
+
+MIH: I’m split about this. Trimming spaces is something that we hammered to death. The problem is not about parser complexity. it’s about the rules that we tell translators. We tell them that you add spaces and they are significant, and now we want to say sometimes that is not the case. Also, I’m a bit tired of reopening issues to discuss again and again when we have other issues that still need to address.
+
+APP: I hear that, but we are hearing this problem from multiple people. I think there is space to address this problem.
+
+LCA: I want to reiterate that this isn’t address the limitations of any one particular file format. My other concern with this is that I’m writing a parser that aims to take any collection of Unicode code points and report a MF AST for this and report diagnostics. It needs to report diagnostics, even 
+
+
+ECH: also look at #505. We turned over the syntax. It’s important to talk about why we came to these decisions. Making this change would contradict that. WYSIWYG is simple messages. We’re allergic to delimiters around simple messages but that would take away a lot of this concern - there’s no more ambiguity. We said no because WYSIWYG, especially for translators. Translators don’t want {{}} around every message. I called out the inconsistency before but that’s not what we decided to go with. Are we now saying simple messages are not WYSIWYG? Yeah, maybe you’re noticing an inconsistency. It’ll be inconsistent no matter how you slice.
+
+> Luca: does https://github.com/unicode-org/message-format-wg/issues/507#issuecomment-1787685799 capture your observation?
+
+
+
+RGN: Thanks ECH for finding those old issues and balloting. #505 and #507 are exactly what I was thinking of. At the risk of reopening things and saying “I told you so”, it really suggests what I was saying that simple messages ought to be nothing more than degenerate complex messages which lack declarations. It does still feel high
+
+
+
+ECH: Feel like we discussed this before. This complicates the rules we have to tell people. Maybe makes some things ealy relevant to me.
+
+I am asking Luca if this is relevant? https://github.com/unicode-org/message-format-wg/issues/507#issuecomment-1787685799
+
+LCA: The red part of that comment is no longer relevant.  The phrase “log me out” is not relevant because it is not quoted.
+
+MIH: If it is inconvenient for certain developers but not others, then I am not sympathetic. If we make it difficult for 1 developer but make it easier for the 50 translators translating into 50 languages, then I am fine with that. If we say that it is important because of Bidi concerns, then I’m okay with the argument. I am not just opposing the argument.
+
+LCA: I’m in favor of simple messages being written in a WYSIWYG manner. 
+
+APP: We provide a workaround for when messages start with a dot by quoting a pattern using double curly braces. I think the important takeaway is that plain strings are valid messages. We have a problem that whitespace preceding a complex message turning into a string. Then if your simple message contains a dot after the initial whitespace, then you have to quote. That seems rare enough to be okay with.
+
+EAO: 
+
+ECH: I do oppose this issue, but not because I’m opposed this in isolation. I’m also not 100% happy with what we have because my view on the whole design is very close to RGN. I think simple messages should be thought of as the same as complex messages. We’re asking ourselves to show burden of proof that we’re not okay with a small complication of the rules, but this is exactly the kind of thing we already considered these topics in the recent past.
+
+MIH: Do we not need something like this for Bidi anyways? Are we arguing about this too much in isolation?
+
+APP: The point that MIH brought up about Bidi is good. The design there is getting complex, which makes me nervous. A couple of options are that we treat Bidi characters like whitespace in the sense that you can add them before the message and ignore them. Or we can completely disregard whitespace and Bidi characters altogether.
+
+MIH: My point about Bidi characters is not about translators because translators for Bidi languages are used to inserting Bidi characters into their 
+
+MIH: I want to summarize my position. We had a discussion about this for weeks, we voted, made a decision. Now we are reopening the issue and discussing it. We keep reopening issues.
+
+TIM: Do Bidi control characters have to be in the whitespace category, or can they be in a different category.
+
+APP: They are different. They don’t have to be considered whitespace.
+
+APP: We have a couple of options. The first is status quo: a message is a simple message unless it starts with a dot and a keyword. The second is that we allow a complex message to start with whitespace that gets trimmed, but it requires simple messages that begin with whitespace followed by a dot to be quoted.
+
+LCA: There is a third option, which is to reject simple messages that start with whitespace followed by a dot.
+
+MIH: I strongly disagree with this option because we make things more difficult for translators by disallowing certain simple messages, and we don’t make the lives of developers better as a result. So we make things worse without any benefit in return.
+
+APP: I will make a ballot with two options, then.
+
+
+## Topic: Contextual Options vs. Expression Attributes (#780)
+https://github.com/unicode-org/message-format-wg/blob/main/exploration/expression-attributes.md
+
+(notes missing; group resolved to accept the proposed design)
+
+ACTION: EAO to file PR for expression attributes; EAO to file PR for contextual options
+
+## Topic: Selection-declaration (#824)
+
+For next time.
+
+Key discussions today should focus on:
+
+Selection declarations (#824)
+Function composition (#823, #814, #728, #646)
+Registry management (#634, #838)
+Whitespace/bidi handling (#811, #673)
+Contextual options or expression attributes (#780)
+
+
+
+## Topic: Issue review
+Let’s close all of the issues
+https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue+is%3Aopen+label%3ALDML45
+
+https://github.com/unicode-org/message-format-wg/issues
+Currently we have 62 open (was 61 last time).
+18 are Preview-Feedback
+2 are resolve-candidate and proposed for close.
+1 are Agenda+ and proposed for discussion.
+0 are ballots
+1 is a survey
+
+
+## Topic: AOB?
+
+