I am way behind in blogging about DrupalCon Boston 2008, which was truly a blast. It was the biggest and best organized Drupal conference so far, and was put together in record time. I was happy to come early to Boston and stay a bit more with people who had their flights cancelled, and others who simply live in Boston to tourist around the city as well.
The conference provided lots of opportunities to be productive on-site in the BoFs and on the code sprint which followed the conference. Honestly, I intended to work on some of my core modifications for filters which (unfortunately) are still not in patch form, but without network connection for a considerable time, I needed to look into what I have on my computer, and figured I should work on the top priority contrib issue in my projects, as identified at the BoFs. Read on to find out more.
Among others, two nice modules run under my name (building on lots of community contributions) for localization named localization client and localization server. The former allows you to browse through your own web pages and translate text as it appears on your webpages. It works with the built-in Drupal locale database and works very well. People love it. The later module is a server which parses tarballs of project releases, extracts translatable strings out of them and provides a community collaboration interface to translate all of those, sharing the work between different projects. People love this as well, lots of translation teams already use it, although it is still in alpha stages, and most probably has bugs and surely has weaknesses.
So you use the l10n_client if you translate your own site, you use an installed entity of the l10n_server if you are primarily a community contributor and work on project translations disconnected from the running interfaces of those modules. The goal of both modules is to free you from the hassles of Gettext, Portable Object files, merging translations, committing them to CVS, branching CVS trees, handling translation releases, coordinating with project owners on their releases, and lots of other hard things.
It is understandable that people find the l10n_client interface a lot more comfortable then the l10n_server interface, and although we are also in the process of redesigning the l10n_server to look more like the l10n_client, it is still a different approach for localization. So what about allowing you to do what you find most easy and most valuable for yourself: translate on your own site, and share each piece of translation as you go along without any extra effort. This was my goal on the code sprint.
Some technology problems (I had at the code sprint) aside, and with some usability additions later on since the code sprint, here comes the connection between the l10n_client and server! Latest development versions of the l10n_client allow you to set up sharing translations with a community server. Upon submission of the settings form, the l10n_client checks whether you actually provided a server URL, which would be able to receive your submissions (supports the same API version used by the client).
If all is set up well, anytime you translate one string on your site with l10n_client, without even thinking about it, l10n_client automatically calls out to the community server, and shares your translation with the community as well. You can contribute in byte-sized chunks, without any extra effort, or knowledge about projects, releases, Gettext, or whatever. It works naturally for you. If there was some issue with the sharing (ie. you were not logged in on the community server, and the server could not store credit information for you), a note is displayed, so you can go and fix the issue.
Since this is both available in the development version of the l10n_client and l10n_server modules, the l10n_server sites listed on the project site still need time to catch up and install the latest software. Most are probably informed only with this blog post.
Notably, there are some limitations of this approach which need to be pointed out. First, the setup only allows one server, while right now there are different servers for most different languages. The plan is to have one central server on drupal.org set up (after the pressing issues with the module are worked out), so this will not be a problem later. Right now this is a limitation, which might be lifted later with per-language server setup, if the drupal.org installment is not drawing near soon. Also, another limitation is that this only shares strings you newly translate. It is still possible to export your translations as a Gettext PO file (feature built into Drupal core) and hand that over to the translation team, where it can be imported to the community server. A more automated way to share existing translations might be devised later.
Finally, the natural question of seeding the clients with translations from the server arises. Yes, this is on the map somewhere , but not an immediate priority.