Archives

redaction technique

Ce tag est associé à 1

Colloque européen sur la rédaction technique

Le colloque européen sur la rédaction technique a été organisé le 17 avril 2010 à Paris par TCEurope, une association européenne de spécialistes de la communication technique regroupant des associations nationales, dont le Conseil des Rédacteurs Techniques (CRT) pour la France.

Ce colloque s’adressait non seulement aux rédacteurs techniques, mais aussi aux traducteurs.

Voici quelques sujets abordés au cours de ce colloque. Il s’agit de points qui ont attiré mon attention, et non d’un compte rendu exhaustif sur la journée.

Promotion d’un style de rédaction clair dans une organisation multilingue : exemple de l’Union européenne (présenté par Paul Strickland, responsable de la qualité linguistique auprès de la Direction générale de la traduction de la Commission européenne)

Les fonctionnaires européens travaillent dans un environnement multilingue et multiculturel et rédigent dans 90 % des cas en anglais, qui n’est pas forcément leur langue maternelle. Une étude interne a révélé que les multiples contributeurs intervenant sur la rédaction d’un texte et l’absence de relecture par une tierce personne pour au moins la moitié des textes produits nuisent à la compréhension du message. C’est pour éviter ces difficultés de compréhension et de traduction des documents qu’un guide de conseils de rédaction en anglais a été édité dans les 23 langues de l’Union, sous la direction de Paul Strickand. Ce guide, qui s’adresse en priorité au personnel de l’Union, peut être téléchargé par tout un chacun à l’adresse suivante : http://ec.europa.eu/translation/writing/clear_writing/how_to_write_clearly_fr.pdf.

Les rédacteurs de la Commission européenne sont désormais encouragés à utiliser les conseils de ce guide pour la rédaction de leurs documents et à envoyer les textes produits à l’équipe de Paul Strickand pour révision. Cette procédure – à caractère facultatif – permet d’assurer un contrôle qualité des documents rédigés au sein de la Commission avant traduction et/ou publication afin d’améliorer la compréhension des messages véhiculés par les textes.

Rédiger en anglais à destination des lecteurs non-anglophones (présenté par Alan Fisk, réviseur technique au Commonwealth Secretariat and the International Accounting Standards Board)

Cette intervention intéresse avant tout les anglophones en situation professionnelle et les enjoint à employer dans leurs documents des termes et expressions non idiomatiques, donc plus facilement compréhensibles par les lecteurs non-anglophones dont le niveau d’anglais n’est pas parfait. À titre d’exemple, « fault repair » est à préférer à « troubleshooting » car la première formulation n’est pas sujette à interprétation.

Il est également conseillé de manier l’humour avec précaution, car il risque de ne pas être compris par les lecteurs ne partageant pas les mêmes références culturelles.

Les coûts cachés d’une traduction de qualité (présenté par Henk Boxma, qui était alors développeur chez un éditeur de logiciels médicaux)

Combien de fois les localisateurs se sont-ils senti frustrés parce qu’un champ de l’écran du logiciel à traduire était trop court pour contenir la traduction ? Si vous avez connu cette situation, vous apprécierez sûrement l’intervention de Henk Boxma.

Henk Boxma a rapporté son expérience en tant que développeur informatique chez un éditeur de logiciels médicaux localisés dans plusieurs langues. Il a mis en évidence le décalage entre le développement des logiciels et les contraintes de développement liées à la localisation. Parmi les points qu’il a identifiés :

  • Les traducteurs réclamaient des champs plus longs dans les écrans des logiciels pour tenir compte de la longueur des mots dans des langues comme l’allemand, par exemple. En effet, il n’est pas rare que la traduction de certains champs soit tronquée à l’écran, car la longueur définie pour la chaîne de caractères au moment du développement est calquée sur l’anglais.
  • Les fichiers texte envoyés aux traducteurs étant dénués de contexte, les développeurs devaient renvoyer des informations complémentaires pour expliciter les champs à traduire. En l’occurrence, les chaînes à traduire étant extraites dans des fichiers texte sous forme de tableau, il manquait une colonne qui aurait pu indiquer aux traducteurs la nature du mot, ou encore le contexte d’apparition du champ en question.
  • La réutilisation des champs dans des écrans différents pouvait poser problème car leur traduction peut varier en fonction du contexte ; de plus, l’ordre des champs est susceptible de changer d’une langue à une autre. À titre d’exemple, « Product Name » se traduit par « Nom du produit » en français. Or, il n’est pas rare que les développeurs utilisent deux champs distincts, « Product » et « Name », qu’ils réutilisent séparément dans d’autres écrans. Cela donnait donc comme traduction des champs dans l’ordre affiché à l’écran « Produit » « Nom », au lieu d’un seul champ « Nom du produit », plus souhaitable.

Ainsi, pour Henk Boxma, la traduction professionnelle des logiciels induisait des coûts cachés de développement car les développeurs devaient finalement retravailler sur le produit pour répondre aux besoins des traducteurs.

C’est ainsi que lui est venu l’idée de traiter la localisation comme une « fonctionnalité » du produit à part entière et d’en tenir compte dès le début du projet, pour lui et son équipe de développeurs. Le respect des contraintes de localisation a ainsi eu un impact positif pour l’entreprise en termes de qualité des traductions et de délai de mise sur le marché des produits, tout en réduisant les coûts liés à cette phase du projet qui était auparavant omise.

Entrez votre adresse e-mail pour recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 135 autres abonnés

Archives