Translation imports: making approval conflicts visible

If you use Launchpad’s Translations feature, then as of today, you may notice a new kind of error for uploads in your translations import queue. Look for the “info” icon next to your upload’s status, and click to unfold. The error message says “Can’t auto-approve upload: it’s not clear what template it belongs to.”


You may find this annoying, and as the person responsible, let me apologize. I hope when I’m done explaining, it won’t seem so bad.

To the right is an example of the error.  Click it to see more.

Where does the error come from? Actually it’s a problem that’s always been there, but instead of telling you about it, we Launchpad developers tried to hide the complexity from you and take care of it all ourselves. And we weren’t keeping up. Some of your uploaded translations would just sit in the queue forever, with status Needs Review, for no clear reason. All that’s changing now is that Launchpad will tell you when this happens, so that you can deal with it without waiting for us.

Why do some translations sit in the queue forever?

Every translation you make in Launchpad has to go into a specific template and language. Usually it’s obvious where you want your translation to go: when you translate in Launchpad’s web UI, you’re already on the page for a specific template and language. If you have upload privileges for the project and language, you can follow the upload link from that same translation page and again it’s obvious which template you’re translating and to what language. If you always upload the same file with exactly the same name and path, new uploads of that file go to the same place as before. But what if you upload a new file from the release-series page, or the translation comes in from a Bazaar branch or an automated build?

Then it’s up to a script we call the Translations Import Queue Gardener. The Gardener periodically scans all waiting uploads—the ones marked Needs Review—and tries more advanced ways of matching them up with known templates and languages. When it finds a match, it approves the upload’s import to the template and language it has found.

One of the Gardener’s most important tools is a template’s ”translation domain.” This is a simple name; no slashes or weird characters allowed. Launchpad figures out a template’s domain when you first import the template, based on its directory path. In principle a template’s domain should identify the template uniquely on the end-user’s system, but Launchpad isn’t as strict about it. It just assumes that the domain name is tied to the template file’s path within a project’s source tree. You probably shouldn’t, but you can give your project two templates with the same domain if you want.

When you upload a translation, the Gardener tries to figure out its translation domain based on the file’s path, just like what happened when the template was created. The Gardener looks for a template with the right domain in the same release series. If it finds one, presto: it’s got the template that the upload is meant for. If not, then the Gardener tries a few other things and if nothing works, simply keeps the upload on the queue.

So the entry doesn’t get imported, but usually the Gardener can’t give any single reason: all it knows is that it tried many ways of matching the file to a template and none of them worked. Maybe it’s an error; maybe it’s just a matter of waiting for the right template to be created.

So what’s changed?

The new error message is about “approval conflicts.” You’ll see it when there is ”more than one” matching template for your upload. This can happen because your project’s directory structure is unusual and Launchpad can’t extract a meaningful domain from it. Or a template’s domain may have been changed, or an old deactivated template is reactivated when a new one has already taken its place.

Whatever the cause, the new error message tells you that this has happened, and what the matching templates are. It’s up to you to decide what needs to be done about it:

  • update one of the templates’ domains, or
  • deactivate an obsolete template, or
  • move a file, or
  • re-upload your file to a specific template, or
  • re-upload your file with a different name, or
  • upload translations as a tarball so that Launchpad sees their full directory paths.

How much you can do, of course, depends on the permisisons you have. Only the project’s owners (and Launchpad’s administrators) can deactivate templates or change their domains. But you can always delete your own uploads if you want to upload your file differently: on the import-queue page, click on Needs Review and select Deleted instead.

Let us know

There’s still plenty more we’d like to do to make imports easier and more efficient, if we can find the time. But I hope this small change will make your life a little easier.

Is this error message working for you? Is it helpful? Are you seeing a lot of these errors, or none at all where you were expecting them? Is the explanation unclear? Do you see something happen for lots of people that we could fix in the same way? Please get in touch:

  • Contact danilos or jtv on IRC, in #launchpad on Freenode.
  • Find or file a bug if it’s broken.


  • If you want to become more familiar with the translations import queue, check out the global queue to see all uploads in Launchpad. The version you see there is just a copy on a test server, so don’t be afraid to play with it.
  • By the way, did you know about our test servers? We test our changes on staging and qastaging servers before they go live. You can try out most of Launchpad’s features there. Look for the grey “demo” text in the background. They get restored to a fresh copy of the real Launchpad once a week.
  • Tired of creating translations tarballs and uploading them to your project? Automate it all with Bazaar integration.
  • You want Bazaar integration but your code is hosted outside Launchpad and/or in a different revision control system? You can tell Launchpad to mirror a branch from elsewhere. Then you can import translations from the mirrored copy.
  • We like transparency! If you’re interested in the engineering details of this change, it’s all online.

Leave a Reply