Create notes-2024-07-15.md

Author: aphillips

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

@@ -0,0 +1,150 @@
+# 15 July 2024 | MessageFormat Working Group Teleconference
+
+### Attendees
+- Addison Phillips - Unicode (APP) - chair
+- Eemeli Aro - Mozilla (EAO)
+- Mihai Niță - Google (MIH)
+- Luca Casonato - Deno (LCA)
+- Harmit Goswami - Mozilla (HGO)
+- Ujjwal Sharma - Igalia (USA)
+- Richard Gibson - OpenJSF (RGN)
+
+Scribe: LCA, USA
+
+## Topic: Info Share
+
+Nothing
+
+## Topic: Tech Preview
+
+Let’s review the Task List:
+
+https://github.com/unicode-org/message-format-wg/wiki/Things-That-Need-Doing
+
+APP: Added “A specification for a one-to-one mapping between the data model and XLIFF” from our goals doc.
+
+## Topic: PR Review
+Timeboxed review of items ready for merge.
+
+Late breaking PRs: #823 through #828
+
+
+
+APP: asked for review on #826
+
+Timebox these first:
+### Dropping machine-readable function registry #815
+
+APP: I have reviewed this, don’t see other reviews, would someone like to review this or should we collectively agree to merge it?
+
+Agreed to merge, with thumbs up from MIH and LCA
+
+### Default formats for :date, :time, and :datetime functions #813
+
+APP: when I wrote this part of the spec for LDML#45, I used defaults from MDN and it turns out the defaults for DateTimeFormat is not one of the named long, medium, short etc.
+
+APP: what if the default is based on implementation?
+
+EAO: not in favor of default on implementation - would lead to weird things
+
+MIH: both in ICU and JDK the default is medium
+
+APP: does CLDR have a default?
+
+MIH: does not think so
+
+APP: it’s probably for historical reasons, also I’m not personally a huge fan of the enumerated keywords because they’re kind of historical and they’re not consistent across locales so I prefer for people to use skeletons or option bags so we could switch to either options bags or skeletons if we choose to add them later
+
+APP: right now with medium, you sometimes get a shortened month, sometimes you don’t. This is not so great
+
+MIH: Two things: I did something at some point to see if we can create the enums from skeletons, which are the same as options bags, just a different representation. Shane is working on semantic skeletons where they try to address this problem by having enums for each subtype
+
+EAO: the enums are locale specific - in Finnish using abbreviated month names is weird for example. EAO would prefer not getting stuck in a discussion about what is the best way to format dates in general, EAO would prefer we change away from short, is OK with medium, but would prefer long. short is weirdly abbreviated in many languages. Skeletons is beyond the scope of this specific PR
+
+MIH: vote for default (medium)
+
+APP: Do we want to propose medium as a default?
+
+EAO: Proposes long
+
+APP: I have a slight preference for medium
+
+Voting:
+- Long: EAO, USA
+- Medium: LCA, APP, MIH, HGO
+- Short: none
+  
+USA and EAO can live with medium
+
+**Action item:** EAO to make change to PR
+
+### Unify input/local in data model #799
+
+APP: we’ve had some previous discussion. Have we discussed feedback from MIH and and STA
+
+MIH: would prefer to keep as is, this simplification is not useful, STA feels similarly
+
+APP: Could you live with the change to remove that distinction? There’s a set of arguments for detecting the local input when … not sure if it goes too far in terms of oversimplifying.
+
+MIH: I think it goes too far, it’s not just about processing, the problem is that it unifies different concepts.
+
+LCA: I didn’t understand the semantic difference between the two earlier.
+
+MIH:
+
+LCA: What’s really interesting is that you think of them like function arguments, but the problem is that the function attributes is more like a .. if you think it terms of JS for instance you have a function that takes an argument and you still don’t 
+
+APP: your mental model is the correct one, none of the input values are needed to be annotated. As programmers, we tend to think of our …
+
+EAO: One concern: building this into the data model has an issue that local variables can’t always be treated as what we consider local variables. So we can’t for .input or .local and change the following annotation and it might not work… the expectations are the same for both. In the data model specifically 
+…
+
+MIH: You need to move that as in input or you could do it as a local variable.
+
+APP: You cannot do local for input.
+
+MIH: So they are different things.
+
+LCA: is it correct to assume that you have a linter rule that disallows variables that aren’t declared appropriately?
+
+MIH: if the input is there, it assumes that it came from the developer. It’s a promise that it is coming from outside and that I cannot mess with it.
+
+LCA: I thought input was a type annotation, but it also has a second function. It also creates a new resolved value with the formatting values that you have specified.
+
+APP: I push back to “remember this is the data model”, not the syntax. Will it matter if the internal structural representation in the data model infers input vs local given what the operand is.
+
+EAO: Do I understand right, in your POV, the first line can be expanded to B but not A?
+You have {$x :number} Into either: A) .input {$x :number} {{You have {$x}}} B) .local $y = {$x :number} {{You have {$y}}}
+
+LCA: What a formatting language that isn’t MF2 would turn into the data model? A language that has no semantic distinction between the two…
+
+EAO: When parsing a MF1 message in a MF2 context, we need to make this relatively abstract decision if we need a … and it’s easier not to have to make it at the data model level.
+
+---
+
+## Key Discussions
+
+### Close out error handling (#816, #804)
+
+MIH: I was unhappy with the discrepancy and I couldn’t find any agreement between us on the subject.
+
+EAO: the part you’re concerned about is the requirement to be able to find out if a message has an error in it.
+
+MIH: what bothers me is that we force programming languages to do error handling a certain way.
+
+APP: we go out of our way to avoid specifying how errors are signaled.
+
+MIH: many systems have existing behaviors for error handling - we can not change them all. we should allow an implementation to have either throwing or fallback behaviour
+
+(There was a long unrecorded conversation about error handling omitted here due to losing our scribe mid-call. The net result was a call for balloting of the issue, to be done before the next telecon)
+
+## If time permits:
+### Whitespace/bidi handling (#811)
+
+APP: Need to consider whitespace interaction with isolates, particularly with regard to syntax validity. Being too strict here could result in user dissatisfaction.
+
+
+
+## Topic: AOB?
+
+Post-call discussion of bidi/whitespace with EAO, APP, MIH, RGN