Thanks to the diligent work of Jose A Reyero and myself, I'm happy to announce that starting from about an hour ago, we launched new filtering options and a moderation screen for easier translation management.

New and more granular filters

Over Drupalcon Paris, we added and launched more granular status filters, which allow you to separately filter for translated/untranslated strings and ones with suggestions or lacking suggestions. These were in one bizarrely integrated filter before, and now are separated.

Today, we also launched two new filters on the Browse and Translate screens. First up is the author filter. That allows people to look up translations submitted by a given user on the site. This also works for suggestions which were approved unedited, because that is directly attributed to the submitter as well. Note that since the Browse and Translate screens filter by the translations themselves, the added filter does not allow filtering for strings which have suggestions submitted by a given user. Just like the "Contains" filter only looks at the source string and the active translation, but not any of the suggestions.

The other added filter is a new limitation capability. Now you can limit your workspace to less or more strings, so if you are unsure about your internet connection, you can work in smaller chunks, or if you are a translator hero, you can churn through more strings at once. In the plans are a more specialized UI for the case when limiting to 1 string at once (not among the limit options yet), which would help you achieve better translations faster.

New moderation functionality

Thanks to previous work done by Jose A Reyero, we have new moderation functionality for suggestions right at your fingertips. While the same filters apply, these actually look at the suggestions and not at the translations, so using the "submitted by" filter will look at the authors of the suggestions in this case, or using the "contains" filter will search in the original string and the suggestion. So these filters complement the lookup functionality of the other screens and also provide bulk actions to work with suggestions. If a user accidentally imported .po file with different language translations, you can filter those out quickly here and decline those to clean up your database.

This was among the top feature requests from people, and many translation teams just solved these mass-moderation issues with SQL queries on their own localization servers. Not having such functionality was a blocker for established teams to move on the central server both due to not having a tool to clean up their suggestion queue to import fresh to the central service and to manage new suggestions onwards on the server. I'm hopeful that this new functionality will both help people to migrate and existing teams to handle the amazing number of suggestions cropping up for the existing teams.

Tested backend

Because this is the first huge public install of the localization server, it was important for the sustainability of the development to have automated tests. There are many interesting improvement waiting in the issue queue, but sometimes it is scary to commit changes which modify the database or the UI in big ways, since there are not many people testing these patches. Therefore I went ahead and took a lot of time to write automated tests for the underlying code.

In fact, I went to write tests for the Translation template extractor powering the source code parsing functionality of the backend, now covering Drupal 5, 6 and 7 source code parsing. The module supports parsing Drupal code on all three APIs, but there was no automated tests to verify that. Now we have 70 passing asserts to verify parsing for all three major APIs.

Testing of the localization server itself was a much bigger feat to be honest. The test written reuse the source code from the Translation template extractor tests, package them up into tar.gz packages disguised as Drupal modules ready to be parsed, even with different releases. Then all of them are parsed up and checked for their appearance on the database/output. The tests add suggestions, verify the individual and mass moderation screens and filtering by different criteria, including all the new features mentioned above. Direct translation submission is also covered. The tests now have 634 passing asserts, and do not include testing of imports, exports and translatability error listings yet.

All-in-all, the new testing setup helps us ensure that big changes like the above get in well-tested. I've found one bug in our existing code and four bugs in the patch before being committed due to test coverage for its functionality. After all users of the online service benefit by getting tested new features to be more effective in their work.

A shout-out for those of you waiting in the l.d.o issue queue

We already have 18 translation teams set up on localize.drupal.org and more then that waiting in the issue queues. I'd love if those waiting in the issue queue understand that our current phase allows us to get the existing teams find issues so teams coming later will suffer less. We also need to clear off previous contribution histories, so teams starting off on localize.drupal.org inherit the translations from CVS and previous translation servers and not start over from scratch. We believe it is important to build on previous work and ensure that we have one definitive source for translations, so users do not need to hunt around the internet to find the latest and greatest translations for their modules and themes.