JC Helary wrote:
Est-ce que vous avez une méthodologie particulière pour la cohérence terminologique ?
Au sein d'un même document le problème de la cohérence ne se pose pas, ou en tout cas ne devrait pas se poser. On trouve parfois des traducteurs qui ne sont pas cohérents à ce niveau et qui utilisent des expressions différentes dans la langue de destination pour une même expression dans la langue de départ. Ceci n'est évidemment pas souhaitable, et ne devrait pas arriver.
Entre deux textes différents, mais dans un même domaine technique, on apprécie la liberté de l'interprétation ;-) En fait, il y a peu de domaines où le vocabulaire est normalisé ou standardisé, aussi bien dans la langue de départ que dans la langue de destination. Il faut aussi comprendre que la signification d'un mot ou de sa traduction, peut-être très important au niveau de la validité juridique du brevet, ou de sa portée. On privilégie donc, à la fois à la rédaction qu'à la traduction, des termes généraliste, plutôt que des termes spécialisés, là où cela est possible.
Bon, alors moi je suis au moins 2 niveau en dessous de toi, puisque en général je suis le destinataire final du fichier "externalisé", pour traduction :) Et de fait, je trouve que les agences manquent cruellement d'imagination puisque au final on se trouve soit avec un fichier scanné image ou bien un fichier word (même pour des sites internet) avec toutes les possibilités intermédiaires.
Oui, nous avons déjà connu ce problème également.
En tant que commanditaire de traduction, est-ce que tu serai tenté de demandé à tes fournisseurs une livraison en ODF à partir de ton ODF ?
Tenté, oui, très fortement, mais à l'heure actuelle, ce n'est pas réaliste. On a déjà du mal à ce qu'ils nous fournissent les images traduites sous forme PNG, voire JPG, alors encore moins dans un format ouvert. Nous devons nous mêmes fournir des traductions à nos agents étrangers, qui eux utilisent presqu'exclusivement Word, ce qui nous oblige à passer par une conversion de toutes façons, avec tous les problèmes inhérents de police, mise en page, etc.
Est-ce que tu penses que tes fournisseurs sauraient traiter ça->soit dans OOo soit directement dans un outil ?
Je ne pense pas à l'heure actuelle. Dans mon expérience, bcp de traducteurs ne maîtrisent pas au départ l'outil de traitement de texte. Certains acceptent un format de présentation si on leur fournit le modèle *.DOT (sic) qui va ;-)
Est-ce que tu penses que la qualité de la prestation finale serait plus élevée si l'ensemble du processus ne passait pas par des conversions vers MSO ?
Oui, indubitablement.
Désolé pour toutes ces questions, c'est la première fois que je parle avec un "client" qui crée ses documents en OOo et donc ton point de vue m'intéresse au plus haut point :)
Il n'y a pas de problème, je suis 100% pour en parler :-))
Au Japon, on a Mozilla et OOo qui ont commencé à ce mettre à des processus intégrant des outils libres (Mozilla utilise OmegaT pour l'interface et la doc, OOo utilise OLT depuis longtemps et parfois OmegaT etc.) Et on a commencé à mettre en place une infrastructure de mise en commun de mémoires etc. Les processus sont encore très flous mais ça avance (marrant de voir l'initiative Sun que Sophie vient de transmettre ce matin, c'est une partie de ce qui a été lancé ici, mais en mieux, Sun oblige :)
Oui, j'ai vu l'annonce, cela à l'air intéressant.
Par contre la présentation "business" que je fais en Juin (17e conférence Ijet) je veux la centrer sur mon activité en tant que freelance pour convaincre non seulement d'autre traducteurs de la validité des outils et processus (qui malheureusement n'impliquent OOo qu'à un niveau secondaire), mais aussi les agences, pour lesquelles une gestion libre permet (éventuellement, si bien appliquée) une amélioration de la qualité, et au final, des commanditaires qui devraient être incités à se mettre à la création/ gestion de documents par OOo/ODF.
Entièrement d'accord.
Donc on retourne à la case départ: quel est l'intérêt pour un commanditaire de traduction de gérer son patrimoine dans OOo, (vu qu'il existe des outils très performants qui intègrent parfaitement les produits MSO). On a déjà démarré des discussions semblables dans le groupe utilisateur de OmegaT pour voir comment les agences utilisatrices intègrent l'outil dans leur processus et si oui ou non ça les incite à fonctionner plus avec OOo ou non, mais c'est vrai que d'avoir l'avis du commanditaire c'est plus interessant que de discuter entre personnes convaincues :)
Notre souci principal est que la traduction soit le reflet en registre et nuance de l'original, car c'est ce qui importe lorsque nos textes sont lus par des juges en cas d'action en contrefaçon. Les brevets ne sont pas en soi des documents bien rédigés au niveau de la construction grammaticale, parce que ce sont des instruments juridiques, écrits par des spécialistes qui connaissent les rouages du système et qui se comportent à la rédaction pour donner un avantage sémantique (là, où cela est possible) aut titulaire pour lequel ils rédigent. Du coup, on ne peut pas dire que l'on soit très représentatif de ce qui se fait en matière de traduction technique classique.
Espérant avoir au moins éclairé ta lanterne un peu sur notre secteur un peu étrange ;-)
Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
