(this report is a little bit late as it took time to finalize
it...sorry for the inconvenience)
The work on internationalisation (i18n) and localisation (l10n) at
Debconf6 has been particularly interesting and productive.
The main topic has been the discussion on l10n infrastructure, both
summarizing existing features and services (most of them being
summarized in the paper I published along with Javier Fernandez
Sanguino) and future features.
The two main topics were:
-begin to work on the l10n 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 l10n talk by Javier
Fernandez Sanguino and Christian Perrier concluded the week.
Many other informal discussions also happened with several people
involved among who we can cite: Javier Fernandez Sanguino, Otavio
Salvador, Michael Bramer, Nicolas François, Javer Sola, Gerfried
Fuchs, Margarita Manterola, Raphaël Hertzog, Christian Perrier, Frans
Pop, Javier Sola, Aigars Mahinovs, Daniel Glassey.
Some cntributions from the mailing list by people not present at
Debconf have also been included and taken into account.
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 institutions. This category include "regular"
users who will use the system to occasionnaly contribute (error/bug
reporting and the like)
- 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 (or ordinary users)
-learn about the system (stats..) (references to l10n)
-propose changes in translations
-report bugs
-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 Pootle and related projects has
finished convincing us that working with the members of the WordForge[1]
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.
As a consequence, we will complete WordForge specifications with ours.
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.
Draft specification for the Debian i18n infrastructure
------------------------------------------------------
This summarizes the various discussions that occurred during Debconf
and on the mailing list during the month of May, mostly. Listed below
are the various modules we identified as needed in the target
infrastructure.
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 l10n contributors
-----------------------------------------
Reviving the DDTP - translated package descriptions as a release goal
---------------------------------------------------------------------
While the work on the new infrastructure advances, Michael "Grisu"
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.
Having working translated package descriptions as an "etch pet release
goal" for the Debian i18n team seems possible.
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 l10n community to allow contributors to start building a
consistent backend to the future Pootle system, benefitting from the
work of Gintautas Miliauskas 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).
References
[1]http://www.wordforge.org
--
Attachment:
signature.asc
Description: Digital signature