Blog

A modified photo by Andrew Huff

Presenting content in different languages is a needful and important feature. And most websites are using generally the same conceptual units for implementing it – translated “portals” of the site and a language switcher. But I believe, it’s a wrong concept!..

When you come to a Wikipedia page, how easy is for you to find your language in the language list? Even for English you need to check the huge list of languages, the majority of which you can’t read! WTF?..

The UI element you see on Wikipedia is a language switcher (also shown on the image to the right of this text), which usually lets you move to the translated page or the start page of the language portal. On that portal you usually get all the interface labels translated to the chosen language… Even, if you don’t speak it (e.g., because you chose it by mistake)! And even when you come to this portal from a search engine (and do not know, how to switch to a language you speak)! Besides, when you are (e.g.) on a German portal and the translation for a label is not available, most websites usually show you the English translation, whenever you can read it or not, even if a translation in another language, you can read, is available… Again, WTF?..

That’s the localized portal concept, that everyone is using nowadays! But it’s wrong! Users should never be redirected to a page translated into a language they don’t speak, unless they explicitly requested this language and really knew, what they were doing! Getting a page in a language you can’t read is the most disappointing experience, that you can ever get on WWW, in my opinion…

Also, not every Wikipedia page has all the translations. And I don’t mean, that some pages are available only in English – many articles do not have the English translation too! So, this also means, that, when you search for a term on the English portal and the term is not available in English, you’ll fail! Even if the term is described in any other language you can read. That’s another sample, that shows why the portal concept is wrong!

Did you know, that your browser usually knows, which languages you speak?.. When you configure your operating system – e.g., localization or keyboard languages – the system usually uses these data to configure the preferred languages in your browsers. For some OSes such browser configuration can also be explicitly done in system settings.

Your browser sends the list of your preferred languages in the Accept-Language header with each HTTP request…

Have you thought the same?.. Why not using these browser data to, at least, make known languages appear above others in, e.g., the Wikipedia language switcher? I believe, we could even show only them by default and let users unfold other languages by clicking some “More” link or whatever. But, in fact, considering, that the browser is configured correctly, we can even drop the classic language switcher. Really, why do we need to switch known languages at all?..

If a website has all its articles translated to all supported languages – it’s an ideal site! Or, most likely, it’s a static website not updated for a long time… In practice, often the original language of a site has much more contents, than its translated portals. This means, that as soon as users switch to a translation they loose access to some contents! I’m sure, that you have experienced this problem, if you can read several languages. Then why do we need such language portals? And is there an alternative approach? I believe, it is!..

If you used to read a Wikipedia article in several languages, you might have noticed, that usually translations are different. And it’s fine, as languages represent cultures and each culture can have its own vision of the topic. Thus, a literature genre may have its own best samples in particular languages, Viktor Yanukovych (the president of Ukraine) does not need to be introduced to Ukrainian readers in a non-dedicated article, and so on. From this point of view to learn a topic better it usually worth reading as many translations as you can…

So, there is no need to hide untranslated topics, but instead it’s better to show them in any other language, the user can read. Also, instead of showing only a single translation it is better to let users choose between the languages they can read. As in many cases translations are, in fact, different articles in different languages but on the same topic…

To avoid mess and confusion, when all the translations are shown in the list, I would suggest to group articles by a primary article and include links to other translations, the user can read. Also I would choose the primary article by its completeness and preference of the language (the Accept-Language HTTP header is able to indicate, which languages are preferred) – not just by the current language of the portal.

When launching my blog (this one) I looked for a multilingual solution to use – I wanted my blog to behave not in a common “translation portal + language switcher” (wrong) way. To my surprise I have not found any better approach (at least among WordPress plugins)…

In my blog I’m not going to provide translations for each article. I will target many my posts to Ukrainian readers, many of whom can read Ukrainian, Russian and English, so I don’t see any reason for hiding other languages from them! On the other side, certainly, I don’t want my English-only readers to be confused by many articles in languages, they do not understand…

This way I was “forced” to think about a better multilingual content handling concept, that got described in this article. As a result this concept was partially implemented in my Language Mix plugin for WordPress. This plugin depends on the great Polylang plugin, which was created by Chouby. The Polylang plugin implements the classic “portals + switcher” concept and my Language Mix plugin provides fixes to make this concept closer to what I’ve described. So to some extent this site and this plugin can be used as a demo and a proof-of-concept for the described approach…