Re: théorie mémoire de traduction
d'une manière générale, 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 récemment par m$ et que le
format de ses mémoires: tmx, semble s'imposer comme un standard). la
tm
est un système 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 :)
ouais, je sais ça, je parle du suffixe sxw (après vérification) :)
Donc, je dois confondre, et parler des usines a gaz hors de prix
/intégrant
des tm/.
cf. le mémoire que tu as du recevoir.
une tm (c'est pas gros, il y a omegaT, une app java opensource qui
fait
autour de 400ko) qui tourne avec en mémoire l'essentiel des segments
des pages man deja traduits: ça produit une base de donnée de segments
qui te permettent de faire un sacre boulot de défrichage pour les
pages
non traduites, surtout considérant la manière relativement formelle
d'écriture d'une page man...
Donc, si une TM c'est ça, ça change mon avis. Ca devient une pièce du
puzzle, aussi utile que les autres. Je m'a gouré', sorry.
pas de problème. en fait il y a même une macro de m$word développé par
un français qui fonctionne comme tm. le problème c'est ce que tu dis à
propos de emacs: quand ça veut tout faire ça devient gros. les machins
genre trados incluent tout, pas seulement le gestionnaire de tm mais
aussi l'amont et l'aval.
le fichier cible est pris en charge par un système de contrôle 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 ?
à propos d'extraction/injection/édition, je compare omegaT à appleglot
(ok, rien à voir, je sais :) et le jour ou omegaT supportera le format
appleglot je suis preneur. ok, je n'ai pas eu des masses de contrats
pour des produits apple récemment mais bon ... ;)
appleglot te met sous forme de tag "lisibles" toutes les chaînes issues
des fichiers lproj. comme c'est du osx c'est basé sur xml mais c'est
encore pire qu'éditer du html. l'avantage c'est qu'il réinjecte tout
correctement dans le lproj de ta langue cible sans que tu n'ais rien à
faire.
il me semble que:
1) vérification de syntaxe
2) gestion des bogues
3) notification des changements
4) uniformisation des choix
correspond à l'amont/aval du tm.
si je ne me trompe pas freecats est (enfin, _sera_) basé sur une
structure client/serveur qui répond à 4) quand à 3 il me semble qu'il y
en a un prototype avec le ddtp. pour 1) et 2) je ne vois pas comment tu
peux automatiser ça sans intervention humaine ?
Je persiste, les TM, c'est tres bien, mais ca ne se suffit pas en soit
meme
pour nous.
j'ai rien dit de ce genre :)
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 me goure peut-être mais quand tu dis "extraire" tu parle d'extraire
des chaînes à partir du code compilé ? ou alors tout simplement de
gérer correctement les fichiers à format tagés (genre xml) ? à propos
keith (le dvp d'omegaT) à l'air d'être très très peu dispo en ce
momment, mais le mainteneur (marc prior) se démène pour faire en sorte
que omegaT avance dans le bon sens, sauf qu'il est traducteur, pas
programmateur java...
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.
tu peux développer ?
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.
je crois que il y a eu une tentative récente pour clarifier les
procédure de participation sur le projet de traduction, est-ce qu'il
est possible de développer ce document pour clarifier l'ensemble du
processus ? c-à-d faire un "méta" document sur comment le projet
fonctionne globalement (ou devrait fonctionner dans l'idéal) ? je crois
que ce serait un plus pour des expériences similaires du monde "libre".
a propos, en tant que traducteur bénévole d'attac je leur avais
conseillé de prendre l'exemple de debian-l10n-french. problème: la
procédure ici manque de "modèle" clair (ou clarifié) pour être
applicable hors du monde de l'informatique...
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.
moi aussi pour te dire la vérité :) mais apparemment ça commence tout
juste, laisse _leur_ du temps !
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"...
honetement, je crois qu'il n'y a pas de rêve, juste la nécessité
d'utiliser des produits standardisé par l'industrie de la traduction
qui font que 1) tu bosses un pouielleme plus vite mais que 2) tu es
payé considérablement moins cher puisque la machine fait ton boulot à
ta place (problème de la facturation des segments déclarés identiques
par la machine...)
je ne suis pas certain que la plupart des traducteurs (ie les gens qui
mangent grâce à leur compétence linguistique) soient hyper excités par
le fait que leurs outils évoluent au rythme de la volonté de Bill Gates
et consorts et donc que pour continuer à vivre de leur travail ils
doivent continuellement réinvestir dans des usines à gaz. Il me semble
que l'expérience débian (ie projet _hyper_ complexe avec un taux de
réussite/satisfaction relativement élevé) est à modéliser (aussi bien
en terme de procédure que d'outillage) pour fournir au monde du
non-libre les options nécessaires à une autonomisation de la production
(hahaha) translinguistique !
si un tm trouvait sa place dans debian le projet de traduction n'en
serait que bénéficiaire. pièce du big puzzle. pas panacée.
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.
ben tu vois que tu as plein d'idées :)
et on en est où de ce truc génial ?
jch
Reply to: