Attendees:
- Shane Carr - Google i18n (SFC), Co-Moderator
- Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
- Richard Gibson - OpenJS Foundation (RGN)
- Eemeli Aro - OpenJSF (EAO)
- Felipe Balbontin - Google i18n (FBN)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Leo Balter - Salesforce (LEO)
- Philip Chimento - Igalia (PFC)
- Zibi Braniecki - Mozilla (ZB)
- Younies Mahmoud - Google i18n (YMD)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
RCA: We've started on some implementations: Mihai, Elango, Zibi, are creating some POC’s to implement a use case(selector & placeholders) We're creating smaller task forces on smaller issues to try to increase velocity.
SFC: What are some of the recent decisions?
RCA: We will start by implementing the placeholders. That will help us learn the constraints. Then we will follow up with bigger decisions.
SFC: discusses access control on the ECMA-402 repository
FYT: What does the write access give intl to? I still have no merge button in the PR got approved.
SFC: The write access is for adding items in the wiki page, triage the issues, ... Merging PR requires admin access. I set intl to write access because of that was the status quo.
LEO: We could grant intl admin access too and trust the 19 people in the intl group to do the right thing.
SFC : Will create an issue, to follow up later if we should give admin access or not.
SFC: show an alternate status listing on airtable.com
SFC: The wiki page of showing the status are good to view but hard to change
FYT: The wiki is hard to edit, yes, but airtable looks much worse. There ought to be an alternative which improves things on both ends.
SFC: I’ll kick off an email thread for this.
SFC: the same contributor added string tags to all Intl constructors that didn’t have it, and now they have proposed it for the Intl top-level object itself. Frank and Ujjwal approved, I think it’s a good idea too. Frank even made a V8 CL.
SFC: Any thoughts on this? Otherwise I will record consensus.
EAO: Good idea.
SFC: We didn’t get consensus on this PR during the last meeting IIRC.
LEO: We actually did; see ECMA262 issue #2057.
SFC: perfect. In that case, we did get consensus during the July meeting.
LEO: no pressure, but we can merge this in if we get consensus right now.
SFC: Ok, I'm gonna record consensus.
TC39-TG2 Consensus.
USA: I think I've resolved all the comments. But I need people to give an approving review. I'd like everyone to go back and hit the review button if everything looks okay.
SFC : Sounds good to me, we should provide links to Issues(Jeff and Frank) and MDN
USA: I'll follow up with FYT and JSW.
https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange
FBN: I think we're on track for Stage 4. What's the process for reviewers?
SFC: the process is that you ought to open a PR for the upstream ECMA-402 repo and we can merge this in once everything is ready.
RCA: this should come alongside updates to MDN.
SFC: do you specifically mean the compat table?
RCA: I precisely am referring to the compat table, the MDN text is already there for these PRs anyway. Should we track it on the ecma402-mdn github repository?
SFC: I think we should reopen the old issue.
FYT: Is it true that we need to make a version of the spec in Stage 4 with the ins and del tags? Or do we only need the PR?
RGN: Those tags are most useful for rendering spec changes. I use them and I see them in proposals. But the PR itself should just make the change.
FYT: question: there are some concerns from anba. What’s the nature of those concerns? I haven’t had the time to look into it so far. Do you think we’re ready for Stage 4?
FBN: Yeah, so I put that PR together and sent it for review. It's mostly an issue that ABL pointed out, that we're missing options for locale data. But we are saying that the implementations must have that data available, because these are new fields used only for range formatting. ABL proposed a change that I liked, which I proposed for the spec. But this shouldn't affect implementations.
FYT: So you're saying that ICU outputs the desired result, but the spec is missing that detail?
FYT: Yes.
https://github.com/tc39/proposal-intl-enumeration
FYT: We got to Stage 1 in July. We added some options for the timezone and are working on figuring out some options for regions. Let's say you pass in Switzerland; it may return different values as opposed to passing in “United States”. There are some questions about the use cases. There are some open-source JavaScript libraries providing similar functionality. But I wonder what questions people have before I go to Stage 2.
ZB: I have deep reservations whether we should do this because of fingerprinting. I think this PR is fully overlapping with HTML for pickers, and I think HTML can handle privacy better. But I don't have deep privacy knowledge.
SFC: There is an issue on the repo, issue #3 regarding privacy issues. It would be good to get a follow-up on that issue.
tc39/proposal-intl-enumeration#3
ZB: I think we should get feedback from a privacy team, maybe Chrome or Apple. I know Mozilla is having to deal with supported fonts having privacy issues. So I'm concerned, but I might be wrong.
FYT: Comparing this with fonts is very different. A user could download new fonts, so fonts could be unique to that user. On the other hand, the number of time zones is based on the OS or the browser supports, and users can't change the set of time zones. ZB, do you have references to whether anyone is working on this in the HTML side?
ZB: I think working with HTML would make sense assuming the dominant use case is for pickers. You're right that fonts are different, but it's still a way to enumerate info about the user. So my question is, if we land this in browsers, are we going to make work for people from other domains to clean up the privacy problems?
USA: For the specific use case of time zone pickers, something on the HTML side makes sense. But I think pickers aren't the only use case. This is an iterator so that someone dealing with time zones can programmatically access the list of time zones. Also, because the result of this depends on your browser version, I don't know how this could provide fingerprinting beyond that of user agents.
ZB: If you look at the list of APIs that's in the proposal, it's quite a few bits of info. It sets precedent for potentially adding similar functions in the future. So the question is whether we can design this API in a way to protect privacy, so that V2 doesn't need to be incompatible.
SFC: The high bit is that we need to get a privacy expert involved.
EAO: Another question is whether these endpoints would vary between browsers. We clearly don't have an understanding of it at this time.
SFC: as mentioned in the issue, the source of all of this is the CLDR data. In Safari, that is linked to the OS version, for Chrome and FF, it is linked to the browser version.
ZB: Yes, but we're also talking about making our constructors asynchronous, which could cause additional data to be loaded. For example, maybe you visit controversial websites written in a different language and have data loaded from those websites.
USA: That's a good point.
RCA: If we're exposing with these APIs specific data from CLDR that is always the same, what is the point of getSupported? Because we're conditionally loading these lists.
FYT: When we say “the same”, we mean within that version. If you upgrade your browser, you may get a different list.
https://github.com/FrankYFTang/proposal-intl-locale-info/
FYT: This is based on issues #6 and #205 on the ECMA-402 issue tracker. For Locale, there are certain things associated with the locale that may be useful for the user to get. I put those together.
One is the weekday data. Zibi already has mozIntl.getCalendarInfo. And there are some not-internationalized JavaScript APIs that give you the first day of the week. But the fact that those libraries exist speaks to the use cases. The week data provides basic information: what is the first day of the week? Where does the weekend start and end? How many days need to be in the week to be considered the first week of the year? There are questions on Stack Overflow. We also have ICU4C/ICU4J for this.
Another is language direction. Given a language, is it RTL or LTR? It should really be "is it bi-di", since no language, not even Arabic, is strictly right-to-left. There are third-party libraries that do a similar thing.
Then, there’s something called a “measurement system”. Currently, I don’t think ICU exposes everything we need for this, there’s a different set of functions in both Java and C, but data is in CLDR. I don’t know how exactly we need to expose that information. One solution is that we can just add getters to Intl.Locale and we keep adding more getters as we go. The second approach is to add a function to Intl, and you can pass the info you need in a string, this is closer to how Mozilla does it currently. This is still up for discussion. I want to discuss if this is meaningful to move to Stage 1.
JSW: This is perfectly reasonable information.
ZB: I am also in favor of this and this looks like a pretty solid API. This is important info that I can give numerous use-cases for. Lots of applications would require this kind of information eventually.
SFC: I like this idea, but I’m not sure what the final API should look like. I would point you to issue #409 where DE proposed getters like “preferredCalendar” and more. For locale, we’d check the extension key and if none exist, we’d have to fall back to the base locale. Therefore, we need to see how this works alongside the user preferences use-case. Eventually we’d reach a point where locales would have user preferred values and we need to make sure these two work well together.
FYT: but the locale already has the user preferences, whether it is in object or string format. This is different from the question of user preferences, which might have its own set of privacy concerns.
SFC: Locale identifier keywords is a mechanism within the vision for user preferences. The point is that if you get a locale identifier that has a keyword like hourCycle, you should return that keyword, or else fall back to locale data.
FYT: there’s multiple ways of dealing with this. That said, we can discuss that at more length at Stage 1, this is definitely not a concern that needs to be addressed right now.
SFC: I agree, we should answer these questions at Stage 1, before Stage 2.
FYT: would you like to co-champion this?
ZB: I can help with specific requests but I cannot commit to co-championing this currently, apologies.
SFC: Do we have consensus for Stage 1?
JSW: +1
EAO: +1
USA: +1
Consensus for Stage 1.
https://github.com/FrankYFTang/intl-displaynames-v2/
FYT: Intl.DisplayNames has got to Stage 3, and we’re looking at Stage 4. This is a set of enhancements to that proposal. We’re mainly considering two enhancements.
The first one is: weekday names and month names. Originally we had weekday names and month names, but due to challenges with calendars with leap months and Temporal, we took it out of V1. But for V2, I think we should find a way to put it back.
Next is that NumberFormat is shipped with units, and there are times when users have a UI with a column with labels like "meter", which requires a unit display name. It was originally tracked in Intl.DisplayNames issue 34. I think we need to work on the use case in a little more detail.
Next is time zone names. People can hack around with the DateFormat API, but it might not be correct. For example, daylight savings time is confusing, because it varies from northern to southern hemisphere.
The other two are numbering system and calendar names. For example, the Islamic Calendar (there are 3-4 types), etc. Maybe we decide it's not that important, but it's an option.
Finally, we would consider Supporting Dialect. SRL suggested this one. It's talking about when we ask for a language… I'd like to discuss use cases.
JSW: What is the use case for time zone names?
FYT: Pickers.
JSW: If they build a picker, would they have America/Los_Angeles instead?
SFC: There are metazones as well as specific time zones like “Pacific Daylight Time”. This makes much more sense in different languages, for example “India Standard Time” translated in Hindi would make so much more sense.
USA: A lot of people don't know about America/Calcutta, which is generally what they should be using.
JSW: People living in Arizona don't have local variants from the norm.
PFC: In my opinion the most effective time zone pickers are map-based.
SFC: It is still useful to have localized strings.
PFC: no pickers are quite ideal because timezones aren’t ideal.
JSW: I'm looking at the GNOME picker. It has a drop-down.
SFC: do we want to discuss which of these we want to promote or should we promote the whole proposal and discuss the rest later?
FYT: If people have opinions on what should or shouldn't be here, now is a good time to express it. Priorities are also good to know.
ZB: My experience is that weekday and month names are the most commonly requested from frontend engineers.
SFC: I made a comment that we can deal with at least month names (the problem being with leap months). I think we can use Temporal.YearMonth. reasonably by casting Temporal YearMonth into DisplayNames. For weekdays, maybe we can qualify them to be called “modern weekdays” because of historic calendars. Temporal has progressed to a point where we can discuss this in more detail.
FYT: Can you talk about the YearMonth thing in more detail?
SFC: Temporal.YearMonth can be a year and a month in an arbitrary calendar system. By using this, we don’t have to figure out a weird way of dealing with leap months. In the Hebrew calendar, things get messy but this allows us to unambiguously deal with this problem.
JSW: We're missing month, weekday, quarter, day period, and datetime field. I think day period is especially important.
SFC: The first two are covered but the last three aren’t.
FYT: I can put those back.
ZB: The problem with day period is that it doesn't span across all cultures. We could figure out some way to deal with them, but it would potentially get pretty messy.
FYT: day period is indeed very tricky. CLDR has two definitions of day period, one which you mentioned and the other is AM/PM. We need to be careful when discussing this.
SFC: It’s not perfect but it’s not horrible to use Intl.DateTimeFormat with a single field. It doesn’t give us a few things that DisplayNames does, but it does handle a lot of these things much better.
FYT: The problem is you have to construct a Date first. You have to figure out the date and time zone. You're forcing the engineer to do steps beyond what they need to do.
SFC: Hopefully this would become much easier with Temporal, but I get your point.
FYT: Can I have someone to help me with use cases to express how important this is?
YMD: I could help.
FYT: Which one could you help with?
YMD: You talked about the islamic calendar. I could help with those cases.
RCA: I can help with week and month names.
SFC: Peter Edberg wanted unit names for Apple. I can look those up.
JSW: Would you include data for compound units? Like kilometer-per-hour?
SFC: Good question. I think we'd only want to expose the data explicitly in CLDR. kilometer-per-hour is supported, but not kilojoule-per-furlong, but right now ECMA-402 doesn't distinguish between those two.
FYT: Can we move to Stage 1 in the next TC39 meeting?
SFC: I have Stage 2 concerns for the weekday/month/dayperiod, but I think we’re good to go for Stage 1. It would be useful to write example code for how you can do this today in DateTimeFormat, and then what the code would look like in Temporal and in Intl.DisplayNames V2.
FYT: sounds like a decent approach. Do we have another meeting for the deadline for the next meeting?
SFC: Yes.
FYT: perfect. We can discuss this in more detail next time once I’ve put in some more work.
Consensus for Stage 1
SFC: reads CP’s response
SFC: this predates Caridy’s time as editor, we should ask NL.
LEO: You can ask RW about it too.
SFC: I see three options:
- Continue adding items to Section 2 that could throw RangeErrors.
- Keep Section 2 stable without adding new options to it.
- Remove items from Section 2 to make conformance requirements stricter.
LEO: I like Option 3 and removing the third paragraph of Section 2. However, Option 2 is the safest and most convenient.
FYT: I don't have a strong opinion. I think that Option 2 is the status quo and isn't too bad.
PFC: In Temporal, we plan to use options bags similar to 402. There isn’t any precedent for such options bags in 262. For that reason, we’d like to move the abstract op to 262 and 402 pick it up from there. At the very least, we’d want the two to be the same. The current GetOption in 402 is a bit weird. It boxes primitives and tries to read them then, which makes little sense. This behavior never really shows up in 402. This includes two commits: one is editorial which doesn’t change behavior in 402. That said, there’s a normative commit after that which does change the behavior, because the current behavior seemed strange and we wanted to change that if possible in a web compatible way.
SFC: right now when you call an Intl constructor with an options arg which isn’t an object, we call ToObject on it. The reason it’s not an editorial PR, we’d throw a typeerror instead of calling GetObject.
JSW: the only case we can be worried about would be accidental cases in which case this was done but somehow worked because the caller was expecting the default behaviour.
FYT: so do you mean
SFC: I want to separate the semantic issue and the spec issue. The important question here is, are we okay with the normative change here.
FYT: I agree but I don’t think it’s as simple as an editorial issue.
SFC: Let me start with this question. Does anyone think the original behavior is better than the proposed version? In this case, Temporal would like to adopt this. The question now is, do we need to match it in 402 or do we keep doing what we do?
SFC: we can stick to the new behavior in Temporal, rename the GetOptions to something like LegacyGetOptions and use GetOptions moving forwards.
???
SFC: we call GetOptions multiple times sometimes. Is type checking observable?
JSW: that depends on the implementation.
RGN: to answer SFC’s question, no.
FYT: Is there a Type abstract op?
RGN: It’s just a notation.
SFC: We can explicitly move those 4 lines to something like “NormalizeOptions”
RGN: That seems to be an improvement in itself.
FYT: that would be observable. The current PR is an improvement over that.
SFC: I propose we only call it once, at the top.
FYT: I would suggest we discuss this on the issue tracker.