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 ([EMAIL PROTECTED]): > > 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
