Contrairement à ce que son nom pourrait suggérer, il s'agit bien d'un logiciel. Celui-ci permet aux traducteurs d'enregistrer au format TMX, un format XML standardisé et ouvert, la concordance entre un segment dans une langue source et un segment dans une langue cible.
Décrit ainsi, cela ne semble pas vraiment intéressant ? Vous vous demandez peut-être ce que cela apporte par rapport aux bibliothèques Gettext (NdM : voir les entrées Fuzzy ) ? Vous ne voyez pas en quoi cela aide un traducteur ?
Eh bien, lisez le reste de l'article.
Le système que je propose, Mémoires Libres, est utilisable dès à présent, il n'attend que des contributeurs et c'est le but de cette dépêche que d'en trouver. Bien sûr, je vais aussi contacter les listes de diffusion liées à la traduction de logiciels libres. N'hésitez pas à critiquer le projet, que ce soit au niveau du site Web, de son organisation ou autre chose, ça lui permettra d'avancer.
NdM : KBabel et POedit disposent aussi d'outils de recherche dans des dictionnaires de chaînes traduites. Le projet KAider (devenu Lokalize) ainsi que la présentation ci-dessous montrent ce qu'apportent des mémoires de traduction en plus. La mémoire de traduction est une interface qui enregistre dans un fichier chacune des correspondances que l'utilisateur établit lors de la traduction. La mémoire inscrit dans un fichier qu'un segment dans telle langue correspond à tel segment dans une autre langue.
En quoi cela aide-t-il le traducteur ? Lors de la traduction de son texte, la mémoire enregistre chaque concordance dans un fichier TMX et à chaque fois que le traducteur aborde un nouveau segment, la mémoire regarde dans les fichiers TMX s'il existe des traductions similaires, elle précise (à l'aide d'un taux) le degré de similitude entre les segments sources. Le traducteur sait donc comment il a traduit le (ou les) segment(s) similaire(s) et connaît les termes ou la tournure de phrase utilisés précédemment et la typographie employée.
Cependant, un traducteur, en particulier dans le monde du libre, ne travaille pas seul et l'un des intérêts des mémoires de traduction, c'est qu'elles permettent à une ou plusieurs équipes de traducteurs de collaborer. Ainsi, la mémoire de traduction conserve les choix de traduction (typographie, la phraséologie, la terminologie, les options, unités de mesure et sigles par exemple) dans les fichiers TMX et fournit un moyen de les partager au sein des équipes de traduction.
Un autre intérêt des mémoires de traduction est l'accumulation des fichiers TMX afin d'avoir accès lors de la traduction à un large panel de concordances. Par le biais d'un dépôt entreposant les fichiers TMX, le traducteur (ou l'équipe de traducteurs) possède un stock de concordances qui lui permet, à chaque fois qu'il aborde un nouveau projet (que ce soit un logiciel, une documentation, un site Web), de ne pas retraduire mais au contraire de s'inspirer de ce qui a déjà été fait.
J'espère qu'à ce stade, vous entrevoyez les possibilités dans le monde du logiciel libre. Il existe deux mémoires de traduction libres, à ma connaissance, l'une est OmegaT, un logiciel en Java (fonctionnant avec IcedTea), l'autre étant Lokalize (anciennement Kaider). OmegaT est celui que je connais le mieux, étant donné qu'il existe depuis quelques années et l'ayant déjà utilisé. C'est un logiciel stable, pratique et dont l'interface est plutôt simple lorsque le concept de mémoire de traduction est connu. C'est un logiciel à part entière (certaines mémoires de traduction sont intégrées dans l'interface de Word), il permet d'importer plusieurs fichiers TMX à la fois, de ne modifier que les caractères du texte et non sa mise en page, de faire une couche d'abstraction entre les formats de fichier à traduire et le fichier TMX par le biais d'un système de filtre. Cela permet d'utiliser ses fichiers TMX avec divers formats et donc une meilleure réutilisation de celles-ci.
Concernant Lokalize, je ne l'ai pas encore testé, celui-ci n'étant pas encore en version stable à ma connaissance, il semble cependant prometteur.
Maintenant que vous connaissez un peu les concepts, voyons l'application que je propose.
L'idée est d'avoir un système qui permette de partager et de gérer les fichiers TMX libres. Les problèmes sont multiples, licences différentes (la traduction d'un document devant avoir la même licence que le document source), gestion des contextes (une traduction n'ayant de sens que dans un certain contexte, un autre contexte aurait possiblement entraîné une autre traduction), gestion des langues bien-sûr :), et, évidemment, tous les problèmes liés à la gestion d'une communauté, communication, rapport d'erreurs et demande. J'ai donc mis en place un site afin de présenter le projet, un dépôt Subversion pour gérer les fichiers TMX et le gestionnaire de tâches Flyspray, il y a aussi des listes de diffusion.
Le format TMX et les mémoires de traduction ne gérant pas encore d'elles-mêmes la contextualisation des segments (c'est-à-dire un système de balises qui permettrait par exemple d'indiquer : ce segment a pour contexte la traduction de l'interface d'un navigateur Web), il me fallait penser à une solution dans mon coin et rapporter ce problème en amont en espérant qu'il soit pris en considération. Une interface PHP/Python/base de données avec une gestion des balises pourrait résoudre le problème mais préférant avoir quelque chose de rapidement utilisable (mes compétences en développement ne sont que naissantes), j'ai simplement crée un système de dossiers pour trier les fichiers TMX par domaine puis par projet. Ainsi un traducteur pourra facilement retrouver tous les fichiers TMX liés à un même domaine, il devra en revanche faire davantage d'efforts pour trouver les mémoires d'un même projet (KDE, GNOME).
Les objectifs de ce projet sont divers et ambitieux, tout d'abord aider la traduction des logiciels libres afin qu'elle soit plus rapide et permettre d'harmoniser les traductions entre les divers projets ; arrêter de voir sur les listes de diffusion des traducteurs de logiciels libres toujours les mêmes questions sur des termes, typographies et autres questions que les mémoires de traduction résoudraient naturellement. Sur le long terme, donner la possibilité aux distributions de choisir leur traduction, par le biais d'une gestion poussée des fichiers TMX, permettre à différents projets, tels que GNOME et KDE, d'harmoniser leurs traductions. Il est même possible qu'un jour des traductions soient l'objet de recommandations par Freedesktop, ceci afin d'améliorer l'accessibilité.
Aller plus loin
- Mémoires libres (260 clics)
- Pour contribuer à mémoires libres (87 clics)
- OmegaT (GPL) (94 clics)
- Projet Lokalize (67 clics)
# bon article, mais le langage...
Posté par olivierweb . Évalué à 4.
In fine, si j'ai bien tout suivi, ce système c'est un KBabel collaboratif avec
* collaboration des traductions,
* partage de la mémoire
* moteur d'analyse linguistique.
En effet, KBabel dispose déjà d'une mémoire des traductions, affiche le taux de concordance, traduit si demandé ces concordances.
Pour ce qui est du projet, ça me semble vraiment intéressant.
Par contre, la définition des contextes sera sans doute un sujet à controverse : pourquoi le "Copier" du navigateur serait différent de celui du traitement de texte ou du gestionnaire de fichier ?
En tout cas, je pense que ce sujet (si ce n'est ce projet) est important pour permettre le développement des logiciels (libres) dans le monde non anglophone.
<aparté sur le langage>
Pour une fois, je vais me plaindre du niveau de langage. Ce texte est sensé être un article pas une pseudo discussion.
A-t-on gardé les cochons ensembles ? Les tournures de phrase m'ont choqué :
..., vous savez,...
...tellement bien écrites que, si vous avez le choix, ...
...eh bien...
En définitive, la première phrase est un peu difficile à lire.
...but... => objet
...ce qu'apportent des mémoires de traduction en plus... => ce qu'apportent en plus des mémoires de traduction
</langage>
[^] # Re: bon article, mais le langage...
Posté par lejocelyn (site web personnel) . Évalué à 2.
Pour le contexte, il ne s'agit pas de forcément traduire différemment, il s'agit de dire, attention, c'est un terme (par exemple : port, porte, portail, sont des mots qui suivant le domaine seront traduits en anglais différemment) et ce mot peut correspondre à une réalité différente suivant son contexte (le contexte, c'est énormément de chose, la date, l'auteur, le domaine, etc.). Le problème, c'est que les mémoires de traduction n'implémente pas un système de balise segment par segment, ça serait peut-etre lourd à gérer pour le traducteur, mais ça permettrait une gestion approfondie des correspondances.
Au niveau du registre de langue, j'ai voulu etre assez léger, peut-etre trop et on me l'a fait remarquer lors de la modération. Je ne le referai plus (car j'ai l'intention d'écrire d'autres articles) mais soyez gentils :p, c'est mon premier article.
[^] # Re: bon article, mais le langage...
Posté par Duncan Idaho . Évalué à 4.
La mémoire de traduction c'est intéressant, y a-t-il des travaux sur l'utilisation de corpus parallèles pour alimenter les bases de données de mémoire ? Je bosse un peu là dessus (ceux qui savent diront que non, ils auront raison), mais il est relativement facile, à partir de deux textes qui sont des traductions strictes, d'aligner les paragraphes, les phrases, les mots et expressions. C'est entre autres comme ça que google procède pour être capable de traduire différement le terme "main courante" (traduit en "handrail") des termes "main" et "courante" ("hand" et "running").
Concernant les manuels d'utilisations, ceux qui sont "bien fait" sont traduits automatiquement à partir de traductions antérieures. Une fois que vous avez traduit le manuel pour le modèle X de votre super appareil photo, il est envisageable de reprendre la même base pour le modèle Y qui ne rajoute que quelques fonctionnalités, et de s'appuyer justement sur les mémoires de traduction, accompagnées d'un dictionnaire bilingue, pour compléter les bouts de phrases manquants. Je sais qu'ils font comme ça chez Toyota (même s'ils ne font pas d'appareils photos, à ma connaissance).
[^] # Re: bon article
Posté par olivierweb . Évalué à 2.
KBabel ouvre les fichiers de traduction de Qt et les XLIFF.
Je dispose des traductions que j'ai réalisées dans les .ts pour les .po (il suffit de scanner avec kbabeldict un dossier comprenant les traductions).
par contre, POEdit récupère les traductions des .mo.
bonne écriture des prochains articles
# Il n'y a pas encore de mémoires
Posté par lejocelyn (site web personnel) . Évalué à 2.
# Note sur les notices
Posté par Perthmâd (site web personnel) . Évalué à 2.
Au point qu'il vaut mieux les lire directement en 普通话 ou en にっぽんご!
Et pas que les notices, j'étais tombé un jour sur une page de man complètement incompréhensible de la main d'un noble codeur nippon. (Je ne retrouve malheureusement pas le nom du programme...)
L'i18n, mangézan™!
# Déjà fait ?
Posté par olivierweb . Évalué à 2.
[^] # Re: Déjà fait ?
Posté par lejocelyn (site web personnel) . Évalué à 2.
Leur manière de faire est très intéressante, je dois avouer que ça me donne pas mal d'idées mais apparemment, je ne pourrais pas faire ce genre de choses chez Tuxfamily car mon accès à SVN est limité et je ne pourrais pas développer d'interface PHP à ce dernier. L'idée de développer une interface par exemple pour OmegaT et le dépôt SVN serait terrible mais il faudrait un système de balises ou de contextualisation pour pouvoir retrouver les mémoires après les avoir déposées.
[^] # Re: Déjà fait ?
Posté par Paul Chavent (site web personnel) . Évalué à 1.
Est-ce que ce sont les mémoire de traductions qui sont soumises à licences ? La licence s'applique à chaque entrée de la mémoire ? Elle s'applique au fichier .TMX ?
Parceque par exemple, on peut imaginer que deux textes sous deux licences différentes contiennent des blocs identiques sans qu'ils violent mutuellement leur licence. Mais les mémoires de traductions générées pour ces blocs seront identiques. Donc on se retrouve avec un problème de licence.
Ma question est donc : a-t-on un TMX par texte/document/oeuvre qui hérite de sa licence ?
Si oui, je pense qu'on perd l'intérêt de ce mécanisme puisqu'on ne peut plus merger les fichiers. Donc on a un TMX par source et on a pas de chance de factoriser les mémoires communes...
[^] # Re: Déjà fait ?
Posté par lejocelyn (site web personnel) . Évalué à 2.
Donc, le logiciel mémoire de traduction est soumis à une licence mais les fichiers TMX générés par le logiciel ne sont pas soumis à cette meme licence (après tout, on peut faire du code propriétaire avec Emacs, une mémoire de traduction n'étant qu'un éditeur de texte avec une fonction de complétion particulière). Les fichiers TMX sont soumis à la licence du texte traduits, un fichier TMX étant une traduction, une traduction possède la meme licence que le texte qu'il traduit.
Il est donc interdits de se servir d'un fichier TMX sous licence GPL pour traduire un logiciel propriétaire, après, prouver que le traducteur a utilisé le fichier TMX GPL pour traduire un logiciel propriétaire...
Chez les traducteurs professionnels, il est en théorie interdit de mélanger les fichiers issus des mémoires de traduction sur différents projets.
Nous, on a de la chance, la licence GPL nous permet de faire cela. Mais, il faut tout de meme classer les memoires selon les differentes licences. (GPL2, GPL2+, GPL3, BSD, etc.)
# Traduction hors contexte ?
Posté par pshunter . Évalué à 2.
Le logiciel indiquait :
« Écrire l'état du tampon »
Qui était une traduction correcte, dans l'absolu, de :
« Write buffer status »
Mais la bonne traduction était :
« État du tampon d'écriture »
Est-ce qu'un système tel qu'il est proposé ici pourrait corriger ce genre d'erreurs ? Sans voir le contexte (boîte de dialogue de gravure) dans lequel le texte est présenté à l'utilisateur, comment le traducteur peut-il trouver la bonne traduction ?
[^] # Re: Traduction hors contexte ?
Posté par lejocelyn (site web personnel) . Évalué à 2.
Par exemple, dans un fichier TMX, on trouvera grosso modo : lang="en-US" msg="Write buffer status" lang="fr-FR" msg="État du tampon d'écriture". Ensuite lorsqu'un traducteur se retrouve en face d'un segment contenant : "Write CD status", la mémoire montrera au traducteur : "Write buffer status : État du tampon d'écriture, similarité= 60 %."
Dans le cas présent, ça n'aide pas et ça pourrait même pousser à l'erreur, ceci dit, c'est au traducteur de traduire, pas au logiciel, le logiciel n'est là que pour l'aider, lui ressortir les termes, les tournures de phrases et autres choses déjà traduites. Ce ne sont que des indications et c'est toujours le traducteur qui travaille !!!
Donc ça ne permet pas de connaître le contexte du texte sur lequel le traducteur travaille, en revanche ça permet d'en connaître un minimum sur ce que propose la mémoire de traduction. Je voudrais bien pouvoir en faire davantage à ce niveau mais ça passe par beaucoup de développement.
Le système que je propose ne fait donc rien, si le traducteur ne sait pas ce qu'il traduit, y a rien à faire pour lui. Il doit avoir le produit sous les yeux et pouvoir l'utiliser pour faire une traduction correcte. Sinon, ça doit se faire au niveau du format .po (pour les logiciels) qui indiquerait le contexte du message à traduire.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.