[i18n] Integrate Taxonomy Menu with i18n_menu and entity_translation.

Please do send a patch against 7.x-1.x! Thanks for your hard work.

I'm interested in this functionality as well. Here is a patch that applies on the latest dev version, but completely untested for now on my side... I will try to test it and provide more feedback.

The test should pass now...

smartango > I corrected the bug in #5 and it passed the test.

I tested this with entity translation and it works very well. It's nice to see that when you translate a taxonomy term, it appears translated in the menu automatically.

Here is a new patch which fixes one notice message that appeared when saving a term. I think if we could get one more review this could be RTBC...

Another bug fixed with this new patch: whenever a term was updated, it was added again to the taxonomy menu.

Awesome, guillaumev. Great work here.

I'd be all about including this patch in the upcoming release if there were some tests along with it. I always end up breaking multilingual support when I do things, it would be really helpful for all of us.

Thanks!

New bug discovered (when rebuilding entire menu, not all terms were deleted properly) and new patch. I'll try to include some tests in the next patch...

Ok here is a new patch with one test for entity translation. The setup procedure is quite long to run this test though, because it needs to install various modules and configure them.

Ok so the tests in this patch fail while they really shouldn't: I believe the reason is that the automated testing infrastructure of drupal.org does not have i18n_menu included, but maybe I'm missing something...

dstol > How would you like to go about that ?

This might take us in a different direction.

From what I've read (below), the best course of action is to make a taxonomy_menu_i18n submodule, with its own tests. That way we can specify a dependency on i18n in the info file.

I'm not sure if the current architecture of taxonomy_menu would support such a submodule anyways.

What do you think?

http://drupal.org/project/testbot
http://drupal.org/node/1670936
http://drupal.org/node/1676288

I could go ahead and try it (maybe in another issue though, just to make things clearer), but why do you think taxonomy_menu would not support such a submodule ?

I'm sure it could but the main module will need to change a bit to support the submodule.

I think we can stick it out in this issue.

Let's see if that works...

Trying again...

Ok that one passed, because I have the testbot ignore the entity translation tests. However, when there is a new release of taxonomy_menu, the tests should not be ignored anymore, from what I understand from http://drupal.org/node/1670936

Do you think this is RTBC ?

#20: 1665308-entity_translation_i18n-20.patch queued for re-testing.

Could someone summarize what exactly works ? I'm very interested in this feature and I've also work on this on my own, but unfortunately I can't get anything working with this patch.

Config:
- New Drupal install
- Taxonomy Menu latest dev
- menu and taxonomy localized (Translation mode: Localize) along with translations for 2 languages.

Hey smartango,

I had to fix a few whitespaces to get the last patch working on the latest dev but other than that it applied cleanly.

I figured out, like you said, that I had to desactivate localization options. But I still can't get it working. Your vocabulary is not localized but is your menu localized ? What I'm trying to achieve is to create taxonomy terms like that in my menu (for exemple):
- item 1 EN
- item 1 FR
- item 2 EN
--- item 3 EN (taxonomy)
--- item 4 EN (taxonomy)
- item 2 FR
--- item 3 FR (taxonomy translated)
--- item 4 FR (taxonomy translated)
- item 5 EN
- item 5 FR

where item 2 EN and item 2 FR is a translation set because of the localized translation mode of the menu.

What I get for now is something like that:
- item 1 EN
- item 1 FR
- item 2 EN
--- item 3 EN (taxonomy)
--- item 3 FR (taxonomy translated)
--- item 4 EN (taxonomy)
--- item 4 FR (taxonomy translated)
- item 2 FR
- item 5 EN
- item 5 FR

So when switching the language to FR, item 3 FR and item 4 FR are not visible.

Also, I think there should be a dependency to the entity_translation module. At first, I did not even see it was used by the patch :)

Thank you smartango. At least, I know what I should have.

With my previous local work on localization with taxonomy_menu, all I needed left was taxonomy_menu to handle languages in the database. Now I'm sure adding a language column in {taxonomy_menu} table would be a benefit to all localization methods without changing the way taxonomy_menu is working for other users. So maybe that's worth it to be included in the original module.

But still I wonder, what's the advantage using entity_translation module over other multilingual options such as localized.

Ok, I'll do further testing and debugging to see what's wrong on my side. It will be easier now I know what I should have.

I think we need to go in several steps to get this patch/sub-module in.

The maintainers need to be willing to accept a first patch that allows taxonomy menu to deal with languages, more like an API patch. I think this is no problem, data can be saved in the {taxonomy_menu} table with a neutral language by default anyway. If it's OK for the maintainers, I'll open a new issue for that.

Also a module/sub-module would be better than a patch, we need also other translation system (i18n_taxonomy) to be able to interact with taxonomy menu. Once the API changes for languages get in, this is just a matter of how the menu items are prepared to be saved (building their properties). This can differ from one translation method to another, but I think at the end it is just a matter on getting the title/description and data to be saved in the {taxonomy_menu} table. We could introduce a hook_prepare_menu_item($item) to allow other modules to deal with that.

It's really some initial thoughts about it, what do you guys think ?

I've looked at the code and even worked on it, so I am well aware that the API change for languages is already included in the patch. All I am saying is that it would be better to commit the API change separately from the entity translation feature in itself.
What would be great is that once the API change is commited, then we work at getting taxonomy menu more flexible so we can plug sub-modules/modules to it like this one.

About flexibility, I must say I don't really like the fact that when we save a taxonomy term as a menu item in the save function, we decide to save other different menu items at the same time (translations of the taxonomy term). I mean the save function is meant to save one menu item, it is not its job to save silently other menu items in the process.

What I mean is that its great that we have something working, but I think we need more flexibility from taxonomy menu first before actually writing or commiting such a patch/sub-module or create a new module for that. Plus, there are still some small things to fix in the patch like coding standards or the way fields are accessed in the entity (atm, the patch uses something like $entity->field_yourfield[$language][0]['value'];) to get the value of a field, which is not the robust way.

All in all, the maintainers should agree to include the API change first. Else, anything we do will be useless.

My opinion is that we should get committed any API changes related to languages in a new 2.x branch commit, then we can integrate this module/sub-module/patch based on these changes in this branch. If for whatever reasons, we need more changes to taxonomy_menu, we can make them in 2.x without affecting users in 1.x. Aim of 2.x would be to provide the tools to benefit from localization features.
Anyway, all this is not up to me, but maintainers, so let's wait :)

I'll try to find out what changes are necessary in taxonomy menu, so we can easily plug a sub module in order to get the localization working. I think it would be nice to leverage some hooks instead of adding language logic inside taxonomy menu. In function of that, I'll add the respective issues so maintainers can review each change more easily.

After some work on it, I think we need the modifications of database functions to add a language parameter (already in this patch) and a post-save hook so that when a menu item is inserted, other modules can perform actions (like adding translated items in our case). Also, we need to prepare a translated taxonomy term to be a menu link in a different way than the original taxonomy menu's method (changing title, description, parent mlid etc... we already have some logic in this patch), but I have not found a nice way to do that yet, without somewhat "overriding" the original method.

If you have any suggestions or see anything else that I am missing, please do post a comment so we can discuss it !

we can easily plug a sub module in order to get the localization working. I think it would be nice to leverage some hooks instead of adding language logic inside taxonomy menu.

This is the way to go...

Thanks all, there's a lot of good thought here

@dstol If we want to do that, I think this is the right time for a 2.x branch. Right now, I have a sub-module taxonomy_menu_localized that can build/rebuild menu items like expected. In order to do that, I needed the following in taxonomy_menu:
- add a column 'language' in the {taxonomy_menu} table
- database functions dealing with languages
- a hook 'prepare' that is called after a taxonomy term is "converted" to a menu item to be saved. I can then add other menu items based on the converted term, that are "translations" of this menu item.
- changes in the function calls in the handler function.

I think there are also other changes that could go in the 2.x branch:
- Rework database function to fully use D7 database API (ex: convert db_query(DELETE ... ) to db_delete(...) etc..)
- Improve readability of the code by decomposing the "save" function in the handler, which takes care of converting terms in menu items, saving the menu items, and inserting data in the {taxonomy_menu} table.
- Remove insert/update hooks ? (i'm not sure but I don't see their utility right now)
- Coding standards / documentation
- maybe more ?

I created a sandbox http://drupal.org/sandbox/hles/1782024 so you can take a look at the code. Right now, you have to use the rebuild option if you want to get it working. I have not yet tested/coded anything related to options other than default one and update of existing terms. Think about uninstalling taxonomy_menu before because this one ships with a modified one.

Anyway, that may help reviewing possible flaws in the architecture of the module.

Even though this issue seems to be going in a different direction, I would still like to provide a new version of my patch which applies to the latest dev version.

Not being a developer, I did my very best to follow this discussion but honestly I am confused. As far as I understand, hles and guillaumev have different approaches which require different taxonomy configuration.

Could someone please summarize which approach requires what configuration?

I am struggling with the following:
Existing nodes with translation are using a non-hierarchical traxonomy with translation mode 'translate' for taxonomy menu. The parent menu item (menu location) stems from a menu with translation mode 'translate and localize'.

We were unaware of the current issue until it was too late, for the respective menu items were generated and everything looked fine. Now every time a node using this taxonomy is saved, the respective menu item is moved to the original parent menu. I think everyone who is following this issue knows the phenomenon.

Of course, it looked a bit confusing that there is only one menu location to choose from, not one for each language. Heading for the issue queue, I suspected this to be the starting point for a solution. Not a good idea?

Changing title.

"Adding a language field" part of the patch was created in #1799302: [i18n] Add language field in database and update database functions accordingly

Subscribing

Tagging

The plan is to consolidate the 2.x version with tests and get most of the original options working (which is quite already the case). Then to rewrite the code in my sandbox for i18n integration. Could you elaborate on "follow another path" ? I mean what we want to do is basically get available translations of taxonomy terms and create the right menu links from them.

I will post here once my sandbox is updated so we can all start discussing and working on this. From what I've already experimented, it should not be too painful.

Hi, I got here searching for a patch that creates translated menu items for localized taxonomies, but all the patches failed to install. I'm a Git beginner but I have already successfully applied a couple of patches before. (Below is an example from applying patch 41 against 7.x-2.x-dev.) Is there a fresh build with the solution I'm looking for available somewhere?

error: patch failed: taxonomy_menu.info:7
error: taxonomy_menu.info: patch does not apply
Checking patch taxonomy_menu.install...
error: while searching for:
        'default' => 0,
        'description' => 'Vid for the tid.',
      ),
    ),
    'primary key' => array('mlid', 'tid'),
    'indexes' => array(
      'vid' => array('vid'),
    ),

error: patch failed: taxonomy_menu.install:61
error: taxonomy_menu.install: patch does not apply
Checking patch taxonomy_menu.module...
error: while searching for:
  $menu_links = _taxonomy_menu_get_menu_items($vid);

  // Cycle through the menu links
  foreach ($menu_links as $tid => $mlid) {
    // $args must be reset each time through.
    $args = array(
      'menu_name' => $menu_name,
      'mlid' => $mlid,
    );

    if ($tid == 0) {
      $args['vid'] = $vid;
    }
    else {
      $args['term'] = taxonomy_term_load($tid);
    }

    //update the menu link
    taxonomy_menu_handler('update', $args);
  }

  return t('The Taxonomy Menu %menu_name has been updated.', array('%menu_name' => $menu_name));

error: patch failed: taxonomy_menu.module:297
error: taxonomy_menu.module: patch does not apply
Checking patch taxonomy_menu.test...
error: taxonomy_menu.test: No such file or directory
Checking patch tests/taxonomy_menu.test...
error: tests/taxonomy_menu.test: already exists in working directory
Checking patch tests/taxonomy_menu_tests.info...
Checking patch tests/taxonomy_menu_tests.module...

Moniuch, patches were written against 1.x, they should be against 2.x

I am sorry for maybe a dumb question, but is there now a way I can use Taxonomy menu with translated terms? Currently I have Taxonomy menu 7.x-1.4. Which version should I switch to and what patches apply, so that translated and original terms are counted correctly?

There are no way to do it for now. There is just a proof of concept in my sandbox, which has not been updated for 4 months and was written against a modified version of 1.x. The code in the sandbox needs to be updated to work with Taxonomy Menu 7.x-2.x, which has the necessary modifications to make it work but still unstable. That's why i18n integration is suspended on my side, waiting that 2.x is more mature.

I have the same problem, can't use it with entity translation

Let's change the status to active, the work that has been done so far was against 7.x-1.x and was experimental. This feature needs to go in 7.x-2.x, which can handle languages and is more tested. Currently there is no i18n feature whatsoever available in taxonomy menu.

I have taxonomy_menu 7.x-1.4, entity_translation for my taxonomy and i18n_menu for the menu.

Multilingual options for my menu is set to :
Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized.

I used the taxonomy_menu hooks to make this work, in a custom module.
Here's my code if it can help :

/**
 * Implements hook_taxonomy_menu_insert()
 */
function MY_MODULE_taxonomy_menu_insert(&$item) {
  _MY_MODULE_taxonomy_menu_update($item);

}

/**
 * Implements hook_taxonomy_menu_update()
 */
function MY_MODULE_taxonomy_menu_update(&$item) {
  _MY_MODULE_taxonomy_menu_update($item);
}

/**
 * Implements hook_entity_translation_delete()
 *
 * Erase the menu item translation in the deleted term language.
 */
function MY_MODULE_entity_translation_delete($entity_type, $entity, $langcode) {
  if ($entity_type == 'taxonomy_term') {
    $vid = $entity->vid;
    $menu_name = variable_get(_taxonomy_menu_build_variable('vocab_menu', $vid), FALSE);
    if ($menu_name) {
      $menu_links = _taxonomy_menu_get_menu_items($vid);
      $mlid = $menu_links[$entity->tid];
      $i18n_name = array('menu', 'item', $mlid);
      $i18n_title = $i18n_name + array(3 => 'title');
      $i18n_desc = $i18n_name + array(3 => 'description');
      i18n_string_translation_update($i18n_title, '', $langcode);
      i18n_string_translation_update($i18n_desc, '', $langcode);
    }
  }
}

/**
 * Update a taxonomy_menu item with the taxonomy term fields and its
 * translations.
 *
 * @param $item
 *   The taxonomy_menu item for the menu
 */
function _MY_MODULE_taxonomy_menu_update(&$item) {
  $term = taxonomy_term_load($item['tid']);
  if (isset($term->translations->data)) {
    $lang_default = language_default('language');
    if (isset($term->translations->data[$lang_default])) {
      $lang_original = $lang_default;
    }
    else {
      $lang_original = $term->translations->original;
    }

    $name = _MY_MODULE_field_value($term, 'name_field', $lang_original);
    if (! empty($name)) {
      $item['name'] = $name;
    }
    // I use the term summary for the menu item description
    $description = _MY_MODULE_field_value($term, 'description_field', $lang_original, 'text_summary_or_trimmed');
    if (! empty($description)) {
      $item['description'] = $description;
    }
    else {
      $item['description'] = $item['name'];
    }
    $item['language'] = LANGUAGE_NONE;

    $mlid = $item['mlid'];
    $i18n_name = array('menu', 'item', $mlid);
    $i18n_title = $i18n_name + array(3 => 'title');
    $i18n_desc = $i18n_name + array(3 => 'description');
    i18n_string_remove($i18n_title);
    i18n_string_remove($i18n_desc);

    foreach ($term->translations->data as $langcode => $data) {
      $translated_name = _MY_MODULE_field_value($term, 'name_field', $langcode);
      if (!empty($translated_name)) {
        i18n_string_translation_update($i18n_title, $translated_name, $langcode, $item['name']);
      }
      $translated_desc = _MY_MODULE_field_value($term, 'description_field', $langcode, 'text_summary_or_trimmed');
      if (empty($translated_desc) && !empty($translated_name)) {
        $translated_desc = $translated_name;
      }
      if (!empty($translated_desc)) {
        i18n_string_translation_update($i18n_desc, $translated_desc, $langcode, $item['description']);
      }
    }
  }
}

/**
 * Get the value of a field in a specified language and format.
 *
 * @param $term
 *   the taxonomy term.
 * @param $field_name
 *   the field name of the taxonomy term where to get the value.
 * @param $langcode
 *   the language code of the value to get.
 * @param $field_formatter
 *   the field formatter to use to get the value.
 * @param $settings
 *   settings for the formatter.
 *
 * @return the field value.
 */
function _MY_MODULE_field_value($term, $field_name, $langcode, $field_formatter = 'text_plain', $settings = array('trim_length' => '100')) {
  $display = array('label' => 'hidden', 'type' => $field_formatter, 'settings' => $settings);
  $field_item = field_get_items('taxonomy_term', $term, $field_name, $langcode);
  $field_value = field_view_value('taxonomy_term', $term, $field_name, $field_item[0], $display, $langcode);
  $field_rendered = ($field_formatter == 'text_plain') ? render($field_value) : strip_tags(render($field_value));
  if ($field_formatter == 'text_summary_or_trimmed' && empty($field_item[0]['summary'])) {
    //$field_rendered .= '...';
    // Finally I don't add description if there's no summary.
    $field_rendered = '';
  }
  return $field_rendered;
}

@nikosnikos this is great ! and this is similar to the approach I've taken in my sandbox. Would you have time to adapt your module for Taxonomy Menu 2.x version and provide a patch ? I think this would be straight forward and be a nice base for working on this farther.

Changing status to active as we have nothing but proof of concept here.

OK ! I like this idea ! I made a quick port of my module to taxonomy_menu 2.
I did some small test but it has to be more tested and I didn't add the unit tests.

What I did :
- I added a new submodule : tm_translation.
- I added a new hook_taxonomy_menu_presave() (mandatory to make tm_translation works).
- Added a lot of todos in tm_translation ;)

I think, I have to change the status to "needs work" ...

Thank you Niko ! This is a good start for anyone who wants to work on this.

I'm trying to use the patch proposed at #63 by Nikos on taxonomy menu v2.
But I'm not really successfull with it.

As explained in #60

Multilingual options for my menu is set to :
Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized.
My terms have been translated correctly with entity translation.

1) Under my vocabulary settings, I selected a "Menu Location" under a menu item which is language neutral.

I could see now my taxonomy terms in my menu, but none of them is translated.

2) And if the "Menu Location" chosen is a menu item with a defined language(with translation), no term are displayed under the translated menu iteml in non default language.

Is it the actual behavior of the patch or I'm missing something ?

PS: I resolved the first case. It seems to be related to a nice_menus issue, but it still doesn't display any terms in the second case only the parent menu item localized is displayed.

It is the actual behavior of the patch.

So the problem is only in the second case, nice menu have some i18n bugs.

for the second case did you try to see in the menu administration page ?
I tried to reproduce it and the terms appear under my menu item but there are not translated.

@nikos : I'm finally using the patch from #41 with TM 7.x-1.4 and entity_translation 7.x-1.0-beta2.
Everything works great.
If you want I can make further tests of your patch as soon as my actual project is finished.

The patch below integrates Taxonomy Menu with Entity Translation.

I did a theme level function to override the taxonomy menu items name and description with the correct language. I don't know if it is a good solution but for my purpose it works pretty well ^^. Hope can help someone.

I get some code from function taxonomy_menu_translated_menu_link_alter(&$item, $map) present al taxonomy_menu.module

function MY_THEME_translated_menu_link_alter(&$item, $map) {
  if (module_exists('entity_translation')) {
    // In case of localized terms, use term translation for menu title.
    if ($item['module'] == 'taxonomy_menu') {
      $t = _taxonomy_menu_get_item($item['mlid']);
      // Only translate when term exist (may per example occur with stray menu item)
      if ($t) {
        // Get the taxonomy term
        $term = taxonomy_term_load($t->tid);
        //Get the language
        global $language;
        $lang = $language->language;
        //check for the Title field (name_field)
        if (isset($term->name_field[$lang])) {
          $item['title'] = $item['link_title'] = $term->name_field[$lang][0]['value'];
        }
        //check for the Description field (description_field)
        if (isset($term->description_field[$lang])) {
          $item['options']['attributes']['title'] = $item['localized_options']['attributes']['title'] = $term->description_field[$lang][0]['value'];
        }
      }
    }
  }
}

#71 works but the corresponding menu needs to be set with multilingual settings "No multilingual options for menu items. Only the menu will be translatable. "

This is not very handy if you have other menu items (not part of the taxonomy menu) that require to be translated as usual

Sorry to gloam on this issue but the taxonomy_menu_translation-1665308-63.patch failed on a basic problem so was wondering if it is a fully viable patch by removing the offending hook declaration?

resubmitted for testing

The above patch works with settings as follows with one detected bug:

Applied the patch taxonomy_menu_translation-1665308-72.patch against Taxonomy Menu 7.x-2.0-alpha2.

Enabled new module: Taxonomy Menu - translation

Target Menu translation: Translate and Localize. Menu items with language will allow translations. Menu items without language will be localized.

Target taxonomy: Entity Translation default language:default language

Target menu item: Translated prior to building menu using Taxonomy Menu.

Taxonomy terms: all translated with a hierarchy.

Taxonomy term translation gets inserted into i18n Menu translation when one of the terms translations is selected in the taxonomy and re-saved.

BUG No 1: Hierarchy in taxonomy terms is not respected on the menu rebuild. But you can go into the menu edit and rearrange the terms as you want.

Major bug in the patch taxonomy_menu_translation-1665308-72.patch.

Error Message: Cannot use object of type stdClass as array.

Location: line 150 tm_translation.module

Assumed is because using object property as a variable and not testing it exists.

Changed code

  // delete operations in translate tab
  if ($form_id == 'i18n_string_translate_page_overview_form') {
    $item = $form['object']['#value']->get_object();
    if ($tid = _tm_translation_taxonomy_menu_tid($item['mlid'])) {
      foreach($form['languages']['#rows'] as $lang => $row) {
        $form['languages']['#rows'][$lang]['operations'] = '';
      }
    }
  }

To the following:

// delete operations in translate tab
    if ($form_id == 'i18n_string_translate_page_overview_form') {
        $item = $form['object']['#value']->get_object();
        if (property_exists('item', 'mlid')) {
            if ($tid = _tm_translation_taxonomy_menu_tid($item->mlid)) {
                foreach ($form['languages']['#rows'] as $lang => $row) {
                    $form['languages']['#rows'][$lang]['operations'] = '';
                }
            }
        }
    }

Tried to patch the patch

Resubmitting patched patch

Resubmitting patched patch again

Above patch only works when adding individual terms if you resave the taxonomy vocabulary the batch update for all the terms in the vocabulary does not add the i18n translations it only recreates the menu items without the translations.

Anyone know why this would be the case?

I've tried the patch from #80 above and it does recreates the menu items with translations in batch update. ("Rebuild the menu on submit" was checked)

Regarding Bug No 1 in #75, it seems to be due to term language need not be the same as the parent term language (e.g. LANGUAGE_NONE vs default language, due to different translation status). As a result, the plid cannot be retrieved using the langcode from child term. I tried to skip checking langcode condition in _taxonomy_menu_get_mlid() when calling from taxonomy_menu_term_get_plid($term, $langcode). It seems work, only when the vocabulary is using Entity Translation. Other vocabulary not using Entity Translation will probably be BROKEN. Any good idea?

here is a re-work of the last patches, that moves the i18n and entity integration directly in taxonomy.module, instead of having new (sub)module.

new patch, should fix the last "failed testing".

You fixed the exceptions, but there are 10 test failures (from taxonomy_menu.test), at the following line numbers:

• 340
• 505
• 577
• 774
• 777

let's try another patch

So this solve the watchdog warning about "Menu and taxonomy name mismatch:" ??

@killua99: the string "Menu and taxonomy name mismatch" appears in half a dozen open issues.

I think it was added by commit 333323c here: #1483010-1: [i18n] Localized stray item generate "array_flip() [function.array-flip]..." and "Trying to get property of non-object" errors...

I added a test and an output to the watchdog to help to remove bad menu entries:

...

I'm not sure though :/

ook ... meeh well so I have to see what's going on with the menu stuff etc ... :/

Thanks for the patch Vasike, it applied nicely but I now have an error when adding new terms to the taxonomy:

Fatal error: Cannot access empty property in /modules/field/field.attach.inc on line 325

The path alias is also not created for that term but the term is added to the taxonomy regardless, not sure if that's related.

Any idea why that could be happening?

#88: taxonomy_menu_translation-1665308-88.patch queued for re-testing.

In last patch all terms in menu have been shown and translated right but terms are showing in flatten hierarchy.

After applying the patch in #88 everything works great, but when I submit a term that doesn't have a description I get this notice:

Notice : Undefined offset: 0 dans _taxonomy_menu_term_field_value() (ligne 498 dans /Applications/MAMP/htdocs/woonportaal/sites/all/modules/patched/taxonomy_menu/taxonomy_menu.module).

This is my patch to solve that issue:

diff --git a/taxonomy_menu.module b/taxonomy_menu.module
index d898319..11adab0 100644
--- a/taxonomy_menu.module
+++ b/taxonomy_menu.module
@@ -493,7 +493,10 @@ function taxonomy_menu_entity_translation_delete($entity_type, $entity, $langcod
 function _taxonomy_menu_term_field_value($term, $field_name, $langcode, $field_formatter = 'text_plain', $settings = array('trim_length' => '100')) {
   $display = array('label' => 'hidden', 'type' => $field_formatter, 'settings' => $settings);
   $field_item = field_get_items('taxonomy_term', $term, $field_name, $langcode);
-  $field_value = field_view_value('taxonomy_term', $term, $field_name, $field_item[0], $display, $langcode);
+  $field_value = '';
+  if ($field_item) {
+    $field_value = field_view_value('taxonomy_term', $term, $field_name, $field_item[0], $display, $langcode);
+  }
   $field_rendered = ($field_formatter == 'text_plain') ? render($field_value) : strip_tags(render($field_value));
   return $field_rendered;
 }

Maybe this can be integrated in the patch for the i18n issue as well?

Confirming patch from #88 shows all terms in menu translated right but in flatten hierarchy.
Update: not Taxonomy menu bug https://drupal.org/node/2217227
Update 2: Confirming flatten hierarchy again.

xxxLOGIATxxx, did you have views disappearing on every edit until cleaning cache?

For me problem with flatten hierarchy disappeared after fixing views behavior by disabling field_group_views: https://drupal.org/node/2217227
Update: not really, that was another problem. Re-confirming flatten hierarchy.

Thank you for patch #88.
I just applied it manually and it works, after regenerating the menu I can finally see translated terms on non-source language versions of my pages.
I am not using hierarchy for this vocabulary though.
Taxonomy Menu is very useful but can't use it without multilingual integration.
I actually made version 1.4 of Taxonomy Menu module work on a multilingual site in the past but because I wasn't using Entity Translation on nodes, Content Translation instead. Really glad I can finally have it to work with Entity Translation... so thanks a lot for the hard work!

83: taxonomy_menu_translation-1665308-83.patch queued for re-testing.

Re-roll of #88

Which version of taxonomy can i apply the latest patch for? Cos i have tryed 1.4, 1.5, 1.x-dev but the patches(taxonomy_menu_translation-1665308-103.patch, taxonomy_menu_translation-1665308-88.patch) failed.

Mibfire, I have just applied the #88 patch to 7.x-2.0-alpha2 successfully. I believe you have to recreate all the terms or even the vocabulary in order to achieve the desired result. It seems to be a bit tricky.

paulocfaria, yes i have already patched the 2.0 alpha module, but i still struggling with this, cos i dont know the exact steps what i should follow.

What i have done so far is: I created a new test vocab, replaced term name with field, set taxonomy term on entity translation page(admin/config/regional/entity_translation), added a term named testhun and translated it to testeng and rebuilt the menu, but i have only one link in the menu and i dont know whether this is the desired result after these steps, cos the menu item wont be translated but only the page title.

Take a look at this: http://screencast.com/t/PXPCg7zIP37

mibfire, do you have "Translate and Localize" enabled on the menu (needs i18n_menu)?

jgullstr, not yet, i have set "No multilingual options for terms. Only the vocabulary will be translatable." Do i have to change to the "Translate and Localize"? What are the steps that i have to follow? thx

It seems like you have to enable localization on the vocabulary ("Localize"). Contrary to what I thought, menu localization is not required.

jgullstr, it is working now! THX!!! But the hard part of it will come just now. I have to do custom paths and make url alieses for these. For example:

My views path is termekek/[termid] so i have to create paths like this and url aliases for them like termekek/15-> /hu/termekek/szappan, if language of term is english i should have /en/products/soap.

How could i achieve this?

If your vocabulary has translations "products" and "szappen" then the pattern "[term:i18n-vocabulary]/[term:name_field]" should suffice. Remember to delete and bulk update your aliases.

mibfire, I struggled with this too. Here I leave a step by step walkthrough in case someone needs it:

1. Disable 18n_taxonomy (this might conflict). For taxonomy translation use only Entity translation. If you have also i18n_taxonomy enabled set your vocabulary to "No multilingual options for terms. Only the vocabulary will be translatable."
2. Go to admin/config/regional/i18n/select and Uncheck "Select taxonomy terms by language"
3. Go to admin/config/regional/language/configure:

• For the "User interface text language detection" enable URL (first position)
• For the "Content language detection" enable Interface (first) and Url (second position)

4. For the language switcher block enable the "Language switcher (Content)" block and disable "Language switcher (User interface text)" block.
5. Empty caches
6. Go to /admin/config/regional/entity_translation and set Taxonomy term as a translatable entity
7. Add a new menu:

• with translate and localize option.
• translate the menu name.

8. Configure the block region, make block translatable and translate the block.
9. Add a new vocabulary (there are no multilingual options) (If you have also i18n_taxonomy enabled set your vocabulary to "No multilingual options for terms. Only the vocabulary will be translatable.") and set the new menu as the taxonomy menu location.
10. On manage fields, replace name and description with field instances.
11. Go to /admin/config/regional/entity_translation:

• Set Taxonomy term as a translatable entity
• and set Current language as default language for your new vocabulary

12. Add a term.
13. When viewing the term you will see now the "translate" tab. Translate the term.
That's it. You will see now the menu in both languages.

jgullstr, in this case i cant use name of the vocabulary cos it is not products. Unfortunately there is no language specific pattern for taxonomies in url alies page(admin/config/search/path/patterns) like for nodes. There is a module Pathauto i18n Taxonomy that would solve this issue soon, but currently only bulk generated is provided so the "[term:i18n-vocabulary]/[term:name_field]" woudlnt work either.

I am just trying to implement the taxonomy menu api, more specifically the hook_taxonomy_menu_path, where i could generate aliases for terms.

paulocfaria, thx dude!!!:)

mibfire, you can achieve all that using just views.

I've just edit my previous comments. You can use i18n_taxonomy to translate the vocabulary name, but set your vocabulary to "No multilingual options for terms. Only the vocabulary will be translatable." For terms use only Entity translation.
Then, configure your patterns to [term:vocabulary:i18n-name]/[term:name] . Don't forget to delete and update aliases. You will have your aliases in both languages now, including the vocabulary name.

You may also enable the disabled Taxonomy term view to override default behaviour, for instance, to change the breadcrumb or use fields.
Read also:

• http://www.webbykat.com/2012/04/overriding-default-taxonomy-page-view-dr...
• https://www.drupal.org/node/394062#comment-1953504

paulocfaria, in my case i cant use name of the vocabulary cos it is called Category not Products.

Here is my solution:

/**
 * Implementation of hook_boot().
 * @see http://api.drupal.org/hook_boot
 */
function  potpourri_boot() {
	// Path that is used by Views for product page
	define('PRODUCTS_BASE_PATH', 'termekek');
}

/**
* Implementation of hook_taxonomy_menu_path.
*
* @return array
*  function name => Display Title
*  a list of the path options.
*/
function potpourri_taxonomy_menu_path() {
  $output = array('potpourri_termekek_menu_path' => t('Products'));

  return $output;
}

/**
* Callback for hook_taxonomy_menu_path
*/
function potpourri_termekek_menu_path($vid, $tid) {
  $base_path = PRODUCTS_BASE_PATH;
  // if tid = 0 then we are creating the vocab menu item format will be taxonomy/term/$tid+$tid+$tid....
  if ($tid == 0) {
    // get all of the terms for the vocab
    $vtids = _taxonomy_menu_get_terms($vid);
    $end = implode(' ', $vtids);
    $path = $base_path . "/$end";
  }
  else {
    $path = $base_path . '/' . $tid;
    if (variable_get(_taxonomy_menu_build_variable('display_decendants', $vid), FALSE)) {
      // Use 'all' at the end of the path
      if (variable_get(_taxonomy_menu_build_variable('end_all', $vid), FALSE)) {
        $path .= '/all';
      }
      else {
        // we wait to run this instead of during the if above
        // because we only wan to run it once.
        $terms = taxonomy_get_tree($vid, $tid);
        foreach ($terms as $term) {
          $tids[] = $term->tid;
        }
        if ($tids) {
          $end = implode(' ', $tids);
          $path .= ' ' . $end;
        }
      }
    }
  }

  _potpourri_alias_set($tid, $path, $base_path);


  return $path;
}

/**
 * Generate alias to a given term id with base_path
 *
 * @param	$tid
 *  Term ID
 * @param	$path
 *  System path
 */
function _potpourri_alias_set($tid, $path) {
  $parents = taxonomy_get_parents_all($tid);

	$term = $parents[0];

	// Get the language for the created or translated term
	$lang = pathauto_entity_language('taxonomy_term', $term);

	$alias = potpourri_transliteration_clean_filename(t('products', $args = array(), $options = array('langcode' => $lang)));

	$length = sizeof($parents);
  for($i = $length-1; $i > -1; $i--) {
		$term = $parents[$i];
		$wrapper = entity_metadata_wrapper('taxonomy_term', $term);
		if (isset($term->translations->data[$lang])) {
			$term_path = potpourri_transliteration_clean_filename($wrapper->language($lang)->name_field->value());
		}
		else {
			$term_path = potpourri_transliteration_clean_filename($wrapper->language($term->translations->original)->name_field->value());
		}
		$alias .= '/' . $term_path;
	}

	$ps = array(
		'source' => $path,
		'alias' => $alias,
		'language' => $lang
	);
	path_delete(array('source' => $path, 'language' => $lang));
	path_save($ps);
}

/**
 * Implements hook_entity_translation_delete().
 */
function potpourri_entity_translation_delete($entity_type, $entity, $langcode) {
  if ($entity_type == 'taxonomy_term') {
		$taxonomy_menu_path = potpourri_taxonomy_menu_path();
		$item_menu_path = variable_get(_taxonomy_menu_build_variable('path', $entity->vid), 0);
		if ($item_menu_path == key($taxonomy_menu_path)) {
			$base_path = PRODUCTS_BASE_PATH;
			$ps = array(
				'source' => $base_path . '/' . $entity->tid,
				'language' => $langcode
			);
			path_delete($ps);
		}
  }
}

/**
 * Modified version of transliteration_clean_filename transliterate module.
 *
 *
 * @see transliteration_clean_filename()
 */
function potpourri_transliteration_clean_filename($filename, $source_langcode = NULL) {
  if (is_array($filename)) {
    foreach ($filename as $key => $value) {
      $filename[$key] = potpourri_transliteration_clean_filename($value, $source_langcode);
    }
    return $filename;
  }
  $filename = transliteration_get($filename, '', $source_langcode);
  // Replace whitespace.
  $filename = str_replace(' ', '-', $filename);
  // Remove remaining unsafe characters.
  $filename = preg_replace('![^0-9A-Za-z_.-]!', '', $filename);
  // Force lowercase to prevent issues on case-insensitive file systems.
  if (variable_get('transliteration_file_lowercase', TRUE)) {
    $filename = strtolower($filename);
  }
  return $filename;
}

The only problem is i have to recreate the aliases for all languages if a term is translated cos i dont know current language in case of translated term.

Here you can check this: http://sanol.no-ip.org/en/products/universal, http://screencast.com/t/WcbOvtsaBqzQ

So the original path is termekek/212, and the alias is products/universal for on english one
On hungarian one it looks like: termekek/212 -> termekek/univerzalis-felitatok

The only problem is i have to recreate the aliases for all languages if a term is translated cos i dont know current language in case of translated term.

I have managed to find the solution to get the current language for the created or translated term with

$lang = pathauto_entity_language('taxonomy_term', $term);

and now the above code is working perfectly.

paulocfaria, overriding the default taxonomy url with views is a big bullshit. for example: "http://www.webbykat.com/comment/138#comment-138", i cant believe how stupid the people are.

How can you solve this using custom path view with taxonomy menu and url aliases without using the above code and overriding all taxonomy url with views(as i quoted with the link)?

Using the patches available in this thread as a starting point, I've created a submodule which can be found here. In order to hide missing translations, I needed the terms to be translated menu items, so that is also available as an option. Please try it out and share your views either in this thread or in the sandbox issue queue.
The code is rather hacky and is missing tests atm, but results look promising.

The module is written for the latest dev of taxonomy_menu-7.x-2.x (c2b6b87)

jgullstr, the submodule works well for me, thx

Does it mean submodule makes the same as patch #103 only with taxonomy_menu hooks?

Or should I use patch #103 and submodule?

The module should be used without patches.

a simple workaround modified from comment #71

function THEMENAME_translated_menu_link_alter(&$item, $map) {
  if (module_exists('entity_translation')) {
    if ($item['module'] == 'taxonomy_menu') {
      $item['hidden'] = false;
    }
  }
}

does that mean that the solution to integrating with entity translation is changing the logic of when an item is hidden ? if I understand well taxonomy_menu sets this hidden or no ?

I have this situation
Taxonomy with entity translation
Taxonomy localized
Field title replaced as field
Taxonomy node translated
Taxonomy with children

The problem was that tm table saved my node as LANGUAGE_NONE but term had language associated, so $language_code in function taxonomy_menu_menu_link_prepare patched, the $term passed as param did not have the translations loaded, so it looked for the 'es' code in tm table and it could not found it therefore it did not found any parents so menu tree was not build.

I had to reload the full term before checking for translations and that way worked perfect. So the repatch in function taxonomy_menu_menu_link_prepare is:

$term_description = $term->description;
// Get the right langcodes for terms with entity translation enabled.
+ $term = taxonomy_term_load($term->tid); // Added this line
if (module_exists('entity_translation') && isset($term->translations->data)) {

Maybe it's useful for somebody

Eugeni

comment #112 paulocfactoria: nice tutorial for multilingual taxonomy menu with the use of Entity translation! Thanks to you and mibfire.
To complete your tutorial I would like to add: if the translation in other languages still doesn´t appear in your menu and all the conditions are met, it helped me menu items->neutral language

I have an issue with the Patch rerolled in comment #103. This Patch uses the Function language_default() in the prepare function to decide which language should be used for menu-name as Source. In my case the source Language is English but the default Language of the site (which is returned by language_default) is german. Is there any reason not to use the value set in $entity->translations->original ( which is the source language of the Term. English in my case )?

// Well ignore my comment
New Taxonomy Term will be created in language_default() so this is not the issue..

Update:

I think this piece of code should be added after line 180 in the prepare function

if (module_exists('i18n_string') && i18n_string_source_language() !== $lang_default) {
      $lang_default = i18n_string_source_language();
    }

I have a submodule that's close to finished incl. tests here. There's still an issue with duplicate menu items that I haven't figured out (can be seen from the test output). I'd appreciate if someone could take a peek, as I wont have time to work any more on it in a foreseeable future.

Attached is the module. The functionality is now complete including tests. Some of its content shuold probably be better off living in its own file. Many parts of it could be further optimized, but that would require modifying taxonomy_menu, so I'll leave it like this for now.

New attempt

I've got all day, just keep failing me..

PHP Fatal error: Class 'Drupali18nTestCase' not found in /var/lib/drupaltestbot/sites/default/files/checkout/sites/default/modules/taxonomy_menu/taxonomy_menu_i18n/tests/taxonomy_menu_i18n.test on line 11

This class is part of the i18n suite, which is a dependency of the module. Shouldn't Drupals class registry be able to recognize this class, as its containing file is declared in i18n.info? Is there any way to know which module versions are used on the test server? (Tests execute fine locally)

If you want to localize menu items instead of translation (it's different modes) you need following snippet to generate right (none) language:

/**
 * Change language for menu items generated from terms of localized vocabularies
 */
function module_taxonomy_menu_insert(&$term) {
  if (i18n_taxonomy_vocabulary_mode($term['vid'], I18N_MODE_LOCALIZE) &&
    isset($term["language"])) $term["language"] = LANGUAGE_NONE;
}

/**
 * Change language for menu items updated from terms of localized vocabularies
 */
function module_taxonomy_menu_update(&$term) {
  if (i18n_taxonomy_vocabulary_mode($term['vid'], I18N_MODE_LOCALIZE) &&
    isset($term["language"])) $term["language"] = LANGUAGE_NONE;
}

Added test dependencies to module .info

Cannot get testbot to run with Drupali18nTestCase as parent class. Changed parent class from to DrupalWebTestCase, copied used helpers from Drupali18nTestCase.

Added locale dependency. Sorry for the spam, I'm trying to wrap my head around how the testbot works.

I changed dependencies in my .info file, but the wrong dependencies are still being loaded on test Dependencies only get built when the new dev release is rolled, every 12 hours. So if you change dependencies, it won't be reflected until the new dev tarball is rolled.

https://www.drupal.org/project/testbot

I guess this means that the tests wont ever pass, as the added dependencies are not available on the testbot? In that case, the patch needs to be tested and commited manually before the testbot can be properly ran. Drupali18nTestCase should be available then, too, hence #138 is the cleanest patch (excluding others from display).

@jgullstr nice work, this is just what I'm needing right now.

However, it "doesn't work" (TM)

1. Upgraded to the latest dev of taxonomy_menu
2. Applied your patch cleanly
3. Enabled the new taxonomy_menu_i18n module provided by your patch
4. Edited the vocabulary and saved to rebuild the menu
5. Menu tree is not present anywhere in the system

I have 2 languages enabled apart from English, and a vocabulary which is localized (not translated).

Any hint? Thank you very much in advance.

@mariano.barcia, make sure you're using the 2.x branch of taxonomy menu. What do you mean "Menu tree is not present anywhere in the system"? Is no menu at all generated?

Here are the configuration steps:

• Enable the module.
• Set translation mode to "Translate and Localize" for the menu you use with taxonomy_menu.
• In the vocabulary's Taxonomy menu settings, set your preferred translation choice (Fieldset "Translation options"):
  • Disabled. Menu items will not be translated.
  • Localize. Menu items will be localized using string translation.
  • Translate. Term translations will be created as translated menu items. Missing translations will not be available in the menu.
• Check "Rebuild the menu on submit" and save the vocabulary
• The menu should be translated.

@jgullstr thank you for your prompt reply, I have good news.

Turns out it was a problem in my environment: all the /taxonomy/term/* paths were throwing a 404 because of a contextual filter validation. Messing with a feature this filter went berserk without me noticing the problem.

All is good now, I will keep you updated, thanks again.

Using the patch in #1665308-138: [i18n] Integrate Taxonomy Menu with i18n_menu and entity_translation., I get the following error:

Error: Call to undefined function taxonomy_menu_variable_get() (line 66 of /sites/all/modules/taxonomy_menu/taxonomy_menu_i18n/taxonomy_menu_i18n.module).

I use Entity Translation for the vocabularies. The error occurs when I want to edit a vocabulary.

If I disable taxonomy_menu_i18n, I can access back the vocabulary edit page (but indeed there is no translated menu items ;-) )

@B-Prod, are you using the 7.x-2.x branch of Taxonomy menu?

I use taxonomy_menu 7.x-2.0-alpha2 with patch #103. All work is good, but have:
Notice: Undefined offset: 0 in _taxonomy_menu_term_field_value() (line 504 in /www/sites/all/modules/contrib/taxonomy_menu/taxonomy_menu.module) when I save translated taxonomy term. What have I missed?

Hello,

I need some help, please. In this moment I have multi-language on my website. I have managed to put links on the menu using taxonomy menu. How do I get translated in other languages?

I have a Dropdown in English, but in others languages don't appear

I need to apply a patch that are on this page?

I need help urgently. Thanks.

See my comment at #112.

paulocfaria,

I used your the tips and it works.

Obrigado. :)

@paulocfaria

I did what you described in #112. Unfortunately my menu is still available only in default language.
I had to enable i18n_select in order to do point 2.
I had to enable i18n_block to do point 8.
I had to enable title to do point 10.
I tried with and without i18n_taxonomy....

Is there anything else that should be done?
Should I apply any of the patches above?
Should I use 7.2 version of the taxonomy_menu?

Thanks

Here is the patch from comment #41. I needed this functionality for a project and needed sth asap. The only thing that I added is assigning the default language to the menu links when they are created, to avoid having them assigned a LANGUAGE_NONE value.

Submitting again due to typo.

@tterranigma the last patchs is empty, it's 0 bytes file

Clumsy me.. Hope I get it right this time!

@tterranigma Thanks for this patch, it worked for me!

For testbot

Just a note on this which may or may not be correct behaviour ... if a term does not have a translation, it won't show up in the menu. But fallback settings would normally mean that term would be viewable in the untranslated language, just in its original language. So I suggest that taxonomy menu ought to do similar, so an untranslated term should still get a menu item, showing the original language content?

But if all your content is translated, or if you wanted that behaviour (despite the inconsistency with how the fallback is applied elsewhere), then this patch works fine AFAIK :-)

I'm continuing on top of #158 (I realise there is also work for the 7.x-2.x branch in this ticket, perhaps a spin-off ticket is needed really for 7.x-1.x?), the attached patch resolves two things:

1) The entity translation form language is respected when saving a menu link, as otherwise the menu link in the original translation language gets renamed rather than the language of the translation being edited.
2) The patch is made against the unpackaged version of 7.x-1.5 (so it can be applied with git, which it couldn't before because of the extra bits added to the .info file)

I tested the patch at #163 and it's working fine.

I have to rebuild the menu to see the changes but I believe that's default behaviour.

I tried patch #163 on versions 7.x-1.5, 7.x-1.x-dev, and 7.x-2.0-alpha2 but all failed with the messages below. What I am doing wrong? For which versions the patch is made? (to patch i used the command "patch < taxonomy_menu-1665308-entity_translation_i18n-163.patch"):

7.x-1.5

patching file taxonomy_menu.database.inc
patching file taxonomy_menu.info
Hunk #1 FAILED at 7.
1 out of 1 hunk FAILED -- saving rejects to file taxonomy_menu.info.rej
patching file taxonomy_menu.install
patching file taxonomy_menu.module
Hunk #3 succeeded at 639 (offset -1 lines).
Hunk #4 succeeded at 671 (offset -1 lines).
Hunk #5 succeeded at 694 (offset -1 lines).
Hunk #6 succeeded at 722 (offset -1 lines).
Hunk #7 succeeded at 873 (offset -1 lines).
patching file taxonomy_menu.test
patching file taxonomy_menu.test
patching file taxonomy_menu_tests.info
patching file taxonomy_menu_tests.module

7.x-1.x-dev

patching file taxonomy_menu.database.inc
patching file taxonomy_menu.info
Hunk #1 FAILED at 7.
1 out of 1 hunk FAILED -- saving rejects to file taxonomy_menu.info.rej
patching file taxonomy_menu.install
patching file taxonomy_menu.module
patching file taxonomy_menu.test
patching file taxonomy_menu.test
patching file taxonomy_menu_tests.info
patching file taxonomy_menu_tests.module

7.x-2.0-alpha2

patching file taxonomy_menu.database.inc
Hunk #1 FAILED at 13.
Hunk #2 FAILED at 29.
Hunk #3 FAILED at 47.
Hunk #4 FAILED at 69.
4 out of 4 hunks FAILED -- saving rejects to file taxonomy_menu.database.inc.rej
patching file taxonomy_menu.info
Hunk #1 FAILED at 7.
1 out of 1 hunk FAILED -- saving rejects to file taxonomy_menu.info.rej
patching file taxonomy_menu.install
Hunk #1 FAILED at 61.
Hunk #2 succeeded at 126 with fuzz 2 (offset 17 lines).
1 out of 2 hunks FAILED -- saving rejects to file taxonomy_menu.install.rej
patching file taxonomy_menu.module
Hunk #1 FAILED at 297.
Hunk #2 FAILED at 440.
Hunk #3 FAILED at 640.
Hunk #4 FAILED at 672.
Hunk #5 FAILED at 695.
Hunk #6 FAILED at 723.
Hunk #7 FAILED at 874.
7 out of 7 hunks FAILED -- saving rejects to file taxonomy_menu.module.rej
The next patch would delete the file taxonomy_menu.test

I applied the patch at #163 against version 1.5.

The errors are in the info file. I believe I fixed the info file manually.

Thank you, @bramvandenbulcke. Since I am not that experienced, could you give some information how to fix the errors in the info file manually?

@adam1: I used an editor like Sublime Text and changed taxonomy_menu.info just like the default file in version 7.x-1.5.

Could it be that you're applying the patch on a release package? When a module is packaged, the .info file is edited with some metadata. That could explain patches not applying. You have to clone the repository or manually apply the diff for the .info file.

@bramvandenbulcke @a.ross thank you, I got it, was applying patch to release package.

There's an important setting ommited in this patch. If you have multiple taxonomies and not all of them are translated using entity translation, then the ones that don't use it will have all links's language set to none in their respective generated menus. It's because of this line in taxonomy_menu.module:

$language = LANGUAGE_NONE;
  if(isset($taxonomy_entity->translations) && isset($taxonomy_entity->translations->original)) {
    $language = $taxonomy_entity->translations->original;
  }
  if(!module_exists('i18n_menu') || !i18n_menu_mode($item['menu_name'], I18N_MODE_TRANSLATE)) {
    $language = LANGUAGE_NONE;
  }

As you can see it sets language to None to all links not translated using entity translation. An else statement should be added to last if statement in case taxonomy terms are translated using i18n module:

  if(!module_exists('i18n_menu') || !i18n_menu_mode($item['menu_name'], I18N_MODE_TRANSLATE)) {
    $language = LANGUAGE_NONE;
  }else{
     $language =  $taxonomy_entity -> language;
   }

Hi,
I recreated the patch for 7.x-1.5

I added the changes from the last comment, I also treated the deletion of taxonomy translation.

Use code from #172.
I have problem with creating menu items duplicates .

Steps to reproduce:
1. Create taxonomy menu from vocab with 2 lang and hierarchy (each term has own language)
2. Edit any term and save.
3. New menu item created instead of changing the existing one

If i click to rebuild menu after that - duplicates disappear.

I would like to use patch from #172 with all new version 7.x-1.6.
It would be awesome, if someone tech-savvy could recreate patch for 7.x-1.6!

Hi, I would really appreciate if someone could create a patch for 1.6. !

My translations don´t work anymore after update taxonomy_menu to 7.x-1.6. (drupal core: 7.63)
Re-activating the former version from backup didn´t help and the patches above - strange - dont´match (any more ?)

I described my issue here.

Any help out there?

Vincent jo

Hi,
really no one else is missing translations from vocabularies in the taxonomy-menus? (after update to v.7.1.6)

I have a taxonomy driven site, bilingual with entity translation. The taxonomy menus are the main navigation through the site.
The menus (displaying the translated items) worked before with these patches provided above.

After core-update to 7.63 and module update to v.1.6 along with it, the issues started:

Main issue: No translated items.

There are other problems in behaviour of the module, but I want to keep this support request focused on this.

The site is in production since over two years ... I need to fix it!

Somebody out there who can help?

regards
Vincent Jo

Hi,

I have the same issues as @liland in #173, but in my case I get repeated menu items on node save. This content type has a term reference field whose vocabulary is one associated with the menu that is using taxonomy_menu.

I have this issue if I have the option "show number of items" enabled in taxonomy settings. If I disable this feature, I haven't got duplicates in menu when saving the node or taxonomy term.

Any ideas? Does anyone else have this issue?

Thanks in advance!!

Here is a patch that will apply cleanly to v7.x-1.6+1-dev of taxonomy_menu module.

This patch assumes you are using the termstatus module v7.x-1.2+3-dev to control if a menu item should be hidden or not. Please make sure you install and configure termstatus before applying this patch.

Thank you for your contributions.
Drupal 7 is no longer supported.
Closing this issue as outdated.

Thank you for your contributions.
Drupal 7 is no longer supported.
Closing this issue as outdated.