Warning: This is not a plea to move GNOME translations to Launchpad. I am just publishing an analysis I did about how suitable Launchpad is for translating a big project like GNOME. I am using GNOME as an example because that's a big project I am most familiar with.
If GNOME was to switch translations to Launchpad today, this is what would happen: I am listing all the benefits, status-quos and missing features compared to what GNOME does today.
- Easy to use web interface
- Some would debate this, but Launchpad web interface is easy to start with, and good for maintaining translations as well: global suggestions help maintain consistency and speed up the work, review mechanism allows someone to ask for a peer review, etc.
- Translations sharing between different releases
- No need to put in extra effort to do identical translations for both GNOME 2.28 and latest trunk when all the GNOME modules branch for the 2.28 release; also, translation fixes can automatically go to 2.26, 2.24,... for any distributor's benefit who wants to keep using those older versions
- Automatic commits of merged translations
- Launchpad can provide automatic export of all translations merged with latest translation template as a bazaar branch (this can easily be used to automate commits to a git branch as well); there is one big caveat here, though (see below)
- Not saying that GNOME's damned-lies are immature, but Launchpad is a complex system that is capable of delivering translations for entire Ubuntu which has over 300k translatable messages. It also does many things like taking care of conflicts between multiple translators working at the same time, etc.
Stays the same
- Ability to work on PO files off-line
- One can easily download a PO file from Launchpad, work on it using their favourite tools like Gtranslator, KBabel or po-mode, and upload it back when they are done
- Ability to control who can do the translation for each language
- Project in Launchpad can decide to let only translation team members for a particular language review translation suggestions (which anybody can submit); if there's no team for a language, project can decide either to lock those translations out, or to let anybody submit them; if needed, even translation suggestions can be limited to team members only
- Ability to directly submit translations to git repos without going through the web interface
- Launchpad will automatically pick these up as well, and import them pretty quickly, and the chance of conflicting translations will be minimal; even if conflicts happen, Launchpad will handle them gracefully but letting the last submitter review all the conflicts
- Communication between translators still stays outside actual translations — this is not a good thing, and would be great to add to Launchpad; still, external mailing lists and forums is what everyone is using anyway, and Launchpad can even host mailing lists.
- Statistics and regenerating POT files
- Today, Launchpad can't regenerate POT files for GNOME modules, meaning that we can't import the latest POT files automatically — this is what Damned Lies is doing for GNOME today (however, without this, it'd be worthless to try to do automated commits), and up-to-date statistics are impossible without it
- Workflow management
- Launchpad has a slightly different concept of workflow management compared to damned-lies, and it's missing some core features like PO file assignment, and PO file submission for review (while it has even better review capabilities when translations are submitted through the web interface, there's nothing to allow submission of PO files for review: they are either rejected or accepted)
- GNOME specifics
- Damned Lies is heavily geared toward GNOME and thus can do things for GNOME that no other platform can. For instance, it's able to track string freezes for GNOME and email gnome-i18n about any problems. Or, report about intltool setup problems.
- Complete control
- Even though software behind Launchpad.net is free software, Canonical is still the major driver behind it. However, GNOME community would be able to implement any features they need (like the above workflow management or string freeze support) without anyone complaining :)
After this analysis, I feel reasonably confident that Launchpad is already pretty good for large projects wanting to manage their translations. Yes, there's always room for improvement, but there's already some workflow management, and one can live without built-in string freeze support.
And, since it's already "decent", the new focus for Launchpad is going to be slightly different from what it was in the past few years. That means that we will not concentrate on improving Launchpad for projects hosting their translations in Launchpad, but instead on having a two way communication between Launchpad and upstreams (especially upstreams living elsewhere).
As such, we will definitely not work on improving the Launchpad to provide string freeze abilities for a project, or to improve workflow management. We will, however, work on regenerating POT files because that's implicitely related. But more on that in the next few days.