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).
Attachment:
signature.asc
Description: Digital signature