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

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

Hi Gasper,
Implementing translation workflow in Pootle is one of our priorities at WordForge. The conclusions that we reached at the Debconf 6 meeting were that we had to make a very flexible system that would allow the configuration of many different flows favored by different Debian teams. I wrote a paper about this. It is in:
http://khmeros.info/download/process_managment_in_ XLIFF_files.pdf I think that this is a large task by itself, it is interesting because it is something that it has not been done before and generates a lot of value for translators. 

For the other half of the proposal, I would like to understand it better.
If I understand correctly, what you are proposing is to use SVN as Pootle storage, instead of using the file system of the server that is running Pootle.
This is an interesting idea. It solves the issue of having to store old copies of the files once they are modified.
Are you thinking of local SVN at the Pootle server or original SVN at the project site (such as the Debian SVN), without Pootle storing any local data?
I am not the expert on Pootle implementation, I would like to see what Dwayne, Friedel and Andreas think about this, but there are several issues that I would like to understand.
- The first one would be performance. Assuming that SVN is local, all operations on files (updates, etc) would require checking files in and out of SVN. I have no experience on the speed of SVN, so I cannot judge this.
- The second one is that when we use the on-line editor of Pootle, we would have to ensure that we do not commit to SVN each time that we change one string, otherwise we clutter SVN with far too much useless information.
- This would have to be a specific storage for Pootle, it could not be modified by external sources, as this would break all the statistics, controls and internal workings of Pootle. Any incoming information would have to go through Pootle. This eliminates the possibility of using the original project's SVN, as this one might be updated (with new POTs) directly by the project. 

Cheers,

Javier





Gasper Zejn wrote:

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: