On Drupal 11.4.8 with Admin Toolbar 3.6.3, Views-derived and module-derived dropdown labels remain English in Spanish and Brazilian Portuguese. Content-type and media-type children translate correctly on the same pages.
Views-derived examples include Content, Files, People, Media library and Content blocks. Module-derived examples include Security Review. Available Spanish configuration targets included Bloques de contenido and Archivos, and the interface catalog contained Revisión de seguridad.
Expected: each link follows the interface language. Observed: these children stay English in both cache orders, while translated content/media-type children remain correct. The behavior also occurs with language-prefixed administrative paths, so it is not limited to an unprefixed admin-language preference.
The translation queue was checked before filing. #3019298 and #3026337 cover older entity/config-label handling; #3065781 is a duplicate of that older cache-order problem. #2938890 concerns missing local-task titles. #3004575 has a separate admin-language feature patch whose latest discussion says its draft MR requires related core integration and has failing tests.
This report isolates the remaining deterministic Views/module-label behavior. Discovery-time plain strings and the core menu plugin/config-translation path are investigation candidates, not a confirmed root cause. The older entity-label and admin-language patches have not been treated as proven fixes for this reproduction.
Resolve Views and module labels in the active interface language without capturing the first visitor language in shared discovery caches. Verify both independently warmed language orders, language-prefixed routes and admin-language preference, preserving access filtering. Please link an existing issue if this remaining path is already covered.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 3629740 after, FR.png | 240.36 KB | csakiistvan |
| #10 | 3629740 after, EN.png | 223.53 KB | csakiistvan |
| #10 | 3629740 before.png | 248 KB | csakiistvan |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
wkr1shna commentedComment #6
dydave commentedSuper good catch Jeremy (@jmcerda)! Once again, thanks a lot! 🙏
Nice work Krishna (@wkr1shna)! The MR looks good! 🤩
I'll fix the pipeline issues quickly and give it a review so it could hopefully get merged very soon. 👌
Comment #7
dydave commentedThanks a lot everyone for your great help on this issue, once again! 🙏
OK, I fixed the phpstan and phpunit issues with an extra commit:
https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/221/di...
and all the jobs and tests are back to passing 🟢, therefore moving issue to Needs review for now, as an attempt to get more reviews and testing feedback.
I have challenged the changes in the MR with an AI agent and got a rather positive report: The code is solid and accurately fixes the problem initially reported for the Views extra menu links.
Overall, Jeremy (@jmcerda), the changes in MR !221 should fix cases related with Views.
However, could you please help us clarify a bit what you meant with the following part?
Are you talking about the links in the admin_toolbar_search?
Which module-derived links are you talking about?
Could you please give us more examples?
At this point, I would recommend focusing on fixing the case for the Views menu link items, review/test the merge request, merge it, then create a follow-up issue to fix the rest of the cases.👍
Any additional information that could help us get a better understanding of the "module" related part of the requirements, would be very helpful.
Feel free to let us know if you have any questions or concerns on any of the code changes in the merge request or this comment in general, we would surely be glad to help.
Thanks again very much for your interest for the Admin Toolbar module! 🙏
(Great work Krishna @wkr1shna! Thanks a lot!)
Comment #8
dydave commentedAdding here a piece of the AI prompt for reference:
Related problem in search suggestions (not Views)
The labels in the search suggestions (
SearchLinks.php) do follow the language. The cache is keyed by interface language, and the English and Spanish suggestions were correct. After editing only a Spanish translation, the tray updated correctly, but the Spanish search suggestion kept the old text (ES-n2instead ofES2-n2). An English label edit updated correctly.The cause is that the suggestions are cached with only
config:core.extensionand the list tags (for exampleconfig:node_type_list,config:menu_list). Saving a language override does not invalidate those. It only affects bundles beyondmax_bundle_number, which the search gets from the server, and it lasts until the next invalidation. A likely fix is to add each bundle's and menu's own cache tags ($bundle->getCacheTags(),$menu->getCacheTags()) around lines 155 and 260 ofSearchLinks.php. I have not implemented or tested that fix.Comment #9
csakiistvanComment #10
csakiistvan✅ Tested and works — added a French label override ("Contenu FR-TEST") to the Content view and confirmed the Structure > Views dropdown showed "Content" on /fr/admin/structure/views; then checked out MR !221 as-is (not rebased on 3.x), rebuilt caches and reloaded: the dropdown now shows "Contenu FR-TEST" on /fr and "Content" on /admin/structure/views. The Views extra links follow the interface language; module-derived labels were not tested, per the maintainer's suggestion to handle them in a follow-up.