I'm happy to report that on http://localize.drupal.org, the past month have seen British English, Estonian, Filipino, Finnish, Lolspeak (yes, lolspeak), Persian (Farsi), Punjabi, Romanian, Slovak, Slovenian and Tamil added; growing the list from 33 languages to 44. We've also grown to almost 500 contributors which means about 11 contributors per language on average.

Focus on the past few weeks was on improving the user interface and submission feedback on imports as well as adding test coverage for imports and fix some odd bugs found by active users. The freshly deployed new import screen is now much more usable, showing what will exactly happen when either option is chosen:

We've seen people having problems with the attribution and status options before, given that they were checkboxes assuming a default behavior from where one could divert. Now all paths are clearly explained, so those importing .po files should know exactly the results to expect.

We've also worked on fixing bugs. Claudiu Cristea was very active submitting suggested fixes which got refined, committed and deployed. Thanks to those efforts, the translation view screen now handles plurals properly, languages with more then 2 plural variants got the plural string copied to those further fields as well and the moderation screen now properly remembers the selected filters on form submissions. I've also worked on signaling errors for modules which have empty strings to translate.

Work is still ongoing towards an improved translation interface, first breaking out more granular permissions for moderation. Help and testing is - as always - welcome!

While Gerhard Killesreiter is working out solutions for queued .po file imports (to work around the relatively big resource needs we have on an import), and Jose Reyero is working on building translations to actual .po files which people (and automated clients) can download, Konstantin Kaefer was busy with the user interface of the module.

Let me focus now on Konstantin's ongoing work, because it is in need of your feedback. A major update to the translation user interface like this should be done with your feedback heard. So I've studied the new features (and Konstantin's previous video) and made a demonstration video with the up to date functionality.

The new approach introduced treats translations and suggestions more on the same level. So when a string has a translation and outstanding suggestions, you can review them on the same level. The advantage for translators is that they can see previous suggestions and take them into account when composing their suggestion. Duplicates (which are catched by the server) would not take time to write anymore. Also, the active translation and the outstanding suggestions can be viewed in a diff view (when hovering over one of the strings, differences to the others are shown). This helps reviewers to figure out actual changes in relatively long strings. There are also some other niceties with the diff coloring, since it includes marking HTML tags and their closing pairs as well as placeholders. So you can match the placeholders from the English original text to the translation or between the different suggestions. Treating outstanding suggestions and translations on the same level allows you to filter for all of them at once (with the contains and author filters).

The approval workflow also changes with the patch. When you approve a suggestion to be the active translation, you don't need to disapprove all other outstanding suggestions for the same source. You can pick declined suggestions one by one or actually disapprove all other strings by approving the best translation with a double click. After saving your changes on the form, you cannot get back the declined suggestions, but before saving your changes, you can still undo your decisions.

Check out the video here (or as hosted on vimeo) and provide your UI feedback on the issue at http://drupal.org/node/563128

Through the previous days, several small to big changes happened on localize.drupal.org, so I thought it would be a good idea to write a quick post summarizing the changes.

Many people brought up the need for "wordlists" on localize.drupal.org in the past. These would be (maybe not so) mini dictionaries per translation team, so people coming in would be able to quickly accommodate themselves with the terminology used, without the need to infer that from other translations. The basic form of this would be a table with English and suggested translation words. While this can just be a full HTML input format node (to let you put in a table), ideally we'd reuse this data to actually help translators.

Thanks to many hours of work from Jakub Suchy and myself, I've integrated and deployed many performance optimization and caching improvements on localize.drupal.org tonight. The front page and the main explore pages (explore languages and explore projects) are now using fully cached data, so will load way faster then before. This is on the expense of absolute accuracy.

We have seen certain teams eagerly pushing for their groups to be created on localize.drupal.org as soon as possible, no matter what. I've just received a personal contact email which even included this remark about the process, so I decided to repost the reasoning here for the public to read and hopefully understand.

[...] I want to know why this process is so ugly - we need to make some bureaucracy for adding active projects into drupal growing process

I don't think it is ugly, but I agree it might not be clear. We need to ensure that other random people speaking your language are not taking over your existing fine work. (Ie. they do not open a new team without consulting the existing project/team maintainers). So we need to ensure that whatever previous work was done in the given language is cleared in terms of cooperation, so we are not opening some new parallel effort. This is hopefully ensured both by looking for existing teams and asking for their feedback and by letting the issues sit for some time for others to find out about what is going to happen.

Also, similar issues apply to some people having tensions inside language teams and wanting to fork translations. While this happened before with multiple servers per language with overlapping projects or with one server for core and another for contrib translations. We are actively discouraging that and trying to get people under the same roof. We are providing a (hopefully) good infrastructure for people to just concentrate on translation, so that they don't need to suffer from the maintenance overhead.

Those creating a team should understand that this will be the primary source of their translations and they should not do work in CVS without adding to the web service too and they should not operate a localization server elsewhere with the same team for Drupal.org projects. Many of the teams run localization servers before and we need to migrate that data, which takes some time given the accumulated suggestions on those sites, for which we have no tool to import. The issues are used to make sure that those, who open the teams understand these goals and directions and go with them.

Finally, we are beta testing, so the less people experience big issues the better; but we need people to experience those issues for them to come up and get fixed. Those starting early on the localize.drupal.org site naturally experience more issues then those coming later, since the base issues should be resolved by then. For example, we expect to roll out some performance improvements later as performance issues are starting to show and could get painful if we open the gates freely to any number of translation teams.

As with new software, it is not about secrecy or exclusiveness, it is about doing things right, so that you'll suffer less. You should not feel shut out if your team is not created within hours of your initial issue being submitted, there are teams waiting for up to a week already. Please be patient as we go through the process, it is to ensure that your existing contributions are valued and that you can effectively work on the localize.drupal.org interface when you get there.

Some of the reasons above will apply later as well, so I'm not expecting that the moderation based group creation workflow will turn into a first come first served free-for-all process in the long term either.

The fine folks, many of whom also did the Drupalcon Szeged video recordings were in Paris to do the video recording for that conference too. Finally, my session video is online, so you can watch most of my session about localize.drupal.org hosted on archive.org. It was uploaded in two parts, so to watch from (almost) the start to end, watch them in succession. To download in different formats, go to http://www.archive.org/details/Herecomeslocalizedrupalorg

I've posted my slides previously at http://acquia.com/blog/drupalorg-steps-helping-localized-drupal-installs... and http://localize.drupal.org/node/119