- Shane Carr - Google i18n (SFC), Co-Moderator
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
- Eemeli Aro - Mozilla (EAO)
- Philip Chimento - Igalia (PFC)
- Richard Gibson - OpenJS Foundation (RGN)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Yusuke Suzuki - Apple (YSZ)
- Zibi Braniecki - Mozilla (ZB)
- Greg Tatum - Mozilla (GPT)
- Craig Cornelius - Google i18n (CCN)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
RGN: No big updates.
FYT: Do we have the PDF of the 2022 edition? Are the tables working this year?
USA: There's a draft PDF on the reflector issue. It seems that ECMA is trying to get professional help.
RGN: https://github.com/tc39/ecma402/releases/tag/es2022-candidate that includes PDFs: https://github.com/tc39/ecma402/releases/download/es2022-candidate/ECMAScript.2022.Internationalization.API.Specification.pdf and https://github.com/tc39/ecma402/releases/download/es2022-candidate/ECMAScript.2022.Internationalization.API.Specification.-.A4.pdf
RCA: Working on syntax issues to get it ready for release next fall.
EAO: We're under time pressure. ICU wants code to land by mid August. It would be valuable for everyone to take a look at the issues and comment on them.
SFC: What are the plans to reconcile the two syntax proposals?
EAO: We're hoping to avoid large sets of options and address individual issues.
SFC: What are the plans to address the comments on the slide deck?
EAO: Specific comments were migrated to individual issues on the repo.
https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue+is%3Aopen+label%3Asyntax
SFC: Although each individual item can be discussed in a vacuum, the larger proposal should be considered. We are on a time constraint, so should we take the details together and discuss the end result?
EAO: Effectively, the challenge here is that exactly that approach has been tried twice two far. The fact that this hasn’t produced the results we were looking for means that now we’re looking for alternatives by looking for divisive issues and having those conversations. Perhaps the best ones would be ones that encompass many different issues. There are so many details. The comments are not concluded on each of these detailed items, and this blocks progress on the entire proposal. We could try to debate overall which starting point to choose but since that hasn’t produced results so far, we’re thinking of trying this.
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
SFC: Any updates on the grid?
RCA: Only PR 615.
SFC: This has been effectively abandoned. We should close the PR if it’s not in a milestone.
FYT: Yes
USA: Do people think that this would be helpful? It could be picked up, but it’s not clear if it’s highly requested.
FYT: There’s no activity, in case someone is interested they can re-open the PR and pick up from the actual status.
SFC: It’s not simple and cannot be handled as a simple PR.
SFC: There are still a lot of other PRs in the spreadsheet.
RCA: Will look at these.
GPT: Re: SpiderMonkey and Segmenter. When Ting-yu gets back from parental leave, this will be picked up again. USA: We should create a new header from next year’s ECMAScript ?
SFC: LocalInfo and Enumeration still in stage 3? To be merged? Maybe stage 4 candidates?
FYT: Not quite ready for S4. Perhaps in July.
SFC: Intl.NumberFormat V3 - some small issues remain.
FYT: Some implementation issues remain, but handling of string is moving forward in review of a 700 line patch. Probably not in Chromium by end of Q2, but 80% confident of finishing by EOQ Q3.
SFC: DurationFormat?
USA: Yes, making progress on DurationFormat. There is a discussion that i added to the agenda for today,
FYT: Temporal has lots of things needing discussion in 402. These issues should be tracked here, especially things in Section 15. THere is no mention here of Temporal. E.g., Era, etc. should be made visible to this community.
USA : I support what FYT , there is a large amount of spec that comes from Temporal to 402 , all proposals that includes any Intl component should be followed closely here as well. Temporal Intl component is definitely much bigger that our current proposals.
SFC: Temporal proposal is about the size of entire 402 (or bigger).
USA: Intl part of the proposal is somewhat neglected that would benefit from discussion in this group. THere’s not a lot of discussion yet.
SFC : In February, we did a deep dive about Temporal in this meeting. I think it would be useful add parts to track in our wiki, but material discussions should happen in the Temporal champions meeting
https://github.com/tc39/ecma402/blob/HEAD/meetings/notes-2022-02-10.md#temporal-presentation
SFC: It may be useful to add USA’s work on the Calendar spec here. FYT is working on this in ICU. We are waiting on this for our work. It would be helpful to track this in our document.
USA: Re: work item, it’s also a work item for us here as well as the 262 folks since they will need to create a PR when it gets to stage 4. The actual implementation of tempora should have a lot of active involvement from people in this group.
FYT: For all things we track, we add tests. Maybe for Temporal as a whole (or subsection), we should be tracking that here since that will help us decide if it can be merged into ECMA 402 spec when it reaches S4. If we are not tracking, it may slow down our work.
SFC: I think we’re all in strong agreement that at least we should track the 402 section of the Temporal proposal. I believe that we should additionally track the calendar spec as another row.
RCA: I think we can add a “dependencies” section and that way we can track other similar things.
FYT: What do you mean when you say dependencies?
RCA: In the comments section, we could note down any dependencies for that particular proposal.
We can check each item in tracking, adding new comments as needed. E.g., ICU or other things that might affect our proposals.
USA: Re: the mention of ICU, etc., these are somewhat unrelated things. Things like DurationFormat have dependencies on the rest of Temporal, but the 402 side of Temporal is quite really just a 402 work item.
SFC: Re: dependencies, most proposals don’t have them. Can we just track in comments? RCA could you please take the action to update the wiki to reflect this in the next week or two?
RCA: Re: calendar changes, what is the timing for this?
FYT: I don’t think it’s just a spec-level question. On the impl side, it’s also relevant. I implemented Temporal in V8, including but not limited to the 402-parts. Already in the code base, now in revision and updating for non-UTC timezone. Most of this is implementable but only with very nasty code requiring lots of detailed explanation with the reviewer. One particularly difficult part is leading month in the Chinese calendar. If it can be done, hoping to get out by October. It’s implementable today, but very ugly. Hoping to get new API to make this easier to implement.
RCA: okay, thanks.
SFC: I'm hoping for calendar spec. Not in TC39, but hoping for Unicode update specifying what error codes and other things mean. We are hitting a wall on the implementation part and we really need it.
USA: In most cases except for preleptory or Gregorian calendar, there is no detailed specification. It would be good to have publicly available description. Perhaps it makes sense for Unicode to do this, but this hasn’t been formally discussed with Unicode.
FYT: What part of Unicode?
SFC: There are several different scopes that could be done in USA’s work. I anticipate this landing in Unicode under a new Technical Report number. Waiting for draft before approaching Unicode.
USA: At the moment, current ability to do “whatever” is not sufficient.
SFC: On Stage 1 proposals: all the items on Era Display have been discussed. It looks like this is ready to move to S2 now that these questions have been answered. SFC is the assigned champion, aiming for July. Would like to engage ICU4X and ICU.
LAF: Aiming at July would be good. Moving ahead to technical spec phase seems good.
SFC: Is anyone else interested in Era Display proposal?
SFC: Segmenter V2 is abandoned. How about MessageFormat?
EOA: Currently preparing presentations and will be happy to share. Other than that, waiting for Unicode proposal to progress.
SFC: Younies’s work on Unit Preferences - TC39 is not satisfied yet. We need to decide whether to build a stronger case around the impact of the work, or whether to take it from the angle of being important for a multilingual web.
tc39/proposal-intl-numberformat-v3#98
SFC: The issue as currently specified is for mathematical entities that have no bounds. There are two separate but related issues:
(1) Even if we were only doing pass-through formatting, the library needs to handle this. ICU does handle this, but not ICU4X.
(2) Certain operations need to be defined including LessThan. It is tricky to perform these on string values.
The point of this part of the proposal is to extend the bound since double precision is not enough. However, we have not discussed clearly about what is “infinite precision”? It’s somewhat arbitrary where these limits are set (1000, 5000, etc?) If the exponents need to be unbounded, then these too need to be strings. ICU4X currently does not support this capability. V8 implementers expressed that unlimited is very rough to build.
YSZ: I now understand why we are in the current state. We should probably align our limits, e.g., with ICU4X.
FYT: the string format has the same format as numbers, e.g., infinity. Current implementations treat very large values as infinity, even if not explicitly declared. Precision beyond some large limit exists, but behavior is not well defined. Currently, beyond a certain value is treated as infinity. Should we pick a reasonable value for practically limited values. Do we really need a 64-bit value for the exponent?
SFC: Re: existing limits, maximum significant digits is set to 21, rather low. But fractional digits have a higher boundary. Has a couple of examples showing where limitations have impact.
FYT: First, the string format is the same as the grammar of Number. The grammar can express an Infinity value. But in 262, once you reach a very large number, it treats the value as infinity.
The second thing is that whenever the value gets too large, we have this MAX_SAFE_INTEGER value which says that the precision beyond it is not very accurate. It’s still usable though. In some ways, we have precedence in 262 for this. We may choose not to throw, but it’ll definitely cause some unex pected side-effects. They have different effect when they’re beyond that value , current proposal already has a minimum/maximum value
We need to think about wether it’s even needed to have that power. Let’s say I use a 64-bit integer to store it but there’s always a limit. Should we pick a reasonable boundary then? If we have no use-cases for something as big as a 64-bit exponent, why bother going that far since you have that limit anyway.
SFC: Regarding existing limits, the max significant digits is set at a very low number (21), but fractional digits have a larger limit, so you could use that to format large numbers, but not as significant digit formatting. This is why I decided to stick with an integral power of 10. I’ll try to find you an example.
YSZ: I think it makes sense in terms of impl difficulty, for example, for implementing comparison operations, so I understand that it’s some kind of a path for these things and this is just an artificial limitation anyway. The only thing I’d like to ensure is that we have some level of consistency with handling this so we have some reasonable number based on prior-art of 262.
SFC: Found number.prototyp.toExponential as example. More than 100 digits throws and error. Another example is Date ranges, explicitly indicating range +- 9*10^12. Links:
- https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-number.prototype.toexponential
- https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-time-values-and-time-range
So there’s definitely some precedent for this. Actually, this Date example shows how this limit came up. I’ll try to explain my logic. The double type inaccurately represents numbers upto 1.8E308, which means in order to represent a double's exponent, you need something larger than an 8-bit value, which is naturally a 16-bit value. This means the largest exponent supported by ICU4X is 32K. Rounding to nearest power of 10, this gives +/- 10K for exponent. Current proposal is being revised to formally have +/- 10K for exponent values.
Re: number of significant digits, smaller values make it possible to have it be stored in a stack.
RCA: Should this be integrated into the intl mathematical value PR?
SFC: No. I really want to have that PR merged as-is to make progress. This would be a normative change on top of that PR.
FYT: want to express support for exponent values +/- 10K. Not sure about significant digits range.
Given a string, may possibly convert to integer type. If there’s a magical way to convert to integer type? This would need 333 bits in an integer.
SFC: For stack allocation, rule of thumb is about 500 bytes to prevent overflow.
FYT: You will have 45 bytes of… I agree. You may choose to do it this way. It’s limited, not infinite.
It’ll be tricky how to check. If you set a limit on the number of digits. If your spec would like to do that, then you’d need an adding algorithm. It is necessary to write methods to check whatever limits are set, This may be very complicated. Need to parse the string, finding the decimal point. The algorithm will be more complicated.
SFC: If… we will just use number semantics for it. ICU4X model uses exponent to store the position of leading zeros using a 16 bit integer.
FYT: We want to impose limits, and need to be able to check.
YSZ: If a string length doesn’t fit …
If we want to put a limit on the exponent, then the length of the string is not enough to verify that. For example, you could pass a string that uses the exponential part of the string, like "1.0E10000", the string is short enough, but it has a significantly large exponent.
We still need to parse the string.
FYT: Sure, but how to check the throwing condition? I see your point, I take my comment back.
SFC: I think we should have a limit on both the exponent and the mantissa, not on just one of them. Do we have a thumbs up on having limits or are we going to treat this as a mathematical value (i.e., with no limits)?
FYT: Additional concept - the Intl value is only an intermediate value, never exposed to the outside. The formatting function has the limitation, but it’s not exposed outside the formatting function.
SFC: Internally, it’s still a mathematical value. Only when we convert from string to mathematical value does this become important. Do people have opinions on no limits vs. ranges?
FYT: This is different from the mathematical value in the other place where it’s passed not in string form but in numeric form. In this case, the only option is to return a string.
SFC: Is everyone in favor? Against? Neutral?
GPT: I am fairly neutral. We should do whatever helps with implementation best. Vaguely in favor though. We can eventually remove the limitation if there is a need.
ZB: +1 to GPT.
LAF: Neutral.
SFC: GPT’s point is important that we can always remove the limit later but we cannot impose the limit later.
FYT: We cannot lower it either.
SFC: Let’s wait to see use-cases where a double doesn’t suffice. There’s two use cases that motivated the current features: scientific calculators and currencies. There can be amounts of currencies that doubles cannot represent.
USA: Many astronomical calculations may exceed the limits of a double.
SFC: Recording consensus that we add limits rather than unlimited.
OK to add limits. SFC to follow up with a specific PR.
tc39/proposal-intl-numberformat-v3#97
YSZ: THe problem is that when max and min fraction digits are different, an error is thrown with roundingIncrement. What do we think about
FYT: it’s very difficult for the user to figure out how to use this.
SFC: We already have an example of setting min/max to different values in some cases. One way to fix this is to set min/max to zero since default is zero.
FYT: If we set it to zero, it’ll fix it?
SFC: That fixes the issue where the roundingIncrement is set by itself.
An additional change is possible. If only one is set, then the other will be set to the same value when rounding. However, I’m not sure if I like that change because it doesn’t feel future-proof. Not sure if we want to always require minimumFractionDigits to be maximumFractionDigits on increment rounding.
FYT: Please type all the options in so we can check out how they look.
SFC: Here are the options I see:
- Keep status quo
- Throws on
{ roundingIncrement: 100 }
- Throws on
- If roundingIncrement is present, set mxfdDefault to mnfdDefault
- Will not throw on
{ roundingIncrement: 1000 } - Will throw on
{ roundingIncrement: 1000, maximumFractionDigits: 2 } - Will throw on
{ roundingIncrement: 1000, minimumFractionDigits: 2 }
- Will not throw on
- If roundingIncrement is present, and only one of maximumFractionDigits and minimumFractionDigits is present, set the other to be the same value
- Will not throw in either case
RGN: Why is this impossible to recover from? It’s up to the spec to provide useful information
FYT: We don’t specify an error message in the spec.
RGN: Just wanted to know if I understand the problem. So it’s all about ergonomics. When roundingIncrement is provided without fractionalDigits.
CCN: We have three options.
FYT: May I suggest an additional statement on all three options that they all throw with a minimum.
SFC: Votes for option 2 because the constraint may be relaxed in the future. The only reason for the constraint is an existing implementation, not theoretical limit.
EAO: It’s possible to go from opt 2 to opt 3, right? If so, then it’s a sensible step to take.
FYT: +1 on Option 2. In general, this will not be surprising behavior to users. If nothing is specified, current behavior is too surprising.
USA: I'm also in favor of Option 2.
YSZ: I'm also in favor of option 2. When the other option is specified, user have more context about it.
Move forward with option 2 as stated above.
tc39/proposal-intl-duration-format#92 tc39/proposal-intl-duration-format#96
USA: This is regarding intl duration formation (originally PR #92). #92 was intended to be unrelated. However, Jordan reailzed that it was referencing the Temporal Spec, which was unexpected by that group. This introduced a dependency on a S3 spec. I tried to copy over the parts from Temporal.
However, it’s going to be very difficult to implement this in a pre-Temporal world. There’s effectdively a chain of references that need to be implemented.
We can recognize the dependency explicitly. However, it requires lots of work that is effectively large parts of Temporal.
Does this match with what implementers think about this? Is it possible to ship DurationFormat without Temporal?
YSZ: I'm currently looking into the Intl.DurationFormat spec.
USA: It borrows some AOs from Temporal.Duration, specifically the one that coerces a string or object into a Temporal.Duration record. This AO comes from Temporal. If we want to decouple the two proposals, we can change the proposal to only work for duration objects. But if there is no possible way, then there's nothing to debate.
YSZ: Currently, Intl.DurationFormat takes a Temporal.Duration, so if Temporal.Duration is not introduced when Intl.DurationFormat is introduced, what would the argument be?
SFC: There are two parts of dependency: (a) the coercion to a Temporal.Duration and (b) arithmetic. It’s not intended to be difficult to decouple these. Durations options bag can be passed in, which doesn’t require Temporal implementation. Later, after implementing Temporal, additional options can be added.
If we are using arithmetic, it may be harder to do this before Temporal is available.
USA: ToDurationRecord is an example of the problem. It needs the ability to parse a Duration string, requiring the entire grammar.
FYT: Current will not require parsing string form. But, if we require this parsing, then there’s no way to ship the implementation without Temporal.
USA: The original intent was to be decoupled. PR#92 was merged 28 days ago. That was assuming that the fields could zeroed out. But there’s a problem with the BUILD - stuck?
FYT: CUrrently Duration is S3, Temporal is S3. They depend on each other (Ch. 15 of Temporal). Should we merge these? We already have a big piece of Temporal implemented now that we support string, now that we need the grammar. Now we need a parser to move forward.
USA: Let me clarify there is 3 ways forward
- DurationFormat it’s very difficult to implement without temporal - and will be shipped after temporal
- If temporal can ship a duration formatter that way would be more independent from Temporal
- We don’t want to do this, and we really want to ship DurationFormat before Temporal, with only option bags. This works.
SFC: It the only dependency is on input type, then we should decouple them. That’s easy and can be done. The thing really concerning is the editor’s note re: question about doing arithmetic - expects Yes or No as answers. The specification doesn’t indicate this.
USA: There should be text answering this - looking at DurationFormat spec.
SFC: Looking at the editor’s note, it looks like “Yes, we want to support largest/smallest unit.” Can we make the spec reflect what’s recorded on GitHub?
USA: Will review issues again and will update Spec text to be consistent.
SFC: If there’s arithmetic, keep decoupling. If no arithmetic, then these should be merged. I’m not drawing the line at inputs because that’s easy to solve. There’s a table on the arguments accepted. Duration will not take string form unless Temporal is already available.
FYT: without string form supported, agree that these can be separate.
SFC: Who were the S3 reviewers on this? There seem to be holes that should have been handled at S2. Handling these at S3 breaks the process because the linkage wasn’t resolved in the promotion from S2 to S3.
FYT: Still somehow DF progressed to S3 but should not have before resolving exact AOs (dependencies). Missing that means that it’s not clear at S3.
USA: Was not aware that there should not be such dependencies between two S3 proposals. Reviewer’s did not flag it.
FYT: Temporal group has added a lot of editorial notes.
USA: After a lot of research, we realized that options were needed, e.g., style. This made common use cases easy, and also made other combinations doable.
SFC: Is removing the editorial note OK?
USA: Will keep this “pre-Temporal” as a separate proposal.
FTY: What do we need to do to DurationFormat to keep these separate? Do
SFC: Want’s to flip dependencies around, making Temporal dependent on DurationFormat.
USA: Will remove DF’s abstraction reference, making it independent. Later, it will be easy to add string processing, etc., by referring to Temporal.
RGN: Temporal includes changes in 262 and 402.
SFC: Temporal will also require that DF will accept Temporal objects.
FYT: Make DF independent of Temporal.
USA: Will update DF with a normative change to do that, then will set up discussion.
EAO: Would it be possible to split the proposal into two Stage 3 proposals, one independent and one with dependencies?
SFC: Perhaps; let's decide on the exact mechanism later. Do we have agreement on the principle of decoupling Intl.DurationFormat from Temporal?
RCA: +1
LAF: +1
YSZ: +1
Decouple the two proposals. Exact mechanism to be discussed.