Attendees:
- Shane Carr - Google i18n (SFC), Co-Moderator
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Richard Gibson - OpenJS Foundation (RGN)
- Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
- Zibi Braniecki - Mozilla (ZB)
- Leo Balter - Salesforce (LEO)
- Daniel Minor - Mozilla (DLM)
- Greg Tatum - Mozilla (GPT)
- Eemeli Aro - OpenJSF (EAO)
- Long Ho - Invited Expert (LHO)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Michael Saboff - Apple (MLS)
- Sergey Rubanov - Invited Expert (SRV)
- Justin Grant - Invited Expert for Temporal (JGT)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
LEO: I've been speaking with USA, and I would like to invite USA to the editorship group of ECMA-402.
USA: Thank you! I'd be happy to help with this.
SFC: This has been a long time coming and I am looking forward to having Ujjwal on the editorship group.
LEO: The ECMA bylaws require a quick vote, let’s do a quick roll-call.
FYT: Just to confirm, are we just talking about adding USA and not removing any existing editors?
LEO: to be fair, I have less time to work on things lately, but let’s keep this discussion separate.
SFC: Let’s take the votes:
- Google: yes
- Igalia: yes
- OpenJS Foundation: yes
- Mozilla: yes
- Salesforce: yes
- Apple: yes
Approved. Welcome, Ujjwal!
RCA: increased the number of meetings in order to accelerate progress and decision making. Prioritizing certain features to test different data models in order to finalize decisions and unify the final two positions. Once we have unified into a single solution, we can start working. EAO and ZB did a great job on that. Things are moving forward!
LEO: Still working on #561. This is one of the most annoying parts of editorship because printing this document into a PDF is really messy. TC39 is now hiring external experts in order to deal with this. I still have this as my top priority and I’m working on it.
FYT: there are more tables that might have a problem this year. Let’s make sure all the tables are taken care of.
LEO: we have problems all over, none of the browsers are perfect at doing this. There are system-related issues when printing HTML to PDF.
USA: I'm not sure if this PR is editorial or normative.
LEO: It's complicated to add normative changes at this point; otherwise ECMA GA may not be happy with it.
USA: There is no noticeable change within the spec, because the algorithm is not specified.
USA: Oh, I didn't mean to discuss this in the context of ES 2021.
RGN: I think it is normative. It is updating the _opt_ spec variable in a way that provides additional input to the spec function that receives it.
SFC: I agree.
FYT: I don't understand why this is a normative PR. There are two paths that receive this option: one doesn't read it, and the other is implementation-defined. So there's no observable change.
RGN: There are. Look straight from the text of the specification. Right now, there is no path that connects hourCycle to input of BestFitFormatMatcher. This change introduces that path. "Implementation-defined" is still dependent on the inputs that it receives.
LHO: There are 2 algorithms for skeleton matching. In format.js, when we read from CLDR, we treat both the 12-hour and the 24-hour patterns with equal weight. But with this change we can treat the two with different weight.
SFC: Why is this necessary given that _bestFormat_ already contains two fields, [[pattern]] and [[pattern12]]?
LHO: The hour cycle can affect the consent of the pattern, like certain strings appearing in the 24-hour version versus the 12-hour version.
FYT: I am in support of this, this just adds additional information and for the specified text, there is no observable change.
RGN: That’s not precisely true.
SFC: Should we take it offline?
FYT: The discussion here doesn’t affect the result anyway.
- PR is Normative.
- It was mistakenly discussed during this section, it has nothing to do with ES 2021.
SFC: It's a bug that got introduced in ES2020. It has to do with significant digits rounding.
LEO: We need to make clear that this is a spec bug to people who are present at ECMA GA. So I'm skeptical, because otherwise this needs to go through the opt-out period for the spec freeze. The consequence is that it could cause ES 2021 to be punted to December.
FYT: I'd suggest we get it into trunk and don't do ES 2021. And we probably have other bugs we haven't discovered.
Don't include in ES2021.
FYT: We need Test262 support for Intl Locale Info. The V8 impl is checked in.
USA: I intend to work on this.
FYT: And anyone to take MDN?
SFC: If I go to the tracking page, V8 impl was discussed. MDN and tests are the two big things, alongside polyfill. LHO generally takes on the polyfill part, but we should discuss the other tasks. Segmenter is missing MDN docs, so any help on that would be higher priority.
RCA: Intl.Segmenter is started. For Intl Locale Info, I can create an issue and a skeleton.
tc39/proposal-intl-displaynames-v2#2
FYT: I tried to advance this to Stage 3 last month, but we got stuck on use cases for units.
MLS: I don’t recall Apple requesting that.
SFC: pulls up demonstration linked below here, this example demonstrates how unit names are relevant.
https://www.nhlbi.nih.gov/health/educational/lose_wt/BMI/bmicalc.htm
FYT: I think the specific question we should ask is: which of the members would find this useful?
SFC: pulls the Google unit conversion tool it would be useful here for Google.
https://www.google.com/search?q=convert+meter+to+feet
RGN: what is interesting here is that the Google tool doesn’t use plural forms, I wonder why that is the case? Will you switch once this is shipped?
SFC: We’ve been working with the team which builds this to integrate ICU/CLDR better.
ZB: It is very costly and we don’t seem to have too many use cases here. This data scales for every unit… multiple lengths for multiple units for multiple locales. So the cost is high. And it seems it's not hard to just ship the strings in the translation bundle.
SFC: As a Googler, I was just pointing out how this data is useful to us, by no means do I intend to push this feature through if only we need it.
RCA: So there are two concerns: the size, and the possible use cases. For size, what ZB said is clear. For use cases, I haven't seen too many beyond the Google use case.
FYT: If there are no strong advocates, should we remove it from the spec?
SFC: The problem ZB said for display names is true for all types of display names, not just units.
ZB: I agree with that, we should be careful about the expansion of the payload sizes.
RCA: I wanted to second that.
SFC: Let’s remove this feature before moving to Stage 3.
Remove unit display names.
tc39/proposal-intl-displaynames-v2#30
FYT: presents issue. Doesn’t have prior art, can we hold this and not add it during this stage.
SFC: +1
USA: This suggestion came out of efforts to provide more completeness, which is not something we care as much about. It comes at the cost of payload size, without clear use cases. Once we have sufficient use cases for it, we could consider it.
ZB: Anba did not ask for the addition of "menu". He asked whether it should be supported. Anba serves the role of evaluating the spec against the implementations.
SFC: talking about the use cases with Apple folks, the menu option allows an alphabetically sorted list, perhaps in a selection dropdown, and they find it really useful and would switch to it by default. We should wait for prior art here, and then consider switching to this form as the default form.
ZB: It makes sense that this is an implementation concern about whether they want to return the menu form or the standard form.
LAF: +1
Excluded from the current proposal.
tc39/proposal-intl-displaynames-v2#31
SFC: I support the new form.
LAF: Yes, languageDisplay.
RGN: makes sense for me as well.
USA: I support this as well.
JSW: languageDisplay /currencyDisplay is a nice consistency.
Adopt languageDisplay.
USA: +1 from my side.
LAF: +1
RGN: +1
SFC: Can we have a +1 explicitly from Mozilla, after removing “units”? This makes it a much smaller proposal than it originally was.
ZB: Do you have a sense of how the dialects affect the payload?
FYT: In most cases, they are the same. It should be pretty minimal.
ZB: Okay, I'm fine with that.
ZB: One concern is that if we introduce dialect here, then maybe we need to follow that in other fields. Slippery slope?
FYT: Dialect only makes sense for language display names.
ZB: But you could have display names at the beginning of sentence, middle of sentence, …
SFC: That's the display context. There's another issue to track that.
ZB: perfect, they’re different things, got it. I’m happy with this then.
FYT: So I have blessing from Mozilla for Stage 3?
ZB: Correct.
MLS: I don't have a comment on this.
Approved for Stage 3
https://github.com/tc39/proposal-intl-enumeration
FYT: So we've resolved the fingerprinting concerns. There are some open issues, but they are not actionable, except the one from Jordan as part of the Stage 3 review. He suggests using a different object for the Iterator.
tc39/proposal-intl-enumeration#18
SFC: It would be useful if the editors could look at this offline.
ZB: There was some misunderstanding, because when I was reading the notes and discussing with YSV, there was some conflation of our support about privacy with our support of the proposal. We are still uncertain about whether we support the value of this proposal as a whole. I don't think we should be blocking the proposal on vague claims. I'd like to resolve our position before the upcoming TC39 meeting.
SFC: It would be useful to have clear guidance from Mozilla on specific things we can change in the proposal if necessary.
FYT: Will you have a clear answer before the May meeting?
ZB: Yes. But unfortunately not by today.
FYT: I'm happy to abandon this proposal if that's what everyone thinks is best. I just don't want this to hang forever in limbo. So my plan is to add this to the agenda for Stage 3, but if Mozilla has any issues, I would like to remove it from the agenda.
FYT: Do any other companies have feedback on this?
MLS: I need to investigate, but I think this has the same kind of fingerprint concerns as previous enumeration APIs. I'll have to look at this.
FYT: I thought Apple already stated their position on fingerprinting.
ZB: Yes, this is the same proposal that we previously discussed.
ZB: If the main use case are time zone pickers, then is there opportunity to bring synergy between HTML and JS?
MLS: It makes sense, but sounds difficult to coordinate.
SFC: I did raise this concern last month at the TG1 meeting and the conclusion was that JavaScript is a good place to put this logic because it is a good building block. W3C could do this by introducing pickers, but could do that in addition to having the API in ECMAScript.
FYT: +1, because ECMAScript has other cases besides the browser.
ZB: Yes, like in a Nodejs environment.
SFC: From our position, can we seek Stage 3 consensus? We do not have stage advancement authority but we can voice opposition or support here.
ZB: We will come back with our position before the meeting.
MLS: I think we're fine moving forward with it.
RGN: I don't object to moving forward but I haven't reviewed the spec text.
USA: From the Temporal champions side of things, as well as Igalia, we are generally supportive, but we'd like to go through the spec text.
LAF: +1 for Enumeration API.
SFC: It would be fair to suggest that no explicit concerns were raised in the TG2 meeting and the final consensus would be discussed on the plenary.
tc39/proposal-intl-extend-timezonename#7
FYT: the only concern people have is “short wall” and “long wall”. I would like to pick one and stick with it.
USA: From the Temporal perspective, "zone" makes sense because it aligns well with the mental model we have in Temporal, where you either have named time zones or zone offsets. Since we have an option named "offset", it also makes sense to have "zone".
FYT: To be clear, these strings are like "Pacific Time" or "PT" without daylight/standard specifiers.
USA: That makes sense to me, because as a human being living in the Pacific Time time zone, the definition is within your time zone. People usually refer to time zones using this terminology.
RGN: The concept is a locally relevant name for a time zone, short form and long form.
SFC: I like the idea. We could come up with a different key for daylight-type names.
FYT: Those are already “short” and “long”.
SFC: Okay, great, perfect. I support this even more!
RGN: Okay, so taking this example. The identity of the time zone is America/Los_Angeles. The location is Los Angeles. And then we have this additional concept. In the time zone database, I think it is referred to as "abbreviation". But there's nothing formal about that. But I don't like calling it "zone", because the zone is Los Angeles.
USA: but this is still a “time zone”, right?
RGN: yes, but now we have different representations for the time zone.
SFC: there were some other options, with different formats but we chose to exclude them because of payload size creep.
FYT: ECMA-402 previously referred to the time zone. Here, we don't display the zone. So I think shortZone/longZone could be confusing.
JSW: Could we just use "metazone", like SFC mentioned in CLDR? shortMetaZone, longMetaZone.
RGN: I think that doesn't have an ambiguous interpretation.
SFC: I like the metazone suggestion by JSW. It is correct to refer to these strings as the display names of meta zones.
RGN: I could live with C, D, or E, but am least happy with D.
SFC: I don't like C, because I think "shortLocal" should refer to formats like “Los Angeles Time” or “Denver Time”.
RGN: The IANA docs refer to "abbreviation". But that's mostly associated with a template into which a letter is slotted.
JGT: "Friendly name"? They seem to be used for more informal and less precise usage.
EAO: I like "friendly" better than the alternatives.
JSW: I think "shortFriendly" and "longFriendly" are half-baked ideas that sound good once I think about them.
SFC: I don't like "friendly" because these strings have actual use cases besides being friendly. For example, this meeting starts at 10am Pacific Time. It would also be correct to say 10am Los Angeles Time. But it's not correct to say 10am Pacific Standard Time.
USA (?): You could call it "shortNoDST" and "longNoDST".
EAO: "Base"?
SFC: I don't like "DST" because it's very US-centric. Other countries don't call it "DST" or might have other types of variants.
SFC: The word "Generic" is used in CLDR for this as well.
SFC: I do find the concept of "meta zone" to be self-explanatory. "Meta" means a collection of several things.
PFC: +1 generic
MLS: I like *Generic
USA: yeah let's do generic
GPT: +1 generic
JSW: Generic sounds pretty good.
EAO: +1 on generic
MLS: The other option could be "common".
JGT: I just noticed shortBase and longBase and I do like that quite a bit more than generic.
SFC: Should we do a quick poll about this?
Options:
- MetaZone
- Friendly
- Generic
- Base
- Common
Votes:
- SFC: 1 = 3 > 4 = 5 >> 2
- USA: 3 = 5 > 4 > 2 > 1
- GPT: 3 > 1 = 4 = 5 > 2
- JSW: 3 > 2 > 1 > 4 = 5
- EAO: 4 > 3 > 2 = 5 >> 1
- DLM: 1 > 3 > 4 = 5 >> 2
- FYT: 1 > 3 = 5 > 4 >> 2
- JGT: 4 > 5 = 3 = 2 >> 1
- MLS: 5 > 3 > 4=2 > 1
- PFC: 3 > 4 > 5 >> 1 = 2
Notes:
- 1 and 2 appear to the right of a ">>" multiple times; eliminate.
- 3 appears before 4 in 8/10 rankings.
- 3 is equal to 5 in 3/10 and before 5 in 5/10 rankings.
- 3 is the most common first choice, in 5/10 rankings.
- 3 is at least the second-favourite choice in all rankings.
shortGeneric/longGeneric wins.
https://github.com/tc39/proposal-intl-extend-timezonename
SFC: Is everyone now happy with this proposal?
USA: +1
JSW: +1
SFC: I think we should bring this for Stage 3 given that the real advancement happens in the TG1 meeting.
SFC: Does anyone have concerns about this proposal?
USA: This is a great proposal; thanks for the work.
FYT: I'd like to see the spec text.
SFC: Thanks for the feedback; let's follow up offline.
tc39/proposal-intl-duration-format#40
USA: the original proposal by JGT included, alongside hide and show, an option called auto for all three zero fields options. I did not add them yet because of two reasons:
Since the values are set right alongside “style”, there is not a massive benefit
?????
FYT: I have a hard time discussing this, because the spec text does not have any "auto". Are you saying to add an additional value? It's confusing what that really means.
JGT: I think the defaults for the leading should be "hide". For internal should be "hide" for everything except "digital", and the default for trailing is interesting… we could imagine a default where we show, but I'd probably say "hide" for trailing as well.
USA: That basically translates to what we have now, in which case you can only say hide and show. Also, we sometimes throw RangeErrors.
JGT: Are there any styles we want to add in the future that have different defaults?
FYT: I propose we don't add "auto" and that we make the defaults leading="hide", internal="show", trailing="hide".
USA: No, I feel that it is really unlikely that new styles would be added. Also since these fields are included right alongside style and largestUnit and smallestUnit the benefits are greatly diminished.
JGT: FYT raises an interesting question… should "show" be the default for internal? Clearly it should be the default for digital. But if I have a duration that's 2 days and 30 minutes, do I really want to have the 0 hours?
SFC: I think we should be consistent across styles. It would be jarring for internal fields to appear and disappear. So I think we should have internal="show" as the default at all times.
JGT: If I have a duration of 10 years and 2 minutes. Do we show weeks?
USA: This is one of the big reasons why I brought this question. There is no consensus about what the better default should be. There are arguments to be made for any of these. So I think therefore it's hard to come up with a good answer for "auto".
SFC: On the "weeks" issue… we need a way to toggle between 0 weeks and 0 months. For example, "1 year, 0 weeks, and 3 days" versus "1 year, 0 months, and 3 days".
FYT: Is it possible to say "1 year and 200 days" without months or weeks?
JGT: There are two issues. One is SFC's issue. The second is that, if that's allowed somehow, should the default behavior to show internal things, or should the default be to hide them? They are two somewhat separate issues. And I think hiding internal by default is more likely to be a good
SFC: It seems like we keep getting more and more complicated with smallestUnit, largestUnit, and the three types of zeros. So should we revert back to the version where we just have an includelist of units?
USA: Do we at least have consensus on removing "auto" and sticking with either "hide" or "show"?
JGT: The challenge with SFC's suggestion is, how do you format a Temporal.Duration? It sounds heavyweight.
USA: It did work before.
SFC: a whitelist of fields is accepted as an option in the constructor. Those fields are pulled out and displayed.
USA: ???
JGT: To reply to SFC, if you don't supply a list, I think that doesn't work for "digital". And what you said brings us to the default that we should hide what's inside. I like the idea of showing specific fields, but it doesn't solve the other question.
SFC: Digital only really is defined for three forms: hour/minute/second, hour/minute, and minute/second. Those are the only ones in CLDR. So we could require that type="digital" comes with a fields list which is one of those three sets.
FYT: It could also include just the hour, just the minute, and just the second.
JGT: If you're using a digital format, and you have only one unit, then it's just toString on that unit.
FYT: No strong opinions.
JGT: I like the idea of manually specifying the fields, as long as the default hides nonzero fields for non-digital formats