- Shane Carr - Google i18n (SFC), Co-Moderator
- Eemeli Aro - OpenJSF (EAO)
- Richard Gibson - OpenJS Foundation (RGN)
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Greg Tatum - Mozilla (GPT)
- Craig Cornelius - Google i18n (CCN)
- Yusuke Suzuki - Apple (YSZ)
- Zibi Braniecki - Mozilla (ZB)
- Corey Roy - Salesforce (CJR)
- Leo Balter - Salesforce (LEO)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
RCA: We did a Q&A Session where some questions were presented/asked in order to simplify the understanding of all MFWG and help unblock the Data Model progress. We are quite happy with the final outcome but we don't have a conclusive answer yet. We will continue the next Extended and Plenary meetings working on that to have the final decision soon.
Sharing documents:
EAO: We still have two proposals for the data model, but we are getting a better understanding overall of the differences and progress. The two documents are presenting the same thing, one by Mihai and one by me, describing the differences between the models.
RCA: I still have to update the existing Pull request as soon as possible to unblock all documentation regarding this proposal.
FYT: It's a basic thing. Most of ECMA-402 have notes about extensions that are unsupported. But somehow "cf" was not included. So I added a note that "cf" is not supported.
USA via issue thread: How do we handle the list of extension keywords getting longer over time as the BCP 47 standardization process moves ahead?
RGN: I think we can probably address this as Unicode moves forward. I don't think there's anything actionable right now. I think it would be nice to have a plan, but it's low urgency.
SFC: I think it would be useful to have a systematic approach for keeping ECMA-402 in sync with UTS 35. We had a similar discussion a few months ago for numbering systems. I suggest the editors and specifically Ujjwal make a plan for this offline.
FYT: Yeah, this tag was added in 2015. We should have a meta question and take a stand.
Editors to make an action plan.
tc39/proposal-intl-numberformat-v3#46
SFC: (explains issue)
RGN: How does this affect nickel rounding left of the decimal separator?
SFC: With maximumFractionDigits: 0 and roundingIncrement greater than 10, e.g. 50 or 500.
ZB: How does this handle cases when either fraction or significant digits could be used?
SFC: My intent is that the exception happens in the constructor any time significant digits rounding could be used, which is either if significant digits are present, or if rounding priority is used.
ZB: My concern is if one number among the many provided to an instantiated formatter will have issues.
SFC: It's intended to only be based on the other options in the options bag.
EAO: It would be surprising if roundingIncrement would start throwing an exception rather than being part of the priority fallback.
SFC: roundingIncrement is a new option, so there are no new exceptions on pre-existing code. The only way to get the exception is to add roundingIncrement to your code.
Accepted.
tc39/proposal-intl-numberformat-v3#34
SFC: (explains issue)
JSW: The limit relates to memory consumption, but doesn't it also relate to IEEE?
SFC: I think the limit of 20 was chosen because that is sufficient for all IEEE doubles. But now that we support arbitrary precision input, perhaps that could be a case to raise the limit if we wanted to.
RGN: ???
ZB: I also don't feel convinced.
RGN: How precise can we get in 262?
SFC: In Number.prototype.toFixed?
RGN: We should be as capable as 262, but going beyond is not necessary. Looks like 100: https://tc39.es/ecma262/#sec-number.prototype.tofixed
JSW: I'd say raise it to 100 then. Be consistent.
SFC: I have a slight preference to keep it at 100 for supporting portable code, but would also be fine with raising it to 100.
FYT: Should we do this as a separate PR for this? This is kind-of a new addition to the NFv3 proposal. I just hesitate to snowball it into this proposal.
SFC: I kind-of agree with FYT.
JSW: +1
RGN: Same.
SFC: Let’s migrate it to 402 and track it there.
Migrate the issue to 402.
tc39/proposal-intl-numberformat-v3#33
SFC: (introduces issue)
FYT: I have some concerns about this feature. The use cases are nickel rounding and dime rounding. But should we also support quarter rounding? The second thing is that you could support multiple digits. What's the need beyond dime rounding?
SFC: First point: we could support quarter rounding. That would be fine. Second point: we want to support rounding to the nearest 500, e.g., "turn left in 500 meters."
FYT: My preference is we only support the increments we know we need for specific use cases.
SFC: We could have a smaller list of multiples less than 10k and add in some quarters: « 1, 5, 10, 25, 50, 100, 250, 500, 1000, 2500, 5000 »
EAO: Why is this arbitrarily limited?
SFC: It’s much easier with factors of powers of 10... rounding to e.g. the nearest 7 would have an unclear reference point. ICU supports arbitrary rounding, but I haven’t seen a realistic use case.
EAO: I recently needed to round to a multiple of 20. But the periodicity constraint makes sense to me.
SFC: What is your use case for rounding to the nearest 20?
EAO: I was anonymizing monthly salary data.
ZB: What would have been worse if you had rounded to 50 rather than 20?
EAO: The difference between actual value and rounded value would have been too big for numbers that were e.g. almost 100.
FTY: I could also see using 20, but 25 might be close enough.
EAO: But there is benefit in the last number always being zero to communicate precision.
SFC: I propose then that we accept « 1, 2, 5, 10, 20, 25, 50, 100, 200, 250, 500, 1000, 2000, 2500, 5000 » as Number.
FYT: I second that.
JSW: In a lot of the normal ES functions, there's a requirement that you don't mix numbers and BigInt. Actually, never mind. (Formatter and number to format are specified at different times, doesn’t seem necessary to align them.)
Use SFC's recommendation above.
tc39/proposal-intl-numberformat-v3#32
SFC: (discusses issue)
RGN: Seems good to me.
Merge the PR.
SFC: This has been a long time coming. I feel I have resolved everyone's concerns.
RGN: Editorial issues aside, I support it.
FYT: I've prototyped this in V8. I feel it is in good shape, and I support it.
ZB: Sounds good to me based on what I've seen. But we'll get more feedback when we try to implement it. Do we have a prototype of the implementation?
JSW: I don't believe so right now.
GPT: I don't have thoughts right now.
FYT: I think it would be valuable before TC39 for Anba to take a look as well.
YSZ: Internally we talked about this and we are okay moving it to Stage 3.
TC39-TG2 approval for Stage 3.
SFC: (introduces issue)
RGN: Definitely in favor of specifying it. No strong opinion about which order.
FYT: What's the benefit of specifying the order?
JSW: I assume it's one more step of removing implementation dependence.
RGN: I prefer to reduce undefined behavior.
ZB: I believe the problem here, and the reason it's worth discussing, is that it is an example of a kind, that could set precedence. The fact that this is at all sorted is an artifact of JS. It's completely meaningless. This is a set of options. There is no order to it, except that we happen to be returning a data structure that has an order. It's like saying that we are sorting a list of names. If we were to sort it, though, and since arrays have a sort order, we may as well sort it. I don't like using the English alphabet to sort these strings; it's a very Westernized way of thinking. But what I'm most concerned about is the slippery slope of adding precedent.
FYT: From an implementation point of view, any sort order requirement means I need to sort it. Which means I need to spend CPU cycles. So I agree with ZB. If there's a strong benefit, it seems like a good thing to do, but if there's no benefit, we just waste power and contribute to global warming.
RGN: The benefit is that implementations behave the same way and can be relied upon to do so. I'm coming from the perspective that we should specify everything and leave implementation-defined only what it specifically makes sense to leave unconstrained.
JSW: +1 to specifying everything.
SFC: Three points. (1) Sorting lexicographically allows for efficient operations such as binary search. (2) Identifiers are romanized; that's what we've decided consistently (shares some examples), so this is not a new Western bias. (3) Code in the ecosystem could rely on certain behaviors, like web reality returning these in alphabetical order, and we should specify these behaviors rather than leave them unspecified and potentially breaking userland code.
EAO: I agree that this is a set, and cannot come up with a scenario where order matters. I would be in favor of explicitly leaving this implementation-defined.
ZB: There is a risk of misleading users. The category "one" may or may not contain the number 1. The use case I imagine is a localization GUI in which options are presented in order.
JSW: Binary search on so few items is probably slower than searching linearly.
SFC: Acknowledged; my point about sorted order is more about the precedent setting "slippery slope" argument.
JSW: We generally try to specify behavior because people rely on this behavior, and we've learned the hard way that we can't change that behavior later.
FYT: Is there really a UTS 35 order? Here's the thing. Someone argued that someone may depend on the order. If they depend on the order, they depend on the web reality order, and that order is not the same as UTS 35 or lexicographic order. So specifying an order different than web reality is not productive.
EAO: If we are to pick an order, I'm very strongly in favor of the UTS 35 order, because it's an order where I can see use cases, like the drop-down menus and other cases Zibi listed.
FYT: But do you think that's strong enough to break web reality?
EAO: Do we have any examples of code that relies on the order?
FYT: We have to assume that there are people who depend on it.
SFC: The more this conversation goes on, the more I'm convinced that we should do lexicographic ordering. In fact, ZB's point that one shouldn't assume that one contains 1 and so forth is a stronger augment that we specifically shouldn't build that order in to the API.
ZB: (1), Frank stated that if we aim to specify the order, that means that someone depends or will depend on it. That's false implication. Richard stated that he’d like us to specify the order irrelevant of if anyone depends or will depend on it. (2), I could claim that no one in the world depends on this order.
SFC: The web is huge, and it is very likely that one of its billions of pages does in fact depend on current order.
EAO: Worth noting that the polyfill for Intl.PluralRules returns the UTS 35 order, as it uses make-plural as its data source for the plural categories, which in turn are drawn from CLDR data.
No conclusion. Share the notes above and allow the issue champion to work them out.
CJR: There are some inconsistencies between Safari and Chrome for weekday: "short".
ZB: This is not an error; it specifically says you shouldn't accept a specific localized string output.
SFC: For data inconsistency issues like this, you should look directly into CLDR. If it is a bug, it is a CLDR bug, not a 402 bug.
CJR: There are issues here about product devs wanting uniformity, and these inconsistencies introduce challenges for adoption.
CJR: For locale "ar", different browsers have different numbering system defaults.
SFC: I'll give some context on the nature of this inconsistency. The industry standard is to use arabic digits. But Google made its own decision to use Latin digits. That's a Google issue, not an industry issue.
FYT: I echo what SFC said, but will also say that if someone uses a specific country, like ar-EG, then you get the arabic numerals again.
ZB: This is a good example of how you really can't rely on these strings. Languages evolve. And that just needs to be part of what teams adopting Intl need to consider.
LEO: I agree, but I also express the desire to obtain some consistency.
CJR: Language evolves, which is why CLDR gets updated twice per year. But I think it's reasonable to say that there is a consistent experience across browsers that use that same data set. But generally speaking, they should be generally in sync. There's a choice devs make between solving things via Intl or using a third-party library like Globalize. If there's an observable mess of inconsistent behavior that Intl provides, but a third-party behavior is consistent, then devs will choose the consistency. They don't like to take that risk. But at the end of the day, maybe we could add some tips to the spec to say that if devs want more consistency, they can be explicit
SFC: (1), having a handbook for devs who want consistency is a good thing. That could go perhaps in section 2 of the spec doc, or in a separate markdown file in the repo. (2), data inconsistency is a real problem for adoption. I've seen that issue for Google clients adopting Intl as well. I consider issue #210 to be the holy grail; it allows apps to provide data overlays to add more consistency. It's still a ways off, but some of the underlying infrastructure like ICU4X helps lead us in that direction.
JSW: The spec’s Annex A mentions a whole bunch of things that are unspecified -- including supported numbering systems and the format patterns for formatting numbers. https://tc39.es/ecma402/#annex-implementation-dependent-behaviour Given that formatting choices can change over time, particularly within regions as governments change, it seems unavoidable.
FYT: ???
CJR: So ideally we want a consistent behavior across browsers, and then people can alter that baseline as they need for those use cases.
ZB: Intl is inherently a long tail. There are a million web sites, and each web site has a different pet peeve. Finding the best layer of abstraction for uniform behavior is hard. Because although you care about numbering system behavior, some people will care about consistent calendar systems, etc. There are just millions of data points in the matrix. I'd say that the direction we need to take is specifically saying that we can't be uniform, and UX designers need to make their UX flexible around that, which is good practice anyway.
FYT: I think the issue Corey brought up is a good one; I just don't know what the way is to solve it. You always have this problem, even if it is a browser update. Some browsers might use ICU 68, and others ICU 69. That could be different, event if server-side.
SFC: (1) languages evolve. (2) data is consistent within the device. (3) data size.
CJR: I would like to be involved in the effort for a consistency handbook. I think it's important, even more so for companies that don't have a lot of resources for internationalization testing.
FYT: There were two main concerns at the last meeting. (1), use cases, and (2), iterator versus array. I changed the iterator to array, and I am updating slides with the use cases. So I would like to ask for stage 3.
SFC: We've been working on this proposal for a long time. I think we've done a good job addressing everyone's concerns. So I support this for stage 3.
LEO: You should sync offline with Jordan Harband.
ZB: We reached a conclusion not to block. We do not believe this proposal is useful, but we're not going to block.
YSZ: We are okay moving this to Stage 3. We prefer to have stronger motivation, but in terms of fingerprinting, that concern is resolved. And in Apple, we're already shipping the entire payload, so it's okay.
Proceed with Stage 3 at TC39.