Switch admin/content from showing one translation per row to one node per row

Steps we need:

• We need a new option on the langcode filter which does a default_langcode === langcode filtering

I don't agree this is a proper solution.

D8MI worked hard for a long time to have multilingual views work correctly with all possible configurations of row language, doing this would mean just ignoring the probem. Anyone installing Drupal 8.0.0 and configuring admin/content to display individual translations instead of original only would incur in the same UX issue causing data loss that was originally reported.

I laid down a viable plan with @amateescu and @dawenher to fix these two:

• #2476563: Entity operations links tied to original entity language, ignore everything else
• #2484037: Make Views bulk operations entity translation aware

I can live with them not being critical, I'll work on them anyway if no else does, but I cannot really support this issue. Assigning to Gabor to have his feedback but I really cannot see this being a viable solution.

I can live with them not being critical, I'll work on them anyway if no else does, but I cannot really support this issue. Assigning to Gabor to have his feedback but I really cannot see this being a viable solution.

While I also don't like that we don't push directly towards a proper solution (and so in total add additional time to the community in exchange for yeah what exactly, I don't know), I think its fine to just fix the criticality of the issue. Majors can still land without any problem, actually maybe people are actually open to more changes than to just fix the bug.

Given that I think the strategy to fix one problem and then revert the change and work on a proper fix is a fine move.

Just realized that in case someone wants to work on this issue, its even more easier to fix:

• Remove the language filter
• Add a filter for the boolean default language flag
• Write a test to ensure this behaviour

Just realized that in case someone wants to work on this issue, its even more easier to fix:

• Remove the language filter
• Add a filter for the boolean default language flag
• Write a test to ensure this behaviour

Yep, that should just work. No problem on the technical side.

I am completely behind the one-row-per-node approach.

While training clients to work with their new Drupal site, I have seen that the content overview is important for their understanding of how Drupal works. The /admin/content view is more than a tool people use. Indirectly it teaches users about the underlying content model. It sets expectations about where your content lives, and how translations work.

In a one-row-per-translation situation, it would be more difficult to explain for instance that you can leave an image field untranslated so the value will be shared across translations.

If users expect translations to work differently than they actually do, I'm worried that some contrib modules may also have a hard(er) time explaining why they do what they do on the entity level, not on the entity translation level.

Tagging this with "Needs usability review" because I would love to know what usability experts think about this.

The simplest thing that could possibly work is to change the admin/node view so that each row is a single node (most likely showing the source translation), not a single translation.

I've been playing around with the views configuration, but this actually was harder than I expected. Maybe I still have to learn a couple of things abount Views in D8, but I couldn't make it output one row per node. Looking at the query, I guess the main reason is that node_field_data (not node as I expected) is the base table for node views. I couldn't even figure out how to add a relationship (join) to the node table. Drupal should be able to do this, right?

I still support fixing View's ability to do bulk operations per-translation, but IMO that should ultimately be represented as a separate tab on admin/content/translations or something. Not here.

I agree. Do we need to actively guide the user into that direction, and make it clear that there are translations to be managed? Or should we at least show the user which translations are available? There is a "Translate" operation in the dropbutton, but it's hidden and it doesn't inform you about the current state of translations.

I don't agree there's a single "right" recipe, that's my point. We see that all the time with multilingual sites, just read the parent issue and you will find at least a couple of different "right solutions" for this screen. The problem I see with this issue is that it's just a way to ignore a set of legit Views configuration, among which the one D8MI has always considered the default one, for good reasons. Release D8 without supporting them and a whole bunch of users will screw their sites in the attempt of recreating them.

Yeah, probably I'm not explaining myself clearly :)

There's nothing inherently wrong in configuring admin/content to display one entry per node, that's what we have in D7 when using Entity Translation, for instance. D8MI decided to go with the other approach as a default for a few reasons. But the point is that it has always been a stated goal to support both configurations (and other too), because they serve different use cases.

So I'm only against the idea that this issue is a solution for the UX issue reported in the parent issue: it just means hiding it, unless we fix the issues that were formerly marked as critical anyway, because there will surely be people changing the default configuration to get what we have now.

Aside from that, I think that this change should be validated by Gabor, because he originally proposed the configuration we have now.

It is certainly true that we would just fix core listings and everyone else will still have the exact same issues, so we have to solve the other issues, maybe just ignore priorities :)

If creating a translation view with operations will result in data loss, then fixing the operations should be critical either way no? Where else do we allow optional configuration possibilities to expose data loss bugs and not think of that as critical. As per how looking at /admin/content sets up a data model, when people look at frontend views, nodes will appear different in different languages, they will have a different URL per language by default, etc. We can "fix" the admin/content view to list a node only once, but I don't think that fixes the actual critical data loss problem of the operations, so not sure doing a temporary fix to be possibly reverted later buys us any time if the underlying bug is critical anyway?

My understanding is "If you click this, and configure this one option, and do X other thing you get data loss" is major, not critical. "If you click on a primary admin page and click X you get data loss" is critical.

Well, the way how you interpretate it, that is for sure, but IMHO we should care about API usage and what not. You know destroying data is the worst thing you can do, IMHO.

Anyway, here is a simple patch which introduces the filters, but it will show that it will be an effort to remove/change test coverage, so this is a proove that it kills NETTO time, to do this issue.

it will show that it will be an effort to remove/change test coverage, so this is a proove that it kills NETTO time, to do this issue

I'm not sure if I understand what you mean here. Can you elaborate please?

I'm not sure if I understand what you mean here. Can you elaborate please?

I think fixing the critical + the subissues will take more time than just fixing the subissues (because I'm sure we will do that before the release), so we loose time we could be spent on other issues.

Also, can you clarify why we'd want to revert admin/content being for nodes only? One argument for doing this is it's fixing a regression from D7, where that's how this page worked originally.

Drupal 7 shows all translations as individual items in this "view". It is substantial work in Drupal 7 to replace this page with an actual view and undo that by only showing the originals of translations, not all of them. So I would not say that doing the same thing that Drupal 7 did is a regression?

I'm somewhat confused by this issue/topic.

Drupal 8 has a different translation model than Drupal 7. We have to accept and live with that. That means that no matter what we do and change on admin/content, it will *not* be like D7. D7 (with translation.module) showed only nodes *and* all translations at the same time, because translations were different nodes. So, how D7 worked is not relevant, we need to do something so it makes sense in D8.

As others said, I think it is important that content/translations managers understand that difference. For many reasons, the D8 model is different and it is important that all translations are part of the same thing. Examples for that include configurability on fields about being translatable or not, that references to content are to all translations and not a specific one. Yes, you *can* have different aliases for different translations, but it doesn't take a computer science degree to see that the Edit-URL always points to the same ID.

And once #2486177: Deleting an entity translation from the UI deletes the whole entity is fixed, I honestly don't see a data loss bug anywhere. Clicking on delete and then seeing a confirmation form that very explicitly tells you that you will delete all translations is *not* a data loss in by book (Unlike #2468045: When deleting a content type field, users do not realize the related View also is deleted, which automatically deletes something that it didn't tell you upfront. That's way more critical than this IMHO).

As we have I think seen in the discussions on the bulk form/operation links, it is far from clear that delete should automatically only act on a specific translation or not, what should happen with the source language and so on. And as soon as we talk about multiple operations, separate translation overviews and so on, then that sounds a lot like feature requests to me. Also, a translation overview isn't done by just listing all translations but more like something that TMGMT provides IMHO. We can't solve every problem/use case in 8.0/core.

As for the argument that we made the API to reflect D7, sorry, but that's just not true. We never managed to do #2072945: Remove the $langcode parameter in EntityAccessControllerInterface::access() and friends and #2073217: Remove the $langcode parameter from the entity view/render system, so we still have API's that need to pass an entity and a langcode around. It's also different in many other ways. The only thing that is close is that we have the ability to set the current language and pass an object around in the right language.

To summarize, I strongly believe that this was the right decision (showing only the source translation), I made the same suggestion as well.

I mean if actually exposing this feature in default config is critical rather than merely keeping the option that causes it, then its fine to say it should be fixed by not trying to reproduce the D7 behavior for now (ie. introduce a hopefully temporary regression). We can still roll back this issue later once the operations are fixed.

@berdir: we crossposted, my response was still to @webchick in #23.

As for how different the D8 model is from D7 translation, we made it so that that would be up to the site configuration in various ways. By making base fields multilingual, you can practically reproduce the same D7 behavior in Drupal 8 by making all base and configurable fields use different values, so the only common value between translations it the entity ID. So the only difference from Drupal 7 then is where the translation is stored and how its referred to (a usually numeric ID + langcode instead of just a usually numeric ID). That sounds like an internal storage model decision (to support the desired flexibility), which may not necessarily be exposed on the UI. In fact the default Drupal 8 field configuration is ALMOST identical to the Drupal 7 setup in that every base and configurable field is marked translatable by default except the file reference of image fields. So while the Drupal 8 model allows for a sharp departure from how Drupal 7 worked, it is practically configured very closely to how Drupal 7 worked from the point of site builders and content editors who the admin/content view is for AFAIS.

Whether different translations as different items in admin/content makes sense is totally up to the structural design of a site in my mind. We *need* to pick one for the defaults obviously. We can pick the "translations are secondary citizens" concept and make people customize from there if we think that makes more sense (although that would not match well with the default field translatability settings which point to the opposite direction). If translations are secondary, tertiary, etc. then it indeed does not make sense to show them here. If you however consider each language as a subsite, and for example post content originally in different languages as needed (may not even translate some of them), then you would want to use this page to filter down to content in specific languages regardless of originality of translation. Show me content in French does not care for whether that content was originally in French or English or German or if it has any languages other than French. I've seen this model too with high profile clients.

Not sure which model would be 80% honestly, but of course Drupal needs to pick one for the default. I see supporting the current way is not convenient for managing timing of the release, which is a totally good argument if we understand the tradeoffs.

To turn this question around, here are the default operations in the admin/content view:

ALL of these operations may be interpreted per translation. In fact the default Drupal 8 behavior is translations have independent stickiness, promotion and publication status per language. So if this issue is to be fixed as proposed to fix that the understanding of the delete operation is not per language, these operations would not make a lot of sense either on an out of the box multilingual site. What does it mean to publish a node as a whole when their individual translations have independent publication status (as is default)? What does it mean to unpublish it? Should these operations do their changes on all the translations simultaneously? The proposal of how this issue should be fixed suggests so. How is this made clear to the user?

Once again while I see how this suggested simple fix gets us a temporary workaround to avoid a data loss bug exposed in a primary admin UI, I don't think it makes this primary admin UI releasable as-is if we want to claim we support multilingual sites.

@webchick: most of the summary makes sense yup.

As for the first pro point, I don't agree though, because Drupal 8 already works the same way before and after enabling translation modules. Without translation modules (or using the API) you can only get one variant per node, so there will never be a different variant to list. Once that variation is possible to input, this page will work with those variations and let you filter for authors, publication status, etc. regardless of something being an original language vs. translation. A huge benefit of the current view is you can express different possibilities with exposed filters. Ie. people can filter down to original languages if we expose such a filter, etc. and combine that with the bulk operations and other filters. If this would need to be a separate tab, then all the filters and bulk operations would need to be cloned there, so practically one of the exposed filters would be exposed as a tab instead of a form element. That may or may not be desired depending on your use case.

Also if this issue is to be fixed as suggested, we also need to consider the columns author, status and updated (let alone title) which are also per language, so this table would reflect only one variant of the nodes. If there is only one row per node these would only reflect the original language variant of the node. Eg. if you are to filter to content which is not published, you would get content where the original translation is not published even if a translation is published. In other words you cannot use this form to search for and do operations on published content if you cannot access variants which are published. (Everything but the content type may be language dependent.)

#2486177: Deleting an entity translation from the UI deletes the whole entity seem to be informing the user on the confirm screen on what is going on when deleting things, so at least that would be a definite improvement to claim people have been warned. I am fine demoting this to major (or better yet won't fix) in favor of that issue.

@webchick - I'm confused. By marking this as Closed (won't fix), are we saying the "problem" discussed in this issue and in the original #2473989: Views that provide lists of translations with operation links / bulk operations are problematic is actually not a "problem" but a "feature", or are we saying #2473989: Views that provide lists of translations with operation links / bulk operations are problematic is the way forward ?

@cpj: in short what we said is all the columns shown in this table (except 1) and all the operations in this table pertain to translations not a node overall, so for it to make sense as it is now it needs to show translations. That the operations may not actually work on translations yet is a bug but not critical.

Are we in agreement on this?

And once #2486177: Deleting an entity translation from the UI deletes the whole entity, I honestly don't see a data loss bug anywhere.

Because if so, I think we can downgrade this issue, perhaps postpone it on the other "make X respect translations" issues, and continue to hash this out w/ some UX help to decide on the "80% case" as a default and see where we end up.

For the record, I totally agree with this. What I was missing was a critical dealing with the data loss implied by translation deletion. Gabor has abundantly explained why so far D8MI has kept the current approach, but I wouldn't be against this issue in principle, even if it's now closed: I think both what we have in HEAD and the solution proposed here serve valid use cases.

Looks like the problem of views of multilingual entities having duplicate rows is now being looked at over at #2313159: [meta] Make multilingual views work.