Every Home for Christ has a long-term goal of making all their websites available in as many languages as possible.
Obviously, this is a huge amount of work. Each site has a lot of content, and often require multiple translators to account for differences in cultural expressions.
Thankfully, though, I am not a translator. I’m a web designer. My job is to make sure each website is accessible and easy to update in multiple languages — a task that is time-consuming and easy to get wrong.
EHC’s websites are built on a tailored WordPress core, with a variety of plugins and custom bits and pieces to make them sing. We knew that the websites had to be multilingual from the start, so I began researching my options over a year ago — in phase one of EHC’s digital communications overhaul.
According to my research, EHC had three options:
- They could set up multiple sites, each running an installation of WordPress in a different language. They could install each site on different servers. They could even use WordPress’ multi-site functionality (but that has a lot of other trade offs that rarely make it worth using).
- They could install a simple multilingual plugin (like Polylang, which seems like the most popular option).
- Finally, they could set up WPML, which is the Rolls Royce of multilingual Wordpress plugins — in terms of both price and quality.
I played with all three of these options on a couple local WordPress installations, and settled on WPML. Here’s why:
- Having a website dedicated to each language is a content management nightmare. Whenever possible, everything should be in one place — not several.
- Using WordPress’ multi-site tool is a recipe for long-term disasters, and impacts the hosting flexibility and portability of any website.
- If each site is in its own dedicated language, so is each CMS. The people who work on the websites all speak English, so I couldn’t ask them to update it inside a French interface. (If there’s a way around this, let me know, but I couldn’t find any obvious solutions.)
- Polylang is nice, but it adds additional categories to your website to manage its content, which is a pile of hot garbage. It also doesn’t offer string management.
- WPML came with every tool I needed right out of the box, including the ability to find text strings in themes and plugins and mark them for translation. That saved me a lot of time futzing about with if/else statements, which also would have slowed down the site.
WPML is nice. Like most non-core WordPress tools, it feels a bit like a hack. It’s clearly an interface add-on, and there’s a lot of friction in the initial set up. (It’s made for very technically minded people — again, not unlike WordPress.)
But once it’s set up, it’s great. You can filter your content by language, and add additional translations for each page or post with a single click.
WPML also makes it easy to set up multiple domains for your site. (We’ve hit a snag with SSL for this site, but that’s an unrelated DNS issue.)
It’s not all roses, though. WPML could be better at integrating with additional plugins. Not every plugin is compatible with WPML, and WPML relegates those that are to a separate, more technical part of the interface. It’s not easy to use, it breaks WPML’s expected design conventions, and it goes against the typical WordPress content flow.
As a result, if you’re not careful (and lucky), WPML may introduce compatibility issues with existing themes or plugins. Like adding any moving part to a product, you’re increasing the likelihood that something will break down the line.
None of this is insurmountable for any developer, but it’s the reality of WordPress. It’s a piecemeal system with a lot of accumulated technical debt.
WPML is great, but if multilingual features are of paramount importance, you should consider a CMS with those features baked into its core. I particularly like Craft, which includes flexible layout tools and multilingual support right out of the box.