[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (forw) Google Summer of Code 2007 - mentors and project ideas wanted



Hello.

I was thinking about applying to Summer of Code last year involving Debian 
translation and localisation infrastructure. I changed my mind at last. 

Last year I was still looking at Pootle, which was Debian's choice for 
translation server. I was thinking how to best improve Debian's 
infrastructure. I then didn't apply, partly because there was already another 
student, partly because I didn't exactly know what I want Pootle to be.

But I'm back and I've been doing some good stuff lately. I've been migrating 
Pootle from jToolkit to Django web framework and django-migration branch is 
getting much faster now. 

My proposal last year would be to improve Pootle, but Debian wanted a 
centralized message storage. To Debian, a proposal that would just create a 
web portal for translating was of no use, so it was logical for Debian to 
choose translation storage for Pootle. On the other side, integrating 
translation storage into Pootle was impossible because of the state code was 
in, that's why I can understand Gintautas why he can't integrate his work.

My proposal this year is actually what you are already discussing here. Pootle 
has these great specifications[1] written, and I am especially interested in 
a part called version control[2]. 

Pootle is currently an obstacle in translation workflow. One needs to upload 
and download files to Pootle with browser, which is awkward if you need to 
update whole directory. As an alternative, Pootle offers downloading ZIP of a 
folder, but it's still hard to use. I want to make Pootle a natural choice 
for translators, a project that is a must-have for translation teams. 
Therefore it still needs to follow the diagrams, that I have published last 
year[3]. 

If I follow the diagram, "Message gateway" is essentially Pootle's storage and 
it's purpose is to hold all the translations.

Message gateway is connected to translation sources, eg. upstream VCS, URL, an 
email attachment or another arbitrary user contributed translation acquiring 
plugin. Same goes for submitting translations back to upstream: VCS, HTTP 
PUT, email or another little piece of code that can work with the upstream 
project.

Message gateway also stores some properties about translations stored. Those 
are used for statistics, for knowing where to fetch translations from and 
submit them back.

When you think long enough about this, you can make a perfect match with 
Subversion repository:
- it is centralized, which is perfect for translations and QA.
- it supports properties, which are perfect for storing statistics and 
information about upstream
- you can easily check out a whole translation project and stay updated 

This is basically my proposal. I would like to implement translation workflow 
in Pootle and implement storage as Subversion repository.

Offcourse the idea here sounds a bit optimistic, because there's are a lot of 
details that need to have programmers attention, specially the user 
restrictions: "who can translate what when".

Regards,
Gasper Zejn


[1] http://translate.sourceforge.net/wiki/wordforge/functional_specificaions
[2] 
http://translate.sourceforge.net/wiki/wordforge/functional_specificaions#version_control
[3] http://www.kiberpipa.org/~hruske/stuff/debian-i18n/bigpicture.png


Dne petek 09 marec 2007 18:01 je Christian Perrier napisal(a):
> Quoting Jens Seidel (jensseidel@users.sf.net):
> > Why not automate it? Whenever a new package is build (maybe only on the
> > autobilders?) a debhelper tool could request all translations from the
> > i18n server and update existing ones. This makes at least for native
> > Debian strings (debconf templates) sense. For other upstream messages a
> > specified action could be choosen such as sending a mail, a commit to a
> > version control system, ...
>
> Yes, I had something similar in mind.
>
> We will probably put a SVN or equivalent server between Pootle and
> maintainers, precisely for that reason.
>
> I'm currently in the process of using the SVN repository for the
> debian-l10n project, exactly for that purpose.
>
> Then Pootle could be using this SVN as the reference for its files
> with translators using either Pootle or the SVN directly, depending on
> their organisation needs.
>
> Not sure that *this* fits a possible GSOC project.



Reply to: