RMLL, jour 4

Encore une journée passée dans le thème Documentation :)

Conf 1 : par Muriel (éditrice chez Eyrolles).
Une bonne traduction d'un document technique a pour but de servir le lecteur en lui permettant d'être opérationel le plus vite possible. Avant de traduire, il faut comprendre le texte. Ne pas supposer qu'on comprend : si on n'arrive pas à traduire, c'est qu'on n'a pas compris. Ne pas oublier qu'il faut traduire vers sa langue maternelle. La fidélité est à géométrie variable. Une traduction est une adaptation : ne pas traduire mot à mot car traduire, c'est transformer un texte (lire un paragraphe et essayer d'oublier les mots pour ne garder que le sens, puis traduire). La richesse du vocabulaire est une chose mais le bagage technique/culturel est important. Deux types de traducteurs : le technique (qui est à l'aise et qui aura tendance à faire du mot à mot), le "pas technique" (qui devra appréhender la logique, détecter une erreur... il ne doit pas hésiter à se renseigner). Si plus de 60% des lecteurs comprennent le terme anglais, il est plus intéressant d'utiliser ce terme (ce qui n'empêche pas de vérifier l'existence d'un terme usuel en français). Dans la traduction d'une application, il faut utiliser le contexte pour diminuer le nombre de mots. Un débat a commencé sur la traduction des explications : explication pour Muriel concernant le système .po et ses déficiences... interaction nécessaire avec le développeur. La stylisation du texte peut être contre-productif. Ça attire l'attention du lecteur sur certains points du texte sans que cela lui apporte réellement quelque chose. Piège clasique : humour américain, abstraction vs analogie, redondance. Éviter les acronymes... en ajoutant une définition... Beaucoup d'interactivité dans la conf. Quelques liens : ESIT (École Supérieur d'Interprètes et de Traducteurs), eurodicotome ?, jargonfr.

Conf 2 : par Isabelle Hurbain (en tant que membre actif de traduc.org et auteur/traducteur chez Eyrolles)
Conférence sur les idées reçues sur la traduction (tout le monde devrait parler anglais, traductions de mauvaise qualité, rend le suivi de bogues difficile, etc.) J'adore l'idée de cette conférence :)

Conf 3 : par Sophie Gautier (responsable fr chez OpenOffice.org)
Jusqu'à la version 2.0, la traduction était réalisée uniquement par Sun. L'aide sur le basic, version 2.0, a été l'occasion de la première intervention de l'équipe française. Ils ont mis en place un processus bien que le travail se fait en collaboration avec Sun qui relit tout. L'utilisation de fichiers .po sur un CVS permet de gérer un statut des traductions sur le site web. Vingt personnes ont travaillé en commun pour la dernière localisation. Aucun outil forcé : gedit, poedit, etc. L'organisation est assez conséquente : un traducteur, deux relecteurs. La remontée de bogues se fait via l'outil d'openoffice.org : plus de 20.000 bugs ont été répertoriés. Le premier groupe de traduction est allemand, la second français, le troisième russe, etc. A noter qu'ils s'aident des autres suites office pour avoir des traductions homogènes. La traduction de l'aide a l'air assez complexe.

Conf 4 : par une personne de scénari
Difficile de tout noter étant donné à quel point la présentation était riche et rapide. scenari est un environnement libre, gratuit et opensource (un prérequis d'après le conférencier)... et multiplateforme malgré quelques soucis avec la version Mac. Le framework mozilla est utilisé pour la GUI. La saisie se fait avec cette GUI, les sorties sont des plugins paramétrables (HTML, OpenOffice.org pour le texte ou le PDF, flash). Le moteur est écrit en java. La grosse majorité de la conférence était basée sur une démonstration impressionnante pour un client particulier, une PME. Ils ont fait un projet avec l'INA pour créer une webradio. Il suffit d'ajouter des noeuds sonores qui peuvent être modifiés directement depuis le framework (par exemple pour préciser la plage à jouer). Le plugin de sortie est un player flash capable de jouer le flux audio et de synchroniser des images et des textes sur une page web. Pour plus d'infos, voir le site du groupement recherche musique de l'INRA, ircam.fr. Ils espèrent travailler sur des projets moins confidentiels comme radio france. Leur système fonctionne en client/serveur simple (pas comme un CMS avec gestion de droits, d'historisation, etc.) Ils ont une communauté historique d'utilisateurs : une vingtaine d'universités et des entreprises... leur gros boulot maintenant est d'augmenter cette communauté.

Conf 5 : par ?
utilisation de XML pour des bases de données historiques base de données Access passé à une autre base de données stockage des textes (parchemins) découverte du XML passer le texte au web ne correspond pas vraiment aux besoins des historiens plus de 13000 textes codés avec des fiches perforées ils ont besoin d'outils de recherche poussés sur le texte comment coder un texte pour le rendre plus conforme et plsu facile à utiliser ? exemple de documents de dettes Les documents historiques ne sont pas catalogués de façon informatique. Les métadonnées ne sont pas disponibles.

Pour le déjeuner en ville, nous avons abandonné le RU pour privilégier un bon repas en ville, surtout que toady nous a rejoint pour la journée. Du coup, j'ai eu un peu de retard pour les confs de l'après-midi.

Conf 6
pas vu

Conf 7, Eric Bachard (développeur chez OpenOffice.org)
Hummm, arrivé en retard, désolé, toussa. Eric a surtout parlé de son wiki, de son travail de développeur pour OpenOffice.org et de la nécessité d'une documentation développeurs. En effet, documenter permet d'attirer des gens.

Conf 8, par Sébastien Blondeel (auteur/traducteur chez Eyrolles)
Pour écrire son bouquin sur wikipedia, Sébastien a créé sa propre DTD XML, une DTD très simplifiée et légèrement basée sur les styles demandés par son éditeur, Eyrolles. Il écrit ses livres en créant un fichier par chapitre. Un script Perl fusionne les différents fichiers, un autre script s'occupe d'intégrer les images suivant leur type et leur taille (<img f="toto"... donne <img f="images/toto.png" t="640x480"...). À partir de ce dernier fichier, xsltproc crée un XML ODF avec une feuille de style XSL. Le tout est zippé avec les styles et les images pour créer le fichier OpenOffice.org. Le metteur en page utilise le XML ODF avec une feuille de style XSL pour créer un fichier XML de framemaker ce qui lui permet de générer du PDF ou du HTML. Le metteur en page a même réussi a faire une feuille de style XSL pour passer du format de base au format XML de FrameMaker. Bref, Sébastien travaille avec Eyrolles en utilisant une chaîne de construction entièrement validée et historisée (avec SVN). Cela lui a permis de garder sa méthode de travail tout en respectant les prérequis de son éditeur tout en lui montrant sa progression (commit SVN envoyés à l'éditeur).

Conf 9, une autre personne de scénari
Scenari chain, deuxième épisode :) Trois éléments : Scenari framework, scenari builder, scenari chain. Démo d'un slideshow. Exemple utilisé : Dokiel ; création d'une documentation utilisateur (de référence, guide utilisateur, aide mémoire), support de formation (diapos, support stagiaire er formateur, support de formation à distance, exercices).

Vraiment, ce thème Documentation est le meilleur que j'ai vu aux RMLL (pourtant, j'y vais depuis six ans !).

Commentaires

1. Le lundi, juillet 10 2006, 00:50 par christophe

Je ne vais pas laisser de commentaire insipide sur chacun de tes billets sur les RMLL, mais merci de faire partager avec ceux qui n'y sont pas :)

J'en profite pour signaler qu'une erreur s'est glissée dans l'URL de scenari :p

2. Le lundi, juillet 10 2006, 00:56 par Guillaume Lelarge

Merci, c'est corrigé.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet