Not specifically an i10n client problem, but I think the question is best answered here:

Because my themes use the 'hardcoded' primary and secondary menus, not the blocks, in my settings.php I have:

$conf['i18n_variables'] = array(
// Site name, slogan, mission, etc..
'site_name',
'site_slogan',
'site_mission',
'site_footer',
'anonymous',
// Different front page for each language
'site_frontpage',
// Primary and secondary links
'menu_primary_menu',
'menu_secondary_menu',
'menu_primary_links_source',
'menu_secondary_links_source',
// Contact form information
'contact_form_information',
);

In i18n I have block and menu translation enabled.

The core 'Translate Interface' & i10n client seem to be working ok for the built-in drupal strings.

1)
So why is it that when I create a primary-menu menu item called 'prospectus', that it does not appear to be translatable either in i10n or the core 'translate interface'?

Further, if I create the a similar menu item in the core Navigation menu, it isn't translatable either!

Even further, I created a menu with the title 'prospectus', enabled it in the block section, and *that* isn't translatable either!

I've just about given up with attempting to use multilanguage, because none of the strings I actually want to translate are ever translatable. It is so frustrating to have 'prospectus' right there on the damn page in several places, yet none of the provided tools can 'see' it.

2)
At this point, I'm so confused with the language system that I don't even know if I'm required to translate these menu-related strings, or whether I should be just duplicating every link in every language? Maybe this is why none of the menu strings are translatable - we're not supposed to (even though the core strings like 'forum' are translated by the installed language packs)?

Any help would be appreciated.
BTW, I've already read the docs and the forum threads on the subject. Please don't refer me to them.

Cheers.

Comments

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Project: Localization client » Internationalization
Version: 6.x-1.6 » 6.x-1.x-dev

The way you set up the variables, the menu ids themselves can be different per language. So you can have complete different mens (primary and secondary) set up per language. This is a way to translate menus, and some people prefer this way. Basically, these settings just store the menu root ids, and do not make you translate your menu items. If you want to translate menu items, feel free to use the i18nstrings and i18nmenu modules, which do that.

This issue belongs to the i18n module queue.

-Anti-’s picture

-Anti- commented

Thanks for your reply.

> So you can have complete different mens (primary and secondary) set up per language.
> This is a way to translate menus, and some people prefer this way.

It seems to be the only way! The translation of 'menu-block titles' and 'menu items' doesn't work at all, so the only real option seems to be have separate menus for everything and to set them to a specific language.

For instance, I can't have a menu set to 'language neutral', and then have an english and spanish title for it - the title is not translatable. Even if the title could be translated, then inside that menu, I could not have a menu item called 'download' with 'descargas' as its translation, because the menu-items are not translatable.

Everything I've reads suggests 'menu-block titles' and 'menu-items' should be translatable, but they are not.
The 'Translate Interface' doesn't list them, and neither does the 'i10n client'.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

The way you set up only allows swapping menus per language, those are site settings. If you'd use the i18nmenu module, you'd be able to translate per menu item.

-Anti-’s picture

-Anti- commented

> If you'd use the i18nmenu module, you'd be able to translate per menu item.

I *do* have the menu and block translation enabled, but the menu-titles and menu-items I create do not become available for translation, either in the core 'Translate Interface' feature or the 'i10n client' module.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

This may have been fixed by #339057: Performance: menu translations continuously updated. Please try the 6.x dev version of i18nmenu.

-Anti-’s picture

-Anti- commented
Status: Active » Closed (fixed)

Thanks for the heads-up.

But I'm going to forget about translating strings; it doesn't seem stable enough, and is over-complicated anyway.

i10n module is great, but I have a host which doesn't allow the jquery.cookie.js file (needs to be renamed jquery_cookie.js), and doing so throws up errors in the backend (eg. update notification breaks) - no good for a production site.

So as gabór suggested, I'm just going to swap menus per language, and duplicate all menus.
I suppose I just have to leave my primary and secondary horizontal menu bar untranslated though.

Very disappointing. I hope multi-language manages to eventually be solid part of drupal core rather than something which had to be tacked on as an afterthought. Maybe something to look forward to in D8 or D9?

Cheers.

rondev’s picture

rondev commented

I just noticed that to make the menu terms translated, you have to edit the term (in primary menu per example) and just do apply (check that all language is selected). That should initiate something. With terms you didn't do that, that doesn't work.

That makes several months that I tried to make it run. I done it with a new installed site not with an upgraded site. I have nothing declared in $conf['i18n_variables']

I will continue my tests to see if all is OK before upgrading (taxonomy_menu and i18n, ...)

-Anti-’s picture

-Anti- commented

You got it to work?
Could you give a step-by-step instruction of how to translate one term?

---
Just to add to my post above, I said:

> I suppose I just have to leave my primary and secondary horizontal menu bar untranslated though

However, I got multilingual primary/secondary menus to work.

· I created separate primary menus: menubar-en and menubar-es
· Add the i18n variables in settings.php (menu_primary_links_source & menu_secondary_links_source)
· now in admin -> building -> menu -> settings choose 'menu-en' for when english is selected
· swap to spanish using the language switcher, and choose 'menu-es' for when spanish is selected
· populate menu-en with english links pointing to english nodes
· populate menu-es with spanish links pointing to spanish nodes

I thought this would only work for menus in BLOCKS, but it also works for the hardcoded primary/secondary menus (which most themes use for a horizontal bar). I would have preferred one menu populated with multilingual links, but two separate menus works ok; it just complicates the process for users who are allowed to add links to menus when they create content - the user must pay attention to which language the node is in and add it to the correct menu.

rondev’s picture

rondev commented

My configuration:

Modules actually used (all updated on the 21/01/2009):
------------------------------------------------------
Administration
Administration menu 6.x-1.2
Core - optional
Color 6.9
Comment 6.9
Content translation 6.9
Database logging 6.9
Help 6.9
Locale 6.9
Menu 6.9
Taxonomy 6.9
Update status 6.9
Core - required
Block 6.9
Filter 6.9
Node 6.9
System 6.9
User 6.9
Multilanguage
Block translation 6.x-1.x-dev
Internationalization 6.x-1.x-dev
Menu translation 6.x-1.x-dev
String translation 6.x-1.x-dev

Language Negotiation:
---------------------
Path prefix only : works
Path prefix with language fallback : do not work

setting.php
-----------
Nothing added (nothing with $conf['i18n_variables'])
$conf['i18n_variables'] will allow different menu for different language that is what -Anti- described
I will use $conf['i18n_variables'] later for things like 'site_name','site_slogan','site_mission','site_footer'

Menu
----
Add you menu items with Language set to "All Language"

Remarks
-------
I noticed that if you had "Language Negotiation" set to "Path prefix with language fallback" and set it to "Path prefix only", you have to edit each menu items and do Apply.
That works for me for Primary links. I have not tested other features I have in my 5.15 site with this configuration. Hope it will simply work to upgrade it.
I hope I forgot nothing. I would be pleased to know if it works for other people with the same parameters then I will know what is the minimal parameters.

-Anti-’s picture

-Anti- commented

> Language Negotiation:
> ---------------------
> Path prefix only : works
> Path prefix with language fallback : do not work

> Menu
> ----
> Add your menu items with Language set to "All Language"

I realise now that you are setting the menu and items to 'language neutral', and then translating the english links using the 'translate interface' search. When I search, it does not find *any* of the 'menu titles', 'menu items' or 'block titles' that I've created, perhaps because I have 'language fallback' enabled. It's good that you've got this working. I'll try it out when I have an appropriate test site set-up. The disadvantage of this method is that the link points to the same page even though the language of it changes.

The feature I was hoping to hear about was the 'menu translation' module that comes with i18n. When enabled, a language dropdown appears in the menu item pages. For instance, we should apparently be able to have:

· a menu item called 'home' linking to node/1 with the language set to english
· a menu item called 'accueil' linking to node/2 with the language set to french
· a menu item called 'principal' linking to node/3 with the language set to spanish
... all in the same menu

It would be great to get this to work, instead of using a menu for each language, or using the 'translate interface'.

EDIT:
At first sight, the 'menu translation' and 'block translation' modules seem to be fixed in i18n 1.0
I am now getting messages like: 'Created string item:462:title for text group menu: [item]'
And the menu items are found by the 'translate interface' search.
Thanks to Jose and all who worked on i18n in the last few weeks to fix these issues.

I haven't tried the 'menu translation' language selector dropdown yet. Hopefully it will be fixed too.

rondev’s picture

rondev commented

>· a menu item called 'home' linking to node/1 with the language set to english
>· a menu item called 'accueil' linking to node/2 with the language set to french
>· a menu item called 'principal' linking to node/3 with the language set to spanish

That is right.
With 5 and previous version of Drupal, I used to play with aliases:
node/1 = en/societe
node/2 = fr/societe
node/3 = es/societe
The menu item pointed to /societe. And Drupal just added the good suffix to it (/en /fr or /es) after clicking on it.

Now that is broken. I just discover that. the menu says that /societe doesn't exist which is right, only en/societe, fr/societe, es/societe

I don't know if I will find a workaround.

rondev’s picture

rondev commented

No workaround possible? :
Alias workaround appears to be broken:
http://drupal.org/node/80814

I think I will go to one menu with language specified items.
Then for 3 languages = x3 items as only items of the interface language one will be displayed at once.
Exception is Home/Accueil/Principal which have a common link : node

cpsaltis’s picture

cpsaltis commented

subscribing

emi_bcn’s picture

emi_bcn commented

subscribed