This is an attempt to summarize all events, discussions and decisions that happened during Debconf6 in Mexico. I wrote it in the plane, as I couldn't sleep, thanks to a bunch of ultra-noisy Spanish dudes, who seem to think that a transatlantic flight is not a place where people would like to sleep. Please remind me to fly on Scandinavian Airlines next time. Anyway, here we are with the report. If some of the participants want to add stuff or correct me, please do so. Please do not add ideas that HAVE NOT been discussed at Debconf. After being amended, this report will go in debian-devel-announce. Please send updates as patches (save the file, make changes and "diff -u" with the original file). This is why I send this file as an attachment. Of course, putting it on a Wiki would be better, but I'll be often offline in the next two weeks, and I prefer us working offline right now. --
The work on i18n at Debconf6 has been particularly intersting and productive. The main topic is of course currently discussion on i18n infrastructure, both summarizing existing features (most of them being summarized in the paper I published along with Javier Fernandez Sanguino) and future features. The two main topic were: -begin to work on the i18n infrastructure specifications -setup a precise project for the proposed work inside the Google Summer of Code project by Gintautas Miliauskas Two BOF sessions have been organized and the i18n talk by Javier and myself concluded the week. Many other informal discussions laso happened with several people involved among who I'll cite: Javier Fernandez Sanguino, Otavio Salvador, Michael Bramer, Nicolas François, Javer Sola, Gerfried Fuchs, Margarita Manterola, Raphaël Hertzog, Frans Pop, Javier Sola, <please add self here> Discussions from the mailing list: Denis Barbier, Gintautas Miliauskas aka "Gintas" (prospective GSoC student), <please add self here> During our first session and the initial discussions, the main point was trying to setup ideas about the needs for the infrastructure: what are its targets (aka users) and what features might be needed by each of these targets. The second session happened after some informal work between contributors and was aimed at being a summary of the ideas that were floating around. All this lead to the following conclusions: Infrastructure targets: ----------------------- We identified the following targets, or categories of users: - Administrators They are in charge of managing the system and the users - Translators They work on translations of original strings coming from "upstream" - Reviewers They check the work from the translators and certify that it meet the standard of each translation team - Maintainers Either originating inside Debian (the package maintainers) or outside (upstream software authors and maintainers), they are the source of translatable material and the destination of translations. - Visitors They are occasionnal visitors of the web site, or potential users such as governmental institution. - Team coordinators They are in charge of coordination the work of one translations. There may also be transversal maintainers who just work on a single directory or software. Needs of each user category --------------------------- -Administrators -add/manage projects -add/manage languages -delegate --> backup admins, but also delegate tasks to translation team coordiantors. -Translators -get the information about the needs and priorities -"book" a translation. Reservation should be valid only for a certain amount of time. After it (calculation can be automated), the translation is released (post by the robot in d-l0n-foo). -get material (web, mail, SVN...) or work online -derive translations (Spanish, translate from other langs than en) -choose their preferred format (XLIFF, PO...) -licence translations (???) -ability to merge reviews and ACK proposals one by one -avoid collisions with files translated in other projects -need to enforce the concept of "owner" of a translation -optionnally more than one ower in some projects -glossary (able to propose several translations) -Reviewers -get work assigned, on request -express "Intent to review" (released after a calculated amount of time) -do work in public -see what other reviewers have proposed -Maintainers -Modify the source location -send the material -Ask for updates in release time by priority raise -get the updated material -Be notified of updates (opt-in). Options: - every commit - when "Ready" - ... -visitors -learn about the system (stats..) (references to i18n) -propose changes in translations -team coordinators -can be per project and per lang -get status and stats about their field of expertise -add projects -manage assignments (in addition to automated unassignments) -setup and use different processes from team to team (nr of reviews, etc.) -group translations -set some goals, and see/show if the goal is achieved These design goal raise the importance of the project for being as modular as possible. The core of the project should be a backend on which all other modules will plugin to. Going with WordForge -------------------- The presentation by Javier Sola of the projects by Pootle has finished convincing us that working with the members of the WordForge project is certainly the way to go. Their project is aimed mostly at these goals and even more which we had never formalized completely. That project doesn't suffer the concerns we have with the Rosetta project from Ubuntu/Canonical. We indeed have been later confirmed that WordForge also work on open standard for communication between localisation projects and these could be used to communicate between the Debian infrastructure and that of Ubuntu. These early specifications for features certainly have to be enhanced and completed in the future but they will probably already allow Debian to merge them in the Pootle/WordForge specifications which are still under work. We will complete WordForge specifications with ours (needs agreement on how to "mark" Debian additions/needs Google Summer of Code project ----------------------------- The challenge with the GSoC project is multiple: -complete the project prepartion in a very short time (less than 1 week) -give a precise goal to the student -make it reasonable to achieve in the 3 month time frame The first idea that came out has been requesting some work on some "bounties" of the WordForge project. However, some of us prefer that the specifications are ready before we enter such path. Given that they won't obviously be complete, we finally decided to launch a quite conservative project just to ensure that the work done has still some benefit for Debian without compromizing the future. As a consequence, it has been decided that the requested work will be separating the frontend from the backend in Pootle, which will allow future work to be concentrated on the backend used by all future software in the framework. Some ideas about modules ------------------------ This part is more prospective and will need some reorganization. It's more intended to be a summary of ideas that have been floating in the mailing list. Import modules -------------- - Import from po-debconf (need standardization action to provide up-to-date POT. At the minimum, reproduce the current layout) - Import from programs PO (ditto) - Import from man pages converted with po4a (standard layout mandatory) - Documentation (action from maintainers==opt-in) - Web site (no action, source under control) Translation modules ------------------- - Translation teams define their own processes from a set a standardized actions: - TTD (Translation To Do) - TTU (Translation To Update) - RFR (Request For Review) - Reviewed (with counter) == LCFC (Last Chance For Comments) - Pushed to maintainer via Debian BTS - Pushed to maintainer via another BTS - Ready for Use - Different processes for different types of translations - Branching translations with merge features (manually or automaticall for stable/testing/unstable) Export modules -------------- - Individual PO files - Set of PO files as a tarball - Individual XLIFF files - Online work Interface modules ----------------- - Web interface - Mail interface Communication modules --------------------- - Other Pootle servers - Rosetta servers - TP server (?) Future plans for Debian i18n contributors ----------------------------------------- Reviving the DDTP ----------------- While the work on the new infrastructure advances, Grisu (Michael Bramer) will stabilize the current DDTP code to allow some maintenance of existing translations of package descriptions. Most of this work is already achieved, indeed. In parallel, and because APT 0.6 now includes support for translated packages descriptions, the use of these will be promoted. Temporarily, the Translations files will be hosted on another server, namely ddtp.debian.net. Some discussion has to happen with the ftpmasters team to decide whether the use of Translations file on FTP servers is considered suitable and when their inclusion can be possible. Of course, for this to happen, the DDTP must have a working maintenance system so that maintainers of packages can be sure that the bug reporst they might be received from the DDTP, will be maintained. The plan here is to temporarily use http://ddtp.debian.net as the demo case of what can be done with "Translations-*" files and the new APT. We should (re-)advertise this, have it used during a few weeks and then discuss with the ftpmaster to have it integrated in the main repositories, along with Packages files. Extremadura 2006 ---------------- A meeting will be organized in Extremadura, from Thursday September 7th to Sunday September 10th. This meeting will use the specifications previously finalized by the Debian i18n community to allow contributors to start building a consistent backend to the future Pootle system, benefitting from the work of Gintautas to separate both. Inviting the Pootle developers to the meeting is considered highly wished. Hopefully, in the meantime, enough will have been achieved, especially by Gintas during his work. The goal could be setting up the first Debian Pootle server. For all information about Extremadura sessions, the #extremadura-2006 channel can be used on freenode (irc.debian.org).
Description: Digital signature