Create notes-2024-07-08.md

Author: aphillips

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

@@ -0,0 +1,213 @@
+# 8 July 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Eemeli Aro - Mozilla (EAO) - temporary chair
+- Harmit Goswami - Mozilla (HGO) 
+- Richard Gibson - OpenJSF (RGN)
+- Mihai Niță - Google (MIH)
+- Luca Casonato - Deno (LCA)
+- Staś Małolepszy - Google (STA)
+- Toral Cowieson - Unicode (TDC)
+
+Scribe: MIH
+
+## Topic: Info Share
+
+Luca Casonato: “I’ve spent the last few weeks working on some MF2 related projects that I’d like to get the groups’ feedback on. One is a proper website with docs + playground. The other is a very experimental VSCode extension and language server for MF2.”
+
+EAO: Apparently, someone’s working on a go implementation: https://github.com/expect-digital/go-mf2
+
+## Topic: Tech Preview
+
+Let’s review the Task List:
+
+https://github.com/unicode-org/message-format-wg/wiki/Things-That-Need-Doing
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+### 806
+
+EAO: TIM is not present. So unless anyone wants to talk about it we can skip it.
+
+STA: did I understand that he said he will stop working on 806?
+
+EAO: TIM has several documents. I think we (me and him) are getting closer.
+
+### 814 Date - time discussion
+
+
+### 804 Error handling
+
+We reached some agreement 2 weeks ago. Created a PR today.
+
+MIH: I didn’t see if we have an AND or an OR in between these things. This should be made more clear. Addison said an implementation must return an error, fallback, or both. I think Addison is inclined towards OR (as am I) but the PR is still unclear on this issue.
+
+EAO: both are in place, but they don't need to be fulfilled on every format call. Given a message and set of parameters, you must be able to get an error out of it, AND get a fallback string, but there can be two separate methods for this.
+
+MIH: My issue is that I don’t agree with using AND, we shouldn’t make the implementation do both. Rather, it should be one, the other, OR both. There are no methods to do both. It doesn’t have to be my way, but I would like the discussion to capture this more clearly, since I wasn’t clear on what we agreed upon.
+
+EAO: I understand that the consensus was the spec test reflected in the draft PR was that this was not sufficient. A valid implementation should also provide an error so the caller can understand what happened
+
+MIH: This is not my understanding from the PR. Let’s continue this discussion on the PR later
+
+EAO: Agreed, since Addison and Elango are not here either
+
+[...]
+
+MIH: I agree with Luca. The JS implementation is one thing, and we tried to consider all programming languages. In MF2, there will be a fallback, and that’s it. There is either a fallback or it will ‘explode’. We shouldn’t force programming languages and frameworks to handle errors OUR way, rather let them handle errors in their own way. Error handling is useful for tooling, but you don’t want the application to crash if we have a missing variable
+
+LCA: I think that makes a lot of sense to me. A resource-constraint one might not even include code for error reporting. Maybe a compromise would be to say “if an implementation does error reporting, it should be this or that way”.
+
+EAO: one aspect is resource constraint. Part of the discussion was if a boolean is enough.
+
+EAO: will not solve it here.
+Please work on the GitHub issue / PR.
+
+### 815 PR: Drop the machine readable registry
+
+EAO: We’ve been punting on this for a long time.
+We have a text definition for how functions work, what parameters are accepted, etc.
+So we discussed last week if that is enough, and we can drop the registry format.
+That would close a whole slew of issues we have on this topic.
+
+EAO: Any opinion LUC? A LSP might need that information.
+
+LUC: I haven't thought about it too deeply.
+Also for markup, formats, matchers, private annotations.
+We can evolve it over time and independently.
+Can we  use JSON schema? Maybe with some extensions.
+
+MIH: A good example is BCP47, this describes how locale identifiers look like.
+And there is a registry with all the valid tags maintained by IANA (
+You have RFC standard for BCP47, but I don’t think the spec for the registry is part of the BCP47 standard
+
+\[_Editor's note_: In fact, the registry specification is part of BCP47\]
+
+### 803 Date / time format without arguments
+
+MIH: Are you against using medium instead of long? ICU uses something similar to medium, where `DEFAULT = MEDIUM`. It would make sense to be consistent with ICU, and it's definitely better than short.
+
+EAO: would be able to live with medium, as long as we move away from short. 
+
+### 812 Trailing spaces
+
+EAO: Ready to merge?
+
+MIH: I think I approved this one. 
+
+EAO: I’m going to merge this.
+
+### 799
+
+EAO: MIH, I think we were waiting for your opinion here?
+
+MIH: I don’t think this improves anything. It doesn’t hurt, but it doesn’t help
+
+EAO: It removes from the data model something that is purely a syntax consideration for MF2
+
+STA: I don't think we should do this. I don’t think it simplifies anything, and I don’t think it is syntax only.
+Would be good to have some types in our data model, and input and declarations should be some of them.
+Looks like Elango and TIM are also not for it, so I don’t see much push for it.
+
+EAO: I think this is one area where the data model does one thing that it should not do.
+When considering the use of the data model with syntax different from MF2 this is glaring as different.
+We can work on the PR. MIH, would be good if you provide some comment on the PR.
+
+STA: I think you EAO look at this as syntax sugar. I try to model our data model on being too specific rather than too generic. So I would rather have two types, even if one is similar to the other.
+
+EAO: in my experience working with the data model they behave very much the same.
+
+STA: I don’t remember how we got to what we have right now.
+
+EAO: variable expression was needed for the `.input` declaration.
+
+STA: I was in fact thinking to double down on the input declaration vs local declaration.
+
+EAO: this might be one of the last data model PR, unless we get somewhere with expression attributes.
+Let’s continue on the PR.
+I don’t think we have time for discussion on attributes.
+
+EAO: Remaining PRs are about adding things to glossary, registry, no much time to talk about now.
+We can close early.
+
+
+## Topic: AOB?
+
+### Luca Casonato joined for the first time.
+
+Introductions.
+
+LCA: I work at [Deno](https://deno.com/) (JS runtime), but here on my own.
+No i18n experience (other than as a user). Web dev. Find this fascinating. Working with RGN and AOE at TC39.
+The TC wanted proof of real use. So I tried to use this, and found it difficult to use.
+Very little documentation.
+What it is is very technically oriented, for implementers, not for a users.
+Working on a web site / page with better documentation, examples.
+Also working on a Language Server Protocol (LSP)..
+Working on a parser in Rust.
+
+EAO: thank you very much for all the work.
+I would be happy to pass my work on LSP to you.
+
+LCA: I can give a small demo
+https://messageformat.dev/
+Things are from things that I wrote, and TIM, and Ujjwal (USA)
+
+MIH: There is the ICU MessageFormat doc (generic):
+https://unicode-org.github.io/icu/userguide/format_parse/messages/
+
+LCA: Rust parser. Talked with Shane to see if it is an option to include this in ICU4X.
+TBD if that will happen. Might be too slow. Have not discussed that with Shane
+
+LCA: giving a demo of the LSP.
+https://marketplace.visualstudio.com/items?itemName=nicolo-ribaudo.vscode-mf2
+
+LCA: Very much focused on error detection and diagnostic.
+Can also be the base for a linter to be used on localized messages.
+
+LCA: Questions: how to define what functions exist, what arguments they take, what markup is available, annotations, etc.
+
+LCA: also envision this going into the playground.
+
+EAO: syntax highlighting. What is the ruleset?
+
+LCA: TextMate which is used by VSCode, but can be used across editors.
+
+STA: was the syntax highlighting hard to write?
+
+LCA: not very difficult.
+MF2 is very organized, and very self-consistent and no ambiguity.
+Some concerns: some newlines are special in some editors.
+MF2 does not care about multiple line. Either is a regular space.
+Needed different highlighting mode depending on simple / complex messages.
+
+STA: any complaints about curly braces?
+
+LCA: didn’t run into that. VSCode allows you to say “these are matching parentheses” and you can collapse them, or use matching colors.
+
+EAO: we might adopt the messageformat.dev domain “as is”? I doubt we will duplicate this work somewhere else.
+
+EAO: thank you for your contribution.
+
+LCA: “complaints”
+
+- Unclear what placeholders / selectors / markups do, how are they separate. Placeholders / matchers are functions. Markup are only for formatting?
+
+- Annotations everywhere
+
+- Annotations vs attributes: why do we have both?
+For example looking at the use cases, `translate=no`, this probably feels more like markup?
+
+EAO: what you discovered are in fact areas that don’t have 100% consensus, and we are still working to clarify. They are open topics of conversation for us.
+
+EAO: would be nice to open issues in the repo on these topics
+
+STA: very valuable feedback. If you search our discussion you will find many arguments back and forth.
+
+TDC: it was very nice being here during this exchange, with a fresh perspective.
+
+### Toral Cowieson dropped-in
+
+Introductions
+