WordPress is a great blogging platform with a focus on aesthetics, web standards, and usability. However, as Nikolay Bachiyski pointed out on the GSoC2007 WordPress blog (http://codex.wordpress.org/GSoC2007), “there are a number of challenges both the WordPress i18n infrastructure and the WordPress l10n community are facing”.

As an active developer at a Chinese blog hosting site (http://72pines.com/) based on WordPress MU, I believe the improvements in the WordPress core codebase for better handling of internationalization/localization issues would be crucial for attracting more and more WordPress users across the globe. I, together with other developers at 72pines.com, are very excited about the ideas of bringing WordPress to more people in China. After all, China has a population of 1,300,000,000, and more and more people are choosing blog as an easy way to publish thoughts and ideas on the internet.

While a good localization package like the simplified-Chinese package I’m working on can be a good starting point, it is far from perfect. Many things can be done in the WordPress codebase, and the solutions to these issues will not only be beneficial to the huge Chinese blogger community, but also be useful to all blog communities with a native language other than English.

My proposed plan for the Google Summer of Code 2007 contains the following several areas of objectives (most are from Nikolay’s suggestions):

First, relatively easy part:

• Making all strings available for translation via gettext(now some files have to be translated directly);
• TinyMCE;
• All the other JavaScript strings have to be put in a php file in order to be gettexeted;
• Default bundled themes should be multi-language compatible as well.

Second, proposing a scheme for the internationalization of plugins and themes metadata
*This could also related to another area: a plugin update notification framework, because the plugin version should be embedded in the metadata. My current idea is to propose a PHP class for the metadata. So instead of having a hard coded metadata fields, every plugin needs to construct a plugin class incidence with metadata. This way, it is possible for translators to translate the metadata fields.

Third, better infrastructure for translators and possible community-driven translation contributions.
*Possibly a web-based inline translation interface for different languages with backend version controlled. Anyone can contribute to the translation project, but only moderators can commit to the main trunk. Automatic packaging of the translated package is also needed.
It would also be useful when WordPress is upgraded, and the previous translated strings can be easily matched to the new version.

Fourth, possible performance tuning for the gettext or using PHP strings
*gettext is maybe not the best solution for localization. Performance benchmarking has shown that using PHP native strings could improve the performance. While it is unreasonable to push this for all WP theme/plugin writers, but some benchmarking should be conducted to see whether at some point, gettext is going to be a main contributing factor for internationalized WordPress performance.
Reference: http://mel.melaxis.com/devblog/2006/04/10/benchmarking-php-localization-is-gettext-fast-enough/