[Freecats-Dev] Feedback (large bits in French) (specifications document)

[Henri Chorand]

Bonsoir Julien,

Je te réponds en français et mets en copie sur la liste, mais il y a 
trois lecteurs qui ne lisent pas la langue de San Antonio. La prochaine 
fois, ce sera en anglais dans la langue de Douglas Adams  ;-)

Short excerpt in English:
Sorry for Charles, David & Simos - but this one is in French. Next time, 
I'll translate it (when I'll be fresh again after a week-end spent with 
a little more sleep and a little less frantic browsing and typing).

So, Julien just returned me his feedback about the first Specifications 
document.

BTW, please try to provide one within one week or so, after which I'll 
produce a new version of it (in English) and split it into its chapters 
as planned. Julien's ideas more or less extend what's being already 
said, so there is nothing "revolutionary" here, which is also why I'm lazy.

And... at the end of this message, you'll find a nice introduction to 
Japan's simultaneous use of 3 alphabets.
<Troll mode ON>
Yes, it was somewhat on purpose, or they never could decide which one 
they preferred - like between Gnome & KDE?
</Troll mode OFF>

> Après relecture des specs de FreeCATS, voici mes remarques :
>
> Tout d'abord, je trouve que le document est très complet et parfaitement 
> lisible (ce qui n'est pas toujours le cas).

Merci :-)

> L'étendue de la liste des formats compatibles résume parfaitement 
> l'ambition du projet : réussir là où d'autres ont échoué ou parfois
> même rien tenté...

Thierry a vite insisté (à juste titre) sur la nécessité d'un format de 
travail bilingue "pivot" (BWDF dans mon jargon) et de la batterie de 
filtres de conversion.

Comme cela, on règle "une fois pour toutes" [en principe] les problèmes 
liés à la traduction de texte, balisé ou non, puis on ajoute un à un les 
formats sans recommencer le boulot à chaque fois.

La définition du BWDF est la prochaine étape du projet, après le serveur 
(qui se fiche de savoir comment le client bidouille avec ses fichiers, 
il ne s'occupe de segments). J'espère que Thierry retrouvera un peu de 
temps pour ça d'ici quelques semaines (ou plus).

> Dans l'ensemble, je n'ai rien à redire. Sauf peut-être... l'interface 
> utilisateur.
> J'ai l'impression que l'on s'en tient un peu trop à celle de Trados.

Volontairement peu fouillée - j'accepte la critique. Nous avons juste 
défini quelques principes intéressants lors de la première réunion.

En gros, nous savons que l'interface doit permettre ce qu'autorise Tag 
Editor de Trados (d'où la barre d'outils "compatible", bien évidemment 
c'est pour y rajouter toutes nos futures bonnes idées).

> Certaines fonctions pourraient être utiles (comme le marquage 
> de TU qui sont laissées de côté pour traduction ultérieure : Pending 
> TUs).

Prévu (dans ma tête) avec un indicateur Status par segment (dans la TM 
et affichage dans le client), cf DB_indexing 0.2.1.rtf
> Status (integer value used to qualify TUs depending on status),
> managed by translation client & server, for instance: 0 = legacy,
> 1 = untranslated, 2 = translated, 3 = reviewed (validated):

Donc en gros, quand tu vois le segment tu y saisis une traduction ou 
pas, et tu le refermes sans enregistrer (bouton ")" de la barre 
d'outils) et l'indicateur code Status restera automatiquement à 
"untranslated"
D'ailleurs suite à ta question, en fait il serait sans doute plus 
cohérent d'avoir 0 "untranslated" et 1 "legacy" (état plus avancé que 
"untranslated" et moins avancé que "translated") - je change le doc.

> De même l'utilisation de documents bilingues ne nous permet pas 
> d'obtenir un aperçu en temps réel du document cible.

C'est un point délicat.
Pour tout ce qui est HTML/XML, on peut envisager un mode aperçu via un 
navigateur.
Pour tous les fichiers de ressources en texte seul, pas besoin.
Quant aux autres formats de fichiers, je pense qu'il faudra prévoir, 
dans certains cas, des aperçus spécifiques à rajouter petit à petit (ex. 
Latex).

> En y ajoutant un modèle du genre <tag>{index TU1}<tag1>{index TU2}... 
> cela nous permettrait de proposer un mode visuel qui serait mis à jour
> à chaque validation d'une TU.

Le mode aperçu proposé à la première réunion inclut deux boutons, 
"Source" et "Cible". En cliquant dessus pour les activer et les 
désactiver, on doit pouvoir avoir un "semi-aperçu" pour le format texte. 
Si on part dans un aperçu WYSIWIG, on part dans les embrouilles pour 
lesquelles je ne me sens pas de taille - je préfère les laisser à 
d'autres (ex. Wordfast).

> Le fichier temporaire serait traité de cette manière : isolement des 
> tags (external)

Oui. On segmente et on garde des segments contenant du texte (avec 
ponctuation) et les balises internes de mise en forme (internes).

> et remplacement du segment source par l'index de TU 
> attribué par la MT.

C'est à voir. Thierry l'a proposé - si j'ai bien compris ça s'appelle 
"tokenization". Je voudrais y réfléchir plus avant - c'est peut-être la 
porte ouverte au stockage des fichiers à traduire sur un serveur, dont 
je me méfie.
Je pense qu'il faut garder la maîtrise des fichiers sur un système de 
fichiers local, car il peut exister toute une série de bonnes raisons 
pour ça, la première étant la possibilité de faire des manipulations "ad 
hoc" dans des combinaisons de cas impossibles à prévoir à l'avance, sans 
lesquelles le fichier peut ne pas passer sur le système (exemple: 
problème de formatage).

> Ensuite, remplacement de la chaîne contenant l'index
> de TU par le segment cible.

Je verrais plutôt: stockage de la source et de la cible au sein de la 
même TU, accompagnés des informations annexes.
Creation Timestamp, Creation Author, Last update Timestamp et Last 
update Author devraient être gérés par le serveur.
Pour le "fuzzy rate" obtenu lors de la première ouverture de la TU, 
classiquement Trados le conserve dans le document. Dans la mesure où le 
contenu de la MT s'enrichit au fur et à mesure, soit on garde la valeur 
initiale dans le BWDF pour s'en rappeler (et la valeur retournée par le 
serveur de MT change dès qu'on a traduit le segment, Trados fait comme 
ça), soit on la considère comme inutile et on la vire.

> On pourrait ajouter cette option d'aperçu pour les pages de type
> HTML par exemple... (un peu à la manière de Globalsight)

Que je ne connais pas. Oui (voir plus haut).

> Je pense qu'il va vraiment falloir chercher tous les avantages des 
> interfaces actuelles pour en faire un 'best-of'. Nous avons la chance 
> d'être chacun un futur utilisateur final de ce logiciel.

Tout à fait. Et wxWindow devrait nous apporter la possibilité de créer 
un client graphique sophistiqué.

> Nous savons ce que nous voulons, et nous l'aurons!!

C'est avec cette attitude qu'on va l'avoir, ça c'est certain.

> Pour ce qui concerne le japonais, voici un petit truc que j'ai
> trouvé (pour info)

> --------------------------------------------------
> Hiragana and Katakana
> By the 6th century c.e., the island of Japan still had no writing 
> system. Fortunately, there was a country nearby that had a pretty good 
> one (see above). Japanese is an agglutinating language, whereas Chinese 
> is an isolating language, so early attempts to impose Chinese characters 
> on the Japanese language failed. During the Heian period, aristrocratic 
> women developed the hiragana and katakana, two phonetic alphabets based 
> on simplified Chinese characters, to supplement the kanji or Chinese 
> characters. The wacky Japanese still use all three at once.
>  
> source : http://www.princeton.edu/~skerratt/scripts.html
> --------------------------------------------------

Très joli.

> Sinon, c'est parfait. Je suis de plus en plus enthousiaste!

Ouaip, moi aussi !


Henri