I have seen this in the code comments:
If a translation has changes in a certain revision, the translation is considered "affected" by that revision, and will be flagged as such via the "revision_translation_affected" field.
But what does this mean?
This is the confusing issue on my site:
- 2 content types: A and B
- when I go through a common workflow/translation process for each; they end up with very different results on the EN version of the Revisions table.
The workflows setup I have is the same for both and is very simple: Draft and Live (renamed from Publish to not overly confuse the issue with the Published setting of the Status property). Site is set up for 2 languages: EN/FR.
Workflow performed with both A and B.
- create initial Draft revision (rev 1)
- edit and publish by setting state to Live (rev 2)
- translate published rev to FR (rev 3) -- at this point for both A and B, the revisions table appears wrong, but the same for both EN and FR revisions in that all EN and FR revs are shown on both tables.
- publish the FR rev (rev 4) -- this now "fixes" the FR revisions table (same for A and B) in that it now only shows FR revs (3 and 4)
but, and here is the part I don't understand, The EN revisions table for type A continues to be "wrong" and show all the revisions (1-4) - with various other "bugs"as well such as the published FR rev is highlighted and shown as the "current revision" (poorly named as they likely mean live revision); when nothing has changed as far as the live revision.
yet, the revisions table for type B is now showing correct in that it only shows the EN revisions.
Looking at the node_field_revision table I see that the difference between types A and B is that A has revision_translation_affected set to 1 for all the revision rows. Whereas type B has this set to NULL for the rows which seem as though they should not show on the EN revision table (i.e. the FR versions of the EN revs).
I would assume this difference is due to some type of field which exists on A but not B (they are almost identical) or possibly some bundle configuration which I have not yet been able to narrow down. At first I assumed this was a bug as we had only tested with type A and are hard pressed to see the value in the revisions table when the FR items are listed in this table and the Latest revision" is no longer the latest EN revision. But after finding a 2nd content type which appears to work correctly; I tend to think that this is the expected behavior due to some config related to type A (although it seems to make the management of revisions impossible).
SOLVED BUT NOT ANSWERED
It is still unclear as to what this field is for or why this configuration causes it to "break"; but I have determined the setting which is causing the issue:
In the site I mentioned I don't have just types A and B.. I really have about 10 different content types. Of these 10, 6 work and only 2 do not as far as showing the correct revisions in the EN revision table. Of the 8 that work, 6 of them do not have the Comments field added. Two of them do but one has Comments set as Closed and the other has Comments set as translatable (not quite sure what that means as far as the front end but I suspect it means a user could add a comment and could then translate it; but we have no UI for them to do that - so this effectively means nothing). The 2 with Comments, that do not work, have Comments set as not translatable. As an additional test, on one of the 2 broken ones; I enabled translation on Comments, and this fixes the issue with that type.
My guess is this is a bug in Drupal core; but perhaps there is some reason comment translation makes sense to completely mess up the EN revisions table.
This is with Drupal 9.3.16
