Multi-language: best ways?

Ok this topic was discussed many times. But I think it focuses in many hacks to work with multiple languages and not in a general solution. What do you think about this?

At this time we mostly create a document tree for each language and work with tvs to handle the language dependencies. What if modx would be able to create parallel pages for a document? Means that I create a "new document" (at first in my configuration I set 2 languages for instance english and italian) and modx puts automatically 2 parallel documents in my tree:

[tt]
Start
|---- About (english)
| - About (italian)
|
|---- Products (english)
| - Products (italian)
|
and so on[/tt]

What about this?
rasc

Could be done, with a plugin and a module working together.

Don’t know how but that’s another playground.

And what others think about this idea? Good/what the hell .../ugly/...
What do you mean? I want to discuss this as a point of usability for clients we made web sites for. What can be their favorite method to handle multiple languages if we can’t support every time their web site?

This can definitely be done using this tutorial and a plugin that watches new pages and creates parallel documents in each tree.

If you’re question was whether or not this functionality currently exists, then no, it doesn’t.

Nice tutorial, but I don’t want to have different trees for languages. If I understand this tutorial right, then I must manually allocate the corresponding page setting the language tv with the correct page id? Ok for me but NOT usable for simpleminded clients.

I’m looking for a better way to have documents parallel. Really automatic. Maybe it’s possible (with a bit of coding plugins/modules) to create a new document as a folder which includes the language dependent pages. The "folder document" is only a container for admins/authors and contains information only for admins/authors for administration/identifying the content. One language is the default lang. This is the first doc in this folder. It automatically "knows" that all other pages (automatically created) in the same folder are the parallel pages. If I create a folder, it automatically creates all necessary pages in it. The folder itself will not shown in menus. Folders must be set by creators as a category folder or a "document" (including lang pages).

This idea is immature but can be a way ...

Well, if you really want to do it that way I don’t know that folders and subdocuments are necessary. Just create a new TV for each other language’s content (e.g., [*content*] would be English, [*french-content*], [*spanish-content*], etc.). Then call pages using a language variable in the query string (blog.html?lang=german) and script your menus and other elements to use the right content (with a plugin, snippets, PHx, or otherwise).

Advantages: Easy for clients to maintain and edit, since all languages are on one page and you don’t need to do anything to make the alternative languages active (no typing in corresponding doc ids, etc.). Creating new pages automatically creates all languages. Easy to script default content when a document isn’t available yet in a particular language ("Sorry! This document hasn’t been translated into X yet. Below is the document’s content in English." but menus and whatnot would translate).

Disadvantages: Difficult to make aliases work in multiple languages (each doc would have one URL only, although you could use .htaccess to hide the language query string, i.e. blog-german.html). Very little of a page could be cached, since your content will change dynamically. No way to set up user groups that work only on specific language(s).

Nice idea too. The alias problem is mine. Should be a task for a future multi-language version of modx

Tnx all for inspiration. Further ideas will be accepted too.

Quote from: rasc at Feb 07, 2007, 02:57 AM

If I understand this tutorial right, then I must manually allocate the corresponding page setting the language tv with the correct page id?

That’s what the plugin would monitor, any time a page is added/updated, the plugin should make the neccessary changes to the TV. Also, having a separate branch for each language (language-branch method) is ideal for MODx since snippets such as Wayfinder, Sitemap, and Ditto are built with tree structure in mind. If you have a child document for each language (language-child method) you would have to completely rewrite all the snippets, thus still making the language-branch method ideal.

Also, if you go with [*content*] [*french-content*] and so on (language-TV method), you would need to make ANOTHER plugin that would search through each language TV if you intend on your users being able to search the site in languages other than the default.

</rant>

Anyway, I’m not a multi-lingual person and at the moment none of my clients need this functionality, but we’ll just have to wait and see what the world brings...

We should do a poll to see who prefers what method, so far this thread has addressed 3 different, but well thought out methods.

Quote from: sirlancelot at Feb 07, 2007, 10:23 AM

Also, if you go with [*content*] [*french-content*] and so on (language-TV method), you would need to make ANOTHER plugin that would search through each language TV if you intend on your users being able to search the site in languages other than the default.

Actually the issue of not searching TVs is a more general problem in my opinion. It can be dealt with a number of ways, including modifying the queries in Ajax Search or whatever other search snippet you prefer or using an external search indexer (including the new Google methods, which are pretty decent). It seems as if this is being reviewed for future releases, but I think that this is an issue that we’ll need to hack/customize for a lot of purposes for a while.

Personally I do a lot of bilingual sites (and one multilingual setup that never did get translated), and I use the subfolder with a TV that points to the other documents method. But some clients do seem to find it problematic, and they generally don’t like to have to manually link documents. A plugin to automatically create matching docs would be nice if it worked reliably, but I have my doubts as to whether it wouldn’t cause more problems than it solves.

So for now I think there still isn’t a perfect solution, only different pretty good solutions that people will have to choose depending upon their needs and preferences.