Re: (forw) Google Summer of Code 2007 - mentors and project ideas wanted
First some admin. Can I ask two simple things:
1) That a key goal be integration of the work within Pootle. That
didn't happen last year and to be honest it could have if that had been
part of the goal
2) It relates to the last. As the Pootle team it was amazing having
someone help on the code. But frustrating when it took our time with
little ability on our side to influence as we weren't the mentor.
Now to the body of this...
I like the idea of version control locally as that allows us to use
established tools to manage the versioning and control locally. I don't
know enough of subversions features to know how the attributes would
work.
Just out of curiosity, did you at all think of Bazaar? Why I ask is
that that seems like it would make an easier integration. Plus since
its a fully distributed VC system you could essentially work offline and
commit to your local bazaar server. Then push those translations to an
upstream bazaar/Pootle server.
But that doesn't need to cloud the current issue which I think is well
scoped with simply the versioning.
On Sat, 2007-03-10 at 13:56 +0100, 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.
>
>
--
Dwayne Bailey
Translate.org.za
+27-12-460-1095 (w)
+27-83-443-7114 (cell)
Reply to: