Make vocabulary label in administrative listing link to its list of terms

Clarifying issue title.

If we do this, then I think it should be consistent for most Configurables; e.g., also applying to content types on admin/structure/types, and so on.

Also #1891690: Use EntityListController for vocabularies

We also need to decide on field_ui operations and probably delete operation + translate

Currently, the label in each row is not bad in the base EntityListController class. So if we're wanting to make this change consistently across all entity types, it means a lot of classes to change.

I'd suggest fixing #2084255: add label to rows in EntityListController first.

So, this small patch, only addressing the vocabulary label link in administrative listing.

+++ b/core/modules/taxonomy/src/VocabularyListBuilder.php
@@ -68,7 +68,7 @@ public function buildHeader() {
+    $row['label'] = \Drupal::l($entity->label(), $entity->urlInfo('overview-form'));

The docs for l() say:

> This method is a convenience wrapper for the link generator service's generate() method. For detailed documentation, see \Drupal\Core\Routing\LinkGeneratorInterface::generate().

So presumably this could be called on an injected service instead?

+++ b/core/modules/taxonomy/src/VocabularyListBuilder.php
@@ -68,7 +68,7 @@ public function buildHeader() {
+    $row['label'] = \Drupal::l($entity->label(), $entity->urlInfo('overview-form'));

This should use '#type=>link' as \Drupal\node\NodeListBuilder::buildRow() use

Something like that

We can't use *data* because \Drupal\Core\Config\Entity\DraggableListBuilder::buildForm() using label value as string

looks unrelated fail

Any reviews?

Yup, looks good to me.

Hmm, I am not sure about this change. For one thing, we already changed it so that "list terms" is the default operation for the dropbutton (rather than edit) so the original problem statement in the summary is no longer applicable. For another, some users might expect the link to point to the vocab edit page, and others might expect the list terms page.

Nodes, taxonomy terms, etc. link to view the thing in the admin listing, but they are content entities. Vocabularies are configuration entities providing a bundle for a content entity type. The closest analog I can think of for vocabularies is the /admin/structure/types page for administering content types, and that does not link the name of the content type to anything.

The links to nodes and taxonomy terms also do not duplicate any dropbutton operation.

Let's add updated before-and-after screenshots and then get a usability review of the proposed change.

I also might recommend simply postponing this on a better overall design for the vocab pages (see #1340500-28: Merge "list terms" page into "edit vocabulary" page).

Tested the latest patch (1891746-10.patch) getting an error while applying the patch on 8.3.x-dev.
Screenshot attached.

Reroll of the latest patch (1891746-10.patch)

I can review after screens.

Still don't know what to decide according to #15 and #16.
Anyway I tested the patch, and if we pursue that way, this is RTBC.

Hi here,
I've tested the patch and it's RTBC.

Hope to see this in core soon.

I think this is a basic improvement and such a quick fix that will everybody's life easier with Taxonomy in Drupal :)

Let's do the usability review xjm requested in #15. Screenshot is available in #21

Patch #19 failed in 9.2x.Needs reroll

Checking patch core/modules/taxonomy/src/Tests/VocabularyUiTest.php...
error: core/modules/taxonomy/src/Tests/VocabularyUiTest.php: No such file or directory
Checking patch core/modules/taxonomy/src/VocabularyListBuilder.php...
Hunk #1 succeeded at 150 (offset 86 lines).

Rerolled patch #19 .Please check and verify

Including screenshots after applying this patch

Fixed the failed test cases.

#36 patch applied successfully and looks good for me
Thanks for the patch
For ref sharing screenshot ....

Re-rolled for 9.4.