Entity forms will let users edit different language variants of the same piece of data. Actually only one language variant will be editable at any time so we need a reliable way to know which is the form "active" language. Simply relying on the current content language does not always work as it sometimes makes pretty unconfortable the editing workflow, since the user may want to keep her current language and edit different language variants. Hence we need to be able to explicitly set the active form language through a parameter.

As discussed with plach we think it makes more sense to have general language type instead of this one. E.g. language_content_edit or something like that, and then use this as default. Let's do so then.

However Jose is not convinced that this approach can work for multiple realms, so I think we need to find an alternative not involving a new langauge type. Probably just relying on the content language as a default and relying on Request parameters otherwise.

Comment and code doesn't do the same? It uses content language and applies language fallbacks. We should do a final fallback to default entity language though if none of the fallback-languages is in the entity, or?

I'm not sure I fully understand why this is necessary (issue summary is a bit sparse), but all of you seem to agree that it is a good idea. I hope you guys asked each other some criticizing questions in the discussions ;)

The code in EntityFormController::getFormLangcode() could be improved for monolingual sites and clarified in terms of code logic, but that is pretty minor and can be done in a later follow-up.

@catch: the entity_test module is a pure API test module, it does not have page callbacks or forms at all. I think it would be important at this point to get this moving instead of pushing it back to implement a UI for testing in entity_test module while we already have the necessary stuff to test elsewhere, such as in node module.