https://github.com/brettz9/intl-locale-textinfo-polyfill/issues/2#issuecomment-3367441048


On Thu, Oct 2, 2025 at 1:37 PM Frank Tang (譚永鋒) <[email protected]> wrote:

> see
>
>
> https://docs.google.com/spreadsheets/d/1detya2rQsAHzZYm13x-zn-Rea97gtqCisX9fRcmFAFg/edit?usp=sharing&resourcekey=0-4FRh3mbBAS2JLKtAtgdzBg
>
>
>
> On Thu, Oct 2, 2025 at 1:33 PM Frank Tang (譚永鋒) <[email protected]> wrote:
>
>> I have similar finding. I look at about 10 more after Philip. Almost all
>> of them try to access
>> textInfo and weekInfo only
>> And about 30% of them fallback to getTextInfo or a default value.
>>
>>
>>
>> On Thu, Aug 28, 2025 at 1:41 AM Philip Jägenstedt <[email protected]>
>> wrote:
>>
>>> Checking in on this again,
>>> https://chromestatus.com/metrics/feature/timeline/popularity/5232 shows
>>> increasing usage, so it would be good to decide on a path forward.
>>>
>>> Based on the use counter call sites
>>> <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/builtins-intl.cc;l=799-854;drc=50ade2d8d071e10bc5d53234bb2c0b311c515940>,
>>> these are the properties in question:
>>>
>>>    - Intl.Locale.prototype.calendars
>>>    - Intl.Locale.prototype.collations
>>>    - Intl.Locale.prototype.hourCycles
>>>    - Intl.Locale.prototype.numberingSystems
>>>    - Intl.Locale.prototype.textInfo
>>>    - Intl.Locale.prototype.timeZones
>>>    - Intl.Locale.prototype.weekInfo
>>>
>>>
>>> I exported the 106 sites listed on chromestatus.com into a spreadsheet,
>>> sorted them randomly:
>>>
>>> https://docs.google.com/spreadsheets/d/1_oOhcPq5fgOkd4pD9crSJqu2fnpyL2j7M9pxw7n_nD8/edit?usp=sharing
>>>
>>> I looked at the first 10, searching for "Intl.Locale" in devtools.
>>>
>>> 8 of them use textInfo without fallback to getTextInfo(). Instead, they
>>> just assume "ltr". If the sites don't support any RTL language, then I
>>> don't think anybody would notice, but presumably some sites like
>>> adobe.com do.
>>>
>>> 2 of the sites seem to correctly fall back to the get*() methods, and if
>>> they changed the order of their code wouldn't even trigger our use counters.
>>>
>>> I found and filed a bug for the most common pattern:
>>> https://github.com/expo/expo/issues/39205
>>>
>>> Frank, would you be able to analyze another 10 or 20 to see if there are
>>> other common patterns?
>>>
>>> From what I've found I'm fairly confident the breakage wouldn't be
>>> severe, but it would be good to notify libraries that need to adjust, so
>>> that developers have a fix if they are affected.
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Thu, Mar 13, 2025 at 4:54 PM Chris Harrelson <[email protected]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 12, 2025 at 4:22 PM 'Panos Astithas' via blink-dev <
>>>> [email protected]> wrote:
>>>>
>>>>> On Wed, Mar 12, 2025 at 3:12 PM Mike Taylor <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> On 3/12/25 5:38 PM, Frank Tang (譚永鋒) wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 12, 2025 at 8:19 AM Chris Harrelson <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 5, 2025 at 10:39 AM 'Frank Tang (譚永鋒)' via blink-dev <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 5, 2025 at 6:02 AM Daniel Bratell <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Looks like the use counter LocaleInfoObsoleteGetters is at 0.033%
>>>>>>>>> which is a bit high.
>>>>>>>>>
>>>>>>>> Dear Daniel:
>>>>>>>>
>>>>>>>> From your point of view, could you please define what number would
>>>>>>>> be considered as not "high" or "low enough" ?
>>>>>>>>
>>>>>>>
>>>>>>> We don't have a hard and fast rule, but in this case it's "high
>>>>>>> enough" that we would like a bit more info to estimate risk.
>>>>>>>
>>>>>>
>>>>>> If there are no hard and fast rules, then how do we determine 0.033%
>>>>>> is a bit high? but not low enough? gut feeling?
>>>>>>
>>>>>> Experience breaking things. See
>>>>>> https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.83o2xr8ayal6.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> I can't see LocaleInfoFunctions at all so does that mean that it
>>>>>>>>> has never been triggered?
>>>>>>>>>
>>>>>>>> No, we didn't hook up that to the same UI. All other intl features
>>>>>>>> were hook up with this UI and while I added the CL
>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/6020626/
>>>>>>>> So
>>>>>>>> syg@ said I should not use blink_feature but webdx_feature due to 
>>>>>>>> "jstenback's
>>>>>>>> email about WebDX features"
>>>>>>>>
>>>>>>>> So I hooked up the counter of both kLocaleInfoObsoletedGetters
>>>>>>>> and kLocaleInfoFunctions to that
>>>>>>>> but we later on find there are no easy way to access that info from
>>>>>>>> public UI yet. So in
>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/6089243
>>>>>>>> I change LocaleInfoObsoleteGetters back to blink_feature
>>>>>>>>
>>>>>>>> I am not sure how to access the query to check webdx_feature. If
>>>>>>>> anyone know how to query that, we can see from that.
>>>>>>>>
>>>>>>>
>>>>>>> Your use counter is here:
>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5232
>>>>>>>
>>>>>>
>>>>>> That one is for LocaleInfoObsoleteGetters, which is  blink_feature
>>>>>> that we know how to see the counter
>>>>>>
>>>>>>
>>>> Ok, but the URL above also lists various sites that are
>>>> triggering LocaleInfoObsoleteGetters, ranked by popularity. I'm suggesting
>>>> checking the top 20 such sites to see if any are broken.
>>>>
>>>> [image: Screenshot 2025-03-13 8.53.08 AM.png]
>>>>
>>>>
>>>>> What we do not know how to access is kLocaleInfoFunctions, which is
>>>>>> webdx_feature that we do not know how to access the counter.
>>>>>>
>>>>>> Please reach out to pastithas@ or kadirtopal@ for help on that.
>>>>>>
>>>>>
>>>>> Unfortunately we don't yet expose these use counters in ChromeStatus,
>>>>> but we're working on it. In the meantime internal UMA data
>>>>> <https://uma.googleplex.com/p/chrome/timeline_v2?sid=f68dc5965348456a1cfb7dae5fa891d8>
>>>>>  should
>>>>> help make progress here.
>>>>>
>>>>> Thanks,
>>>>> Panos
>>>>>
>>>>> --
>>>>> 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/CAJ8Nf23YhpqRu91ShWcrQLgeoOrjC5KsDnhexLVK7S-sGM7tfA%40mail.gmail.com
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ8Nf23YhpqRu91ShWcrQLgeoOrjC5KsDnhexLVK7S-sGM7tfA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> 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/CAOMQ%2Bw-Rxs7zGWcNUMv2iDi4GxkWD%3Dh%2B5v8ABuim9z08c7VweQ%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-Rxs7zGWcNUMv2iDi4GxkWD%3Dh%2B5v8ABuim9z08c7VweQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>
>> --
>> Frank Yung-Fong Tang
>> 譚永鋒 / 🌭🍊
>> Sr. Software Engineer
>>
>
>
> --
> Frank Yung-Fong Tang
> 譚永鋒 / 🌭🍊
> Sr. Software Engineer
>


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

-- 
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/CA%2B7fzPEKEqs9YRufERfttUStnMEqxSd6yytExYkBsAw%2B9ZQZ3g%40mail.gmail.com.

Reply via email to