[Update 1: If you start reading this thread here, note that the code has been improved several times since I posted this first message. You can read the messages in chronological order to follow the improvements or jump to the Final step by step implementation guide I posted at the end of the thread with the last version of the code.]

[Update 2/Actualización 2: He publicado una versión en español de la guía final de implementación. I've posted a Spanish version of the final implementation guide.]

[Update 3: You can see a working example of this method in a bilingual personal site of mine:  http://alien.alinome.net.]

[Update 4 (2009-08-26): Pierre-Luc has written a module called Babel, based on this method, easier to use and with more features.]

[Update 5 (2009-09-12): After almost three years, I have decided not to use CMSMS any more. It has become too complex for my needs, version after version, and latest upgrades have broken many things in my code. I ported the site I mentioned in "Update 3" (and others) to a custom Website Revision System of my own, much simpler and productive (wiki-like, no database, straight PHP programming...). The website look is exactly the same than with CMSMS, though.]

---

Hi all,

Until now I have built only one site with CMSMS, monolingual; but some of my new projects will be in several languages. I could use other tools I used before, but I like CMSMS so much that I decided to give it a chance. I don't reject the idea to test the CMSMS MLE fork, but firstly I wanted to try to squeeze what I need out of the regular version.

I searched the forum for tips on this question and collected some interesting ideas, mainly about the same solution I already had in my mind at first: separated menu branches for the different languages. (By the way, it is really hard to find useful information with the provided search tool, so finally I googled with the "site:cmsmadesimple.org" option). All the approachs I found were (at first sight) too complex and hard to adapt one way or another. I wanted to find a solution as much simple and configurable as possible.

My goals were these:

• Only one page template for all pages in all languages (though of course you can use more if you like).
• The language bar buttons should link to the current page translation, not to the home page.
• Easily configurable for any number of languages.
• Easily configurable buttons in the language bar.

Here you are what I did step by step:

Menu organization

I created two root section headers for the two languages needed. Their names are the language codes. All pages in every language are created in the corresponding branch:

• es (Section Header)
  
  [li]page1
  
  • page2
  [/li]
• eo (Section Header)
  
  [li]page1
  
  • page2
  [/li]

To make things easier later, the language section headers have the mark "Show in menu" turned off.

Get the language of the current page

To have only one template for all pages I needed a Smarty variable to keep the current language and use it to select the corresponding parts of the template (the other way would be to use a different template for every language, what is worse to maintain).

My first provisional approach, just to be able to start programming the language bar, was a bit fooly: The user had to choose the language of every page by filling a content block. I put this at the top of the template:



Well, some minutes later  :) the second approach was born and it was a bit -- smarty: As I told, the root parent of every page is a section header whose name is the language code itself. I just needed to get the name of the root parent of the page... But I didn't how to get it! I thought I could learn from the menu module code and program a kind of loop to navigate to the upper parent and so on. I found a possible solution too late in
the message Re: Using the Global variables from CMS. Too late, I said, because I had already thought a simpler solution:
The left char of the template var friendly_position was all I need! The new code at the top of the template was:



Of course the if structure is not very elegant. If more languages were needed, it would be better
to use an array with the languages codes, indexed by the menu root positions. Si I decided to write an User Defined Tag called {assign_page_lang}:



So finally this is the only code needed at the start of the template:



The template

The Smarty var $page_lang can now be used in the template and its blocks to select the content depending on the current language, e.g.:



Or:

   

Or the main menu itself, to show only the corresponding language branch:



Very simple.

The language menu

Now the language menu. I wrote a second UDT called... {language_menu}. In its code you'll see the simple trick to get every page related with its translation. Nevertheless I will explain that later.

The tag has two optional parameters:

• show_current = Show an inactive link to the current page in the menu? (true/false)
• show_title = Use the page titles instead of the defined buttons? (true/false)

I needed to execute Smarty tags from a user defined tag (UDT), but happily I found the solution in the CMSMS documentation.



Yes, it's very simple: just use the same page name (alias) for the language versions but add the language code to it, e.g.:

• es (Section Header)
  
  [li]contact_es
  
  • products_es
  [/li]
• eo (Section Header)
  
  [li]contact_eo
  
  • products_eo
  [/li]

I prefer the format "page.es.html" but the dot cann't be used here. You can use "page-es.html" if you like. The code will change only the last to chars. Of couse you can change the code to name the pages other way (e.g. to put the language code at the start of the name).

You create the language menu in your template like this:



Or with parameters:



CSS do the rest.

The code is working fine in a new personal site of mine I'm building these days. I'll post the URL later because the site has no content yet and looks really weird .

Future migration to CMSMS 2.0 or whatever

I use Mod Rewrite to get pretty URLs in the format "/contact_es.html" redirected to "/index.php?page=contact_es".

Maybe useful for someone, the lines I use for this in the file .htaccess are:



(Of course, you have to configure config.php too).

That way, if in the future I migrate to other multilingual system whith a different URL format I will easily create those fake HTML files with PHP code to redirect them (that would be easier for me than messing about Mod Rewrite). E.g. the file products_es.html would be:



Improvements

I'm not very used to PHP (the language I use the most is Forth, what is a extremely different thing!). If you find something that should be corrected or could be improved, please post. I suspect some if structures and conditions could be simpler (when I come back to PHP after a long time, I always forget about && and similar things ). The same about the relation beetwen PHP and Smarty, and the inner workings of CMSMS: all that is a new thing for me.

As the code comments explain, the page title option still does not work, but I will ask for help in the corresponding forum board.

Hope all this helps.

Cheers,

Marcos

PS: After implementing my solution I found this interesting message in the forum:
Starting homepage based on users browser language. I think I will add that feature in my site.

_________________
Marcos Cruz

I don't think so, but I have not compared it with other solutions. Only two UDT are needed: the first has three lines plus the array, and the second has many comments and debug info that make it seem much longer.



You are right, it is not a good thing in some cases. It's the simplest solution I found. (I didn't know MLE works this way too). But I think there's an alternative... What about content blocks to keep the name of the other pages?:



The version in the current language will be left blank (or omitted in the template). The variables can be accessed in the UDT. I am going to explore that.


Thanks, it's nice this code can be useful.

_________________
Marcos Cruz

As promised 30 minutes ago  :) I have explored the question. Here you are a solution:

Add this to your template:



In every page, write the name of the other language versions (the current one is useless).

Then in your template use this modified version of {language_menu}:



I have tested it and it works fine. I think I will use it in my site, instead of the first version. Page names in the page language look much better.

Thanks a lot for the instigation! 

_________________
Marcos Cruz

Two little things:

This simple modification in {language_menu} (second version) is useful to avoid problems when an alternative page has not been specified yet:



And one more idea: Instead of one content block for every language (one of them always useless) , we could use only one content block for all alternative languages. The UDT would transform its content into an array with the PHP function explode() or something like that.



Its content would be something like "lt page_name_in_lt;ru page_name_in_ru;en page_name_in_en". Right now I'm not sure about the most convenient "sintax" for that string to get an indexed array from it, but I will explore the question...

_________________
Marcos Cruz

Hello,

this is interesting. I'd rather test CMSms v2 (pre-alpha in SVN) but your way of doing things (vanillia CMSms) seems sane :-)

I'm not a coder, I've not tested, but may I suggest something :
You have

and

May be instead of if/elsif the array could be used to assign the start_element ?

Pierre M.

_________________
-- Pierre, former support team member.
Please read "how to submit installation/support requests" before posting. Don't send private messages to ask for support.

This second solution I propose is more user friendly (though maybe slower): only one content block to specify all alternative pages.

Put this in your template:



In every english page, fill that content block like this:

lt=page-name-in-lt;ru=page-name-in-ru

In every russian page, fill that content block like this:

lt=page-name-in-lt;en=page-name-in-en

An so on for every language.

The order and number of the languages doesn't matter. Maybe some pages don't have all translations avalaible. Or one single page has more translations than the rest. That's no problem if the arrays in both UDT have all the language information needed. No spaces in the string, though, just to make things easier and faster in the code. The language codes must be two letters long (the UTD should be modified to use three letters).

Then use this (third) version of {language_menu}:



I think this is a good solution too.

_________________
Marcos Cruz

Right, I had the same idea, but I did'nt know how to use, in Smarty, arrays defined in UDT, or vice versa, and I haven't explored the question yet. As I told, I'm not very used to PHP and I don't know Smarty enough. I think it is possible to do what you suggest. That would simplify the template when there are several languages.

Also, I would like to use one single array for all language information (now one is needed in {assign_page_lang} and another in {language_menu}, but it's not very important.

Thanks!

_________________
Marcos Cruz

Hello again Marcos,

Single array, simplified template... tasty
I hope a Smarty Guru or the Smarty doc will answer.

Have fun with CMSms

Pierre M.

_________________
-- Pierre, former support team member.
Please read "how to submit installation/support requests" before posting. Don't send private messages to ask for support.

For info only:
In MLE: title, menu_text and content (and in extended: metadata and description) are separated for each language in a similar way to version 2.0

Alby

_________________
Former Italian Admin and Moderator
Multilingual: MLE is not CMSMS

Thank you Alby for the improvement and for the - Smarty teaching.



I'll try MLE too.

_________________
Marcos Cruz

I've just found what I needed to do without the array in {assign_page_lang}: Get a page's root parent's alias.

With that code I can do what I thought in the beginning: to get the language id of any page from its root parent name. The new version of {assign_page_lang} is:



Now the name of the root parents must be the language code (with the prior method that was not mandatory).

_________________
Marcos Cruz

You're right, I will post the result and will explain how to implement it step by step for non-programmers (as I did in the first post of the thread). I think the last version with no array in {assign_page_lang} and only one content block to specify all alternative languages is the most practical for both the programmer and the content editor. What do you think?

Maybe I wait a little untill you and maybe others test it a bit. It's working fine in my site; the code is simple so I think there should be no bug left.

Thanks

Marcos

_________________
Marcos Cruz

Thanks. That's a typo of mine: I added that languages on the fly, as an example for you. I have corrected the mistake in the the original message.

_________________
Marcos Cruz

That's a good idea! You never can trust content editors...  I'll try to implement that.



Right, "show_current" should show an inactive link to the current page. It worked fine for me. I'll explore the question.

Till a bit later

_________________
Marcos Cruz

Tested: It works fine for me. Maybe you made some inadvertent change?

The tag call works this way:



Or this:



Verify this line in the code of {language_menu}:



And these too:



Is it all right?

_________________
Marcos Cruz