Update notes-2025-05-08.md

Author: sffc

meetings/notes-2025-05-08.md

@@ -110,6 +110,20 @@ EAO: One thing: I haven’t written it down yet but it came up with the discussi
 
 SFC: The currently proposed text here states the web reality and also states the principles that we rely on to load locales dynamically which is why I like the current text since it keeps the door open for us while it lays down the current restrictions we already adhere to. Essentially we should define where the goalposts are so we could actually develop equitable solutions. Until this PR we don’t state anywhere that the ECMA-402 APIs cannot or should not serve as a fingerprinting vector. I like it being a net positive while still allowing us to explore that idea eventually.
 
+#### Notes from a different scribe
+
+USA: This was being worked on when the Intl (?) API was being worked on. User preferences. This PR adds text to that, just a single paragraph. There was some concern from the security folks from Mozilla. DLM?
+
+DLM: I wanted to run the text by our privacy group. No concerns about the text. So I’d be happy to see this merged.
+
+USA: Thanks. This could be as simple as asking for consensus in this call.
+
+EAO: In the discussion between SFC, BAN, and me at the in-person TG2 meeting last fall: the client (browser) already revealing a bunch of supported locales to the server by the Accept-Language header. Chrome team wants to change that into a dialogue type of API. Where at most two locales, default and a fallback, would be revealed, rather than a more complete list. I would argue that in most cases in a browser we end up on a page where we ask for content in a locale that all the parties know that this is the preferred locale. So calls for Intl.DTF, etc. we might use a locale on this page. But vast majority ought to use that locale. That allows for an opportunity for prioritizing, providing support directly. Support for a subset of all locales that a browser knows about, depending on users explicit or implicit choice by what’s being sent to the browser based on Accept-Language. That’s nearly the only place where we might build-in an opportunity to dynamically load a set of all locales. But this proposed language – which I don’t object to – would limit our ability to do that. So I think we don’t need to be as strict. What is required for that list to stay constant? To include the user’s selection of languages for web content, if that makes sense. This came up in a discussion earlier today. IT’s well beyond late for participating in this. Text there leaves open possibility for relaxations to be made later. This kind of dynamic data loading isn’t even possible in ICU for browsers. Not objecting to the language, but here’s a part that we can discuss either now or later when ICU dynamic data loading might be possible.
+
+SFC: Current proposed text has evolved. It states web reality. States the principles that we intent to apply concerning loading additional locales. So the current text is a good take .It leaves open the door for additional requirements. As Henri and Daniel know, I want to evolve but also know where the goal posts are, so we can develop an equitable solution. This PR does that. This PR also reflects feedback from Dan about fingerprinting. Nothing here or in 402 goes beyond what the web browser is already doing. So I think this PR is a net improvement. This gives us flexibility to evolve the spec to support disadvantaged languages and so forth.
+
+USA: To clarify: when this came up, the idea was to restrict more radical options in terms of dynamic loading of locale date to preserve data privacy, as tradeoff between fingerprinting and providing localization experience that the user needs. This isn’t perfect but it’s a step in codifying requirements we already know about here in this group. We could merge this. We could bring this to the next TG1 meeting to get consensus.
+
 ### Intl Keep Trailing Zeros
 
 https://github.com/eemeli/proposal-intl-keep-trailing-zeros
@@ -122,6 +136,26 @@ SFC: Thanks for the clarification, it’s a good example. If a number currently
 
 EAO: The intent is for the changes to be able to format any numerical value type with trailing zeroes as well.
 
+#### Notes from a different scribe
+
+EAO: This is effectively a bug fix. Intent is to change NF.format or PluralRules.select with a numeric string input value with any trailing zeroes beyond the decimal separator, we retain those zeroes. When you call NF.format(“1.0”) you get “1.0” not “1”. Doesn’t add any other capabilities or interfaces. Changes internally how this value gets formatted. This also applies the current formatting options. E.g. formatting “1.000” with minimalFractionalDigits 2 and maximumFractionalDigits 4 you get “1.000”. But with 2 and 2, you get “1.00”. Expectation is that this should be a web-compatible change to make. Likely rare that people are using numeric strings in formatting.select. And when they do this, they probably expect to give them the value we’re talking about here. There’s an issue about possibly making a change with displayTrailingZeroes, which we have, with some allowable values. We may need to add a new option to replicate the current behavior. But if it turns out that what we propose isn’t web compatible, we can add a trailing zero display option which would enable this option with numeric string inputs. But that’s a backup that I hope we don’t need to exercise.
+
+EAO: I don’t have spec text yet. Change would be internal, in the spec. Change what is intl mathematical value, which is currently just a number, to include a representation of trailing zeroes, if any. A couple of ways to do that. This is coming out of the JS numerics recurring call. Feedback there was generally positive. My hope is to get some co-champions, and possibly present this in A Coruña.
+
+SFC: Thanks for championing this. I’ve kind of wanted to see this but didn’t work too much in this direction. Glad you’re taking the initiative. This change has evolved from previous changes to support e.g. more significant digits, which ended up being a web-compatible string. So this is a straightforward change to add. Once we have spec text for this, I expect intl mathematical value will be able to represent trailing zeroes. When Intl.numberformat isn’t set up correctly, then we can use this information. Instead of falling back to 3 or 6 digits, we use the string. Does that align?
+
+EAO: Not exactly. It’s not the case that those options would override these. The value being formatted has some fraction digits. Currently we don’t include trailing digits in that. With this change, they would be included. Example: with this change, if you call NF with minimumFracitonDigits with “1.0”, you’d get “1.0” out. But the intent of the change wouldn’t change any default behaviors. If you format “1.234567”, the output includes only 3 fractional digits.But with this, we end up with the three fraction digits. IF you want more, you of course have the option.
+
+SFC: Thanks. Good example. If a number currently has trailing digits, we may want to retain them with rounding. We may need to do a bit of iteration on the exact behavior. I’ll also want to think forward in terms of formatting a decimal and how this works. I’d like it if the infrastructure we have for this case is the same as what we need for decimals. Not a requirement, nice to have.
+
+SFC: Other comments: I consider this basically a bug fix. We get bug reports with PluralRules and NumberFormat. So this resolves teh different. It doesn’t necessarily impacts decisions on the decimal proposal, and decimal.amount idea. Two different concerns. But this lays down a god framework. I support this and I hope others do too.
+
+EAO: Indeed, changes made here would work for any numeric type that would have trailing zeroes.
+
+USA: Sounds like you have support.
+
+DLM: Just wanted to also express support.
+
 ### Normative: Update String toLocale{Lower,Upper}Case to ResolveLocale with best-fit matching #956
 
 https://github.com/tc39/ecma402/pull/956
@@ -327,53 +361,3 @@ FYT: What about undefined?
 EAO: OK.
 
 SFC: OK. Null also makes sense.
-
-## Define fallback behaviour in {Calendars,Collations,HourCycles,NumberingSystems,CharacterDirection,WeekInfo}OfLocale #76
-
-https://github.com/tc39/proposal-intl-locale-info/issues/76
-
-## And remaining time will be used to go through the issue backlog, including open design questions involving Decimal.Amount or Measure
-
-## Normative: Don't add default formatting to lone era #957
-
-https://github.com/tc39/ecma402/pull/957
-
-## Normative: Don't add default formatting to lone timeZoneName #958
-
-https://github.com/tc39/ecma402/pull/958
-
-### Normative: Added note about sets of locales for web browser implementations needing to not change as a result of user behaviour 
-
-USA: This was being worked on when the Intl (?) API was being worked on. User preferences. This PR adds text to that, just a single paragraph. There was some concern from the security folks from Mozilla. DLM?
-
-DLM: I wanted to run the text by our privacy group. No concerns about the text. So I’d be happy to see this merged.
-
-USA: Thanks. This could be as simple as asking for consensus in this call.
-
-EAO: In the discussion between SFC, BAN, and me at the in-person TG2 meeting last fall: the client (browser) already revealing a bunch of supported locales to the server by the Accept-Language header. Chrome team wants to change that into a dialogue type of API. Where at most two locales, default and a fallback, would be revealed, rather than a more complete list. I would argue that in most cases in a browser we end up on a page where we ask for content in a locale that all the parties know that this is the preferred locale. So calls for Intl.DTF, etc. we might use a locale on this page. But vast majority ought to use that locale. That allows for an opportunity for prioritizing, providing support directly. Support for a subset of all locales that a browser knows about, depending on users explicit or implicit choice by what’s being sent to the browser based on Accept-Language. That’s nearly the only place where we might build-in an opportunity to dynamically load a set of all locales. But this proposed language – which I don’t object to – would limit our ability to do that. So I think we don’t need to be as strict. What is required for that list to stay constant? To include the user’s selection of languages for web content, if that makes sense. This came up in a discussion earlier today. IT’s well beyond late for participating in this. Text there leaves open possibility for relaxations to be made later. This kind of dynamic data loading isn’t even possible in ICU for browsers. Not objecting to the language, but here’s a part that we can discuss either now or later when ICU dynamic data loading might be possible.
-
-SFC: Current proposed text has evolved. It states web reality. States the principles that we intent to apply concerning loading additional locales. So the current text is a good take .It leaves open the door for additional requirements. As Henri and Daniel know, I want to evolve but also know where the goal posts are, so we can develop an equitable solution. This PR does that. This PR also reflects feedback from Dan about fingerprinting. Nothing here or in 402 goes beyond what the web browser is already doing. So I think this PR is a net improvement. This gives us flexibility to evolve the spec to support disadvantaged languages and so forth.
-
-USA: To clarify: when this came up, the idea was to restrict more radical options in terms of dynamic loading of locale date to preserve data privacy, as tradeoff between fingerprinting and providing localization experience that the user needs. This isn’t perfect but it’s a step in codifying requirements we already know about here in this group. We could merge this. We could bring this to the next TG1 meeting to get consensus.
-
-### Intl keep trailing zeroes
-
-EAO: This is effectively a bug fix. Intent is to change NF.format or PluralRules.select with a numeric string input value with any trailing zeroes beyond the decimal separator, we retain those zeroes. When you call NF.format(“1.0”) you get “1.0” not “1”. Doesn’t add any other capabilities or interfaces. Changes internally how this value gets formatted. This also applies the current formatting options. E.g. formatting “1.000” with minimalFractionalDigits 2 and maximumFractionalDigits 4 you get “1.000”. But with 2 and 2, you get “1.00”. Expectation is that this should be a web-compatible change to make. Likely rare that people are using numeric strings in formatting.select. And when they do this, they probably expect to give them the value we’re talking about here. There’s an issue about possibly making a change with displayTrailingZeroes, which we have, with some allowable values. We may need to add a new option to replicate the current behavior. But if it turns out that what we propose isn’t web compatible, we can add a trailing zero display option which would enable this option with numeric string inputs. But that’s a backup that I hope we don’t need to exercise.
-
-EAO: I don’t have spec text yet. Change would be internal, in the spec. Change what is intl mathematical value, which is currently just a number, to include a representation of trailing zeroes, if any. A couple of ways to do that. This is coming out of the JS numerics recurring call. Feedback there was generally positive. My hope is to get some co-champions, and possibly present this in A Coruña.
-
-SFC: Thanks for championing this. I’ve kind of wanted to see this but didn’t work too much in this direction. Glad you’re taking the initiative. This change has evolved from previous changes to support e.g. more significant digits, which ended up being a web-compatible string. So this is a straightforward change to add. Once we have spec text for this, I expect intl mathematical value will be able to represent trailing zeroes. When Intl.numberformat isn’t set up correctly, then we can use this information. Instead of falling back to 3 or 6 digits, we use the string. Does that align?
-
-EAO: Not exactly. It’s not the case that those options would override these. The value being formatted has some fraction digits. Currently we don’t include trailing digits in that. With this change, they would be included. Example: with this change, if you call NF with minimumFracitonDigits with “1.0”, you’d get “1.0” out. But the intent of the change wouldn’t change any default behaviors. If you format “1.234567”, the output includes only 3 fractional digits.But with this, we end up with the three fraction digits. IF you want more, you of course have the option.
-
-SFC: Thanks. Good example. If a number currently has trailing digits, we may want to retain them with rounding. We may need to do a bit of iteration on the exact behavior. I’ll also want to think forward in terms of formatting a decimal and how this works. I’d like it if the infrastructure we have for this case is the same as what we need for decimals. Not a requirement, nice to have.
-
-SFC: Other comments: I consider this basically a bug fix. We get bug reports with PluralRules and NumberFormat. So this resolves teh different. It doesn’t necessarily impacts decisions on the decimal proposal, and decimal.amount idea. Two different concerns. But this lays down a god framework. I support this and I hope others do too.
-
-EAO: Indeed, changes made here would work for any numeric type that would have trailing zeroes.
-
-USA: Sounds like you have support.
-
-DLM: Just wanted to also express support.
-
-USA: This is as good of support as you can have at this stage. Bring it to TG1.