This is the best module ever.

I have admin_toolbar and extras enabled. In the Swedish drop down for Content (Innehall) -> Add content (Lag till..) -> I cannot get the content type names translated. Although they are translated correctly when I got to the /node/add page.

I am not sure this is an admin toolbar problem but I thought I have to start somewhere.

CommentFileSizeAuthor
#25 admin_toolbar-names_not_translated-2759135-25-d8.patch2.64 KBJean Anx
#21 admin_toolbar-names_not_translated-2759135-21-d8.patch3.1 KBadriancid
#13 admin_toolbar-names_not_translated-2759135-13-d8.patch2.19 KBromainj
#12 content_type_names_are-2759135-12.patch1.82 KBJohnny vd Laar
#11 content_type_names_are-2759135-11.patch1.8 KBJohnny vd Laar
#5 translate_content_types-2759135-5.patch1006 byteschegor
#2 translate_content_types-2759135-2.patch1.13 KBmiiimooo
KMS-222-admin-toolbar-translation-01.png32.59 KBmiiimooo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

miiimooo created an issue. See original summary.

miiimooo’s picture

miiimooo
Location Europe
CreditAttribution: miiimooo at Wunder commented
Version: 8.x-1.15 » 8.x-1.x-dev
FileSize
translate_content_types-2759135-2.patch1.13 KB

I am attaching what is by no means a solution to the problem. I've tracked this down to where the menu items are added in admin_toolbar_tools. Menu items that are translated correctly are stored as (serialized) TranslateableMarkup in the menu table and are then translated at runtime to teh correct current language. The current code just stores the translation at the time of the menu tree build as string to the db. So they are not translated when viewed in a different language.

The patch is using t($var) which is probably in most cases not correct. But I am not sure how to access config translation. Maybe some expert in (config) translation can advise.

miiimooo’s picture

miiimooo
Location Europe
CreditAttribution: miiimooo at Wunder commented

(duplicate post)

nghai’s picture

nghai CreditAttribution: nghai commented

@miiimooo Is this problem solved ? Because the problem is still there with Release 8.x-1.17.

chegor’s picture

chegor CreditAttribution: chegor as a volunteer commented
Status: Active » Needs review
FileSize
translate_content_types-2759135-5.patch1006 bytes

Patch works for me in 8.x-1.17.

mrtndlmt’s picture

mrtndlmt CreditAttribution: mrtndlmt commented

Thanks for the patch! Works for me!

ckaotik’s picture

ckaotik
Primary language German
Location Berlin
CreditAttribution: ckaotik at werk21 commented
Status: Needs review » Needs work

\Drupal::entityTypeManager()->getStorage('node_type')->loadMultiple() already returns the localized title/description when using configuration translation. Therefore, t($type->label()) can lead to unexpected side effects, e.g. declaring already translated configuration titles as source strings for interface translation. As far as I know, we should not run the returned label through translation again.

This does create the effect, however, that links are always displayed in the interface language used during menu/links cache rebuild. I don't quite know how to fix this, though ...

bdominguez’s picture

bdominguez CreditAttribution: bdominguez commented

I have the same problem. In my case, patch #5 doesn't work with Drupal 8.2.6.

It's a critical issue for multilanguage sites.

Edit: I expand my answer. It works but only if I do "Rebuild menu". But to display in each language I have to change interface language and then "Rebuild menu". It only works in the current language, to see it in another language I have to do "Rebuild menu" again. And If I do "Flush all caches" I will get the menu in other language (the site default language).

ckaotik’s picture

ckaotik
Primary language German
Location Berlin
CreditAttribution: ckaotik at werk21 commented

The problem is that we can't use string translation (where translation happens very late, during rendering => post caching) because the entities use configuration translation (where translation happens very early, when loading the configuration => pre caching). This in combination with MenuLinkDefault/MenuLinkBase caching everything statically causes issues. We'd probably need a cache context of languages:language_interface to get this working.

I can see two options on how we could resolve this, both are neither nice nor short: Either provide a new MenuLink type that can cache by language context, or create a new StringTranslator for the TranslationManager that pulls translations from configuration and would allow us to use TranslatableMarkup as suggested in hook_menu_links_discovered_alter. The first should be the easier one and might be avoided if we could manage to get a Core-patch that allows definitions of MenuLinkDefault to provide caching information, maybe via metadata?

SpadXIII’s picture

SpadXIII CreditAttribution: SpadXIII at ezCompany commented

It looks like this patch is already included in the submodule admin_toolbar_tools.

Johnny vd Laar’s picture

Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commented
Title: Content type names are not translated » Content type, Vocabularies and Menus names are not translated
FileSize
content_type_names_are-2759135-11.patch1.8 KB

I agree that this possibly isn't the best way to translate these items. But I also needed Vocabularies and Menu items to be translated. So I've passed these through the t-function as well.

Johnny vd Laar’s picture

Johnny vd Laar CreditAttribution: Johnny vd Laar at ezCompany commented
FileSize
content_type_names_are-2759135-12.patch1.82 KB

And a patch for everyone on 8.x-1.19

romainj’s picture

romainj CreditAttribution: romainj as a volunteer commented
FileSize
admin_toolbar-names_not_translated-2759135-13-d8.patch2.19 KB

I think that we need a patch even if it's an ugly one:) I created it according to the latest dev version.

  • romainj committed a3eeb3d on 8.x-1.x 
    Issue #2759135 by Johnny vd Laar, miiimooo, chegor, romainj: Content...
romainj’s picture

romainj CreditAttribution: romainj as a volunteer commented

Committed in latest dev version. Thanks to all.

romainj’s picture

romainj CreditAttribution: romainj as a volunteer commented
Status: Needs work » Reviewed & tested by the community

The last submitted patch, 11: content_type_names_are-2759135-11.patch, failed testing. View results

The last submitted patch, 2: translate_content_types-2759135-2.patch, failed testing. View results

The last submitted patch, 12: content_type_names_are-2759135-12.patch, failed testing. View results

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 13: admin_toolbar-names_not_translated-2759135-13-d8.patch, failed testing. View results

adriancid’s picture

adriancid
Primary language Spanish
Location Montreal, Canada
CreditAttribution: adriancid as a volunteer commented
Status: Needs work » Needs review
FileSize
admin_toolbar-names_not_translated-2759135-21-d8.patch3.1 KB

Rerolling the patch.

This was changed in http://cgit.drupalcode.org/admin_toolbar/diff/admin_toolbar_tools/admin_...

  • adriancid committed d266895 on 8.x-1.x 
    Issue #2759135 by Johnny vd Laar, miiimooo, romainj, chegor, adriancid,...
adriancid’s picture

adriancid
Primary language Spanish
Location Montreal, Canada
CreditAttribution: adriancid as a volunteer and commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Jean Anx’s picture

Jean Anx CreditAttribution: Jean Anx commented
FileSize
admin_toolbar-names_not_translated-2759135-25-d8.patch2.64 KB

I edited the patch #21 because it doesn't work on Admin toolbar 1.27 version. Feel free to review it !