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

Re: Passer au PO pour la traduction du guide d'installation?




On 4 août 07, at 01:58, Christian Perrier wrote:

l'idéal. Donc en ce moment, la vague "pootle" qui ne fait que renforcer cette tendance _surtout_ sur la documentation (tout est mouliné en PO) ne
va pas dans le bon sens du tout à mon avis.

Cela étant, je reste à convaincre sur le fait que les fichiers PO ne
soient pas adapté à de la traduction de gros documents. L'argument sur
le contexte est un peu de la blague: quand on traduit avec gettext un
gros document découpé en paragraphes, on a les paragraphes les uns à
la suite des autres, donc le contexte est bel et bien là.

Ce n'est pas tant ce contexte là, que le contexte en rapport avec d'autres fichiers. Par exemple, gettext te met des fuzzy sans faire référence au segment source du fuzzy, c'est au traducteur de deviner. Et il n'y a qu'une proposition.

Par ailleurs, les outils qui éditent du PO ne sont que des éditeurs de texte spécialisés en PO, pas des machines à faire correspondre du contexte. Certains outils proposent l'utilisation de TMX comme compendia mais c'est pour effectuer des recherches dedans, pas pour obtenir automatiquement des correspondances.

Cela étant, faut rester ouvert, donc OmegaT, pourquoi pas...mais le
fait qu'il lui faille un environnement d'exécution Java est pour moi
un peu rédhibitoire: ça renforce le caractère usinagazesque de la
chose.

:) Si quelqu'un avait la volonté de porter le code en objective-C ou je ne sais pas quoi il n'y aurait pas de problème. Ce qu c'est passé c'est que le code était en C++ à l'origine et que quand il a été découvert par le responsable de Linux4Translators qui avait décidé de cesser de travailler avec Windows et les produits professionnels ne tournant que sous Windows, le code est passé sous Java parce qu'à l'époque c'était la manière la plus simple pour avoir quelque chose d'immédiatement multiplateforme.

Ce n'est pas vraiment un choix politique et il est clair que si on avait une application native par plateforme on s'en porterai bien mieux. Mais il faut des codeurs pour ça et on en manque. Ou plutôt, ceux-ci s'intéressent plus à faire évoluer l'application qu'à faire des "méta" modifications qui au final apporteront plus de complexité pour la maintenance.

Aujourd'hui on travaille sur l'ajout de vérification orthographique avec hunspell et les dictionnaires OOo, sur une meilleure utilisation des glossaires et sur l'intégration de Lucene comme moteur d'indexation/recherche. Si tout se passe bien ce sera bouclé pour l'automne.

Thomas Hurieux nous avait fourni un filtre pour le format PO, mais mes tentatives pour utiliser le PO fournit par les outils des créateurs de Pootle (en particulier pour la localisation de OOo) m'on convaincu que aussi bien SUN que Pootle se trompaient: les fichiers source sont du XML et en les passant en PO on retire tout ce qui fait l'avantage du XML: l'isolation des codes du texte. Tout est considéré comme texte et c'est hyper pénible à gérer (l'ensemble de Pootle/ translate-toolkit fonctionne sur ce principe...). Mais les auteurs de Pootle sont eux aussi très fiers de leur usine à gaz et considère que leur implémentation les satisfait (j'ai discuté avec eux sur leur liste dev et la conclusion ce n'était pas que leurs outils étaient incompatibles entre-eux, mais que OmegaT ne savait pas lire le PO...)

Cordialement,

Jean-Christophe







Reply to: