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.
WP-Translations uses Transifex, which apparently offers free services for open source projects. You can see why WP-Translations is using Transifex here.
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.
You got this post dead on Brian. I was about to write similar post.
i18n tools are absolute great. It can for example auto-add header info from plugin/theme and it adds custom page template names automatically. Even better when these i18n tools are in the core.
WP-translations project is also something that I’m very thrilled. Thanks to François-Xavier Bénard for putting that up. I’ll be in that community for sure. Let’s hope that it’ll be something that helps developers and translators make your theme/plugin more useful for non-english users.
It also seems that plugin translations can be loaded from WP_LANG_DIR/plugins/$domain-$locale.mo in WP 3.7. That’s good news for custom translations what I use for now and then.
Thanks for the mention both of you. Hope to see more devis concernés by i18n, they should by nos with all
Thanks for the mention both of you. I’m happy to see more devs concerned by i18n, that’s why I also founded WP-Translations.
I18n is a win-win for the all WordPress community from devs to users.
Devs make your work ready for translations, i’m sure you’ll be surprised to see how much users will be happy to translate it especially with dedicated tools like Transifex.
One of the best tips I received regarding wordpress i18n was to use this translation tool: https://poeditor.com/. It makes work a lot more efficient and simple. I’ve tried comparing it to others, including transifex, but poeditor is simpler to use and more friendly, on top of all its functions.