Voting starts in March for the Drupal Association Board election.
The current entity translation UI was designed to match more or less the user experiece of the core node translation UI. The main difference is that, since here we are not dealing with multiple entities, the actual translation screen is not the original entity edit form, but a stripped down version holding only the translatable bits (translatable field widgets, publishing status, etc.). However, this is true only for translations, AAMOF when editing the original values we get the standard entity edit form.
This approach has a couple of big consequences:
- On the UX side, as already noted by @peximo in the early days of the TF4 core patch, we are totally losing the contextual editing model we have throughout our content editing experience: the edit tab always leads to the edit form populated with the original values, no matter which translation the user is viewing. Aside from that, you get a different form depending on which language you are trying to edit, which may be confusing as hell, if you are allowed to edit any translation and there is no strong difference in your translation workflow between original and translated values.
- On the architectural side, there is no easy way to reuse the widgets other modules add to the edit form, which might hold translatable elements. For instance, the path alias widget is special-cased at the moment, because it's a core translatable element, but menu translation, pathauto support and anything else would need to be explicitly supported to appear on the translation form. This model simply does not scale.
A side-issue being addressed, since we are revamping the translation UI, is how to deal with original values. In the current model, borrowed from the node translation UI, form widgets are prepopulated with the original values when creating a translation. This solution is far from ideal, since once the translation is over we have no clue of what the original values are. If we need to update the translated values because the original ones are changed, we are out of luck.
A solution to both the problems cited above is turning the usual entity edit form into the translation form by making it language aware: this way a user can get the contextual editing, because the edit form is populated with the values actually being viewed, if a translation corresponding to the current content language exists. Moreover the user always gets the same form, unless per-language permissions are in place, in which case only the allowed fields would be present, as usual.
On the architectural side form additions are always in place, they "just" need to support multilingual values, which is not hard to do once the content they relate to is multilingual enabled. We are planning to post a core patch introducing the
entity_language() function, which could be used to retrieve the language of the translation actually being edited.
Since the edit form will hold shared field widgets alongside with translatable field widgets, the risk of performing unintended changes will be extremely high, if we do not design our UX carefully. One suggested possibility is making shared field widgets available only when editing the original values, the other one is finding a way to make always clear to the user that the change being performed will affect all the translations. We can assume we will mainly deal with variants of two translation workflows:
- The simple model is suitable for most small sites: here translations are "normal" content and are handled the same way no matter which language they are assigned. Usually in this scenario there is a single content admin role which has the same permissions on all the translation. Arguably people being assigned this role expect to deal with every translation as a standalone entity.
- The editorial model instead is more likely to be found on sites having an admin staff with different roles. Here content admins would have full powers on content, while translators would enter translations only for a (possibily strict) subset of the entity fields. Moreover translators would be unlikely to create the original content.
In the first scenario, showing the shared field widgets only when editing the original values might end up in a cumbersome and confusing experience, AAMOF we would lose again the contextual editing capability, since a shared value would be viewable but not editable when dealing with translations. Moreover a missing field in our forms usually means that the user has no permission to edit the value, while in this case it would just mean that the translation being viewed is the "wrong one". OTOH it might be really hard to find a solution letting users safely deal with shared field widgets.
Which is the best solution here is yet to be decided.
- Decide how to deal with shared field widgets.
- Decide how to deal with original values.
User interface changes
No relevant API changes foreseen at the moment.
I had a long UX discussion with @Gabor and @webchick about the current translation UI: we agreed that users should not see a different form depending on whether they are editing the original field values or the translated ones.
The solution we came up with is providing a localized version of the entity edit form and somehow highlighting the untranslatable fields to outline that changing their value will affect all entity translations.