Anyone interested in meeting up with a bunch of Ubuntu/Launchpad/free software people is welcome to join us. You can probably pick us up from the crowd by the t-shirts. :)

That was a huge improvement in both usability (IMO, at least: you translate a string in one release and it's instantly translated in all the others) and allowed us to make Launchpad Translations much more scalable (this one is very tangible). Eg. compared to one full week it took us to "open" a new Ubuntu release for translations, it took us full 25 minutes to do that for Karmic and 45 minutes for Lucid.

However, while 'message sharing' has reduced duplication of efforts a lot, it still happens: translators work at the same time upstream and in Ubuntu, and might be translating exactly the same strings.

What can we do to solve that?

Importing latest upstream translations

Well, first off, Launchpad doesn't even know about latest upstream translations. What it gets is upstream translations as they were packaged in a tarball that is the base of an Ubuntu package.

However, that might mean very old translations. For instance, perhaps there was no Ubuntu package re-upload for 3 months. Translations upstream usually get committed directly to a VCS. They'll flow into Ubuntu only when they get packaged into tarballs, and those tarballs become basis for a new package in Ubuntu.

Today, maintainers decide when to release translations to the world, and packagers decide what upstream releases go to Ubuntu users

This means that there are two high bars for translations to flow over before they can get into Ubuntu:

• Upstream maintainers need to release a tarball with updated translations
• Ubuntu packagers need to prepare updated packages from these tarballs, and sometimes they can't even do that (without merging from VCS directly, because upstream might not be releasing 'translations updates' tarballs)

How about we eliminate these blockers with Launchpad?

So, we want Launchpad to directly import upstream translations from their VCS of choice. Luckily, we can depend on our amazing Launchpad Code team and Bazaar community to provide us with a bzr branch no matter what the upstream VCS of choice is. And we already have imports from bzr branches, so we are all set, right?

Well, not exactly. Projects don't like to keep their generated files in their repos. And for upstream projects, we can't really ask them to (since we know it's a bad idea anyway). So, we need to be able to generate templates (POT files) on the fly.

However, that is a very touchy job which depends on the upstream. I.e. it's not the same thing if you are generating a template for GNOME, KDE or regular GNU (gettext-using) project. And many a script that needs to be run to do this could be very risky: intltool itself has a number of obvious implementation details such that any upstream committer would be able to take over the machine it was run on. So, this has to happen in a safe, sandboxed environment.

Not surprisingly, Launchpad already has this with Soyuz. We just need to slightly modify it so we can run template generation jobs on it.

We've split this into two separate steps: developing a library that allows us to generate templates for a particular source code layout (module named "pottery" inside the LP tree, currently only supporting intltool layouts), and working on the infrastructure to run these on the existing Launchpad build farm.

After translations are committed to upstream VCS, we should import them into Launchpad asap

We are in the process of doing extensive QA on this code, and we expect to roll it out next week. But, this is just a step of our bigger vision.

As a side-note, this feature will also be useful for intltool-based projects hosting their code and translations in Launchpad: they won't have to keep POT files committed either.

In Ubuntu or in Launchpad

We could have gone one route and simply imported these upstream translations directly into Ubuntu. It'd be a big win, but it wouldn't work very well for those upstreams which are already in Launchpad. And, since we are looking a bit further into the future, there are other drawbacks to that approach as well (like being able to send translations back upstream).

So, we decided that it's best to import them directly into Launchpad projects, keep their upstream templates there for the future, but keep those translations read-only.

Now, Launchpad internal database model already has a sort of definition of "upstream", though it was never exactly so (which is why we always struggled with the name: over time, the term went from "published" to "imported", and now finally to "upstream").

Through many discussions on different approaches, we decided to go with the fix is_imported flag one.

This will enable us to share translations directly between upstreams in LP (and because of the feature that we are QAing right now, we'll have latest upstream translations in there already, no matter where project is hosted) and Ubuntu source packages.

The way we are going about this is very similar to message sharing we have today. It's just that now different privileges come into action as well, making it all suitably more complex to handle.

This is something that we are actively working on, and something that we hope to deliver in May.

Pushing latest imported translations into regular Ubuntu language pack updates is the final stage

Before we can even consider calling this done, we'll have to do a lot of testing. And we'll need help from community to get everything set-up. First thing to do is to go around Launchpad and make sure that for every source package with translations in Ubuntu there is a linked upstream project, and that upstream project has a trunk branch that syncs with the latest upstream source code.

Next, we'll really need some serious QA to happen. If you are no stranger to Python code, checking out Launchpad tree and trying out pottery on all the intltool branches you can think of would be very useful input.

Or, if there is your favourite i18n layout that you'd like us to support, extending pottery and our auto-approver to deal with it would be a very welcome addition.

Even going ahead and splitting pottery into a separate branch and module would be nice, because it would make it more re-usable (for instance, it could then be used in GNOME's damned-lies) and easier to extend for people not directly interested in Launchpad.

And... How about giving back?

Ubuntu will get latest translations from upstreams then, which is all pretty neat. But, how about contributing the translation fixes back as well?

That is a natural next step. Having the latest templates and translations in Launchpad will allow us to generate very precise diffs between Ubuntu and upstream translations (i.e. we'll know what string is Ubuntu-specific, and we'll know which translations are newer). Then, we'll have to figure out how to submit those upstream?

Should that happen automatically or should it be user-initiated? How will Launchpad talk to each of the upsterams? Launchpad should talk to every upstream as they prefer it, and that may mean per-project, per-translation-team policies. But, I'll come back to this topic once we have the foundation done with getting latest upstream translations into Ubuntu.

I invite all students interested in getting some serious experience with developing a large web application to apply with their project ideas for Launchpad, as long as they relate to Ubuntu as well. See Launchpad help or development wiki to get a feeling of what is Launchpad about.

I'll be happy to mentor anyone interested in doing some work on Launchpad Translations. David has already posted a few ideas to consider that will benefit Ubuntu, but if you have your own, don't hesitate but apply!

Deadline to apply is April 9th, so hurry up!

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.

Benefits

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)

Maturity

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

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.

Would suffer

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.

But, we didn't just push out the code out to check a box on our 'good free software ecosystem participant' list. We want the community of Launchpad.net users to help us improve it and take Launchpad.net even further as the best free software development platform.

As we are learning to be a good community project, do try us out and go for your favourite bug or feature: get involved!

To learn how you can benefit from Launchpad Translations if you are maintainer, developer or translator, join in #ubuntu-classroom on FreeNode today (April 26th) at 18:00 UTC (20:00h for me :).

PS. There is one question I probably won't be answering, and that's why Launchpad is not free software: I don't know more than FAQ can tell you, and I hope it will become free software in the (again, I hope near) future, or I wouldn't be recommending it for your free software development either.