|
| 1 | +# 13 January 2025 | MessageFormat Working Group Teleconference |
| 2 | + |
| 3 | +### Attendees |
| 4 | + |
| 5 | +- Eemeli Aro \- Mozilla (EAO) \- acting chair |
| 6 | +- Mihai Niță \- Google (MIH) |
| 7 | +- Mark Davis \- Google (MED) |
| 8 | +- Elango Cheran \- Google (ECH) |
| 9 | +- Richard Gibson \- OpenJSF (RGN) |
| 10 | +- Shane Carr \- Google (SFC) |
| 11 | +- Matt Radbourne \- Bloomberg (MRR) |
| 12 | + |
| 13 | +**Scribe:** ECH |
| 14 | +**Previous Scribe:** MIH |
| 15 | + |
| 16 | + |
| 17 | +## Topic: Info Share |
| 18 | + |
| 19 | +EAO: Ujjwal and I will be presenting on MF2.0 at FOSDEM in Brussels at the beginning of February. We will share materials and the recording once it’s available. |
| 20 | + |
| 21 | +ECH: I am iterating on a design doc for implementing MF2.0 in ICU4X. The design doc link and meeting notes on the discussions about it are at the [ICU4X repo issue](https://github.com/unicode-org/icu4x/issues/3028). |
| 22 | + |
| 23 | +## Topic: Blog Post |
| 24 | + |
| 25 | +MED: Addison made [a draft](https://docs.google.com/document/d/1ksazpz37i3UsYtqX4zTC_JlzivEQv8e4/edit). Our goal is to get this out by Wednesday. We'll need to assume that Addison is otherwise occupied, so I want to get it basically ready today. |
| 26 | + |
| 27 | +MED: The reason to get it out soon is that we will finalize CLDR v47 at the end of February, so we don’t have much time to inform people to try it out and give feedback before then. We really should have gotten this out before the winter holidays, but at this point, we should get it published as soon as we can. |
| 28 | + |
| 29 | +MED: I will assign people to flesh out different parts of the blog post draft doc. It is important to talk about the important changes that are interesting for potential users so that they are willing to download and try it out. For that reason, the previous draft text that talks about the history of the project is not relevant here. Also, it’s worth mentioning that if you are someone that depends on localization, then MF2.0 affects your life. Highlighting the personal impact should create engagement. |
| 30 | + |
| 31 | +Action: EAO to create a PR altering the [spec CSS](https://github.com/unicode-org/cldr/blob/main/tools/scripts/tr-archive/tr35.css) so that notes are distinguishable from normative text. Mark to create CLDR Jira ticket needed for the CLDR Github PR. |
| 32 | + |
| 33 | +## Topic: PR Review |
| 34 | + |
| 35 | +*Timeboxed review of items ready for merge.* |
| 36 | + |
| 37 | +### \#974 - Split spec/registry.md into parts |
| 38 | + |
| 39 | +EAO: Can we merge? Addison left comments but did not disapprove. |
| 40 | + |
| 41 | +MED: When this gets packaged up for Part 9 of CLDR LDML, then this is only a convenience for us. |
| 42 | + |
| 43 | +EAO: Yes. It also gets rid of the word “registry” from the name of the file. Okay, I will merge this. |
| 44 | + |
| 45 | +### \#968 - Clarification to default bidi strategy |
| 46 | + |
| 47 | +EAO: Can we merge this? |
| 48 | + |
| 49 | +MIH: I am okay with that. |
| 50 | + |
| 51 | +MED: I’m looking at the notes further down about “futher consideration”. |
| 52 | + |
| 53 | +EAO: That got resolved. Tim made those changes. |
| 54 | + |
| 55 | +MED: Okay, I’m fine. |
| 56 | + |
| 57 | +EAO: Okay. Merging now. |
| 58 | + |
| 59 | +### \#923 - Test schema: allow src property to either be string or array of strings |
| 60 | + |
| 61 | +MED: When you’re mapping this to a programming language, and you have a union type of “string or array”, then it makes it difficult for statically typed languages. |
| 62 | + |
| 63 | +MIH: It still makes it difficult for statically typed languages. |
| 64 | + |
| 65 | +ECH: \+1 |
| 66 | + |
| 67 | +MIH: We can also add a field so that we have `source` and `sourceArray` to handle the case of a single string or multiple strings. |
| 68 | + |
| 69 | +MRR: I wanted to unpack |
| 70 | + |
| 71 | +MIH: It’s not quite the same logic. In a statically typed language |
| 72 | + |
| 73 | +EAO: Do we have any real world concern about handling a string vs an array? |
| 74 | + |
| 75 | +EAO: This is clearly not ready to merge, let's leave its resolution until later. |
| 76 | + |
| 77 | +## Topic: Issue review |
| 78 | + |
| 79 | +Currently we have 31 open (was 31 last time). |
| 80 | + |
| 81 | +* 2 are tagged for 46.1 (1 is resolve-candidate, 1 is Action-Item) |
| 82 | +* 16 are tagged for 47 |
| 83 | +* 3 are tagged “Seek-Feedback-in-Preview” |
| 84 | +* 6 are tagged “Future” |
| 85 | +* 11 are `Preview-Feedback` |
| 86 | +* 2 are `resolve-candidate` and proposed for close. |
| 87 | +* 1 is `Agenda+` and proposed for discussion. |
| 88 | +* 0 are ballots |
| 89 | + |
| 90 | +### [#963](https://github.com/unicode-org/message-format-wg/issues/963) |
| 91 | + |
| 92 | +SFC: We spent literally years in ECMA-402 for the Temporal API debating this. In MF2, you have 3 places that a calendar can come from: there is a calendar option in the message string, and also the locale, and the object being formatted. It’s messy and prone to error. We solved this in Temporal by saying all calendars must match. Else if there is one non-ISO and the rest are ISO, then the non-ISO calendar wins. Else if there are multiple non-ISO calendars, then that is an error. |
| 93 | + |
| 94 | +SFC: I think MF2 should put the least requirements on the implementations. That is also why I’m against having a time zone option because it forces implementations to convert dates between time zones, because that is an expensive operation. And similarly, the implementation should not be required to convert dates between calendars. It seems unclean for MF2 to have this toggle. |
| 95 | + |
| 96 | +MED: In that case, you would have to |
| 97 | + |
| 98 | +SFC: You can still use the `-u-ca-` subtag in the locale id. But I’m against specifying this in the message string. Having dates and calendars specified in the message string makes this complicated. |
| 99 | + |
| 100 | +MED: Although if you specify the locale as a MF2 attribute in the message string, then that complicates things. |
| 101 | + |
| 102 | +EAO: For example, you can specify `u:locale=th-u-ca-iso8601` |
| 103 | + |
| 104 | +SFC: You can do that? That’s allowed? That seems very problematic. This completely breaks ICU4X. In ICU4X, from the very beginning, we declared that every message has a single locale. That affects data loading, so that we only have to load locale data for one locale. If you don’t know what locale you need to format for, then it makes things very difficult and breaks ICU4X. If I had known that this was a feature, I would have said something about this. |
| 105 | + |
| 106 | +EAO: Having the locale attribute in MF2.0 annotated in a message is not required, but it’s recommended. |
| 107 | + |
| 108 | +SFC: I’m not wild about saying it’s recommended. You can still have messages in the wild that have it, and the problem would still exist. |
| 109 | + |
| 110 | +SFC: I will file a separate issue about the locale attribute. |
| 111 | + |
| 112 | +SFC: Regarding calendars, if there is not a strong use case of having multiple calendars, then we should drop the option. The performance cost would be regrettable. But if there is a use case that the WG sees fit, then we’ll have to eat the cost. |
| 113 | + |
| 114 | +MIH: I have seen messages that include multiple calendars. Like a date formatted in an Islamic calendar, and in parentheses, it includes the date in Gregorian or some calendar. |
| 115 | + |
| 116 | +MED: I will record that we will lessen the requirement of specifying a calendar from MUST to either SHOULD or MAY. |
| 117 | + |
| 118 | +MIH: If I understand the objection, is that’s you don’t want to do the calendar conversion all the same. But if at runtime, I pass a date/calendar object that uses the Islamic calendar, what would be the expected behavior in ICU4X? |
| 119 | + |
| 120 | +SFC: If you use `formatAnyCalendar`, then it will support conversion between calendars. I wanted it to be named `formatAndConvertCalendar` to be explicit about that. |
| 121 | + |
| 122 | +EAO: In ECMA-402 Temporal, why is it an error if there are 2 non-ISO calendars? Why not just use the locale’s calendar? |
| 123 | + |
| 124 | +SFC: We see ISO as a neutral calendar, and a non-ISO calendar as an expression of intent or preference of which calendar. When there are multiple sources of calendars, it allows the expression of multiple preferences, and we don’t know how to resolve that, so we throw an error. |
| 125 | + |
| 126 | +MED: Let me see if I can capture EAO’s question: |
| 127 | + |
| 128 | +Example 1: |
| 129 | + |
| 130 | +``` |
| 131 | +$date = xxx // islamic |
| 132 | +…{$date :date u:locale=fr} |
| 133 | +``` |
| 134 | + |
| 135 | +Example 2: |
| 136 | + |
| 137 | +``` |
| 138 | +$date = xxx // gregory |
| 139 | +…{$date :date u:locale=ar-EG-u-ca-islamic} // some Arabic that use Islamic |
| 140 | +``` |
| 141 | + |
| 142 | +Example 3: |
| 143 | + |
| 144 | +``` |
| 145 | +$date = xxx // islamic |
| 146 | +…{$date :date u:locale=fr calendar=buddist} |
| 147 | +``` |
| 148 | + |
| 149 | +Which is the result?: Gregorian from Fr or islamic-civil from the source or thai-buddhist from the option |
| 150 | + |
| 151 | +We could have 3 conflicts: |
| 152 | +* source |
| 153 | +* locale |
| 154 | +* the runtime input object calendar |
| 155 | + |
| 156 | +SFC: This is exactly why the Temporal algorithm was created as it is. |
| 157 | + |
| 158 | +EAO: And ISO 8601 calendar is not used by any locale? |
| 159 | + |
| 160 | +SFC: No |
| 161 | + |
| 162 | +EAO: Then I am okay with the algorithm. |
| 163 | + |
| 164 | +SFC: I find the examples above misleading when they specify the calendar system of the runtime date object carrying a calendar because most systems do not allow the date to carry a calendar. |
| 165 | + |
| 166 | +MED: You could have a date that specifies the number of seconds since 1970. |
| 167 | + |
| 168 | +SFC: And seconds since 1970 doesn’t carry a calendar. |
| 169 | + |
| 170 | +MIH: In Java, you can’t have a ISO 8601 |
| 171 | + |
| 172 | +SFC: I need to follow up with MIH on the Java implementation. If that is the way that Java applications specify a neutral calendar, then that would be fine. |
| 173 | + |
| 174 | +SFC: Typically, in the Temporal algorithm, the calendar is expected to not be attached to a date until the very end when it is time to format it. |
| 175 | + |
| 176 | +EAO: Do the ICU DateTime formatters have a preexisting manner to resolve the calendar of the DateTime and the calendar of the formatting locale? |
| 177 | + |
| 178 | +MED: Yes, they ignore the calendar of the input DateTime. They format it based on the formatting locale’s calendar. I agree with Shane’s description of the ECMA-402 Temporal algorithm. |
| 179 | + |
| 180 | +EAO: How much of this should we define? We could exactly and precisely how the calendar gets picked in every situation. Another option is only defining what is “useful”, for some definition of “useful”, and allow undefined behavior at the edges. |
| 181 | + |
| 182 | +MED: One way we can solve this is say that implementations have 2 different styles for date datatypes: strong calendar datatype or weak calendar datatype (or no attached calendar) |
| 183 | + |
| 184 | +SFC: I agree with Mark’s resolution. |
| 185 | + |
| 186 | +EAO: So you’re not insisting that the ECMA-402 Temporal algorithm should be used here? |
| 187 | + |
| 188 | +SFC: It only works when there is a strong association of a calendar to a date. But if there are differences based on the implementation programming language, and if that affects the |
| 189 | + |
| 190 | +MIH: Even the most modern API for date and times in Java, which is `java.time`, doesn’t have objects that carry with them the idea of a Calendar (from `time.chrono`: `HijrahDate`, `JapaneseDate`, `MinguoDate`, `ThaiBuddhistDate`). If that doesn’t work with the ECMA-402 Temporal API’s model / algorithm, then we can’t use it. We should be able to support the Java types, we can’t throw. |
| 191 | + |
| 192 | +MED: That’s why I specified that we specify about the differences that occur when the implementation has different levels of linkage of a calendar to a date. |
| 193 | + |
| 194 | +MED: I’ll take on writing a PR for this issue. |
| 195 | + |
| 196 | +## Topic: AOB? |
| 197 | + |
| 198 | +EAO: Next week's Monday is MLK Day. |
| 199 | + |
| 200 | +ECH: That is a holiday for us. |
| 201 | + |
| 202 | +MED: We should not cancel the meeting because we have a finite number of meetings before the next version, and issues still need time to discuss. Next week on Tuesday at 10:15 am PT works. |
0 commit comments