In 8.4 it was not possible to create draft revisions of different translations independently. In fact, creating a draft for one translation would suddenly prevent any other draft translation from being created.
This limitation was introduced consciously to cope with a set of a technical issues: Drupal was not able to resolve, load and manipulate the proper revision for each language. This in turn would lead to apparent data loss because draft revisions would conflict with each other and make each other's content inaccessible.
In 8.5 this limitation has been removed and it is possible to leverage the now stable Content Moderation module to moderate content translations independently. However, not every single issue existing in 8.4 was fixed, so a few limitations in the UI are still necessary to avoid the data integrity issues described above. The common goal of these limitations is preventing changes to multiple translations in the same pending revision.
Note that all these limitations apply only when content moderation is enabled for a certain bundle, existing configurations not relying on the Content Moderation module are expected to behave exactly as before.
Non-translatable fields
The easiest way to introduce changes to multiple translations in the same revision, is changing a field configured to be non-translatable, as such a change affects all translations. To avoid that, a new configuration option was introduced to hide widgets for non-translatable fields on translation forms. This mode is enforced when content moderation is enabled for a certain bundle.
A similar issue happens when dealing with translatable fields having non-translatable properties, however in this case the widget cannot be hidden. What happens in this situation is that a validation error is displayed, when trying to change a non-translatable property in a translation form.
Revision translation deletion
Due to how revision translation data is stored, in 8.5 it is impossible to distinguish a situation where a pending revision is introducing a new translation from one where a translation was deleted. To prevent users from bringing the database in this inconsistent state, currently it is only possible to delete translations being part of the current revision.
Flag translations as outdated
This functionality is completely incompatible with how pending revisions are currently handled, as it involves updating all translations in the current revision, so it is not available for moderated content.
A patch to implement this functionality in a pending revision-compatible way is available at #2950626: Allow flagging translations as outdated when content is moderated.
Attachment | Size |
---|---|
8.4-ui.png | 90.76 KB |
utf-settings.png | 105.63 KB |
utf-warning.png | 95.41 KB |
utf-sync.png | 139.88 KB |
rm-translation.png | 114.01 KB |
outdated.png | 41.5 KB |
Comments
How would this work for Paragraph containers?
I'll try to test this soon as soon as I can get 8.5 working but how would this work with Entitiy Reference Revision fields like Paragraphs? The Paragraph container is usually set to be untranslatable but each Paragraph inside it is set to translatable. Would hiding untranslatable fields hide the Paragraphs?
Yep it would. However it's
Yep it would. However it's just matter of altering the form to make the widget come back. I'm planning to discuss this issue with Berdir soon.
8.5 is live now and many
8.5 is live now and many multilingual sites with paragraphs are affected by this. Any news?
Hi team,
Hi team,
I am facing the same issue with Drupal 8.5.8 version. Did anyone solved this problem
A note on paragraphs and non-translatable fields
Make sure to check the "Hide non-translateble fields" checkbox for the paragraph bundles that are used in a revisionable entity.
Else it would result into many errors...
Yes, this solved the issue to
Yes, this solved the issue to me ...
Italo Mairo
www.italomairo.com
itamair@me.com