Multilingual web-project with Revolution: best practice!

Hallo all you happy people!

Firstly, I wanna thank all, MODX developers, for doing a great job making our precious CMS better and better! =)

Now, to the topic:
I need to make my revo multilingual, and I’m just wondering: what is the best practice for that? What is your, modx developers, suggestion in this cases? I read something about contexts in revo docs, but I don’t seem to understand how should it help me? Can anyone give me a clue of how I should use this context and lexicon things together?

I read tutorials about multilingual solutions in this forum, but they don’t seem good enough.
Any help will be appreciated!

Mmmm.... Anyone?

- Design and make your entire site in English.
- Once finished, duplicate the ’web’ context and use separate contexts with a different ’cultureKey’ Context Setting for each language.
- Translate each page in each language context

This method allows you to properly render your content based on that language. Just doing string replacements for translations sounds good (ie, YAMS), but doesn’t work in reality, as languages require different structures, URLs, etc. (Example - right-to-left languages) That’s why it’s best to have a separate Context for each language translation.

If you’re doing most of your structure in Templates, Chunks and Snippets, you can share those across the Context, leaving your Resources for primarily content - which is what they’re designed for.

Thank you for the reply, splittingred!

I’ll definitely follow your advice. But how to deal with links to switch languages? Can I have links like this: mydomain.com/en/xxxx using context or I should use sub-domains?

Depends on how you build it. If you build it with folders, as stated here, you could just make the URLs manually, or from a snippet.

I’d personally recommend writing a custom snippet, but that’s up to you.

Ok! I got the idea, but not quite understand about this custom snippet: can you, please, provide a simple example of that?

Thanks!

It *really* depends on how you build your Contexts; I’d need to know a lot more about how you ended up structuring your site before I can give you a good answer.

Quote from: splittingred at Aug 12, 2010, 02:35 PM

This method allows you to properly render your content based on that language. Just doing string replacements for translations sounds good (ie, YAMS), but doesn’t work in reality, as languages require different structures, URLs, etc. (Example - right-to-left languages) That’s why it’s best to have a separate Context for each language translation.

That’s a misrepresentation of YAMS. It doesn’t just translate strings; it’s a lot more powerful than that. YAMS specifically allows templates, chunks, layout, URLs, style, right-to-let etc. all to be (easily) customised per language if required, and to have language agnostic pages. I agree that it’s important to allow such freedom though. Most users just want to translate strings, but there are a some users that require more freedom.

Quote from: splittingred at Aug 12, 2010, 02:35 PM

- Once finished, duplicate the ’web’ context and use separate contexts with a different ’cultureKey’ Context Setting for each language.

I’m not sure if I understand this correctly. A website is never finished in my experience. It’s always being updated and modified, and MODx allows this to be done easily without breaking the site. In your approach above, if someone modified/restructured the site in one for one context, would they have to manually go and modify/restructure all the other contexts? If so, then I think that’s a flaw in this approach. End users will probably forget to do that or find it too onerous. Ideally it should be automatic (as in YAMS, which has the opposite problem; it’s currently not possible to disable translations for individual documents.).

Quote from: PMS at Aug 15, 2010, 10:16 AM

Quote from: splittingred at Aug 12, 2010, 02:35 PM

- Once finished, duplicate the ’web’ context and use separate contexts with a different ’cultureKey’ Context Setting for each language.

I’m not sure if I understand this correctly. A website is never finished in my experience. It’s always being updated and modified, and MODx allows this to be done easily without breaking the site. In your approach above, if someone modified/restructured the site in one for one context, would they have to manually go and modify/restructure all the other contexts? If so, then I think that’s a flaw in this approach. End users will probably forget to do that or find it too onerous. Ideally it should be automatic (as in YAMS, which has the opposite problem; it’s currently not possible to disable translations for individual documents.).

Yeah agree that a website is never actually finished. I struggled with this exact thought a while back. But now that we have launched a few multi-lingual sites I found that splittingred’s approach works really well. The reason is that when you do grow your content it doesn’t always (actually never) get translated immediately, and so for a period of time it might make sense to launch the first language version of that content first instead of waiting for all other language variations of it to come. You can eliminate that bottleneck and come back to the translated version when it is ready. Next, you may even find that it’s not relevant or necessary to translate all content and that you actually want different sitemaps for different languages. Lastly, you may even have different content editors for each language who aren’t bilingual. If you use one sitemap to manage all content then it’s a real possibility that the content editor can’t find the page he/she needs to edit because only the primary language page title is displayed in the resource tree whilst all his/her language content is behind that in TVs that are only presented once you are in edit mode per resource. I know that this has actually been a problem for me until we used the context based approach - I couldn’t even locate the home page to edit it, because the website’s primary language was Chinese!

So whilst it is more work to create multiple contexts and resources, and it can present room for error, it’s also the most flexible and scaleable way of doing it.

I think from a pre-launch perspective, the workflow splittingred has outlined works great because you’ll be able to use your first language version of the site for development testing purposes and once you’re happy all the code and templates work, then you can duplicate and configure the next one. But from an after launch perspective it’s not necessarily the same workflow.