Xavier Antoviaque
2002-04-17 15:43:00 UTC
Voici le "brouillon" du message à envoyer sur la liste lampadas. Comme
précisé précédemment, puisqu'il est sensé représenter nos idées en tant que
groupe, je le présente ici pour relecture et corrections éventuelles.
J'ai essayé autant que possible de condenser les consensus, mais il peut y
avoir des aspects à revoir.
Notez également que l'anglais n'est certainement pas parfait. Donc s'il y a
des choses qui vous choquent trop, n'hésitez pas à corriger aussi...
===
Hello all,
The intent of this mail is to summarise the results of the discussion that
took place in the french mailing-list traduc at traduc.org recently, leading the
contributors of the "LDP fr" to discuss needed features and development ideas
for an interface similar to Lampadas.
Now that our two projects are merging, we think that it would be a good idea
to give you the results of our thoughts. The intent is also to start a new
discussion, together, and define what we want Lampadas to be exactly at the
end.
I] The translation process
As traduc.org is today used for translation only purposes, our main
contribution may be on this point.
A] Today
By now, the translation process consists of three steps, involving three
types of users : the translator, the proof-reader(s) and the project
coordinator. As the translator does the main job, he is designed responsible
for his document and also quite naturally the document maintainer.
- the translator choose a document or a new version of a maintained document
is avaible,
- the translator translates or makes the appropriate changes,
- when finished, he announces the document ready for proof-reading on the
mailing-list,
- one or more proof-readers contact the translator and help him correcting
its translation (diffs),
- when satisfied, the final version is submited to the project coordinator,
who publish it if he estimates that enough precautions about its reliability
have been taken. What "enough precautions" is depends of the nature of the
document, and of te number of mistakes found by the proof-readers.
This system works well and for a quite long time now, but it has also proven
its limits : the coordinator has too much work, and very few steps are really
automated.
B] The future
We needed a translation process manager, so we started to discuss the changes
this interface would introduce, as well as what would be automated and what
would not.
Changes :
- There would not be only one project coordinator this time, allowing the
amount of work to be divised among two or three. This also avoids some lack
of responsivness when the coordinator has no or not enough time to spare for
the projet.
- The process could be a little more standardized than before (for the
proof-reading step, mainly), becoming more clear to the newcomers. The exact
rules (numbers of proof-readings needed, exact process of the proof-reading
step) have not being detailed yet.
- A new kind of user could be introduced, similar to your markup assistants,
providing help to the translators having difficulties to pass the
XML/SGML/... validation automation.
What would be automated :
- The registrations of documents, traductions and users.
- The publication of the documents (web, FTP, archives...).
- The translation process. Excluding the points in the "What would not be
automated" section, the interface should automate all the steps; from the
selection of a particular document to its publication approval by one of the
coordinators.
- The interface should include a depository of the changes in a document
(translations, proof-readings, comments), like the one a CVS depository could
provide, but probably in a more user-friendly way.
What would not be automated :
- The discussions between the contributors to the project. The mailing-list
would of course be preserved and a translator would still have to subscribe
to it. The discussions between a translator and his proof-reader(s) could
still be made privately by email; a summary of these discussions could be
attached to the document, for later reference.
- The approval of a publication by a project coordinator; this task is
simplified, but one still has to say "ok" before the document is published.
Some alredy existing tools have been proposed for particular tasks :
- Roundup ( http://roundup.sf.net ) : to track user and proof-readers error
reports.
- MoinMoin ( http://moin.sf.net ) : to reference common traduction problems,
solutions and general help to the translator.
II] The document redaction process
As stated previously, it would be a good idea to allow contributions to the
LDP in any langage, and not just the english -> foreign langages translation
scheme that is actually in use.
But, as we do not have discussed this point further, and that you do have a
good experience on this point, we let you speak first. :-)
And remember that it is just an overview of what we have discussed apart. We
have to start a discussion on this...
précisé précédemment, puisqu'il est sensé représenter nos idées en tant que
groupe, je le présente ici pour relecture et corrections éventuelles.
J'ai essayé autant que possible de condenser les consensus, mais il peut y
avoir des aspects à revoir.
Notez également que l'anglais n'est certainement pas parfait. Donc s'il y a
des choses qui vous choquent trop, n'hésitez pas à corriger aussi...
===
Hello all,
The intent of this mail is to summarise the results of the discussion that
took place in the french mailing-list traduc at traduc.org recently, leading the
contributors of the "LDP fr" to discuss needed features and development ideas
for an interface similar to Lampadas.
Now that our two projects are merging, we think that it would be a good idea
to give you the results of our thoughts. The intent is also to start a new
discussion, together, and define what we want Lampadas to be exactly at the
end.
I] The translation process
As traduc.org is today used for translation only purposes, our main
contribution may be on this point.
A] Today
By now, the translation process consists of three steps, involving three
types of users : the translator, the proof-reader(s) and the project
coordinator. As the translator does the main job, he is designed responsible
for his document and also quite naturally the document maintainer.
- the translator choose a document or a new version of a maintained document
is avaible,
- the translator translates or makes the appropriate changes,
- when finished, he announces the document ready for proof-reading on the
mailing-list,
- one or more proof-readers contact the translator and help him correcting
its translation (diffs),
- when satisfied, the final version is submited to the project coordinator,
who publish it if he estimates that enough precautions about its reliability
have been taken. What "enough precautions" is depends of the nature of the
document, and of te number of mistakes found by the proof-readers.
This system works well and for a quite long time now, but it has also proven
its limits : the coordinator has too much work, and very few steps are really
automated.
B] The future
We needed a translation process manager, so we started to discuss the changes
this interface would introduce, as well as what would be automated and what
would not.
Changes :
- There would not be only one project coordinator this time, allowing the
amount of work to be divised among two or three. This also avoids some lack
of responsivness when the coordinator has no or not enough time to spare for
the projet.
- The process could be a little more standardized than before (for the
proof-reading step, mainly), becoming more clear to the newcomers. The exact
rules (numbers of proof-readings needed, exact process of the proof-reading
step) have not being detailed yet.
- A new kind of user could be introduced, similar to your markup assistants,
providing help to the translators having difficulties to pass the
XML/SGML/... validation automation.
What would be automated :
- The registrations of documents, traductions and users.
- The publication of the documents (web, FTP, archives...).
- The translation process. Excluding the points in the "What would not be
automated" section, the interface should automate all the steps; from the
selection of a particular document to its publication approval by one of the
coordinators.
- The interface should include a depository of the changes in a document
(translations, proof-readings, comments), like the one a CVS depository could
provide, but probably in a more user-friendly way.
What would not be automated :
- The discussions between the contributors to the project. The mailing-list
would of course be preserved and a translator would still have to subscribe
to it. The discussions between a translator and his proof-reader(s) could
still be made privately by email; a summary of these discussions could be
attached to the document, for later reference.
- The approval of a publication by a project coordinator; this task is
simplified, but one still has to say "ok" before the document is published.
Some alredy existing tools have been proposed for particular tasks :
- Roundup ( http://roundup.sf.net ) : to track user and proof-readers error
reports.
- MoinMoin ( http://moin.sf.net ) : to reference common traduction problems,
solutions and general help to the translator.
II] The document redaction process
As stated previously, it would be a good idea to allow contributions to the
LDP in any langage, and not just the english -> foreign langages translation
scheme that is actually in use.
But, as we do not have discussed this point further, and that you do have a
good experience on this point, we let you speak first. :-)
And remember that it is just an overview of what we have discussed apart. We
have to start a discussion on this...
--
Xavier.
Xavier.