Updated: Comment #33
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).
hook_entity_prepare_form() to set the target and source language from there, using query string parameters. Use the current content language just as a fallback.
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.
|FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,885 pass(es), 114 fail(s), and 54 exception(s).|
|FAILED: [[SimpleTest]]: [MySQL] 63,181 pass(es), 6 fail(s), and 0 exception(s).|
|PASSED: [[SimpleTest]]: [MySQL] 63,139 pass(es).|