How to manage sites in multiple languages

In today’s global economy, you won’t get away with running your site in just one language. “Oh, let’s stick to English, everybody can read it” is not really an option. Do you want to take your visitors seriously; or better, want them to become customers? Address them in their own language. But how would you handle this in your site? It’s harder than you might think.

The technical part, on the surface, is usually doable (there’s a quite a few systems that allow you to set up multiple languages for your site). But it becomes very complex quickly if you’re mirroring and branching content. The editorial process (which you then have to support in the system) for getting it right is much harder. Machine translation (Google Translate, for instance) can get you by to quickly see what that Arabic/Japanese/Chinese site is on about, but the results are still mostly funny, and only a little bit useful. Which means you need translators for each new article. This is an organizational challenge; and that, in turn, leads to a lot of complications in your technical setup.

However, having seen dozens of implementations of this, I can tell you there’s no need to re-invent the wheel — you just have to understand your options. There are broadly three ways of tackling this:

1. Separate
2. Mirror
3. Branch

Let me give you a quick overview of these three different ways of handling multilingual sites.

1. Separate

This is the simplest solution: just have separate instances for each language. Think, for example, of Wikipedia. Basically, each language is another site, there is not a lot of relation between them (except user management and some other shared resources). Doing that is relatively easy, if you manage to get the i18n (internationalization) right. You just run these at different URLs, say en.wikipedia.org and nl.wikipedia.org, or at /en/ and /nl/, or .com and .nl. (Having separate base URLs is usually a good idea for SEO; Google doesn’t like mixing languages.)

However, the more languages you have, the harder it becomes to keep everything consistent and up-to-date. For instance, wouldn’t you want to know for sure that a new product will also be on each site? And for some content, if the different versions are out of sync, it could be disastrous. (I’ve worked with some hospitals and their medical procedures, for instance — that has to be exactly in sync in each language.)

2. Mirror

You would probably want to build in mechanisms to make sure all content exists in each language (or at least in each site). You could “mirror”: define a master language (often English); once new content is added, it will be duplicated to each language in English, so it can then be translated. For more complexity, add a workflow that makes sure it gets translated (e.g. send it off to translators) before it gets published. This is what most airlines, and some product-oriented sites, e.g. electronics companies do: their sites are relatively simple, but need to exist in many languages.

The main challenge isn’t so much i18n (e.g. encoding of character sets and direction of writing) but L10n (localization, e.g. translation). Ideally, the same object (content item) would have different language versions (including images, since at least the filename and title should be translated, but probably also text contained within images).

3. Branch

If you really want to do it right, you’d have completely different versions for each region/language combination. For example, back when I used to work for a university in Leiden, the Dutch site would highlight the fun you can have in the city of Leiden; the English (international) site would also explain where Leiden is, on the map. Do you know where Leiden is, or even in which country it is? And that Dutch is the language of The Netherlands? That’s stating the obvious for a Dutch audience, but everybody else probably needs some elaboration.

This is very relevant for marketing purposes; for instance, you may have all your content in French, but there’s a big difference in localizing it to Canadian, Belgian, Swiss, and, oh yeah, French needs. And I’m not just talking about the difference between “nonante” (ninety) and “quatre-vingt dix” (ninety), or “internationalization” and “internationalisation”. This is where you get URLs like /en-uk/ and /fr-be/. (It’s also why you shouldn’t use those little flags for languages. French is not always French, and many countries have multiple languages.) By the way, also don’t forget to translate those human-readable URLs (again, if only for SEO).

And you might have a pretty girl showing off a product; but you’d probably want to dress her in a black Abaya for the Gulf; not something you’d like to mix up, so this requires a lot of multimedia work, asset management, and again, approval workflows to make sure nothing goes wrong.

For fun (depending on what you consider fun), also add in legal compliance and other approvals (say, if you’d want to sell investments, or pharmaceuticals). You then have different (but similar) sites in different languages with parallel workflows for translation and approvals.

Basically, at that stage, you’re combining all of the technical complexities above, and then adding in a big editorial challenge. I’ve seen sites that exist in >150 variants because of all the region/language/compliance requirements.

That’s not for the faint of heart and it usually takes a team of ~100 or more people to pull it off (and a big budget).

So in the end, for most purposes…

You might want to stick with Wikipedia does, which is just spin up another instance of the CMS (or blog software, or wiki software) for each language, and live with the drawbacks. Even many large multinationals stick to that and just let the local offices handle digital marketing whichever way they want to.

But for those big multinationals, there can be huge cost savings (standardizing on one, albeit more complex implementation rather than hundreds) and efficiencies (launching a campaign in all locales in weeks, rather than months). Whether you, too, would be ready to spend thousands (or sometimes, millions) on that is a very different question. You might also want to quickly read this: Do you need a simple or a complex CMS? — and make sure you make some pragmatic choices.