Account administration pages option break multilingual

I find there is a problem with this as well. My translated pages come up as 404. If I clear the cache, they load fine. It's an annoyance right now as any newly translated page with this option turned on will need the cache cleared to load it.

Same thing happens on Drupal 8.2.4.

Still applicable in 8.3. It basically breaks the ability to edit/show pages in different languages than your admin interface language setting.

The main problem is that the admin language interface negotiator is limited to admin pages.

in user \src\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin.php

 // User preference (only for administrators).
    if ($this->currentUser->hasPermission('access administration pages') && ($preferred_admin_langcode = $this->currentUser->getPreferredAdminLangcode(FALSE)) && $this->isAdminPath($request)) {
      $langcode = $preferred_admin_langcode;
    }

When we remove the && $this->isAdminPath($request) the negotiation works for non-admin pages.
I will provide a patch later after some more tests.

As suggested in https://www.drupal.org/project/drupal/issues/2801397#comment-12168049
in user \src\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin.php

 // User preference (only for administrators).
    if ($this->currentUser->hasPermission('access administration pages') && ($preferred_admin_langcode = $this->currentUser->getPreferredAdminLangcode(FALSE)) && $this->isAdminPath($request)) {
      $langcode = $preferred_admin_langcode;
    }

I can confirm this worked. Tested on Drupal (8.4.5) with administration language negotiation module. Admin language set to Dutch on admin user profile, content negotiation multi-lingual works as aspected (tested with NL/EN translated node).
Though I do not know if this patch is needed when not using administration language negatation module at all.

Bugs should always be filled against the "stable" branch (right now that is already 8.5 because there won't be any new 8.4 releases).

I don't understand the fix, that just makes this work the same as the normal non-admin negotiator, so you could just as well use that, then?

This will also need tests.

The patch isn't working on 8.5.1 version. Can we research this problem more deeply and find some stable and good solution?

I'd say that basically this is a dup of #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content

I agree. I don't understand the patch here, but the problem sounds like it is in fact the one referenced above.

I Have troubles seeing the duplication. Ok it is mentioned somewhere near the end. But the commit/patch do not provide the solution and this patch does.

This patch allows the admin negation on non-admin paths. So the interface objects (admin menu and view/edit/.. links) are in the preferred admin language and can be different for the active content language.

The Interface button's are in English for dutch content page for example.

Downside is that if t() is used in code it will translate in the interface language and not content language.

The usage of the patch seems pretty straightforward here. Or am I missing something?

Is this still a bug now that #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content was fixed?

the bug still exists in 8.7.x and 8.8.x versions

The bug is still present in 8.9.7.

Hi,
I have just installed 9.1.3 and the bug is still here sadly.

From what I found in case is that the processInbound method in AliasPathProcessor fails to find the path from alias due to not knowing what is the current language and always using default.

Bug still here in drupal 9.4.6 and it's very very not pratical!

When we have 3 or more languages like dutch or chinese it's just impossible to manage the website correctly!

But it's an essential fonctionnality for big groups or multinationals companies.

They are (if I'm not mistaken) the target heart of Drupal and this bug exist since many years.

Many clients want to migrate to Wordpress for this reason... It's an ironic situation I think.

I've just come across this issue too on a D10 site with EN and FR language and existing translated content. I noticed an issue editing the translations of menu items. e.g.

EN a link has the title of "EN LINK" and a translation for FR of "FR LINK"

What I did:

1) Go to the language detection and selection screen (admin/config/regional/language/detection) and tick "Account administration pages"
2)Edit your user profile and choose a preferred admin screen language on the "Administration pages language" option

Then to re-create the bug:
1) Edit the FR translation for a menu link to say "MY FR LINK"
2) Instead of the FR title changing instead the EN link now says "MY FR LINK" and the FR title hasn't been touched

This means it's impossible to change the FR translation with this setting enabled and the EN is incorrectly changed

I noticed that when this "Administration pages language" option is enabled and a preferred language selected on your profile a "language" dropdown appears when editing the FR translation. It only has one option of EN, so I suspect is this part of the issue. That dropdown shouldn't be showing or if it has to then it should have all languages as an option and default to the language being translated

patch to version 10.3.1

Indeed, the language-user-admin negotiation seems to force the language to default (EN) on entity pages.
I created a quick test to showcase it (used entity_test but nodes behave the same). The issue appears as long as ::isAdminPath gets called (so we need proper permissions and preferred_admin_langcode set).

There seem to be some kind of circular dependency issue: initial interface detection triggers language-user-admin that calls isAdminPath which calls route enhancers (EntityConverter::convert, EntityRepository::getCanonical), which calls content detection which calls back interface detection which has a fallback already set to default language (in \Drupal\language\ConfigurableLanguageManager::getCurrentLanguage).

---

Edit:
I have a project that doesn't seem affected so I compared /admin/config/regional/language/detection
That site uses:
- Interface text language detection: Account administration pages, URL, Selected language
- Content language detection: URL, Selected language -> note: "Interface" is disabled so this avoids the circular dependency

In other words: one workaround is to enable "Customize Content language detection" checkbox, and below uncheck "Interface" and check "URL". Quite confusing...
PS: It seems demo_umami uses the same trick.

Tests added in #35