Intent to Ship: Deprecate getters of Intl Locale Info

197 views
Skip to first unread message

Chromestatus

unread,
Nov 12, 2024, 3:34:33 PMNov 12
to blin...@chromium.org, ft...@google.com

Contact emails

ft...@google.com

Explainer

None

Specification

https://tc39.es/proposal-intl-locale-info

Design docs


https://docs.google.com/document/d/1BSpa-LKE69LL1g5CHZ3G06XEfffauwS24atfSUQiIDY/edit

Summary

Intl Locale Info API is a Stage 3 ECMAScript TC39 proposal to enhance the Intl.Locale object by exposing Locale information, such as week data (first day in a week, weekend start day, weekend end day, minimun day in the first week), and text direction hour cycle used in the locale. https://github.com/tc39/proposal-intl-locale-info We ship our implementation in m99 (https://chromestatus.com/feature/5566859262820352 ) . But later on the propose made some change in Stage 3 and move several getters to functions. We need to remove the deprecated getters and relaunch the renamed functions



Blink component

Blink>JavaScript>Internationalization

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

no other browser currently shipped with the removed getters. The earlier version of Safari has shipped it but removed a while ago (see below)



Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1693576)

WebKit: Shipped/Shipping (https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes) "Updated Intl.Locale to replace info getters with individual get… methods. (105570888)"

Web developers: Positive (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale) MDN document already remove these getters and put up the new functions

Other signals:

Ergonomics

low. remove getters



Activation

low. Since Mozilla never have these getters and Safari had it in version 15 but also removed them in version 17 already.



Security

none



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://github.com/tc39/test262/tree/main/test/intl402/Locale



Flag name on about://flags

harmony_remove_intl_locale_info_getters

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/42203770

Sample links


https://github.com/tc39/proposal-intl-locale-info

Estimated milestones

Shipping on desktop 133
Origin trial desktop first 131
Origin trial desktop last 133
DevTrial on desktop 131
Shipping on Android 133
Origin trial Android first 131
Origin trial Android last 133
DevTrial on Android 131
Origin trial WebView first 131
Origin trial WebView last 133


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5148228059398144?gate=5077569312653312

Links to previous Intent discussions

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/JE2ZUxqmsvM/m/WcUlJSZhBwAJ


This intent message was generated by Chrome Platform Status.

Daniel Bratell

unread,
Nov 13, 2024, 11:43:02 AMNov 13
to Chromestatus, blin...@chromium.org, ft...@google.com

Is this request to just deprecate them or is it to remove them as well, right away or at a future set date?

Secondly, you say usage is low, which makes a lot of sense, but do we know how low? Are there Use Counters or some other hard number we can lean on?

/Daniel

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6733bbcd.2b0a0220.26ec07.0802.GAE%40google.com.

Frank Tang (譚永鋒)

unread,
Nov 13, 2024, 4:29:52 PMNov 13
to Daniel Bratell, Chromestatus, blin...@chromium.org
On Wed, Nov 13, 2024 at 8:42 AM Daniel Bratell <brat...@gmail.com> wrote:

Is this request to just deprecate them or is it to remove them as well, right away or at a future set date?


The request is to remove the getters, which is removed from the proposed spec a while back. 
These getters were never part of the standard, and got renamed to functions during TC39 Stage 3. Safari change the getters to function a while ago. We launch the new function but not yet remove the old getters in M131 , and this is to remove the getters. 

Secondly, you say usage is low, which makes a lot of sense, but do we know how low? Are there Use Counters or some other hard number we can lean on?

we only have Use Counters for the Intl.Locale object itself. Which is 4 % page load. The usage of these getters therefore cannot > 4% of page load. But we do not believe 
I added the counter for the getters in the v8 side

 but somehow I forgot to add them into 
third_party/blink/public/mojom/use_counter/metrics/web_feature.mojom
tools/metrics/histograms/enums.xml
third_party/blink/renderer/bindings/core/v8/use_counter_callback.cc

yet. I will create a cl to add them now.


--
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊 
Sr. Software Engineer 

Frank Tang (譚永鋒)

unread,
Nov 13, 2024, 6:12:18 PMNov 13
to Daniel Bratell, Chromestatus, blin...@chromium.org
I added a cl https://chromium-review.googlesource.com/c/chromium/src/+/6020626 to add the counter. The first half of instrumenting the v8 code is done in 2023 but somehow I forgot to add them to the blink code.

Mike Taylor

unread,
Nov 14, 2024, 9:31:20 AMNov 14
to Frank Tang (譚永鋒), Daniel Bratell, Chromestatus, blin...@chromium.org

Thanks Frank.

4% as an upper bound is a very, very large number, so I think we should wait until we have proper UseCounter data for each of the getters to better understand the compatibility risk.

Reply all
Reply to author
Forward
0 new messages