A subject finally getting some attention in the WordPress community is i18n, or internationalization.
Internationalization is the process of making an application ready for translation. Often this gets confused with localization, which is the process by which the text on the page and other settings are translated and adapted to another language and culture.
Both internationalization and localization are equally important within WordPress, but there cannot be any localization if the theme or plugin has not been internationalized first. Therefore it is of utmost importance for WordPress theme and plugin developers to internationalize their software, regardless of whether it ever actually receives a translation into another language.
In the past couple of months we have seen more and more articles being published on the subject of internationalization. Some are even dripping with frustration!
- Last October Thord Daniel Hedengren published Don’t Be A Dick: Localize Everything, then
- in December David Decker posted The 7 Cardinal Sins of Localizing WordPress Plugins and Themes.
I must admit that I have left frustrated comments on sites like WPCandy, WPBeginner, WPMU and the like, whenever something is promoted that is not properly internationalized. It seems I finally got someone’s attention as Ryan is the one who asked me to write this editorial after I left yet another frustrated comment on one of the articles published here.
For those whose native language is not English and who want to develop websites in more than one language, it is very frustrating to read any news about Fantastic Hypothetical Theme A or Cool Plugin B that were just released, only to realize after downloading that it is actually completely useless since it hasn’t be internationalized!
And do you know what is even worse? When said theme or plugin costs money (often called premium). Not only is that frustrating, it’s just wrong. Despite the number of features your theme or plugin has, if it has not been internationalized it shouldn’t be sold in the first place.
This is just not open for discussion. Internationalization should be common practice, not a feature!
But then again…
It actually is not that strange that for many developers internationalization comes as an afterthought. If you look at the Theme Development Standards article in the WordPress Codex, you will see that all the way down, somewhere at the bottom is a quick note about internationalization:
To ensure smooth transition for language localization, use the gettext functions for wrapping all translatable text within the template files. This makes it easier for the translation files to hook in and translate the titles into the site’s language.
“This makes it easier”? Without it, the theme is impossible to translate! Anyone interested in this part of the standards will need to do lots of additional reading.
I believe that because WordPress is primarily an American invention and most popular blogs that cover WordPress are put together by people that reside in the USA, one can unfortunately safely assume that internationalization is not high on anybody’s priority list.
After all, English is the primary language in use on the web, right?
In reality it’s not. The world is larger than the North America. As a matter of fact, as of December 2011 English is being used by only 27% of (online) users worldwide; that is a bit more than one-quarter of the total internet population (via Wikipedia).
I ask you to briefly consider the following: If you are a premium theme developer who properly internationalized your themes, your potential market would instantly increase by four times.
That convinced you, now didn’t it?
The best part is that internationalizing your themes is actually quite easy.
First, I would suggest you add the
textdomain to your theme and to set up a special directory for additional languages. For this to work you need to add the following lines to your
On line 4 you see
mytheme. This is going to be your
textdomain and you will need to replace this with the name of your theme. If your theme name is very long, you can also use something shorter. Make sure that it is unique.
If you are using a child theme you should replace
If you would actually also localize your WordPress theme and offer it with a few additional languages on launch, you would add the .mo files of these languages to the languages directory.
After setting up the
textdomain, next is the actual internationalization of the strings in your theme.
First up is displaying translated text. Let’s have a look at the theme Sunny Blue Sky, which is one of the most recent themes (at time of writing) added to the WordPress Theme Directory.
Via the theme SVN we can have a peek at the theme’s files and we hit the jackpot at the first available file: the 404.php:
The correct way of writing these strings is:
That wasn’t so hard, now was it?
Next up is processing the translated text. To show this I use a string in the
To internationalize this, we change the strings as follows:
Also not super tough, right?
It does actually get a bit more complicated than this as there are more possibilities to write strings; without getting into too much details – after all this information is widely available online – I will list the most common ones below:
Remember that after you have done it once, the second time will be easier, and the third time even easier than that, and so forth. Furthermore there is plenty of information available online and there are people who can help you with it too (for instance the WordPress forums).
Once you have fully internationalized your theme, you will need to make a .pot or .po file, so translators can do their work and add .mo files per translation. You can include this default .po file by adding it to your languages directory.
POEdit is a handy tool that you can use to generate .pot, .po and .mo files of your internationalized theme or plugin. Smashing Magazine published an article on the subject not too long ago, so I’d suggest referring to that.
If you’re looking for additional reading on this topic, I recommend: