My GSoC project: Transifex

Dimitris Glezos dimitris at glezos.com
Mon Jul 9 12:59:55 UTC 2007


Hey all.

I'm working on a system that has everything to do with our Fedora i18n, so it
would be great to start discussing it here. I'm sorry I delayed to do this, but
the picture wasn't really clear until now. I've sent a similar mail to this to
GNOME i18n, so that the team there is up2date on what I'm doing.

As some of you might already know, we're moving our l10n infrastructure from RH
to Fedora systems to better maintain systems etc. For more info, see:

  http://fedoraproject.org/wiki/Infrastructure/RFR/ElvisMove

To make this a reality, we needed a new web frontend for statistics that will be
able to display statistics for many modules hosted in many repositories. We
quickly got a system up and running using GNOME's damned lies software at:

  http://translate.fedoraproject.org/

So the problem is that Fedora Infrastructure supports all CVS, SVN, Mercurial
and git version control systems (VCS) for project hosting and also, some
Fedora-related modules are hosted out of the `*fedoraproject.org` space (*fpo).
But translators are only given access on `cvs.fpo`, so they can't commit files
to these remote systems.

The translator shouldn't care where the module is hosted, he just wants to send
a PO file in. Through GSoC 2007, I begun working on a system (transifex) that
will give them access to submit PO files to a remote VCS. Information about it
(together with an INSTALL file) can be found at:

  https://hosted.fedoraproject.org/projects/transifex

The idea is that transifex will act as a proxy/mediator for translation commits.
A translator will login to the transifex instance running on a host like
`translate.fpo`, choose a module, a PO file to upload, and a destination file
and click "submit". The system will commit the file for him. Underneath this is
achieved by having the VCS admin create a user (eg. fedora-transifex) with a
dedicated SSH key, and give it write access to the specific modules accepting
translations. The transifex admin will then hook the repo and module up with the
system. Each commit will be done by the "fedora-transifex" user, and the actual
user's details (name, surname, email, fedora username) will be written in the
commit message and Changelog file. Transifex supports filaname filters, so even
if a module maintainer can't add ACLs to the repo, he can define them on the
transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$).

The software is written in Turbogears and its architecture is similar to DL's.
Basically it's an add-on to the statistics, providing a web form for submission.
It's pretty easy to install it on Fedora and try it out, just follow the INSTALL
file.

I believe the whole project opens up some exciting opportunities for
translations. Small projects hosted outside of big ones now have a chance to get
some attention from translation communities without the requirement to relocate
their code. And also, two communities can collaborate better by providing
corrections to each other's modules. In the end, I see probably some mechanism
to approve translation landing from language maintainers or something, but this
is a bit in the future for now. :)

Since fedora-trans-list is mostly occupied by translators and not
developers/maintainers, I believe this list is a more appropriate place to host
discussions for the development of the tool and our whole infrastructure that
supports translations. It all falls in the category "Fedora i18n". :)

So, this is it. Any ideas, suggestions, comments, are welcome. Sorry for the
long email.

-d


-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
-- 




-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
-- 




More information about the i18n mailing list