- Shane Carr - Google i18n (SFC), Co-Moderator
- Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Eemeli Aro - Mozilla (EAO)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Daniel Minor - Mozilla (DLM)
- Yusuke Suzuki - Apple (YSZ)
- Philip Chimento - Igalia (PFC)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
USA: Merged #721, DefaultTimeZone changes
RCA: Technical preview is released
EAO: Looking forward to the message bundle proposal
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
No updates.
USA: This PR needs to be approved by TG1 , expands current behavior by adding “GTM” to the supported formats, do you all agree ?
LAF: What's the impact? That you can specify "GMT" without "Etc"?
USA: We're following semantic behavior that already existed
PFC: I don't believe Temporal makes a distinction between UTC and GMT
RCA: +1
LAF: +1
PFC: +1
FYT: +1 , I believe that Chrome already behavior that way for long time
Approved by TC39-TG2
RCA: There were 2 issues being solved in the same PR.
USA: Could FYT review this later when you have the time?
FYT: Will do.
RCA: The 2 issues are handling the 0 option, and allowing display of up to 9 fraction digits, which is what Temporal is doing.
FYT: With this change, if I create a DTF with fractionalSecondDigits set to none, what will happen?
SFC: We should move this discussion offline.
FYT: I'd like the PR author to write more about the intention of the PR.
RCA: I’ll provide the description/intention of PR
SFC : We can get pending approvals from this group and final approval next plenary , YSZ has pending task reviewing it
FYT: I have a suggestion for recurring PR’s , how about agreeing that one month after ICU release we can have test262 so engines can adapt during that month, so if conditions are fulfilled we can talk about that.
SFC: We discussed last year, and we opened a meta issue to work on this, the intention is to have this reflected on the Wiki page along with other updates, but still in our backlog, but a formal process would be the best.
SFC: We should add this issue to the agenda when someone can have a concrete proposal for it (Editors/USA/RCA…)
USA: Should I present this at the next TC39 plenary meeting ?
FYT: Should this one be merged ? They have already been discussed.
Merged
https://docs.google.com/presentation/d/1REfjL8HBfAQQoXzG69kk43ywuT2hW5SuJCNtYxWPAJk/edit#slide=id.p1
RCA: (presents slides)
FYT: Thanks for the presentation. It seems the presentation touches IETF-related things. One of the difficulties is the impact to the Web. As a frontend engineer, who used to work on Google Translate, we need to reduce the network latency. More and more HTTP headers increase latency. Adding more headers increases the number of bytes over the internet. Loading an article from cnn.com, for example, there are dozens of requests, for images, JSON, etc., so increasing header size dramatically increases the overall bandwidth on the internet.
FYT: Second thing, about the JS part. I understand that this is a larger presentation, but for talking to TG2, we don't have the concept of a user. So it should focus on the API for the settings. And otherwise, it should likely go to the W3C. This is the wrong body for it.
RCA: For the first question, Client Hints are already defined on IETF. There's a concern about the size.
RCA: On the W3C side, we are already pushing the proposal on that side. I'm bringing it here because it's the first place those issues were raised, and there are some pending points here that will help the proposal move along.
YSZ: Thanks for the presentation. We didn’t have a link to the draft at that time, but discussed this internally at Apple WebKit team. We've discussed exposing user preferences. It seems like a significant improvement to accessibility and usability. This kind of information can improve the Web; for example, if we hit a web page with Kanji. But, this kind of thing needs to be very carefully balanced. It's a super-strong fingerprinting vector. For example, if you set the measurement unit to celsius, from the Bay Area, with a custom hour cycle and date format, the web page can easily identify my identity. People set this in the OS, and if we expose it, it becomes too powerful. My current feeling is that we are thinking that this is a great improvement, but we should ask the user for permission. For example, if a weather web page is asking for the temperature unit, that's OK, but if a random blog page is asking for it, maybe not.
RCA: I totally agree that this is a sensitive topic. Every detail should be agreed in a way that protects the user. I'm also curious about your ask for asking the permission. Should it go on the same level as asking for your webcam?
DLM: I met with two members of our privacy team to get early feedback. I passed it on to RCA already. There are definitely fingerprinting concerns. The team urged us to try our best to minimize the vector as much as we could. Rather than expose everything we possibly could, we should expose only those we feel the need to, or even perhaps specify a certain about of granularity for the preferences. From our point of view, the fingerprinting concern is pretty much the only one we have. The privacy team is willing to formally review a later draft but this is pretty important issue for Mozilla. In general, Mozilla has a lot of concerns about user consent so I agree with Yusuke’s concern but it’s necessary to discuss how to help them make informed decisions.
RCA: I'd love to ask DLM and YSZ to open issues on the repo with ideas on how to balance these issues and have a list of user preferences that might fit on all use cases and at same time safe for end user.
SFC: It seems like the privacy issues should be handled more in the way that browsers handle cookies (which are the ultimate fingerprinting vector). I agree that asking for permissions in the way we ask for webcam permissions is not going to be meaningful to a lot of users. I'm glad that we are approaching this in a privacy-first way.
USA: One of the reasons we're doing this via Client Hint is to reduce request size. About permissions, the way this feature is specified gives implementations a lot of ways to protect users.
FYT: You can't assume that a JS or an image request won't need user preferences. We shouldn't make an assumption that different types of requests don't need the data. There may be more than one user per IP. In response to DLM and YSZ, if you look at a camera model or text-to-speech model, a lot of those ask for user permission based on per site or per page. For example, maybe I want to give my language preferences to Google Translate, but not a web page belonging to the PRC. The API may be designed in a way that could filter locale settings. There's a lot of stuff: time zone, collation, language. Maybe I'm fine allowing people to know my time zone and hour cycle, but maybe not that my preference language is French or Chinese. So maybe it should be a more granular access to locale settings. If you create this model in a way that everything is asked at once, users need to give a big "No" or a big "Yes", which is not great.
USA: This can be done on either side, on the host or the browser.
RCA: The main reason of splitting this into different options is to not provide all the options as a unique string to the server. I think the mechanisms already provided by Client Hints are quite strong for privacy. On the JS side, we should try to be more creative.
FYT: If I have a web site, and I only want to know time zone, the browser has to ask the user for 30 other things. That's annoying and not useful. The second issue is that if you want to follow that model, there has to be a way to distinguish between a client answering a value… you need to distinguish a user declining to answer. Because then the API caller needs to respond to that.
EAO: Has thought gone into this with respect to reducing the dimensionality that this allows identification of users? We're talking about many different values here: preference on time zone, temperature units, etc., which are all different dimensions. Could we collect sets of these into baskets that would allow a user to say, yeah, I want preferences coming from this basket, which might be closer than the en-US defaults?
DLM: The basketing idea was one of the suggestions from the privacy team. Thanks for bringing that up again. It seems like that might be a viable means of minimizing the fingerprinting problem.
RCA: The difficult part is identifying the bucket of options.
SFC: Regarding the bucket ideas, I worry it would be hard to define those. For example, for unit preferences, we can say I want all user preferences of this region, but translations from another region. But, some folks want temperature units in celsius, but prefer miles over kilometers… this makes it hard to specify in a direction that improves and gives a rich user preferences experience. So I would rather focus on the privacy issue and have a mechanism to access the information with higher granularity without sacrificing the value proposition.
FYT: One thing is traditionally is associated with this locale preferences, example font-family, font-size, font-color, text-to-speech voice (male/female), speed… those could be considered as locale data and related with cultural and language, so we should consider them in the list, too.
EAO: The basket approach would not solve the issue precisely but will be a good option for a majority of people.
USA: The things FYT mentioned seem out of scope.
FYT: Choosing different fonts seems totally i18n related. You might want a different font for Japanese vs Chinese.
USA: You can already specify whether you want your browser to use certain fonts in priority order.
FYT: I just want to point out that fonts are i18n. Maybe there are other ways to solve this problem.
EAO: You can calculate font from measurements. But this is a side-track.
RCA: Thanks everyone for your feedback.
RCA to respond to the feedback from above.
SFC: Should we make this proposal depend on Temporal, since Temporal gives us all the things we need? Or should we move forward as a standalone proposal?
USA: I think that the emphasis on era is common in Temporal. Pre-Temporal, we also don't have the idea of an era in 262. Not that 262 has any special reason… But I think it's not unreasonable to couple this with Temporal. The ease of implementation. We could take a long term strategy, but hopefully not too long-term, since it shouldn't be long before Temporal is finalized. So it seems to make sense to hold for Temporal.
FYT: I am a bit lost when you talk about depending on Temporal from the now object. What’s not supported by Date which also exposes the current time.
SFC: How to get current time is a bit of a red herring, since we can get the current time through other ways. Temporal.Now.plainDate().era gives us the current era, so it avoids duplicating some of that work. But indeed, the current date can indeed be done in the language currently.
EAO: My question is , if we implement this now as in implementation defined behavior and later we use Temporal , would this allow this to land without Temporal dependency ?
SFC: That’s definitely the approach to get them decoupled if we decide to go down that road.
USA: I think one of the persisting problems in the spec are the duplicated normative procedures, example : two different ways to determinate the era… so I support having a single way to determinate the ERA
LAF: I am ok with decoupling EraDisplay from Temporal.
SFC: Looks like the group is ok decoupling this from Temporal, I would like to have a Stage 2 proposal for the next TC39 meeting, I would like to prepare the proposal beforehand and present at TG1 then at the next TG2 meeting have our approval, so I would like to ask permission to move forward with current idea of decoupling proposals so after TG1 we can approve it at next meeting,
USA: One thing we might have the privilege of knowing here is, what sort of timeline are we looking at here? What timeline are we looking at if we decouple or not these two proposals?
SFC: I can follow up with with FYT offline to check if this can be implemented
SFC: This will be implementable on top of ICU4C, but hopefully easier on ICU4X.
SFC: Okay, so I'd like to prepare the Stage 2 proposal for December TG1.
DLM: That will be the decoupled version?
SFC: Yes.
SFC to put the presentation on the TG1 agenda and mail it to this group.
FYT: There are inconsistencies on test262 when ICU changes things, so test are breaking because of a pattern change, the question is should we eliminate this kind of tests that have dependencies on ICU ?
SFC: We had similar discussion years ago and is difficult to test behavior without using this kind of approach , is important to not reduce quality of tests but would be nice not having those tests depending on external dependencies
PFC : If we can have a list of questions for next test262 maintainers meetings , my opinion is that test262 should serve to ease implementations , but if this kind of tests cause friction to update tests we should do less tests of this type whatever best for test implementations
DLM: I reviewed Anba's updates, I don't think these test failures caused a great deal of work during the update.
YSZ: We have encountered this type of problem for a long time. Apple's ICU is slightly customized from upstream. The tests should test the spec. I think that one approach we're taking for some of the tests is to… it's hard to test features on Test262 without depending on CLDR data. I think testing grassroots is the easiest solution.
FYT: We could test, does this string contain the substring "March"? So we could do the easy thing, and update the data, or we could make the tests more complicated and corresponding to the spec.
Add this to the agenda in the Test262 maintainers call.
tc39/proposal-intl-duration-format#128
USA: (introduces issue)
YSZ: Currently we don’t accept any Temporal object, accepting a string now originates a TypeError , so in future if we integrate with Temporal this would cause an error so if we align current DurationRecord to how Temporal behaviors would ease the integration and throw the same error for both cases
FYT: I agree with YSZ's analysis. Currently, the Temporal proposal doesn't have DurationFormat. So what will happen is that if you pass a string into DateTimeFormat, by the Temporal spec, for DateTimeFormat, that will actually… it will throw a RangeError.
USA: If we special-case in this proposal all string to throw a RangeError, and invalid objects throw RangeError, etc., would that be okay? And then we can change the behavior when consolidating with Temporal.
YSZ: The proposal I have is, taking a string and throwing a RangeError. My proposal is saying that in Intl.DurationFormat, we can accept a string, but right now since Temporal is not integrated, this syntax is currently empty.
SFC: I don’t recall discussing the behavior when strings are passed to format function, currently DateTimeFormat try to parse format as number and to a Date, in case of temporal might be not be feasible, I don’t thing we had this discussion when string is passed I should try to convert into an Temporal object, if we do should be a special feature of DurationFormat, since changing DateTimeFormat would not be web compatible.
YSZ: This conversion from string to temporal.duration is not a feature request, is just to use the same AO, in future we should create a function that only works like this.
FYT: I believe this is related with spec alignment between DurationFormat and Temporal, the biggest issues IMHO we have similar but not an 1:1 alignment between proposals which make more confusing
SFC: There are two questions here , should we accept string and parse it as TemporalDuration and at moment throw the RangeError, should we accept a string or not ?
USA: Past TG2 meeting we had consensus that in future we should expand the proposal to support strings
SFC: I’m fine supporting strings
PFC: +1 for string. a design principle for Temporal was that any entry point taking a Duration would also accept a property bag, or a string, so I think it would be surprising if DurationFormat was the only entry point that deviated
USA: So should we throw RangeError for only strings?
FYT: I agree
SFC: I agree
LAF: I agree
RangeError, strings only
tc39/proposal-intl-duration-format#55
SFC: We have a Google use case involving different font sizes. For example, in "1:23.456", the minutes, seconds, and fractional seconds may want to be different font sizes. Similarly, in "1 hr 5 min", the units may have a different font size than the numerals.
FYT: We should in the thread have a concrete thing we can discuss, with an example for digital and non-digital.