Most of the time, I quite like coding WordPress plugins. Nonetheless, in the programming flow, there is something that I hate: all the localization process that takes place at the end of a project. That is, making sure I didn't hardcode a string that won't be translated, creating or updating the .pot template files ("OK, for the 1000th time, how the f** does Poedit work, again?").
This L10n process has no added value for me as a user, as I've always used the default (ie English) WordPress version. Yet, I know some value it more than I do (I guess a lot of people don't understand a single word of English after all), and, that's were it gets painful to me, a few people put time of theirs into creating translation files for my plugins, expecting me to provide an up to date and clean translating framework. So basically, every time I botched the adminmenu.pot file in my Admin Drop Down Menu plugin recently (by leaving hard coded hence untranslatable strings in it), I sort of wasted kind translators' work and probably confused end users. Sorry peeps.
This recurring problem has got me thinking a bit. For my next plugin, instead of using the built-in translating API (a .pot template file, localized .po and .mo files, internal translating functions such as __()), maybe I'm going to sort of reinvent the wheel (something I always advocate not to do, obviously) with a new concept I still have to polish: the plugin would fetch (and probably cache) translation files from a location a user would point it to, that is from a translator's web site. This way, the translator would be able to update their translation without having to wait for me to include their work, and I would also give them more exposure. The key point being: I would never have to bother with updating the plugin just because of translation files or problems.
Still something I have to work on, but the idea really nags me during my morning showers these days :)
Want to share or tweet this post? Please use this short URL: http://ozh.in/jz