On Thu, Oct 04, 2001 at 11:31:14AM +0200, Nicolas Chauvat wrote:
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes... Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
Il ne s'agit pas forcément d'en faire quinze différentes, mais au moins de ne pas contraindre le traducteur potentiel à parcourir quinze sites de qunize projets différentes avant de trouver ce qui reste à faire et qui aider.
Bon, bon, c'est vrai que le raport investissement par nous/ gain pour les volontaires est favorable.
Yapluka.
Je n'ai rien contre le format po pour les *messages*des*programmes*, au contraire, mais vouloir l'utiliser pour autre chose frise l'hérésie. En particulier, je pense qu'il s'applique très très mal à de la documentation.
C'est vrai que c'est une hérésie. Je suis d'accord avec ca. Mais si ca marche (et l'experience KDE semble le montrer), et qu'on a aucune autre solution viable, alors pourquoi pas ?
Quand je parlais de XML comme format de base, c'était pour tout conserver sous forme de XML, documentation *et* messages de programmes, et de le retransformer en po au bon moment et au besoin. Mais je vais passer là-dessus pour l'instant, car je connais plusieurs fervents admirateurs du format po dans la salle et ne souhaite pas lancer une guerre de religion sur ce sujet.
Est ce que le projet de Karl de faire un dtd xml pour les fichiers po (ie, utiliser la grammaire xml pour le format des fichiers po) est hors sujet ici ? Perso, il me semble que les gains ne valent pas la peine qu'on se casse à le faire, mais si c'est fait tant mieux. Je ne suis pas tant admirateur de comment le format a été concu[¹], mais je constate que c'est un standard de fait dans le monde de la traduction...
¹: Par exemple, j'aimerais que msgmerge mette dans le fichier résultant le diff entre l'ancienne chaine originale et la nouvelle. Mais comme le format est un peu ... préhistorique, c'est pas possible sans casser les outils qui l'utilisent.
A mon avis, utiliser po pour des textes de documentation n'est pas une bonne idée. Ca marche, cela ne fait pas de doute. Mais ça n'aide pas à avoir un texte final cohérent. L'unité de base dans un programme est un message de quelques mots, au pire quelques lignes. Dans une documentation, c'est plutôt quelques phrases, voir quelques paragraphes. Et là, po traite beaucoup moins bien le problème AMHA.
Les messages (ie dans ce cas, les paragraphes) vont se retrouver dans le meme ordre que dans le texte. Alors pour gerer la coherence, c'est pas *si* différent. Le bonheur serait d'avoir comme fonctionnalité des frontaux de traduction (comme le mode d'emacs) de prévisualiser le document résultant. Ca semble faisable quand la chaine d'outil se sera un peu standardisée.
D'accord "Debian rules". Il n'empêche que pour le LDP c'est pareil et que ça ne marche pas si bien que ça... parce qu'il y a somme toute peu de gens, que tous sont occupés par ailleurs, et qu'il est difficile, sans vouloir faire du chiffre, de garder un rythme aussi soutenu pour la traduction que celui de la publication des documents (il y a *beaucoup* de gens qui travaillent en amont sur les documents du LDP).
Y'a pas de Debian rules dans mon propos, mais je présente en publique notre politique. Pas de jugement de valeur. Je connais un peu les autres projets, et y'a pleins de gens qui font mieux que nous, mais on fait de notre mieux.
A mon avis, il est donc important d'arriver à mettre en place un système qui facilite au maximum le boulot des traducteurs. Je sais que tu vas me répondre "kbabel" est ton ami", donc j'arrête :-)
kbabel, et toutes les interfaces du monde ne sont pas suffisante si y'a pas l'infrastructure derriere. Je parle ici du robot de mes reves (et des tiens?).
Je ne pense pas qu'on puisse faire une traduction de qualité en traduisant des phrases isolées sans savoir si c'est un livre, un programme ou autre chose...
Non, mais on peut traduire tous les formats avec le meme frontal s'ils arrivent au meme format dédié à la traduction. Et ensuite, en navigant entre les messages, tu vois le texte d'origine. D'ailleurs, perso, je n'utilise que le mode d'emacs car j'aime pas le fait qu'on ne puisse pas voir les messages précédents et suivants dans les frontaux graphiques que j'ai testé.
Mais je suis d'accord pour dire qu'il faudrait que toutes ses traductions se fasse avec un petit nombre d'outils communs (pas forcément un outil ou un format unique non plus, s'il y en a trois au plus, ça me paraît encore raisonnable).
C'est vrai. Mais alors, quels seraient les autres formats ? Peux tu nous donner un exemple de ce à quoi resemblerait grosso merdo le fichier XML que tu penses mieux adapté que po ? Y'a pas de sarcasme ici, ou quelque chose du genre. Juste de la vraie curiosité. J'ai pas ma carte dans la secte des croisés des fichiers Portable Object, mais jusque la, je n'ai pas vu de concurents sérieux...
Ensuite, on utiliserait tous des robots comme celui du projet de traduction ... ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
J'y travaille.
<<rires dans la salle>>
Non, sans rigoler, arrêter de me charrier quoi, j'y travaille vraiment !
Je ne ris pas, je suis curieux. T'as regardé ce que fesais le robot du TP, pour en tirer la substentifique moelle ?
Bye, Mt.