Archives

localisation

Ce tag est associé à 2 articles

Master ILTS Job Dating

Le département professionnalisation de L’UFR EILA de l’Université Paris-Diderot vous invite à participer à la 2ème édition du Job Dating Master Pro ILTS

Le jeudi 24 juin 2010 de 10h à 18h
Bâtiment  des Grands Moulins, Salle 479 C
Université Paris Diderot-Paris7
75205 PARIS CEDEX 13

Qu’est-ce que le Job Dating ILTS ?

Calqué sur le principe du speed dating et créé en 2009 par le département de professionnalisation de l’UFR EILA le job dating est un mode de rencontre et d’échange original
qui réunit les professionnels et les étudiants. Cet événement a pour objectif de favoriser les synergies entre les entreprises porteuses de projets et les jeunes diplômés en quête
de stages et d’une formation pour leur année d’apprentissage.
L’année dernière plus d’une douzaine d’entreprises ont participé au job dating et ont pu rencontrer une trentaine d’étudiants.

Pourquoi le Job Dating ILTS ?

Vous optimisez votre recrutement en rencontrant un maximum de candidats en un minimum de temps.
Vous découvrez toute la gamme des profils sélectionnés pour 2010-2011 lors de courts entretiens de 10 à 12 minutes.
Vous créez des opportunités et augmentez vos chances de faire le meilleur choix lors de cette première prise de contact.

Comment s’inscrire ?

Venez nombreux cette année !
Merci de m’indiquer par retour de mail ou en utilisant le formulaire GOOGLE ci-dessous si vous souhaitez participer à cette session de job dating, ainsi que le nombre de participants
et la durée de votre intervention (journée complète, matinée, après midi).
http://spreadsheets.google.com/viewform?formkey=dHdldnpNa0ZRX1l1WFV5clhrX1VCOHc6MQ

Comment venir ?

Plan et infos accès Paris Diderot : http://www.univ-paris-diderot.fr/sc/site.php?bc=implantations&np=SitePRG&g=m
Plan et infos accès Grands Moulins : http://www.univ-paris-diderot.fr/sc/site.php?bc=implantations&np=MOULINS&g=sm

Publicités

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