I was contemplating WordPress and how it handles multiple languages recently. There are really two main aspects of multilingual sites. There’s multiple languages for the reader (the visitor) and there’s multiple languages for the admin. The two may not be in sync.
For the Admin
This has always been a little tricky. Assuming all projects have the same number of available language packs, you get two primary methods of translating the admin section.
First is the site is set for a language. That means the owner of the website decides “This site will be English, have a nice day.”
The other option is to have the setting be per user, so a user goes to their settings page and says “I speak French.” Obviously the main site setting (see above) will be where they start from, and this can be a little weird to find on some apps.
The per-user setting is the most common, though it gets rather complex when you consider things like a WordPress multisite network. What if I want to make a site for the French and edit it in English? In MediaWiki too, this is an issue. I can only edit French WikiPedia in French. Initially. I can go in and change it per site, but there’s no global ‘default my account to English.’ Which is right? In the case of WikiPedia, it would be sensible to default me to the language on the site where I first make my account. If I sign up via fr.wikipedia.org, I should default to French.
For the Front End
If you only need one language, this is pretty easy. Pick the language for the site, write in it, and you’re done. For most Americans, this is ‘standard.’ But what happens when you need multiple languages on the front end? For the most part, things have to be either intended from the start or something you add in later. And both have drawbacks.
WikiPedia, for example, has two methods. First they have a site for each language that cross links back to other languages:
They do this via Interlanguage Links, but also via an extension called Translate which allows groups of people to translate.
ZenPhoto uses serialized data. When you edit your content, you can add in the descriptions for it in each language. This has pros and cons. Weird things happen if the CMS ever forgets what language you’re using (an issue I actually did have for a while).
When we look at WordPress, it tends to use plugins. Currently I’ve been recommending Bogo for translations. The other options are to make a Multisite and have each language be a site, but without the Interlanguage Links features of MediaWiki, cross-linking people back and forth based on language can be complicated.
Another options?
I’m not as versed in translations as I should be. Are you? I’d love to hear how you (and your projects) handle multiple languages for both admins and visitors.
Comments
10 responses to “Multiple Languages, Multiple Approaches”
I would like to add something that can be quite problematic: I’m German, the WP instances I take care of are set to German. Some plugins don’t have translations and therefor their backend is English. This can already be problematic if you have a great plugin with an author who’s English is really bad (I’m thinking of a very specific one but don’t want to point it out ^^). What’s even worse is a bad translation to German, maybe done by a machine.
But the main problem is simply that I can’t choose to have a plugin use English text if my WP is German. At least that’s what I was told. It’s bad because all the documentation is in English, all discussions about it are English and translations more often than not are not unambiguous. It’s hard if the button you need to use has a different text than stated in the documentation.
My favorite example is from old Windows XP in system controls. There’s “Add and remove programs”. In German that’s “Software”. I never expected “Software” to be called differently in English and in the alphabet S is quite far from A. Things like this are an additional problem all by temselves.
So please, whoever creates a plugin and adds a translation: Make that optional 🙂
@Floutsch: Fascinating comment, and one I hadn’t thought of before. If the plugin translation is poor, the easiest way to fix it is to send a nice email to the developer correcting the translation. The way you’d get to see the original language by default is to remove the de_DE files from the /languages folder of the offending plugin.
But as a English-speaking developer with just enough Spanish in my vocab to get in trouble, I welcome people to correct my translation files, or submit other translations!
What @Ben of BenandJacq said (swap Spanish for French).
Making a plugin translatable isn’t the same as having translations for it 😕 Part of why I tend not to ship translations with my plugins (I’ll put them up on GitHub though) is because those translations can be soooo iffy and if I can’t check that they’re right, then it’s really bad.
You mean if you write a plugin in English and install it on a German site, it will always force you to use the German Translation? Because that seems right, if a little annoying.
@Ipstenu (Mika Epstein): I can’t remember if I have ever encountered a plugin that I would have wanted transalted but wasn’t translatable. For those not doing something visible for the visitor I couldn’t even tell. With themes that’s more of an issue; most times those I use don’t come with German translation but are translatable.
Problems here mostly stem from the author’s lack of understanding of how the actual translation will be done. Three identical single word strings that have to be translated to different terms in another language are going to be annoying if context isn’t given. And the context annotations (“backend”) are often a bit like the use of alt in image tags (“photo”) – not helpful if done just to fill the field 🙂
@Ben of BenandJacq: Regarding said plugin I was thinking about feeding back a better translation. But it is so bad that I wouldn’t know if my translation would be correct. My guessing only works fine for navigating the plugin. In other cases I have indeed given back suggestions 🙂
Regarding removal of translation files from a plugin. That… is a game changer. I never thought about that! o.O I will certainly do that for some plugins. Even if only in the beginning when I don’t want another layer inbetween me and the documentation.
Btw. I wish backend and frontend translation were separate files for core, themes and plugins alike. I don’t know if that’s feasible or wise but then I could either just get rid of the backend translation or – the other way round – only translate the frontend stuff.
Thanks for touching on this Mika.
I’m currently delving into whether to build a site using WPML Plugin, and got a host of responses from seasoned developers that said “I will never use that plugin again, it’s buggy and bloated, for multi-language I will only use WP Multisite going forward.”
I have built sites and implemented WPML before with two languages, however my current project requires 5-languages. Having the flexibility of adding a site per language to a network, in conjunction with the Multi Language Switcher plugin, seems to be the best way.
I’m still doing further testing but so far everything I hear screams “Multisite!!!” for multi-language. Curious to hear what other developers have to say, but for now that’s the path I’ve taken.
@Chris: Multisite strikes me as a nightmare to use for that. Keeping content in sync across sites? Yikes.
@Ipstenu (Mika Epstein):
Thanks Mika.
Are you saying nightmare in terms of 5 languages on a Multisite? As opposed to one site with a Bongo/WPML Plugin approach? – checking out Bogo as we speak thanks for mentioning it.
The intent was originally super admin (english language) assigns languages to each site, assigned site Users then upload translations to each…perhaps I’m complicating.
@Chris: The amount of duplication of effort strikes me as complex. Multiple places to install and configure themes and plugins. One site still has the issues of multiple manual translations and keeping them in sync, but you don’t have to duplicate all the work.
@Ipstenu (Mika Epstein): Thanks for clarifying I see your point now. Having experimented with Bogo and recognizing the number of places where it must be extended for multi-language functionality e.g. menus , widgets, and so on (x 5 languages) I have to say I’m apprehensively heading back in the other direction to WPML Plugin. But that could change again tomorrow. 😉