Allow flagging translations as outdated when content is moderated

+++ b/core/modules/content_translation/src/ContentTranslationHandler.php
@@ -264,6 +264,41 @@ public function retranslate(EntityInterface $entity, $langcode = NULL) {
+      $metadata = $this->manager->getTranslationMetadata($revision_translation);
+      if (!$metadata->isOutdated()) {
+        /** @var \Drupal\Core\Entity\ContentEntityInterface $new_revision */
+        $new_revision = $storage->createRevision($revision->getTranslation($langcode), $revision->wasDefaultRevision());
+        $metadata = $this->manager->getTranslationMetadata($new_revision);
+        $metadata->setOutdated(TRUE);
+        $storage->save($new_revision);
+      }

I feel this section especially is lacking documentation. Why does a new revision need to be created to mark it as outdated?

Just adding that this patch works for us. Having this functionality back would be good to improve the editor experience when working with translations!

Re-roll for 9.2.x, which also includes some refactoring of the test, to stop using deprecated code.

I couldn't apply the patch from #11 on Drupal 9.3.3.
Here is the modified patch.

Added reroll of patch #11.

Looks this this is fixed as part of core in latest core version (10.3.1)

I can confirm @sanket1007
I have tried on Drupal core 10.3.1 and it is working without the addition of the patch.

Unable to test 10.3 right now, but it seems like the outdated option should still be unavailable since the logic hiding it is still there:

https://git.drupalcode.org/project/drupal/-/blob/11.0.4/core/modules/con...

In any case that code should be removed. Also, we should have steps to reproduce.

Additionally, as a commenter noted, "Why does a new revision need to be created to mark it as outdated?" It doesn't. The condition at the end of markRevisionTranslationsOutdated() should use setSyncing(TRUE) to mark the latest revision translation (what the "Status" column references on node/12345/translations) as outdated:

      $revision_id = $storage->getLatestTranslationAffectedRevisionId($entity_id, $langcode);
      if (!$revision_id) {
        continue;
      }

      /** @var \Drupal\Core\Entity\ContentEntityInterface $revision */
      $revision = $storage->loadRevision($revision_id);
      $revision_translation = $revision->getTranslation($langcode);
      $metadata = $this->manager->getTranslationMetadata($revision_translation);
      if (!$metadata->isOutdated()) {
        $metadata->setOutdated(TRUE);
        $revision_translation->setSyncing(TRUE);
        $storage->save($revision_translation);
      }

Rerolling #14 for 10.3.x. Also adding the "setSyncing(TRUE)" described above to setOutdated on the current revision instead of creating a new one.

Thanks for continuing. Patch should be in an MR though vs patch.

Pach #14 doesn't apply on 11.1.5.

I re-rolled the patch locally so it applies, but then I get timeout errors when I save nodes with "translations outdated" enabled.

I would submit a MR, but for some reason I don't have sufficient privileges (I'm working to resolve that now).

Here is a re-rolled patch that works on D11.1.5.

I realize you prefer an MR. I will try to make one tomorrow once I sort out my permissions/account issues.

I resolved the timeout issues (my bad), and this appears to work well.

Update: even though patch 25 works fine in my local, when I deploy it to Pantheon, I still get "The application did not respond in time." when trying to save a node with the "outdated" option enabled.

Patch #22 works well on Drupal 10.3.x. However, I noticed that when a translation is marked using the "Flag other translations as outdated" option, the "This translation needs to be updated" field does not appear when loading the other translations.

To address this, I’ve added a small tweak to Patch #22 to ensure the field is displayed correctly and behaves as expected—just like it does when the content is not moderated.

I’ve attached screenshots showing the behavior after applying the new patch.

I've tried the patch from #27 with the following scenario:

* Node is published in English and French
* Create a new draft in English, tick the "Mark translation as out of date" and save (as draft).

On the translate tab, it shows the French translation as "Published outdated". This seems wrong to me as the published version is not out of date.

Should the published version only be considered out of date once the edit is published?

I used #27 as a basis to create a MR for the 11.x branch per #23. I also saw the issue where a translation wasn't marked as outdated in certain cases that #27 talks about. To reproduce it you need to:

* Create an en node in published.
* Create a fr node in published.
* Create an it node in draft.
* Edit the en node and check "Flag other translations as outdated".
* Edit the fr node, and you will still see: "Flag other translations as outdated".
* Edit the it node, and you will see "This translation needs to be updated".

Interestingly, the status on the translation overview page is already handling this case correctly. The code from #27 is very similar to the code in ContentTranslationController::overview. I made some small optimizations to the existing patch.

Also I updated the test to make sure the above scenario was captured + a few other ones.

A couple of functional tests are failing but they are unrelated to my change.

Will need a green pipeline before moving forward.

MR is almost 1200 commits behind so may need to be rebase

Proposed solution section appears to need to be flushed out.

Rebased and tests are now passing. Also updated the proposed resolution to reflect the changes that are being made.

Since my last changes:

• Added some code to keep the outdated metadata of the last affected revision up to date when saving a translation.
• Added some code to the test to keep track of this. Noticed a weird bug in the test where the storage was returning wrong results for entities. Seems like using $this->container is deprecated so I switched to using \Drupal and everything worked as expected. See https://www.drupal.org/node/3492500

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Re rolled patch Comment#27 for Drupal 11.2.10

Rebased onto the new main branch.

The current PR targets marking a translation as outdated only via the UI but as you can see from the linked issues there is also a need to do this in contrib e.g. TMGMT needs to mark a translation as no longer outdated when an auto translation finishes. There are also MRs open in that module to auto mark content outdated based on information about the node. With the current implementation, the revision metadata would be incorrect if contrib simply called setOutdated.

I think it would be good if core could handle the logic from both markRevisionTranslationsOutdated and updateLastTranslationAffectedRevisionOutdatedStatus in a central place that wasn't tied to the UI. Ideally, just calling the setOutdated method from client code should take care of updating the metadata in revisions via those two methods but client code doesn't need to know about them.

• Updated the MR to make changes I talked about in #42. Revision history is kept in sync in a pre_save hook so client code doesn't need to do anything but called setOutdated.
• Moved the markRevisionTranslationsOutdated inside the public interface retranslate method, so that client code can call that method for revisionable entities as well as non revisionable entities.
• I tried moving everything to the entity builder, but it looks like revisionable entities require being handled in a post save and non revisionable entities need to be handled in the entity builder. So I reverted that and updated the test to catch it breaking if they are moved.

The patch 2950626-outdated-40.patch from comment #40 works for me, new changes since then on the MR results in a Cannot apply patch composer error for Drupal 11.3.2

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Updated the merge request to fix latest main conflicts. Created an 11.3 branch for re-roll of latest main.