New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 640763 link

Starred by 15 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 765077
issue 390966
issue 626153
issue 628989
issue 661326
issue 719760



Sign in to add a comment

Accept-Languages expansion should not change user preferences

Project Member Reported by michae...@chromium.org, Aug 24 2016

Issue description

The user preference intl.accept_languages has overloaded meanings:

1. Populates the ordered list of the user's enabled languages in chrome://settings/languages. These are untranslated by default. Users can choose to re-enable translation for an enabled languages; they can also choose to enable spell-checking for an enabled language.

2. Populates the Accept-Language header. This is an ordered list of preferred languages that a web server should use for content.

Because of (2), when the preference is set in TranslatePrefs::UpdateLanguageList, we expand the list from the user to include families of languages. For example, if the user adds "Spanish (Spain)", we will automatically also add "Spanish". The rationale is that if the user's top Accept-Language is "Spanish (Spain)", website that supports "Spanish" but not "Spanish (Spain)" should serve content in "Spanish" rather than other less-preferred languages. ( Issue 192309 )

The unfortunate consequence is that the user cannot remove these automatically-added languages in Settings, because the list is automatically re-expanded whenever we change the preference. This gives the illusion that "Spanish" cannot be removed without first removing all sub-languages, e.g. "Spanish (Spain)".

The transformation done for Accept-Languages shouldn't affect the user's language list, translate languages, etc. We should calculate the Accept-Languages list when the pref changes, but not commit that list back to the pref.

 
Cc: groby@chromium.org hajimehoshi@chromium.org
CCing folks from translate OWNERS as that seems the most relevant area. Untangling this would clear up some confusion and glitches in the Language settings UI (see blocked bugs).

Comment 2 by groby@google.com, Oct 28 2016

I like it. Is that related to CrOS introducing settings.language.preferred_languages, or is that there for yet another reason?

If there's no other reason, here's what I propose:

1) Remove all reads of intl.accept_languages, replace with ContentBrowserClient::GetAcceptLangs
2) Add automatic expansion (order-preserving, please) in there. This should always generate identical results.
3) Remove list expansion in settings.
4) Migrate Chrome languages to settings.language.preferred_languages, for the general sanity of all involved. Consider intl.accept_languages a youthful mistake and NUKE IT FROM ORBIT. Just to be sure.

SG?
#2: I suspect the reason CrOS uses "language.preferred_languages" is mostly historical and had to do with input method support.

But, whoa. I knew that Chrome OS uses "language.preferred_languages", but I hadn't realized/noticed that saves it from these expansion problems in Settings. The expansion happens under-the-hood (still via the intl.accept_languages pref) just like we want; it's exposed to servers but not to the user. We show the user the user-determined pref and only use the derived pref for Accept-Languages.

In other words, I think Chrome OS already has a valid solution, which we could migrate other platforms to.

The only difference from your proposition is that you propose nuking the intl.accept_languages pref entirely. Generate what its value would be for Accept-Languages, without storing that value in a pref. That should be functionally equivalent, so we should just consider which option is simpler/more efficient.
Cc: zkoch@chromium.org
Blocking: 661326
Cc: msrchandra@chromium.org michae...@chromium.org ranjitkan@chromium.org rbasuvula@chromium.org nyerramilli@chromium.org
 Issue 689921  has been merged into this issue.
this also has implications for the spell-check languages shown, as reported in  issue 689921 
Cc: napper@chromium.org
Labels: Hotlist-LanguageSettings
Components: -UI>Browser>Translate UI>Browser>Language>Translate
Owner: napper@chromium.org
Status: Assigned (was: Untriaged)
Owner: claudiomagni@chromium.org
Cc: claudiomagni@chromium.org
 Issue 722207  has been merged into this issue.
Quick update: I have a working change that fixes the expansion issue, but I want to discuss with Yana and Bruno before I send it for review.
I need to understand the consequences of the change in the whole picture of Language Settings revamp.
I reported  Issue 636721  some time ago, is it a related issue?
Components: -UI>Browser>Language>Translate UI>Browser>Language
Cc: js...@chromium.org
 Issue 636721  has been merged into this issue.
Claudio: as per our convo, let's make sure your fix also addresses the issue raised in 636721 about respecting locale preferences in the actual accept language header.
Blocking: 719760
 Issue 287772  has been merged into this issue.
Blocking: 390966
Blockedon: 765077
Blocking: 765077
Blockedon: -765077
Project Member

Comment 25 by bugdroid1@chromium.org, Sep 25 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/31f0d7fc389035ee8403ecc22759715ee98042de

commit 31f0d7fc389035ee8403ecc22759715ee98042de
Author: Claudio Magni <claudiomagni@chromium.org>
Date: Mon Sep 25 06:52:57 2017

Remove automatic expansion of language list in Settings.

This is part of a large change for Language Settings.
This CL only fixes the automatic expansion of the language list, which adds the base language
whenever a locale-specific one is added.
The feature is behind a disabled flag.

Bug:  640763 , 765077
Change-Id: Ie7d32c06bef0f933bf1e097a277ac063a9c2b54e
Reviewed-on: https://chromium-review.googlesource.com/670459
Commit-Queue: Claudio M <claudiomagni@chromium.org>
Reviewed-by: Dave Schuyler <dschuyler@chromium.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503993}
[modify] https://crrev.com/31f0d7fc389035ee8403ecc22759715ee98042de/components/translate/core/browser/translate_prefs.cc
[modify] https://crrev.com/31f0d7fc389035ee8403ecc22759715ee98042de/components/translate/core/browser/translate_prefs.h
[modify] https://crrev.com/31f0d7fc389035ee8403ecc22759715ee98042de/components/translate/core/browser/translate_prefs_unittest.cc
[modify] https://crrev.com/31f0d7fc389035ee8403ecc22759715ee98042de/tools/metrics/histograms/enums.xml

 Issue 792379  has been merged into this issue.
Project Member

Comment 27 by bugdroid1@chromium.org, Dec 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/61c210920199165e81bdbbbfd57dc7cb7750bd42

commit 61c210920199165e81bdbbbfd57dc7cb7750bd42
Author: Claudio Magni <claudiomagni@chromium.org>
Date: Thu Dec 28 02:34:19 2017

Add the flag to enable/disable the recent fixes to Language Settings.

We have been working on fixing the main bugs with Language Settings
for a while and we are ready to do the final manual testing and launch.

Bug:  640763 
Change-Id: I9dba8e4087267f094b98d0029696bb09f196c86b
Reviewed-on: https://chromium-review.googlesource.com/845241
Reviewed-by: Renjie Liu <renjieliu@chromium.org>
Commit-Queue: Claudio M <claudiomagni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526268}
[modify] https://crrev.com/61c210920199165e81bdbbbfd57dc7cb7750bd42/chrome/browser/about_flags.cc
[modify] https://crrev.com/61c210920199165e81bdbbbfd57dc7cb7750bd42/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/61c210920199165e81bdbbbfd57dc7cb7750bd42/chrome/browser/flag_descriptions.h

Owner: ----
Status: Fixed (was: Assigned)
The automatic expansion has been removed in M65.
Owner: claudiomagni@chromium.org

Sign in to add a comment