Launchpad team is together in Prague, and we are meeting tonight at around 19h at Jama Steakhouse (V Jámě 7).
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. :)
Last year we introduced a feature we internally called 'message sharing': basically a mechanism to directly share translations between different releases of a same project or of the same distribution.
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?
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.
This means that there are two high bars for translations to flow over before they can get into Ubuntu:
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.
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.
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.
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.
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.
This is the first time you'll be able to work on Launchpad as part of Google SoC: last year, it has been released under AGPL, thus making it a free software project. It is done as part of Ubuntu SoC, though, so your project has to benefit 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!
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.
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.
For anyone living under a rock: Launchpad.net software has been published under AGPL 3.0 license on July 21st.
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!
As part of Ubuntu Open Week, there are also a couple of Launchpad sessions, including one on Launchpad Translations by Carlos and myself today.
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.