Dual language menu system
baraban - February 13, 2007 - 22:46
| Project: | Localizer |
| Version: | 5.x-1.9 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
What I am trying to do is extremely simple and I have no idea where I am goign wrong. Please help!
All I want is to be able to switch interface languages for whatever content is there.
The content itself should appear in whatever language it was created
I have provided translated strings via the Localize inputs in the "Menu", but these menu items do not get translated whn I change laguages. Am I the only one that has this problem? What am I doing wrong? Please help!!!

#1
I forgot to mention that the site os http://www.OdessaPage.com/newspaper/
Somebody, please help?!!
#2
Hi.
Perhaps the manual can help you starting with Localizer
http://drupal.org/node/103419
#3
Thank you Roberto.
Apparently the problem is that I didn'patch the files. Since file patching is not normal procedure and because i18 series of modules didn't require it, this requirement should probably be more obviously spelled out at the beginning of the top level README.txt file.
So, now I have now patched all the files, removed the localizer from the sites/all/modules directory, refreshed and moved it back in, reenabled the language chooser and menus are still not being translated. What can I do to fix it now?
#4
Menu translations don't need patches.
User defined menu must be translated in the menu admin interface
and they don't use the localization Drupal core module.
Have you translated the items ?
Let me know.
#5
Do you see my Primary Links menu at the top of my page?
* Blogs
* Books
* Forums
* Polls
These are all standard menu items. So I go to admin/build/menu
and follow the following steps for each menu item:
1. Click edit next to the menu item I wish to translate
2. Click on Translations to expand into languages
3. Clik on Russian, enter the translated Title and Submit
This should work, shouldn't it?!
#6
Also, I was wondering if it would be possible to switch display of the site name, slogan, forum container names and etc. depending on language.
#7
While there may also be other issues, it appears to me that you have not given anonymous users access to Localizer by enabling this in Administer > User management.
I inadvertently left this out of the handbook documentation. I will be fixing this as well as doing some expansion on the documentation shortly.
One other thing to check is in Administer > Site building > Modules to be sure that all necessary modules are enabled and nothing says "missing" by it. I have seen were an incorrect installation has caused this before.
#8
>Access denied You are not authorized to access this page.
You should give grants to anonymous user to "access Localizer"
>I was wondering if it would be possible to switch display of the site name, slogan
Yes.
I'm finishing the implementation of the variables support.
For forum I don't know. I have to install this module and see how it works.
#9
Thanks guys, I have turned on Localizer access and nothing is changed!
I do not have the views module installed and Localizer views is disabled.
Aren't these optional? What else could be my problem?
#10
Views support has nothing to do with menu.
If you want, send me privately a username and password.
I can then verify your options in Drupal and give you more help.
#11
Thanks! I just emailed you.
#12
Ok, understood.
You should seen a new menu item : Test EN (Test RU, Test UK) on your primary links.
The problem is that the four menu items you are using are provided by Drupal
and not created by you, so Localizer doesn't translate it.
I admit that the management interface can make some confusion (I'll fix it).
The expected behavior would be that menu items provided by the system or by modules
should be translatable by the localization module, but it seems that this has not been
taken into account by the authors.
I'll extend Localizer to manage also this menus.
In meantime the simplest solution is that you create by hand that four primary
links disabling that provided directly by the modules.
I have already done it for Blogs link as example.
#13
Thanks for all your help. Don't think your quick fix works in all cases, though. :(
Here are some important issues that I see:
1. Menu still does not switch languages on some of the Admin screens.
2. It does not work for My blog, My account or any of the other menus generated by drupal on per user basis, as well as for those menus that drupal does not allow to be turned off.
3. It doesn't help in translating block names that aren't already translated through the core localization module, nor with the site name, slogan, mission statement and forum container names.
4. It requires lots of admin overhead and is not quite intuitive. :)
i18n series had some of the same issues (and more), as I recall, but some of the more basic stuff was already in place.
Is this right or are there more tricks that can help solve some of the above?
Also, I am curious why the localizer stores all its translated terms seperately from the localization's vocabulary?!
#14
>1. and 2.
Strings provided by Drupal or by modules, I mean, not provided by you, must be translated
by the Drupal locale module. If the author has not properly used the locale module in his
code, the strings cannot be translated.
Which admin menu items are not translated ?
>3. It doesn't help in translating block names that aren't already translated through the core localization module
Of course. See the previous answer.
At now Localizer translates only user provided blocks.
>nor with the site name, slogan, mission statement and forum container names.
The support for variables is almost finished and will be available in the next release.
>Also, I am curious why the localizer stores all its translated terms separately from the localization's vocabulary?!
Here you can read why :
http://groups.drupal.org/node/1827
Besides that locale module is absolutely inefficient and when you begin to insert a lot of strings
your system become unusable, because it uses a blob field to find the string to translate.
#15
Glad to know that somebody smarter than me is thinking about all these issues! Nevertheless, as a system user to a developer, I have to say that this disjointed solution adopted by both the i18n modules and the localizer is rather confusing. I guess the hope is that in Drupal 9 it will be done right?! :)
Regarding:
"Strings provided by Drupal or by modules, I mean, not provided by you, must be translated
by the Drupal locale module. If the author has not properly used the locale module in his
code, the strings cannot be translated. Which admin menu items are not translated ?"
Here is what I meant in more detail:
The strings that you helped me translate - the ones that appear at the top as Primary Links - they seem to appear translated on all the user pages, but not on all the admin pages: for example /admin/build/menu shows all the terms translated using the localizer module only in their original untranslated only. I am assuming that this is a bug. No?
Also, "my blog", "my account", "Create content" and etc. can not be translated using either the localizer or the localization modules. Or is there another trick to make this happen?!
Blocks provided by contributed modules (including the localizer itself) such as the Amazon block, the Workflow block and the Language switcher block on OdessaPage.com are not translatable using either the Localizer or the Localization core module. Am I missing something again?
Also, since you seem to be so knowledgebale on all this langauge stuff, I bet you know the answer to an unrelated question that has been bugging me. Since MySQL 4.1 you can specify caharacter sets in databases. Drupal supposedly sets utf-8 for the database and all the tables within and indeed some tables such as locales_target on my system are utf-8, yet some others, which should obviously be utf-8 (such as cms_node) are not! How did that happen?! Can it be easily fixed? The system, of course, will work anyway, but it makes it difficult to update the database manually...
#16
And here is another bug.
Terms translated through the localizer in certain cases will not get prepopulated with the translated string values once you go back to change the translations next time. (I have not figured out just yet under which conditions this happens, but I guarantee you that it absolutely does!)
#17
OOps, scratch my last comment. Something appears to be not right, but I can't confirm or replicate this problem...
#18
Hello, I am testing out Localizer over i18n.
I followed your above instruction as I really wan to translate my custom menu items. I don't have the option available in step 2, "click on translations". I have enabled all Localizer modules. Have I misunderstood?
>>So I go to admin/build/menu
and follow the following steps for each menu item:
1. Click edit next to the menu item I wish to translate
2. Click on Translations to expand into languages
3. Clik on Russian, enter the translated Title and Submit
#19
On the top, there is a combo box with a list of languages.
Use it to change the language to translate the menu entries.
#20
Hi As a new user of Drupal I do have one problem with dual languages. I can choose with a option between the languages and it works, but it is displaying a button in word at the bottom of the screen where you can change the language. My customer wants that button at the top of a page. How do I get it there?
#21
The thread is really old, so I am assuming you are NOT using Localizer/Drupal 5.x, but I think the (actually one) solution is the same for Drupal 6.x. The language switcher is in a block. If you want it at the top of the page, you can move the block to the header area. (Administer>Blocks)