Translations/Specs/ReportingAPI

Not logged in - Log In / Register

Launchpad Translations Reporting API

This Launchpad enhancement proposal discusses extending the functionality of Launchpad Translations by developing an API which will expose the necessary interfaces to allow read access to translations-related data from Launchpad through launchpadlib for reporting purposes. API access will be provided for both translatable distributions and projects in Launchpad.

On Launchpad: https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-translations-reporting-api

User stories

As an Ubuntu Translations Coordinator
I want to be able to report on the status of Ubuntu translations at the distro level (only default installation source packages)
so that I can present the data to the community in a way they can see the real status of translation, track their work, set translation goals, and in short, improve the translation coverage in all languages

As an OEM Engineer
I want to be able to create an automated report on the translation coverage of a set of source packages in a given set of languages
so that I can inform a customer and assess whether additional translation work is required before shipping

As an Ubuntu translator
I want to be able to obtain translations data in an automated way
so that I can present and use the data in alternative ways that will help my team better organize translation work

Rationale

Due to other higher priority development work, the Translations component has been lacking a full API for quite some time now.

The need of an API arises now from the necessity of better reporting the status of Ubuntu translations. The main benefit accessing data through launchpadlib can provide to Ubuntu is on the statistics reporting side: currently the main access point to translating Ubuntu is at http://translations.launchpad.net/ubuntu. This view offers statistics to all translatable packages in the main and restricted repositories, regardless of distribution. While complete, it does not provide information on how well translated Ubuntu is as a distribution. This information can be very useful to Ubuntu translators in assessing what needs to be translated and on which packages they should concentrate their work. This can also be used to track progress, set up goals, and in short, as an aid to building community around translations. In the same way, this can be useful for commercial customers to assess translation coverage when evaluating to ship Ubuntu in a given language.

As the current focus of Launchpad development is on upstream integration, and as there is no planned UI work in that area, an API appears to be the most adequate way to allow accessing the Launchpad Translations data and present it in alternative ways to suit the stakeholders' needs.

Stakeholders

(David: as the drafter of this proposal, I'm regularly in touch with all of the stakeholders)

Constraints

The new behaviour must provide a way to access translations data from Launchpad, either in read (or depending on the value) or write mode through launchpadlib, without the need for an admin to query the database directly.

It must not provide any additional functionality or a way to circumvent any security privileges built in the layers above (e.g. Launchpad UI)

Subfeatures

This section will be used to list every separate aspect of reporting, with ATTRIBUTES lists as the proposals for the direct data to be exposed and METHODS as indirect data that can be obtained by calling a web app method or another referenced resource

Language

ATTRIBUTES:

Language Set

METHODS:

PO Template

For each template the following data would be required:

ATTRIBUTES:

METHODS:

PO Files

ATTRIBUTES

METHODS:

Source Package

We already have a few exported attributes for source package, but to help in identifying translations moved to univers we also need to know the component for this sourcepackage (https://api.launchpad.net/+apidoc/devel.html#source_package)

ATTRIBUTES:

METHODS:

Series (distribution and product)

METHODS:

Workflows

The idea behind this workflow is simply to use a gradual approach, which will be easier to get right and get landed, without ending up with a too large a branch to review or follow.

Success

Although the intention is to propose a full API, the two main success criteria are the implementation of API functions for reporting and the imports queue, so we will know that we are done when we can report on the status of Ubuntu translations at a distro level (i.e. on a given set of packages, for all Launchpad languages) by having sourced the data trough launchpadlib.

The success can be measured in how seamlessly this data can be obtained and in whether all requirements in terms of exposed data have been implemented.

Thoughts?

Translations/Specs/ReportingAPI (last edited 2011-02-22 15:34:23 by dpm)