Crowdsourcing WordPress i18n
During one of the wrap-up talks at WordPress Community Summit 2012, @nacin dropped the hint that a crack team was working on modifying the i18n/l10n system within WordPress to allow incremental / on-demand deployment of “language packs” with new .mo files, independently of the core update cycle.
This is a huge step toward enabling complete localization of WordPress, but the scary-cool part is for plugin developers – opening the door for third-party translations to be easily pushed out without necessitating a full dot revision.
[Skip all the verbage and take me to the pretty UI pictures]
Much (okay, all) of the details were clouded in much mystery, but it seems that there would be some kind of server / repo component (I envision something like Trac, only not like Trac) where designated community translators can log in, create translations for core, plugins, themes, whatever, and then push them out into language packs, which would then pop up in your Updates panel whenever your wp-cron did an update check.
Cool. But There’s a Bottleneck.
The bottleneck of course are the community translators themselves. Having the responsibility to translate all those strings from all those plugins, particularly if the plugin addresses functionality from some knowledge domain outside the purview of the translator’s expertise. This could be the case of building a state-of-the-art sports arena that never gets filled to capacity.
But if we crowdsourced the translations?
“Crowdsourcing” is such a buzzword these days, but in the case of a community-driven project like WordPress, especially in the domain of i18n, it couldn’t be more appropriate. All that remains is setting up the technology in such a way as to make it really easy for any user to submit their translations, improvements, even new locales, without even knowing what a .pot, .po or .mo file is, and without having to visit GlotPress (which I’m not even going to link to here, because trust me, you’ll just find the site confusing).
So here’s a draft UI. Beyond proposing a home for i18n features within the WordPress Admin, I’m proposing a very user-centric way of submitting translations / improvements / spelling fixes for core, plugins and even themes. When a user enters “Translation Mode” for a specific component (ie: core, a plugin, a theme), all localizable text – __() and its derivatives – becomes “hot” and can be translated / fixed with a click of a button.
Where do we go from here?
I’d like to see whether this approach has merit. I am soliciting comments from the community. Please don’t be afraid of Disqus – feel free to comment anonymously.




Pingback: Can WordPress i18n be Crowdsourced? - WP Realm