CMS Made Simple Forums

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

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

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

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:
I also created a UDT (mostly stolen from jsmonzani's original) named {get_lang} which is put at the VERY TOP of your template:
And for the user to actually make the language switch, my template code looks something like:
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:
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

Hello,

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

   {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.

thanks for the constructive criticism!

example?...

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.