- Shane Carr - Google i18n (SFC), Co-Moderator
- Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
- Eemeli Aro - Mozilla (EAO)
- Philip Chimento - Igalia (PFC)
- Richard Gibson - OpenJS Foundation (RGN)
- Yusuke Suzuki - Apple (YSZ)
- Tomomi Imura - Microsoft (TIA)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Daniel Minor - Mozilla (DLM)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
RGN: We clarified layering between 262 and 402. An ECMA-262 normative change is going to have normative consequences on 402 as a result, such as time zones accepting offset strings. I'm excited to shepherd through the Stage 4 proposals landing soon.
FYT: Can you clarify the timezone part? How about implementation ?
RGN: Currently the constraint in 402 to get the default timezone will go away , the change in 262 will propagate to 402, implementation if does not output offset timezone won’t be affected, current implementations cannot output a numeric offset.
FYT: Currently depending on the platform the values are picked differently , so this change may return a offset ?
RGN: It’s not a named timezone it’s anumeric signed followed by hours+minutes
FYT: Should this be covered by test262 ? How should we test this change
RGN: I have to look into that with test262 folks at test262 meeting
RCA: Technical preview PR landed; will be available in ICU 72. We're getting ready to make announcements and press release. There's still lots on the to-do list.
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
Intl.DurationFormat
YSZ: We currently implemented based in the proposal still have to look at the decision on formatToParts
FYT: The implementation , is in progress still have bugs mostly related with formatToParts
FYT : Intl.NFv3 already shipped in Chrome V? ,
SFC: This proposal it’s close to be ready for Stage4 , maybe we can ask for stage advancement in next January meeting
https://blog.unicode.org/2022/09/announcing-icu4x-10.html
RCA: We're getting ready for Temporal.
FYT: Temporal changes lots of things; fractional second digits is one of them. Why are we pulling this out specially?
SFC: It seems like a good idea to pull things off from the Temporal monolith, and there are other issues being resolved.
FYT: If there is other benefits of this PR it’s ok but if no we should wait for Temporal , otherwise would be a duplication of work
PFC: It does have value to peel things off the large proposal. This change isn't directly related to a Temporal API. That's what we're doing with default time zone in ECMA-262. I think it doesn't duplicate work; it saves work and allows people to look at it more carefully when it's not inside the giant proposal.
FYT: Without temporal we can keep the support from 0-3 , if temporal never ships why we are support the 4-9 ?
SFC: There are 2 different issues solved by this PR the 0 not throwing and the 4-9 support also is not harmful
SFC: My proposal is to discuss offline so next month we can proceed
FYT, PFC, SFC, RCA to discuss offline and come up with resolution for the next meeting
YSZ: What is the ICU version that has these?
SFC: Unicode 15, which is ICU 72.
FYT: Last year, in similar cases we hold off until ICU releases, so we should wait probably until november
Next meeting ICU should be released so we can revisit this again
FYT: The current shape of code currently passes test262 , but this could be an web compat breaker, it’s an observable behaviour change so when it lands we have to change a lot of tests
RGN: I do believe that’s necessary, so current specification would improve if we can move to the proposed state
SFC: There is a chance to evaluate the web compat risk ?
RGN: Usage counters might be the appropriate approach
FYT: I think we should list the Test262 that would be affected, and then we can tell if there is a "red flag" that could cause a compatibility issue. So I support the change but I think we need to understand the potential impact, be cautious.
RGN: That's reasonable and it's not difficult to do. Using engine262
EAO: +1
YSZ: Sounds good to me.
RGN: I'll work on the test changes.
Review the Test262 impact. Further discussion is not necessary in this group unless red flags show up. Approved with conditions.
https://github.com/tc39/proposal-intl-enumeration
FYT: Presenting - https://docs.google.com/presentation/d/1IIlwdOospGLmqCNjGuhh-NrZrxlHGhGbo0-uQFqfmyM/edit
SFC: I see 3 open issues what’s this affect the Stage 4 advancement ?
FYT: The first issue is #39.
SFC: The default fallbacks should just be ignored from the enumerated list.
FYT: There's no contradiction.
SFC: I vote we should close it or tag it as editorial. It shouldn’t affect stage 4 .
FYT : The second issue #37 we have a PR , with a simple solution to make it clear that’s a canonical id the changes are basically adding word canonical
PFC: If there is no compromise possible , we should find a work around it , I would prefer not continue with discussion
FYT: Do we have support for this Normative PR in TG2?
SFC: I see a lot of discussion on that issue and maybe we should add this PR to the TC39 agenda to have more people discussion about it
PFC: Unsure if that would be a good use of plenary time, this is an Editorial preference that might bring more people to bikeshedding on this issue
SFC: I have to catch up on the current status of this PR to have a informed opinion about this
RGN: Would be possible to summarize the positions ?
SFC: We don’t have time for it , best option it’s do it offline, None of the discussed issues are stage advancement blockers, changes might only apply strictness to the implementations,
FYT : This is a normative change, so we should take this strictness requirement before merge , making sure that only return canonical …
SFC: Are we all ok on merging this 43 PR and discuss future improvements later
PFC: Ok with that , my objection was based that this would be more work around everybody
FYT: Do we have support from Moz and Apple ?
YSZ: Yeah, +1
EAO: That's fine
DLM: Looks ok to me!
Merge PR #43 and go stage 4 and after work on the 3 remaining issues
FYT : Presenting - Slides https://docs.google.com/presentation/d/1_GAPg4P6FWNN9vJ_BwAHMsjikF7WHuJUX7VJczV0t0Y/edit#slide=id.p
FYT: What should we do with issue #62? tc39/proposal-intl-locale-info#62
RGN: I'm willing to help with that ,
FYT: Should this should be resolved before stage 4 ? or current behavior it’s ok for stage 4 ?
RGN : Why is this is different right now ?
FYT: This is not intention
RGN: We should return the same object.
YSZ: What happens if the return object is modified, if we remember it?
FYT: We'd need to make the object so it couldn't be modified.
RGN: I didn’t realize the value return is a object , you could either freeze it and always return the same thing. Or you could replace the property getter with a method.
SFC : My question is, what is the extent to which there is precedent for this and in other APIs ? since is a getter behavior should be consistent
RGN : It’s a free choice , we don’t have get methods that return objects , but I’m ok to set this new precedent,
SFC: This Stage 3 and already shipped in the browsers, so the change might affect implementations and maybe we shouldn’t be changed at this point
RGN: I think this should be changed
EAO : It look like a good use case for a Record
SFC: That would be a breaking change if in future we replace this by a Record ? This might be less invasive for people using this APIs
RGN : Web compat only applies when something is merged into the spec
SFC: Disagree cause this shipped in V8 for a long time…
EAO: The best way is to leave it for now and wait for Record
RGN : How essential is this interface for the proposal ? and what be the consequences for not having this ?
FYT I believe that would affect all of it
SFC: I believe this would be a good question for TG1 plenary - this is one of the issues that we should discuss there
- Make it a function
- Leave it the way it is
- Make it return a frozen object
- Wait a year and make it return a R&T
FYT: The other issue we need to discuss is tc39/proposal-intl-locale-info#33
FYT: Preference data is not available. We could sort alphabetically.
RGN: I would support that, and in the hypothetical future where preference data is made available in e.g. CLDR, we would just leave this as-is and add a new interface to expose it.
SFC: I have another proposal to solve issue #33. We could drop this; what are the use cases for collations anyway? We can have an issue to follow up this in future and we unblock this.
FYT: It's useful for browsers to know which collations are available in Chinese.
SFC: Other getters are specified to return data in implementation-defined locale-preference order. If browser has data that says has preference order it’s ok otherwise we should use alphabetical order.
FYT: Currently time zones are returned in alphabetical order
SFC: So timezone is alphabetic? So maybe it’s ok make collations alphabetic as well. For timezones, do we return timezone as first element of the array?
FYT: It’s alphabetical order
SFC: We may want to add -u-tz at some point, in which case the 1st element of the array should be the locale's time zone. If we insert the 1st element now, then developers can get used to that pattern. But, I'm okay relaxing this point and just always returning time zones and collations in alphabetical order.
FYT: It’s ok not considering drop the api ?
SFC: Yes
SFC: Do we have support for this ?
DLM: Based upon the context of this issue, he landed half the patches and is waiting for further feedback. We should leave info for him on Bugzilla on what to do next. I wouldn't expect that if we are approaching Stage 4 that there are other blocking issues.
FYT: I’ll change my slot in the agenda , not feeling comfortable going stage 4 , and will do change proposal to sort alphabetically and follow up with Mozilla to check if we have all we need to ask stage 4
Delay Stage 4 advancement and wait for Moz feedback and meanwhile we can fix the alphabetical sort
tc39/proposal-intl-messageformat#16
https://github.com/eemeli/proposal-intl-message-resource
EAO: (discusses issue)
SFC: I’m supportive with this change , also compatible with direction with direction group is taking decoupling this , I support this
DLM: +1. I think it makes sense to consider these separately. So I support this.
RCA: +1
YSZ: I support splitting. One question; in the resource spec, will we also specify the actual format of the resource?
EAO: That specification is undergoing under Unicode. We're hoping to rely on that.
YSZ: OK.
Approved message resources for Stage 1, split from the main proposal
https://github.com/FrankYFTang/proposal-intl-temporal
PFC: RCA and I were talking and we'd like to suggest a different name for the proposal, to avoid confusion with Temporal. The purpose of the proposal is to specify the calculations, which is not only about Temporal but also about DateTimeFormat, which also uses these calculations. I'm worried that if you take this to TG1 with the name "intl-temporal", it will raise unnecessary questions. I'd like to suggest a name like "intl-calendar-calculations" or something like that.
FYT: Originally the core of proposal , the most important things in this proposal was not specify calendar calculation and might not be achievable , the core part is the ERA for each calendar and the meaning of each month when working with temporal. When we specify anything related with calculation can be vaguely mentioned in this proposal.
Ideally by this time we should have enough information on Temporal information to progress implementation , at current state there is no mention calendars , but we have test262 testing that behavior that we have a gap between proposal , documentation and proposal, so my intention was to have a minimum set of spec to unblock that.
Do we want to include simple calculations there ? Example differences in calendars …
It could belong internally to Temporal proposal , but at the moment is stage 3 being more difficult to expand the scope, so this new proposal would be complementary to temporal as an independent proposal that can be used in future by temporal. Currently this also block temporal implementation if we don’t have this bits of spec to fulfill the existing gap
SFC: We should resolve the naming, I would suggest call it intl-calendar-proposal
FYT: I’m afraid that if we change it to calendar that would be much bigger task
PFC: I was going to suggest, intl-era-and-month-codes
FYT : I’m open to that
PFC: I’m happy to discuss later about this and if this should belong to the temporal proposal scope
SFC : Everybody is happy with proposal-intl-era-and-month-codes ?
RCA : +1
SFC : + 1
FYT : +1
We approved the change of name proposal-intl-era-and-month-codes
tc39/proposal-intl-duration-format#125
RCA: How many implementations are in progress ? This would affect them ?
YSZ: We agreed that the default unit length is short, so this looks consistent.
LGTM from two implementers. Bring back to the issue for agreement from Ujjwal.
tc39/proposal-intl-duration-format#115
PFC : I talked with Ujjwal Sharma about this and we do believe that a table driven test would fit here , cause if we do exhaustive test we would likely to have more than 12M combinations , so this option of having a table driven test can cover the needs we have for validate spec correctness
FYT : There is a strong dependency between option fields that impact others so those combinations are difficult to test and are likely to cause errorsthis case is different from DateFormat or others, current the DurationFormat has dependencies on previous options so it makes more complicated
PFC: I don’t have much to say about the proposal , we discussed a testing strategy that would work for the proposal
SFC: It sounds like the action here is to write the tests. Not much more to discuss.
RCA and USA to write the tests.
RCA: (introduces the topic)
SFC: This is a really important area that I'm looking forward to progressing throughout 2023.
RCA to sync with DLM and YSZ.