Hey Alex (and others),
Here’s a few questions we asked ourselves to hopefully answer questions you
or others might have, in order to feel comfortable with moving forward with
this experiment:
1.
What do we hope to learn from this 1% stable experiment that we can’t
already get from UMA or pre-release experimental data?
1.
With this 1% stable experiment, we would like to test the following
hypotheses:
1.
Reducing accept-language won’t cause site breakage or meaningful
compatibility issues since the majority of users only have 1 or 2
language
preferences: e.g., on Mac 68% users have a single language, and 95% of
users have 2 or fewer. That said, breaking the experience for upwards
of 5%
of users is clearly a bad situation to be in and unshippable - hence
we’re
trying to gather more information.
2.
The feature won’t introduce significant regressions to LCP.
2.
In Chrome 109, we ran an Origin Trial to test these assumptions - but
we had only a few origins participating. It’s hard to draw useful
conclusions about the feature design from this data, unfortunately.
3.
In our pre-release studies we observe the following:
1.
LCP changes are neutral.
2.
For language related metrics:
1.
We don’t see any significant changes in the number of languages
that users choose to always translate via the built-in Translate UI.
2.
It's also neutral for other manually translated language
metrics from UI.
3.
That said, the pre-release population is quite small and gathering
data for 1% of users would help us better understand potential impact.
2.
What % of top sites are using Accept-Language? Do we know what % of
traffic those sites represent?
1.
What % of top sites are using Accept-Language
1.
From our crawl-based study on the top 10K sites data provided by
Tranco <https://tranco-list.eu/>, only only 773 sites
(773/7889*100 = 9.8%) respond to different languages when setting
different values on the Accept-Language header.
2.
For top 10K sites in UK, only 366 sites (366/9744*100 = 3.7%)
respond to different languages when setting different values on the
Accept-Language header.
2.
What % of traffic those sites represent
1.
We don’t have this data handy, but from the top 10k sites that
support multiple languages, ~200 of 773 contain google in the
origin.
3.
Do we already know how frequently `Content-Language` or HTML `lang`
(where they exist in responses) are different from the first language
preference? This should help us estimate some “wrong language breakage”.
1.
Content-language metrics:
1.
Nearly 96% of sites don’t send a Content-Language header or the
content is empty in the header including most of the large sites. 2.2%
of
content-language headers matches any user’s accept-language, only 1.4%
of
content-language headers matches the user’s first language. So there’s
not
a lot of useful data to use here to make compat predictions.
2.
HTML lang metrics:
1.
77% of html lang matches the user's first language, and 5% match
any user’s language preference. 17% is empty.
3.
You can infer an upper bound of breakage from this, but there’s so
much missing data sent by servers that it’s hard to have a lot of
confidence just based on this. And we suspect that upper bound is way
larger than actual potential breakage would be.
Hope those are helpful.
Bests Regards,
Victor
On Wednesday, August 21, 2024 at 12:07:29 PM UTC-4 Victor Tan wrote:
> Hi Alex,
> I will try to get approval to publish some data if that helps.
>
> Victor
>
> On Wed, Aug 21, 2024 at 11:58 AM Alex Russell <slightly...@chromium.org>
> wrote:
>
>> Sorry for the slow response.
>>
>> Victor: it would be good to see some of that data if and when y'all can
>> publish it. The API OWNERS aren't generally keen to take breakage risks on
>> faith.
>>
>> Best,
>>
>> Alex
>>
>> On Wednesday, August 21, 2024 at 1:26:24 AM UTC-7 Mike Taylor wrote:
>>
>>> Thanks for the thoughtful article and feedback Yoav - we'll chat about
>>> it internally.
>>> On 8/20/24 11:24 PM, Yoav Weiss (@Shopify) wrote:
>>>
>>> <api owner hat off>
>>>
>>> I wrote a few words about this proposal and how I think we can avoid
>>> some of the tradeoffs it is making and end up with better user experience
>>> *and* more privacy:
>>> https://blog.yoav.ws/posts/improving_language_negotiation/
>>>
>>> On Wed, Aug 7, 2024, 17:41 Victor Tan <victor...@chromium.org> wrote:
>>>
>>>> Email Body
>>>>
>>>> Contact emails
>>>>
>>>> victor...@chromium.org, miketa...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/explainers-by-googlers/reduce-accept-language
>>>>
>>>> TAG review To be filed.
>>>> Summary
>>>>
>>>> In order to reduce the amount of passively available entropy in HTTP
>>>> requests, we want to reduce the amount of information the Accept-Language
>>>> header exposes in HTTP requests and JS interface navigator.languages.
>>>> Instead of sending every user's language preferences via Accept-Language,
>>>> we only send the user’s most preferred language after language negotiation
>>>> in the Accept-Language header. For the HTTP Accept-Language header, we
>>>> will
>>>> potentially expand a base language based on the language-region pair
>>>> (e.g.,
>>>> if the preferred language is “en-US” we will expand to “en-US, en;q=0.9”).
>>>> The JS getter navigator.languages returns the same value as
>>>> navigator.language.
>>>>
>>>> We would like to run a Finch 1% experiment from M128 to M131 inclusive.
>>>>
>>>> Blink component
>>>>
>>>> Privacy>Fingerprinting
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EFingerprinting>
>>>>
>>>> Risks
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> The compatibility risk is relatively low for most users since we're
>>>> planning to reduce the amount of information in the Accept-Language header
>>>> and navigator.languages, rather than remove the header or change value
>>>> format in the header. Most existing Accept-Language detection code should
>>>> continue to work. This experiment should help us validate this assumption
>>>> and identify corner cases.
>>>>
>>>> As for interoperability, for multilingual sites to rely on the
>>>> Accept-Language, developers would need to depend on a user's full
>>>> Accept-Language list for some browsers and a primary user's
>>>> Accept-Language
>>>> for others. Another signal is that the Chrome incognito model already
>>>> reduced the Accept-Language header and JS interface navigator.languages to
>>>> one language, and Safari ships this behavior for many users today.
>>>>
>>>> Gecko: Pending (
>>>> https://github.com/mozilla/standards-positions/issues/1014)
>>>>
>>>> WebKit: Shipped (
>>>> https://github.com/WebKit/standards-positions/issues/338) Safari
>>>> already reduced the Accept-Language to a single language in most cases.
>>>>
>>>> Web developers: Some web developers are concerned about the
>>>> client-side language negotiation implications (
>>>> https://github.com/Tanych/accept-language/issues/10).
>>>>
>>>> Experiment Goals
>>>>
>>>> The goal of this experiment is to ensure web compatibility with our
>>>> proposed changes. Developers can also test how reducing the
>>>> Accept-Language
>>>> request header and the JS getter navigator.languages will affect their
>>>> systems via the chrome://flags/#reduce-accept-language flag,
>>>> especially to understand the impact on client side language negotiation
>>>> via
>>>> navigator.languages. We will be relying heavily on user and developer
>>>> feedback to identify where breakage occurs, or where use cases are not
>>>> accounted for, especially for multilingual sites depending on the
>>>> Accept-Language header, and navigator.languages.
>>>>
>>>> Experiment Risks
>>>>
>>>> There are some risks, as many multilingual sites have come to rely on
>>>> the value in Accept-Language header and JS interfaces navigator.languages
>>>> to send the right representation pages to the user. Site breakage can
>>>> take
>>>> many forms, both obvious and non-obvious - which is the point of running
>>>> this experiment. If we are confident the design is largely web-compatible,
>>>> we will request a Deprecation Trial for sites to be able to have time to
>>>> migrate or modify how their sites work.
>>>>
>>>> Debuggability
>>>>
>>>> Both of these settings and the resulting network requests are visible
>>>> in DevTools.
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>
>>>> No (All but WebView)
>>>>
>>>> Is this feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>> ?
>>>>
>>>> No (We fully test in browser_tests, WPT has limits to cover all the
>>>> test cases in the Accept-Language header).
>>>>
>>>> Flag name on chrome://flags
>>>>
>>>> #reduce-accept-language
>>>>
>>>> Finch Flag name
>>>>
>>>> kReduceAcceptLanguage
>>>> Tracking bug
>>>>
>>>> https://issues.chromium.org/issues/40218547
>>>> Launch bug
>>>>
>>>> https://launch.corp.google.com/launch/4317282
>>>> Link to entry on the Chrome Platform Status
>>>>
>>>> https://chromestatus.com/feature/5188040623390720
>>>> <https://chromestatus.com/feature/5188040623390720#details>
>>>>
>>>> --
>>>> 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+unsubscr...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HuVnM9iE1%2BMF2pY%3DP%3DVNHmtP%2B1oZdUQ2Hm2bMjrW04Dw%40mail.gmail.com
>>>>
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7HuVnM9iE1%2BMF2pY%3DP%3DVNHmtP%2B1oZdUQ2Hm2bMjrW04Dw%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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d538dcc-db6c-4cc4-9012-fa2f984d4c83n%40chromium.org.
