Gsoc: Full API for Launchpad Translation

[Danilo Šegan]

Hi Dhastha,

We did already chat on IRC, and I am happy to see you are interested to
work on this.

У уто, 06. 04 2010. у 04:30 +0530, Dhastha Gheer пише:

> My Name: Dhastha Gheer
> Email Address: dhasthagheer [at] gmail [dot] com
> IRC nickname: dhastha
> Launchpad ID: Dhastha
> Skype username: dhasthagheer
> Webpage/blog: http://dowithlinux.wordpress.com
> College-University: Pallavan Engineering College, Kanchipuram, Tamilnadu, India
> Major: Computer Application
> 
> 
> 
> Project Name: Full Launchpad Translations API
> 
> Project description:
> 
> Using Launchpad, we can translate free software projects and
> distribution packages into our own language. The aim of this project
> is to implement a full Application Programmable Interface for the
> Launchpad Translations component. With launchpad-lib we can integrate
> our applications into Launchpad without knowing a lot about HTTP
> client programming.
> 
> API COMPONENTS
> 
> 1. Reporting
> 
> If a project already being developed one of the component Reporting
> will display in what languages it has been developed, How many
> contributors in each language, status of project, How many project
> have to need review, how many texts are changed
> 
> 2. Import Queue
> 
> We can import our translating file from a Bazaar branch. When
> importing translation files into Launchpad from a tarball or a Bazaar
> branch, we must follow launchpad's translations import policy. So our
> API must check tarball or branch
> 1.Contain at least one .pot file with English strings, rather than
> message IDs or another language. We cannot upload a .po file on its
> own.
> 2.Give each template its own directory
> So using this component we can follow the constraints of Launchpad
> importing guidelines
>
> 3. Translation
> 
> This component will help us to translate a software project and
> distribution packages into our own language.
> It also do three things before use Launchpad to translate our project:

Basically, I think the requirements of a proposal should be put slightly
differently.  The API is the basis for any future development that
others will want to do, and it's important that it enables certain
operations, instead of just being implemented for the sake of itself.

Eg. it should be possible to:
1. Set up projects with translations using API
2. Manage project and Ubuntu translations
3. Manage translators and translation groups
4. Do template approval and review (in the import queue)
5. Develop client-side translation tool that integrates with LP,
providing review, translation and suggestion capabilities, including
ability to do mass operations like "revert to upstream translations"
6. Provide ability to report on the status of Ubuntu translations
through API

Doing the development to make some of these possible is not trivial and
will probably consume most of your summer.

Do note that you will have to hack on Launchpad code, which has a lot of
"old" code, and some of it will have to be refactored to accommodate for
new APIs.

> Create a graphical helper for

For most of the above, I'd be happy if we get simpler command line tools
which allow changing these settings.  If there's time left, you can
focus on developing actual useful tools, but I think a "Reviewer
Dashboard" would be very interesting one to tackle which touches on a
bunch of other things.

> 1.Enable translation by following the Change details link on our
> project's overview page and selecting Translations for this project
> are done in Launchpad.
> 2.Upload a translation template and any existing translation files to
> the series you want to translate.
> 3.Choose a permissions policy - i.e. decide who can make what sorts of
> changes to your translations.
> Create a gui to import and export GNU gettext's file format (.pot, .po, .mo)

That'd be nice but let's not get over the top of our heads just yet.

> Miscellaneous tools
> 
> 4. Status tracking tool
> 
> This tool picks the status of a project in Launchpad
> translation.Following are the staus of a project
>                    *Translation unchanged since last synchronized,
>                     *Changed in Launchpad ,
>                     *Newly translated in Launchpad ,
>                     *Untranslated.
>  This tool display the status with different colours.

This would again be nice to have, but let's not worry about these for
the time being.  Having a simple "Report on languages with translations"
console application would be enough for this phase.

> 5. Client side online translation tool

> This tool help us to save our precious time. We can do translation
> using a client. No need to login in  Launchpad for every time. It
> support all the tools which are using in the Launchpad Translation

As a matter of fact, it'd probably be more interesting to integrate into
existing translation tools like GTranslator, POEdit, or KBabel.  Anyway,
this would be a project in itself, so I wouldn't worry about it.

> 6. Navigation of the site in custom applications
> 
> We can access the Launchpad Translation component within the application.
> And
> 7. Create Requesting downloads tool
> 8. Create a tool to fetch fetching individual messages or suggestions,etc

Again, nobody will mind if you deliver all this, but it does sound like
a lot of things and simply impossible for the duration of the summer.

> To know more about my project
> 
> https://wiki.ubuntu.com/GoogleSoC2010/Dhasthagheer

As already suggested, it's a good idea to start by getting a local
Launchpad set-up (as you already started), and poking around the code in
there a bit.  Most of the Launchpad Translations code is in
lib/lp/translations/ so try playing with code there to see how it all
fits together.

Anyway, I'd be happy to mentor this, but we'll need to clearly define
what the goals are and what we want to achieve.  After you've delved a
bit more into code, we can probably discuss what and how it'll work.

To improve chances of your proposal being accepted, you'll have to
define it to a finer detail.  I.e. you'll need to nag me to explain how
things fit together, so we can come up with a proposal which clearly
sets expectations.  That's best done on #launchpad-dev on FreeNode IRC:
you've already found me there, so let's keep discussing until we are at
a point where we are happy with it.

Once we know exactly what we are striving for, we should define it as a
Launchpad Enhancement Proposal.  See
https://dev.launchpad.net/LaunchpadEnhancementProposalProcess for
details on how the process works.

Cheers,
Danilo