Administration pages language setting makes it impossible to edit content translations for some roles

Did you encounter this with core only? I don't believe there is any language based redirects in core to begin with.

All right, so you are not redirected (note the URLs before clicking on them), but you get different URLs generated.

This seems to affect users who have access to edit entities. Users who can only translate can still access the translation links output on the entity translations overview page.

By design, it appears, ContentTranslationManageAccessCheck blocks editors access to the entity.$entity_type_id.content_translation_edit route:

 // Editors have no access to the translation operations, as entity
 // access already grants them an equal or greater access level.
 $templates = ['update' => 'edit-form', 'delete' => 'delete-form'];
 if ($entity->access($operation) && $entity_type->hasLinkTemplate($templates[$operation])) {
   return AccessResult::forbidden()->cachePerPermissions();
 }

And the overview controller always provides editors with links to the entity edit page:

  if ($update_access->isAllowed() && $entity_type->hasLinkTemplate('edit-form')) {
    $links['edit']['url'] = $entity->urlInfo('edit-form');
    $links['edit']['language'] = $language;
  }
  elseif (!$is_original && $translation_access->isAllowed()) {
    $links['edit']['url'] = $edit_url;
  }

But the entity.$entity_type_id.edit_form route always loads the translation of the currently negotiated language.

Allowing editors to edit translations in the admin interface language of their choice seems like a pretty big use case. When we build multi-lingual sites for clients the person creating nodes and adding translations frequently is just copying pasting and is not actually a speaker of the languages of the content they are entering.

Would it make sense to add the translation language as an additional parameter to the entity edit route? Just like in D7 entity_translation we can edit a German translation within the English interface at /en/node/1/edit/de.

Also, if we decide to make it, I would not change the language in the URL. I mean that it would be nice that translation links at the /en/node/1/translations page lead to /en/node/1/edit/en and /en/node/1/edit/de, so no language interface switching happens.

If we implement the above, both "Account administration pages" language detection method and "Administration pages language" setting are useless and can be removed.

+1 for #7 to add (back) a language suffix to the entity edit route and restore the D7 admin interface negotiation pattern. Seems like the simplest fix.

Working on a patch.

Here is a patch.

1. It clones entity edit form route, adding the language parameter
2. It uses hook_entity_prepare_form() to set the entity translation (fetching language from the current route match)

I'd love to hear if there are better ways to implement this.

From my #7:

If we implement the above, both "Account administration pages" language detection method and "Administration pages language" setting are useless and can be removed.

Actually there are many ways to get to an admin page in a non preferred language. So the mentioned features are still useful.

Updated links on the entity overview page. Test fails are expected.

The only issue I see for now, tabs are gone on the edit form.

Changed the whole thing a bit. Here is what the patch does:
- adds optional content_translation_language parameter to the edit route
- uses hook_entity_prepare_form() to set a desired entity translation on the form
- uses hook_entity_operation_alter() to add translation language to the edit link

Fixed URL in test.

Green light!

Is this in some ways related to #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content?

After some usage of #16 on a dev project, we found several issues with the patch. (I can provide some feedback if anyone is interested)

Now I think that we need to fix #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content first and then try to solve the issue with the language detection configuration.
Here is a screenshot of the configuration that should solve the issue:

@Gábor Hojtsy, thanks for mentioning that issue!

Yeah #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content needs tests, it would be really helpful to help with those :)

I manually tested #2189267-24: When content language detection is different from interface language detection, the detected language is not applied to the rendered content with the #20 language detection configuration.
I was able to create/edit content translations. So I think we can close this issue.

I found one small additional issue and reported it to #2715887: Can't use translated field default values when "Administration pages language" setting is set