Bien sûr, cette liste est loin d'être exhaustive et devra varier en fonction de l'environnement de travail. La détermination des critères doit être faite – idéalement – par les personnes qui se chargeront de la création des mémoires de traduction (et donc des alignements) et par celles qui utiliseront les mémoires, afin que les intérêts de chacun soient correctement pris en compte.

Deux outils, deux expériences

WinAlign – Fédération internationale des sociétés de la Croix-Rouge et du Croissant-Rouge (Fédération)

1. Contexte – objectifs

   Comme son nom l'indique, la Fédération est l'organisme international qui regroupe toutes les sociétés de la Croix-Rouge et du Croissant-Rouge. Le Secrétariat de la Fédération, dont le siège est à Genève, a un service de traduction et conférences qui compte deux traductrices pour le français et une pour chacune des autres langues officielles, à savoir l'anglais, l'espagnol et l'arabe. Le Service de traduction compte également une responsable de la documentation, une répartitrice et trois assistants responsables notamment de la mise en forme des documents traduits. Il emploie en outre des traducteurs externes, dont le nombre varie en fonction du volume de travail. Conscient de la nécessité de produire des traductions de grande qualité, avec une terminologie fiable et cohérente, le Service a décidé d'acquérir un outil d'aide à la traduction. Il a opté pour les outils Trados, installés en avril 1999.

   Les objectifs étaient les suivants: créer des mémoires de traduction pour traiter des textes répétitifs (par ex. les avis de vacance de poste), pour les utiliser comme matériel de référence tant pour les traducteurs internes qu'externes; et créer une base de données terminologiques (ou plutôt un glossaire multilingue complet) pour garantir la cohésion et la fiabilité des termes typiques à la Fédération. Il avait également été envisagé d'échanger ces données avec le CICR, qui utilisait aussi MultiTerm.

   N'ayant pas participé à la prise de décision, je ne saurais dire exactement quels ont été les arguments qui ont convaincu le Service de traduction d'opter pour les outils Trados. Je pense cependant que ce choix a reposé sur deux critères: l'excellente réputation des outils Trados, notamment de MultiTerm, et la "promesse" de Trados de lancer une version supportant l'arabe.

2. Problèmes

   Une des particularités du traitement des documents à la Fédération est que seules les versions papier font foi. Ce sont les versions finales et une version électronique sera toujours considérée comme moins fiable que la version papier. Les documents traduits que le Service de traduction publie sont parfois modifiés par d'autres services, qui ne gardent pas toujours une dernière version électronique de l'original et/ou de la traduction.

   Lorsqu'on crée une mémoire de traduction (MT), il faut être sûr de ce qu'on y insère et il est inutile d'y intégrer des documents qui ont été révisés depuis leur parution. Le premier problème rencontré était donc de trouver la version finale des documents. Lorsque seule une version papier était disponible, il a fallu scanner le document et corriger le résultat du scanning avant même de pouvoir aligner.

   L'autre particularité tient au traitement de textes utilisé à la Fédération: à l'exception des postes de travail pour l'arabe, équipés avec Word, tout le personnel du Secrétariat, et donc du Service de traduction, travail avec WordPro (traitement de textes Lotus). WordPro n'étant pas un logiciel aussi répandu que Word, les constructeurs d'outils d'aide à la traduction l'ont à ce jour ignoré. Le deuxième problème, et sans doute le plus important, était donc que WinAlign ne reconnaissait pas le format WordPro (extension .lwp). Chaque document à aligner devait donc être ouvert dans WordPro (Word ne reconnaissant pas non plus ce format) et converti en RichTextFormat. Outre la considérable perte de temps que la conversion représentait, cela causait d'énormes problèmes pour la mise en forme des documents, qui n'était plus respectée dans le format rtf. Si l'on ajoute à tout cela le fait que la présentation des documents différaient selon la langue (par ex. liste à puce en français et un seul paragraphe avec éléments séparés par point-virgule en anglais), on peut imaginer le résultat à l'alignement.

   Étant donné la façon dont WinAlign présente le résultat d'alignement, sous forme de deux colonnes séparées par une zone de liens, si une paire de segments était mal alignée en début de document, il fallait revoir l'intégralité de l'alignement. L'interface de WinAlign s'est montrée alors extrêmement peu souple, obligeant un travail manuel à la souris qui, sur un texte de plusieurs dizaines de pages, peut se révéler particulièrement fastidieux.

3. Solutions

   Lorsqu'on cherche des solutions dans un tel cas de figure, il faut bien distinguer les problèmes qui sont inhérents à l'environnement et ceux qui sont dus à l'outil. WinAlign est certes un outil fiable, solide, qui présente des fonctionnalités intéressantes, comme l'ajout d'attributs et de listes d'abréviations etc. En ce qui concerne l'alignement lui-même, WinAlign est performant pour autant que l'on travaille avec des documents mis en forme dans Word (par exemple à l'aide des styles) de manière rigoureuse et que la mise en forme soit semblable dans les deux langues.

   Dans le cas présent, le fait que les documents disponibles étaient en format .lwp ne pouvait pas être changé et constituait un problème indépendant de l'outil lui-même. Il fallait donc trouver le moyen d'obtenir un premier résultat d'alignement le plus juste possible, de manière à éviter une perte de temps à la correction. La seule solution envisageable a donc été de procéder à une pré-édition des textes dans Word. Cette pré-édition consistait à ouvrir dans Word les deux textes à aligner, à en corriger la mise en forme générale (suppression des retours à la ligne manuels, par ex.), et à établir une mise en forme parallèle des deux textes (parallélisme dans les listes à puces, les tableaux, etc.). Une fois les deux textes pré-édités, il était possible de les aligner et d'obtenir un résultat satisfaisant, nécessitant un minimum de corrections.

   Cette solution était bien sûr biaisée sur bien des plans, car le temps gagné au moment de la correction de l'alignement dans WinAlign était en partie perdu à l'étape de la pré-édition. De plus, ce n'était une solution envisageable que dans la mesure où le corpus des textes à traiter n'était pas très important (une cinquantaine de textes au départ, puis ajout de textes au fur et à mesure de leur parution). Ce n'est certes pas une solution adéquate si l'on doit aligner plusieurs centaines de textes, dans quel cas il faudrait tous les ouvrir d'abord dans Word etc.

   Il faut noter ici que les options offertes par WinAlign supposées améliorer le résultat de l'alignement (prise en compte des styles, changement des règles de segmentation, etc.) se sont révélées particulièrement inefficaces pour régler le problème.