Attendees:
- Eemeli Aro - OpenJSF (EAO)
- Felipe Balbontin - Google i18n (FBN)
- Zibi Braniecki - Mozilla (ZB)
- Shane Carr - Google i18n (SFC), Co-Moderator
- Philip Chimento - Igalia (PFC)
- Richard Gibson - OpenJS Foundation (RGN)
- Justin Grant - Invited Expert for Temporal (JGT)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
SFC: See the slides: https://docs.google.com/presentation/d/1nEnkIu4BpS9S-_K4WR-glfgB9sbjWEP9DeUXuKnrkkQ/edit. USA and I recorded a video that will be played at the conference followed by a Q&A.
DateTimeFormat.prototype.resolveOptions may show fewer resolved options than present in formatted range #22
tc39/proposal-intl-DateTimeFormat-formatRange#22
FBN: I'd like to discuss my comment from Aug 11. There are two issues listed there:
- Should the resolved options contain the additional date-time fields used when formatting a date range?
- There is no way for the user to determine upfront which fields are going to be displayed in the formatted string.
SFC: I think the main purpose of resolvedOptions is to roundtrip. It might not give complete information.
JSW: I'm not sure we have a cohesive vision of resolvedOptions, but roundtripping sounds like the thing we should shoot for. If you want to get the options for a specific formatted string, that should be an extra API.
SFC: We could add it as another field to the object returned by formatToParts.
FBN: I will create a follow-up issue in the 402 repo to gather feedback.
SFC: On the second issue, I think we should stick with current behavior. We are formatting a range between JavaScript Dates, which are timestamps. If we want to drop fields, we can format a range of Temporal.Times. We can figure out the semantics for this in the Temporal proposal.
tc39/proposal-intl-DateTimeFormat-formatRange#19
FBN: I think the behavior is unexpected. We should not allow it.
SFC: We should either update the spec to allow it, or add Test262 to assert the behavior and mark implementations as non-conformant.
ZB: I'm concerned when we are unnecessarily strict with output. One option is that we should only require that the strings are human-readable; further restrictions on that output is outside the scope of 402. Alternatively, if we feel that the desired behavior in issue 19, we should make sure the spec says so: formatRange should call format if the dates are the same.
FBN: That's what the spec does already, but it's tricky on the ICU side.
FYT: I don't think what ZB said is enough. If two dates are exactly the same, you can call format(). But if the DateTimeFormat is set up to format a range of hours, in the implementation, you can't check ahead of time that the two dates are the same, because the minutes and seconds are dropped.
SFC: What is the current spec behavior exactly?
FBN: It checks for date equality after the fields are computed.
SFC: I think we should keep the spec the same then, and just make Test262 to assert the behavior.
ZB: Sounds good
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
ZB: It's okay that we don't have these implemented. We will catch up.
FYT: Do we have consensus on #471?
(several thumbs-up and no objections)
FYT: How about #459?
(several thumbs-up and no objections)
FYT: How about #347?
(several thumbs-up and no objections)
tc39/proposal-intl-DateTimeFormat-formatRange#28
FBN: Given the conclusion above, I will do the spec update.
FYT: We should have instructions for proposal champions to do the MDN work themselves.
SFC: RCA has largely done this work. We have https://github.com/tc39/ecma402-mdn to track. I'll follow up offline.
RGN: I will review them and push the button when I'm able.
tc39/proposal-intl-numberformat-v3#3
JSW: Some prior art is hour12 versus hourCycle.
JGT: Having an option take either a boolean or a string is weird.
ZB: We went with something else on hour12 because the name clearly didn't allow other options. The difference here is that useGrouping is not a very bad name. You can squint and say useGrouping: "min2" is a perfectly valid API. I don't know how often duck typing is used in similar APIs; is there prior art?
JSW: I don't have a strong opinion on which approach to take.
EAO: I like SFC's approach. Do we support ICU ON_ALIGNED?
SFC: Yes; it's called "always".
EAO: I find it nice for non-strings to map to strings in documentation.
SFC: How about false?
EAO: If false needs to be false for backwards compatibility, that's okay.
JSW: If false has to be the odd one out (that is, the only one with no string equivalent like “never”), so be it.
EAO: Can we just return the same value that the user provided?
FYT: Internally, there are only 4 values stored internally. So resolvedOptions should reflect the internal resolved option.
SFC: Is everyone okay with returning false and the three strings?
(consensus)
JGT: Is this a pattern that we would want to duplicate somewhere else?
JSW: I think we would probably use all strings if designing this from scratch.
FYT: +1
SFC: I think it's a nice pattern to use in general. Making the absence of something indicated by a falsy value, and the presence indicated by a truthy value, feels JavaScripty to me.
JGT: I think it's weird that undefined does not mean false.
RGN: I don't think we should commit to a position that this generalizes out of ECMA-402. It might work, but doing it in 402 is at most weak evidence that it should be done in 262.
tc39/proposal-intl-numberformat-v3#12
JSW: I think it's perfectly reasonable for infinity to participate in ranges. As far as "5+" or "≥5", that should be its own option; it shouldn't be conflated with formatRange.
FYT: I think ranges with infinities could be seen in mathematical formulas. So I don't think there's a reason we should disallow it.
tc39/proposal-intl-numberformat-v3#16
EAO: Definitely yes.
JSW: The data is in CLDR; see https://unicode.org/reports/tr35/tr35-numbers.html#Plural_Ranges
USA: +1
tc39/proposal-intl-numberformat-v3#11
SFC: I think formatRange should throw a RangeError upon encountering a negative value.
RGN: I would find that very surprising.
JSW: What about temperatures?
RGN: And uncertainty ranges, e.g. ±1 meter
JSW: This is undefined in CLDR: https://unicode.org/reports/tr35/tr35-numbers.html#Plural_Ranges
FYT: If this is undefined in CLDR, then we should push for it to be fixed. Negative numbers should be supported.
RGN: Because it is backwards-compatible to relax errors, we could ship with a RangeError and fix it later—not that doing so is necessarily the best strategy
EAO: CLDR doesn't specify plural forms for single negative numbers either. So it would be no worse with negative plural ranges.
FYT: You believe that currently, a negative range will be formatted correctly but selectPlural output may not be correct?
SFC: Formatting ranges with negative numbers is not currently well-specified, but ICU behavior is pretty much as expected.
SFC: Data from translators tends to use only positive numbers, and the spec implicitly assumes that. There’s an open ticket on CLDR to improve the specification, currently assigned to me. But I think ICU behavior is good enough to move forward with.
EAO: And we’re already doing that exact thing with PluralRules.
tc39/proposal-intl-numberformat-v3#13
SFC: Given the decision on #11, I think my preference switches to option 1 (always obey signDisplay)
FYT: What would it look like when formatting e.g. -50 to -20?
SFC: The same as without signDisplay.
EAO: I would expect -50 – -20.
EAO: If one has a sign, I would expect both to have a sign.
SFC: I’ll come back next time with a new design.
SFC: Blocked on #442
FYT: This is marked draft, which is appropriate. It cannot be merged right now.
SFC: Does someone want to champion this? If not, we can close it now.
ZB: Is there an associated issue?
SFC: #402
ZB: Then let’s close the PR and keep the issue open.
SFC: Ok. #402 in the ES2021 milestone.
FYT: I don't know whether this change is warranted or not.
JSW: It makes sense to me. Also, ABL was doing similar work in this area.
SFC: Let’s discuss more next month, and try to get the author to join us.
ZB: (discusses issue)
SFC: Additions need a clear and compelling use case with stakeholders, a solution (ECMA-402 doesn’t invent i18n, it just exposes it), and be difficult to implement in userland.
ZB: Is it enough if there are multiple stakeholders? Backtracking on API design decisions can be extremely painful—cf. hour12 and useGrouping.
FYT: Other organizations encounter similar problems, e.g. C++20 includes STL additions and the Unicode Consortium considers new encodings. Can we borrow strategy from elsewhere?
SFC: Unicode is decided by stakeholder demand for e.g. new measurement units in CLDR. Companies request a feature and provide the resources to implement it.
ZB: I agree with FYT that we should look at what other standards groups do. Maybe WebAssembly, DOM, WebAudio, WebGL, HTML, etc.
SFC: TC39 is also largely stakeholder-based. Someone proposes a feature, and the feature gets adopted as long as no-one (e.g. implementers) object to it.
ZB: Is there an example from other groups where some APIs carry (large) payloads?
FYT: I agree about payload.
SFC: Who wants to do this research and report back here?
SFC: I don’t think we should adopt any new features before answering this question. I’m assigning to USA.