Merge branch 'master' into FrankYFTang-patch-3

meetings/notes-2023-01-12.md

@@ -5,7 +5,7 @@
 ### Attendees
 
 - Shane Carr - Google i18n (SFC), Co-Moderator
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Daniel Minor - Mozilla (DLM)
 - Eemeli Aro - Mozilla (EAO)
 - Frank Yung-Fong Tang - Google i18n, V8 (FYT)

meetings/notes-2023-02-09.md

@@ -9,7 +9,7 @@
 - Henri Sivonen - Mozilla (HJS)
 - Richard Gibson - OpenJS Foundation (RGN)
 - Frank Yung-Fong Tang - Google i18n, V8 (FYT)
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Eemeli Aro - Mozilla (EAO)
 - Yusuke Suzuki - Apple (YSZ)
 - Louis-Aimé de Fouquières - Invited Expert (LAF)
@@ -194,7 +194,7 @@ HJS: I think we shouldn't add more API. I don't want to provoke this question be
 
 SFC: I’d like to record a conclusion. 1: we expect that it’s okay for implementations to differ. 2: Ideally we should document this in prose (either in the spec or MDN) on what this is used for. Currently on MDN: usage: “search” and “sort” are two options, maybe add a few sentences documenting this. 
 
-BEN: +1
+BAN: +1
 
 MWS: +1
 

meetings/notes-2023-03-09.md

@@ -8,7 +8,7 @@
 - Ujjwal Sharma - Igalia (USA), Co-Moderator
 - Henri Sivonen - Mozilla (HJS)
 - Romulo Cintra - Igalia (RCA)
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Yusuke Suzuki - Apple (YSZ)
 - Richard Gibson - OpenJS Foundation (RGN)
 - Justin Grant - Invited Expert for Temporal (JGT)
@@ -115,7 +115,7 @@ YSZ: This sounds great.
 
 ### User Preferences Update
 
-BEN: We've largely been focused on ways of gaining user consent. Since last meeting, it seems that there is no consensus on the methods of gaining consent. A pop-up asking for permission like camera and microphone doesn't seem to align with stakeholders. The other approach is to have it set as browser preferences. But, we're trying to move focus more to exposing this data in a way that makes it harder to individuate users. What I've heard is that we should limit the ways users can set. So for example, rather than letting users specify their currency, digits separator, and temperature units, which gives a big fingerprint, give users a smaller number of sets that are commonly used, i.e., deviations from one's locale that are common use cases. There are technical and social problems that need to be resolved. For example, how do we make a JavaScript API so that these sets can be selected? (1) How do we decide what these sets should be, like with user research? (2) How do we decide on these sets without being colonialist? So I would like to start with a couple of questions. The first that comes to mind is that if we're reducing the sets of preferences people can select to a smaller number, can users specify an arbitrary region? For example, if we allow users to specify that they want sites to serve up a specific currency, we can only have a few currency options in those sets. Would it be too individuating to have a common set of preferences, which doesn't accommodate currencies, but have region overrides?
+BAN: We've largely been focused on ways of gaining user consent. Since last meeting, it seems that there is no consensus on the methods of gaining consent. A pop-up asking for permission like camera and microphone doesn't seem to align with stakeholders. The other approach is to have it set as browser preferences. But, we're trying to move focus more to exposing this data in a way that makes it harder to individuate users. What I've heard is that we should limit the ways users can set. So for example, rather than letting users specify their currency, digits separator, and temperature units, which gives a big fingerprint, give users a smaller number of sets that are commonly used, i.e., deviations from one's locale that are common use cases. There are technical and social problems that need to be resolved. For example, how do we make a JavaScript API so that these sets can be selected? (1) How do we decide what these sets should be, like with user research? (2) How do we decide on these sets without being colonialist? So I would like to start with a couple of questions. The first that comes to mind is that if we're reducing the sets of preferences people can select to a smaller number, can users specify an arbitrary region? For example, if we allow users to specify that they want sites to serve up a specific currency, we can only have a few currency options in those sets. Would it be too individuating to have a common set of preferences, which doesn't accommodate currencies, but have region overrides?
 
 HJS: Last time there was a use case regarding numbering systems in India. Is there a list of user stories that are realistic and need to be addressed?
 
@@ -136,7 +136,7 @@ YSZ: At the moment, we have the following mental model: <>, some of the users ca
 
 USA: I think 
 
-BEN: I love the distinction made by Yusuke between UI-critical and non-critical things. That said, there’s a grey area here. For example, a ticketing app having minor misunderstandings can cause a lot of problems. Regarding the translation question, I would prefer the elements to be translated.
+BAN: I love the distinction made by Yusuke between UI-critical and non-critical things. That said, there’s a grey area here. For example, a ticketing app having minor misunderstandings can cause a lot of problems. Regarding the translation question, I would prefer the elements to be translated.
 
 EAO: Two things: firstly, what Henri mentioned about the list of use cases. It would be nice to hear about that list of use cases. Secondly, what I was really thinking about, when talking about user preferences where the user doesn’t set the preferences, for example in a public computer. These user preferences would be telling the website the wrong information. Is there a way to get this toggling mechanism, or would a website be able to integrate it? And if so, will they have to forgo user preferences completely?
 
@@ -149,7 +149,7 @@ YSZ: Quick comment, are these things public or not.
 
 SFC: Two general things here: first, regarding the idea of ambient preferences. We can conclude that the best solution would be for all Intl APIs to use a selected locale. That said, there’s also the thing regarding the default locale. It is a limitation of the current web platform to not use the full set of locale options that are specified in the Unicode spec. The second question is, can there be a line between essential and non-essential preferences? That’s a gray area. Numbering systems for example is well supported. In terms of measurement units, it’s harder to draw this line. It’s true that people in the world can do a conversion inside their head, but it would be bad for accessibility to mandate that. For hour cycles, it’s easier to accept but it’s a bit harder for people to read the time with the opposite hour cycle so it gets to a situation where we have to judge which sets of preferences are more important than the others. Maybe it’s possible, but I’m skeptical when I hear this.
 
-BEN: There’s two ways to think about getting the most coverage. One is to find the sets of preferences which covers the most individual users, which we can determine with user research, and the other is to find the set of overlapping preferences that cover the widest range of users, even if this doesn’t necessarily cover the maximum number of users. 
+BAN: There’s two ways to think about getting the most coverage. One is to find the sets of preferences which covers the most individual users, which we can determine with user research, and the other is to find the set of overlapping preferences that cover the widest range of users, even if this doesn’t necessarily cover the maximum number of users. 
 
 USA: Raises the question of fairness: I don’t want to be in the position of answering these questions. Although I do like the idea of restricting user choice, I’m not certain that the end result will be equitable.
 
@@ -171,21 +171,21 @@ HSJ: There has already been the suggestion to drop something like currency since
 
 Conceivably someone could pick some of the other ones, but the other ones potentially the traditional collation is a thing. CLDR has it for Finnish and Swedish. For Finnish I can say confidently that users don’t care about it, for Arabic I’m not certain it matters for the Web that CLDR ships what’s old for ICU. For CLDR, they don’t want to unship a thing that has been shipped. For the collation one, Taiwan and maybe Spain are ones where there are two different choices. 
 
-BEN: Something I’ve been thinking about is that some amount of this data is necessary to be exposed for localization and is there a case to be made that we need to design mechanisms to ensure that when that information is exposed, it’s exposed in as responsible a way as possible.
+BAN: Something I’ve been thinking about is that some amount of this data is necessary to be exposed for localization and is there a case to be made that we need to design mechanisms to ensure that when that information is exposed, it’s exposed in as responsible a way as possible.
 
 USA: Related to what EAO mentioned, from my understanding there’s at least a number of language, the ones I would know of would be about 10, where there’s significant variations. With the variations we see, the popular ones are most lower (?)
 
 SFC: In response to what HJS said, that seems like another path. We support zh-TW and zh-TW with Pinyin collation, if that’s a common use case. We could support en-US and en-US with celsius – variations on existing locales. That’s an interesting direction to explore. We currently support any variation of language, script, and region. We could take this set of 250 of the most major language-script pairs and increase it to 275, we’re increasing the combinations that users can specify.
 
 EAO: Voicing my support for that idea: talking about or considering a set of individual locales or sub-locales for which we would be solving actual real-world problems within these groupings, so the question of Taiwan, American English with Celcius, would be much easier to start verifying that these populations are sufficiently large that we could get some utility for something like this with fewer privacy concerns. 
 
-BEN: I have enough info to proceed. It seems like the group consensus is to focus on selecting commonly used sets and also pinpoint the most popular ones.
+BAN: I have enough info to proceed. It seems like the group consensus is to focus on selecting commonly used sets and also pinpoint the most popular ones.
 
 SFC: That’s certainly a proposal that was raised.
 
 AVK: I think you need to first come up with a set in order to perform a proper privacy analysis. I feel that most popular places to see things like temperatures and distances come with individual toggles to choose the appropriate units. Things certainly get more complicated but you need to find out which problems that bothers users most. 
 
-BEN: It seems like the numbering system is the higher priority thing here since that’s one of the bigger things when it comes to making a website unintelligible.
+BAN: It seems like the numbering system is the higher priority thing here since that’s one of the bigger things when it comes to making a website unintelligible.
 
 EAO: On that topic, maybe we can try to provide better defaults like “International English”.
 

meetings/notes-2023-04-06.md

@@ -9,7 +9,7 @@
 - Daniel Minor - Mozilla (DLM)
 - Chris de Almeida - IBM (CDA)
 - Yusuke Suzuki - Apple (YSZ)
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Richard Gibson - OpenJS Foundation (RGN)
 - Justin Grant - Invited Expert for Temporal (JGT)
 - Frank Yung-Fong Tang - Google i18n, V8 (FYT)
@@ -530,7 +530,7 @@ SFC: We don’t have time for slides, will present next time, would appreciate p
 
 FYT: I want to make sure that anything we have merged into spec but don’t have clear consensus in TG1 or here so that we can present in May to have official consensus. 
 
-SFC: Hopefully we haven’t merged in anything normative that we don’t have consensus in. USA/BEN, can we review these to make sure we have them right from a process POV? 
+SFC: Hopefully we haven’t merged in anything normative that we don’t have consensus in. USA/BAN, can we review these to make sure we have them right from a process POV? 
 
 #### Conclusion
 

meetings/notes-2023-05-04.md

@@ -5,7 +5,7 @@
 
 - Shane Carr - Google i18n (SFC), Co-Moderator
 - Justin Grant - Invited Expert for Temporal (JGT)
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Yusuke Suzuki - Apple (YSZ)
 - Richard Gibson - OpenJS Foundation (RGN)
 - Eemeli Aro - Mozilla (EAO)
@@ -46,7 +46,7 @@ RGN: Cool, so I'll merge this in today, and I'll rebase any other PRs that we de
 
 https://github.com/tc39/ecma402/pull/770
 
-BEN: I think I'll take RGN's suggestion to split this into smaller work items.
+BAN: I think I'll take RGN's suggestion to split this into smaller work items.
 
 
 ### Normative: Reorder NF resolved option “roundingPriority”
@@ -393,7 +393,7 @@ https://github.com/tc39/issues/574
 
 FYT: This could be considered an editorial bug – currently it’s just undefined. This should have that section, but I can’t find it.
 
-SFC: Assigned to BEN.
+SFC: Assigned to BAN.
 
 ### Intl.supportedValuesOf('timeZone') for UTC, Etc/GMT*, and other non-contintent/non-ocean time zone identifiers #778
 

meetings/notes-2023-06-01.md

@@ -6,7 +6,7 @@
 
 - Shane Carr - Google i18n (SFC), Co-Moderator
 - Ujjwal Sharma - Igalia (USA), Co-Moderator
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Frank Yung-Fong Tang - Google i18n, V8 (FYT)
 - Louis-Aimé de Fouquières - Invited Expert (LAF)
 - Richard Gibson - OpenJS Foundation (RGN)
@@ -177,7 +177,7 @@ EAO: I think it’s arguable that in that case the platform has changed.
 YSZ: Right now lockdown mode is system-wide – it changes basically everything. So as you said, we can say that this is a different platform. 
 
 
-SFC: Let’s get another round of feedback from the Apple and Mozilla side on this pull request, and any changes we can make to it in response to Addison’s feedback. It would be good to follow up on this. BEN has made this PR based on feedback from Apple and Mozilla. 
+SFC: Let’s get another round of feedback from the Apple and Mozilla side on this pull request, and any changes we can make to it in response to Addison’s feedback. It would be good to follow up on this. BAN has made this PR based on feedback from Apple and Mozilla. 
 
 
 Conclusions:

meetings/notes-2023-06-29.md

@@ -6,7 +6,7 @@
 
 - Shane Carr - Google i18n (SFC), Co-Moderator
 - Ujjwal Sharma - Igalia (USA), Co-Moderator
-- Ben Allen - Igalia (BEN)
+- Ben Allen - Igalia (BAN)
 - Justin Grant - Invited Expert for Temporal (JGT)
 - Frank Yung-Fong Tang - Google i18n, V8 (FYT)
 - Yusuke Suzuki - Apple (YSZ)
@@ -85,7 +85,7 @@ YSZ: This sounds like we should add it.
 
 USA: We can record conditional consensus, or just consensus on the behavior but not the PR, 
 
-FYT: Did we already add it? I didn’t see it since BEN added the changes, I’ll need to review it.
+FYT: Did we already add it? I didn’t see it since BAN added the changes, I’ll need to review it.
 
 USA: We can tentatively call this TG2 consensus, but in the one week FYT and YSZ can take a look and we can discuss it further in plenary if there’s any comments.
 
@@ -219,7 +219,7 @@ JGT: Other concerns, especially blocking concerns? And as a note, I do want to a
 
 https://github.com/tc39/agendas/pull/1409
 
-USA: So the expectation is that everything should be discussed by our meeting once before it goes to the other group. Looking to document this as best we can. I’ve also been told that the way that we do normative proposal – presenting them at the end of the editor’s update and asking for consensus on all of them – is not correct. So what I did was I took the two normative PRs that we discussed and already had consensus on and added it here, in a new section (Needs consensus) for us. You may see that needs consensus in links to 262, the point is that all of the normative changes to 262 are done in this section, and we need to do ours as well. Going forward I will add each individual item here. Right now I’ve listed them to myself as presenting them, but I would also encourage you to all to present your own PRs if you’re there. I’ll ask BEN, we don’t have anyone from Mozilla on the call, but I can reach out to everyone behind the scenes so that it doesn’t have to be here. 
+USA: So the expectation is that everything should be discussed by our meeting once before it goes to the other group. Looking to document this as best we can. I’ve also been told that the way that we do normative proposal – presenting them at the end of the editor’s update and asking for consensus on all of them – is not correct. So what I did was I took the two normative PRs that we discussed and already had consensus on and added it here, in a new section (Needs consensus) for us. You may see that needs consensus in links to 262, the point is that all of the normative changes to 262 are done in this section, and we need to do ours as well. Going forward I will add each individual item here. Right now I’ve listed them to myself as presenting them, but I would also encourage you to all to present your own PRs if you’re there. I’ll ask BAN, we don’t have anyone from Mozilla on the call, but I can reach out to everyone behind the scenes so that it doesn’t have to be here. 
 
 SFC: Comments on process: for the PRs it’s good to list them.
 
@@ -255,7 +255,7 @@ https://github.com/tc39/proposal-intl-duration-format/pull/150
 
 USA: Next, what I believe is the last change for DurationFormat. This change is because we had consensus on the wrong change – misunderstood the consensus, presented to plenary a solution that’s not aligned with our consensus. Now it is. 
 
-SFC: That looks right to me – aligns with my expectations. No opinion on 158 – if [Anba] and BEN like it, I’m okay.
+SFC: That looks right to me – aligns with my expectations. No opinion on 158 – if [Anba] and BAN like it, I’m okay.
 
 USA: It’s pretty much the only option – we’re copying a PR that exists in Temporal, if we don’t the behaviour on our side would be different. 
 
@@ -297,7 +297,7 @@ SFC: Sounds great!
 
 Presenter: Ben Allen
 
-BEN: (presents slides)
+BAN: (presents slides)
 
 FYT: What does "auto" mean?
 
@@ -309,4 +309,4 @@ YSZ: It's nice that all the content in the repository… we need to discuss this
 
 FYT: With this proposal, you can be fingerprinted as one of a Xillion people, not one of ten or a hundred.
 
-BEN: It's all about reducing the minimum size of the anonymity set. So we can for example allow users in bigger locales to have more options than users in smaller locales. There's clearly a tradeoff there.
+BAN: It's all about reducing the minimum size of the anonymity set. So we can for example allow users in bigger locales to have more options than users in smaller locales. There's clearly a tradeoff there.