Views does not include strings in the menu definition in exported translatables

Not 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?

I 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:

$items['my-callback'] = array(
  'title' => 'File list',
  ...
);

To this:

$items['my-callback'] = array(
  'title' => t('File list'),
  ...
);

The latter being incorrect.

The string 'My Drafts' is being used as the display title which is being picked up for translations:

$handler->display->display_options['title'] = 'My Drafts';

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.

$handler->display->display_options['menu']['title'] = 'My Drafts';

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.

Digging 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?

Making 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."

Or 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

        'title' => array('default' => '', 'translatable' => TRUE, 'translate' => FALSE),
        'description' => array('default' => '', 'translatable' => TRUE, 'translate' => FALSE),

Where the default for 'translate' is TRUE if 'translatable' is TRUE.

Just showing some piece of code in views

        // Do not translate menu and title as menu system will.
        'title' => array('default' => '', 'translatable' => FALSE),
        'description' => array('default' => '', 'translatable' => FALSE),

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.

http://palantir.privatepaste.com/21b8ad72d1 might be a solution based on #9.

For d7 i would like not to change the behavior but introduce something like export_translatable
as every tiny little change can cause other issues :(

Yeah 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.

I 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.

Cleaning 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.