Multilingual Site?

I want to create a multilingual site, so all menus and contents to have its alternatives in the different languages.

I need ONE page to have it’s corresponding alternatives in different languages, not to duplicate the tree structure (I saw such a solution). One ID, one button link, just different content based on user selected language. Is there a way of making this? And also to be easy editable from frontend by non techie people.


In a similar post ganeshXL answered me the following:

That can be easily done; again by using TVs - one for each language (or keep the default content field for the main language, and only use TVs for the translations).

Simply store the user-choice in a cookie or php session, and output the language (TV) you need.

I think such a solution was already shown here in the past...

I didn’t found such a solution. All the solutions I found were very old (from 2005 and 2006), so I asume they don’t fully work with the current release of modX.

Is there any current solution of achieving this? Any tutorial? Any ready snippet?

Thanks in advance

Yes I wrote in January 2009 a multilanguage snippet named "LangBar".

It it based on tree structure duplication but is fully automatic.

The philosophy is the following:
- you write all the pages in one language
- you run a PHP script that sets some "match_id" TV do the doc id for all documents in the tree
- you duplicate the tree (which must start with a 2-letters language code ("fr", "de", a.s.o.)
- then the snippet Langbar find in which language it is by going up in the tree and finds which is the corresponding translation.

I think this is a perfect solution if you create a site in a language and then translate it, but you still have to do manual edition of the "match_id" variable if you add documents later.
This could be improved however, I think by writing a plugin to synchonize new documents.

If there is interest, I’ll try to update my site with the snippet and the necessary instructions.

Yes, this is good, but for small sites only, that won’t be chanched very often. But for a large sites with dynamic contents which will be administrated by non-techie people this is not a good idea. I can’t tell my clients "to translate this content, just go there and there, change that ID to this ID, run that script...". There must be an easy and logical way.

That’s why I think the TV’s method is better. There is just one item with one ID. The question here is how to show the right TV asociated with the selected language? I’m very very new to modX, so I literally don’t know anything. I don’t know how to grab the languages and build a select dropdown... also how to grab the selected option and use it as variable in the TV’s name? I know PHP, but the philosophy of modX is entire new to me. So any help, any hint, any snippet is more than welcome

P.S. Is modX Revo gonna have multilingual capabilities out of the box? I think I read something about this a while ago...

Programming with MODx API is not so hard, although the API is poorly documented.
The better manner I found to program with it is to type the API function names in some search engine and see what others have done with it.

Look at the code of some exisiting snippet and try to understand how it works.
Also look at the structures of MODx tables using phpMyAdmin. Table names are quite obvious, as well as fields.

I think that doubling the structure built for a language is not so bad, as you have the same TVs and pagetile, longtitle (, ...) in all languages. When you add a new TV for content you don’t have to create one per language.

It is probably possible to add some buttons to the backend to create the translated docs (if not exist) and switch to them for edition.
An advantage of plugins is that you can associate events with the PHP codes, for example perform some action when the changes in some document are saved.

I think that the best way to do such think would be improving some standard duplication snippet like mine and then transform it into a plugin so that translating becomes easy from the backend.
This is just a question of time and willingness.

I never programmed plugins myself (only snippets), but as you have already some PHP experience, I think that 2 to 5 days programming would suffice you to discover the MODx API and create a very flexible solution.

I read somewhere that MODx revolution is fine once you understood it. And it is multilingual from what I heard. But from my very small experience with it (and it is also the opinion of many MODx users), MODx Revolution’s interface is very deconcerting at the beginning.

I know PHP, but the philosophy of modX is entire new to me.

General rule of thumb is "if it works out od MODx then it will most likely work inside MODx". What I am trying to say is that do it the same as you would a stand alone php script. Consider snippets as page level functions and use plug-ins for global functions (this is a very generalized statement since both snippets and plug-ins can have global or local reach).

There are a few tutorials / methods that work in the way that you describe (some may be old but the methods are still valid). I don’t have them bookmarked but I remember reading a few. I have personally done this using cookies and session vars in the past. The major challenges are with some snippets like wayfinder, getting the menu to change accordingly and getting the error page, error messages, aliases etc.. to work. For example do you want the about-us page to have the same alias for all languages?

As for the independent fork for each language method; this is much easier and some clients actually prefer to have the ability to manage each language so that if there is an update in one language and the translations for other languages are not ready yet. Once they learn the method it is easy.

I am preparing for a project where the client wants to handle all languages in one file. It will be twice as costly as the fork method since much more effort will go into it.

P.S. Is modX Revo gonna have multilingual capabilities out of the box?

Not sure, I think that Revolution provides a clear method for doing this by using a ’context’ for each language. But i do not think that it will have a language interface out-of-the-box. I could be way wrong

The initial Revo 2.0 release is mainly to introduce the new API and provide as seamless a transition point for migrating from Evo/096x as possible. In later releases we’re going to make some changes to the data model that will tremendously facilitate doing things a bit differently and what most would argue as "more properly implemented". That’s a long way of saying there won’t be a true multi-language manager implementation with the requisite workflow out of the box in Revo 2.0, but it’s clearly on the roadmap and the underlying data model changes are actually very far along. Revo 2.1 should be an eye opener for lots of folks and not all that far along behind the initial release.