Problem/Motivation

In #2484037: Make Views bulk operations entity translation aware @webchick reported (after setting up an English site and adding French too):

Config entity lists:

Content entity lists:

Proposed resolution

1. On config entity lists, keep the current admin language as-is. This is resolved by adding ['language' => NULL] to URL options when creating operations for config entities. Those will keep the language.
2. On content entity lists (which are views based), update the entity operations field to consider the language of the views row found, generate links using that language.

Remaining tasks

Discuss how to improve content operation languages to also enable to keep the interface language by linking to specific edit URLs.

User interface changes

1. Config entity lists should link all operations to pages in the same language as the page is viewed in.
2. Content entity lists should link operations to the language relevant for the row displayed at least (ideally keeping the interface language and linking to specific operation pages for the language).

API changes

EntityOperation field in views gets a new LanguageManager constructor argument.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Title: Views may jump out of a foreign language to site default with links » Operations links jump out of current language back to site default
Issue summary: View changes
FileSize
273.78 KB
Gábor Hojtsy’s picture

Issue summary: View changes
tim.plunkett’s picture

Can you confirm if this is also true for other dropbuttons like those on the content types page?

Wim Leers’s picture

Sounds like a missing cache context?

Gábor Hojtsy’s picture

@tim.plunkett: yeah I had this earlier in the issue summary: This is true to menus, users, etc. so not unique to views or config entity listings either.. I verified with those pages. SO looks like independent of what is doing the listing.

Wim Leers’s picture

Then it sounds like the operations links don't point to the right translation.

Debugging hints:

  • putting a breakpoint on the first line of \Drupal\Core\Render\Element\Dropbutton::preRenderDropbutton()
  • evaluating the following expression: $element['#links']['edit']['url']->toUriString() — it should point to a route beginning with the content_translation.translation_edit_ prefix, but it's probably pointing to the original entity edit/delete/… links.
Gábor Hojtsy’s picture

Well, they don't need to be a content_translation route, the bug affects config entity listings just as well. I don't think the route needs to be different for the language to be different :) Eg. if I go to hu/admin/structure/menu, all the operations link out of /hu to / but the Add menu, breadcrumbs, etc. are correctly pointing to /hu links.

On /hu/admin/structure/menu the dropbutton Uri debug for the first menu is:

toUriString(): route:entity.menu.edit_form;menu=admin

getOptions(): array ( 'entity_type' => 'menu', 'entity' => Drupal\system\Entity\Menu::__set_state(array( 'id' => 'admin', 'label' => 'Administration', 'description' => 'Contains links to administrative tasks.', 'locked' => true, 'originalId' => 'admin', 'pluginConfigKey' => NULL, 'status' => true, 'uuid' => '8f054fa2-9987-4eef-a000-d0f4d44c420a', 'isSyncing' => false, 'isUninstalling' => false, 'langcode' => 'en', 'third_party_settings' => array ( ), 'trustedData' => false, 'entityTypeId' => 'menu', 'enforceIsNew' => NULL, 'typedData' => NULL, '_serviceIds' => array ( ), 'dependencies' => array ( ), )), 'language' => Drupal\Core\Language\Language::__set_state(array( 'name' => 'English', 'id' => 'en', 'direction' => 'ltr', 'weight' => 0, 'locked' => false, )), )

So looks like an explicit English is set in the route options.

Gábor Hojtsy’s picture

It is also not a general dropbutton problem. Dropbuttons on hu/admin/config/regional/config-translation work very well, dropbuttons on hu/admin/config/regional/config-translation/view fall back on English again. Looks like it depends on whether its based on entity links.

As per Entity::urlInfo():

    // Display links by default based on the current language.
    if ($rel !== 'collection') {
      $options += ['language' => $this->language()];
    }

So entity links will have an explicit language set :/

Wim Leers’s picture

Great investigative work!

Gábor Hojtsy’s picture

Priority: Normal » Major

Not sure at this point though how to fix this and its a major at least because we are supposed to let people edit a Chinese block on an English UI, but there is no way to get there from the English list if the block was Chinese...

Gábor Hojtsy’s picture

Title: Operations links jump out of current language back to site default » Entity operations links tied to original entity language, ignore UI language
Issue summary: View changes
FileSize
337.97 KB

Here is an inverse example with installing in Hungarian and adding English as second language. This time with menus :)

Gábor Hojtsy’s picture

Different symptom of this same bug:

Wim Leers’s picture

Gábor Hojtsy’s picture

Status: Active » Needs review
Issue tags: +sprint
FileSize
3.37 KB

Here is a partial patch that at least matches expectations for a few of the config entity listings. Did not "fix" all config entity default operations, but eg. menus fully work as expected with this. The destination of the edit form submissions is still not good (it breaks out of interface language again), but this gives an idea of the extent of changes needed :/ Hopefully we can do it more elegantly...

Gábor Hojtsy’s picture

FileSize
13.21 KB
9.84 KB

Adding the remaining config entity controller fixes.

And finally the views operations fix for loading the entity in the right language (similar to the BulkForm plugin). It looks like this is not invoked every time, but is cached indeed :/

Wim Leers’s picture

Gábor Hojtsy’s picture

FileSize
1.3 KB
13.73 KB

Well, not sure. It is cached for further page loads, but not within the page. All rows get invoked properly one by one. I forgot to add the query ensurace / langcode alias setting method (again same as BulkForm field), so now it starts to work much closer to what someone would expect.

Gábor Hojtsy’s picture

Issue tags: +VDC

Now for content entities I think the question is whether we should swap to the specific content entity edit path and keep the UI language or break out of the UI language for the respective content translation language (the later is what the patch does now).

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

Title: Entity operations links tied to original entity language, ignore UI language » Entity operations links tied to original entity language, ignore both views row and UI languages

The last submitted patch, 14: 2504663-14.patch, failed testing.

The last submitted patch, 15: 2504663-15.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 17: 2504663-17.patch, failed testing.

Gábor Hojtsy queued 14: 2504663-14.patch for re-testing.

Gábor Hojtsy queued 15: 2504663-15.patch for re-testing.

Status: Needs work » Needs review

Gábor Hojtsy queued 17: 2504663-17.patch for re-testing.

The last submitted patch, 15: 2504663-15.patch, failed testing.

The last submitted patch, 14: 2504663-14.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 17: 2504663-17.patch, failed testing.

amateescu’s picture

Gábor Hojtsy’s picture

@amateescu: looks like it, yeah, I'll merge my changes there :)

Gábor Hojtsy’s picture

Status: Needs work » Closed (duplicate)
Issue tags: -sprint

Intgrated everything there in comment #39 and #40. Let's keep moving there then.

jhodgdon’s picture

Status: Closed (duplicate) » Needs work

Ummmmm... Which issue is this a duplicate of? The reference in comment #32 is to this issue itself. And the only at that time open related issue is #2473873: Views entity operations lack cacheability support, resulting in incorrect dropbuttons, which is about cacheability, and has no mention of things here being merged in. Opening this back up until this is clarified.

Gábor Hojtsy’s picture

Status: Needs work » Closed (duplicate)

@jhodgdon: the titles are similar, but the issue in #31 (not #32) is different.

jhodgdon’s picture

Titles and issue node IDs are both similar, ha! Updating meta... thanks!

_renify_’s picture

FileSize
148.3 KB

Still has bug on User entity
bug