Node revisions page might not list a default revision

There is only *one* default revision. So if revisions are enabled by default, this situtation will be the normal case, not the exception, only one translation will be the default revision.

Absolutely. I'm saying it is worse than the issue description currently makes it sound. It sounds like "This might happen", but if you have revisions on by default, it is pretty much guaranteed to happen.

I'm wondering if we need to somehow show why we show the default revision, despite not being affected in the current language?

Apart from that, this is fine with me. But it would be good to get a +1 from Gabor, mkalkbrenner and others that were involved in the refactoring of the revision UI to be filtered by translation.

I think @mkalkbrenner and @hchonov would be the best to ask to take a look. I am not sure I even understand the problem by reading the issue summary twice, sorry.

The idea behind this revision overview filtered by language is that for the user there is no logic shown and for the user the revisions are per language and not per entity.

If we show the current default revision then on the revision overview I would

1. flag the current default revision somehow as the "current default revision" if it has the revisionTranslationAffected flag set
or
2. flag the current default revision somehow as the "current default revision without changes compared to %last_revision_with_translation_changes_for_current_language" or something similar if the revision has the revisionTranslationAffected flag set.

As I've pointed in IRC, should we actually show forward revisions (drafts) on the revision overview page which is meant as a history overview or should we have another "drafts overview"? I personally would like the second one.

Discussed this at the Entity Field API triage meeting with core and Entity API maintainers and we agreed on the current classification as "major".

So I guess both #10 and #14 are hinting at the fact that we should probably add some sort of hint to the UI about why this revision shows up. While thinking about this and trying to come up with wording that normal people can at least somewhat reasonably understand, I was wondering the following: If the default revision did not affect the currently displayed language, the values displayed for the node in that language will be equal to those of the previous revision. So does it make sense to instead add the (Current revision) suffix to the previous revision and not add the current revision at all? If revisions are only created through the UI I'm fairly (though not 100%) certain that simply going back to the previous revision is a correct assumption, but I'm very unsure whether that holds when revisions are created through the API in their various forms.

Re #20. Yes, pretty much. Unless I'm mistaken (which may very well be the case, so I implore everyone to think about this very critically) we should be able to incrementally go back in the list of revisions (by decrementing it one by one) and find the first one where the current translation is marked as affected and display that as "current".

There is also somethin i came across while creating new revisions without any changes but having a revision log message.
The Revisions exist but dont show up in the 'revision' overview.

due to revision_translation_affected being 'null'

there are no other languages involved.

@vierlex, this is an expected behavior, because you haven't actually changed the content of the entity, but only the revision metadata information. However there is no point in altering the revision metadata information without actually making any content changes.

@vierlex, do you by chance know the back history or the issue where that decision was made? It is slightly confusing to not always see current_revision. Example: first time changing the state from draft to published you see current revision, but second time, you are not presented with what the current revision is, if you have a forward revision, etc.

@timmillwood, It seems like there should be more detail also given on this page. Would it make more sense to change the revisions table from a separate controller to a view and allow people to customize the data that is displayed, example: language, state, etc.

Given that

• This affects mono-lingual sites too
• From the content editor's perspective, it looks like there's data loss

I don't quite follow why this is back to "Needs Work".

My suggestion is to commit this patch (if it still applies), and to address any UX improvements to the list of revisions (either for all revisions lists, or just for translated ones) in a separate issue(s).

I'm not sure why this would affect monolingual sites and it is for example needs work because the patch is 4 years old and doesn't apply anymore.

Updating #2 for 9.1.x, interdiff is not required.

This bug is already take care in other issue [#2938947]

Screenshot showing default revision for each language without any patch.

I'm currently developing the etuf module (entity_translation_unified_form) , there's some pretty tricky/strange things going on between some transition states, I'm noticing revisions labeled as 'Publish' that are actually 'draft' revisions, the current revision is still published , I'm hoping this patch might help.

scouring the issue queues for something that might help.
I will continue this battle tomorrow only 4 minutes left on sunday.