Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.Problem/Motivation
In our current project there is the desire to be able to choose, when replicating a node, whether we want to replicate all translations or only the default language. The use-case is:
* Editor replicates an existing (translated) node
* Editor modifies replicated node (default language) extensively
* Editor sends the new node (using tmgmt) to external translation system to be translated
* When translations come back, there are conflicts between the original translations and the translated versions of the modified (cloned) node.
I know there are ways to avoid this, namely:
* Instruct editors to delete translations before sending the node to be translated, or:
* Implement our own event subscribers in custom code to remove the translations of the entity object being cloned.
I wanted to see if maintainers would consider this feature appropriate for replicate_ui, in which case I could work on a patch to make the confirmation screen have a checkbox so editors could chose on a per-node basis if they want to replicate all translations or only the default language.
Thanks!
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3215573-6.patch | 12.34 KB | marcoscano |
| #6 | interdiff-5-6.txt | 2.3 KB | marcoscano |
| #5 | 3215573-5.patch | 11.51 KB | marcoscano |
| #2 | 3215573-2.patch | 3.6 KB | marcoscano |
| #2 | copy_all_or_not.png | 271.87 KB | marcoscano |
Issue fork replicate_ui-3215573
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
marcoscanoWould still need tests and 👍 on the approach from the maintainers, but this seems to be a functional attempt.
Screenshot:
Comment #3
quicksketchI found one pretty edge-case bug that none-the-less could be confusing:
This is because the required field stops the submission of the form at the browser level, but the field is hidden, so no message is shown.
Perhaps the fields should be made optional, but verified in a validate handler.
Separately, I wonder if each translation should be given the option to replicate, rather than all-or-one choice in this current approach. In our situation, we really only need to replicate that "source" language, so the current implementation is good for our use-case, but might not be what all users may want. I could see a situation where an editor might want to replicate only the French version, but not the English (source) version, in the event they were making a page that did not have an English version.
Comment #4
berdirSeems useful, and yeah, you can't have fields really-required combined with states, required needs to be state too combined with optional server-side validation.
Comment #5
marcoscanoThanks for the feedback!
Here's a new patch that takes into account the required elements behavior, and also doesn't error out if we start the replication in a translation route (i.e. /fr/node/123/replicate).
(Sorry no interdiff since the previous patch had been done against the tagged release, and this current patch is a re-roll on top of -dev, plus modifications. Not directly comparable)
Regarding:
I'm not sure this issue is the best place for this feature... Unless I'm missing something, adding the ability to replicate only one non-default translation would mean that the submit callback, instead of just calling replicate API as-is, would need to first create a new values array that's the result of merging the non-translatable fields from the original entity with the translated values we want to copy, make the new langcode the default langcode, and then create an entity from that? (in which case at this point we don't even need the replicate API anymore?) I'm probably misunderstanding what this would involve, but I'd vote for a separate issue for discussing only this.
Comment #6
marcoscanoSorry, forgot to add a check in the test for the `/es/node/123/replicate` error I mentioned above. Expanded version attached now.
Comment #7
quicksketchThanks @marcoscano and @Berdir! I didn't realize replicating a translation alone would be so different than replicating the source node. As such, this approach seems like the best way forward for this feature.
The validation code in this patch gets a little hard to follow. Clearing the entire form's validation state and then re-adding individually seems convoluted. Perhaps either A) just don't make the fields #required in the original form definition and set the required message in the validate handler B) Don't worry about this particular minor problem and remove the specialized validation code entirely and leave as-is.
Comment #8
berdirYeah, agreed, the validation stuff seems a bit complicated for what it brings. The label field is prefilled, someone would need to go through the trouble of removing the content and then not duplicate the translations. I'm fine with just removing that and the test coverage for it.
We've been using this for a while and it works quote well, there's a confusing issue with paragraphs though, their translations don't get deleted when deleting a translation. So when you then re-add a translation. But I think that's an issue with ERR/paragraphs and happens when manually removing a translation as well.
Comment #9
berdir#3249609: Replicate in a different user interface language from the original language of the Entity will cause error on a multilingual site is also related and does the untranslated change always, which probably makes sense?
Comment #10
ghost of drupal pastWe went the opposite direction with this issue: our checkbox says replicate only $default_language and defaults to FALSE. It felt more natural.
Also, if we were to add an event called ReplicateUiOnlyUntranslatedEvent then paragraphs ReplicateFieldSubscriber could catch it and remove the translations from paragraphs.
https://gist.github.com/chx/ec7a6f1ec990016c218d6c0cf5a1372e
Let me know how to proceed: if there's any interest at all I will submit the paragraphs part in the relevant issue queue (and commit the relevant bricks patch too) and I will add the event to the current patch. Further let me know whether there's interest in swapping the direction in the current patch.
Small footnote: there's a bugfix hidden deep in there where broken paragraph references would fatal the replicator, no longer.
Comment #11
berdirForgot about your comment, we did actually run in the paragraphs issue again and created #3485869: When a translated node is duplicated with no translation, the paragraphs are still translated, I don't think a separate event is necessary.
Comment #14
anybodyNice work all! As #3485869: When a translated node is duplicated with no translation, the paragraphs are still translated is fixed now, are there plans to proceed here and finish the UI?
I made a first step and turned the patch from #6 into a MR here.