launchpad-users team mailing list archive
Mailing list archive
Re: Lost in translations
Peter Clifton wrote:
I made a tarball and uploaded as usual, but some uploads have failed
(with no quoted reason), and I'm not sure the updates which claimed to
have been approved have even been merged.
You should at least have gotten an email with the error. Some of the
failed files had clear errors in them that msgfmt detected, but others
did not. For the ones that look alright, I've asked the system to try
again. I've also re-imported the files in the queue to what appear to
be their correct templates. The only errors I saw this time around were
one deadlock, which is rare but becoming less so with scale (we have an
idea for fixing this), and an error about a header that should be in
your inbox now if it was about one of your files.
The extra imports will have produced some duplicated email for you, but
I hope it fixes the problem.
If I'm working with an individual language, I can upload a .po file and
mark it as being "identical" to upstream. Why isn't there a similar
option for uploading the whole .tar.gz of .pot and .po files?
For pot files, the system has no concept of such differences: the
distinction between published and user ("Launchpad-specific")
translations is there to cope with multiple translation sources, not for
forking of the actual codebase. For forking within a project we have
When it comes to the tarball uploads, the workflow was designed with
Ubuntu in mind. The assumption is that a translator is not going to
upload a tarball of Launchpad-specific translations, but the people who
manage a project may periodically upload a tarball of fresh templates
and upstream translations. So the tarball uploads happen at the series,
package, or possibly template level and contain published translations
whereas translators may upload individual PO files that could be their
own offline work or ones they got from some other source at their own
We've long been too conservative to mess with this. One reason is that
it's very important for us to avoid adding knobs and levers where at all
possible, or throwing too much text at the user. We've been discussing
what we can do to improve this area of the UI recently. Your frank
criticism is a good stimulant for us to do so!
Our library, libgeda has had a major SO_VERSION bump, so the translation
template is now called libgeda35 (not libgeda32). Something appears to
be severly broken in the import, as it is quoting:
libgeda/libgeda35.pot in gEDA Series: trunk
Uploaded by Peter Clifton on 2009-01-25 00:49:33 GMT Will be imported
into Template "geda-gattrib" in gEDA trun
The most likely explanation is that this file was uploaded specifically
from the UI pages for geda-attrib, instead of from the "trunk" page. In
that case, the system does not try to figure out for itself which
template the file belongs to and trusts the context in which it was
About the libgeda32 vs. libgeda35 situation: do you want those to exist
side by side? Or are you saying it should be renamed? We can do
either. I jumped the gun a bit by creating a new libgeda35 template.
If you just wanted me to rename the old libgeda32, please say so and I
can give you a single libgeda template again, with the existing
translations. (I'd leave the filename out of the template, so the
file-to-template matching logic is never thrown off by a name change).
If you do want the two side by side, I'd suggest having a single libgeda
template but in separate release series. You can kick-start the
translations for a new series by importing the translations of the
previous series (or trunk) there, and from there on diverging as the
By the way, this is probably also why the imported translations weren't
appearing. If libgeda35.pot was imported in place of geda-gattrib, then
for all the system knows, that is the latest version of geda-gattrib.
And that means that the existing geda-gattrib translations will appear
as obsolete. The situation is easy to spot when you download a
translation: if (almost) all the translations appear as obsolete
messages, i.e. commented out with "#~", then the problem is most likely
that an import went to the wrong place. I hope the kick I just
administered to the import queue fixes the situation for you though.
The automated translation approval process seems to be broken,
un-necessarily slow, and very frustrating with its lack of feedback, and
sensible project admin interface.
Is there a way we could explicitly mark our project as _not_ using
launchpad for translations any more (if we wanted to)?
Of course. Just click "Change details" from the project's main page,
and uncheck the "Translations for this project are done in Launchpad" box.