Issue 855192  has been merged into this issue.

A third part of this comes from 855192:
1. For any user who has more than one language in the accept-language list *that can be translated* (so if a user has en-us and en it doesn't count, or if a user has a second language that can't be translated to it doesn't count), allow them to opt into translations on the UI Language 
2. If they opt in, in that case the next language in the list becomes the target.

Here is a suggested change in behavior that I think would fix all of the above. We can always ensure at least one candidate target language (i.e. a language we can translate to) is in the list. Anytime there is more than one candidate target language, we allow any language to be marked as translatable, removed, etc... If there is only a single candidate target language, prevent it from being checked as "Offer to translate pages in this language". Finally, we could make sure the list is never empty by adding back the UI language if neccessary (and preventing its removal if its the last language). 

All of that sounds good except for: We should never allow the target language to be marked as translatable (even if other languages are present) because then we won't know what to translate it to.

From my understanding, there is no explicit target language. At run time, we pass the list of languages, and a target language is chosen from that. So I don't see a problem with marking any language as translatable as long as there is one that isn't. Unless we want to keep the top language of the list as the target language.

Actually that's not true. There is an explicit target language which by default is the most recent target language, or for users who have never translated, it's the UI language.

The (default) target language ends up always being the UI language because 1. it is always translatable, 2. we see if we can use it as a target language before checking the Accept Language list.

If the user marks the most recent target language as translatable, then we should just reset the most recent target language. As for the UI language, I think we should not treat it differently from all other suitable candidate target languages in the accepted languages list. If the user marks the UI language as translatable, then the target language should become the next suitable language in the list.

Talked in person:
1. We will always have the target language at the top and if the user changes it - either in the UI by moving it up or down or in language preferences - we will adjust it accordingly.
2. Only the target language will remain untranslatable.
3. We will add a string underneath the top language  - if translation is enabled - that states: "This language is used for translations." or something like that (frechette@ will add this as a separate bug and cc srahim@ and dpapad@ on it)

Also, this is specified in the OS checks below, but just to make it clear: we don't want to touch iOS with these changes since iOS does not have Chrome language settings.

"either in the UI by moving it up or down or in language preferences" should read "either in the Translate UI by changing the "to" language there or by moving it to the top in Languages settings" 

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

commit 570a7457a1f2eae2b59d1e282da69e6ef2a66c43
Author: Alexandre Frechette <frechette@chromium.org>
Date: Tue Nov 06 18:18:59 2018

[Accept Languages List] Check all criteria when updating whether a language can
be translated or not.

Bug: 872096
Change-Id: I9cd2df787c46f6b95f3918adaf8023a030c0b480
Reviewed-on: https://chromium-review.googlesource.com/c/1313416
Commit-Queue: Alexandre Frechette <frechette@chromium.org>
Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605744}
[modify] https://crrev.com/570a7457a1f2eae2b59d1e282da69e6ef2a66c43/chrome/browser/resources/settings/languages_page/languages.js
[modify] https://crrev.com/570a7457a1f2eae2b59d1e282da69e6ef2a66c43/chrome/test/data/webui/settings/languages_page_tests.js

This bug now tracks the effort to line up the concept of a target language (and everything related to it) with the accept languages list. And also fix a few inconsistencies with the list itself.

See go/chrome-language-accept-list

 Issue 889946  has been merged into this issue.

go/language-fluency-list

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

commit b0ff80fdb24326a87a6b1c00215fbb1e5ac2f719
Author: Alexandre Frechette <frechette@chromium.org>
Date: Mon Jan 14 17:53:27 2019

Ensure Language Settings always has one blocked language.

Bug: 872096
Change-Id: Ie8c6c78c8437c7782afe05f8c44ae7b73a0a91ac
Reviewed-on: https://chromium-review.googlesource.com/c/1378244
Commit-Queue: Alexandre Frechette <frechette@chromium.org>
Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622506}
[modify] https://crrev.com/b0ff80fdb24326a87a6b1c00215fbb1e5ac2f719/chrome/browser/resources/settings/languages_page/languages.js
[modify] https://crrev.com/b0ff80fdb24326a87a6b1c00215fbb1e5ac2f719/chrome/browser/resources/settings/languages_page/languages_page.html
[modify] https://crrev.com/b0ff80fdb24326a87a6b1c00215fbb1e5ac2f719/chrome/browser/resources/settings/languages_page/languages_page.js
[modify] https://crrev.com/b0ff80fdb24326a87a6b1c00215fbb1e5ac2f719/chrome/browser/resources/settings/languages_page/languages_types.js
[modify] https://crrev.com/b0ff80fdb24326a87a6b1c00215fbb1e5ac2f719/chrome/test/data/webui/settings/languages_page_tests.js