When it comes to multilingual blog management, things get hard. It’s not your fault; the “multilanguage thing” is complex.
Terminology (not official)
Internationalisation should be the ability of a system to deal with many languages and cultures. Natively, it supports one or more ways to translate and localise the content it manages.
Localisation is the act of creating content for a specific language and culture. It could be that some content makes sense in one language or culture and not in another. Talking about labels, the localisation is just the translation.
On this page, you can get deeper into those concepts. If you need to play internationally, you should definitely read it.
A locale is a set of information (texts and so on) that the system uses to adapt to a specific language and country (with variants). A locale is identified by a code, made of the language, the country (usually), and a variant. For example, it_IT indicates the Italian language used in Italy. While it_CH identifies the Italian language used in Switzerland. There is a third-level part called variant, but I never had the chance to use it on a real product.
WordPress Multilanguage Concepts
WordPress is ready for internationalisation and localisation: it provides tools to create language packs for more than 60 locales, so you can choose to use it with your preferred locale. For example, my customers usually install it with the it_IT locale and WP downloads the related language packs (for itself and the installed plugins).
A WordPress site has a default locale selected during the installation, and you can find it on WP main settings. Once it was hard-coded on the site’s wp-config.php file with the constant WPLANG.
Of course, WP knows nothing about the language you use when writing content or defining tags and categories. The blog language is used only to get the correct locale pack and show in that language all the labels coded to be translated.
So if you set the WordPress language to Italian, you’ll see the admin side and the common labels of your public site (for example, the “Search” word) translated into Italian (if your theme has the Italian locale).
The language can be set even at the user level. So, when a user logs in and has a different language in his/her profile than the default site language, WordPress will give priority to the user setting and switch to that locale.
Problems Come With Content
The real internationalisation/localisation problem starts when you need to translate your content. Not only that, but even your categories, tags, or media (yes, an image could be translated if it contains text or metadata).
There are two main approaches:
- Everything you write in your primary language needs to be translated
- What you produce in a language does not necessarily need to be available in another language
With the first approach, you just have one site, and you add, over the translations provided by WordPress, the translations of your content. So, for example, a post is a post, and you can read it in English or Italian. A category is a category, and you have the name in English and in Italian.
This is the first thing that comes to mind when we think about translating a site. And it is a good, methodical, and easy method. TranslatePress is one of the tools available.
The second approach is more general, and it’s like having two sites. You can have posts in English and posts in Italian, completely uncorrelated. This is common for companies that use the “translation” to provide content for different countries, and those contents need to be different.
Of course, you can have a post that just needs to be translated: the approach is to create different posts for your language and “link them” so you know that post #12 is the translation of post #17 (and online, you can switch between them).
But you can have post #67 just in English and visible only when someone surfs the site selecting the English language without any way to switch to the Italian version of the article (that doesn’t exist).
The tools you can use for this second methodology are WPML and Polylang.
Is There a Best Choice?
No. You need to think carefully about what you need and remember there is no easy way back.
