Fact. To build a multilingual (or multi-language?) website is hard. Much harder than a single language website version. Fact. The current available solutions to simplify designers/developers life when building multi-language websites are…very complex.

Multi-language websites are probably more common outside US, and maybe, more complex in the European territory, since over here we share a huge diversity of languages and dialects in a small piece of land. Take europa.eu website as a good starting point…you got my point, right? 

This is probably why it is an excellent idea to have a special session about this topic on the first WordCamp Europe. It’ll have three different developers points’ of view about multilingual solutions, WPML, Babble and Multilingual Press, “introduced and moderated by Zé Fontainhas, WordPress Polyglots lead, who will talk about why multilingual WordPress is a problem and why it’s important.”

Yes it’s a problem…a nightmare for some of us.

The Starting Point

There are dozens of reviews, plugins’ comparisons, tutorials and articles published about this subject. A good starting point for reading about this is the Codex. A quick overview over all the stuff published will probably lead you to the WPML plugin as being the most complete and functional of the market. What about the competitors: qTranslate, Polylang, Stella, Xili-language, Transposh, Global Translator, Google AJAX-translation, mLanguage, Multilingual Text, Multisite Language Switcher, and so on…

Well, I don’t know. So I went into some kind of test phase.

The Casting

One year ago, during the kick-off of a client’s project where we would need to build a site in 5 different languages, I’ve tried all the most known standalone site plugins, including  WPML, qTranslate, Polylang, Stella, Xili-language and probably some others I found in the WordPress repo. It was a really hard process. Some of them are very complex to configure and to operate. Some of them were spitting out so many error messages (debug on!) that there were no sign of confidence. Others weren’t intuitive enough for a non-developer user (after all, the backoffice will be in the client’s hands as soon as the site is on-air).

In the end, I’ve selected the Stella plugin (paid version).

On a previous post I’ve shared some of the issues during the process and I must say I’m still not happy with the final setup.

Each individual project needs a different approach, and so I’m not saying that I’ll be using Stella on all my projects in the future (certainly not). It all depends on what you are trying to achieve. But, there are some pressure points that need some prior attention:

  • Plugin support and future maintenance of the code
  • Complexity to manage content language variations ( one language per post vs. different languages in a single post) and easiness for client’s future operation.
  • Level of extra non-WP core logic (new DB tables, SQL direct queries…), thus increasing the potential to break as soon as core is updated.
  • Nice-to-have features: Possibility to translate categories/tags/taxonomies, custom post type support, and the Pièce de résistance, different slugs per language post variation.

I personally tend to pick the easiest to configure, simple to operate and well coded plugin, where I tend to be very picky with the ones that create extra DB tables, or do direct SQL queries, to point some of my itches with others’ code.

Maybe in the end, it all comes down to “Decisions, not Options” philosophy, and here I must say that each plugin should focus on doing one thing as perfect as possible instead trying to be the All-in-one type, capable of work in several different scenarios and configurations…

This is my take 1 contribution for the State of Multilingual WordPress discussion, to be held in WordCamp Europe  2013. Multi-language solutions deserve more attention from the community as this is clearly an area where WordPress is not a winner.

See you in October.

Posted on August 17, 2013, by Luis Godinho in Notes
Tagged , ,