Integrate with i18n (II) - Solution for "Per language terms"

subscribe

subscribe

subscribe

Hi,

I found that, when using a vocabulary with "Per language terms", the language attribute wasn't being added to the menu items, so they were all displaying. I've attached a patch with a two-line change that seemed to work OK for me - the menu items are assigned a language and marked as 'customized' and only terms for the active language show up in the menu.

Hi,

I don't understand, you say you made a two-line change, when I open your patch file, I see indeed two + in front of some lines. Does that mean that I can forget about the other lines???

Strange because your line in the patch that says:
$link['options']['alter'] = TRUE;

has no + in front of it, but I can't find it in the original file either??? The same goes for the preceding line which states:
if (module_exists('i18nmenu')) {

So what has to be altered in order to get it working... I am very interested, but I don't seem to get it to work...

Hi,

The file is in patch format generated by CVS - you can read more about patches here: http://drupal.org/patch/apply - but you need to install CVS on your computer to be able to use it as-is.

But, basically, yes - any lines prefixed with a minus '-' are automatically removed by the patch process and lines prefixed with a plus '+' are added, but for a really simple patch like that one, a manual update is feasible (just copy those lines into place and strip the + signs). The other lines contain meta data about where to apply the patch - which file, which function and the line number.

To be honest, I think I created that patch against the 6.x-2.4-beta1 release, rather than the latest dev release as I should have done, but I've just taken a look at the dev release and the patch should still apply to 'taxonomy_menu.module' at around line 495.

All the patch does is make sure that the language for the term is included in the item sent to the menu system to create a new menu item. If the language information is included, the i18n module takes care of adding it to the menu item.

Hope that helps...

patching worked now! thankx, but my problems aren't solved. Still the two languages show up under the menu.

Did you only apply this patch, or also the patches from the other thread [http://drupal.org/node/316632#comment-1441076]?

No, I didn't apply that other patch although, looking at it, it looks like it also passes in the $language attribute. That other patch is designed to work with translatable taxonomy terms, while mine was a quick fix for Vocabularies with 'per language terms'. Hopefully solutions for both type will make it in to the module.

You might need to rebuild the taxonomy menu, on the Vocabulary edit page, for the changes to show up.

I did a rebuild of the menu, but still the same issue occurs.

Have you tried clearing the caches on the 'site configuration > performance' page?

It's possible something's conflicting with both patches applied. This is working for me with a patched 6.x-2.4-beta1 version of Taxonomy Menu, and the 6.x-1.1 release of i18n.

- cleared the caches
- rebuild the menus

and still both languages are being displayed and it also displays this error:

Menu and taxonomy name mismatch : Zuid Amerika (0) != Zuid Amerika
Menu and taxonomy name mismatch : Argentinië (2) != Argentinië
Menu and taxonomy name mismatch : Chili (1) != Chili
Menu and taxonomy name mismatch : Uruguay (1) != Uruguay

That error has been mentioned on the other Taxonomy Menu/i18n issue #316632: Integrate with I18n (I) - "Localize terms" and also on this one #421526: Taxonomy menu, Views apparantly when the 'item for vocabulary' is checked - although I also have that selected and am not seeing that error.

Have you tried applying only the patch from this issue to a clean copy of the module?

@maikling @matkeane

It's a similar issue as #421526: Taxonomy menu, Views . mailking has "Show number of items" selected and it changes the menu text to " term name (number of nodes)" It's trying to translate the whole whole things instead just the term.

By the way. Great work getting this working. Once it's stable, it will be part of 2.4-beta2 or 2.5.

I've applied the patch to a clean copy of the module.
'item for vocubulary' is now uncecked
as is 'display number of nodes'

errors have disappeard, but still two both language items appear....

I have the following options checked:

- Syncronise changes to this vocabulary
- Hide Empty Terms
- Auto Expand Menu Item

What can I be doing wrong?

OK, well glad we know where that other error is coming from. I've just checked the settings on the Vocab I'm using this for:

Use Term Name - Yes
Syncronise changes to this vocabulary - Yes
Display Number of Nodes - No
Hide Empty Terms - No
Item for Vocabulary - Yes
Auto Expand Menu Item - Yes
Display Descendants - No
Use 'all' at the end of URL - No

I'm now using a custom path for this vocab, although I originally used the default path, and it rebuilt successfully, so I'm not sure why you're seeing the problem - sorry!

It's quite possible I've missed something with my patch - when I saw that the i18n module was expecting the language attribute, but Taxonomy Menu wasn't supplying it, I just quickly added those lines to make sure it was passed along with the new menu item, and it worked.

Can you check in the database? In the 'menu_links' table, the 'options' column should include a 'langcode' attribute if things are working correctly.

my database show nothing at the attribute for the options of the menu_links. It says:

options text utf8_general_ci Yes NULL

Hi,

No, I meant in the actual data itself - if you look at the 'options' column of the menu_links table you should see a serialized set of attributes. If the patch is working properly, you should see something like:

a:3:{s:10:"attributes";a:1:{s:5:"title";s:9:"Argentina";}s:5:"alter";b:1;s:8:"langcode";s:2:"es";}

Note the "langcode" attribute in there (set to "es" in this case). Before applying the patch, the langcode wasn't being set by the 18n module, and so the menu module couldn't determine which menu items should be displayed.

Okay, thanks for pointing that out to me. I see this in the database, so I guess that works... Now why doesn't it work the way I want? It still shows both languages under the same menu item.???

4 a:2:{s:10:"attributes";a:1:{s:5:"title";s:0:"";}s:8:"langcode";s:2:"en";}
3 a:2:{s:10:"attributes";a:1:{s:5:"title";s:0:"";}s:8:"langcode";s:2:"nl";}

2 a:3:{s:10:"attributes";a:1:{s:5:"title";s:13:"South America";}s:5:"alter";b:1;s:8:"langcode";s:2:"en";}

1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:4:"Asia";}s:5:"alter";b:1;s:8:"langcode";s:2:"en";}
1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:4:"Iran";}s:5:"alter";b:1;s:8:"langcode";s:2:"en";}
1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:4:"Iran";}s:5:"alter";b:1;s:8:"langcode";s:2:"nl";}
1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:4:"Laos";}s:5:"alter";b:1;s:8:"langcode";s:2:"en";}
1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:4:"Laos";}s:5:"alter";b:1;s:8:"langcode";s:2:"nl";}
1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:4:"Peru";}s:5:"alter";b:1;s:8:"langcode";s:2:"en";}

I'm just coming in with the same issue, and what I've found (before applying the patch) was that each menu item (or at least the root), in the menu admin page, needs to be set to the language. For example, your root item in English needs to be an English menu item, and your root item in Dutch needs to be set to Dutch. Again, that's in the menu items, not the taxonomy or term admin page.

The problem is that the taxonomy menu module does not take into account the term's language when writing the menu item into the database, so the language for the menu gets overwritten when a change is made to the taxonomy term when "Synchronize changes to this vocabulary" is set to "Yes".

Looking forward to testing the patch.

EDIT : it seems upgrading to 2.x.dev has solved the issue for me, so I won't be applying the patch.

Hi,

Hate to say this, but I'm not sure... The langcode attribute is being applied OK to your menu items. Is the menu showing as customized ('customized' column is set to '1' in menu_links)?

Some more info about my setup: I created a new menu to contain the links generated by Taxonomy Menu as well as some other manually-added menu links, so the Taxonomy Menu tree is being added to an existing menu, and the top-level item for the Vocabulary is showing as 'all-languages' (i.e. On the Vocabulary setting page, there is no language defined for the vocabulary, only the terms).

steps I made:

- create a new vocabulary ABC, with the following options:
- Translation mode: Per language terms
- Language: none
- Primary links
- Menu Path Type: Default
- Syncronise changes to this vocabulary
- Item for Vocabulary
- Auto Expand Menu Item

- testing shows, this item shows in both languages

- Now I add two terms:
- Cooking (English)
- Koken (Dutch)

- I did not make any translations yet, but testing shows, that both items show up in both languages under the ABC menu-item. And this is not how it is suppose to work is it?

- I rebuild this menu in the taxonomy_menu options
- I flushed all the caches

- It still stay the same.

In the database under 'menu_links' under options, I find these references:
for the new vocabulary ABC:
1 a:2:{s:10:"attributes";a:1:{s:5:"title";s:21:"testing taxonomy menu";}s:5:"alter";b:1;}

and for the terms Cooking (English) and Koken (Dutch):
2 a:3:{s:10:"attributes";a:1:{s:5:"title";s:13:"kook recepten";}s:5:"alter";b:1;s:8:"langcode";s:2:"nl";}
1 a:3:{s:10:"attributes";a:1:{s:5:"title";s:16:"cooking recipies";}s:5:"alter";b:1;s:8:"langcode";s:2:"en";}

When I look under the menu items (admin/build/menu) these terms have the right language either Dutch or English.

What am I doing wrong here?

Sorry about the delay responding to this...

I just went through your steps to recreate the problem, and I'm seeing the same behaviour as you - all terms show regardless of the language.

However, if I change the Vocabulary settings to move it under another menu (i.e. not Primary Links or Navigation) it works as expected, and only the terms with the current active language show up (Hurrah!).

Where things get strange is that if I then move the Vocabulary back under the Navigation menu, it still works as expected! I need to look into this more, to see what isn't being set properly when the menu is first created, but at least there's a kludgy workaround!

I'm stil seeing a problem when adding a new term in another language as it initially shows up alongside the correct language term - but forcing a rebuild sorts that out.

Aha... I must try that...

Hmmmm...

I don't seem to understand what you mean by "to move it under another menu". I am using the Marinelli theme and the Primary links. I created a new menu, but it doesn't show itself. How do I accomplish this?

So I don't "see" your solution yet.

When I first added the terms, the Vocab was assigned to the Navigation menu, I then went back and changed this to another existing menu I'd created (called 'Explore' in this case). You need to make sure the new menu block is displayed in a region somewhere, but if there are no menu items, it might not show anyway.

Once I did that, only the terms in the relevant language showed, but I suspect this is because moving the Taxonomy Menu to a different menu tree forced a rebuild. I'll have to look and see if it's possible to force a rebuild (or a partial one) automatically when a new term is added with a language.

subscribe

This is part of the 6.x-2.4-beta2 release. These needs to be in RTBC before I can create the stable release.

I think that this really needs to be set as 'needs work' for the moment.

The patch works as expected for existing Taxonomy terms where a language is defined (the menu is successfully created with only the current language terms showing) but, when new terms are added, they are displayed in the current menu regardless of the language setting. Although forcing a rebuild of the menu resolves the problem, I can see situations where users may have permission to add new terms, but not have sufficient permission to access the Vocabulary settings page to force a rebuild of the menu (and ideally they wouldn't have to).

I suspect that we need to add something to the taxonomy_menu_taxonomy() function so that new terms are properly saved, but I'm not sure what yet (and I'm open to any advice from those that understand the inner workings of Taxonomy Menu better than me)!

subscribing