My trick for multilingual pages with regular CMS v1.0.6

snuggere · **Joined:** Sun Sep 21, 2008 4:40 pm **Posts:** 2

Thanks guys!

Yes, I did. To my embarassment I'd have to admit that I only found it after I posted the above message. I noticed the use of content_en and the implications of this in the light of what the future official multi-lingual release will bring: content_nl, content_etc.
The way I did I used the single content (and other) fields and allow editors to provide the different translations in one field (i.e. content, content blocks, menu text, etc.). I checked out the multi-lingual branch you pointed out but decided to stick to the way I did it for a couple of reasons:
1. If and when the official release comes it would be fairly easy to migrate; I made only a few changes (code only, not in the db) that are very easily traceable so my upgrade path would be smooth, migrating my db contents to the new db should be just a simple script of some sorts. Well, probably wishful thinking here.
2. And probably the most important reason: in the website I am currently working on my templates use around 5 to 6 separate content blocks on each page. The editors providing the content will do the translations in the different languages, so it's not my end-user who will provide the language for their specific mother tongue. This would mean a very long and confusing editor page where they have to fill out around 7 or so fields on one page. The way it is now it still is a lot but it should still be 'simple' enough for them to cope.

What do you guys thinks? Will this unofficial branch be the way forward in terms of how the official release will deal with multiple languages?

Thanks

alby · **Posted:** Fri Sep 26, 2008 10:01 am

snuggere wrote:

What do you guys thinks? Will this unofficial branch be the way forward in terms of how the official release will deal with multiple languages?

I think we should do a bit of clarity between language trees and MLE.

Language trees: work now; certainly upgrade to version 2.0 is more smooth; with 2.0 could be delicate the module's multiple languages work in a non-native way

MLE: work now; the upgrade to version 2.0 is yet to be verified; same way of working of 2.0

The choice between the two methods is personal, security of upgrade and features you want
if you are uncertain, it is better going in multi tree

Alby

Gregware · **Joined:** Tue Nov 27, 2007 12:48 pm **Posts:** 6

Hello jsmonzani
i would like to know if your proposition about multilingue is also working with all of the modules
what i really would like to do is to get a "news" and a "shopmadesimple" modules totally multinlingue.

Thanks for your answer

oct4th · **Posted:** Wed Apr 08, 2009 10:11 am

I know this thread is getting up there in age, and some good work has been put in here: http://forum.cmsmadesimple.org/index.php/topic,19099.0.html ... but so far no multilingual version has worked exactly how I wanted it to. Thus, I've created my own, using similar techniques as posed in this thread.

NOTE: I'm not a programmer. My PHP skillz are pretty limited, so if any pros read this and laugh, please don't be shy in telling me so.

There were two issues in particular that I wanted to fix: having the language change work when using pretty URLs and NOT having to have separate pages for each language (ie, index_en.html, index_zh.html).

To fix this, I created a file and named it language.php and stuck it in my main directory (www.mysite.com/language.php). It looks like this:

Code:

<?php 
if (isset($_GET['slang'])) {
   $expire=time()+60*60*24*30;
   setcookie("slang", $_GET['slang'], $expire, "/");
} else {
    setcookie("slang", "zh", "/");
}

$ref = $_SERVER['HTTP_REFERER'];
header("Location:".$ref);
?>

I also created a UDT (mostly stolen from jsmonzani's original) named {get_lang} which is put at the VERY TOP of your template:

Code:

global $gCms;
$smarty = &$gCms->GetSmarty();
if (isset($_COOKIE["slang"])) {
  $gCms->smarty->assign('weblang', $_COOKIE["slang"]);
} else {
  $gCms->smarty->assign('weblang', "zh");
}

And for the user to actually make the language switch, my template code looks something like:

Code:

<a href="language.php?slang=zh">CHINESE</a>
<a href="language.php?slang=en">ENGLISH</a>

The base href from {metadata} and the redirect in language.php makes using this with pretty URLs no problem. The cookie will be set, and the user will be redirected right back to the page they were on. The $_GET is never even shown in the browser for ultimate prettyness!

The magic for the content is the same as jsmonzani proposed:

Code:

<div id="content">
   {if $weblang == "en"}
       {content}
   {else}
       {content block="Chinese"}
   {/if}
</div>

Thus far it seems to be working, but as mentioned in the NOTE above, there could be problems my uneducated eyes can't spot.

Lastly, there have been some questions asked about making the News module multilingual. Using the above technique it's actually relatively simple:

- Create a category for each language in the News module - I have two: English, Chinese.
- Using a Page created with the above template simply tell the News module to display the desired category. For example, in my first text box I have "{news category="english"} and the second I have {news category="chinese"}.

This is my first crack at a multilingual site (I moved to China, if you couldn't tell).

Thoughts?

c

Pierre M. · **Posted:** Wed Apr 08, 2009 1:10 pm

Hello,

calebkm wrote:

I know this thread is getting up there in age, (...)

Code:

setcookie("slang", "zh", "/");

Code:

if (isset($_COOKIE["slang"])) {
  $gCms->smarty->assign('weblang', $_COOKIE["slang"]);
} else {
  $gCms->smarty->assign('weblang', "zh");
}

Code:

<a href="language.php?slang=zh">CHINESE</a>
<a href="language.php?slang=en">ENGLISH</a>

Code:

{if $weblang == "en"}

Thoughts?

Yes, this thread is old and somewhat obsolete.
My (personal) other thought is that I dislike the cookie or URL disturbing way of doing things. I'd rather "§12.3 Transparent Negotiation" from http://www.ietf.org/rfc/rfc2616.txt see "§14.4 Accept-Language" (page 103).

Pierre M.

oct4th · **Posted:** Wed Apr 15, 2009 1:57 pm

thanks for the constructive criticism!

example?...

Pierre M. · **Posted:** Wed Apr 15, 2009 4:16 pm

calebkm wrote:

thanks for the constructive criticism!

example?...

http://www.debian.org/ and http://www.ruby-lang.org/ are sites that respond multilangualy OK with my browser language preferences. No cookie, no URL parameter, just http.

Pierre M.

Warod · **Joined:** Fri Mar 12, 2010 1:46 pm **Posts:** 1

Pierre M. wrote:

http://www.debian.org/ and http://www.ruby-lang.org/ are sites that respond multilangualy OK with my browser language preferences. No cookie, no URL parameter, just http.

Pierre M.

Are you seriously planning of implementing _ONLY_ the http way of selecting language? Even though debian and ruby-lang sites do detect language preferences correctly from browser, they always redirect to language specific URL of the site. Debian site seems to be ultimately broken since it always throws you at the browser specified language when following a link even though the language is manually changed on the bottom of the page. Ruby site in the other hand masks GET based language selection under rewrite and menu and links change accordingly.

Yes, if you want to make multilingual site actually work correctly and user friendly way in practice, you'll need more than 'just http' to get it done. URL parameter is the way to go. So, time to let go of the ideological correctness and do things right.

No offence but I'm just worried that the implementation will not work out in real world usage cases.

My trick for multilingual pages with regular CMS v1.0.6

Who is online