On Thu, Jan 09, 2003 at 11:52:32AM +0100, Guillaume Lelarge wrote:
Bonjour,
Déjà, merci pour les infos... po4a m'intéresse de plus en plus.
Ca, c'est cool.
Un autre intérêt, c'est qu'en coupant le document en morceaux, on isole les parties les unes des autres, et ca permet de voir rapidement quels morceaux ont changé, et permettre de les mettre a jour tout aussi rapidement. Plus besoin de lire tout le document pour se rendre compte que le seul changement est un ajout de virgule. Certes, diff fait ca. Mais que faire quand une section est déplacée, et qu'une virgule y est ajoutée? ;)
Là dessus, entièrement d'accord... les virgules sont mortelles :) D'un autre côté, isoler les 'morceaux' du document peut être dangereux, on n'a plus d'idée globale du document.
Je prétend que si, on garde l'idée globale du document. Les gens de KDE qui utilisent souvent cette approche prétendent que si. Les traducteurs professionels prétendent que si. Mais je me repete, la, non ?
Et la question qui revient tres souvent, c'est de savoir si un texte découpé en paragraphe reste compréhensible (et donc traduisible), ou si c'est mort. La réponse que j'aime bien faire, c'est que les docs de KDE sont traduites de cette facon depuis assez longtemps, et que comme par hasard, c'est les mieux traduites parmis la doc libre, il me semble.
Le mieux, ou le plus? en meilleur français, tu parles de la qualité ou de la quantité?
Des deux. Mais ce n'est pas un mystere. Débarrassés de galères techniques et rébarbatives, les traducteurs de KDE (appli et doc) peuvent se concentrer sur des choses comme uniformiser les traductions, faire la chasse aux typos, chercher de meilleures traductions pour des mots et expressions techniques et ainsi de suite. Pendant ce temps, nous, chez debian, on passe notre temps à chercher comment organiser le chaos ambiant. De l'agacement est né po4a.
Perso, je trouve que c'est de l'artisanat, et que faire des choses comme ca à la main alors qu'on est sensé etre assez performants techniquement, ca fait pas riche.
Oui, d'où cette discussion :)
Mais de toute façon, on peut utiliser CVS sur les .po au lieu des .(sg|x)ml .
A condition de bien passer les flags -I '^#:' à diff, pour éviter les changements sur les lignes générées automatiquement indiquant à quel endroit du source se trouve la chaine à traduire, car sinon, ca fait pleins de cacas inutiles.
Le gros désavantage de poxml à mes yeux, c'est qu'il gère les listes comme un benêt. C'est a dire qu'il met toute la liste dans une seule chaine à traduire, ce qui fait de bien trop gros morceaux. Les deux autres coupent au niveau de l'item de liste, ce qui fait des morceaux bien plus digestes.
Intéressant. Son gros avantage est qu'il est immédiatement disponible, contrairement à po4a si j'ai bien compris.
Well, contrairement aux modules sgml et xml de po4a, oui. Certes. Mais comment veux tu que je trouve du temps pour coder si je passe ma vie à faire des mails pour expliquer les avantages potentiels de la traduction de documentation avec gettext ? :)
L'interet de po4a par rapport aux deux autres, c'est que ca rend possible/simplifie l'ajout de texte non traduit. Du style une partie « À propos de cette traduction ». C'est à mon avis le point le plus douteux de l'approche par fichier po pour la traduction de documentation, mais je pense que la solution de po4a est assez générique et utilisable.
Je vous laisse lire les pages de manuels qui viennent avec le programme pour voir comment on fait ;)
Oui, ne t'en fais pas. Je vais les scruter.
Voici ou trouver le CVS de po4a, et plus particulierement sa doc principale, écrite de frais (cette nuit):
http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/po4a/po4a/doc/po4a.7.p...
Bye, Mt.