Internationalization (i18n) and translation is one of those fuzzy gray areas for many of us in the WordPress community, especially amongst Americans. We’re simply not very accustomed to a multilingual society, therefore we sometimes erroneously don’t think about internationalization of our code and translating our projects to other languages.
But WordPress is 20% of all the web, not just the English speaking web. People all over the world benefit enormously when developers offer their projects in a variety of languages. In fact, a third of all WordPress installs are non-English.
A primer on i18n
There is a difference between being “translation ready” and actually supporting languages. To be translation ready, you need to have used proper internationalization in your code itself, and then create files with all of your strings ready for translation. This process is called localization (l10n). That’s what POT (.pot extension) files are.
Here’s a quick rundown of the files in play:
- POT: Portable Object Template – a file with all i18n ready strings.
- PO: Portable Object files – a file with the translated strings and English strings.
- MO: Machine Object files – a PO file converted to a format optimized to be read by machines.
There are a few ways to create POT files, but Tom McFarlin does a great job showing direct steps for doing it one way. I’d love for people to add their favorites to the comments. The Codex also has tools listed for translating WordPress, and 3.7 will have i18n tools included in core. They’ve been public for a long time, but as Nacin noted to me, “no one knew where to find it [the POT creation script]”. I’ll have more to say on i18n and core that I’ll cover in the next couple of weeks.
Once you’ve done proper i18n in your code, and created your POT files, you have then prepared the way for translation. Translators then can take that POT file and translate the project by creating a PO file for a particular language. To see a sample POT file and corresponding MO and PO files for each language, check out Yoast’s WordPress SEO plugin languages folder.
So, each time someone translates your plugin, they can do so because you’ve collected the necessary strings in your POT file, and you can add their translations to your plugin or theme.
A community for translation
I love meta communities. I recently learned of WP-Translations, a newly launched community “where translators meet developers.” It appears, with a Transifex account, you can submit projects for translation as a developer, or translate existing plugins and themes for your language.
Another community you certainly shouldn’t forget about is the WordPress Polyglots team. They have their own Make WordPress blog, and have at least started a draft handbook for WordPress translators. Currently though, it basically links to this excellent resource by Zé Fontainhas on WP Realm. There is also a resources page on the Polyglots blog.
More focus on WordPress in different languages
WordPress has significant growth potential if it can be effectively translated into new languages. And even if WordPress itself is translated, it will take efforts from theme and plugin developers to make it really shine in new languages.
While English may be the international programmer’s language, it’s definitely not the universal web user’s language.
One of the core goals for 3.7 is to improve core capabilities for supporting i18n and l10n, for core itself, core plugins and themes, and even your plugins and themes. I spoke to Andrew Nacin and Otto Wood about what’s in the works, but it’ll be more effective to describe the new tools in a post in a couple of weeks.
Language packs are definitely getting core support though, which you can read about in this ticket; and Matt Mullenweg has said that the language packs being added to core this version will be big for internationalization.
It’s time for us to stop ignoring other languages. Internationalization isn’t a feature. If you don’t have properly localized plugins and themes, you have bugs in your project. That’s all there is to it.