Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The tab 'admin/workbench/files' named 'File list' cannot translated. It seems missing in the translatable strings of the view.
Comments
Comment #1
Dave ReidNot sure how to best fix this considering it's a menu link and simply a views export. You can't normally translate menu links without an additional solution like i18n_menu.module, so how is this any different?
Comment #2
hass CreditAttribution: hass commentedNormally all views strings can be made translatable? The translatable strings are on the end of a view file... I'm confused that this is not possible. I thought it's just t()'ifing that is required and someone missed it. Other tabs are translated properly...
I mean the $translatables()
Comment #3
Dave ReidI don't think the menu link text that Views provides has ever been translatable because menu links themselves are not translatable. This is the equivalent of asking someone to change their hook_menu() from this:
To this:
The latter being incorrect.
Comment #4
hass CreditAttribution: hass commentedYes, this would be wrong. But what your you doing with My Drafts and other tabs? They are all translated... Maybe the code can optimized to to add this? Maybe we only need to add the string to the translatable's array and that's it... I haven't tried it yet manually...
We need to find any better solution than closing the case with won't fix. It's not ok to show English strings if the interface is German.
Comment #5
Dave ReidThe string 'My Drafts' is being used as the display title which is being picked up for translations:
This however is not going to be translated because it is a menu link even though the same string is provided in the exported translatables array.
So I'm looking at http://api.drupal.org/api/drupal/includes%21menu.inc/function/_menu_item... and it appears to automatically run t() on menu local tasks. So I'm wondering if Views actually needs to be patched to ensure that the strings in menus are added to the exported translatables array.
Comment #6
Dave ReidDigging through older issues, the only thing I could find is #401822: views multilanguage menu items.
So a summary for the views issue queue: If you have a view with a page display that is added as a local task menu item, then the title of that menu item needs to be listed in the translatables array when the view is exported. This is because core does not provide any way to provide translations for local tasks, so we need to explicitly register them. This should probably be true of all menu titles in Views displays because if you think about it, we always extract every 'title' from hook_menu implementations for translation, so why shouldn't we do the same here?
Comment #7
tim.plunkettComment #8
Dave ReidMaking this change seems to make the strings show up in the exportables array: http://palantir.privatepaste.com/fa437a1f36
However, I suspect that changing this 'translatable' flag has unintended side effects of running t() in places where we *don't* actually want to for the menu links since it's handled by core later when menu links/tasks are rendered. So, I could use guidance on where to go for "add this string to the exportables array, but don't really do anything with it."
Comment #9
Dave ReidOr we need some kind of flag for 'please include this item in the list of translatable strings, but don't do anything with it.' Something like
Where the default for 'translate' is TRUE if 'translatable' is TRUE.
Comment #10
dawehnerJust showing some piece of code in views
So basically views assumes that the menu system does the translation,
so views shouldn't expose the value as translatable via views itself.
So basically to support this usecase we would need both a way to tag something as translatable and tag something as, this should be marked as translatable on the export but not translated on the actual loading.
Comment #11
Dave Reidhttp://palantir.privatepaste.com/21b8ad72d1 might be a solution based on #9.
Comment #12
dawehnerFor d7 i would like not to change the behavior but introduce something like export_translatable
as every tiny little change can cause other issues :(
Comment #13
Dave ReidYeah I understand the concern about regressions, but considering this is supported from the base views_object which all views must extend from, I cannot see how this would actually change any functionality. Doing some research to show if this would affect anything.
Comment #14
tim.plunkettComment #15
xjmComment #16
JeremyFrench CreditAttribution: JeremyFrench commentedI have just stumbled upon this issue today. Wondering why advanced forums has some tabs which are not translated. I think because it is not included in the translatables array, and is added by a hook menu (I believe views are added by menu_alter) the translation system skips the strings. So a module may report that it is 100% translated but not have these strings in it.
Comment #25
LendudeCleaning up old bugs.
Menu settings are now fully translatable, so this shouldn't be an issue anymore in Drupal core. No idea about D7, so since this is still marked as 'needs backport', I'll move it to the Views queue.