The 3 approaches we use to build multilingual WordPress sites

The WP Crowd
Published: April 19, 2016
Topics:

So you’ve been tasked by a client with creating a multilingual site? Or perhaps you’d like to address a new language demographic and want to add a 2nd language to your site? Because after all, how hard can it be, it’s WordPress, so it’s got to be easy, right?

This article will not be your typical laundry list of plugins that are available, or how you might do it … this will be about the three (3) approaches that my firm uses every day to build client WordPress sites.

Why do I care, what makes me qualified?

I’m based out of French-speaking province, in a bilingual country, where the provincial law states that any corporate communications MUST be available in French, or in the case of bilingual content, that French should have predominance (read “default language”) over other languages.

 

 

Reality Check

WordPress was written, coded and documented in English, and the company is run by an all English-speaking executive team.

Yes, there’s been an effort recently to improve the translation process for the core CMS, as well as providing an easier system for theme and plugin authors to accept translations, and there’s Global WordPress Translation day coming up.

But… translation != multilingual

 

Lay of the land

If you search for “multilingual” today on the WordPress Plugins repository, you’ll find 417 plugins claiming to address some aspect of this. Four-hundred-and-seventeen ! No wonder everyone’s got a different way of tackling it.

You’ll also find plenty of blog posts discussing this topic because it is a real issue, something that bogs down many seasoned WordPress beginners and professionals alike, because having a perfectly multilingual WP site that also provides ease-of-use for the end user is a real challenge.

In the end, the solution you choose will depend on the nature of your site (blog, corporate, e-commerce, etc), its complexity (# of plugins, custom code, etc) as well as the level of proficiency of the person that implements it.

But before we get into this, let’s get one thing out of the way right now : whatever approach you choose, you WILL have to manually input content in that other language. There’s no escaping it.

So plan accordingly if you’re the one doing content entry on the multilingual site. My firm charges a 25% premium on the cost of the project for each additional language in a multilingual site.

The approaches discussed below are based on years of experience delivering multilingual website

 

Approach #1 : WPML

WPML is the proverbial 800-lbs gorilla, a (commercial) plugin that’s been available for years. It has its detractors for various reasons, some of which are valid, others less so. But the one constant has been, and that should be important to anyone, that their development team stands by their product, and have consistently improved it over the years all the while providing great support on their discussion forums.

We’ve been using WPML for years now over a variety of sites, and now have a good grasp on when to use it :

  • Simple blog-based site
  • Small to medium-size corporate site
  • Basic e-commerce, with little or no customization
  • Most sites that use a WPML-compatible theme

In those scenarios, WPML will handle 90 to 95% of the translation requirements, and with a few tricks, you’ll be able to get to 100%. What tricks ? Here are some straight from the trenches :

  • Validate that all your plugins are WPML-compatible, or that they are localized, as you’ll be able to scan them and translate their strings through WPML String Translation
  • Use the WPML Widgets plugin to conditionally show a plugin based on the language use (another great choice would be the Display Widget plugin)
  • Make extensive use of WPML’s Multilingual Text Widget : use for text, images, shortcodes
  • WPML lets you scan Admin Text Strings (look at the bottom of the String Translation panel), for those cases where you enter content in a plugin or theme’s configuration panels
  • Fetching the mo/po files for your WordPress language and sticking them in the /languages folder might be more work, but your database will thank you for adding less bloat
  • If a plugin absolutely refuses to play nice, find an alternative…

 

Approach #2 : Polylang

If you’re building a bespoke theme/site for a client, or building your very own SAAS and have tight control over all aspects of translations, then Polylang is a great choice. It also boasts a solid team which has been cranking out updates consistently over the last few years.

Don’t be fooled by the simplistic website they use, it’s the code quality that counts. They provide full compatibility with WPML functions and XML files, meaning any WPML-compatible theme will be compatible with Polylang’s translation functions as well. And of course, Polylang adds functions of tis own

But where Polylang really shines is in performance. Granted, the article dates a little, and WPML has made recent efforts to improve it’s DB querying techniques, but the fact remains that Polylang is more lightweight in its approach and barely impacts a site’s workload.

Also, whereas WPML consists of multiple plugins (a site may require anywhere from 2 to 8-10 plugins) to provide a site complete multilingual capabilities, Polylang uses only ONE. Less updates. Less memory use. Less complexity. Less failure points. All things that matter to a developer crowd or the performance-inclined.

 

Approach #3 : Multisite

The last approach is not a plugin, but rather a technique.

For years, people have been using WordPress Multisite to build different versions/languages of a given site, and it works. Even today, a case can be made that there is a difference between offering a translated site, and one that also takes into account cultural differences by using different colours, marketing techniques, and so on.

As cool as WPML and Polylang are, they will always use the same theme to render the content (yes, you could add language conditionals in your templates, but that becomes unwieldy very quickly).

Using Multisite, you’d make the base site you default language, and once done, by using a plugin such as NS Cloner, you would make a copy of the base site into a new subsite, change the language in General Settings, translate the content, change the theme if desired and be done.

You can then make use of some plugins, like Multilingual Language Switcher, that will provide the visitor with the ability to switch from one language to the other effortlessly.

Additional benefit : it should also be noted that, all things being equal, each site will perform as fast as a single WordPress site, as all internal calls are native, there are no extra DB calls to fetch translated content, or provide additional UI to the visitor.

When should you consider using Multisite :

  • When building very complex sites, which make use of many plugins (15-20+)
  • When top performance is critical
  • When needing to use a different theme for different languages/geographies

 

Of course, those approaches worked for us, but your needs or decision criteria may differ, in which case, there are 415 other plugins to try before making your mind 🙂

Jean-François is the Founder of ARSENEAULT Consultation, a WordPress development shop servicing the SMB marketplace in Canada, and is also the Co-Founder of Propulsif, which focuses on building web platforms and SAAS solutions for the midmarket space.

Get the latest from The WP Crowd

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.