Multi-lingual sites with the Processwire CMS

[ryan]

Almonk posted a great article on his approach to building multi-lingual sites with ProcessWire:

http://codeordie.posterous.com/multi-lingual-sites-with-the-processwire-cms

[jbroussia]

Currently, and considering the future developments in PW, what's the preferred solution to manage multi-languages websites ? The multiple trees structure, or the duplicate fields ? Or something else ?

[Pete]

This thread discusses a couple of approaches - not sure if it's of any help to you though: http://processwire.com/talk/index.php/topic,311.0.html

[jbroussia]

Not really  :-\ I've already read every posts here about multi-languages, but I still can't make my mind...

[apeisa]

Currently, and considering the future developments in PW, what's the preferred solution to manage multi-languages websites ? The multiple trees structure, or the duplicate fields ? Or something else ?

I think there is one important question that you have to answer first: do you want/need to translate all content as it is (ie. webstore) or do you want to have at least something in different languages (most of the sites). If you have 1000 pages in English, 300 in German and only one for Spanish and Finnish, then best way to go is multiple tree structure. Changing language takes you to front page of that language, since you are not interested to have page-to-page translations.

If you aim to have all pages translated, then I would go with duplicate fields solution. This allows you to have translations for every page and easy language switching in current page. It's rare to see normal site or blog to have this, but running application or webstore this would be the normal way. Although this (at least on the simplest form) doesn't allow multilingual urls, if that is needed.

[jbroussia]

The site won't have many pages, big maximum a few dozen, but all pages should be available in 3 languages, maybe more later.

I think that the fields solution would be better for the client because it looks easier to translate each page if I can put each language in its own tab (can anyone give some directions on this BTW ?)... also it looks that this solution is easier for sharing common content, for example images that are not language specific !? Not sure about multilingual urls, do the visitors notice anything about urls ? Is it important for search engines ?

But I'm also afraid that additional fields may be difficult to manage: it means that for each page I create, I have to duplicate most fields for each language, and if I have to add a new language, I have to go through each page and do the same thing again (take note of fields names, types, order, and create new ones accordingly)... Ouch !

[ryan]

I've not had to build a multi-language site myself before, but based on what I've read of your needs I tend to think you should take the multi-page-tree approach. This leaves you with no concerns about search engines as every URL is going to be unique and indexable without you having to consider URL segments or session variables. It also means you won't have to maintain multiple versions of each field. On a site as small as what you've indicated, I think that the disadvantages of the multi-page-tree approach really aren't going to matter much. If you were working on a site where the number of pages was a lot higher than the number of fields (including all language versions), then the multi-field approach would probably start to make more sense. But if my understanding of your case is correct, I think the multi-page-tree will be better.

[jbroussia]

Another problem is that for some parts of the site, the client might have to create new content: imagine there is a news section, or a blog section, the client writes a new post... then he has to browse the tree, find the matching page in every language and create a new child with the same - translated - content  :-\

Also the pages won't be "linked", for example if he wants to hide or delete some content (or modify some property), he has to remember to hide/delete them under each language tree.

I don't know, would it be easier to write a some tool to analyze each page and automatically duplicate fields named with a specified suffix: say my fields have the _en suffix for the default - english - language, if it doesn't find the same fields with _f_ or _es then it creates them... Then the templates could display the _en content by default if fields in the current language are empty (untranslated) !?

[Pete]

But you then end up with another problem - I've had dealings with a multi-lingual site before and the company who owned it decided to have most site pages translated but with news being specific to their dealings in each country, so you can't in that situation have it creating a new page in each language for every page.

The way I've seen of doing this in another CMS was that once you had set up the module that tells the CMS to expect multi-language content and you've set up the root pages for each language, when you add a page to a section there are links at the top of that page to create the same page in one of the other languages or, if it's already linked to another page then you can switch across to that other page easily without having to go back to the page list.

I think this was the best solution I saw as rather than creating new pages in every language automatically it just made it easier to create and switch to the alternative pages instead.

In theory a module could be written to handle this, but it's something that's a bit beyond my level of knowledge in PW at the moment.

[SiNNuT]

Pete, what you are describing sounds a bit like the Babel add-on for MODx Revolution. I haven't used it but it seems quite nice.

http://rtfm.modx.com/display/ADDON/Babel

And a tutorial on how to set things up, including some 'gateway' code, contexts etc. Of course no CMS works the same but it gives an impression:

http://designfromwithin.com/995/modx-multilingual-setting-up-babel/

Something like that would be a nice way to go from the PW prototype described here:

http://codeordie.posterous.com/multi-lingual-sites-with-the-processwire-cms

[Frank Vèssia]

I like the /lang/ solution because i think we can positioning a website more easily on google in this way... multifields solution is too hard to do, it's like facebook or twitter or big websites do but i guess they don't care about positioning on google...

If i want to use this method but using subdomain what i have to do?

ex.:

http://en.mysite.com/page  http://fr.mysite.com/page 

[ryan]

Sevarf2, good points. You are right in that if maximizing the search accessibility potential of the pages is important, then a solution that ensures each language version has a unique URL is key. If not using a multi-tree approach, you could still do this with URL segments on a multi-field approach. But multi-tree is the most straightforward way to ensure search accessibility.

As for subdomains, I'm not sure there is an easy answer to that question since it depends on how your web server is handling subdomains. On my server, I can configure the subdomain to run from a subdirectory off the main domain so that site.com/test/ is equivalent to test.site.com. So the first thing I would try would be to setup the subdomain in the web hosting control panel, remove any /test/ directory it creates, then create a /test/ page in ProcessWire and see if it works. If that doesn't work, you might have to symlink /test/index.php to /index.php and /test/.htaccess to /.htaccess. I haven't had the opportunity to experiment with subdomains in PW yet, so let me know if you are able to experiment with this.

[doolak]

So this thread was started before there was the Language Support with multilanguage fields was added to the core...

I wonder what you would recommend now for a smaller site - still the multi-tree approach?

I can imagine just one case which speaks against the use of the multilanguage-fields: If there are some pages which should just be displayed in one language version. But it should be possible to exclude them somehow in the template and redirect to the homepage then - so i personally tend to go for the multi-language fields.

[ryan]

I don't think there is necessarily a right answer to that question, as there are various factors and preferences that would dictate what approach may be best for a given situation. But for a small site, maintenance of two trees would probably be the most direct and easy route. On a larger site, multiple trees may take more work to maintain and other solutions may be more attractive in some cases. The multi language support page covers some of this and the multi-language fields page in there gets into a couple of different approaches as well. But it's a broad topic and a good question so always good to discuss different strategies.

[bytesource]

Hi,

I would like to know if it is possible to turn the built-in name field into a multi-language field. This way the page name (URL) would change automatically based on the language used. 

Cheers, 

Stefan

[arjen]

I believe that's not possible. Soma and mcmorry created the great Language Localized URL module for those purposes.

[bytesource]

I believe that's not possible. Soma and mcmorry created the great Language Localized URL module for those purposes.

Thanks for the great tip. I'll check it out.