Hi.

I still didn't figure out how and where to translate custom menus (which are showen as blocks).

Also Primary and Secondary links are needed to be translated for me.

I tried also to add to locales_source and locales_target tables custom data. This works but only for specific locations and i need it for locations specified under blocks.

Comments

edinjapan’s picture

edinjapan commented

Not sure if it will entirely help you, but I created a simple documentation page on translating menus. The method explained will work for Primary links and the Navigation links.
http://drupal.org/node/232316

Jack_Sparrow’s picture

Jack_Sparrow commented

EdInJapan,

Your documentation works well for new menu items, unfortunately if I create a new Menu, I cannot find the string to translate.

For example, I've split my menu into 2 sections.
1 - Logged in user menu with create content, log out, etc.
2 - Site Menu for general users who aren't members, but viewable to logged in members too.

I've named the new menu "Site Menu", but there is nowhere to go to translate the words "Site Menu".

Any thoughts?

edinjapan’s picture

edinjapan commented

Jack_Sparrow,

I don't have a definite solution for you, but I have seen some glitches with the cache that may occasionally keep the new menu from showing up in the search results. Once you have created a new menu item, switch back and forth into all the languages you are using on your site before you go to look in the Localizer strings area. Once you get to the Localizer strings area, you might want to switch the languages again just to be sure the language cache has cleared. Then cross your fingers, and hope it comes up. If not, it is best to file this as a separate bug report so the Roberto can track it.

Roberto Gerola’s picture

Roberto Gerola commented

Upgrade to version 3.3.
Save again your menu items.

Using the search panel, change the language and search your string agian.
The strings are stored with the language you were seeing your website.

Take a look at the table localizertransaltion and watch if the string is stored
and in which language.

Roberto

--
http://www.speedtech.it

Bodo Maass’s picture

Bodo Maass commented

Hi Roberto,

What was the reason to switch from the menu translation approach in localizer 1 to the new one in 3.3 ?
Interface-wise, I think it is a step backwards, and the old approach was easier.

It is possible to use the string table as a backend for menu translation and still provide a nicer interface that only translates menus. I made something like this for i18n once (http://drupal.org/node/70919), but then I switched to localizer, partly because it already had a better interface for menu translation. So I am wondering why you switched to the current approach.

Bodo

Roberto Gerola’s picture

Roberto Gerola commented

>What was the reason to switch from the menu translation approach in localizer 1 to the new one in 3.3 ?
>Interface-wise, I think it is a step backwards, and the old approach was easier.

Because it wasn't impossible to create proper permissions for translators.
You were obliged to grant admin permissions to your users only to translate
menu items.
Plus I received many complaints that the interface wasn't easy to use and
was causing a lot of confusion and maintaining that code was really problematic.

> It is possible to use the string table as a backend for menu translation and still provide a nicer interface that only translates menus
Do you mean localizertranslation table ?

>I made something like this for i18n once (http://drupal.org/node/70919)
Sorry, I have no time to test it, have you a screenshot ?