Inconsistent moderation state for translated content

Updated with patch that applies without error.

I found a similar issue but went about fixing it differently by directly ensuring we load the right language for the revision.

Tested #4 manually and confirming that it solves the issue

+1 Tested #4 successfully --> I would suggest a status change to RTBC

+1 Tested #4 successfully

works for me.

I don't believe the current patch works correctly when there is *not* an affected translation. In that event, the UI skips revisions that have no translation.

See similar issue in #2882334: Revisions are not visible for some nodes

I think what we want to do is ensure the proper *translated* revision is loaded, not that it exists or not.

This patch also adds the VID to the output.

BEFORE REVISED PATCH:

AFTER PATCH:

The failing tests here are because the current tests assume that only current language revisions are loaded. However, in my quick tests, that only seems to be a condition if translations actually exist.

What I don't know -- and why I didn't update the tests -- is this:

* If a site is set for multilngual but no translations of a node exist -- what should appear on the translated node revisions tab?

To be clear, I am dealing with a site that defaults to EN but allows ES translations. Without the patch in #9, some revisions are missing for nodes that are not yet translated.

I think the attached approach -- checking against the $current_langcode -- is correct, but can't be sure.

This issue is in fact closely related to #2882334: Revisions are not visible for some nodes, as stated in #9. I created a MR for that issue and added the change from #4 to it, so both issues are fixed with one change.

This issue appears to be related to #3418442: Revisions should be filtered by language in the database query. See patch #5 that correctly checks whether the entity type is translatable and it updates the automated tests.

#11 I think listing all revisions, instead of just the affected ones, is making it hard to tell how many changes there actually were to the translation being viewed. That could be a lot of revisions even with just two languages. Our use case is similar, with mostly Swedish nodes with some English translations here and there, but there can still be a large number of revisions.
I'm also not quite sure this actually fixes the issue, see below.

+++ b/src/Form/RevisionOverviewForm.php
@@ -209,15 +210,23 @@ class RevisionOverviewForm extends FormBase {
+        // If dealing with a translation, load that version.
+        if (($revision->hasTranslation($langcode) && $revision->isRevisionTranslationAffected()) ||
+          $langcode === $current_langcode || !$revision->hasTranslation($current_langcode)
+        ) {

This says it'll load a translation if one exists, but never actually does.

This condition also looks like it will always be true because $langcode is the entity's current language, which is by default the same as $current_language.

I took a slightly different approach and added the query filtering @recrit mentioned, which also meant a few conditions could be removed, and then added a check to figure out which older revision the current revision was based on, if it does not affect the viewed translation.
(I kept the hasTranslation check to be safe, since switching to one that does not exist throws an exception.)

The interdiff was generated without white-space changes to make the indentation changes easier on the eyes.
(Tests not updated yet.)

I tried to be clever in the check for what would correspond to the default revision content and it already bit me, so modifying it and the message to better reflect reality.

Tweaked the wording a bit, also made the interdiff against 11 to be more clear about all the changes since, again without white-space changes and test fixes.

Reroll patch #20 for diff 8.x-1.7

This issue needs an MR (not the 8.x-1.x or 2.x branch as a source please) against the 2.x branch with tests.

Rerolled the #24 patch as a issue fork branch for 8.x-1.x, with some minor improvements (show the revision ID as a translatable text, as well as an utility revision-was-default class to dictate if the highlighted revision was a previous revision, rather than the default current revision.)

Rerolled patch #20 for 2.0.0-beta4

Rerolled patch #20 for 2.0.0-beta4

Contributions must be made via MRs, not patches. And we'll need tests as per the issue tags.

Working on tests.

Converted patch into MR, also added test to verify this,
Please review!!

Tests are failing and there seems to be a lot of unrelated changes in there.

This also seems likely to have overlap or duplicate with these issues that are all postponed on fixing a related issue in core, once the core issue is fixed we will apply the same logic to Diff.

#3227907: Current revision listed only for one translation
#3418442: Revisions should be filtered by language in the database query
#2882334: Revisions are not visible for some nodes

Core issue #2722307: Move translation based conditions into database query on revisions overview page