Bonjour,
Après quelques jours passés à m'imprégner plus avant du fonctionnement passé de traduc, je vous livre mes premières réflexions quant à la mise en oeuvre d'une interface étendue et automatisée. Ce point ayant été communément admis comme prioritaire, il est donc nécessaire d'ouvrir dès maintenant un débat quant à ses spécifications exactes.
Car, on a pu le voir ces derniers jours, plusieurs interfaces existent déjà, et peuvent éventuellement être réutilisées sur traduc.org (voir sur le LDP fr, si le projet devait finalement se concrétiser). Mais avant de se lancer à corps perdu dans l'installation et le développement de telles architectures, encore faut-il savoir ce que l'on doit en attendre.
Ce mail se veut donc un point d'ouverture à une discussion devant aboutir à la rédaction des spécifications de l'interface. Il n'a rien d'une proposition finie pour l'instant, et la discussion nécessite le concours du maximum de personnes, ceci afin que l'outil final corresponde le plus possible aux besoins de chacun.
Notez que beaucoup de passages ne font que reprendre des idées déjà énoncées par ailleurs sur la liste.
I] Vue d'ensemble
Le premiers stade de l'élaboration des spécifications consiste à définir les tâches accomplies par l'application finale au travers de principes généraux. Ces principes, ou règles de base, définiront la structure interne du suivi des traductions, et donc - par extension - de traduc.org. Ils serviront également de référence lors de l'élaboration de l'interface (que celle-ci soit créée de toutes pièces par nos soins, ou adaptée de celle d'un projet tiers).
Cette étape est donc particulièrement importante, et est également la moins technique de toutes. Les points auxquels on s'attachera seront les suivants : gestion des utilisateurs, gestion des documents, publication. Cette liste est éventuellement à compléter, si vous voyez d'autres aspects qui demandent une réflexion de notre part.
2] Gestion des utilisateurs
Actuellement, il y a trois types d'utilisateurs sur traduc : les traducteurs, les relecteurs et le coordinateur. Dans le cadre d'un passage à l'automatisé, il peut être intéressant de repenser cette attribution des rôles, qui a été prévue à l'origine pour une gestion "manuelle" des traductions.
Le grand pas en avant que permet l'automatisation est la possibilité de déléguer toute la partie validation effective d'une traduction. Pour éviter les traductions fantaisistes, on est en effet obligés de conserver une validation manuelle de toute proposition de traduction. Actuellement, le système consiste à attendre la validation de trois relecteurs, qui est constatée par le coordinateur, lequel publie le nouveau document.
Pour éviter cela, on peut distinguer deux types de relecteurs : ceux ayant déjà fait la preuve de leur sérieux (typiquement en soumettant/relisant une traduction validée), et les 'nouveaux'. Les traductions ou relectures doivent obtenir l'aval d'un utilisateur confirmé avant d'être publiés. Le coordinateur n'intervient alors plus là que pour régler des problèmes ponctuels, tels un mauvais plaisantin qui se serait glissé entre les mailles du filet.
3] Gestion des documents
Cette partie détaille l'évolution d'un document depuis son intégration en langue étrangère jusqu'à sa parution.
Ici, il semble clair que toutes les procédures se font en ligne. Une page spécifique regroupe les documents en attente de traducteur ou de relecteur, il est possible d'y consulter le document en VO (et évenuellement VF pour les documents non relus) pour se faire une idée. Si l'utilisateur est loggé et n'est pas déjà en train de traduire/relire un document, il peut décider de s'occuper de celui-ci.
Pour éviter les doublons, une fois qu'un utilisateur s'occupe d'un document, il est marqué comme [EN COURS] et ne peut plus être pris par un autre. Pour éviter le squat, le traducteur (et le relecteur aussi, dans une certaine mesure) devra indiquer à intervales réguliers l'avancement de sa traduction, ainsi que les raisons d'un éventuel retard (relances par mail). Au bout d'un certain laps de temps (2 mois?), le retard sera visible du coordinateur (avec les explications éventuellement fournies par le traducteur), qui pourra décider de libérer le document. L'utilisateur pourra d'ailleurs décider lui-même de libérer un travail qu'il effectue.
Il est possible à tout moment d'uploader un travail partiel, ceci afin de permettre à tous de voir l'avancement des travaux, mais aussi de pouvoir transmettre ce document s'il change de main.
Une fois terminé, le document traduit est soumis à validation des utilisateurs confirmés. S'il y a à redire, les modifications sont à intégrer par l'auteur lui-même. Il va sans dire qu'un utilisateur confirmé ne pourra pas auto-approuver une de ses propres traductions...
Pour les diffs entre deux versions d'un document, ou lors d'une relecture, il faut regarder les possibilités techniques exactes (notamment au niveau de xmldiff, comme mentionné par Nicolas Chauvat), mais il ne paraît pas inenvisageable de proposer une interface web complète à ce niveau.
4] Publication
Un document traduit, c'est déjà une bonne chose. Mais encore faut-il que l'on puisse y accéder simplement et agréablement...
Il pourrait en effet être intéressant de proposer les documents par un autre moyen que le FTP. Et même lorqu'ils sont mis directement sur le web (cf Freenix), force est de constater que c'est un peu fouilli et rébarbatif, comme présentation.
Il manque une valeur éditoriale, même très simple, qui permettrait au moins de regrouper les documents par thèmes. Une autre bonne (?) idée serait d'avoir un moteur de recherche (bon, ok, il y a déjà Google...).
Au final : tout ceci n'est qu'une première ébauche. J'insiste à nouveau sur le fait que ce genre de chose doit être le fruit d'un travail de groupe pour être vraiment utile. Et notez bien que je ne m'approprie pas le rôle de coordinateur : ce mail est avant tout un pavé dans la mare. A la charge du futur (ou présent?) coordinateur d'obtenir un consensus.
A vous !