diff --git a/meetings/notes-2023-01-12.md b/meetings/notes-2023-01-12.md index efac4756..97574fe1 100644 --- a/meetings/notes-2023-01-12.md +++ b/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) diff --git a/meetings/notes-2023-02-09.md b/meetings/notes-2023-02-09.md index 502a5052..22fdf312 100644 --- a/meetings/notes-2023-02-09.md +++ b/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 diff --git a/meetings/notes-2023-03-09.md b/meetings/notes-2023-03-09.md index cd4bf2a7..52053ba7 100644 --- a/meetings/notes-2023-03-09.md +++ b/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,7 +171,7 @@ 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 (?) @@ -179,13 +179,13 @@ SFC: In response to what HJS said, that seems like another path. We support zh-T 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”. diff --git a/meetings/notes-2023-04-06.md b/meetings/notes-2023-04-06.md index ad0540c6..2b245c48 100644 --- a/meetings/notes-2023-04-06.md +++ b/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 diff --git a/meetings/notes-2023-05-04.md b/meetings/notes-2023-05-04.md index 82f99184..759f4988 100644 --- a/meetings/notes-2023-05-04.md +++ b/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 diff --git a/meetings/notes-2023-06-01.md b/meetings/notes-2023-06-01.md index 0aa520f2..38cbf790 100644 --- a/meetings/notes-2023-06-01.md +++ b/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: diff --git a/meetings/notes-2023-06-29.md b/meetings/notes-2023-06-29.md index cd1b5df8..06263bff 100644 --- a/meetings/notes-2023-06-29.md +++ b/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. diff --git a/meetings/notes-2023-08-03.md b/meetings/notes-2023-08-03.md index 751046bc..7f806eae 100644 --- a/meetings/notes-2023-08-03.md +++ b/meetings/notes-2023-08-03.md @@ -4,7 +4,7 @@ ### Attendees - Shane Carr - Google i18n (SFC), Co-Moderator -- Ben Allen - Igalia (BEN) +- Ben Allen - Igalia (BAN) - Eemeli Aro - Mozilla (EAO) - Frank Yung-Fong Tang - Google i18n, V8 (FYT) - Myles C. Maxfield - Apple (MCM) @@ -28,7 +28,7 @@ RGN: Have been away most of the month. Some small things landed. -BEN: Recently merged: well-known intrinsics iterator, etc., were added to the table, adhering to 262 style, and a few normative PRs that are up. Some fairly small re-wording "increase x by y" instead of "set x to x + y". Removed some unnecessary double negatives. +BAN: Recently merged: well-known intrinsics iterator, etc., were added to the table, adhering to 262 style, and a few normative PRs that are up. Some fairly small re-wording "increase x by y" instead of "set x to x + y". Removed some unnecessary double negatives. ### MessageFormat Working Group @@ -48,7 +48,7 @@ SFC: Looking at this table, it seems like we’ve got pretty good test coverage https://github.com/tc39/ecma402/pull/817 -BEN: (introduces PR) +BAN: (introduces PR) SFC: It does seem useful to have the extension keywords – I’m not sure if removing the tags from the locale is the right direction – we could go the other way. Then we can have the locale identifier and the options bag consistent with each other. I also worry that if we start removing this information it may not be completely web-compatible. Adding is easier than taking them back out, especially because the options for setting these are not that old. @@ -85,7 +85,7 @@ FYT: When [littledan] said that we should only do that when we have all of the o SFC: I hadn’t consider this when I mentioned favoring option 2: if we’re in a situation where the locale keywords and the options keywords are not always the same set, then we can’t always have the invariant that the locale and the options bag keywords are consistent with each other. Maybe the status quo is fine? “If we read the field value from the locale, keep the locale value the same, but if we changed it in the options, you have to read it from the option bag because we may not be able to put it back in the locale tag for you. It’s still accessible in the resolvedOptions() if you need it. -BEN: proposes adding a note explaining the behaviour? +BAN: proposes adding a note explaining the behaviour? EAO: One approach is to consider that we have two different ways that users may be giving the options to us. Do we have a preference between them? The options bag approach that the Intl constructors have are telling the story that this is the way that things are supposed to go. Are we making a explicit preference for one or the other? Like, “you can do it this way, you can do it that way, but this way is better” – and in this case, it’s the options bag that’s better. @@ -99,7 +99,7 @@ FYT: I propose no change – I don’t see a strong case to solve people’s pro EAO: +1 to that. -RGN: That makes sense, and I really like BEN’s idea of capturing the reasoning in a note. If nothing else, it will be relevant if this should come up again. Decision for now to not change behavior, and also to document the behaviour and its motivation. +RGN: That makes sense, and I really like BAN’s idea of capturing the reasoning in a note. If nothing else, it will be relevant if this should come up again. Decision for now to not change behavior, and also to document the behaviour and its motivation. SFC: +1 @@ -109,7 +109,7 @@ Keep current behavior, but add documentation in the spec. ### Locale Extensions? -BEN: Integrating feedback from MCM. +BAN: Integrating feedback from MCM. SFC: Hope to see a concrete presentation/update next month. @@ -169,11 +169,11 @@ RGN and FYT will work together on changes to the PR, which we will then bring to https://github.com/tc39/ecma402/pull/807 -BEN: (introduces PR) BestAvailableLocale did not handle `t` and `x` extensions. +BAN: (introduces PR) BestAvailableLocale did not handle `t` and `x` extensions. FYT: This is a normative change, but how are we going to test it? -BEN: That’s the hard question – ICU doesn’t use it. +BAN: That’s the hard question – ICU doesn’t use it. FYT: This isn’t a general exposable thing that if you ask a question it’ll give it to us, it depends on what the available locale is. Whatever comes out is limited to what the system supports. In theory we could have some T extensions, but practically I don’t think anyone ships T extension data. This is a theoretical case, since one part of the sets that need to be matched are not including the whole thing, at least not what we’re currently aware about. Theoretically, yes, practically, I don’t believe it impacts anything, therefore it’s difficult to test. @@ -211,13 +211,13 @@ FYT: How? SFC: Let’s treat this as normative just to be safe. -BEN: The problem is that the current state of the spec is buggy – if a hypothetical implementation tries to use `-t-` extensions, they’ll have invalid lookups. +BAN: The problem is that the current state of the spec is buggy – if a hypothetical implementation tries to use `-t-` extensions, they’ll have invalid lookups. RGN: Strongly agree with that; with the current spec text being buggy, I'm in support of a change. I need to review the details of this one. FYT: Looking at the PR, line 90 strips the Unicode locale extensions, and now you're removing it? Are you going to add it back? -BEN: In practice, everything using this AO strips out the Unicode extensions anyway. +BAN: In practice, everything using this AO strips out the Unicode extensions anyway. SFC: Let’s bring the detailed discussion of the spec text offline, it seems like we’re aligned on the spirit of it. Let’s bring it back up for discussion next month to bring it to the next plenary. If there are substantive updates, we should bring it to the group, otherwise we can say we’ll approve this PR to take to plenary aside from the feedback on the exact wording. @@ -243,15 +243,15 @@ FYT: If it’s private use, it should be private use. RGN: Yes, but that requires that the implementation be allowed to pay attention to it. If the specification requires the implementation ignore it, it is no longer available for private use -BEN: My first thought is that there's a lot of wording ambiguity in the spec. There's not a term for referring to `-t-` or `-x-` extensions, but `-u-` extensions has its own term. Preferences, in order: Keep the extensions, require implementations to ignore them, and then finally the current situation where we allow implementations to consider them but provide a buggy algorithm for doing so. +BAN: My first thought is that there's a lot of wording ambiguity in the spec. There's not a term for referring to `-t-` or `-x-` extensions, but `-u-` extensions has its own term. Preferences, in order: Keep the extensions, require implementations to ignore them, and then finally the current situation where we allow implementations to consider them but provide a buggy algorithm for doing so. RGN: I agree with that order of preferences. -SFC: I have a strong preferences for allowing implementations to use them and not require that they ignore them. But if we can’t reach consensus on that then I don’t know how I’d rank between two and three on those options that BEN listed out. I don’t like requiring implementations to ignore private use extensions, that’s not the direction we should take. +SFC: I have a strong preferences for allowing implementations to use them and not require that they ignore them. But if we can’t reach consensus on that then I don’t know how I’d rank between two and three on those options that BAN listed out. I don’t like requiring implementations to ignore private use extensions, that’s not the direction we should take. SFC: T has a very specific semantics that’s not used for negotiation generally, but could be. If you wanted your locale to be Zawgyi or Chinese Pinyin or Hinglish, all of those use T extensions. -BEN: Sometimes T extensions are use in Japanese to mark that text translated from other languages be rendered in katakana. +BAN: Sometimes T extensions are use in Japanese to mark that text translated from other languages be rendered in katakana. FYT: It’s a pretty big change to say that unicode extensions are exclusive and others inclusive. @@ -274,7 +274,7 @@ Allow use of T and X Leave it the way it is Remove them -BEN: In any case, we should document this. +BAN: In any case, we should document this. SFC: How about both documenting it and also fixing the algorithm to allow their use. @@ -332,7 +332,7 @@ SFC: Current situation is that the X and T extensions are used in a buggy way. I RGN: Yes, I think this strip last tag algorithm makes sense within the language identifier, but not the broader locale identifier. -BEN: Would it be reasonable to not dictate the algorithm? Since only specific implementations that we don’t know about are even potentially using it, what if we say the algorithm for using them should be implementation defined? +BAN: Would it be reasonable to not dictate the algorithm? Since only specific implementations that we don’t know about are even potentially using it, what if we say the algorithm for using them should be implementation defined? SFC: I hate this algorithm – I kind of want to make it all implementation-defined. Change the algorithm to say that this function will return an element of the availableLocales list, which entry it returns is implementation-defined or it can return undefined. @@ -366,7 +366,7 @@ The spec follows RFC 4647 already. We should continue using that algorithm. Impr SFC: Do we agree on this conclusion? -BEN: +1 +BAN: +1 RGN: +1 diff --git a/meetings/notes-2023-09-07.md b/meetings/notes-2023-09-07.md index 3cf0fa7f..421c6b23 100644 --- a/meetings/notes-2023-09-07.md +++ b/meetings/notes-2023-09-07.md @@ -7,7 +7,7 @@ - Shane Carr - Google i18n (SFC), Co-Moderator - Daniel Minor - Mozilla (DLM) - Louis-Aimé de Fouquières - Invited Expert (LAF) -- Ben Allen - Igalia (BEN) +- Ben Allen - Igalia (BAN) - Eemeli Aro - Mozilla (EAO) - Yusuke Suzuki - Apple (YSZ) - Richard Gibson - OpenJS Foundation (RGN) @@ -32,7 +32,7 @@ RGN: I've been getting things ready for the upcoming plenary. I merged Frank's 768 follow-up. Had some back-and-forth with Ben. Most of the clarifications we had at our last meeting are pretty much ready to go. -BEN: Anba has migrated all of 402 to structured headers! +BAN: Anba has migrated all of 402 to structured headers! ### Updates from the MessageFormat Working Group @@ -63,7 +63,7 @@ SFC: Explicit support? LAF: +1 -BEN: +1 +BAN: +1 DLM: +1 @@ -87,7 +87,7 @@ FYT: I strongly support this. I currently have to do something weird to output t LAF: +1 -BEN: +1 +BAN: +1 SFC: Are these normative changes for Intl.DurationFormat tracked in Test262? @@ -234,7 +234,7 @@ EAO: One aspect here is that there’s two levels of source. SFC: I believe that most of these problems that EAO has pulled out are solvable, but we just need to hammering out details. If there are concerns about going this direction we should bring them up now so that we don’t do all that work and then having proposals blocked later. -SFC: If there are no concerns, this seems good, I’m happy with the general direction you’ve shown, I think we should convene a smaller group of people who can go in deep, I think an incubator call is the way to do it (RGN, SFC, ZB, BEN?) to dive into the details? This is probably the biggest, most exciting proposal we’ve seen in this group since it was formed. This is an excited proposal, I’m guessing there’s a number of people who would be excited to be in the loop on this one. +SFC: If there are no concerns, this seems good, I’m happy with the general direction you’ve shown, I think we should convene a smaller group of people who can go in deep, I think an incubator call is the way to do it (RGN, SFC, ZB, BAN?) to dive into the details? This is probably the biggest, most exciting proposal we’ve seen in this group since it was formed. This is an excited proposal, I’m guessing there’s a number of people who would be excited to be in the loop on this one. ### Normative: Added note about sets of locales for web browser implementations needing to not change as a result of user behaviour #780 @@ -242,7 +242,7 @@ https://github.com/tc39/ecma402/pull/780 LAF: Can you clarify what you mean by the impact on fingerprinting? -BEN: i18n and privacy is fundamentally difficult. +BAN: i18n and privacy is fundamentally difficult. DLM: Is this going to TG1? @@ -463,7 +463,7 @@ https://github.com/ben-allen/locale-extensions - Slides: https://drive.google.com/file/d/1gry4GFNPhzV42ezJ4ArtF5RHA9z6EETA/view -BEN: (summarizes the updated README) +BAN: (summarizes the updated README) DLM: Support getting feedback from the W3C group. But getting it on the agenda for Tokyo also gives me something to point to.