Currently when editing an entity translation, entity form 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).
- Define a new non-configurable language type for the content translation form language.
- Negotiate its value via a new detection method, using query string parameters, e.g.
hook_entity_prepare_form()to set the entity form language based on the negotiated value. Use the current content language just as a fallback, if no query parameter is specified.
Post a patch to implement Do reviews, update or write tests, evaluate if documentation or a change notice is needed.
User interface changes
When editing an entity through its regular entity form, URLs like
http://example.org/node/1/edit have now a query string parameter:
The access-control issue originally reported here has been solved in.
Beta phase evaluation
|Issue category||Task because there is no specific functionality broken, however this blocks 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.|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,138 pass(es).
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,134 pass(es).
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,072 pass(es).