[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: théorie mémoire de traduction



On Thu, Jul 17, 2003 at 11:59:59AM +0900, suzume@mx82.tiki.ne.jp wrote:
> de fait, suite a ma requete j'ai recu un memoire de maitrise traitant 
> des tm (comme on dit en franglish: translation memories).
> 
> le principe c'est d'identifier des chaines de caracteres entre les 
> documents source/cible et d'etablir la probabilite qu'une chaine 
> ressemblant a une autre en source ait la meme correspondence en cible.
> 
> d'ou:
> 	1) probleme du decoupage de la source en segments pertinents
> 	2) probleme de la pertinence du decoupage pour le texte cible
> 	3) probleme du sens que la probabilite (c-a-d la ressemblance) 
> d'identite entre deux segments propose
> 
> d'une maniere generale, la tm semble s'imposer pour des textes 
> _techniques_ sans questionner leur format (bien que trados, le big 
> machin sur le marche ait ete approprie recemment par m$ et que le 
> format de ses memoires: tmx, semble s'imposer comme un standart). la tm 
> est un systeme qui selon les applications absorbe aussi bien du /doc 
> que du html ou xml (ou encore le format oo, je ne me souvient plus du 
> suffixe).

oo => xml :)

Donc, je dois confondre, et parler des usines a gaz hors de prix /integrant
des tm/.

> par ailleurs, les systemes de maintenance de trads existent, entre 
> autre trados, qui est adopte par l'UE pour tous les documents 
> officiels. je n'utilise pas la bete vu son prix et mes besoins mais 
> considerant le nombre de boites qui ne t'acceptent comme traducteur que 
> si tu as trados ca a l'air d'etre _tres_ important sur le marche.
> 
> >Mon avis, c'est qu'il faut pas suivre l'approche windows (des 
> >bloatwares
> >tentant de resoudre tous les pbs de la terre), mais l'approche unix 
> >(des
> >programmes specialises pouvant collaborer -- je ne parle pas d'emacs, 
> >un
> >bloatware resolvant effectivement tous les problemes de la terre ;).
> 
> c'est une approche qui a ses points forts.
> 
> pense a ceci:
> 
> une tm (c'est pas gros, il y a omegaT, une app java opensource qui fait 
> autour de 400ko) qui tourne avec en memoire l'essentiel des segments 
> des pages man deja traduits: ca produit une base de donnee de segments 
> qui te premettent de faire un sacre boulot de defrichage pour les pages 
> non traduites, surtout considerant la maniere relativement formelle 
> d'ecriture d'une page man...

Donc, si une TM c'est ca, ca change mon avis. Ca devient une piece du
puzzle, aussi utile que les autres. Je m'a gourre', sorry.

> le fichier cible est pris en charge par un systeme de controle de 
> version, et hop !

Mouais. Ca te donne une piece et demi du puzzle, mais tu sais toujours pas
comment extraire/injecter, editer agreablement, et CVS n'est pas tres adapte
au moulinage des fichiers po, ou les commentaires changent tout le temps
sans que personne n'en ait rien a faire. Et quid de la verification de
syntaxe automatique ou des gestions de bogues de traduction ? Quid de la
notification des changements aux traducteurs ? Et comment uniformiser les
choix de traduction sans un dico accessible en ecriture aux traducteurs ?

Je persiste, les TM, c'est tres bien, mais ca ne se suffit pas en soit meme
pour nous.

> le format po est considere comme format a introduire sur omegaT, 
> probleme, le developpeur est indisponible. a l'heure actuelle, le 
> mainteneur de la page (marc prior, traducteur professionel) est en 
> train de galerer pour apprendre java et se taper les modifs 
> necessaires...

J'avais cause avec le mainteneur d'omegaT a une epoque. Je lui disais que
traduire sans extraire ne sert a rien (forcement, je fais du lobbying pour
mes idees, hein), et il etait d'accord. Mais ni l'un ni l'autre n'avons fait
qqch pour que ca change.

Je suis alergique au java sous toutes ses formes (langage jouet de prototypage a
mes yeux, comme le perl ou le python, mais en plus pedant), et le fait qu'il se
contente d'extraire depuis le xml de oo, traduire, reinjecte m'avait paru de
mauvaise augure pour la suite.

> >Les pieces du puzzle murrissent, mais personne n'a encore essaye de les
> >assembler. Ca promet d'etre .... enrichissant.
> 
> ouais tout a fait, et il me semble que debian est le lieu privilegie 
> pour ce genre de tentatives.

Je pense aussi. On est bien etabli comme equipe de traduction [*], on est
assez nombreux [*], tres actifs [*], on a de l'experience[*], y'a des gens
techniquement performants, des linguistes et meme des gens normaux qui nous
remettent les pieds sur terre au besoin.

([*]: dans le monde libre). Disons qu'on est des amateurs eclaires.

> >Quant a freecats, je serais bien aller voir de quoi il retournait, 
> >mais la
> >page web me retourne 403: Forbidden...
> 
> ouais ben y faut chercher un peu mieux. google te donne un certain 
> nombre de pages, ils ont un site sur savanah (orthographe ?) mais le 
> plus important c'est la liste a l'heure actuelle puisque le projet 
[...]

Nan, zami, c'est les pages webs sur savannah qui me retournent un 403.
http://www.nongnu.org/freecats/

C'est le site web du projet, savannah lui meme marche tres bien, mais bon.
Rien dans le CVS des sources, rien dans le CVS des pages webs, rien dans les
forums, rien dans la zone de telechargement...

J'esperais au moins trouver les deux design documents dont parle Henri dans
http://mail.gnu.org/archive/html/freecats-dev/2003-07/msg00001.html
Ils seraient a leur place dans la zone de telechargement, aussi.

Ca fait pas tres ouvert, comme projet, la. Je sais que vous commencez, mais
tout de meme.



Le probleme ici, il me semble, c'est que les systemes de traduction pro font
rever les traducteurs pro, mais pas les traducteurs amateurs du libre, car
leurs besoins ne sont pas exactement les memes. Je ne suis pas hermetique
aux charmes des TM, mais je refuse de leur donner un status superieur a
"piece necessaire du puzzle"...

Et si on voulais faire un vrai groupware de traduction, le plus dur sera de
choisir ou se trouve son centre, quelle piece est la piece maitresse. Je
pense que ca doit etre un robot a la TP (ou meme, soyons fous, a la ddtp).

 Interface:
   - Type B2B avec une entree pour les traducteurs et relecteurs et une
     autre pour les "clients", c'est a dire les developpeurs voulant faire
     traduire leurs programmes et documentation, ou autre.
   - mail+HTTP+socket directe pour les clients interactifs (qui sont
     quasi indispensables pour la plupart des traducteurs).
   
 Service de centralisation:
   - des choses a traduire
   - des choses traduites, avec gestion des versions et notification
   - une TM
   - un dico 
   - rapports de relectures et autres bogues
   
Et ensuite, une fois que le coeur fonctionne, on peut reflechir a faire des
moulinettes sur les serveurs debian qui injectent dans le systeme les choses
a traduire, et recuperent depuis ce systeme les traductions pretes pour les
mettre dans les paquets.

Bye, Mt.

-- 
Dans un pays d'extrême droite, On se torche avec les doigts, 
Y'a plus de journaux pour ça.
   -- Frères misère



Reply to: