Currently when being on an content entity route, entity language is set by inspecting the available entity translations and picking the one matching the current content language or falling back to another exisiting one. This approach is not flexible enough as it prevents us from explicitly specifying the target translation language. One relevant consequence is that, if content language negotiation settings are configured in a way that does not allow to switch content language, there is no way to edit a translation not being in the current content language (see).
So there are two major problems:
A: Site configration with domain based language negotiation
Steps to reproduce:
- An authenticated user goes to the translate overview "https://en.example.com/node/1/translations".
- The user decides to view or edit the french translation of the node entity.
- The links for the french translation will look e.g. like this "https://fr.example.com/node/1" or "https://fr.example.com/node/1/edit".
- This is a different domain, where the user is not logged in.
B. Site configuration with url based language negotiation
Steps to reproduce:
- An only english speaking authenticated user goes to the translate overview "https://example.com/en/node/1/translations".
- The user wants to edit the french translation of the node entity and just exchange e.g. a picture in the content.
- The links for the french translation will look e.g. like this "https://example.com/fr/node/1" or "https://example.com/fr/node/1/edit".
- The user clicks on the edit link and now the interface language changes to french and the user is not able to understand the titles of the action buttons.
- Define a language negotiator for the language type "language content".
- It will determine the content language from a query parameter e.g.
- If the new language negotiator is configured with a higher priority than the url language negotiator, then it will look up in the options for the outbound urls if the language option is specified. If so, the query parameter with the language specified by the language option will be appended to the outbound urls. Then the language option will be unset, so that the url language negotiator does not rewrite the url.
- If the query parameter is on a url for a content entity route, then all the outbound urls on this route, which are pointing to a route defined in the entity link templates of the entity on which route we currently are, will inherit it, as long as the urls do not have the language option set. In this case they will also have the query parameter but with the language specified in the url options. Otherwise the urls will remain untouched.
This proposed resolution solves both major problems listed under the section "Problem/Motivation".
Review the current approach and evaluate if documentation or a change notice is needed.
User interface changes
If the new language negotiator is configured with a higher priority than the url negotiator, urls which specifiy the language option will have the query parameter language_content_entity set and pointing to the desired target translation language.
The access-control issue originally reported here has been solved in.
Beta phase evaluation
|Issue category||Bug report, because as at the moment if a site is configured with a different domain for each language, then a link to a specific content entity translation will redirect an authenticated user to a different domain. This blocks also a bug fix:.|
|Issue priority||Major because this unties the translation UI navigation from the current content language, which may be big limitation for sites using domain-based URL language negotiation.|
|Prioritized changes||This is issue is a follow-up of the issue originally adding the Content Translation module to core. Additionally it unblocks a bug fixing issue and opens the door for further UX improvements.|
|Disruption||None foreseen: old URLs will keep working exactly as before.|
Why this should be an RC target
Domain-based language negotiation has been a problem for a long time for Drupal. The multilingual initiative during the Drupal 8 dev cycle helped in making a lot of improvements, but this one problem proved to be a tough one and the issue is already three years old. Finally at the Drupal Con 2015 in Barcelona we agreed after a discussion with @alexpott, @plach, @hchonov and @mkalkbrenner that this is the best solution we can provide. If it made its way into 8.0.0 it would be a great improvement, if not Drupal 8.0.0 would be shipped with an unnecessary and avoidable UX problem.
The change does not introduce any disruptions as it only adds a new feature to Drupal 8 which is disabled by default. Even turning the new feature on does not introduce any disruptions.
Additionally, we are changing the Content Translation route names, which even if it's probably not an API change, it's better to do before 8.0.0.