Export import queue for a target in the API

Bug #664327 reported by Jeroen T. Vermeulen on 2010-10-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Medium
Jeroen T. Vermeulen
Ubuntu Translations
High
Unassigned

Bug Description

David Planella asks for the Launchpad Translations web-service API to export not just the translations import queue, but also the queue for a specific target (distribution, distro release series, project group, project, product release series, or person).

ITranslationImportQueue.getAllEntries has a "target" parameter, but we don't expose it on the API. Doing so would pollute the API a bit, since it's one step further away from the method returning "all" entries. On the other hand we see no reason not to export IHasTranslationImports.getTranslationImportQueueEntries.

Related branches

El dj 21 de 10 de 2010 a les 07:20 +0000, en/na Jeroen T. Vermeulen va
escriure:
> Public bug reported:
>
> David Planella asks for the Launchpad Translations web-service API to
> export not just the translations import queue, but also the queue for a
> specific target (distribution, distro release series, project group,
> project, product release series, or person).
>
> ITranslationImportQueue.getAllEntries has a "target" parameter, but we
> don't expose it on the API. Doing so would pollute the API a bit, since
> it's one step further away from the method returning "all" entries. On
> the other hand we see no reason not to export
> IHasTranslationImports.getTranslationImportQueueEntries.
>

Thanks Jeroen for looking into this and filing the bug.

Just a bit of background on the rationale:

Right now, one of the tasks that takes most of the time from the Ubuntu
Translations Coordinators team (UTC) is manual work in the imports
queue: approving templates, fixing paths, blocking templates, etc. In
the case of big source packages (take KDE or OpenOffice.org), manually
processing hundreds of packages is a task that can take several hours or
days, which could be best spent working on community-related aspects -
apart from the fact that repetitive manual work is very prone to
mistakes, as I've had the pain to experience.

Often, when there really isn't any other option, we resort to the
Launchpad Translations developers to fix entries through database
surgery, but that's still not optimal: it takes both developer and LOSA
time, and it is also not without a risk regarding entry data loss or
corruption.

I'm not sure if extending the imports queue API will be the holy grial
in terms of solving everything, but I'm sure that it will very much
reduce the amount of time we spend taking care of the imports queue.

I'm also adding a task for the ubuntu-translations project. Not a bug
per-se, but as the queue which sees most activity and is most looked
after is the Ubuntu one, I'd like the UTC team to be in the loop.

Thanks!

 affects: ubuntu-translations

--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

tags: added: qa-needstesting
Changed in rosetta:
status: In Progress → Fix Committed

Marked as qa-ok after minimal QA on https://translations.qastaging.launchpad.net/phpdevshell/trunk/+imports to confirm it doesn't break existing API use on the web UI (so it wouldn't block deployment), but Jeroen, please do proper QA on this further.

tags: added: qa-ok
removed: qa-needstesting
Jeroen T. Vermeulen (jtv) wrote :

This actually failed in Q/A due to an apparent inconsistency between our webservice test browser and launchpadlib (see bug 668190). Dealing with this separately as bug 668194.

David Planella (dpm) on 2010-11-05
Changed in ubuntu-translations:
status: New → Fix Released
importance: Undecided → High
Curtis Hovey (sinzui) on 2010-11-17
Changed in rosetta:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers