Draft translations should be based on the latest revision of the source language, not the published version

Seems to be little movement on this issue; despite its importance.

Some progress on my end. Before Xmas i had come up with a new version of this patch as well as a new version of the Paragraphs patch; which seemed to work well. Due to holidays and other commitments, our QA team has only recently gotten around to testing this and although they think the forward path (create draft, translate, publish, new draft, new translations, publish, etc) now works well, they noticed that reverting to old revisions is broken. I have tweaked my patch a little to possibly fix this and they will do further testing this week. If it goes well, i'll post the patches.

Yesterday, someone on Drupal's #multilingual slack channel suggested they have a working solution for translation/moderation/paragraphs but using Workbench Moderation. I did a quick test, and sure enough, this does work with WBM. :) The issue is, that module supposedly has been migrated into core as Content Moderation - but apparently has gotten broken at some point along the way.

I posted this: 🌱 Life expectancy of this module? Active

@liquidcms, any luck with your patches? I'd like to try them as I'm having similar issues with content moderation + multilingual + paragraphs (or ERR) + IEF.

• Create and publish EN and SP version of content that has a Paragraph field using IEF widget, but don't populate the Paragraph field
• Create a draft of EN version and enter content for the Paragraph
• As, expected, the published EN and SP version does not show the Paragraph, and the Latest revision of the source (EN) translation shows the Paragraph
• Edit the SP version and woops, the Paragraph does not show up and there's no way to add it.
• Publish the EN version. Now you can edit the Paragraph in the SP version

This gets worse when using an ERR field that is not a Paragraph. In this case, the ERR field does not show up in the SP translation even when the Latest revision is published. Of course, this is a separate issue.

I have an ugly patch to core which is targeting the same method the patches here are attempting to fix: the createRevision method of cores ContentEntityStorageBase class. As well as a modified version of this patch #3004099: Allow to translate paragraphs from pending revisions →

We pushed it live just last week; but as always.. some new test case discovered which fails.

After months of trying to come up with a solution (without really understanding Drupal's moderation system's inner workings), I may give Moderation Workbench a go (the D7 version of Content Moderation); which, at first glance, does seem to work.

Hi @liquidcms, any luck with your patches to core along with the Content moderation module ?
Facing the same issue and scenario mentioned by you.

Also tried the patched provided in on #32 and #16 but they are not working. Also this this link : https://www.drupal.org/project/paragraphs/issues/3004099 → but no luck.

When node for both de and fr languages for eg are in published state where de is default language, and then de is set to draft with a newly added paragraph it does not appear for translation in the fr version.

fr version of node still points to the published version and no revision for this is created.

Tried forcefully adding a revision for the same via hook_update but while changing the content moderation state from published to draft the site crashes with Deadlock condition.

We are on my RC6 of piecing something together for this. We have had 2 earlier versions that our editorial team has tried but eventually came back with a new test case which failed. The new version has only been live for a couple days but each release has more test cases it has gone through so hopefully this is the last one.. as this really is a nightmare.

I suspect the bottom line is that the architecture of paragraphs simply does not support this as it is now.

I'll post the 2 patches (core/paragraphs) we are currently using and perhaps you can try them out to see if they work for you. They are not language agnostic at the moment so you may need to modify for your specific case. I should redo to use "default language" where appropriate instead of hard coding in the language we use.

There are still some "editorial caveats" required for this which our editorial team has suggested are fine - and that i will eventually add some validators to ensure are forced (we use EN/FR):
- if a new EN draft is created which adds/removes paragraphs, and a FR draft is also created, the EN must be published first.
- when, in situation described, the EN is published, the FR (previous live version) will appear incorrect - in this case i would publish both at the same time.

There is also the possibly obvious trait of paragraphs that needs to be kept in mind: the translation needs its source (this is likely the primary failing with paragraphs that makes this such a mess). So if you remove the source you can't expect the translation to maintain its translated paragraph. In other words paragraphs between languages need to line up. For our application that is always the case; so not an issue.

Hi,
I am facing the same problem, for paragraph translation in content moderation, using drupal 9.5.7
Translation of paragraph content is not rendering latest change done in default language. I need to re-publish the translated content then its rendering properly.

@liquidcms, are you by chance using the "conflict" module? There's a critical bug in the "conflict" module 🐛 Original language entity content got overwritten when updating translated entity for multilingual site RTBC I suggest uninstalling the "conflict" module or patching it. Not sure if this is related but it very well might be.

@joeseph - never heard of it. But as documented in a few places now; my issue, and others', stem from core issues with how core handles moderation and translation and then complicated with paragraphs. Would be nice if this was all just due to some rogue module messing things up. Sadly not.

Re-rolled the rc1 patch so it's compatible with 9.5.11

First off, thanks for this patch/patches. Just wanted to give a heads up to anyone else who may come across similar, I was noticing that using this patch with a couple of content types on a client site that it would block translations from being edited. For some reason, the 'changed' and 'created' fields were not translatable on this particular content type, and thus new translations would receive these values from the parent = form submissions being blocked on edit (Outdated form).

Removing the patch and the issue goes away, setting these fields to be translatable (with the patch) and the issue is resolved.

@aaron.ferris yes if you have content_translation enabled and you mark the changed field as untranslatable on content entities then you can run into the scenario where it becomes impossible to ever edit the entity again without repairing the database. I opened this related issue a while back https://www.drupal.org/project/drupal/issues/3170926 → . It's a sticky problem but basically with how things are currently implemented in core, I think it should be at least posting warnings somewhere that changed should never, ever be flagged as untranslatable because at some point you will become unable to edit your content (obviously a massive issue for a CMS) due to EntityChangedConstraint.

Yes indeed, thanks for linking that issue @lpeabody.