- Shane Carr - Google i18n (SFC), Co-Moderator
- Ben Allen - Igalia (BAN)
- Eemeli Aro - Mozilla (EAO)
- Richard Gibson - OpenJS Foundation (RGN)
- Yusuke Suzuki - Apple (YSZ)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
- Daniel Minor - Mozilla (DLM)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
RGN: Fairly quiet month. Landed a PR to better align with 262 for lists (iterating over elements). New PR for refactoring PartitionPattern
EAO: Very active. Many discussions of how to represent complex messages. Working at speed on other issues, still aiming to finish by April or May of next year. It’s risky, but I’m optimistic. Updates on error handling and the shape of what the custom formatters should look like, since that’s complicated for internal reasons of what’s possible in MessageFormatv2. No news from W3C internationalization group that’s relevant to us
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
FYT: There are some changes on Intl Locale Info, which we’ll talk about later.
DLM: We had to back out our ICU74 updates, wanted to raise that in case anyone had missed it.
SFC: Let’s discuss that here. One comment that I’ve seen is that it’s great that Firefox is great at getting the update rolled out fast, but that means that Firefox was the first to notice this webcompat problem, but it will be encountered in the other browsers as well. It appears that it may be an ICU bug rather than an intentional CLDR data change, and I believe Rich Gillum is already fixing it on the ICU side. But I was wondering what the timelines are for other browsers, and if we should make sure we pull back the ICU74 update until this issue is resolved.
DLM: Our choice is that we would lik to coordinate with other browsers and make sure we're patching things the same was as other vendors.
FYT: Do you think this is a set of problems, or one giant problems? In other words, do we have a finite set of issues causing this, but the question is is that set one big problem or a bunch of small ones?
DLM: My impression is that it’s a small problem, they made a decision to back it out right away instead of trying to patch it.
FYT: Several small problems, or one?
DLM: My impression is that it’s one small problem
FYT: One key thing, basically?
DLM: I thought it was that there’s one date format that’s incorrect, but one that’s heavily used for generating ISO-8601 dates.
EAO: My understanding that it’s not specifically related to these locales, but about how ICU is handling dependencies between this locales, or root and locales. Anba has pointed to a likely reason for this, and it looks like the fix will be easy and simple – but it hasn’t been done yet, so who knows?
SFC: Based on the findings in Anba’s thread as well as in the ICUTC thread that followed from it, it appears the root cause is a bug with the ICU fallback mechanism, which means that it probably impacts other types of data as well, it’s just this is the one that got noticed because it’s a common pattern to use on the web for ISO date formatting. Probably this is just a symptom and it affects other locales as well – it’s a little bit of a pity that ICUTC didn’t detect it sooner. We’re working on a new data-driven test framework that should hopefully have better test coverage and detect these things in alpha, beta, or release candidate. There was a talk about the data-driven testing at the Unicode Technology Workshop last week – hopefully these issues will be detected sooner. The next step is to get the ICU74 patched, and make sure that YSZ and FYT be careful about incorporating shipping once Rich’s change is landed, before we ship anything.
YSZ: Sounds good!
EAO: To address the other part of the root cause, that makes this bug a webcompat issue, is the way this locale is misused on the web.
FYT: I think we need to think carefully about this, and we need to talk with the rest of TC39. There’s web misuse of this locale, but why? Because there’s no other way to do the right thing. When ECMA-402 produces an option that’s good for the user, we have to think about whether non-402 has something to offer. This will be used in the future, because 262 doesn’t have the right way to do it.
SFC: We had a discussion on StableFormatting and an incubator call on this – I believe we should have this conversation in that context.
EAO: No updates relevant to us.
Should be on agenda:
- #839
- Locale info firstDayOfWeek issue
- Six DurationFormat PRs
https://github.com/tc39/ecma402/projects/2
Issue: tc39/proposal-intl-duration-format#169
PR: tc39/proposal-intl-duration-format#176
BAN: (introduces issue and describes change)
SFC: This is a stopgap recommended by CLDR. We may eventually follow up with a future change to reflect changes to CLDR data.
SFC: Any objections?
TG2 agreement to bring to TG1.
Issue: tc39/proposal-intl-duration-format#155
PR: tc39/proposal-intl-duration-format#178
BAN: (introduces issue and describes change)
SFC: LGTM
FYT: Looks okay
TG2 agreement to bring to TG1.
Issue: tc39/proposal-intl-duration-format#170
PR: tc39/proposal-intl-duration-format#180
BAN: (introduces issue and describes change)
BAN: This seems to be the only output we can get that doesn't switch numeric formats between list formatting and digital formatting and that avoids ambiguity.
FYT: I like the changes in terms of the expected behavior, but this section of the spec is really confusing and I need more time to review it. But if it produces the stated behavior, I support it.
LAF: In what you showed, "numeric" is written like "2-digit". In my opinion, when you say "numeric", you write "2h", "1h", "59m", "59s". In this case it wouldn't be ambiguous. But I've seen in most cases, whether you give numeric or 2-digit, you get the same result, even if you change from one locale to another.
BAN: In the spec as written, when "hours" is styled as "numeric", and there's no explicit style for minutes and seconds, those fields are defaulted to 2-digit. I believe the AO for that is GetDurationUnitOptions.
LAF: In real life, you can express hours and minutes with "h" and "m".
SFC: We do already support "2h, 1m, 59s". I don't know if we support "2h1m59s" but this would be something that CLDR could support in the future and that we could also support once there is prior art.
SFC: I would ideally like to see the full editorial refactor land first, but I agree that it's good to pull things out to get approval.
TG2 agreement to bring to TG1.
Issue: tc39/proposal-intl-duration-format#157
PR: tc39/proposal-intl-duration-format#173
BAN: I think we previously discussed this and this is the PR to implement those changes.
SFC: It seems like a lot of math to me but PFC confirmed that this is what Temporal does so therefore I'm fine with it.
YSZ: I support this change too.
LAF: Okay from me.
TG2 agreement to bring to TG1.
BAN: The numeric style is deceptive/confusing because "numeric" does not indicate that it should be formatted as a number; it indicates that it should be digits appended to the previous number. A fix which is fairly major is to have an explicit style for these fractional units. It may also be useful for allowing fractional minutes and hours in a V2 proposal.
SFC: Currently
Instead of calling the style for subsecond units “numeric”, instead call it “fractional’. The code below would end up appending fractional milliseconds to seconds
// Current:
new Intl.DurationFormat("en").format("PT3.05S") // "3s 50ms"
new Intl.DurationFormat("en", { milliseconds: "numeric" }).format("PT3.05S") // "3.05 s"
new Intl.DurationFormat("en").format("PT3.0501S") // "3s 50ms 100us"
new Intl.DurationFormat("en", { microseconds: "numeric" }).format("PT3.0501S") // "3s 50.1ms"
// Proposed:
new Intl.DurationFormat("en", { milliseconds: "fractional" }).format("PT3.05S") // "3.05 s"
new Intl.DurationFormat("en", { microseconds: "fractional" }).format("PT3.0501S") // "3s 50.1ms"
// Can do in future:
new Intl.DurationFormat("en", { seconds: "fractional" }).format("PT3M30S") // "3.5m"
BAN: One advantage of switching to the name "fractional" means that it is more clear what is going on. If I say "numeric" it's not clear where they go, whereas with style "fractional" it is more clear that the unit ends up as a fractional unit.
SFC: If we keep style "numeric" for this, we can still add "fractional" in the future, and just special-case style "numeric".
FYT: I have a hard time understanding this.
BAN: Style "fractional" means "append this to the last unit that didn't have fractional style."
LAF: I did not totally understand what you did, because it was the same. I think if you want to expand that idea to fractional hours, I would rather say “decimal hours” instead of “dividing the hour into sixty minutes”, express it as a decimal number.
FYT: It doesn't make sense to say milliseconds: "fractional" but it's not milliseconds that have a fraction, it's seconds that has a fraction.
LAF: There are in fact two concepts here. First, do I want to express seconds? Second, what is the precision that I want to have with the seconds? If I want to express seconds, I say seconds: "numeric", and then I say the precision I want to the milliseconds or microseconds. The number of digits after the decimal separator. I think most people using these options are scientific people looking at events that happen at a small amount of time. They think , "I want to see seconds, and I want a precision of X". If you do that for seconds, why not for other units? Meters, liters, etc. Are there use cases with microseconds and so on? Not sure.
BAN: We're taking in Temporal.Duration objects, which have separate properties for the subsecond values. So we have a way of expressing desired precision, with the fractionalDigits option. But yeah, it's because seconds in durations as we have them set up… it's an integer number.
SFC: Based on what FYT and LAF said, it seems we have more design space to explore here. Therefore, I think we should stick with the current style options right now, and revisit this in DurationFormat v2. Additionally, though, I do think we should have a DurationFormat v2 – we just can’t start v2 until we have DurationFormat v1 landed.
SFC: And we can still use style "fractional" internally in the spec.
BAN: Yes, using it internally improves the readability of the spec.
tc39/proposal-intl-duration-format#161
SFC: This issue would change restrictions on engines when they perform formatting, but it doesn't change user-visible behavior with regards to things like exceptions, default options, etc. Do we want to consider this a normative change, or can it be a smaller change that doesn't need TG1 explicit approval? Process question to the group. How do implementors and others feel about PRs of this nature. Consider cases like the negative duration formatting PR – this is another change that doesn’t affect user-visible behaviour? Yes, they can see the literal change in the behavior, but it’s a change in something coming from an implementation and locale dependent black box. One of our goals in the upcoming TG1 meeting is to make sure that the DurationFormat proposal is fully solidified so that someone like FYT can implement it. Would this change be something disruptive for someone like FYT? I would say no, because he’d just be deferring to ICU.
FYT: DurationFormat? I don’t think so, I don’t think there’s something I can defer to ICU
SFC: You can defer to ICU on digital duration formatting, which is the thing that this largely impacts.
FYT: No? I don’t think so? I don’t think DurationFormat is easy to delegate, with the complexity we’ve put in the spec.
SFC: Conclusion for Issue 161: I’ll say the conclusion that I think it is, that we should bring it to plenary when we’re ready, but doesn’t necessarily have to be in the batch that we bring in November.
YSZ: SGTM
SFC: [posted comment on DF #89]
SFC: I believe we’ve gotten in all the issues – I’m marking them as “consensus” and “needs tg1”. I think this brings us to the end of DurationFormat in terms of all the issues we know about.
tc39/proposal-intl-locale-info#78
FYT: Some background: I presented Intl.LocaleInfo in July and September meeting. I propose the bag take seven different strings and output those, but TC39 prefers we take the value and output it as whatever’s used in Temporal, which is 1 to 7. I made the change and landed it. The problem is that this issue got filed, with a comment about the string saying other things and that being a problem, and going back to the idea that we should use string form. DE noted that the output format as number can also be retrieved from weekInfo. DE asked me to talk to him offline, and after some discussion in email and here he said “I understand your point now” and said that he’s not going to hold that against it when we go back to TC39. So I’m proposing to change it yet again, but a little different from before. In July, the second line doesn’t include 0 to 7, but the return value will be String, so that’s what we’re proposing. Pardon: the thing I’m realizing is that my PR’s not good either. Apologies: I’ve just realized that the proposed fix is not good enough, I don’t want to waste your time.
SFC: It is useful to discuss that the proposed fix does go back to what we discussed last month, which is that the return value is should be the string.
FYT: Yes, but the point is that it should be returning anything in the locale that you pass in, so this is not a good PR.
SFC: I still think we can bring this back to the November plenary as a 15 minute item once we have the PR fixed up.
FYT: Anyway, DE agreed that we could return the string form. But it should be, probably, the same as whatever we have in the calendar for the thing, and he agree that if we take 0 to 7, he’s fine. So we do need special handling for 0 to 7.
SFC: Do we still want to have the special handling for 0 through 7, or now that we’re returning Strings should we only deal with Strings in this API? It might be easier, since otherwise you have to have a special case for it.
EAO: The other interface is representing this, right, the other places in JavaScript where start of the week–
FYT: Yes, those are returning numbers
EAO: Then I think we should accept specifically those ones.
FYT: Yes, I should rework the PR and convert 0 to 7 to that. I think that’s what TC39 told me before, and they have concern about that part. EAO: That would match the approach of being liberal on input and strict on output, which I think is appropriate here.
SFC: Thank you, FYT!
FYT to update the PR and bring to TG1.
Consider making ResolveLocale return the normalized requested locale instead of the available locale #830
SFC: There’s two places you can get locales back from the API: supportedLocalesOf, which takes in a list and returns a subset of that list, with normalization, but it just returns the elements of the list in normalized form. But resolvedOptions of a locale returns information about any locale, not just this locale.
SFC: For example, if your input locale is de-Latn-At and your resolved locale is de, should we return the input locale or the resolved locale? The alternative is we keep the current behavior, which we implemented in ICU4X. The original motivation for this is kind of moot, because we have an avenue to support both the original behavior and the proposed behavior. I just think the proposed behavior is cleaner, because resolveLocale isn’t exposed anywhere else in 402, which makes it a lot more flexible for implementations.
FYT: The resolved locale is… you're talking about the resolvedOptions().locale, right? The issue is that you’re passing in a list of locales, and whatever got resolved would be maybe something that you never pass in. For example, you pass in nothing, it’ll be the default locale.
SFC: That’s true, passing in nothing would need to be a special case.
FYT: Or you pass something we don't have, you pass in Cherokee or something that we may not have sorting order, it will resolve to default locale or some other language. It’s not just normalized.
EAO: I think there are two different behaviors here. One is when we take the input and decide that it really means something, and we are not doing fallback to the system locale, then we end up in a situation where resolvedOptions and supportedLocalesOf end up producing different sorts of results. If we are doing fallbacking to the system locale or to whatever that is, that’s different. Because if we end up not supporting this locale, the result is the same always, right? So I would say that the least surprising thing for me as a user of this interface would probably be that effectively the behavior of resolvedOptions and supportedLocalesOf are as much the same thing as possible.
FYT: But if you’ve already passed in something, you know that, then this API has no meaning. If you return exactly what you put in, you don’t need it.
EAO: But if I pass in an array of three things and it picks the second of those, how else could I find it aside from resolvedOptions.locale().
FYT: That’s the case
EAO: With the same localization as in supportedLocalesOf
FYT: I still have problems understanding the motivation for the change – what’s the problem with the current behavior? If there’s no good reason to change, there’s a good reason not to change.
SFC: The reason to change is because the available locales list is not exposed anywhere, except in this one API. By keeping it away from users so that they can’t get to it, it makes it a little bit easier to implement, because otherwise this is an implementation detail that we’re exposing to the web, which would be nice to avoid. In terms of priority of constituency, that’s low: most end users, second developers, third implementors. But also I agree with what EAO is saying, which is that it’s strange that you can pass to a list to supportedLocalesOf and to the constructor, and get different results. So I do think there’s a motivation for changing the behavior. The reason, though, that I’m not like “we should definitely move forward with this 100%” is that this is a very old behavior, and if we change it there may be web compatibility issues.
EAO: To go on from there, there’s also the POV that with this trying to make implementor work easier, we’re doing it by making implementors do extra work and have extra uncertainty. I would be okay with us deciding not to change anything at all, but I can also see that doing this differently than we did before to make it more logical does have appeal.
SFC: I’m going to tentatively say that we’re not going to take action on it now, but to leave it as a thing we’re going to revisit in the future. I do think it was a mistake to reveal resolvedLocale, but the motivation to change it isn’t strong enough. If it does become stronger, we should revisit it again.
No action for now. Keep issue for potential future discussion.
RGN: What I’d pitch here is status quo: the underscore exists as a legacy thing within Unicode, because at some point they needed the identifiers to match identifier (?). But it’s not in BCP 47, it’s explicitly legacy in UTS 35, and we haven’t been using it. To flex that now, to start using things that are invalid and in contravention of the specs we follow, I don’t know what the benefit is.
SFC: The comment from Addison is that he tends to agree, but PCO said that in GNOME there’s things that tend to use underscores. My thought on the issue was that I tend to agree with Richard, but also I see that accepting underscore is low risk. I’m happy to do the same thing as with the previous: keep the status quo unless someone comes back with more convincing evidence. So that we can get this issue off the queue and move on – anyone here going to disagree with this conclusion?
LAF: +1
YSZ: Sounds good
FYT: If you want to support underscore, you could do it in userland – you don’t need to do it in 402
SFC: That’s a good point
FYT: And I believe those three criteria are drafted by ZB, so I turn it back to him.
No action for now. Keep issue for potential future discussion.
Normative: Use CLDR data for currency rounding and precision, allowing users to specify rounding based on cash denominations in common use #839
BAN: This is about resolving how many digits to use in cash currency. There is a lot of room for bikeshedding.
new Intl.NumberFormat("en", { style: "currency", currency: "EUR", currencyPrecision: "cash" })
new Intl.NumberFormat("en", { style: "currency", currency: "EUR", currencyPrecision: "financial" })
BAN: I feel "financial" is better than "accounting" because we use "accounting" for the formatting style.
FYT: So cash rounding is connected to the physical bill or coin, right?
BAN: Yes, it’s what you’re most likely to be using in your day to day life. I believe this came up because there exists locales where the ISO 4217 digits are far more than what anyone would ever use.
SFC: “precision” is alright – the other option would be something more specific, like “currencyCash”, either “cash” or “financial”. I think I lean toward “currencyPrecision”, though. Another issue with this type of PR is that it’s right on the border of what’s big enough to be a proposal and what’s small enough to be a PR, so I would like to hear a signal from someone like FYT or YSZ about whether it’s reasonable to move forward in its current form as a PR, or if you’d like to make it a full-fledged proposal.
YSZ: I would like to look into it. I don’t have a concrete comment right now, but I would like to look into ICU and if the current interface works well, or if we need to have to have an additional option pack or something like that, in terms of implementation.
SFC: It should be supported in ICU. ICU, both C and C++ have this option and have had it for quite some time. ICU4X doesn’t have it, but should be coming soon. For ICU4C, it should be there.
YSZ: This sounds good.
SFC: I’ll take that as a signal that we can put this on the agenda for TG1.
FYT: I support that.
Ask for TG1 consensus with the currently proposed option names. BAN to update the pull request to address RGN's concerns about normative CLDR references if he hasn't already done so.
SFC: This person filed an issue saying that they’d like to get the date format for a given locale, so that users can get the pattern string for that locale themselves.
FYT: Well, he doesn’t say he wants the pattern, he says he wants to get the label.
EAO: To me this seems way too much like they’re saying they want to get this so that they can parse this localized string you’re giving me. If they wanted it, they could use .formatToParts
SFC: I agree, and also we have date field display names. If you really must get the things out of the parts, we also support formatToParts. We support this, and a user can implement this in userland. And this particular pattern is very much English-specific. Somewhere else they might use different letters, and CLDR doesn’t even give us that information – they used to have something called a “localized pattern”, but that was a mistake and they don’t use it anymore. I think we should say that we don’t plan on action this in its current state and then close the issue.
Say we’re not going to action this, and give advice on what to do in the short term.