Intent to Implement: Fix for Accept-Language HTTP Headers

[Claudio Magni]

Contact emails

claudi...@google.com, yyus...@google.com

Spec

See design doc.

The HTTP headers spec is here.

Summary

We want to change how Chrome generates the Accept-Language HTTP headers. As websites tend to only accept languages without region (i.e. “en” vs “en-AU”), the user could receive websites in an unexpected language. We plan to add the base language in the correct position so that users receive webpages in their preferred language.

Motivation

Some users have a bad user experience when they receive a website that is not in their preferred language, despite having set their language preferences correctly.

Interoperability and Compatibility Risk

This change is meant to fix an existing problem by increasing compatibility, so I see very little risk. In particular, websites that are currently working correctly are not affected.

Ongoing technical constraints

None.

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

Yes.

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

Yes, it will be tested.

The relevant tests already exist in "src/third_party/WebKit/LayoutTests/http/tests/".

OWP launch tracking bug

I don't think I need one in this case.

Feature dashboard

N/A

Requesting approval to ship?

No.

The change will be behind a flag and we will ship it later. I'll send another email accordingly.

[PhistucK]

See my comments inline.

☆PhistucK

On Wed, Aug 2, 2017 at 4:45 AM, 'Claudio Magni' via blink-dev <blin...@chromium.org> wrote:

Contact emails

claudi...@google.com, yyus...@google.com

Spec

See design doc.

The HTTP headers spec is here.

Summary

We want to change how Chrome generates the Accept-Language HTTP headers. As websites tend to only accept languages without region (i.e. “en” vs “en-AU”), the user could receive websites in an unexpected language. We plan to add the base language in the correct position so that users receive webpages in their preferred language.

​So would en-AU,fr;q=0.8 and en-AU,fr;​q=0.8,en;q=0.6 become en-AU,en,fr=0.8?

 

Motivation

Some users have a bad user experience when they receive a website that is not in their preferred language, despite having set their language preferences correctly.

How many users are "some"?​ How do you quantify that?

 

Interoperability and Compatibility Risk

This change is meant to fix an existing problem by increasing compatibility, so I see very little risk. In particular, websites that are currently working correctly are not affected.

​What about the interoperability part? What do each and every browser do at the moment?​

 

Ongoing technical constraints

None.

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

Yes.

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

Yes, it will be tested.

The relevant tests already exist in "src/third_party/WebKit/LayoutTests/http/tests/".

​Does that mean you will be upstreaming those tests to web-platform-tests?​

 

OWP launch tracking bug

I don't think I need one in this case.

Feature dashboard

N/A

Requesting approval to ship?

No.

The change will be behind a flag and we will ship it later. I'll send another email accordingly.

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BQCODoc%3Df_2QRFvPzdftKwTsBuMEeX%3Db-nCrxCt-UJBsoAt1A%40mail.gmail.com.

[Mounir Lamouri]

On Wed, 2 Aug 2017, at 13:45, PhistucK wrote:
> See my comments inline.
>
>
> ☆*PhistucK*

>
> On Wed, Aug 2, 2017 at 4:45 AM, 'Claudio Magni' via blink-dev <
> blin...@chromium.org> wrote:
>
> > Contact emails
> >
> > claudi...@google.com, yyus...@google.com
> >
> > Spec
> >
> > See design doc

> > <https://docs.google.com/document/d/10eGUww_2Ufv-YyGwnmr9ke_89Q6By_94v02FM_NTU24/edit?usp=sharing>
> > .

> >
> > The HTTP headers spec is here

> > <https://tools.ietf.org/html/rfc7231#section-5.3.5>.

> >
> > Summary
> >
> > We want to change how Chrome generates the Accept-Language HTTP headers.
> > As websites tend to only accept languages without region (i.e. “en” vs
> > “en-AU”), the user could receive websites in an unexpected language. We
> > plan to add the base language in the correct position so that users receive
> > webpages in their preferred language.
> >
>
> ​So would en-AU,fr;q=0.8 and en-AU,fr;​q=0.8,en;q=0.6 become
> en-AU,en,fr=0.8
> ?

What if the user has multiple sub-locales such as en-GB, en-AU and
en-US?

> > Motivation
> >
> > Some users have a bad user experience when they receive a website that is
> > not in their preferred language, despite having set their language
> > preferences correctly.
> >
>
> How many users are "some"?​ How do you quantify that?

Also, do you have examples where this issue happens?

> > Interoperability and Compatibility Risk
> >
> > This change is meant to fix an existing problem by increasing
> > compatibility, so I see very little risk. In particular, websites that are
> > currently working correctly are not affected.
> >
>
> ​What about the interoperability part? What do each and every browser do
> at
> the moment?​

FWIW, Firefox seems to automatically add the base locale. If you have
en-AU set for your browser, it will automatically add "en" to your list
of preferred language but you can remove it by changing the pref.

> > Ongoing technical constraints
> >
> > None.
> >
> > Will this feature be supported on all six Blink platforms (Windows, Mac,
> > Linux, Chrome OS, Android, and Android WebView)?
> >
> > Yes.
> >
> >
> > Is this feature fully tested by web-platform-tests

> > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> > ?

> >
> > Yes, it will be tested.
> >
> > The relevant tests already exist in "src/third_party/WebKit/
> > LayoutTests/http/tests/".
> >
>
> ​Does that mean you will be upstreaming those tests to
> web-platform-tests?​
>
>
> >
> > OWP launch tracking bug
> >
> > I don't think I need one in this case.
> >
> >

> > *Feature dashboard*

> >
> > N/A
> >
> > Requesting approval to ship?
> >
> > No.
> >
> > The change will be behind a flag and we will ship it later. I'll send
> > another email accordingly.
> >
> > --
> > 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 on the web visit https://groups.google.com/a/
> > chromium.org/d/msgid/blink-dev/CA%2BQCODoc%3Df_2QRFvPzdftKwTsBuMEeX%3Db-
> > nCrxCt-UJBsoAt1A%40mail.gmail.com

> > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BQCODoc%3Df_2QRFvPzdftKwTsBuMEeX%3Db-nCrxCt-UJBsoAt1A%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+...@chromium.org.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_LBq6f93tqPNzP%3DcLg6jjZLRymwLOzCZCNuaq-Q_oCXXg%40mail.gmail.com.

[Claudio Magni]

Replies inline.

I have updated the design doc to include another edge case we came up with. Also, the doc is now open for comments.

On 3 August 2017 at 06:45, PhistucK <phis...@gmail.com> wrote:

See my comments inline.

☆PhistucK

On Wed, Aug 2, 2017 at 4:45 AM, 'Claudio Magni' via blink-dev <blin...@chromium.org> wrote:

Contact emails

claudi...@google.com, yyus...@google.com

Spec

See design doc.

The HTTP headers spec is here.

Summary

We want to change how Chrome generates the Accept-Language HTTP headers. As websites tend to only accept languages without region (i.e. “en” vs “en-AU”), the user could receive websites in an unexpected language. We plan to add the base language in the correct position so that users receive webpages in their preferred language.

​So would en-AU,fr;q=0.8 and en-AU,fr;​q=0.8,en;q=0.6 become en-AU,en,fr=0.8?

That's correct. 

 

Motivation

Some users have a bad user experience when they receive a website that is not in their preferred language, despite having set their language preferences correctly.

How many users are "some"?​ How do you quantify that?

It's hard to quantify it. We don't have a metric that tracks this. In the design doc I have listed a couple of bugs (crbug/737232, crbug/640763).

We suspect many bugs go unreported, because users might not be aware of this and blame the website for showing an unexpected language.

 

 

Interoperability and Compatibility Risk

This change is meant to fix an existing problem by increasing compatibility, so I see very little risk. In particular, websites that are currently working correctly are not affected.

​What about the interoperability part? What do each and every browser do at the moment?​

I have tested other browers. These are the results of my findings:

• Safari: only the top language is used for the header. The header always contains a single language and it does not fallback to the base language from a regional one. However the set of languages that can be sent in the header is limited and I wasn't able to figure out the exact logic that governs it. For example, English languages are sent as "en", while Spanish-Argentina is passed as "es-es".
  
• Firefox: the header matches exactly the language list in the user preferences. Nothing is added or moved, thus they do not perform the expansion that we are suggesting in this design.
• Edge: given that in the user preferences they do not allow a base language without at least a region associated to it, they add the base language after the last occurrence of any corresponding regional language. Out of all the browsers, their behavior is the closest to the one we want to implement, with just small differences in a few edge cases.
• Opera: did not test.

This page has a good summary of the different behaviors.

In summary, each browser does it own thing regarding Accept-Language headers and our change would be in line with Edge browser.

 

Ongoing technical constraints

None.

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

Yes.

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

Yes, it will be tested.

The relevant tests already exist in "src/third_party/WebKit/LayoutTests/http/tests/".

​Does that mean you will be upstreaming those tests to web-platform-tests?​

If that's what is required, yes. :-)

I am not familiar with the web-platform-tests, so I will learn what to do there.

[radchenk...@gmail.com]

Hi guys

Im use Chrome Browser and language settings is set to English

but accept-language is come as ru-RU,ru;q=0.9,en;q=0.8,ar;q=0.7

so, there is a question, why I have 'ru' in the headers, if its does not set in the settings, also does not set in the account settings, and Im located in the Ukraine ?

thanks

[PhistucK]

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.

☆PhistucK

--

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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b12a9a19-2854-4cd7-99d4-9459931d3ce0%40chromium.org.

[Yana Yushkina]

This sounds like crbug.com/784740. Take a look and add a screenshot of your chrome://settings/languages and whether you're signed into the browser and using Chrome Sync.

Anthonyvd@ is currently working on it already so hopefully a fix should be available soon. 

--

Yana Yushkina

Product Manager -  Chrome Custom Fit & Language

Google, Inc.