Split templates for Avogadro project

Asked by Geoff Hutchison on 2009-05-20

I need to add a new template "libavogadro" to the Avogadro project -- we split the larger template into two smaller ones:
- avogadro (the main userspace application)
- libavogadro (the library, now used by other packages)


But when I upload libavogadro.pot, it merges it into the existing "avogadro" template!

I also need help to delete the current en_GB translation. It got horribly mangled in a merge with the packaged PO file. If you delete the current translation, I can upload a new PO and everything will be perfect.


Question information

English Edit question
Launchpad itself Edit question
Данило Шеган Edit question
Solved by:
Geoff Hutchison
Last query:
Last reply:

We seem to have a bug where we incorrectly match templates by the substring, instead of the full pathname (so, "libavogadro" is matched against "avogadro").

It seems you managed to get templates working by now, though. About fixing up translations, it would require a bit more time, and we are currently sprinting, so it'd be best for it to wait until next week. Can you explain exactly what do you want done there (removing is our last resort, we'd rather fix data as much as we can).

It would help if you describe what you did so we can more easily revert the situation. Thanks.

Geoff Hutchison (geoffh-pitt) said : #2

What happened was that I uploaded an avogadro-es.po file into the en_GB slot (i.e. https://translations.launchpad.net/avogadro/trunk/+pots/avogadro/en_GB/+upload). Incidentally, I think there should be an additional field in the PO templates which prevents this. Perhaps you can add:

"X-Launchpad-Code: en_GB\n"

Anyhow, this translation is now very confused. If you take a look at the summary page, you see that the percentages add to over 100%:


We have tried uploading revised PO files both as "user" and "packaged" with little effect -- most of them fail.

If there's some way to fix it, great. Otherwise, we can upload from a known good PO file.


I'll be happy to look into all this, but is it fine if this waits for next week (i.e. you are not planning a release next weekend or something)?

(had to change status as it's required by this launchpad.net thingy, please put it back to "Open" so it comes back to my attention :)

Btw, the above statistics bug is fixed in our "development" version, and should land on production any time soon. Check out


Geoff Hutchison (geoffh-pitt) said : #5

The statistics bug fix looks great.

I'd still like some sort of reset on the en_GB translation, since we can immediately rebuild from a known good PO file. This can wait a week or two. We have a release, but we also have a working PO file for en_GB.

Incidentally, I do think there should be a mechanism to prevent this:
* An X-Launchpad field with the exported language code
* Checking the filename for a language code

If either of these is present, the import should not work for a different language without explicit approval.


Launchpad Janitor (janitor) said : #6

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

We still haven't resolved this.

Ok, we've fixed a bug that was stopping imports of certain files. I've re-marked your "Failed" files as approved, and they got imported now, so I believe all should be fine. Sorry for this taking so long, we've had a bit of a fight with this bug, and it seems there are still rare instances where it can bite us.

Also, if you still want us to remove all translations so you get rid of bad suggestions that now appear, please say so and we'll do it (and we'll be faster this time :).

Geoff Hutchison (geoffh-pitt) said : #10

Yes, if you could remove the en_GB translation, I can rebuild it from the PO file quickly.

Thanks for all the help!

Scheduled removal as well: https://pastebin.canonical.com/19695/ (don't worry, you can't see this, it's internal).