Create notes-2023-12-14.md

meetings/notes-2023-12-14.md

@@ -0,0 +1,294 @@
+# 2023-12-14 ECMA-402 Meeting
+
+## Logistics
+
+### Attendees
+
+- Shane Carr - Google i18n (SFC), Co-Moderator
+- Chris de Almeida - IBM (CDA)
+- Eemeli Aro - Mozilla (EAO)
+- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
+- Louis-Aimé de Fouquières - Invited Expert (LAF)
+- Richard Gibson - OpenJS Foundation (RGN)
+- Ujjwal Sharma - Igalia (USA), Co-Moderator
+
+### Standing items
+
+- [Discussion Board](https://github.com/tc39/ecma402/projects/2)
+- [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update!
+- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt)
+- [MDN Tracking](https://github.com/tc39/ecma402-mdn)
+- [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com)
+- [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org)
+
+## Status Updates
+
+### Updates from the Editors
+
+RGN: Nothing to report, although we're prefixing percent-quoted intrinsics with Intl. I think that will land between now and the next meeting.
+
+SFC: It's almost time that we should start planning to get the artifact for ES 2024. I don't want to rush like we did last year.
+
+USA: We should reach out to the 262 editors and Samina. What ended up happening was we did the regular routine that Leo (LBR) had done. This was acceptable to ECMA. If they hire professional help… but we have an existing process which isn't too bad.
+
+RGN: I agree with that. We worked out something that was acceptable last year.
+
+FYT: My understanding is that for 2024 are several normative PRs and no new proposals. Right?
+
+SFC: Maybe DurationFormat
+
+FYT: I don't think that will happen, implementation-wise.
+
+SFC: Intl Locale Info?
+
+FYT: I was hoping for the same, but there’s too many unresolved issues so it’s not to track for that.
+
+USA: Is your understanding of DurationFormat based on the spidermonkey implementation? My impression was that it is closer to done.
+
+FYT: Maybe we'll have implementations but will we reach Stage 4 by the deadline?
+
+USA: The requirements are tests, implementations, and no unresolved design questions. There aren't unresolved questions, and I think there are tests.
+
+SFC: The road to get from where we are to where we need to be is clear but some parts of the spec are still in flux, there needs to be some editorial work done. The big editorial refactor is not yet landed and certain tests haven’t landed either.
+
+USA: On the big editorial refactor, parts of that have already been landed and we need to re-evaluate. I agree that there are still some pieces that need to get across the finish line.
+
+SFC: I didn’t like the last time we had to scramble to get it done at the end, so I’d prefer if we keep it to Feb and focus on getting everything into the spec in a clear way instead of rushing through this.
+
+FYT: From my understanding at the moment, I don’t think any proposals can make the cut.
+
+SFC: The unresolved issue regarding the first day of the week, was it approved by TG1? 
+
+FYT: Yes
+
+SFC: Does it mean there’s no outstanding issues then?
+
+FYT: There’s still some, including the resolution of fw and the ordering of the calendars.
+
+SFC: Did they approve the getter functions? Including the spec and tests?
+
+FYT: It’s approved but the spec isn’t merged yet.
+
+SFC: Then it might be done by then.
+
+FYT: I don’t see that happening.
+
+SFC: Fair enough, no need to rush. I’d love to have bandwidth to work on other things instead of keeping revisiting DurationFormat and Intl Locale Info.
+
+USA: Something that we can do, I believe, as editors, is to institute a cutoff date ourselves. We might decide collectively to have a cutoff date after which we make a branch and freeze that for the purposes of ES 2024.
+
+SFC: I think that it’s up to the editors. There’s an easy way to enforce that, let’s call the Feb 2024 plenary meeting a deadline and anything that lands after that isn’t considered to be a part of the upcoming release.
+
+FYT: So it seems like ES 2024 are the normative PRs. That's the scope, right?
+
+USA: There are a lot of editorial changes that have gone through this year.
+
+SFC: Yes, and I wouldn't downplay the impact of those other changes.
+
+### Updates from the MessageFormat Working Group
+
+EAO: A bunch of progress. We're chasing down remaining blockers for getting the whole spec out as part of the ICU spring release (ICU 75). I'm optimistic that we can make it. We don't have consensus on the definition in that specification for a formatted parts structure. So we will need to specify that in the Intl Message Format proposal for the formatToParts method. Still tweaking some parts of the syntax. We are close to finalizing an update to how markup placeholder elements work. They will work like HTML tags, `#` and `/`... And the function registry is well on its way to being finalish. We have also agreed to have a second in-person meeting after the San Diego TC39.
+
+### Updates from Implementers
+
+https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
+
+FYT: Nothing recently.
+
+SFC: Do you have an update on CLDR 44?
+
+FYT: Nope. There's an issue and Mozilla decided to backtrack. They are waiting for ICU 74.2 to resolve it. And V8, because of that and another issue, they haven't addressed how to roll to 74. That's not in my hands right now. So it seems nobody is moving to 74 yet.
+
+The problem for why Mozilla backtracked is because CLDR changed some inheritance model and there is a hack inside of ICU that opted out the inheritance in that code causing some locale to be not right (sv-SE). We didn't catch that until after the ICU 74 release. Mozilla realized that it is a bug that was set incorrectly in ICU. So Apple is signed up to solve the bug. But, that won't be released until mid January. But I also saw an issue come in today from Apple where the fix is not complete. So I'm not sure.
+
+EAO: I thought ICU 74.2 was out this week.
+
+SFC: It's in progress this week for sure. BRS tasks are going.
+
+EAO: The main announcement from Firefox's point of view is that Intl.Segmenter is in non-nightly builds of Firefox. It's going into release.
+
+SFC: That's great news! But how is it implemented? ICU4X doesn't support random access yet.
+
+EAO: It looks like the impl is using ICU4X Segmenter: https://bugzilla.mozilla.org/show_bug.cgi?id=1423593.
+
+### Updates from the W3C i18n Group
+
+EAO: I'm not able to attend all of these meetings. But I'm still communicating with the members and will bridge things when necessary.
+
+FYT: Is Addison still the chair? I thought he retired.
+
+EAO: He retired from Amazon but he's still the chair.
+
+
+## Proposals and Discussion Topics
+
+https://github.com/tc39/ecma402/projects/2
+
+### DateTimeFormat Editorial Discussion
+
+USA: This is an in-depth discussion about improving DateTimeFormat editorially. But this is resolved due to Anba's pull requests. But DateTimeFormat has come a long way since I put this on the board.
+
+SFC: Are those changes that have been made since the card was filed about 6 months ago?
+
+USA: The structured header change, yes.
+
+FYT: Point of order, the agenda item has no context.
+
+USA: Yeah, that was an oversight. I apologize. Here's a link: https://github.com/tc39/ecma402/pull/822 It is a big pull request and not all of them deal with DateTimeFormat. So the DateTimeFormat spec is in a much better state than when I hastily put this on the agenda.
+
+SFC: I would suggest that we table this discussion for when we have something more specific to discuss.
+
+USA: Sounds good. I'll start taking a look and filing issues.
+
+LAF: Does eraDisplay take place in part of this discussion?
+
+SFC: Separate.
+
+### Normative: Allow locale based ignorePunctuation default #833
+
+https://github.com/tc39/ecma402/pull/833
+
+FYT: I was working on V8 and I realized that V8 broke a Test262 test. It seems like there is a difference between CLDR and our spec. ignorePunctuation is false for most locales but true for Thai.
+
+SFC: I think this is a good change. Good to pull items from locale data, and good to make them well structured like a Boolean.
+
+FYT: Any other explicit support or objection?
+
+EAO: +1
+
+SFC: I think this is good enough approval from this group to put it up for TG1 consensus.
+
+### eraDisplay Updates
+
+https://github.com/tc39/proposal-intl-eradisplay
+
+LAF: (presents slides)
+
+https://docs.google.com/presentation/d/1E52qRsTNoPyIJx8YesoPuz0ilfGT61X7Rnwj13Bdpz4/edit?usp=sharing
+
+FYT: More calendars besides Julian use 1 - N for the backwards era. For example, Minguo.
+
+LAF: Yes, that was an example. I updated the slides.
+
+FYT: How about Coptic? How did they number the year?
+
+LAF: In ICU, yes, it has 1 - N. But for historical dates they used a 365-day year. They numbered the year from emperors/pharaohs. It was based on the historic Egyptian calendar. Same with the Islamic calendar; people used different calendar systems before it started.
+
+FYT: And for Chinese/Dangi, ICU recycled the era field, but they are not eras. Note also that ancient China had multiple emperors for different regions resulting in different era counting.
+
+LAF: So I would like to propose some more values for eraDisplay:
+
+- void: existing behavior
+- auto: best decision according to locale & calendar
+- discreet: hide the era if the present era
+- explicit: display the era but only if `year` is present
+- always: display the era even if `year` is not present
+- never: do not display the era
+
+SFC: How about era display before a cutoff date? For example, I might read "763 AD" but "1600" and there's a cutoff between there somewhere.
+
+LAF: I think we could do that. Could be specified in CLDR. For example, certainly in the first century we like to write AD, so you don't confuse the year with the day of the month.
+
+SFC: In my opinion, we should keep "auto" as the default. I don't think this rises to the level of keeping around the old, broken behavior.
+
+LAF: I'm in line with this
+
+FYT: I agree
+
+FYT: Can you clarify when you would use discreet and explicit?
+
+LAF: For example, for Buddhist.
+
+SFC: I've definitely seem "BE" used to clarify that a date is in the Buddhist Era and not in the Common Era as the default behavior.
+
+SFC: I don't think "explicit" and "always" should be separate. We should just do the right thing. There is another proposal to fix field resolution.
+
+SFC: Is there a concern with adding the new field for PatternEra?
+
+FYT: It's only a single pattern string, right?
+
+SFC: Yes, well one contains the era field and the other not.
+
+FYT: That seems fine to me. The concerns I had was when the slots contained much deeper data.
+
+SFC: Cool. So I'd like to come back next month with another update and then maybe put this up for stage advancement.
+
+### Month and Era Code Proposal
+
+https://github.com/tc39/proposal-intl-era-monthcode
+
+FYT: This is still a proposal we need. I just haven't had time to work on it.
+
+### ApplyUnicodeExtensionToTag and ResolveLocale set the result record's internal slots to non-canonical values #707
+
+https://github.com/tc39/ecma402/issues/707
+
+FYT: I don't actually see where the spec allows us to canonicalize the extension keywords. I only see where it canonicalizes LSRV: https://tc39.es/ecma402/#sec-canonicalizeunicodelocaleid
+
+RGN: It is here in UTS 35: https://unicode.org/reports/tr35/#processing-localeids
+
+FYT: ApplyUnicodeExtensionToTag is used only in Intl.Locale. The other constructors are using resolved locale.
+
+SFC: Does this impact firstDayOfWeek?
+
+EAO: No, we still need the string forms, and there's not a way to handle the error conditions.
+
+#### Conclusion
+
+Change step 5f in ApplyUnicodeExtensionToTag to canonicalize the keyword value. FYT volunteers to do it.
+
+### Add option to use variant era names #845
+
+https://github.com/tc39/ecma402/issues/845
+
+LAF: Might be interesting for Julian-Gregorian or for the Islamic calendars. You could write "Umm al-Qura" for one calendar based on the precision.
+
+EAO: Are there really no differences between AD and CE?
+
+RGN: It's an alias, a different spelling.
+
+LAF: In my opinion, AD/BC only applies to the Julian calendar whereas CE is the proleptic Gregorian calendar.
+
+SFC: I concur that it would be nice to get the era display differences via changing the calendar system (between gregory, gregory-julian, and julian) than introducing a whole new option.
+
+SFC: A reasonable conclusion would be to put this on the backlog and revisit when Temporal, Era Code, and Era Display are all landed.
+
+LAF: Yes
+
+### NumberFormat has odd behaviour for narrow/compact display of bytes #730
+
+https://github.com/tc39/ecma402/issues/730
+
+CDA: Looks related to this issue: https://github.com/tc39/ecma402/issues/810
+
+SFC: The solution I proposed in 810 might solve the issue enough to make it not a problem anymore, but I wonder if we should just make notation compact with style unit select the correct unit for specific sets of units.
+
+RGN: Is there a locale where we get formatting like "100USD"? It would look like "100BUSD"
+
+SFC: I recall that type of problem coming up before but I think they fixed it for currency.
+
+RGN: So I think you just need to put whitespace in between. And then split this formatting bug from the bug of selecting the right unit.
+
+SFC: It is a CLDR bug then and we should fix it in the CLDR.
+
+EAO: Meanwhile, we should provide a proper solution for SI prefix formatting, because that's how users are currently using this.
+
+RGN: Yeah, it could even cause web compat issues like the NNBSP problem.
+
+EAO: It could even be done with a special locale code! like "null".
+
+RGN: I don't know if that's the whole but I agree.
+
+SFC: Is there any problem with special-casing units that get formatted with SI prefixes?
+
+https://tc39.es/ecma402/#sec-measurement-unit-identifiers
+
+RGN: Seems brittle to me.
+
+CDA: strawperson: would anyone ever want e.g. 100 billion bytes?
+
+RGN: yes, e.g. "100K s" (1e5 seconds) vs. "100 Ks" (1e2 kiloseconds)
+
+EAO: I'd like to discuss this in the context of stable formatting.
+
+SFC: I'd like to discuss this with the CLDR design group.