Problem/Motivation
Right now, using the createRevision() API to prepare a new revision uses the untranslatable fields of the current default revision. This does not make a big difference currently when just using regular untranslatable fields as they are not visible on the edit form. They are however visible when looking at the saved translation draft.
Example:
Content type 'Article' has an untranslatable image field and a translatable body text field. There is an existing published version in EN and a translation in DE. Then, the user creates an EN draft with a new image and a different text. Then, he also edits the DE translation and creates a new draft, updating the text also accordingly (lets say it describes the untranslatable image). In Edit, the image is hidden, but when then saving that draft, it still shows the old image.
This becomes a bigger problem with e.g. paragraphs, but then you can for example add completely new paragraphs with new translatable fields, which are then impossible to translate until you publish the EN draft. This goes against user expectations/requirements.
Proposed resolution
Basically, the proposal is to change createRevision() and specifically use the draft versions of the untranslatable fields, However, what happens if you try to then publish the DE translation draft before the EN draft? I can imagine at least 3 variants:
1. We just publish the translatable fields. This would be the default behavior, but it's really problematic for paragraphs as you would then basically just drop translations you might have created for new paragraphs.
2. We disallow that with a validation constraint
3. We publish it including untranslatable fields. Don't quite see how that would work as it basically goes completely against the current behavior.
Maybe a combination, core would continue to do 1, but in paragraphs, we add our own validation that prevents publishing a DE draft if it is based on the EN draft with a different structure.