Localization vs Internationalization

Hi,
I’m new to this CMS and it seems very promising. But by reading the docs and trying the demo, I’m not sure about what MODx really offers regarding different languages.

It seems it’s "localization" capable (l10n) : you can translate the interface.

But is it "internationalization" capable (i18n) ? I mean can I build a truly multilingual website, without dirty hacks (like dual install) and without the need to duplicate everything for each language?

This is very important here in Europe, as most website are built at least in two languages : "native" language + english.

At this time, we are l10n and i18n capable, but we do not offer any tool out of the box (yet) for managing these capabilities. That said, MODx also does not inhibit this capability in the ways that many other CMS offerings might (forcing you to hack their system), and several members of our international community have already come up with their own schemes for presenting sites in different languages. I believe we’ll see more and more in this area with our quickly growing population of non-US members.

I am very interested in input from our non-US user base (or anyone with significant multi-language site capabilities) as to what has worked well for them in other projects. We’re in the midst of addressing several design optimizations right now and this is the perfect opportunity to bring this into the mix!

I’ve just finished a multi-language site with the method described here. I like the idea of not having to use a page-parameter. The idea of jaredc (here) suits this method perfectly.

For now I use different chunks (templates) for each language. So my list of chunks looks like
- dothis_nl
- dothis_uk
- dothat_nl
- dothat_uk

And calling a snippet goes like
[[snippet?tmp=dothis_nl]] and
[[snippet?tmp=dotthis_uk]]

This way I separate the code from the templates. Ideally you would like to separate the layout within the template from the text within the template. I’ve solved that by using css for layout and using div tags within the templates.

What I think would make MODx a lot better is a way to organize the chunks (templates, snippets and plugins) like the way the documents are organized (as raised by others). This would be quite a change though.

Chunks organized in a tree would give access to a chunk in a certain language easily. I’ve used the ’_uk’ way to set the language for a chunk. A way to be able to set the language of a chunk (template, snippet and plugin) seems like a valuable addition. (Make everything a document, as raised by others!)

Ultimately I think of a way to organize TV’s the same way. If we could have the TV’s in a tree structure and make every possible field a TV you could have as many RTE-TV’s as you need for your languages. Hierarchical TV’s on the same level become tabs and child TV’s become tabs on their parent-tab.

The way MODx works now though is better than anything I’ve seen elsewhere. The biggest drawbacks of the ways we can do multi-language are the mutual settings for the language pages.

eg: I like to publish all the languages for one page on the same day. I’ve to set the publish date for all the languages individually. TV’s in a tree structure would solve this by having the publish date field on a parent with the RTE-fields as children.

Quote from: theo at Nov 09, 2005, 04:20 PM

What I think would make MODx a lot better is a way to organize the chunks (templates, snippets and plugins) like the way the documents are organized (as raised by others). This would be quite a change though.

Chunks organized in a tree would give access to a chunk in a certain language easily. I’ve used the ’_uk’ way to set the language for a chunk. A way to be able to set the language of a chunk (template, snippet and plugin) seems like a valuable addition. (Make everything a document, as raised by others!)

Exactly what we’ve been discussing over the last 48 hours. The ability to define hierarchical taxonomies of various components (templates, chunks, snippets, plugins). I don’t think it’s as big a change, or as far away as you think.

Quote from: theo at Nov 09, 2005, 04:20 PM

Ultimately I think of a way to organize TV’s the same way. If we could have the TV’s in a tree structure and make every possible field a TV you could have as many RTE-TV’s as you need for your languages. Hierarchical TV’s on the same level become tabs and child TV’s become tabs on their parent-tab.

Great idea. And fits in well with our current thinking and approach to core improvements as I mentioned above.

Hmmm... from a back  end standpoint, anyone have experience with the following resources?

http://www.sitellite.org/docs/I18n/I18n.html

http://www.php.gr.jp/project/i18n/ (Carsten?)

http://blog.innerewut.de/articles/2005/07/03/php-gettext-as-an-alternative-to-gnu-gettext

http://pear.php.net/packages.php?catpid=28&catname=Internationalization

Interesting, though never used these. I use ’setlocale(LC_TIME, $locale)’ to get the date functions to display the right language.

I think I would go for gettext and ’setlocale(LC_MESSAGES,$locale)’ if chunks wouldn’t do for me anymore.

What’s the reason for looking at the alternatives?

theo, I have the same date display format issue, and I was thinking about using SETLOCALE.

Where did you add the code ?

I’ve modified the DocumentMapper snippet to work with TV’s. I’m using a custom API function in this snippet. I didn’t post this snippet because of that.

This snippet allows the use of [+tvname+] placeholders in your list template. Since I have a DATE-TV and needed multiple languages this snippet has a parameter ’locale’.

You could write a plugin that sets the language (based on a page-parameter if you have more than one language).

These are the lines that do the date formatting in the snippet:

Theo, is there any chance you could post the full snippet code for those of us who know how to use custom API?