On Thu, Sep 18, 2025 at 3:29 PM Philip Jägenstedt <[email protected]> wrote:
> On Thu, Sep 18, 2025 at 2:51 PM Mike Taylor <[email protected]> > wrote: > >> On 9/18/25 5:54 a.m., Philip Jägenstedt wrote: >> >> Some additional context. Upgrading ICU can break sites and it cannot be >> done with a flag because of the size of the library (two copies would be >> needed). To mitigate the risk, we'd like to use the Blink launch process >> going forward. Where we can identify a risk ahead of time, we can add a >> targeted flag for that, as we've done for Italian number formatting here. >> >> On Thu, Sep 18, 2025 at 11:40 AM Chromestatus < >> [email protected]> wrote: >> >>> *Contact emails* >>> [email protected], [email protected] >>> >>> *Explainer* >>> None >>> >>> *Specification* >>> https://tc39.es/ecma402 >>> >>> *Design docs* >>> >>> https://unicode-org.github.io/icu/download/77.html >>> https://cldr.unicode.org/downloads/cldr-46 >>> https://www.unicode.org/versions/Unicode16.0.0 >>> >>> *Summary* >>> ICU is not a feature itself, but the third-party library we use for >>> general Unicode support. We are using the Blink launch process because >>> there is web compat risk and security considerations. The upgrade is from >>> ICU 74.2 to ICU 77.1, the current latest release. ICU 77 contains CLDR 46 >>> and other changes to support Unicode 16. The web-exposed changes are mainly >>> the Intl and RegExp APIs, IDNA rules for URLs, and text segmentation. Intl >>> and RegExp (V8): Lots of small changes. The change of Italian number >>> formatting is the riskiest and has a dedicated flag, see compat risk >>> section. IDNA: Generally more things are allowed, and this upgrade improves >>> our overall test results in WPT. Text segmentation: The most interesting >>> change is better Japanese line breaking when using `word-break: >>> auto-phrase`, related to >>> https://chromestatus.com/feature/5133892532568064. All test changes are >>> explained in >>> https://docs.google.com/document/d/1lrfJJmWvLXYPYSYlxE3mXTgDZI9U1bw2FrJYrDorgqE/edit?usp=sharing >> >> This doc mentions changes to "added comma in en-GB in a date format" - >> where's the best place to see what that change looks like? This kind of >> change sounds pretty similar to >> https://issues.chromium.org/issues/40256057 (or go/omg-1414292-pm if you >> can read it (apologies to non-googlers)), and the type of things to easily >> break regular expressions >> > > It shows up in two places in test changes in > https://chromium-review.googlesource.com/c/chromium/src/+/6578333. > > The first is base/i18n/time_formatting_unittest.cc with these are the > changes: > > "Saturday 30 April 2011 at 15:42:07" → "Saturday, 30 April 2011 at 15:42:07 > "Saturday 30 April 2011" → "Saturday, 30 April 2011" > > The other > is third_party/blink/web_tests/webexposed/intl-date-time-format-expected.txt > with this change: > > "Wednesday 14 June 2023 at 14:50:00 British Summer Time" → "Wednesday, 14 > June 2023 at 14:50:00 British Summer Time" > > I agree that this carries some risk. On the "probably fine" part of the > ledger we have: > > - It aligns more with en-US where there is a comma for the "full" > format, as well as some of the shorter ones > - Firefox shipped it and didn't get any regression reports about this. > I can't spot anything in my own search > > <https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=&content=en-gb+comma&comments=0> > either. > > https://issues.chromium.org/issues/40256057 is precisely the reason why > nobody has updated ICU for a long time and why it's important to have > enough checks in place to make such breakage much less likely. > > Putting a change like this behind a flag is a bit fraught because we're > writing some new code to emulate what older versions of ICU did, and can't > be 100% confident that it's correct for all combinations. I will dig up the > CLDR change behind this and see if it's controllable by ICU inputs, as was > luckily the case for the Italian number formatting change. > The CLDR change for this is https://github.com/unicode-org/cldr/pull/3879. I reached out to my CLDR expert colleagues and learned that the origin of that change is feedback from the CLDR Survey Tool, where linguists propose and review changes once per year. The comment was: The way I believe we used to render these strings is like this: For en-GB, > there should be no comma in any date string UNLESS it consists of 4 date > fields or more, and then the comma would go after the day of the week, so: "29 June 2023”, “Thu 29 June”, "Thu 29/06" and "Thursday 29 June", but > "Thursday, 29 June 2023” and "Thursday, 29 June 2023 AD”, for example. To see which locales are impacted I tested more English locales: https://chromium-review.googlesource.com/c/chromium/src/+/6973556 Comparing the results before/after the ICU upgrade the locales that got the extra comma are en-AU, en-GB, and en-IN. (The CLDR PR touched them all, as well as en-CA for another change, see below.) It should be possible to undo this change behind a flag, by removing any commas if the date style is "full" for en-AU, en-GB, and en-IN. This also revealed a few more minor changes to English locales: - en-CA changes "Pacific Daylight Saving Time" to "Pacific Daylight Time", matching en-US - en-AU removes a period in narrow duration format, from "2h 35s." to "2h 35s", matching all other en-* variants tested - en-ZA changes the thousands grouping and decimal separator, from "12,345.00" to "12 345,00". It's the only tested English variant with this format, but many European variants like en-FR and en-UA have the same style. None of these seem risky enough to warrant putting them behind a flag. While testing things I also noticed that Safari 18.6 on macOS now uses ICU 76 or later. Everything except the en-CA PDT change was confirmed already shipped in Safari: - Italian number formatting - Added comma for en-AU, en-GB, and en-IN - en-AU duration format change - en-ZA number formatting changes Shipping last reduces the risk quite a lot, but I'll still add a flag for the en-* comma change just to be safe. The other changes don't seem worth the flag, but I can try if requested. Best regards, Philip -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYey%2BYZn%2Bu7Qgn1c%3Dyq3hdb1dPVDVVXEdVvVFLA28vnhHg%40mail.gmail.com.
