Comme vous le savez, le logiciel libre vit essentiellement de contributions, grandes ou petites. Et comme le code source est ce qui fabrique le logiciel, on a souvent tendance à penser que la contribution doit forcément passer par le code. Mais vous n'êtes pas dupes, et puis vous avez lu le titre de ce journal…
Je suis contributeur dans plusieurs projets : j'aide à créer une carte du monde avec openstreetmap. J'aide à rendre les emballages plus simples à lire avec openfoodfacts. J'aide à créer une liste complète des livres ayant jamais été publiés sur openlibrary. J'aide à rendre le logiciel libre plus facile à installer en contribuant des « recettes » de paquets et de services pour ma distribution favorite. Enfin, j'aide à rendre le logiciel plus simple à comprendre en le traduisant.
Vous avez remarqué ? Pas de code, ou en tout cas très peu.
Le sujet qui m'intéresse aujourd'hui, c'est la traduction. En effet, J'aimerais que le logiciel libre soit utilisé partout et par tout le monde. Mais pour certains ce n'est simplement pas une option : si on ne parle pas un mot d'anglais, comment utiliser un logiciel dans cette langue ? Comment utiliser un logiciel en français si son manuel est en anglais ? Si tous les tutoriaux sont en anglais ? Si tout le support n'est qu'en anglais ?
Bref, on a compris : c'est important d'avoir des logiciels dans la langue de ses utilisateurs. Et si on parle anglais, ça reste agréable d'avoir des interfaces dans sa langue maternelle. Je constate aussi que la régionalisation est une priorité de la FSF. C'est génial ! Mais en parle-t-on ? Je n'en ai pas l'impression. J'aimerais que la traduction soit un sujet plus visible, que les traducteurs se regroupent et communiquent entre eux, qu'une dynamique se crée.
Actuellement, on constate qu'il est possible de traduire beaucoup de logiciels, surtout les plus gros. Mais certains projets continuent d'être créés sans que leurs auteurs ne pensent à la régionalisation. C'est terrible, car cela donne plus de travail aux contributeurs (de code) ensuite. Si vous êtes créateur de logiciels libres, par pitié pensez à rendre vos chaînes traduisibles par exemple avec gettext. Lorsque le code de l'application peut être traduit, c'est son manuel ou sa documentation qui ne peut pas l'être. Vous me diriez, si ce n'est que ça, vas-y toi, traduit-le, le manuel. Sauf que voilà : une fois que vous avez traduit une version du manuel, une nouvelle version du logiciel sort, qui change une partie des fonctionnalités et on se retrouve avec des utilisateurs qui ne comprennent pas pourquoi ça marche pas. La traduction d'un logiciel comme d'un document ne se fait pas sans les développeurs. Il faut un moyen de savoir quand une partie de la traduction est devenue obsolète et pouvoir la corriger de manière ciblée. C'est d'autant plus simple quand cela est intégré au dépôt en amont. Si vous êtes vous-même traducteur de logiciels libres, j'aimerais beaucoup savoir ce que vous traduisez exactement (logiciel, documentation, tutoriaux, autre) et sur quels projets. Pour ma part, je travaille sur Linux from scratch, le projet de traduction de GNU, et certaines applications android : dns66 et stringlate.
Je voudrais aussi savoir quelles plates-formes sont utilisées pour vos traductions. En effet, chaque projet a tendance à choisir une plate-forme différente : certains n'en choisissent même pas, ce qui oblige le traducteur à connaître git, savoir ce qu'est une pull request et le faire. D'autres utilisent des plates-formes auto-hébergées (pootle ou weblate, essentiellement). D'autres encore utilisent des solutions non-libres toutes prêtes (transifex est l'exemple le plus connu). Certains utilisent des plates-formes ad hoc: le projet de traduction de gnu ou le site de traduction de weekly OSM par exemple. Cela coupe la communauté francophone en autant de petits groupes indépendants qui ne se connaissent pas. Et ce n'est pas évident pour un nouveau contributeur de savoir où trouver des projets qui ont besoin d'aide.
Enfin, je m'intéresse à la manière dont vous travaillez. Moi, je travaille avec un dictionnaire bilingue (et parfois uniquement en français), j'essaye de me servir des lexiques des projets (quand ils existent) et de la mémoire de traduction (quand ça veut bien marcher). Et vous ? Est-ce que cela correspond à vos besoins en tant que traducteur ?
# On va tester Zanata chez Framasoft
Posté par Framasky (site web personnel) . Évalué à 10.
J'ai mis en place Zanata chez Framasoft, sur https://trad.framasoft.org/zanata/, et on va essayer de tester ça.
Notre projet est de permettre à terme à tout un chacun de venir créer son projet de traduction dessus, mais comme pour Framagit en son temps, on va d'abord l'utiliser en interne, histoire de voir le workflow et d'être capable d'expliquer comment ça marche, de déminer le terrain. Parce que si on propose un truc qu'on ne maîtrise pas et qui n'est pas forcément le plus intuitif du monde, on va crouler sous les demandes de support.
Pour l'instant, j'y ai mis mes projets personnels (Lutim, Lufi, etc.) et on va importer les projets Framasoft au fur et à mesure du temps qu'on arrivera à y consacrer (c'est pas une top priorité).
Les inscriptions sont ouvertes par contre hein ! Vous pouvez déjà contribuer, vous ne pourrez juste pas, pour l'instant, y créer de nouveaux projets de traduction.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: On va tester Zanata chez Framasoft
Posté par Marotte ⛧ . Évalué à 4.
C’est un peu le B.A BA du métier, ça fait du bien de le rappeler :) On ne peut pas enseigner ce que l’on a pas soi-même appris, ça semble tomber sous le sens mais on l’oublie parfois pourtant !
[^] # Re: On va tester Zanata chez Framasoft
Posté par Glandos . Évalué à 4.
Intéressant. C'est supporté par RedHat je vois.
Et pourquoi Zanata ? Weblate et Pootle sont assez connus. Pootle a même assez bien participé, car il me semble que certaines bibliothèques créées pour lui ont été utilisé ailleurs. Mais peut-être que Zanata apporte quelque chose que je n'ai pas su voir ;)
[^] # Re: On va tester Zanata chez Framasoft
Posté par Framasky (site web personnel) . Évalué à 6.
En fait, comme à terme on veut ouvrir la plateforme a tout le monde, il faut un truc qui permette à tout à un chacun de créer un projet et de le gérer, ce que ne permet ni pootle, ni weblate, qui sont plutôt fait pour une équipe qui va gérer plusieurs projets (exemple, yunohost).
Framasoft a d'ailleurs payé un bugbounty pour ajouter ça à pootle. Le patch a été fait mais n'est toujours pas intégré upstream, et en plus il faut un accès au serveur pour déposer les fichiers à traduire, synchroniser la bdd depuis ces fichiers. Bref, pas du tout possible d'utiliser ça pour nos besoins.
Zanata par contre répond à tout ça.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: On va tester Zanata chez Framasoft
Posté par gnumdk (site web personnel) . Évalué à 3.
J'ai utilisé longtemps Zanata pour mes projets mais beaucoup de traducteurs m'ont demandé de passer à Weblate parce que Zanata n'est pas pratique à utiliser pour une utilisateur lambda. Et je peux le comprendre vu l'interface!
[^] # Re: On va tester Zanata chez Framasoft
Posté par Framasky (site web personnel) . Évalué à 2.
Si c'est pour tes projets à toi uniquement, effectivement, c'est pas le top, je l'avoue.
Après, bon déjà, on n'a pas trop le choix vu nos besoins (ouverture à tout le monde), mais surtout on prendra le temps de faire un guide d'utilisation pour aider les traducteurs, les accompagner, on va leur fournir du support, chose qu'on n'a généralement pas le temps de faire quand on fait ça pour ses projets persos.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Translate it bordel !
Posté par Marotte ⛧ . Évalué à 10. Dernière modification le 15 février 2018 à 23:20.
L’une de mes rares contributions au LL fût la traduction en français de LMMS, à ses débuts, j’ai abandonné par la suite. D’autres ont je pense pris le relais. J’ai suivi le projet depuis le début (ou presque), le principal développeur avait alors 18 ans, ça devait être vers 2005 donc, je crois que lui aussi a plus ou moins laissé les rênes à d’autres sur ce projet. LMMS est un excellent logiciel par ailleurs : il propose une autre vision pour le logiciel principal d’un DAW, différente de ce que peut faire Ardour, mais il est aussi complet et fourré de fonctionnalités, l’automation par exemple : elle marche proprement sur absolument tout ! :)
L.M.M.S signifie à l’origine “Linux Multi-Media Studio”, le côté multimédia n’a jamais existé et c’est devenu un incontournable de l’audio en LL (il est multi-plateforme, enfin au moins GNU/linux et Windows), mais le nom, pas terrible il faut bien l’avouer, est resté. Ça a paru une mauvaise idée de changer, à l’époque où l’idée de le faire (tant qu’il en était encore temps…) s’est fait sentir. Conclusion : choisissez un nom « qui claque » (qui claque comme une phrase choc…) dès le début de votre projet !
Pour en revenir à la traduction, LMMS utilise, je pense toujours, les possibilités offertes par Qt : Qt Linguist, donc côté traducteur, il faut avouer que c’est assez simple et intuitif de participer, à partir du moment où on parle la langue et, plus important encore, on connaît bien le domaine couvert. Reste, comme tu le soulignes, à « poule riquouester ». C’est une tâche qu’il est tout aussi facile de faire faire à un non-informaticien qu’utiliser Qt Linguist si c’est sur une forge type Gitlab. Une condition nécessaire et aussi qu’on lui montre, quand même, comment faire. Logiciel intuitif ne signifiant pas, comme certains décideurs pressés pourraient le croire, flairant un quick-win de forte belle nature, zéro besoin de formation… Je dirais même que faire le pull-request en lui-même est une tâche bien moins qualifiée que la traduction elle-même.
Pour ce qui est de mon dictionnaire FR-EN et EN-FR préféré il s’agit de Wordreference, le dictionnaire est bien fourni mais la grande valeur de ce site est l’activité sur les forums : La qualité des participations n’a rien à envier à celles de linuxfr.org (je pèse mes mots). Je sais que si j’ai la moindre question de traduction j’aurais une ou plusieurs réponses de qualité, si ma question est bien posée, bien-entendu.
Plus en vogue actuellement (j’y suis aussi mais je participe moins) il y a french.stackexchange.com et autres “Q&A” sites. Le principe est archi simple, il existe depuis longtemps mais c’est seulement depuis quelques années que la masse critique de gens (et l’état de l’art technique/technologiqe) est suffisante pour obtenir ce qui commence à ressembler à une source inépuisable, toujours à jour, de réponse à n’importe quelle question dans des temps record (!)… Il me semble que ce sont Stack Overflow, Server Fault et Super User qui furent les premiers Q&A connus (après Yahoo! Answer je dirais) (les noms parlent d’eux-mêmes quant au domaine concerné… oui : la flemme) mais la liste est maintenant plutôt longue, et je pense qu’il y a d’autres acteurs sur ce secteur. Après, comme pour Gitlab et n’importe quel crowdsourced bidule, sans centralisation ça paraît plus compliqué de faire démarrer et fonctionner le truc…
Et c’est le pavé /o\ … Heureusement que je n’ai pas à le traduire en anglais :)
# Chez Wikimedia …
Posté par Thomas Douillard . Évalué à 7.
Sommaire
Ça pourrait être un peu long parce qu’il y a pléthore d’outils, alors je vais me contenter d’un inventaire à la Prévert. On sent que c’est un projet fondamentalement international pour lequel les langues sont importantes, même si comme ailleurs bien des discussions se font en anglais. Voici un aperçu des outils que j’ai eu l’occasion d’utiliser :
Tanslatewiki.net
(que je découvre pour l’occasion n’est même pas géré par Wikimedia). Un wiki qui expose les chaîne de traduction de divers projets, dont Wikimedia et ses extensions. On peut proposer son propre projet en en parlant aux responsables de wiki. Gère d’autres projets d’envergure comme les logiciels OSM, apparemment.
Pour le traducteur, il se voit proposer une interface avec une pseudo page wiki à traduire pour chaque message, éventuellement avec une doc pour aider les suivants et contextualiser un peu (si vous avez tenté de traduire un logiciel, vous savez sûrement qu’un message isolé sans avoir connaissance de l’interface autour, on sait pas toujours bien ce qu’il est supposé vouloir dire). Relativement simple. L’interface utilise une extension Mediawiki dont on parle plus bas. L’aspect social est géré par les messages entre utlisateurs sur le wikis et les différents systèmes de notification, et de suivi des modifications habituels sur les wikis.
Pour le développeur, ça à l’air de fonctionner grâce aux fichiers .po et à la bonne volonté des responsables du wiki, donc peut possible de gérer plus ou moins d’autres formats en s’arrangeant avec eux : https://translatewiki.net/wiki/Translating:Localisation_for_developers
Extension « Translate »
L’extension Translate est une extension Mediawiki qui permet de gérer des wikis multilingues. En pratique une page wiki dans une langue peut être préparée pour être traduite grâce à des balises dans le code déterminant les parties à traduire. L’interface expose alors à un traducteur dans une langue la liste des parties d’article à traduire. Elle génère ensuite une version traduite de la page par langue.
Elle gère une éventuelle documentation des message à traduire et l’identification des message dans la page pour suivi grâce à des annotations automatiques du code wiki. C’est important parce que les pages wiki sont évolutives et éditées en permanence, tout peut être déplacé à l’envie. Elle possède des fonctionnalité de relecture et d’aide à la traduction : suggestions de traductions existantes de messages proches dans la base existante de traduction, et suggestion de traduction par des services de traduction automatique.
Elle gère aussi des listes de traductions de messages non associées à des pages wikis traditionnelles. Peut être des pages de fichiers « po » annotés dans le cas de « translatewiki.net », mais c’est pure spéculation de ma part.
Dans le cadre de l’utilisation aux quotidien sur un wiki, il faut compter sur la bonne volonté des éditeurs d’une page wiki qui peuvent ne pas apprécier des annotations du code induites, qui sont perçues comme compliquant l’édition. (note perso et certains vouent un tel culte de la « simplicité » du code que ça en confine au simplisme.)
Extension « Content Translation »
Outil pour le transfert d’article d’un projet linguistique à un autre, par exemple traduire un article de wp en français en arabe ou en anglais.
Fonctionne en divisant la page en titre / section / paragraphe qu’on peut sélectionner (ou pas) pour la traduction. Propose pas mal d’aides comme la traduction des liens de site, il s’agit de trouver automatiquement l’article équivalent (ou la catégorie) équivalente dans le wiki cible, l’expansion des modèles (les modèles du wiki source sont pas forcément dispo sur le wiki cible, ou sont incompatibles). Propose pour certaines paires de langues des traductions automatiques. Fonctionne avec une version « visuelle » des parties à traduire et du formatage wysiwig.
C’est assez sympathique et utile, mais ça souffre de pas mal de bugs qui font que la sortie de l’outil doive de mon expérience forcément être revue après traduction (perte des formules mathématiques, difficulté de gérer le formatage avec l’interface au moment de la traduction.) Défauts de jeunesses mais qui perdurent, les équipent qui développent ayant d’autres projets et priorités. J’ai subis des gros bugs comme l’impossibilité de recharger une traduction en cours (qui traînait un peu) après quelque semaine quand l’article original est modifié, tout perdu. La traduction est toujours en cours mais du coup j’ai suivi une stratégie différente, exporter un semblant de traduction depuis l’outil de traduction dans une page wiki très tôt dans le processus traduction vers une page normale de mon espace utilisateur, que je modifie comme n’importe quelle page.
Tooltranslate: les outils web de l’univers Wikipedia
Des serveurs hébergent des interfaces web qui fournissent des service divers et variés pour visualiser / modifier / faire des requêtes sur les outils Wikimedia, par exemple https://tools.wmflabs.org/reasonator/ opur visauliser Wikidata ou https://petscan.wmflabs.org/ pour récupérer des tas d’articles et leur élément Wikidata en fonction de tout un tas de critères et des éditions en masse.
Ces outils disposent de tooltranslate, qui vise manifestement l’efficacité et l’ouverture. On clique sur « traduire », on choisit sa langue et on traduit. Il semble possible d’ajouter ses propres outils à l’envie sans demander à personne. Il suffit d’avoir un compte Mediawiki pour traduire, l’identification est gérée par Wikimedia.
Ressources linguistiques inter-langues libres :
Il y a bien évidemment le wiktionnaire, qui donne des définitions de pleins de termes dans plein de langue, avec le projet en cours de wiktionnaire structuré, c’est à dire d’utiliser des structures de données informatiques pour stocker les synonymes, antonymes … des termes dans les différentes langues, les relier à l’élément Wikidata correspondant à leurs différentes définitions. Il y a des projets de https://en.wiktionary.org/wiki/Wiktionary:Thesaurus . Wikidata fournit un point de vue inverse : pour un concept donné, on peut retrouver un « intitulé » (terme) (et les pages wikipédia le décrivant) le désignant dans toutes les langues. C’est ce qui permet à l’outil de traduction d’article de transposer les liens, même si c’est pas abouti.
En conclusion :
J’ai un peu débordé du cadre, mais le potentiel de Wikimedia en terme d’ingénierie du langage est tel que c’est bien tentant. On pourrait rire au nez et douter du succès de n’importe quel autre projet avec ce genre d’ambition, mais dans le cas de Wikimedia ça semble juste naturel. La fondation a une équipe de développement dédiée
[^] # Re: Chez Wikimedia …
Posté par roptat . Évalué à 1.
Oh, incroyable ! Voilà encore plein de liens que je ne connaissais pas. Et j'adore l'idée d'utiliser le wiktionnaire comme un glossaire (et plus avec synonymes et antonymes). Justement l'un des points que je reproche aux différentes plate-formes, c'est d'être fermées sur elles-mêmes. Pas moyen de partager automatiquement les glossaires ou les traductions alors que ça serait bien pratique. Par exemple pour OSM, on peut imaginer que diverses applications qui font GPS vont avoir la chaîne « tournez à gauche » ou encore « restaurant végétarien ». Ça ce sont des termes faciles, mais quand on commence à creuser, on a des trucs assez difficiles à traduire et il faut faire attention à ce que ça soit traduit partout pareil, sinon on ne s'y retrouve plus.
Alors oui, les plate-formes permettent d'exporter et importer les glossaires à la main, mais c'est pénible et on ne sait jamais si c'est à jour entre les projets.
# Localization
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
La traduction, c'est bien, mais c'est pas tout. Tu dois plutôt faire la "localization" de ton logiciel, pour prendre en compte les dates, comment trier les données, choisir les bon symboles, etc.
Sinon, ben, j'utilise pas d'outils de traduction… Je les crée :)
Pour info, généralement, les gens utilisent de la "traduction machine avec post édition". En gros, tu files ton texte à un logiciel, puis tu envoies l'original et la traduction à un relecteur professionel qui corrige. C'est moins cher, plus rapide, et ça te permet aussi d'améliorer ton système de traduction. Et tu utilises souvent des traducteurs (même logiciels) et relecteurs spécialisés pour un domaine (eg, légal, médical, informatique, etc).
[^] # Re: Localization
Posté par roptat . Évalué à 2.
Salut !
merci pour le commentaire. En effet, la localisation (régionalisation ?), c'est ce que j'appelais la traduction : je fais attention à bien traduire les dates, unités, et à utiliser des exemples plus parlant : par exemple, quand en anglais on a « lancez “export LANG=en_US.UTF-8” », je remplace par fr_FR.UTF-8.
Par contre, je trouve que la « traduction machine avec post édition » est compliqué. Ça marche bien assez souvent, mais parfois ça donne des tournures bizarres ou peu satisfaisantes et je me retrouve bloqué à pas savoir quoi faire parce que la proposition éclipse tout ce que j'aurais pu trouver par moi-même. Par contre j'utilise de la traduction automatique pour les trucs vraiment répétitifs (mais sans relecture du coup). Ensuite il faut trouver des relecteurs et j'ai l'impression que c'est encore plus rare que les traducteurs :)
Tu parles de traducteurs et relecteurs spécialisés, est-ce que tu penses à quelque chose en particulier ?
[^] # Re: Localization
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
J'ai des amis qui sont traducteurs dans le jeu-vidéo, et je ne leur donnerais pas à traduire ni à relire un document légal. Inversement, je ne donnerais pas un document sur le jeu vidéo à un interprète de l'ONU.
C'est pareil pour la traduction automatique. Nos systèmes sont spécialisés pour les besoins du client. On les entraine avec des données pertinentes en fonction de leurs besoins. C'est en partie pour ça que, par exemple, Google Translate n'est pas top: c'est un système générique. Ça fait un peu de tout, mais pas grand chose de bien. Mais les boîtes de traduction automatique, leur business, c'est la traduction spécialisée pour le client.
[^] # Re: Localization
Posté par Chuck #1 . Évalué à 1.
Il m'est arrivé de recevoir la traduction d'une décision de justice pour laquelle la conclusion, l'argumentation et les demandes avaient un sens exactement opposé à celui de la décision originale ! La traduction avait été commandée par le tribunal à un traducteur assermenté.
J'ai d'abord pensé à l'utilisation d'un logiciel de traduction automatique sans relecture. La traduction donnée par Google était quand même meilleure que celle du traducteur assermenté (pour la compréhension, pas pour la grammaire). Un peu plus tard, j'ai lu un article qui citait de nombreux cas dans des affaires de demandes d'asile traitées par le même tribunal donc il est possible que les contre-sens soient intentionnels.
Cette signature est publiée sous licence WTFPL
[^] # Re: Localization
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 16 février 2018 à 20:03.
J’ai vraiment du mal à concevoir que ça puisse être moins fastidieux de relire et corriger une traduction plutôt que de la faire directement…
Traduction : je traduis
Relecture : je traduis, je compare ma traduction avec la traduction donnée
[^] # Re: Localization
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Tu n'as pas à chercher les mots, et si la traduction est bonne, tu n'as rien à écrire. Souvent, la traduction a des fautes mineures comme des fautes d'accords ou quelques mots mal placés. Au final, ça vaut vraiment le coup.
Traduire, c'est pas aussi rapide…
Aussi, dans pas mal de domaines, les traductions sont souvent faites à l'échelle de la phrase, et non du document, donc elles sont indépendantes. Ça demande donc un effort minimal. Je n'ai pas de chiffres à donner en public, mais ça vaut le coup.
[^] # Re: Localization
Posté par Marotte ⛧ . Évalué à 3.
OK. Merci pour ta réponse, je vois un peu mieux l’avantage.
# Quels outils ?
Posté par JN . Évalué à 3.
Pour les logiciels, on utilise les outils proposés par le quadriciel d'internationalisation, mais pour le texte, comment vous-y prenez-vous ? Comment suivre les évolutions du texte par la suite ?
Par exemple, la doc de Git est écrite en asciidoc : à part po4a, il n'y a pas grand'chose qui puisse faire le boulot de gérer les évolutions en encore, ce n'est pas mirobolant (les saveurs d'asciidoc trompent quelque fois l'extraction des textes).
Je serais curieux de connaitre les outils/méthodes utilisées par ailleurs…
[^] # Re: Quels outils ?
Posté par roptat . Évalué à 2.
Pour LFS, on utilise po4a, ça marche plutôt bien. J'ai un script qui tourne chaque nuit pour récupérer les derniers changements et les proposer sur notre instance pootle. Ce qui est dommage, c'est que ça fait une instance en plus (donc encore un compte) et pour l'instant ça n'est utilisé que pour le français.
Je suis aussi curieux de savoir s'il y a d'autres outils, et s'il y a des exemples d'intégration dans le dépôt amont, ou si c'est tout le temps géré à part comme pour LFS.
[^] # Re: Quels outils ?
Posté par Ericounet . Évalué à 1.
Bonjour,
je n'ai pas vu cité: omegaT.
Je l'avais testé il y a quelques années. Logiciel libre bien sûr.
La prise en main prend du temps.
[^] # Re: Quels outils ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Pour Haiku, on utilise:
Je précise que nous avons aussi choisi de ne pas utiliser gettext, nos traductions sont basées sur le support fourni par ICU qui donne pas mal de contrôle au traducteur pour le format des messages, et permet notamment une gestion correcte du pluriel dans toutes les langues (certaines ont des règles complexes ou inhabituelles).
Une conséquence est l'utilisation de notre propre format de fichier pour les traductions. Ce format a été intégré dans Pootle mais à ma connaissance pas dans les autres outils. Nous avons aussi une application native pour traduire ces fichiers, mais l'utilisation d'un outil en ligne et collaboratif est finalement plus conviviale.
Nous avons aussi un ensemble de documents destinés aux traducteurs afin d'aider la coordination, le choix d'un vocabulaire commun, etc: https://dev.haiku-os.org/wiki/i18n
[^] # Re: Quels outils ?
Posté par roptat . Évalué à 2.
Merci pour les liens ! Ces trois outils sont tous en ligne, pour le traducteur, n'est-ce pas ? Comment fait le programmeur pour générer les fichiers à traduire, et sous quel format, du coup ?
Pourquoi avoir choisi des outils maison, plutôt que des outils existants ? Typiquement, j'ai l'impression que tout pourrait se trouver sur pootle, non ? Et je voudrais pas dire, mais votre version de pootle est un peu ancienne :p
La deuxième question, c'est pourquoi le format fournit par ICU. Je ne connais pas ce format, donc je me demande quelle différence il y a entre ça et gettext ?
[^] # Re: Quels outils ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Pour la génération des fichiers de traduction, ce sont également des outils développés par Haiku. Il s'aggit de collectcatkeys qui va parser des sources C++ à la recherche d'appels à une famille de macros (B_TRANSLATE) et extraire les chaînes de caractères passées en paramètre.
Pour chaque appel à la macro on peut avoir:
- La chaîne à traduire
- Un "contexte" (qui permet d'avoir la même chaîne avec des traductions différentes, par exemple quand un nom et un verbe sont homonymes en anglais mais pas dans les traductions)
- Un commentaire (qui est là pour informer les traducteurs)
Ces trois informations sont affichées par l'outil de traduction.
Le résultat est un fichier "catkeys" qui contient simplement ces entrées, une par ligne, avec les 3 infos séparées par des tabulations (les chaînes elle-mêmes sont stockées avec les caractères spéciaux échappés comme en C, donc s'il y a une tabulation ou un retour à la ligne dans la chaîne à traduire, il est remplacé par un \t ou un \n).
Ensuite on convertit les fichiers traduits dans un format binaire qui permet un accès plus rapide aux traductions.
Pour les outils de traduction, il y a d'abord eu un premier outil maison (c'était vers 2009 ou 2010), avant le passage à Pootle. Pootle fonctionne bien pour le système, mais nous n'avons pas réussi à y intégrer des applications tierces sous forme de projets indépendants. Pour la version ancienne, c'est en cours de migration!
Un problème de Pootle est qu'il est écrit en Python (si je me souviens bien) et donc en héberger une instance nécessite un serveur qui permet de faire des pages en Python. Ce n'est pas un problème pour le projet Haiku, mais ça l'est pour plusieurs projets de petites applications qui sont hébergées juste sous forme d'un projet github. Et là on a un développeur qui a eu envie de se faire la main sur le développement d'application web, je crois :)
Pour le format d'ICU, je ne sais pas si je peux répondre car je connaît assez mal celui utilisé par gettext. Il y a quelques exemples ici:
http://userguide.icu-project.org/formatparse/messages
En gros, le format est presque un langage de script qui permet au traducteur d'exprimer tout un tas de conditions sur les données à formater. On l'utilise principalement pour gérer correctement le nombre (singulier/pluriel en français, mais c'est plus compliqué dans d'autres langues, comme on peut le voir dans la base de données CLDR.
Comment ça se passe avec gettext pour gérer ce genre de problèmes?
# Mon expérience sur Rolisteam
Posté par Renaud Guezennec (site web personnel) . Évalué à 2. Dernière modification le 19 février 2018 à 14:10.
C'est un projet en Qt donc j'utilise les outils de Qt pour le faire:
Linguist est assez pratique mais cela demande une implication du traducteur assez importante.
Il faut installer Linguist, récupérer les fichiers ts, le traduire, envoyer la traduction à l'équipe de dev pour intégration etc..
Ce n'est pas très pratique.
Pour faciliter le travail, j'ai choisi Transifex (le mal pour beaucoup mais j'ai le sentiment d'aider la Grèce).
1/ Il y a beaucoup de logiciels libres utilisateurs de la plateforme.
2/ l'alternative de framasoft n'était pas encore prête. Je suis l'actualité à ce propos de loin.
Le support des fichiers ts sur Transifex est suffisant mais pas encore idéal.
Je m'occupe personnellement du français et de l'anglais.
C'est relativement facile d'ajouter une langue et de traduire le soft.
Rolisteam est traduit en français, anglais, allemand, hongrois, roumain, espagnol, portugais, néerlandais et turc.
Pour mon planning, j'essaie de sortir une version majeure par an (environ). Quand le soft est prêt mais pas les traductions cela retarde beaucoup la sortie du logiciel.
J'essaie de communiquer avec les traducteurs mais tous n'ont pas le temps et tous ne répondent pas.
Je comprends tout à fait qu'ils ne souhaitent plus participer ou qu'ils n'aient plus le temps.
Je laisse du temps aux traducteurs puis si rien ne bouge, ben tant pis.
Après j'ai commencé à écrire du code optimisé pour la traduction. Recycler les chaînes de caractères, utilisés des symboles mathématiques (un + pour Ajouter…), quelques combines de-ci de-là.
Bref, ce n'est pas merveilleux, mais cela tourne bien quand même.
Le problème se situe dans la traduction du manuel.
J'ai actuellement un manuel rédigé dans un wiki (wikimedia).
Je n'ai pas vraiment (pris) le temps de devenir expert de wikimedia.
C'est compliqué de faire le tri entre les solutions mise en place pour wikipédia et celle accessible pour les utilisateurs de wikimedia. Je parle d'une installation en 2011 par là.
J'ai eu trés rapidement des spams dans tous les sens sur le wiki. J'ai coupé les inscriptions. Cela ne laisse que peut de possibilité pour traduire la documentation.
Puis il est compliqué pour moi d'avoir un suivi des versions propres de la documentation. Je suis obligé de faire des pages parallèles.
Une part non négligeable des mes utilisateurs utilisent encore des vieilles versions.
Bref, la solution n'est pas utilisable dans les faits.
Du coup, j'ai entamé une réécriture du manuel en markdown avec pelican (générateur de site statique).
Je pourrais le versionner avec git et même proposer des consultations hors ligne. (Je dis pas que c'était pas possible avec wikimedia, juste que je sais pas comment faire). Avec pélican, c'est facile, je génère, et je créé une archive).
J'ai profité de cette étape pour décrire comment participer à la traduction du manuel et du soft en utilisant github.
La nouvelle documentation sera mise en ligne pour la prochaine version majeure.
Après je chercherais un moyen de mettre sur plateforme web (transifex et autre) la documentation.
Rien n'est facile.
Peut-être qu'un capitaine connaît l'outil idéal, la merveille, la bête de course pour gérer une documentation en traduction et en version.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.