I've found a problem translating contents into another language in a particular scenario. Those are the steps to reproduce the problem (tested on simplytest.me):
1.- New Drupal 8.2.5 installation in Spanish with the standard profile.
2.- Enable Content Translation module.
3.- Set a content type to be translatable, for example, the page content type.
4.- Add the English language.
5.- Go to language detection and selection settings (admin/config/regional/language/detection) and enable "Account administration pages", "URL" and "Browser" detection methods, with that exact order.

6.- Go to admin account settings (user/1/edit) and set "Administration pages language" to Spanish.
With that configuration, if you create a new page node in Spanish, then, when you go to translation page for that node and adds an English translation, a locale combo appears in translation edit, in which the only possible value is Spanish. If you save the translation it seems that it creates a redundant translation into Spanish. If you navigate to /en/node/1 it appears in Spanish. Neither you can't edit the English translation.
If you still have an existing translation, it results in data loss for the translated content.
As a temporary solution, I've solved the problem configuring the "URL" detection method above "Account administration pages" detection method, but the administration pages language setting, obviously, has no effect.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | Screenshot 2018-08-20 15.15.28.png | 196.52 KB | iztok |
| #11 | 2843439-11.patch | 1.54 KB | valthebald |
| Captura de pantalla 2017-01-13 a las 21.28.30.png | 71.6 KB | skuark |
Comments
Comment #2
skuark commentedComment #3
skuark commentedComment #4
cilefen commentedComment #5
j-leeI could reproduce this issue at 8.3.7 too.
Comment #6
j-lee8.4 is affected as well.
Comment #7
j-leeMaybe related to #2802403: Combination of language negotiation and path aliasing can cause a corrupted route cache, 404s
Comment #9
j-leeThe problem persists with Drupal 8.5
Comment #10
j-leeComment #11
valthebaldConfigurableLanguageManager uses single flag to check if language is initializing, while there are several language types, initialized in different ways.
Suggested solution: use array of flags instead of a single one
Comment #12
valthebaldChanging to "Needs review" just to see if the patch breaks anything
Comment #13
josebarbosa commentedSame problem here. Any advance on this?
My client needs to insert content in Mandarin and it's almost impossible to manage the backend if the account administration pages option isn't enabled.
Comment #14
valthebald@josebarbosa: the patch from #11 works for me
Comment #15
josebarbosa commentedOk, thanks @valthebald. I'll give it a try.
Comment #17
iztok commentedI had an issue when setting "Interface text language detection" and "Content language detection" seperately.

When opening a node translation (on a URL reserved for a specific language) it opened the original English content.
The #11 patch resolved this issue for now.
Comment #18
huzookaPossibly a dup of #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content
Comment #19
laravz commentedI believe it is, or at the very least the patches do very similar things (except the specifics of the checks and the manner in which initializing[$type] is unset). However, issue 2189267 is older and seems to have tests. So maybe it would be best to compare the patches for the best solution and set this one to Closed(duplicate)?
Comment #22
mirom commentedThe patch from #2189267 is basically the same, closing as duplicate