- Shane Carr - Google i18n (SFC), Co-Moderator
- Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
- Yusuke Suzuki - Apple (YSZ)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Craig Cornelius - Google i18n (CCN)
- Sergey Rubanov - Invited Expert (SRV)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
RGN: Not a lot of updates; ES 2022 is on track.
RCA: Still working on the syntax. Thanks to Richard for very helpful comments.
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
RCA: I updated parts of this. We don’t have an open PR. Re: browsers, need to ask browser developers to update the status, esp. with versions. Re: versions, update formatting.
FYT: Update on Stage 3, in staging and testing. Needs to request to ship this, but there is more than a week until the deadline. There’s a mistake that should be fixed. FT is still hesitant about running the unit tests, concerned that additional tests are needed.
RCA: I've started porting RGN's set of tests; I have a draft PR. I'm trying to get a little more coverage on that part of the spec. I compared the spec with the previous version and found some areas where coverage could be improved.
RGN: That's great; thanks!
SFC: Spider Monkey has flags. Will Mozilla ship this unflagged?
YSZ: We already shipped this, still have some “fix” that we should address but everything it’s ok
SFC: We already meet the requirements for S4, and are pretty close. Will wait for Frank’s PR.
SFC: Still waiting for the Intl Mathematical Value PR that’s been waiting for a long time.
FYT: The real question is is this will make it into 2023 version, February. We want to merge as early as possible.
SFC: It’s good to land the proposal in the fall if possible.
FYT: This is not a tiny proposal , we should give time for editors to review
SFC: Any updates on Duration Format? It’s been at Stage 3 for a year, stable. It’s waiting.
RCA: It has some coverage, but it’s not prioritized. Has been waiting to understand how this relates to Temporal, which was the main blocker. No longer blocked, however.
YSZ: Implementation-wise, we don't have an update. I understand last meeting we decoupled this from Temporal. If that's true, it doesn't have a blocker for JSC, so we can start prototyping this. But we don't currently have an implementation.
FYT: I prototyped it a while ago, but recently I've been too busy implementing Temporal. I think the decouple the proposal it’s pretty good but needed changes still big
SFC: Thanks. Most of 2022 has been polishing proposals. Still hoping to finish Error Display for July (maybe September.) At this time, this is the only one that looks ready for S2. MessageFormat may get to S2. Duration is the big item still open on Intl. There are still pieces in Units awaiting further action, but not prioritized. Asked Long about Locale Matcher, but it’s not prioritized.
SFC: there is a process for being downgraded. MessageFormat is in progress. There’s definitely room for more work.
FYT: I see a gap that needs to be filled in Temporal - Era is missing. Will that be part of Temporal or another proposal to 402? There is not even a placeholder for it.
SFC: Romulo?
RCA: Added modifications but did not update the tracking.
SFC: Much more than just temporal, e.g., Calendar, etc.
FYT: Duration is already here. But 2nd part… Third part is …??? Should we have another item to fill in the gap, e.g., Era?
SFC: We have Duration, Section 15, Calendar.
FYT: Duration is at S3, Section 15 at S3.
FYT: I will open a repo at stage 0 as placeholder for Era proposal and will work with USA to define the scope. He volunteers to push this to Stage 0.
SFC : Thanks for volunteering. Forwarding an info link to FYT that will help get started. Note to RCA that this issue is being tracked, but it’s definitely 50% as indicated
SFC: The notes from Ujiwal: https://notes.igalia.com/o7MT_yQJTV2Ka06sjyuJ5g#. AFAIK this is the full extent today.
SFC: Any new PRs to review? Richard, #690.
RGN: (explains PR) ECMA 262 is purely additive. Nothing permitted by 402 is prohibited or constrained by 262. Nothing required by 402 is incompatible with implementation freedom allowed by 262.
RGN: Areas where this comes up are 402 and 262 behavior being required to agree on default time zone. The other area is what time zones and calendars are going to be allowed in a non-402, 262 implementation. If 402 has a constraint, 262 should have the same constraint, like the IANA list or the CLDR calendars.
SFC: I think this is clarifying, quite frankly we could have something similar also with Temporal. This is a model for making spec more modular, and 402 is an example of this. In favor!
RCA: +1
LAF: +1
Consensus on 690
tc39/proposal-intl-numberformat-v3#96
SFC: This is an issue that Philip opened. There are two approaches possible. Some parts of the behavior of rounding are “surprising or non-intuititve”. Happy that Philip has given a concrete proposal for improvement. The keyb difference is bullet #3, involving minimum digits to choose. This is a fairly easy change to make, and should be nailed down. Continual changes are a problem, and this proposal is disruptive. The circumstances for this proposed change are in a specific case detailed in the PR.
SFC: What is expected for the example?
CRN: I expect “1.00”, based on minFraction.
SFC: describes how this actually works with implicit maximum significant digits. Because min Sig Digits is indicated, fraction digits is ignored, so 2 significant digits is all the counts → “1.0”.
CRN: Should this be disallowed when they have conflicts ?
SFC: roundingPriority is the way to indicate which wins. Depends on what roundingPriority actually means.
RCA: There’s an issue with fraction digits in case of not being set by the user, but the default setting for fraction digits doesn’t help in this case. SFC: Likes Philip’s model, but is this important enough to disrupt at Stage 3? Concretely, this entails a spec change, then a change in ICU 72, which will automatically be implemented when ICU is released.
SFC: Understanding is that Philip’s proposal defines how the conflict is resolved.
RCA: Always showing more than less would be better ????
SFC: Proposed fix changes on what basis the resolution is made, based on the setting. Philip came in with fresh eyes and proposed how it should actually work. This is helpful, and it makes sense.
SFC: Is anyone opposed to this change for this S3 proposal? Is anyone in favor of making this change?
FYT: Slightly in favor.
RCA: In favor but somewhat afraid of the impact.
SFC: No opposition, 3 in favor. Plan to draft normative change and implement in ICU, and will make sure the use case works in Compact Notation as well as distance rounding. In short, make the change, check that it works, then ask for review if it works.
SFC to follow up as discussed above.
tc39/proposal-intl-locale-info#33
SFC: One of our favorite problems that we cannot seem to resolve in this group. What is the order in which the locales should be returned? The only thing we agree on is that the order should be specified, but not on which ordering?
SFC: There are several proposals. The broad topic was covered a year ago.
SFC: Default collation: should that go first? General but not complete agreement on this.
SFC: What about remaining entries? Alphabetically; rough order of descending preference (but how is that determined?) From CLDR data? This might be implementation dependent…
So, the options are:
- Default setting first; remaining settings implementation-defined ordering, with prose to say that they are in descending order of preference
- Default setting first; remaining settings defer strictly to somewhere else (likely UTS 35) to define the ordering
- Default setting first; remaining settings in lexicographical order
- All settings in lexicographical order
FYT: THese are the consequences, not the intentions, esp. for the first one. That is not a necessary consequence, however. Or is a standard used to define the order (defered to.) We are only discussing collation at this point.
RCA: The ordering for numbering systems is a completely different in Browsers vs CLDR.
SFC: Summarizing the thread: General agreement: it’s fairly easy to specify the ordering, but….
Markus: added discussion points, that a use case in which the ordering could be used to present a list to a user. Alphabetic ordering seems to make sense.
SFC: Henry noted that alphabetic may not be consistent across browsers, because additional collation choices in some browsers introduce differences. Should these options be prohibited?
What are the use cases? Intl.Collator doesn’t allow “standard” and “search”, instead using the “usage” property.
SFC: This is a fun problem but we apparently aren’t ready to decide. FYT made proposal #36 last year to excluded “standard” and “search” .
FYT : We also it’s mentioned in the #31 , we can consider the first items are implicitly defaults ones, so we don’t have any Additional sorting we do not list there
SFC: the first entry of the list should be what the Intl Collator does in effect. Gives an example in inspector, showing how Chrome’s Intl.Collator(“en”... ) works. Trying with ‘zh-TW’ and various options. Trying with “zh-CN”, which gives “pinyin” as default. Trying with “en-u-co-emoji”.
SFC: Soliciting opinions:
YSZ: No strong opinions.
CCN: Avoid implementation-dependent behavior.
SFC : My opinion it’s we should revert 36, then do the default as first , collation. It is not consistent with the collation you apply in the option bag of collator and locale and it’s no equivalent that could work in both places and it’s no equivalent for default collation.
SFC: “en-u-co-default” is not valid. However, V8 doesn’t throw an exception. Testing “toString()” with various options.
“en-u-co-search” - is this disallowed? But {usage: “search”} works.
FYI: check 402 for “search”, demonstrating that values “standard” and search”; are not allowed, but “default” is allowed.
SFC: This is a divergence from UTS-35. We could put “default” at the beginning of the list, a way to make this work. There are two options: change the standard to allow “standard” and “search” put “default” at the start of the list
Added note in #33 asking about option b. above.
FYT: would there then be “default” at the start of every list? This collations would only return that if it is in the right order you have an implicit default
SFC: “default” at the beginning? What is the default for “zh-CN”, for “en”? The first default should be spelled out rather than be implicit.
No solid conclusion. Odd that ECMA-402 differs from UTS 35. See if there's a value we can prepend to the list that indicates the default collation.
SFC: last discussed at March meeting.
FYT: Long ago, in Chromium, patch was made to break differently. The patch has been inherited and the desire is to break differently. Should this be treated as spec problem or as a bug in V8 ?
SFC : What do you mean by that ?
SFC: This is a place where we don’t agree at this group, the spec just specify just enough that implementers could make assumptions to c
We have fairly clear feedback from a user that the difference is big enough that they cannot use Intl.Segmenter at all.
FYT: For a user of Intl.Segmenter, e.g, Japanese segmentation, would this be different between browsers?
SFC: What we agree that what should be needed to get specified its a bit fuzzy , at ECMA402 we can define some prose about defining this behavior
RGN: we effectively have this because we defer to Unicode.
FYT : This is an issue because in V8 we have this patch - this it’s a bug in V8 not a spec issue
SFC: We already have a note (in prose) that is clearly not sufficient. We could tighten the text in ecma402/segmenter-objects. My proposal it’s to modify this prose to be more specific about correct behavior with URL’s.
RGN: We could make a PR, but it’s purposely under-specified. But it does reference to the default rules and default rules do not permit identification of a break inside of a domain name, WB6 and WB7 in Unicode TF29
SFC : This a chrome bug , we agree
FYT : Would be helpful have test262 that covers this
RCA : Yes we can add it
SFC: Adding task for RCA to add a test.
RGN: Could also push for an explanatory note above WB6 in TR29 regarding what doesn’t break, similar to that above WB8. This would make it clearer to readers.
CCN: How to make this happen in TR29?
RGN: Checking how to post an issue - probably a Unicode Jira process. Maybe send email directly to TR29 editor?
This needs to be fixed in V8 not a spec bug.
RGN to write up a note for TR29, suggesting a change, to be communicated with Unicode editors.