Re: (forw) Google Summer of Code 2007 - mentors and project ideas wanted
Dne nedelja 11 marec 2007 12:25 je Javier SOLA napisal(a):
> 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
>
The document you have pointed me to is very specific, as it deals mainly with
XLIFF and some of it's details.
> 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.
Exactly. Being a translator still requires a lot (too much) knowledge about
underlying technical solutions. Implementing such a workflow with sufficient
quality, so translator would need not to know of details, would make
translating projects far easier. This has partly already been shown with
Ubuntu's Rosetta, which has lowered the technical barrier for translators
(but failed with workflow, since no proper review was made).
> 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.
Exactly. Besides that, it also provides additional features, such as easy
checkouts or updates and svn properties.
> 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?
Pootle storage must be strictly local. Every translation is imported from
upstream, translated in Pootle, stored in SVN storage and later, when
coordinator decides, sent back to upstream.
> 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.
I too don't have much experience with large SVN repositories. I only know SVN
was designed to also fix some performance issues of CVS. But since repository
is local to server, it would probably be a performance issue. Also, the
commits can't be executed in Pootle web server process, but a separate
process, that only manages storage.
> - 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.
True. That's why a separate process, that would manage storage, locks
translation if a translator starts translating it in Pootle, and if it does
not recieve next translated string in a specified timeout, it saves (commits)
pending translations.
> - 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.
Sure, every incoming translation must go through Pootle and this is quite
logical. Translation teams don't want translators to use upstream SVN or any
other VCS. If they would, this would essentially mean the same as if they
wanted programmers to use direct hard drive access and not use functions
provided by the file system.
But the new POTs, that you are referencing, will be updated by Pootle and
every commit must also be done by first merging with fresh upstream POT.
Hope I cleared some misunderstandings.
Regards,
Gasper Zejn
>
> 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: