Attendees:
- Myles C. Maxfield - Apple (MCM)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Craig Cornelius - Google i18n (CCN)
- Richard Gibson - OpenJS Foundation (RGN)
- Zibi Braniecki - Mozilla (ZB)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Richard Gibson - OpenJS Foundation (RGN)
- Yusuke Suzuki - Apple (YSZ)
- Younies Mahmoud - Google i18n (YMD)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
ZB: We reconciled into two models. We brought those to the main working group. We are going to double the number of meetings to try to converge on the data model question. It's a question of flexibility versus strictness, and finding a place on the spectrum. We plan to move forward with a combination of debate and code experimentation.
SFC: In case someone wants to join the meeting, you can find them on the ECMA-402 calendar.
SFC: FYT found an issue about the table running over in the PDF file.
FYT: The issue on the units table is in both the 2020 version and the 2021 version. The numbering systems table in 2021 will run over, but not in 2020.
RGN: The 2020 version is effectively frozen, we can’t do much about it, not sure if there is an amendment process. Similar 262 issue has been considered irrelevant. The 2021 issue I would like to fix, and I believe LEO is working on it.
tc39/proposal-intl-enumeration#3
SFC: Last month, ZB presented an update from Mozilla and the AP was on Apple delegates to confirm the findings.
MCM: We agree with ZB's privacy evaluation. Although we still have concerns with the proposal overall.
ZB: +1
SFC: Then we can close the issue, the privacy concerns have been resolved and the merits outside of privacy concerns have been discussed extensively by committee.
tc39/proposal-intl-locale-info#9
FYT: Need additional Stage 3 reviewers. Misunderstood the timeline around seeking reviewers.
ZB: I can take it.
https://tc39.es/proposal-intl-locale-info/
FYT: present different approaches in the spec
FYT: Do we like Approach 1 or 2?
SFC: both approaches are valid, prefer Approach 2 because of semantics and usability. The catch with either approach is that these getters require locale data, so when implementing on ICU4X we might have to take that into consideration.
FYT: ???
ZB: only consideration when considering those proposals was
FYT: ???
SFC: The first element of the list, [0], should reflect the best guess at the user’s preference. If there are no extension tags used, then we should look into the locale data; otherwise, the first element is the extension tag. A user might have a different preference based on the specific locale; there is no overall preference list.
FYT: the current 402 model does not preclude the system to return the override information to the system. If my users say calendar=”roc”, I could return zh-CW to return roc. The spec does not preclude the implementation from doing that, but if current implementations do that or not is another question altogether. A user can change calendar options, but that’s an implementation issue, not spec issue.
FYT: Section 1.1. If we get a locale without the extension key, then preferred is undermined. But if an extension is included, should the system return additional information that the system knows in addition to what the user has explicitly requested?
RGN: What is the question?
FYT: If you are using chinese calendar in Taiwan, the locale can return gregorian, roc or chinese. Gregorian is first priority, ROC is second, Chinese traditional is 3rd. If you pass in a locale without an extension, that's what we return. But if the locale has a -u-ca-japanese entry, should it only return the Unicode extension, or should it return everything? If it returns Japanese, should the system return only Japanese or also the other related options. Should the system restrict or extend the return value?
RGN: my preference is the restriction. If the preference is provided explicitly, then we should reflect that.
ZB: I have the opposite preference. We do not have a rejection list format. There is no way for the user to say that they DON’T want a calendar, just that they do a specific one.
If the user says use Serbian, it doesn’t mean that the user is rejecting other options. Fallacy of selecdting the first best option. We are always working on incomplete information. What happens if user specifies a calendar that we can’t return and we are using restrictive model,, then return something that may work but it may not be valid and may even crash the system.
RGN: You are questioning the intended operation of the system - this is not the right discussion to have at this level.
FYT: I’m more aligned with RGN’s note, but I can see ZB’s point. It’s hard to say what’s the right behavior.
ZB: Culturally, I’m making a strong opinion, but it’s weakly held.
RGN: A reasonable answer cannot be discussed without discussing use-cases and semantics?
ZB: Maybe step forward is to build a case study and think about what could be returned. Result given to another formatter, or some other action. What is the consequence of not providing a fallback?
SFC: there are two primary use-cases here: one is negotiating the calendar system with what the application supports. In that case, all you need is an API that returns the resolution.
Reason for an array of possible values, e.g., in Iran or other places where multiple calendars are routinely used.
It is common for countries that use multiple calendar systems since they might show the same date in different calendars one over the other. If the user does specify their preference.
SFC: The simplicity of returning a single value is nice, but a Japanese person living in the US may have multiple preferences. I would prefer seeing a future where UTS 35 can support multiple ordered preferences.
MCM: We've been discussing the mechanism by which to expose user preferences. In WebKit, we plan to not to expose user preferences through this API. This is to avoid fingerprinting the user.
ZB: Same in Firefox.
FYT: A developer on the server side could store a locale string with preferences. They can call this API and get preferred calendar from the API.
But we are talking about what is provided to process the preferences, not what it returns
ZB: I understand that right now, this is how it works. And I understand that after we ship this API, we will get requests to make this API respect operating system preferences.
FYT: The system does not have any way to get the preferences.
ZB: The way I would imagine this request coming is that someone passes en-US, and they get the 12-hour clock in the Electron app. People will ask why the system cannot just look into preferences.
SFC: There should not be a way to get OS data through ECMA-402. This can be done on the web platform from language settings. (Encourages listeners to think about gathering user preferences from a variety of places.)
Cannot get this from Locale, however! Could get from navigators, headers, or other source.
FYT: Two approaches - but neither seems strongly held. Suggests brining to Stage 3 at next meeting.l
SFC: For now, I would prefer choosing shorter return of just one element.
RGN: suggests proposing now, application can return shorter result, but ??? can get the full fallback list.
???: When creating Intl.Locale, can we allow setting behavior to be used on return.
SFC: There’s a way to get the full behavior even if we choose the shorter option. It's easy to write code that removes the extension keyword to get the longer list.
FYT: OK to change spec to shorter option and go to TC39 Stage 3? Support or object?
RGN: In principle, I’m on board but the current explanation does not support semantics we’ve just been discussing.
FYI: If no one objects, he’ll take this to TC39.
SFC: Anything more on Intl.Locale info? Do we have a conclusion?
Conclusion: Propose choosing the shorter list, but document that applications can change that if they choose.
No objections.
SFC: Do we have consensus on Intl Locale Info for Stage 3? I support it.
USA: +1
RGN: +1, contingent on the changes we talked about
ZB: +1
LAF: +1
- Slides: https://docs.google.com/presentation/d/1_BR2bq6gi_i9QjDDluv683cuO2AXNwZl-3hXC4gLl3M/edit
- Repo: https://github.com/tc39/intl-displaynames-v2
- Spec: https://tc39.es/intl-displaynames-v2/
FYT: Change after 402 January Stage 2 discussion:
- taking out time zones, only keeping calendar and unit
- people want to see date/time field
- requests for dialects of languages, so it would return more than one way of representing the language language name.
- E.g., en-GB vs. “British English”
- Slide 5: If type is “language”, added “dialect” option
- Slide 6: added field to validate date/time code
- Slide 7-9: added code for return of “dialectName” and “standardName”
Is this sufficient for going to Stage 3?
Also, soliciting ideas on better names for these fields and value enums.
SFC: Any example of how dialect choice would change output
FYT: shows example in README.md with “en” using “dialectHandling”, en vs, en-AU, “American English” vs “Australian English” This feature has been requested by a couple people, including IBM. Other is asking for same feature,
Needs a Stage 3 reviewer. Any volunteers in addition to SFC?
USA: I can be a Stage 3 reviewer.
FYT: Any suggestions on names? Also showing examples in Spanish & Chinese of dateTimeField
SFC: Are we happy with this to progress to Stage 3? (uncomfortable silence). SFC supports Stage 3, which is already scaled back and is now a fairly thin proposal.
Planning to fill in calendar names?
FYT: will add in README
SFC: Approving 3 new options: date field names, calendar names, unit names. Also dialect handing.
SFC: I support Stage 3. Can I get more explicit support?
YSZ: A lot of web apps have a lot of text, and the text is filled with display names. Having localization with this feature is useful. I support Stage 3.
RGN: I'm good with it.
ZB: I'm okay.
LAF: Okay for me too.
SFC: Hearing no objection, move to Stage 3 with this pared down specifications.
BREAK TIME
SFC: Next on agenda: -Time Zone for S2
- Rounding options
- Intl Duration format
Any other topics to prioritize before 12:00 hard stop. Return in 10 minutes (X:27 or X:57 (India))
- Slides: https://docs.google.com/presentation/d/1eYuygaDvErbftDjg4S6zCYqhaxpEiCyFDDdpjmPaMyo/
- Repo: https://github.com/tc39/proposal-intl-extend-timezonename/
- Spec: https://tc39.es/proposal-intl-extend-timezonename/
FYT: (introduces slides)
FYT: bringing up spec tags for details needed for Stage 2. The spec is ready for review.
FYT: The only open issue is people asking us to add more patterns for ISO-8601 TimeZone format. I strongly object because it is out of scope for Intl. SUggests that if it’s needed, they should go to ECMA-262 to request.
Payload analysis is from a long time ago.
FYT: When we go for Stage 2, we need to fulfill the three entrance criteria: Prior Art, Expensive to Implement in Userland, and Broad Appeal. I also wanted to address Payload Mitigation, which is for Stage 3.
For Prior Art and Broad Appeal, there are a lot of examples where web sites use these alternative time zone formats. E.g., “ET” for US Eastern Time Zone on news websites.
For Expensive to Implement in Userland, this has a locale data dependency, and it is locale-dependent formatting.
For Payload Mitigation, there are data I show here that shows that this size is small.
Short is much smaller because fallback is allowed.
Also added spec tag detail. Changes are highlighted in green background. Section e. xi, xii. etc. Proposes to move to Stage 2.
SFC: Frank has done his homework and the arguments are quite compelling. I agree with the TimeZone comments re: ISO-8601. I support Stage 2 and would even support Stage 3.
RGN: I support the proposal, but I don't know about the names "shortGMT" and "longGMT".
FYT: look at README - interesting examples are French as well as India with its 30 minute offset.
RGN: GMT is not really a reference - it’s obsolete.
USA: We use such a representation in Temporal, and refer to it as an "offset". So maybe we could call it "shortOffset" and "longOffset".
RGN: that’s the same direction I was going to take that.
FYT: Is the offset a number or a string in Temporal?
USA: It's a string. Do you
FYT: Not very picky about names - no preferences
RGN: I am in favor of "offset".
SFC: I also prefer “offset” rather than GMT, because the string "GMT" is not used in every locale.
ZB: +1
FYT: shortOffset and longOffset are accepted
FYT: Consensus to move to S2 in May?
USA: Good that this has described use cases without adding much payload.
SFC: To be clear, asking for S2?
RGN: +1
ZB: +1
USA: +1
SFC: +1
LAF: +1
SFC: That’s 5. Working from consensus, that’s agreement.
tc39/proposal-intl-numberformat-v3#8
SFC: asking for agreement on Rounding Options Puzzle (PR#8). From deep dive earlier this week, presented notes and conclusions from April 6 mtg on Rounding priority.
Mental model uses maxFractionDigits and maxSignificantDigits to signify a power of 10 at which to round the number.
roundingIncrement: support only 1 or 5 followed by any number of zeros
trailingZeroDisplay: proposing as an orthogonal option with values “auto” and “stringIfInteger”
RGN: Thanks to Shane for the marathon effort.
USA: no opposition
LAF: +1 to these rounding options
tc39/proposal-intl-numberformat-v3#7
SFC: now proposing9 rounding modes (ceil, floor, … halfEven). FYT: What’s the current default? SFC: current is halfExpand
USA: also would be useful. HalfOdd was dropped because no use cases were found.
FYT: Question: there are several other formats touched with Intl. When we add these rounding options, will they affect other formatting?
USA: Followup question - in those other formatters, do we allow the user to select the option? E.g., with duration formatting (in process), currently does not allow formatting options. Will these rounding changes affect that, for example?
SFC: These options set precedent for other proposals. Other use one or more of the proposed options.
FYT: Plural rules affected? SFC: SHort option may be added wherever needed. They will have to pass the options down to NumberFormatting when they use
FYT: Relative Time Format - does it accept anything other than integers? SFC: good questions for S3 review. Asking for comment on 9 modes proposed.
RGN: +1. I like this a lot and I'm happy we converged.
YMD: +1
FYT: +1
SFC: these are the last two issues on NumFormat V3
tc39/proposal-intl-duration-format#32
ZB: this is one of the most interesting topics that I’m following
USA: Starting with PR #32 - a “fun one”
USA: We decided last meeting to move from the fields list to smallestUnit / largestUnit and hideZeroValued. We also agreed that for every format call to DurationFormat, we could call .round() on that Duration object. If it wasn’t an duration object, then it would be converted to that type.
The question I have is, you may come to a situation where you have a DurationFormat object, and you pass in a different duration, and based on what the duration is, you might need to specify a different smallestUnit and largestUnit, because it's rounding it based on those options. The behavior throughout 402 is that you pass in a number of options to the constructor, and those options are also accepted by toLocaleString. I was wondering, can we make an exception in this case?
Can we deal with situations in which locale only passes half of the options?
FYT: I understand that something changed that reached consensus a while ago. Those changes have not been reflected in the spec text yet. Last month, I prototyped three different versions in V8 based on the spec text, but then SFC told me that the spec text is out of date. From my point of view, it's difficult to discuss anything until we can reflect what we've already agreed upon into the spec text. Because otherwise we're relying on people's memory.
USA: I understand. Unfortunately I had to drop the ball on this a while ago, but I picked it back up again a few days ago. So I intend to update the spec text in a couple of days.
FYT: Totally understand. I cannot any new issue until this has happened. I suggest not discussing until the new spec text reflects latest discussion.
SFC: I agree with Frank’s statement. But I think that we can make some decisions on a meta level and that USA’s ideas are on the meta level. Options that go into the formatter should be for resolution of locale data. We should now have to touch the data bundle after the constructor. Options for formatting should not require new data retrieval. smallestUnit / largestUnit may seem to go into that category. But other changes such as unit (e.g., “month”) would need new data. So if purely for a specific display function, then the option can be given in the format function.
USA: THere's certainly a locale data size function. The locale is on the constructor. The biggest differentiator is the style, which I'm happy keeping on the constructor. With both the locale and style on the constructor, keeping a record of patterns rather than a single pattern which can then be keyed by the format function is acceptable to me. The reason I think it's acceptable is that I think it is reasonable for people to pass around durations with non-overlapping options. My understanding of how the options would pan out is that if you put those options into the constructor, people would have to create many different formatters.
FYT: I strongly opposes putting into format based on his formatting prototypes. If passing into format, need to construct all the formats ahead of time. Or dynamically reconstruct the object, needing new data. THis may cause failure at formatting time.
USA: Does smallestUnit/largestUnit affect the number format?
FYT: No. I may need to waste resources. This may force getting new data / new construction.
RGN: From the perspective of an author using this API, the overwhelming pattern is that the only argos to formatter are the data themselves to be formatted. I don’t see a compelling reason to change this now. Better to put in constructor.
SFC: There are two compelling reasons to keep these options in the constructor. First is that if it’s not in constructor, then the data needs to be prepared for all the possible units, from nanoseconds through years. Another good example is digital units. Waiting until formatting delays choice of code paths. Second is from the use case perspective. That is another argument for constructor-time because fields and units are known at construction time, based on the context in which you intend the duration to be displayed, e.g., a count down timer.
USA: That’s all right - just wanted to see what comments were. Maybe take it offline with Frank.
SFC: On to Issue #44?
tc39/proposal-intl-duration-format#44
USA: This is about the consistency of unit plural symbols in DurationFormat, NumberFormat, and Temporal. NumberFormat uses a singular naming scheme, but Temporal uses plural.
Since the others are at Stage 3 and we have no compelling reasons to change them, how do we align Duration with Temporal and also Intl.DateTimeFormat.
FYT: Made a mistake referring to DateTimeFormat. Should have been RelativeDateTimeFormat and NumberFormat, we output singular forms in formatToParts. If we go with the plural form, it creates an inconsistency in ECMA-402.
FormatToParts with value “day” vs “day”. I suggest we keep this consistent, returning the unit such as “day”
For Stage 3, we can still influence, but RelativeDateTimeFormatter has been published.
SFC: I agree with Frank on this.
USA: if Temporal does switch to singular, does this resolve?
SFC: I don’t agree that we need to do come up with a Plan B. We can make a recommendation in our capacity of TG2 that TG1 should make this change. Only if TG1 declines our request, then we can define Plan B.
FYT: I don’t want to see any conflict. They (other proposals) have the opportunity to avoid any conflicts.
USA: I don’t see anything that we can really discuss here.
FYT: We can discuss that TG1 should …. I don’t want to receive tons of bugs in the future based on a decision now.
USA: I feel that it’s OK to use singular forms in the output, but for input, we should error on the side of plural. Other than that, I don’t know how to resolve this because I have such a strong conflict of interest. If you all agree that we strongly favor “singular”, I’ll go along with that.
SFC: I've been an advocate for a long time that Temporal should adopt “singular”, but was not pushing too hard previously. Now, however, Frank is bringing up new reasons to consider this. We decided to recommend camelCase specifically so that input and output would be consistent. Besides that, I favor singular forms because, when in doubt, English is a really weird language with the addition of “s” in addition to changing spelling.
FYT: If Temporal goes with plural, then there will be additional requests for other parts to use plural. This is a pretty big impact, There is no place in ECMAScript that currently specifies plural forms. I think there is a big issue here.
SFC: 4 minutes remain. How does this group feel about making a formal recommendation that TG1 changes the decision on plurals in Temporal. We will recommend that TG2 wants them to reconsider that decision.
RGN: It’s definitely worth considering raising this even beyond Temporal. Seeking explicitly decision is important. Definitely give Temporal a heads up on this.
FYT: This will set precedent, so what is decided will definitely influence later decisions.
RGN: I can't think of another intersection with 402 where that would crop up. We have things like plural names to enumerate keys and values in collection data types, but that's not the same thing we're dealing with here.
LAF: +1 for reconsidering to come back to singular form
USA: At the very least, we have a plan of action. Frank can write up a recommendation on this is.
FYT: Cannot put this together without having more complete codified proposal
USA: I will do that. If we decide to move forward with singular units, and temporal does not, then this is a case where constructing a new object with different fields will be needed.
SFC: We’ve got a clear path forward. Who will take this action item to present something clear to Temporal.
CCN: Shane and I will collaborate on writing this up.
SFC: We finished agenda items - amazing!
FYT: Should we add this to the agenda?
SFC: Yes, I’ll add to agenda, even though we don’t need the document right away.