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 :)
Shorter URL
Want to share or tweet this post? Please use this short URL: http://ozh.in/jz
Would be happy to help you test such a thing. My case a difficult one: I use rtl :)
I have my doubts about reading file at backend from remote sources if i want translations for plugins/themes. In my opinion the plugin directory at wordpress.org should get the same subfolder architecture like wordpress itself: an i18n folder for each trunc and tag version not been pre-packaged to the download zip. The autor of plugin should be able to give other users (translators) the ability to checkin/checkout there language files. The plugin/theme author is responsible to branch/tag and authorize this translated checkins.
In this way also a plugin/theme language file update management could be introduced similar to the core or plugin update mechanism and would allow easy browsing the needed files for plugins (nessessary for multi-lingual environments).
This would fit much more seamless into WordPress as a new technology. I'm interested nevertheless into your more specific idea to do it beside the road.
(and if interested you will find a complete WordPress plugin compete a bit with PoEdit but pure PHP and Google Translate support at WordPress plugin directory or at my development page)
Maybe we should provide a way within the plugin/theme installer framework for I18N file discovery and download.
Based on the translations ending up in plugins svn and being servered by the wordpress.org download infrastructure.
This could include automatically providing a translated version when a localised install of WordPress does plugin installation.
Maybe a good discussion topic for wp-polyglots/wp-hackers.
It's something that was in my thoughs time to time in the past, we at wordpress italy would love to give users a large library of localized plugins and I can have few people that would love to collaborate tokeep them updated. Unfortunatly in the past i made some translations and some I18N of plugin and sent my works back to the authors… very few give a feedback few added the translations but failed to send me a beta of new version to update the translation, so new release are partially untralsated. Now with auto update it's worst than before.
Having a centralized repository as wp.org that can care for localizations as we do for WP would be great people can translate plugins they love and submit to us locale team for a check and for commit (we need to have a method to give credits to translators) and this will improve the numbers of translations, the quality of them (locale team can write tralsation guide with rule and dictionary for trnaslating some words making the plugin follow the trsnaltion style of WP etc)
I agree with Westi put this on polyglots and hackers and let's do some brainstorming on it!
daima wordpress:)
Don't like your idea on reinventing the wheel but would love to have exactly your technology for posts and pages. Without adding translations inside tags (like most translating plugins do).
I agree with Westi, would be a good thing to discuss this on wp-hackers. I find the localization process to be so annoying that I just don't do it…