Hi Jose, et all

I am not completely sure of the "preferred" approach to making what I call a "TRUE" bilingual site. By this I mean not only bilingual menus and text but also bilingual URLs as well. It seems as though many people forget this part – but I now for Canadian Federal Government standards at least – this is required.

BTW – I will likely post my recipe for TRUE bilingual site (and link to demo) in a separate post later today.

As far as I can tell there are 2 common practices to making a bilingual menu block.

- it is possible to make duplicates of your menu block and then use the i18n block module to pick the correct one

- the other method that can be made to work is to simply translate strings inside the block

So, now my suggestion:

Since I decided to use the 2nd approach (translate strings) AND I needed to have bilingual URLs I realized that the code for the i18nmenu.module does not support this. It generates a translate string entry for only the “title” of the menu item.

by modifying the function to this:

function i18nmenu_translate_all(){
  global $_menu;
  global $user;
  global $locale;
  $cid = "menu:$user->uid:$locale";
  cache_clear_all($cid);
  // Translate all user defined meny items
  foreach($_menu['items'] as $mid => $item) {
    if($item['type'] & MENU_CREATED_BY_ADMIN) {
      $_menu['items'][$mid]['title'] = t($_menu['items'][$mid]['title']);
      $_menu['items'][$mid]['path'] = t($_menu['items'][$mid]['path']);
    }
  }
  // Update cache
  cache_set($cid, serialize($_menu), time() + (60 * 60 * 24));
}

and basically adding the t(path) line; a translate string will now be available in “manage strings” to provide the translated clean URL value.

One final note:

Even though this will allow me to make a bilingual menu without the need for a 2nd menu block – it is more work that it needs to be. The translated string that I have access to from my fix above is simply allowing me to enter data that already exists in the system. It is added when I add the Clean URL for my translated page when I enter a new page. The code (somewhere??) should add the translation string automatically to the locale table. Eventually I will look at doing this correctly.

Comments???

Peter Lindstrom
www.LiquidCMS.ca

Comments

davemybes’s picture

davemybes CreditAttribution: davemybes commented

Hi Peter

I can't comment on your proposed changes to the function (although in theory it sounds reasonable), however I can tell you how I did my bilingual site (http://mbacasecomp.com). I used option 1 and created two menus, one english and one french. Instead of using a multilingual block, I used Nice_menus module to do the drop-downs for each language menu. Then I told each language to only appear on that language's page eg. english menu on en/* and french on fr/*. Take a look at the site and see what you think. I prefer this option to the translate links option as it gives me a place to see both language menus laid out and an easier way to edit them. Sure, I have to do both menus, but if you keep track of the menu layout properly, then it works out OK.

To help me keep track of things, I had a file that had the menu items listed one below the other. Then I put all the destinations in the next column, followed by weights, followed by the french translations and their destinations. I also added the menu id's in a column for calling up separate menus if needed. By having this all in front of me, changes are much easier to follow between eng & fr menus.

Just my $0.02...

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

nice looking site.. i havent used nice menus but guess i will have to try them out soon.

I have done a bilingual site using the dual block technique; but thought i would try out the translation method to see which i like best - and as far as i can tell there is no damage done by the change i have requested.

the benefits i think to the translated method over the dual block method, i think may be (and this assumes what i refer to as the "real" fix for the paths - which would be a modification to auto translate the clean urls when the translated page is saved):

- i think less translating info required to be entered since you wouldnt need to re-add the translated info for the path
- only need to keep track of the one menu
- i don't think the category_menu.module will support bilingual blocks; this method shouldn't have an issue with cat_menu auto created menus (although at the moment i dont think that module is useable - but soon)

a couple things about your site and how it relates to what i am doing (which is looking at making a Drupal theme/site that adheres to cdn fed gov standars (what is referred to as Common Look and Feel):

- CLF does not actually permit pull down menus - but i am not sure if you are saying nice menus (even if i didnt use them for pull downs) gives you an easy way to manage the dual menus

- another way to do the multilingual block for the menus would be to just use the i18nblock.module; which, i guess is basically doing the same thing your specifying when each block is vivisble does

Beginning of my site can be seen at: http://clf.liquidcms.ca

this is not an actual site that i am building for a client, it is simply an demo to show of the CLF Theme i am designing and to give ideas on how to use Drupal to build CLF sites for the Fed Government.

thanks for the tips,

davemybes’s picture

davemybes CreditAttribution: davemybes commented

On my site, the Nice_menus are purely there for having pulldowns. In your case, each menu would just be its own block, as you mentioned.

So far your theme is looking excellent - I thought I was on the government's website for a minute there :)

I have recently been looking at the category module for a recent project and what it does is automatically create menus from the container/category name. So french container/category will create a french menu etc. Each menu is then a block which you can display as mentioned above. However, once again, this ends up being two menus. I haven't tried your 2nd method - I personally feel less in control if I don't see all menus in front of me. However, I'd appreciate it if you could post back here if it works well for you - if it works then I'll give it a try and maybe I'll change my ways :)

JordiTR’s picture

JordiTR CreditAttribution: JordiTR commented

Hi you all, I'm very interested on multiingual sites, I've already created 3 with 3 or more languages using i18n.module and maaaany tricks ;-) Fortunately last version for Drupal 4.7 works without patches and very smooth.

Peter, I've added you proposed line to i18nmenu_translate_all and I've found a drawback, well, at least a very serious disadvantge for me: it translated the url. Yes, it looks that's what you wanted but it translates primary links (added by me) to the login page from /es/user to /es/usuario or /fr/user to /fr/utilitsateur what directly drives to a "page not found" message. Am I making something wrong?

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

I am not quite sure i understand - are you suggesting that you now have added a menu item such as "User Info" with a path of "user" and when you switch to ES the url for the menu item is no "/es/usuario" - but since this is not a clean URL but a predefined drupal page that you do have a translated page (i.e. "usuario") to go to.

If that's the case i am wondering why have you translated "user"? When you say "it translated the url for me" I dont understand. All my suggestion does for you is give you the ablity to translate the string - if you dont translate it; it will still remain as "es/user" when you switch to ES.

Is it possible that you have translated the word "user" for some other reason and that is causing the "user" url to also be translated? I didnt think that the translation module was that un-specific.

but maybe i am missing what you are doing??

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

ok, now i see what you are referrnig to - as soon as i manage strings and select manage everything it translates the string "user" and then gives me the url to non-existant page.

I will need to think about this a bit - I guess my technique was intended for clean url menu items and not links to predefined drupal pages (user, node, admin, etc). Perhaps this is a core change required for when drupal eventually brings i18n into core functionality.

but i will think about this a bit and see if i can think of anything

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

a partial fix for this:

if you set a "url alias" fo be:

alias: utilisateur
system : user

then, even though the menu link shows as /fr/utilisateur it will actually go to /fr/user when selected

however, the address in browser when on that page will show /fr/user which is NOT bilingual URL as desired but to fix this, pretty sure core drupal changes would be required.

so, basically for user defined (claen) URLs my method is valid; but only half valid for drupal defined URLs such as node, user, admin, etc...

hope that helps.
peter...

Jose Reyero’s picture

Jose Reyero CreditAttribution: Jose Reyero commented
Status: Active » Closed (won't fix)

This version is not supported anymore. No new features for it.