Update our in-tree ICU to 72
Categories
(Core :: Internationalization, enhancement)
Tracking
()
People
(Reporter: anba, Assigned: anba)
References
(Blocks 1 open bug)
Details
Attachments
(16 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1792775 - Part 9: Handle new script codes in GetCommonFallbackFonts. r=#platform-i18n-reviewers!
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Also updates to CLDR 42 and Unicode 15 and brings various bug fixes and improvements.
Release notes: https://icu.unicode.org/download/72
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Try run with ICU 72 (RC): https://treeherder.mozilla.org/jobs?repo=try&revision=ac232dba6acac24381bb309d91dcb34896d09516
Assignee | ||
Comment 2•2 years ago
|
||
Remove the patch for bug 1766220 because the local patch was just a backport
from the ICU development branch.
And update the local patches for Sorbian and WASI integration to apply cleanly
on ICU 72.
Assignee | ||
Comment 3•2 years ago
|
||
Update to ICU 72 by running ./update-icu.sh https://github.com/unicode-org/icu.git maint/maint-72
.
Assignee | ||
Comment 4•2 years ago
|
||
Update language tags by running ./make_intl_data.py langtags
.
Assignee | ||
Comment 5•2 years ago
|
||
Update measurement units by running ./make_intl_data.py units
.
Depends on D160181
Assignee | ||
Comment 6•2 years ago
|
||
Update numbering systems by running ./make_intl_data.py numbering
.
Depends on D160182
Assignee | ||
Comment 7•2 years ago
|
||
Update SpiderMonkey to Unicode 15 by running ./make_unicode.py --version=UNIDATA
.
Depends on D160183
Assignee | ||
Comment 8•2 years ago
|
||
Update Gecko to Unicode 15 by running genUnicodePropertyData.pl
and
genSpecialCasingData.pl
.
Depends on D160184
Assignee | ||
Comment 9•2 years ago
|
||
UDAT_STANDALONE_NARROW_QUARTERS
has been promoted from draft to stable.
Depends on D160185
Assignee | ||
Comment 10•2 years ago
|
||
Use the fallback path for both new script codes.
Depends on D160186
Assignee | ||
Comment 11•2 years ago
|
||
CLDR 42 replaced plain ASCII space U+0020 with U+202F when formatting dates.
For backward-compatibility reasons we want to ensure that
Date.parse(date.toLocaleString())
works when the default locale is English,
therefore we have to normalise U+202F to U+0020.
Depends on D160187
Assignee | ||
Comment 12•2 years ago
|
||
CLDR 42 replaced plain ASCII space U+0020 with U+202F when formatting dates.
This change requires to update the expected results for more tests than usual.
Depends on D160188
Assignee | ||
Comment 13•2 years ago
|
||
Require at least ICU 72, because we're using ICU APIs which are only stable
in ICU 72.
Depends on D160189
Assignee | ||
Comment 14•2 years ago
|
||
See bug 1315397 for why a clobber is necessary.
Depends on D160190
Assignee | ||
Comment 15•2 years ago
|
||
Temporarily disable some test262 tests which no longer produce the expected
results when using CLDR 42 resp. Unicode 15. We can re-enable those tests when
we next update test262 and the following PRs are all merged upstream:
- https://github.com/tc39/test262/pull/3662
- https://github.com/tc39/test262/pull/3663
- https://github.com/tc39/test262/pull/3676
Depends on D160191
Comment 16•2 years ago
|
||
(In reply to André Bargull [:anba] from comment #12)
Created attachment 9300075 [details]
Bug 1792775 - Part 11: Update expected test results. r=#platform-i18n-reviewers!CLDR 42 replaced plain ASCII space U+0020 with U+202F when formatting dates.
This change requires to update the expected results for more tests than usual.
This is an interesting change. Do you know if any other browser has shipped it yet? I wonder if there are sites out there that do some kind of manipulation of a formatted date/time string, and depend on (ill-founded) assumptions about its contents. Or users who will be surprised when they copy/paste formatted dates somewhere and find that the "space" doesn't behave as expected -- e.g. perhaps they're copying the date from a webpage into an old form that only accepts ASCII.
Assignee | ||
Comment 17•2 years ago
|
||
(In reply to Jonathan Kew [:jfkthame] from comment #16)
This is an interesting change. Do you know if any other browser has shipped it yet?
Chrome is currently working on updating to ICU 72, too.
I wonder if there are sites out there that do some kind of manipulation of a formatted date/time string, and depend on (ill-founded) assumptions about its contents. Or users who will be surprised when they copy/paste formatted dates somewhere and find that the "space" doesn't behave as expected -- e.g. perhaps they're copying the date from a webpage into an old form that only accepts ASCII.
The output for date.toLocaleString()
is localised, so it already can contain non-ASCII characters. But I've seen code which manually tries to parse the output of new Intl.DateTimeFormat("en", options).format(date)
. That could break with this change.
Comment 18•2 years ago
|
||
Yeah..... no question, if code depends on such things, it's inherently fragile, buggy code. But it could still look to users like "the browser updated itself, and broke my website/workflow/...". Hopefully such things are rare.
Maybe we should try to synchronize (as nearly as possible) with Chrome's schedule, given the possibility of some breakage?
Comment 19•2 years ago
|
||
Maybe we should try to synchronize (as nearly as possible) with Chrome's schedule
I would agree given the webcompat risk.
Assignee | ||
Comment 20•2 years ago
|
||
I've posted a comment on the Chromium bug tracker to ask for an updated schedule for their ICU-72 integration plans.
We could also try to replace U+202F with U+0020 after calling into ICU in mozilla::intl::DateTimeFormat
, if it's necessary to update to ICU-72 sooner, for example because we want to support Unicode 15 to fix things like bug 1796880.
Comment 21•2 years ago
|
||
There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:anba, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Comment 22•2 years ago
|
||
I think we're waiting on landing this to coordinate timing with Chromium's update to ICU 72.
Assignee | ||
Comment 23•2 years ago
|
||
I didn't get a response in the Chromium bug tracker, but it looks like V8 was today updated to ICU 72. I guess that means the ICU 72 update will be in the 110 Chromium release, which is scheduled for Feb 7, 2023. If we land our ICU 72 update in the current Nightly, we'll have it in Firefox 110 (scheduled for Feb 14, 2023), so about the same time as the Chromium 110 release.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1371208#c15
[2] https://github.com/v8/v8/commit/08c469719caf45b7d1e898c9dc326b8d61cc3eb2
Assignee | ||
Comment 24•2 years ago
|
||
We don't use the "personNames" data, so let's filter it out to reduce the ICU data file size.
Depends on D160179
Assignee | ||
Comment 25•2 years ago
|
||
Depends on D160189
Comment 26•2 years ago
|
||
Comment 27•2 years ago
|
||
Comment 28•2 years ago
|
||
Backed out 3 changesets (Bug 1792775) for causing build bustages in dateTimeField.js CLOSED TREE
Logs:
https://treeherder.mozilla.org/logviewer?job_id=397429255&repo=autoland&lineNumber=59772
https://treeherder.mozilla.org/logviewer?job_id=397430386&repo=autoland&lineNumber=2256
https://treeherder.mozilla.org/logviewer?job_id=397429234&repo=autoland&lineNumber=55925
https://treeherder.mozilla.org/logviewer?job_id=397430737&repo=autoland&lineNumber=3554
https://treeherder.mozilla.org/logviewer?job_id=397430426&repo=autoland&lineNumber=4394
Backout: https://hg.mozilla.org/integration/autoland/rev/f823c1fd4adf66393fa51ddc039bf97855cd7a21
Assignee | ||
Comment 29•2 years ago
|
||
I had to push the patches in multiple steps, because Lando was always reporting an error when I tried to push everything at once. Landing the first three patches worked in the third try. I guess the other patches will also be backed out shortly, because they rely on the first three patches, which are now backed out. Sigh.
Comment 30•2 years ago
|
||
Sorry for the mess, had to backout the other changes too as the first backout was also busted.
Logs:
https://treeherder.mozilla.org/logviewer?job_id=397431307&repo=autoland&lineNumber=57989
https://treeherder.mozilla.org/logviewer?job_id=397431266&repo=autoland&lineNumber=20416
https://treeherder.mozilla.org/logviewer?job_id=397431265&repo=autoland&lineNumber=78938
Backout link: https://hg.mozilla.org/integration/autoland/rev/0f0c5d1ecfaff9a722f5e6085caf610516b03d3a
Comment 31•2 years ago
|
||
Comment 32•2 years ago
|
||
Backed out 16 changesets (Bug 1792775) for causing build bustage in TestDateIntervalFormat.cpp CLOSED TREE
Logs:
https://treeherder.mozilla.org/logviewer?job_id=397469233&repo=autoland&lineNumber=4080
https://treeherder.mozilla.org/logviewer?job_id=397469270&repo=autoland&lineNumber=15680
Backout: https://hg.mozilla.org/integration/autoland/rev/c300f1dba775b816820c22e7eed5ae860c236754
Assignee | ||
Comment 33•2 years ago
|
||
Interesting. Clang14/15 accepts "\u{...}" with -std=c++17
, even though that syntax is actually from C++23.
Comment 34•2 years ago
|
||
Comment 35•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7c90c9d2f39c
https://hg.mozilla.org/mozilla-central/rev/5ee93ac1caae
https://hg.mozilla.org/mozilla-central/rev/71a01400e4fe
https://hg.mozilla.org/mozilla-central/rev/c92b71e1b41d
https://hg.mozilla.org/mozilla-central/rev/8b10808f777b
https://hg.mozilla.org/mozilla-central/rev/3e1f11ae3da5
https://hg.mozilla.org/mozilla-central/rev/1c0774432aeb
https://hg.mozilla.org/mozilla-central/rev/772dbda0b3a0
https://hg.mozilla.org/mozilla-central/rev/a61361c04d92
https://hg.mozilla.org/mozilla-central/rev/6f75e695b8ea
https://hg.mozilla.org/mozilla-central/rev/ec6d6d1542df
https://hg.mozilla.org/mozilla-central/rev/ffd0f2c18d01
https://hg.mozilla.org/mozilla-central/rev/0ca8bf428e91
https://hg.mozilla.org/mozilla-central/rev/9e9f7f88851a
https://hg.mozilla.org/mozilla-central/rev/f01760fa98c6
https://hg.mozilla.org/mozilla-central/rev/b12f89a6bbff
Comment 36•2 years ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 37•2 years ago
|
||
backout |
This update was reverted from Beta109 due to bug 1806042. It remains landed for 110+ at this point, though there's still some discussion happening about whether that's what we want or not.
https://hg.mozilla.org/releases/mozilla-beta/rev/94c0c172ef0b
Description
•