July Attendees:
- Shane Carr - Google i18n (SC), Moderator
- Craig Cornelius - Google i18n (CC)
- Felipe Balbontin - Google i18n (FB)
- Frank Tang - Google i18n, V8 (FT)
- Jahziel Villasana - Student (JV)
- Jeff Walden - Spidermonkey (JW)
- Jessica Rose - Mozilla (JR)
- Leo Balter - Bocoup (LB)
- Long Ho - Dropbox, Format.js, react intl (LH)
- Richard Gibson - OpenJS foundation, Oracle (RG)
- Romulo Cintra - CaixaBank (RC)
- Myles C. Maxfield - Apple (MM)
- Valerie Young - Bocoup (VY)
- Younies Mahmoud - Google i18n (YM)
- Zibi Braniecki - Mozilla (ZB)
Discussion board: https://github.com/tc39/ecma402/projects/1
August 8, 10am PDT (5pm GMT)
-
Last month: FT decided to wait until the next two issues get addressed (#227, #351). Because it could cause forward-behavior problems.
SC: Wait until Dan is back.
-
Last month: ECMA 402 has consensus on the PR, and the directly related PRs.
SC: Is tc39 approval the blocking issue for these PRs? Should we seek approval for basically stage 3, so we can move forward with tests and documentation and implementation.
FT: Yes we should do that.
LB: Daniel is championing, but he is not present, should we bring it?
SC: We’ll there is no pressing reason to bring it to TC39. We can wait until Dan is back.
-
Last month: Consensus based on #351.
SC: Wait until Dan is back.
-
Last month: MN raised some concerns and would discuss offline with FT.
-
Partial tests in tc39/test262#2194
-
V8 behind flag --harmony_intl_dateformat_fractional_second_digits
FT: I discussed later with MN. He thought this was about relative time format. But then he said his concern was addressed.
SC: Do we have consensus on this normative PR? (Sounds like yes from silence). We should here from mozilla and apple.
JW: It looks pretty sane to me.
ZB: LGTM
MM: Sounds fine.
- Consensus on accepting the PR in ECMA 402.
- We need implementation and documentation.
FT: I will push for next Chrome release - 78. We have test262 tests.
SC: Romulo, can we consider this normative PRs needing MDN documentation as well.
RC: Yes, will review and add issues.
Notes: not yet covered in Test262: format , formatToParts , formatRange and formatRangeToParts.
-
Last month: Consensus achieved.
-
Partial tests in tc39/test262#2194 and tc39/test262#2217
-
V8 behind flag --harmony_intl_dateformat_day_period
SC: Still need implementation and MDN documentation.
FT: I will try to push this on Chrome 78.
-
Last month: concerns raised over what this means for non-Gregorian calendars.
-
Partial tests in tc39/test262#2194
-
V8 behind flag --harmony_intl_dateformat_quarter
FT: Even within Gregorian calendar, you can still have trimester and semester. So it seems this does not depend on the calendar system. Second, within Gregorian, first quarter could mean something different depending on the financial year. Third, we may have to deal with leap months. So these questions need to be answered on the CLDR level. I propose we hold this for now and continue discussions in CLDR.
FT: This is kind of stage 1.
SC: Don’t make documentation for this, or tests, since this proposal is being sent back “stages” due to these issues.
LB: Would it help if this PR were transformed into a formal proposal?
FT: Eventually maybe, but the current issue is that this is much more complicated and a lot of things need to be looped in. I don't think a proposal would help because this needs to go to the CLDR level: the scope and all the math.
LB: I'm happy to help resolve some of these problems. I was just thinking that a proposal would help us track blocking issues. But maybe that's overkill.
FT: I'll think about it.
Notes: not yet covered in Test262: format , formatToParts , formatRange and formatRangeToParts.
Editor note (from Leo): The editors are reviewing all the current Proposals in stage 2 and 3. We'd like to prioritize items planned to advance to a further stage in the next meeting. Please help us building a priority list!
-
Last month: André Bargull (@anba) has a patch which is waiting for review for Firefox. Low priority for Safari.
-
Last month: bug with
type: 'disjunction'in Spanish? #45 -
Update: New team member at Google is working on the CLDR ticket.
-
Test262 tests: Good.
-
MDN Documentation: Good.
-
Documentation related with this issue on github : tc39/proposal-intl-list-format#37
ZB: We need to make progress on ListFormat.
YM: We will decide soon with CLDR how to implement this. Probably option 2.
MM: No updates from Apple.
-
Last month: André Bargull (@anba) also has an implementation that is on the review queue for mozilla.
-
Test262 Tests:Good.
-
MDN Documentation: Needs examples, work on going from Jahziel Villasana and Romulo.
ZB: We are about to land a major patch that moves us to use local identifiers (1522070). Will unblock landing of intl.Local. Hopefully milestone 70, but maybe 71.
JW: I might be able to finish reviewing those patches this week.
RC: I have GitHub issues for the MDN documentation to track the progress. I have added links above.
MM: No update (yet).
-
Last month: Firefox needs to upgrade to ICU 64. FT: It should land pretty soon in V8. And it won't have a flag.
-
Test262 Tests: Good.
-
Github Issue - MDN Documentation (Closed)
-
MDN Documentation: Good.
ZB: FormatToParts landed in nightly!
SC: What is the timeline for Stage 4? Does this need to be shipped in stable?
ZB: I'd like to make sure we have some level of approval from Apple.
MM: I can't comment; we can chat afterward.
LB: It is not a blocker to have something in nightly. It's preferable to have 2 implementations shipped in a release version. Probably not advance this in July, but maybe in September.
ZB: I understand that technically, we can put this to Stage 4 with two implementations. For the sake of consistency, I don't want to wait for Apple, but I want intention from Apple.
ZB: It will go for release in Firefox in October. In September, it will be in beta.
LB: It will probably be mature enough in September, but any meeting this year, the release is the same.
ZB: Let’s aim for September stage 4.
SC: As long as we have two implementations, MDN and test262 (considering this is the tc39 stage process) we should go for stage 4. Polyfills can also help.
MM: We do not want to hold this process back. Two implementations is sufficient.
-
Update: v8 will ship with Chrome 77. Firefox status?
-
Test262 Tests: Only 4.
-
MDN Documentation: Does not contain examples for this proposal.
SC: More test262 for rounding and for combining settings would be good to have.
LB: It would be good to have that documented. Next week, I'll have lots of time to work on this.
FT: The PR not only adds a couple, it is also an algorithm change, is this ok at this stage?
SC: It’s not an algorithm change, only change checking a string. If it is disruptive then maybe we shouldn’t support vehicle consumption units. It had 4 simple units and 2 compound units. We went from 150 to 39, now we are adding back 4 more. We are adding them based on CLDR unit preferences.
ZB: We are increasing the data payload by 10%.
SC: Approximately. I haven’t calculated exact size increase. Issue #39 on proposal discusses data size. If people are concerned about the consumption units (and only add volume units), then we can not support now and potentially add later.
FT: Is anyone lobbying to add consumption? Why?
SC: junkshik, a googler, on issue 39 is advocating for it. We haven’t gotten quite as much weigh in on picking units as I’d like.
ZB: Already 230kB. Proposal adds 30 kB approx?
SC: No. That number is too small, it is from a smaller set of 12 units.
ZB: Can we get an approx number for the current set. It would be helpful for me to understand.
SC: About 20kB per unit.
ZB: So, about a MB of data.
SC: Uncompressed. And for all ICU locales, larger than supported in browser.
ZB: We do the default ICU locales. We cut tables, not locales.
RC: There is no issue for number format MDN. I can make an issue for it.
-
Last month: not sure about Firefox status. DE will check.
-
V8 ship with Chrome 76
-
Test262 Tests: 16 tests.
-
MDN Documentation: None
ZB: we have a bug filed. This is in spidermonkey, we just need to expose it.
FT: From user's point of view, this is not available yet in Spidermonkey.
SC: Looks like the bug has recent activity. What are the plans/timeline for enabling in firefox?
ZB: I don’t know.
JW: I don't specifically know.
ZB: Intl.Locale is definitely the priority right now.
SC: That would be great if we could get this into Stage 4 this year, as soon as the bit if flipped spidermonkey and we have MDN docs we are good for it.
RC: I will make a bug for the MDN documentation. I need to review to make sure what has and hasn’t been done.
-
Last month: V8 ship with Chrome 76. The tests are all in. We are in good shape.
-
Test262 Tests: Good.
-
MDN Documentation: None.
ZB: Spidermonkey intends to implement, can’t commit to any timeline.
RC: I will open an issue on the proposal and add tasks to issues for minimal documentation.
-
Last month: extended discussion about RG's proposed changes.
-
Update: additional deep dive meeting with ICU stakeholders.
SC: Discussions about the shape of intl segmenter API. Updates?
RG: I'll be working on this again later this month. I'm not planning for stage advangement this July, but hopefully in September.
SC: Any other blocking issues?
RG: Not at this time, but I will solicit things on GitHub and bring it up next month as well.
LB: Just a note, it's fine to advance to Stage 3 if the spec text is not fully finished, if there are small parts that need to be finalized, as long as they are identified.
- Issues:
- Casing issues/32
- Add link issues/35 pull/41
- Improve Intro: pull/40
- Syntax to access fields by variable / Internal Slots:
- issues/36
- issues/37
- pull/42
FT: We have several issues to address, some of which have PRs. The main problem is about casing. An enum could be used as a key for another API. For example, timeZoneName could be in different APIs. So it's unclear whether we should use kebab-case or camelCase.
SC: We need to discuss this further, we will after PRs.
FT: The other thing is having a text backpointer to the README. There was also a suggestion about how to improve the intro paragraph, and deal with the internal slots. I would like to move this to Stage 3 in the upcoming July meeting. I won't be able to attend at that time.
SC: Let’s discuss these soon so we can resolve them. Can we put this in stage advancement for this TC39 meeting?
FT: Today is the last day for putting on agenda.
SC: Explains Issue. If it is a string, we should use “-” according to w3c design principles. But if the string is used as a key, we can’t use “-” in javascript. Three directions:
- Use kebob case for strings, with inconsistencies when using as key.
- Use only camelcase for everything (including updating old decisions).
- Middle ground, support both camelcase and kebab case at the same time in api where it is possible.
FT: key problem is input of api could be output of another. You might have to do manual mapping. Casing issue is beyond intl display name proposal.
SC: Maybe this is a discussion worth having at TC39 this month.
LB: I’ve been trying to formalize a recommendation. I have a strong preference to follow W3C. At the same time, as daniel and frank have pointed out, we would be more consistent to just follow camel case. At the end of the day consistency wins the recommendation. I would be ok if we justed used camelcase, but we should document that. If we go with camel case, I recommend we do not use aliases (option 3).
FT: I agree with Leo about the aliases.
SC: We already have this inconsistency in formatToParts. We already use kebab case in local strings. Datetime format options use it.
LB: For locales, it's a very specific part. We could say that for options, you use camel case. If we could write from scratch, I would avoid camel case for string enumeration values. But considering what we have already, I think we need to stick with camel case in the API for options.
SC: If that's the case, should we consider patching Unified NumberFormat to use camel case where possible? For example, on sign: "except-zero" or sign: "exceptZero".
LB: As the champion, how do you feel?
SC: What I want is consistency with ECMA 402. And it seems that if we choose camel case for ECMA 402, we should change Unified NumebrFormat to also use camel case.
FT: But LB pointed out that "2-digit" is used in Intl.DateTimeFormat. But maybe that's a bit different.
CC: It seems that casing should be consistent with a particular class. Otherwise people will guess and guess wrong and it will be frustrating.
LB: Yes. I'd love to hear from more people. This is a hard decision. The more people we get weighing in, the better.
SC: Only three people have commented, would like to hear more.
RG: The argument I find most compelling is the one in favor of camel case, just so you can pass in the output of one API as the input to another. It seems to be the more common pattern in ECMA 402, even though it is really weak. I would not object if it went the other way.
LB: I am going to propose two questions, and see if we have consensus from the room. (1) For this issue, in the context of the DisplayNames proposal, should we recommend camel case? (2) Should this recommendation affect other active proposals like NumberFormat?
SC: I like these clear questions.
LB: Does anyone have an objection to recommending camel case for DisplayNames? Silence will be considered assent.
(silence)
JW: I would like camel case; it seems that most of JS uses camel case, and being consistent there is a good thing. Except I don't understand the W3C recommendations.
RG: My impression is that the W3C recommendation was influenced by CSS.
LB: We found no strong objections.
SC: A good example of a similar problem with JavaScript and CSS is HTMLElement.style. You access CSS properties via camelCase fields on element.style, like "element.style.borderColor", even though in CSS, the property is called "border-color".
MM: I looked at the CSS spec https://drafts.csswg.org/cssom/#the-cssstyledeclaration-interface and the properties you mentioned are non-standard.
SC: Let's discuss Leo's second question.
FT: Are we talking about just Unified NumberFormat or all of Intl.NumberFormat?
SC: We're talking about existing proposals and future proposals, but not changing existing API.
SC: My preference is to be consistent with the decision above and use camel case in the exceptZero option string. I should point out that the unit identifiers are kebab case, "meter-per-second", but that comes from CLDR spec, UTS 35.
RG: I agree with Shane and I’m not disturbed by the unit identifiers being kebab.
LB: I will consider silence as a yes. This is your last minute to object.
SC: Are we on for stage advancement in July, since this has been resolved? I can do the presentation, I am attending.
(general support).
LB: I will be attending.
SC: UTC meeting is in redmond the same week Tues-Friday. Could attend both! Do we have an issue to discuss with them?
SC: Ms2ger submitted PR a week ago. We need reviewers. I can review. This PR is blocker on stage advancement for temporal.
LB: I can review but I'd be welcoming to someone else who is interested. It's better to have more eyes on this.
FT: This PR is adding to the temporal proposal.
SC: The sooner we can do review the sooner we can let Ms2ger work on spec text.
FT: I can review if deadline is September for TC39 stage advancement.
Question in Intl.Locale from Anba: tc39/proposal-intl-locale#65
FT: Default is true.
SC: The concern is that either the string “true” or empty string means true.
??: We should probably concern a consistent value, so user don’t have to check both empty an dtrue. What does it take to do that? Internally it must store true.
SC: This may involve a PR to the Intl.Locale spec. Maybe a change in V8.
FT: it’s pretty hacky there
SC: Do we have agreement from the commit that we should adopt what anba is proposing.
LB: He is proposing to convert empty string to true.
FT: We should return true.
CC: Are there any objections? (silence)
Consensus: given what we know now, I will record consensus.
CC: Does this also affect the toString output?
SC: Let's follow up on the thread about that.
How to select the glue pattern? From Frank: #338
SC: If you have datestyle long, timestyle short, how do we put time and date together? One approach is that we could have a key you could specify. But we still need some way to pick the default.
FB: What does ICU use as a default?
FT: I don't know.
FB: To keep it simple, for now, we can adopt ICU behavior in the spec.
SC: Do we think that this is a feature that would be useful to expose as API? That could be a normative PR.
RG: I could see that coming in, but I'm struggling to see a compelling case to deviate from the default.
Consensus: update the spec to adopt ICU default behavior, without plans right now for API.