Admin toolbar and contextual links should always be rendered in the admin language (if set)

+1 for an admin language type, it could be used for other UI elements such as local tasks/actions and contextual links.

I still think a new language type could be the solution here: if we define a non-configurable admin language type having as hardcoded negotiation settings something like admin language > UI language, then every UI element can decide whether it is and administrative item and default to the current Admin language. It shouldn't be hard to add a flag to a menu definition to mark it as "administrative".

IIRC the user admin page checks whether the admin language detection methods is enabled for the UI language type, if not it should be very easy to add a check. Anyway, do you think it would really make sense to configure an Admin language type? IMHO its meaning is pretty well-defined, not sure what alternative choices the user would be supposed to make.

Yes, but the current UI is pretty confusing if one has just to enable/disable admin language support. Wouldn't a single custom checkbox work better?

I am not sure I follow, I'll try to recap my proposal to see whether I can explain it better:

• the admin language type is non-configurable and locked (like the URL one), so no table is ever exposed for it
• the locked negotiation configuration is admin language > UI language
• a checkbox somewhere in the "Detection and selection" page (probably on top) lets the user enable/disable admin language support (I'd make it opt-out, btw)
• the admin language detection method checks the configuration value tied to the checkbox to decide whether returning a value or not, otherwise the fallback is the regular UI language
• the admin language selector is displayed on user account pages only if the configuration value above is TRUE

Edit: The admin language detection method is bound to the admin language type and cannot be used elsewhere.

We could also leave it always enabled and use a NULL default for users, so that Admin language is not active until explicitly configured. We could also add a permission to control access to the widget on user pages.

I am currently experiencing this issue in a Drupal 8 project using 8.0.5. I opened a related issue before finding this one #2688741: Administration pages language ignored in toolbar when viewing regular pages. It could probably be closed in favor of this one?

From reading through this thread it seems that #18 sound very similar to the Administration pages languagethat is currently in core, but it would be much more usable than the current solution. I don't see any good use case for wanting to have admin pages including the toolbar in a special language but not when viewing non-admin pages. In my opinion it would be much better with an "admin language" setting, that affected admin pages, admin toolbar, contextual items, drupal messages. etc everything that is seen as an admin string, no matter what page you are on.

Would it be possible to progress further on this issue and maybe get a fix in 8.0.x or is it postponed?

I will work on this patch re-roll for few hours.

As 2313309-toolbar-language-7.patch didn't apply anymore.
I had to rewrite all in every files 8.2.x . So didn't created an interdiff.
So my patch covers the same previous patch. I didn't had time to take into account comment since #7
Still need work.

We have #2313309: Admin toolbar should always be rendered in the admin language (if set) for that, which did not see to have much interest from users so far unfortunately :/

(Gábor Hojtsy, https://www.drupal.org/node/2189267#comment-11754752)

@Gábor Hojtsy - Unfortunately I can't help coding but I'm very interested in this issue which is quite important in my opinion.

@lba_emanuel - Are you planning to continue your work on the issue? Does it make sense to test the last patch, or should I wait?

I added a RTL Language translation File (Like: Persian, Farsi) to my drupal 8 site and What I simply want is to All "Administration Pages language" (or backend Language) in english only and all admin menu Always in left side and frontend pages of the site(Site Language) in another language (Like: persian, Farsi)
I do below setting:

1- I enabled the Language module, and set-up one additional language. Install was done in En (english), and I added Fa (Persian) language.
Language Module Configuration

2- I configure the administration language separate to the content language by below setting:

/admin/config/regional/language/detection:
Account administration pages: enabled

Interface text language Configuration

3-Admin -> Edit Profile -> Edit(Tab)
Configuration of Administration Language

This work properly for all administration page and those are English and in left side (LTR) except the "home page" and "user/1/" and admin/structure/block/demo/'Theme Name' of the site that the administration menu is in Persian Language and in right side (RTL) yet.

Administration Pages

Home Page

I followed Mojtaba Reyhani's steps, and I don't know if I have different expectations (he says this is working perfectly), but for me it does not work as expected. If I set the administration page language to English under Admin -> Edit Profile -> Edit(Tab), then I cannot edit any content in other languages; it only lets me edit pages in English. If I don't set that, then I can edit content in other languages, but then the admin toolbars are also shown in that other language. I can't tell if I'm doing something wrong, or if this is an ongoing issue.

In Drupal 8.24 it is NOT working.

Admin language is set to "en" - still the tool bar is shown in "japanese" in my case. Can't read anything. So the existence of the toolbar is useless in frontend pages of foreign languages.

Anybody encounters the same issue?

I've done a workaround for this problem by translating the local tasks and discovered links in a hook

define('BACKEND_LANGUAGE', 'en');

/**
 * Implements hook_menu_local_tasks_alter().
 * Translate all local tasks
 */
function language_frontend_local_tasks_alter(&$local_tasks) {
  foreach ($local_tasks as $key => $task) {
    if ($task['title'] InstanceOf \Drupal\Core\StringTranslation\TranslatableMarkup) {
      $options = $task['title']->getOptions();
      $options['langcode'] = BACKEND_LANGUAGE;
      $local_tasks[$key]['title'] = t($task['title']->getUntranslatedString(), $task['title']->getArguments(), $options);
    }
  }
}

/**
 * Implements hook_menu_links_discovered_alter().
 * Translate all local tasks that were not yet translated
 */
function language_frontend_menu_local_tasks_alter(&$data, $route_name) {
  foreach ($data['tabs'] as $key => $tab) {
    foreach ($tab as $route => $element) {
      $link = $element['#link'];
      if (!is_string($link['title']) && $link['title'] InstanceOf \Drupal\Core\StringTranslation\TranslatableMarkup) {
        $options = $link['title']->getOptions();
        $options['langcode'] = BACKEND_LANGUAGE;
        $data['tabs'][$key][$route]['#link']['title'] = t($link['title']->getUntranslatedString(), $link['title']->getArguments(), $options);
      }
    }
  }
}

I do not really like the workaround, but it seems to work for now.

Hello

How do you implement your workaround ?
In a module ?

I think that workaround code is flawed, comments imply that this implements certain hooks while it actually doesn't apply to those hooks.

What's the status of this issue? It seems that some assume that this already works as designed in D8? Though some of the others (include) seem to still get the admin menu in non-admin-language on the frontend of the site.

A (very hacky) fix to get this working for a client.

This also needs patches from:

• #2189267-53: When content language detection is different from interface language detection, the detected language is not applied to the rendered content
• #2868193-10: 'Account administration pages' language negotiation causes 'access denied' in toolbar subtree caching.

What we really need, I think, is a generic way to switch languages during handling of a single request.

Maybe this can help someone: https://drupal.stackexchange.com/questions/246793/multilingual-content-a....

I have the following case:
Multi-site installation.
One of the sites is multilingual and the the other one is not. The site which is not multilingual is crashing with the error:
Call to undefined method Drupal\Core\Language\LanguageManager::setCurrentLanguage() in Drupal\toolbar\Element\Toolbar::switchToUserAdminLanguage()

Refactored #40 patch to check if the site is multilingual and also added some code improvements..
Not sure if it still can be committed to core, but it definitely needs to be covered by tests.

Patch didn't really work with all menu. I have fixed user links and contextual links also.

I can confirm the patch from #44 works in combination with patch #78 from #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content.

Is that bug still relevant? I applied the patch from #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content. The admin toolbar works correctly and appears in english when I'm on the french version. My only problem now is the active tasks bar where menu items from administrative actions (Edit, Translate, etc.) appear in french instead of english.

I'm on Drupal 8.6.1.

Note that if you use the Admin Toolbar module (https://www.drupal.org/project/admin_toolbar), this patch doesn't have any effect!

I also confirm #47.

RE #48, I believe that is outside the scope. Getting the core Toolbar working in the admin language is what needs to happen no?

I think this should be done on a more generic level and not specifically towards Admin toolbar, as mentioned previously, i.e. if using something like Layout Builder I might want to display the interface in the administrative language.

Quick note that #2189267: When content language detection is different from interface language detection, the detected language is not applied to the rendered content was merged and this is probably no longer needed. For me #47 stands true.

I'm operating on Drupal 8.6.7, and with this patch applied. I can confirm two things:

1) With this patch applied, admin_toolbar DOES render in the language specified in the user's administrative pages language settings.
2) Without this patch applied, admin_toolbar DOES NOT render against the user's administrative pages language setting.

The same is true about the toolbar on it's own (i.e. admin_toolbar uninstalled, toolbar enabled).

So, IMHO this patch is still needed. Given it works exactly as I expect it to, I'll switch this to RTBC.

All works fine for me with patch #44 (core version 8.6.12), but I had this issue without using of this patch. So, this patch is still needed.

I've created a similar issue but for local task labels (see #3054641: Local tasks should honor selected admin interface language (if set)).

If current issue doesn't address translation of Contextual Links I guess a new issue should be created. It seems this is addressed in #44, but is not mentioned in issue's title nor in the summary, we shouldn't forget it.

I've tested patch #44 and seems to work for the Admin Toolbar, but I've not clear results about contextual filters (I didn't work for one test, but given I've a heavily patched Drupal site probably was a secondary effect). Although tests still fail, ti works ok on a Drupal installation.

@tunic I've been running the patch from #44 on several different sites we are working on and a local test site, and on all of them it seems that the contextual filters (quick edit etc.) have mixed translations for some reason, in the attached image it is of a site with 2 language (Installed with English, added Danish later and made it default language). I've checked that the translations aren't missing or attached to the wrong langcode, but all looked good.

So it does not look like the contextual filters are fixed, at least not during my testing, but it does fix the admin toolbar as expected.

If you know how to fix the contextual links, please by all means make an issue for it and post a patch, I'll gladly help test it out.

Hi, for Drupal 8.8.5 i can confirm that #44 works as expected but i can not apply the #78 or any other (most recept) patch (2189267-100.patch or 2189267-98.patch).

Patch #44 works for me too on Drupal 8.8.6.

Working on it.

Solving test cases.

Drupal 8.8.6
I have multisite configuration.
First one use translations, but for second Language module is disabled.
With this patch (#44) I got next error (on site without Language module):

The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\Core\Language\LanguageManager::setCurrentLanguage() in Drupal\language\ConfigurableLanguageManager::switchToUserAdminLanguage() (line 269 of core/modules/language/src/ConfigurableLanguageManager.php).

I wanted to test the patch in #64 but immediately got the following fatal error:

Error: Using $this when not in object context in Drupal\language\ConfigurableLanguageManager::switchToUserAdminLanguage() (line 269 of core/modules/language/src/ConfigurableLanguageManager.php).

After comparing the code from the patch in #44 I noticed on lines 269 and 294 the variable "$languageManager" was replaced with "$this". Reverting it back to "$languageManager" (see attached patch) fixed the error but I'm not experienced enough to be sure if this is correct or if there's a reason why the original author of the patch used "$this".

I hope I've helped a little bit and didn't made it worse.

FYI: this patch was tested and works on a D8.9.3 install

Created a reroll for Drupal 9 + added trustedCallbacks method to ConfigurableLanguageManager.

Patch from #68 is working fine for me on 8.9.7, but contexual filters are still being translated and also tabs are still being translated as well. But admin menu is working nice now.

#71, local tasks (tabs) are being handled on this issue: #3054641: Local tasks should honor selected admin interface language (if set).

Also, it's interesting that the patch is working for you but tests for pacth from #68 reports 89 errors.

Errors from #68 don't seem random errors because I've scheduled a re-test and fails the same way.

Handled CS messages.

Fixed the test case.

+++ b/core/modules/contextual/src/Element/ContextualLinks.php
@@ -20,8 +20,12 @@ public function getInfo() {
+        ['\Drupal\language\ConfigurableLanguageManager', 'switchToUserAdminLanguage'],
         [$class, 'preRenderLinks'],
       ],
+      '#post_render' => [
+        ['\Drupal\language\ConfigurableLanguageManager', 'restoreLanguage'],
+      ],

I think all the tests failing were due to this. I don't think adding the language module to those tests is the proper fix, since the error being thrown in those tests will happen on any site that doesn't have the language module enabled.

Rather, I think only conditionally adding these pre/post render callbacks if the language module is enabled makes more sense. I'm going to take a look at that now.

#78 no longer applied against 9.2.x:

Checking patch core/modules/workspaces/tests/src/Functional/WorkspaceTest.php...
error: while searching for:
  /**
   * {@inheritdoc}
   */
  protected static $modules = ['workspaces', 'toolbar', 'field_ui'];

  /**
   * {@inheritdoc}

Here is a re-roll. Nothing else was changed, so no need for an interdiff.

Well let's see if approach in #80 works.

Added test coverage for contextual links, toolbar and links provided by user_toolbar().

patch needs reroll

There you go!

+1

FYI, #100 patch applies on 9.2.x and 9.2.0-beta2 too.

Confirming RTBC for #100. Are we ready to set this RTBC?

#100 works well, but there is one small issue still - for arabic (or any rtl language) the layout is still appearing in right to left format. it's a bit weird to have this when the text is in english. I was thinking of just overriding this in my theme with css but it might be a good idea to include this in the patch if it's going to be committed soon.

also maybe unrelated, but is there a similar patch or workaround to get the theme local task links/tabs to appear always in english as well?

thanks!

@chrisss Good point! We could add a dir attribute on the toolbar wrapper.

You'll find the patch you need for local tasks here: #3054641: Local tasks should honor selected admin interface language (if set)

@DuaelFr I tried that actually but the issue is that the css currently gets the dir attribute from the parent element, so it's still overridden. Might need some css hacking.

Also thanks for the link!

Patch #100 seems to be working well using Drupal 9.2.1 with French (admin + content) and English (content) languages.
Thanks

Needs work for #104.

I was trying to fix #104 but it's not as simple as adding a dir attribute on the toolbar wrapper since styling is also added to the body element. e.g. in toolbar.module.css:

[dir="rtl"] body.toolbar-tray-open.toolbar-vertical.toolbar-fixed {
  margin-right: 240px;
  margin-right: 15rem;
  margin-left: auto;
}

I have conflict with LoginDestination which decorates ToolbarLinkBuilder class
https://git.drupalcode.org/search?search=LoginDestinationToolbarLinkBuil...

We probably cannot inject moduleHandler as it breaks compatibility with other modules

ArgumentCountError: Too few arguments to function Drupal\user\ToolbarLinkBuilder::__construct(), 1 passed in /Users/pari/Sites/drupal8/cimex/web/modules/contrib/login_destination/src/LoginDestinationToolbarLinkBuilder.php on line 41 and exactly 2 expected in Drupal\user\ToolbarLinkBuilder->__construct() (line 40 of core/modules/user/src/ToolbarLinkBuilder.php).

@parisek

login_destination implements a decorator pattern, but in the wrong way. It is completely up to contrib to make sure the implementations are correct.

Side information: decorators should not extend the class they're decorating. They should implement the correct interface, implement all methods and use $this->inner->method calls for each method they're not decorating. This mistake is made often though, but it shouldn't block improvements from going in core imo.

Patch on #100 didn't work for core 9.2.5. The reason is due to the following 2 files
1. When I examined the patch, I saw that the line in the file "core/misc/cspell/dictionary.txt" was added to the core. I deleted these lines from patch.
2. I saw that the file "core/modules/toolbar/tests/src/Functional/ToolbarMenuTranslationTest.php" has changed. I manually adapted the patch according to the current file.

In one of my environments I can't apply the patch in #114, I get the following message: "error: patch fragment without header at line 580: @@ -55,9 +55,8 @@ class ToolbarMenuTranslationTest extends BrowserTestBase {"

Since I could apply it in one of my other environments I was able to recreate it and now it works well.
The block for the file core/modules/toolbar/tests/src/Functional/ToolbarMenuTranslationTest.php was moved in the new patch.

Fixed the "custom command fail" issue.
Added word "entitynodedelete" in the cspell/dictionary.txt file. As per my understanding we can also ignore this word because it is on the test file however the related word 'entitynodeedit' also available in the dictionary file, on the basis of that I have added this word also, Please have a look and advise.

The patch in #116 didn't apply for me in 9.3.0
I recreated it, there was some functions that had some changes in core/modules/contextual/tests/src/Functional/ContextualDynamicContextTest.php and there was some changes in core/misc/cspell/dictionary.txt which caused the patch to not apply. I recreated the patch so it applies.
Unfortunately I couldn't create an interdiff for the changes.

Hi,

Which patch will work for 9.3?

I have improved a little bit the path #116:

- The sentences that come from configuration entities are also translated managed (for example the content types names)
- Checked the same permissions that are used in order to decide to show or hide the Administration pages languages option in the user profile (web/core/modules/user/src/AccountForm.php:255)
- Removed the LanguageInterface::TYPE_INTERFACE since it's the default one

I created a new MR based on #122 againt the branch 9.3.x https://git.drupalcode.org/project/drupal/-/merge_requests/1713

I've created a patch file from #126. We prefer a patch file because a MR url is moving target.

The patch in #127 is working for me.

I think there is still a problem with cache. When you change the language on the user profile page the toolbar isn't in the right language. I guess this is because the toolbar is cached based on the interface language and not on the user's admin language. I added a CacheContext for the preferred admin language and added it to the toolbar element.

I think we should decouple the contextual link changes from the toolbar changes. I'm 100% sure that the toolbar should be in the user's admin language. Contextual links are a bit trickier because there are probably use-cases where the admin language might bit be the correct choice - that said writing that down I'm struggling to actually come up with a use-case so let's fix up the issue title to reflect what this patch is fixing.

Here's a patch that hopefully passes tests and works for the toolbar and contextual links. Will write up a comment with some additional thoughts later.

This should fix the failing tests.

Hello,

I am experiencing issues when trying to apply this patch for keeping the english language in the form "media_library_add_form_upload".

I have a custom module with a form_alter, which does "$form = AdminLanguageRender::applyTo($form);"

But it seems that the AJAX callback is broken after this. I have been able to trace the issue and it seems that it is related with "Drupal\media_library\Form\AddFormBase::buildActions()". The "save select" action uses $value => $this->t('Save'), which is translated to "Enregistrer". After this, #pre_render seems to show the action button as "Save", but when clicking on save the triggeringElement() is not correctly detected.

I have changed the code of "buildActions" in order to use $value = 'Save', just for testing, and in this case everything works well.

Maybe this fonctionality is not thought to be used by $forms ? Is there any solution that would allow it to be used in forms, specially in forms with AJAX requests ?

I could not apply the patch in #135 on Drupal 9.4
Here is a new patch that applies.

[edit: my comment was addressed before I posted, hadn't refreshed the page]

@simohell can you unhide my patch if it works for you, or should I upload it again?

Hello

I have just tried to apply the patch from 135 comment but it happened that did not applied.
I am using Drupal core 9.4.x. It seems the reason way is that from that file dictionary.txt is missing that line entitynodeedit. It used be there in Drupal core 9.3.x but it seems it is not longer there in Drupal core 9.4.x
I have just added that to the patch and it applied for me.

P.S. if that line needs to be removed then we just need to remove it and the patch will apply again.

I've found a couple of nitpicks

1. +++ b/core/lib/Drupal/Core/Cache/Context/AccountAdminLanguageCacheContext.php
   @@ -0,0 +1,51 @@
   +/**
   + * Defines the AdminLanguageCacheContext service, for "per admin language" caching.
   

   80 cols

2. +++ b/core/modules/contextual/tests/src/FunctionalJavascript/ContextualTranslationTest.php
   @@ -0,0 +1,117 @@
   +  protected $defaultTheme = 'classy';
   

   should this be olivero now?

3. +++ b/core/modules/language/src/AdminLanguageRender.php
   @@ -0,0 +1,124 @@
   +  /**
   +   * The language manager.
   +   *
   +   * @var \Drupal\Core\Language\LanguageManagerInterface
   +   */
   +  protected $languageManager;
   +
   +  /**
   +   * @var \Drupal\Core\StringTranslation\TranslationManager
   +   */
   +  protected $translationManager;
   +
   +  /**
   +   * @var \Drupal\Core\Session\AccountInterface
   +   */
   +  protected $currentUser;
   

   only one of these has a short description, all of them should

4. +++ b/core/modules/language/src/AdminLanguageRender.php
   @@ -0,0 +1,124 @@
   +  public static function applyTo(array $type): array {
   

   Needs @return documentation

This patch covers all the suggestions mentioned in #142.

I've been using the patch from #143 in a site with 5 languages for a couple of days and it works like a charm (Drupal 9.4.4).

Thank you!

I used this patch (2313309-143.patch) on Drupal 9.4.4. The patch is successfully deployed, but it breaks the site:

The website encountered an unexpected error. Please try again later.

InvalidArgumentException: Class "language.admin_language_render" does not exist. in Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (line 24 of core\lib\Drupal\Core\DependencyInjection\ClassResolver.php).
Drupal\Core\Controller\ControllerResolver->createController('language.admin_language_render:switchToUserAdminLanguage') (Line: 69)
Drupal\Core\Controller\ControllerResolver->getControllerFromDefinition('language.admin_language_render:switchToUserAdminLanguage') (Line: 760)
Drupal\Core\Render\Renderer->doCallback('#pre_render', 'language.admin_language_render:switchToUserAdminLanguage', Array) (Line: 363)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 85)
__TwigTemplate_64381f4af3c78cf09ccf72dcbfcb0abed14b23cd5876352e631da3cc7c98b69d->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/custom/front/templates/layout/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 162)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 163)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 46)
Drupal\redirect_after_login\RedirectMiddleware->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

(Removing only the patch restores the site, so it "must" be the patch.)
PHP version: 7.4.16

As the patch conflicts with another one(https://www.drupal.org/project/drupal/issues/3101231), so I combine these two patches together.

Add the combined patch and add the enable option for the new feature.

#146 and #148 are not needed here, if you need the combined patch it would probably be better to just put it in your own project. I also don't see the relation between both issues, they might touch the same code but they feel very different in scope and purpose.

It seems like the error in #145 is enough to actually move it back to NW.

@Jeroen Dost does a cache rebuild after applying the patch make the error go away? It sounds like the service definition can't be found but there is a definition in service.yml, if that fixes it we just need an update hook, otherwise we're going to have to figure out what else could be causing this.

#143 is working well for me. (D9.4.5 / PHP 8.0.22)

Was hoping to get a response from @Jeroen Dost about their missing class error but I think that was just a cache problem somewhere.

Reuploaded the patch from #143 and setting it to needs review. Would like to see if this still passes tests.

Patch #152 is working with me

Tested on Drupal 10.1.x and php 8.1

- The issue summary is clear
- The patch applies cleanly
- Tested contextual links for multiple languages and works as expected
- #135 and #154 already includes screenshots so avoiding for repeatation
- No code issues noticed

Moving to RTBC

1. +++ b/core/lib/Drupal/Core/Cache/Context/AccountAdminLanguageCacheContext.php
   @@ -0,0 +1,53 @@
   +  public function __construct(AccountProxyInterface $current_user) {
   +    $this->currentUser = $current_user;
   

   I'm pretty sure the API addition here (the new method on the configurable language manager) makes this only eligible for a minor release, so I think we should add return type hints and use constructor property promotion here.

2. +++ b/core/lib/Drupal/Core/Cache/Context/AccountAdminLanguageCacheContext.php
   @@ -0,0 +1,53 @@
   +  public static function getLabel() {
   ...
   +  public function getContext() {
   ...
   +  public function getCacheableMetadata() {
   

   Let's add some return type hints here

3. +++ b/core/misc/cspell/dictionary.txt
   @@ -432,6 +432,8 @@ enim
   +entitynodedelete
   +entitynodeedit
   

   Are these still needed, I don't see them anywhere else in the patch

4. +++ b/core/modules/contextual/contextual.module
   @@ -174,13 +174,15 @@ function contextual_contextual_links_view_alter(&$element, $items) {
   +    $args['metadata'] += ['langcode' => $langcode, 'admin_langcode' => $admin_langcode];
   

   nit >80 here on an array

5. +++ b/core/modules/contextual/tests/src/FunctionalJavascript/ContextualTranslationTest.php
   @@ -0,0 +1,117 @@
   +    $this->clickContextualLink('article.node', $edit_translation);
   

   Whilst I know this is testing what we want, is there any way we can do it without using a WebDriver based test, which are typically slow and flaky?

6. +++ b/core/modules/language/src/AdminLanguageRender.php
   @@ -0,0 +1,131 @@
   +  /**
   +   * The language manager.
   +   *
   +   * @var \Drupal\Core\Language\LanguageManagerInterface
   +   */
   +  protected $languageManager;
   +
   +  /**
   +   * The string translation service.
   +   *
   +   * @var \Drupal\Core\StringTranslation\TranslationManager
   +   */
   +  protected $translationManager;
   +
   +  /**
   +   * The current user.
   +   *
   +   * @var \Drupal\Core\Session\AccountInterface
   +   */
   +  protected $currentUser;
   ...
   +  public function __construct(LanguageManagerInterface $languageManager, TranslationManager $translationManager, AccountInterface $currentUser) {
   +    $this->languageManager = $languageManager;
   +    $this->translationManager = $translationManager;
   +    $this->currentUser = $currentUser;
   

   Because there's an API change here (the new method on ConfigurableLanguageManager), this is likely 10.1 only.

   So let's use constructor property promotion here.

7. +++ b/core/modules/language/src/AdminLanguageRender.php
   @@ -0,0 +1,131 @@
   +  public function switchToUserAdminLanguage(array $element) {
   ...
   +  public function restoreLanguage($content, $element) {
   

   Let's add some type hints and return types here

8. +++ b/core/modules/language/src/AdminLanguageRender.php
   @@ -0,0 +1,131 @@
   +  public static function trustedCallbacks() {
   

   Let's add a return type hint here for : array

9. +++ b/core/modules/language/src/ConfigurableLanguageManager.php
   @@ -235,6 +235,18 @@ public function getCurrentLanguage($type = LanguageInterface::TYPE_INTERFACE) {
   +  public function setCurrentLanguage(LanguageInterface $language, $type = LanguageInterface::TYPE_INTERFACE) {
   +    $this->negotiatedLanguages[$type] = $language;
   +  }
   

   Shouldn't we be adding this to the interface too?

   Also, let's add a string type hint for $type and either make this method fluent (return $this) or add a void return typ

10. +++ b/core/modules/toolbar/toolbar.routing.yml
    @@ -4,3 +4,5 @@ toolbar.subtrees:
    +  options:
    +    _admin_route: TRUE
    

    This isn't necessarily so - see #1044090: Enable toolbar for authenticated users also, so that non-admin users can use shortcuts as well

11. +++ b/core/modules/user/src/ToolbarLinkBuilder.php
    @@ -21,14 +23,24 @@ class ToolbarLinkBuilder implements TrustedCallbackInterface {
    +  public function __construct(AccountProxyInterface $account, ModuleHandlerInterface $moduleHandler) {
         $this->account = $account;
    +    $this->moduleHandler = $moduleHandler;
    

    we can use constructor property promotion here.

    I was going to ask if we need to do a deprecation dance here, but there's no sub-classes in contrib according to https://git.drupalcode.org/search?search=ToolbarLinkBuilder&group_id=2 so we can probably just go with a change notice

Tagging for release not and change record

Looks like more work is also needed to support layout builder sections/blocks (in \Drupal\layout_builder\Element\LayoutBuilder::buildAddSectionLink / \Drupal\layout_builder\Element\LayoutBuilder::buildAdministrativeSection, I think).

Is there a way to add a test that allows us to test if other frontend UI items are also translated?

Add the combined patch and add the enable option for the new feature.

I've rerolled the patch in #158 so that it applies on the latest versions (10.1.x, 10.0.4 & 9.5.4).

I implement a small fix to patch #152, I assigned a NULL value to moduleHandler on the _construct function
public function __construct(AccountProxyInterface $account, ModuleHandlerInterface $moduleHandler = NULL) {
in ToolbarLinkBuilder.php file as I get this error when running the patch.

The website encountered an unexpected error. Please try again later.
ArgumentCountError: Too few arguments to function Drupal\user\ToolbarLinkBuilder::__construct(), 1 passed in /app/docroot/modules/contrib/login_destination/src/LoginDestinationToolbarLinkBuilder.php on line 41 and exactly 2 expected in Drupal\user\ToolbarLinkBuilder->__construct() (line 41 of core/modules/user/src/ToolbarLinkBuilder.php).

Rerolled #152 for 9.5.4 .

Fixes #161 patch.

The patch in comment #162 applied cleanly to 9.5.5

Add the combined patch and add the enable option for the new feature. for 9.5.5

Patch #162 has applied but contextual links are totally disappeared in some cases in layout builder

I see #149 says that #146 and #148 are not needed, and #164 seems to be an extension of those. Should anyone outside of the people posting those patches be using them? I'm not sure what the point is of an enable option, given that is just honoring existing config.

I started a new branch based off 11.x with the patch from #152 and the feedback from #156. Only the refactoring of the WebDriver based test hasn't been done yet. Let's stop posting patches now to avoid confusion, especially patching combining multiple issues. These don't belong here.

Regarding the typehint related feedback in #156: I'm not sure we should add typehints if the parent class hasn't decided on a typehint. For example, CacheContextInterface::getLabel currently has string documented as return type, but we also have to account for instances of TranslatableMarkup there. How exactly that should be done hasn't been decided yet, so we shouldn't either in the child class.

Regarding #160, there's a separate issue for that problem in the login_destination queue: #3261748: LoginDestinationToolbarLinkBuilder implements the decorator pattern in a wrong way.

This patch represents the current state of MR created in #170. We prefer patch files as long as the merge request urls are considered dangerous, see https://github.com/cweagans/composer-patches/issues/347.

This time with a valid patch file extension...

HI @timohuisman,

thank you for the heads up!

I'm not sure what #173 was, but it was not created with https://git.drupalcode.org/project/drupal/-/merge_requests/4604.diff.
Attached is the new 11.x MR 4604 at commit 7975cb1f.

Updated:

#175 gave me error but I got it working. This patch didn't solve my toolbar problem

The patch in #173 was working for us in 10.1.x. But it no longer applies in 10.2.0, nor does the patch from MR 4604. I'll take a look to see what's changed, but it may be several days until I have time.

Rerolled the patch #173 for Drupal 10.2.0

Fixes #178 patch

#179 works, thx!

I didn't review the code but just wanna report that #179 works well for me on a big site running Drupal 10.2.1!

#179

Works on drupal 11.0-dev

new branch with the commit of patch 179:

https://git.drupalcode.org/issue/drupal-2313309/-/tree/2313309-179-11.x

and MR:

https://git.drupalcode.org/project/drupal/-/merge_requests/6351

thanks!

Patch #179 works fine in Drupal 10.2.2 with PHP 8.2.

The patch in #179 fixed this for us. The merge requests !4604 and !6351 both include the patch file, which shouldn't be included in the MR's but at least !6351 looks otherwise ok.

#179 works for me in Drupal 10.2.2 using PHP8.1.

+1 for #179. Drupal 10.2.6 using PHP 8.2.

I hide all other branches than MR 4604. I rebased it and addressed the parts of feedback from #156 that where missing, except for
- Typehints not done per #170.
- #156.5: Is still open question.
- #156.8: Instead of adding typehint, made https://www.drupal.org/node/3349470, that seems still need a work with tests (AutowireTest)

This still needs work:
- Fix issues on MR 4604
- Needs change record
- Needs release note

Fixed the tests and created a draft for change record and release notes.

@sokru thanks for hiding the old MRs, also good to hide all patches since those aren't needed anymore and the bot could pick them up.

Left some comments on the MR.

All the feedback has been addressed.

Feedback does appear to be addressed

But CR https://www.drupal.org/node/3456217 is empty