Cloning a node with existing translations, clones all translations of the node

With the patch in #13 some properties are cloned that shouldn't be cloned, such as the path property. This is not the case in how the module originally works. Finetuned the patch a little bit - the outcome is now more close to the original logic.

Agreed with #11 let's make this a feature request to provide the flexibility during the cloning process while maintaining the original behavior as default. If a dev updates the module without knowing that a major change is happening in the module, it's going to cause some mass confusion to a lot of those who already rely on the feature to clone all translations along with the parent node.

Can confirm as of Jan 2024 in Drupal 10 that the Patch #14 works perfectly. Thank you so much!

Please re-roll this change in a merge request so that GitLabCI tests will run against it. Thank you!

This issue has been fixed with this patch.

Patches are not working with dev version or version 1.18.0

Re-roll patch #18, so it can be comaptible with version 1.18.0

Rerolled #14 to work with latest version.
I saw a lot of added changes to the patches in #18 and #20. Not sure if these are needed and they where not applying.

Made a mistake in #21, updated.

My issue is that when the translations are also cloned, they keep the owner and date. This can prevent an editor from removing unwanted translations.

Also, if the editor doesn't have access to edit or delete content in specific languages, this can pose a problem, but that's a different issue.

I have attached a patch that makes sure that all cloned translations have the same uid, created, changed, and revision_timestamp as the cloned original language.

Unfortunately, we still have the following problem:

If the cloned translation, e.g. EN, is adjusted in the Layout Builder and you then call up the original translation in the Layout Builder, the text of the cloned translation is displayed in the editor (see image → ).

This only happens in the translation. This error does not occur in the original language.

Does anyone have an idea what could be causing this? It would be great if we could solve the problem.

Thank you for opening and working on this issue.
I have a use case where translations are automatically generated by TMGMT but as the module clones both the orignal node and its translations, these do not trigger the TMGMT job as it considers the entity as already translated.

Having a global configuration like suggested above seem to be a good way to solve my issue.
Patch #22 is working for me and the code looks harmless for existing projects so it shouldn't need any upgrade path.

I think #24 has a point too but that it's a bit out of scope here. Maybe it should be addressed in another issue.

Re-rolled patch from #14 to work in latest version (8.x-1.18), but also adding same logic to CloneParagraphs() method.
Without this patch, when cloning a node with translations, nested paragraphs from that node will keep the translations, not being able to edit those paragraphs, as Drupal thinks it's editing a translation instead the original node.

Same patch as #27, but now re-rolled to work with latest stable version (8.x-1.18). This one also includes logic in CloneParagraphs() method.