Problem/Motivation
The D8 content translation model allows to create per-language variants of a single entity, as opposed to the D7 model that groupes separate entities (nodes) with different languages in translation sets.
When we come to revision support, the D8 approach is less flexible than the D7 one, as it can support only per-revision translations, while the D7 approach allows to have independent revisions for each translation.
Currently revision handling with multilingual entities is not working properly, both on the functional side and on the UI side, mainly because of the inability to deal with revisions independently for each translation.
Proposed resolution
Emulate per-language revisions at UI level by tracking which translations were affected for each revision, which allows to implement per-language revision listing, reverting, and comparing.
Remaining tasks
We identified the following issues:
- Track affected revision translations by storing per-language modification timestamps:
#2428795: Translatable entity 'changed' timestamps are not working at all - When reverting a revision process only affected translations:
#2453153: Node revisions cannot be reverted per translation - Improve the node revision UI to support per-language revision handling:
#2465907: Node revision UI reverts multiple languages when only one language should be reverted - Improve concurrent editing:
#2465909: Implement per-language locking at entity form level - Improve (revision) write performance:
#2297817: Do not attempt field storage write when field content did not change - Translatable entity 'created' and 'uid' fields not initialized properly during content translation 'Add':
#2472621: Translatable entity 'created' and 'uid' fields not initialized properly during content translation 'Add' - Make the node entity's revision_log untranslatable:
#2480921: Make the node entity's revision_log untranslatable
#2506213: Update content entity changed timestamp on UI save
User interface changes
TBD
API changes
None foreseen at the moment, just additions.
Comments
Comment #1
plachComment #2
plachComment #3
miro_dietikerPossibly postpone the following issue?
#607396: Killer feature: Fieldable Fields in core
Comment #4
plachI'm not sure I see how they are related, could you expand on that?
Comment #5
plachComment #6
miro_dietikerSome more details about the reference #607396: Killer feature: Fieldable Fields in core
There are many projects like field_collection or paragraphs. They are introducing one new thing that is previously not seen in Drupal core UIs: A composite relationship with editability in one single form. None of these solutions completed both complexity dimensions revision and translation in its implementations, because it is a nontrivial task. All the implementation i've seen partially break revision or translation support.
Similarly, we should postpone the following issue until we have a working implementation for all the minimal revision + translation processes:
#1776796: Provide a better UX for creating, editing & managing draft revisions.
All decisions here (and in the sub issues) will affect how a proper solution in the two domains referred should be designed.
Comment #7
plachOh, ok, you were proposing to postpone the other issue, not this one. Sorry for the confusion :)
Comment #8
plachComment #9
plachComment #10
hchonov#2428795: 'created' and 'changed' timestamps not correctly updated is now taking care only of the changed timestamps.
I created a new issue for the created timestamps with provided patch: #2472621: Translatable entity 'created' and 'uid' fields not initialized properly during content translation 'Add'
Comment #11
hchonovComment #12
plachComment #13
matsbla CreditAttribution: matsbla commentedI'm adding a new issue to make it able to save translations per language
Comment #14
plachRemoved the issue, as it was closed. See #2562759-2: Nodes revision cannot be saved per translation for details.
Comment #15
plachSaving to see colors
Comment #16
plachAnd again :)
Comment #17
plachComment #18
matsbla CreditAttribution: matsbla commentedOne question:
Would it not make sense to see changes of statuses for the different translations in the revision log? Like if the translation is marked as outdated, or if the translation change their published/unpublished status.
Comment #19
Gábor HojtsyRemoving from sprint so it reflects what is currently being worked on.
Comment #21
moshe weitzman CreditAttribution: moshe weitzman at Acquia commentedbased on the little work remaining here (hurray!), I'm downgrading. Feel free to change it back if I am mistaken.
Comment #22
xjm#2465909: Implement per-language locking at entity form level is the only remaining child issue, so maybe this one can be marked closed?
Comment #23
plachAgreed