Cannot localize menus built by contributed modules

same happened to me

Drupal 7.19 7.19 Up to date
Internationalization (i18n) 7.x-1.8 7.x-1.8 Up to date
Views translation (i18nviews) 7.x-3.x-dev 7.x-3.x-dev Up to date
Localization client (l10n_client) 7.x-1.1 7.x-1.1 Up to date
Localization update (l10n_update) 7.x-1.0-beta3 7.x-1.0-beta3 Up to date

Solution / workaround:
after disabling the menu entry in views the menu item remained active and I was able to translate it.

This module only translates Drupal core custom menus, doesn't even try with menus generated by other modules. Maybe try i18nviews module.

I deleted (removed in db) menu items created by views and re-created them manually by adding items with path into menu. This way menu items can be translated with no problems, but I am thinking maybe we should have warning for these non-system-menu items?
Getting unexpected Fatal error thrown is perhaps not the way to have this?
(I re-opened issue for this discussion)

Ran into this same issue, I am in favor of #5's solution of warning user's that they can't translate views generated Menu Links.

I ran into the same issue and I solve it
In my case, I wanted translate a element built by views in a menu set to 'Translate and Localize' but the element was set to 'Language neutral'. I just set a language in the element and after was possible translate it without problem.

#3 Jose Reyero: if is right, maybe can be a condition for force the user to set the language in the menu item before translate it (only one idea).

greetings!

My issue was similar but the item I wanted to translate was not the one generated by the view, however it was a menu item with the same title as the one the view generated. The view generated item was in a different (non-translatable) menu, and when it was there the item I wanted to translate would not get added to the menu group of strings. Changing the setting on the view to remove the menu item solved the problem for me.

Menus created by contributed modules can be translated. The menu item created by contributed modules is language netural, you need to set it to a specific langauge, then you can translate it.

However, if the original menu langauge is unset, the error message should be more useful than This object has no strings available for translation.

True, they can be translated this way. I think there is some confusion around the terminology being used here. My understanding of the problem is that they can not be localized. When they have no set language they should appear in the Menu group of the Translate Strings page after a string update has been done, and instead of the error message it should allow you to localize it through the translate tab like when you create your own language neutral menu item.

Sorry, posted to a wrong issue. See #1897696: Inconsistent check for translatable title in _i18n_menu_link_localizable_properties() and _i18n_menu_link_localize()

The same problem here, I'm trying to translate Forums (/forum) menu item and when going to Translate tab, I've the message: This object has no strings available for translation.

Had a problem similar to the one described in #8, except removing the view's menu item didn't cut it.
For whatever reason, the solution described in #7 did it for me (set a language, saved configuration, then went back and put it back to 'Language neutral' and it was finally translatable).

Thanks!

"Add content" of navigation menu not found in Translate interface. How to translate that????
Thats a part of core menu :(

I ran into that fatal error on some links. Debug shows that i18n_menu_link::get_strings() returns nothing because _i18n_menu_link_localizable_properties() also returns nothing.

function _i18n_menu_link_localizable_properties($link) {
  $props = array();
  $router = !empty($link['router_path']) ? _i18n_menu_get_router($link['router_path']) : NULL;
  if (!empty($link['link_title'])) {
    // If the title callback is 't' and the link title matches the router title
    // it will be localized by core, not by i18n_menu.
    if (!$router ||
        (empty($router['title_callback']) || $router['title_callback'] != 't') ||
        (empty($router['title']) || $router['title'] != $link['link_title'])
    ) {
      $props[] = 'title';
    }
  }
  if (!empty($link['options']['attributes']['title'])) {
    // If the description matches the router description, it will be localized
    // by core.
    if (!$router || empty($router['description']) || $router['description'] != $link['options']['attributes']['title']) {
      $props[] = 'description';
    }
  }
  return $props;
}

it will be localized by core

I wonder if this really happens? I know that the core does translate the router item, but I think it does not handle the menu links...

I removed that "core translation" checks, changed the function to this

function _i18n_menu_link_localizable_properties($link) {
  $props = array();
  if (!empty($link['link_title'])) {
    $props[] = 'title';
  }
  if (!empty($link['options']['attributes']['title'])) {
    $props[] = 'description';
  }
  return $props;
}

and now it works good for me.

Can someone tell if this is a correct approach?