Journal Traduction des logiciels libres

Posté par  . Licence CC By‑SA.
Étiquettes :
16
16
mai
2016

Je ne sais pas si les traductions de texte sont encore au programme dans les écoles mais ce serait intéressant de demander aux développeurs de chaque logiciel libre quelle méthode est utilisée pour traduire le logiciel libre (via un site web, avec https://poedit.net etc.) puis de demander aux enseignants de préparer des séances de traduction de logiciels libres éducatifs par exemple.
Au moins, ce serait des traductions utiles, qui rendraient utilisables les logiciels libres éducatifs non traduits et qui impliquerait plusieurs enseignants (anglais + français + informatique).

  • # Des exemples

    Posté par  . Évalué à 5. Dernière modification le 16 mai 2016 à 12:10.

    Si quelqu'un a un témoignage d'une expérience de ce type…

  • # What !!!

    Posté par  (site web personnel) . Évalué à 10.

    Vous parlez de faire travailler GRATUITEMENT des étudiants afin de rendre accessible des logiciels LIBRES a encore plus de gens (sûrement pauvre en plus) ? Sachez que ce n'est pas du tout "Croissance/Emploi free" avec des raisonnements tels que celui-ci vous risquez de vous faire confisquer votre matériel informatique et de vous ficher comme activiste extrêmement dangereux par les patrons du CAC40 les politiques.
    Si vous faites de la moto attention aux camions !

    kentoc'h mervel eget bezan saotred

  • # Pas adapté et pas très utile

    Posté par  . Évalué à 10.

    Ça paraît être une bonne idée à première vue mais en réalité, les traductions de logiciels sont assez peu adapté à un exercice de traduction. Il y a pas mal de termes techniques et beaucoup de répétitions. Le choix actuel d'utiliser de la littérature me semble plus adapté. Et c'est utile aussi pour les élèves puisque ça peut leur permettre de découvrir un extrait d'une œuvre qu'ils ne connaissaient pas auparavant.

    L'autre aspect, c'est que, dans tous les projets libres que j'ai vu, le français n'est pas le problème. Très souvent, quand j'essaie de participer à une traduction, je vois que le français est déjà terminé.

    • [^] # Re: Pas adapté et pas très utile

      Posté par  . Évalué à 9.

      Sans compter qu'il y a un gros problème en général : la perte de contexte. Quand tu traduis, tu ne vois pas souvent le message dans son environnement naturel et du coup t'es un peu obligé de lancer le logiciel/lire le code pour comprendre de quoi il s'agit dans certains cas. Ou de connaître le logiciel par coeur, mais c'est rarement le cas.

      Ça donne souvent des traductions un peu wtf en contexte qu'il faut décrypter.

    • [^] # Re: Pas adapté et pas très utile

      Posté par  . Évalué à 6.

      Entièrement d'accord. Cependant, un point qui peut être traduit plus facilement dans ce cadre, c'est la documentation du logiciel (bon, il faut qu'il y en ai une correcte en anglais, mais ça arrive :)). C'est plus rarement traduit et se prête mieux à l'exercice de traduction.

      Cependant, le problème que je vois à cela, est l'existence de traduction précédentes qui peuvent, selon les cas, faciliter un peu trop le travail de l'étudiant qui n'aura plus grand chose à faire.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Pas adapté et pas très utile

        Posté par  . Évalué à 3.

        Sauf que je ne vois pas comment traduire la doc sans avoir le logiciel déja traduit. Tu ne peux pas dire dans la doc "cliquez sur Affichage -> Résolution" alors que le logiciel indique "Vue -> Niveau de zoom".

        Il ne faut pas non plus traduire les termes techniques (plug-in), il faut faire beaucoup de calques de l'anglais pour qu'on puisse comprendre, etc. Bref, on est loin d'un travail de traduction littéraire.

        Évidemment, on peut critiquer le choix de l'éducation nationale de privilégier l'enseignement de l'anglais britannique littéraire quand les besoins principaux concernent l'anglais US technique ou conversationnel, mais bon, c'est comme ça. Du coup, si tu veux te retrouver avec des trucs comme "veuillez cliqueter sur le pannonceau amovible" à la place de "cliquer sur le menu contextuel", c'est un choix…

        Sur le fond, honnêtement, je trouve que la grande majorité des logiciels gagnent à ne pas être traduits. Évidemment, on peut traduire les navigateurs, les traitements de texte, les jeux, et les logiciels de média, mais pour le reste… Traduire Latex, gcc, ou ghostscript, quel intérêt? Savoir utiliser ces logiciels demande 10 fois plus d'investissement que pour comprendre l'anglais technique de leur doc. J'ai toujours trouvé assez étonnant que pour un grand débutant (par exemple, un retraité qui n'a jamais utilisé d'ordinateur au cours de sa vie active), l'anglais n'était pas un problème majeur. Le français informatique, c'est du chinois! "Imprimer dans un pdf" ou "Print to pdf", quand on ne sait pas ce que ça fait, ça n'est pas plus clair en français qu'en anglais. Et quand ils ont compris ce que ça faisait, bah ils disent "Print" prononcé comme "pinte", et ils s'en foutent, parce que ça imprime et qu'ils ne sont pas cons au point de ne pas comprendre que ça veut dire "imprimer" en anglais.

        Parfois, la nature humaine m'apparait impénétrable, et celle des geeks encore plus. Je veux dire, il y a déja eu un mec qui s'est dit "ah ouais, je vais traduire «segmentation fault» par «erreur de segmentation», ça va être plus clair pour l'utilisateur"!!

        • [^] # Re: Pas adapté et pas très utile

          Posté par  . Évalué à 4.

          Sauf que je ne vois pas comment traduire la doc sans avoir le logiciel déja traduit

          L'autre aspect, c'est que, dans tous les projets libres que j'ai vu, le français n'est pas le problème. Très souvent, quand j'essaie de participer à une traduction, je vois que le français est déjà terminé.

          Bref, on est loin d'un travail de traduction littéraire.

          C'est vrai, mais j'ai eu à faire des traduction techniques durant mon cursus.

          Le français informatique, c'est du chinois! "Imprimer dans un pdf" ou "Print to pdf", quand on ne sait pas ce que ça fait, ça n'est pas plus clair en français qu'en anglais.

          D'où l'intérêt d'avoir une doc bien faite et traduite (même si elle indique des menus en anglais) par rapport à traduire le logiciel. Et dans ta liste, avoir une doc bien traduite pour LaTeX peut être très intéressant.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Pas adapté et pas très utile

          Posté par  (site web personnel) . Évalué à 2.

          Il ne faut pas non plus traduire les termes techniques (plug-in),

          Ah non ? C'est interdit ? Quid de courriel, logiciel, ou ordinateur ?
          T'aimes pas les plugiciels ?

  • # Le point de vue d'un développeur

    Posté par  (site web personnel) . Évalué à 5.

    Il y a trois problématiques : le langage de programmation, la localisation unique/multiple et la traduction proprement dite.

    1. Le langage de programmation
      Aujourd'hui, grosso modo, il y a deux grandes familles de langage : le langage C avec ses multiples dérivés et les langages de script comme Python. Ces langages ont, au fil des ans, développés des procédures de traduction. L'une des plus connue est gettext.

    2. La localisation unique/multiple
      Par localisation je mets dans le même sac (par simplification) la traduction pure, les variantes linguistiques et les contraintes politiques locales (mots interdits par le politiquement correct). Quand on développe un projet, surtout si l'on n'est pas anglophone, la question de la traduction de son œuvre se pose assez tôt. il y a deux voies : traduire le code source avant compilation (ce que fait gettext) ou bien intégrer toutes les traductions dans le logiciel avant sa compilation. Dans le dernier cas, la variable d'environnement (LANG, par exemple) détecte la localisation à appliquer au moment où l'utilisateur lance le logiciel.

    3. L’œuvre de traduction
      Si l'on est dans le cas de gettext, effectivement, la chose est plus facile car cet outil permet d'opérer sans grande connaissance de la programmation. Dans les autres cas, c'est beaucoup moins limpide. Et encore moins quand on touche à des langages moins main stream (comme mon projet fBlog qui est en Fortran). Reste que la traduction d'un logiciel n'est pas strictement une tâche littéraire ! En effet, une traduction mot à mot n'est pas toujours possible même dans le cas le plus simple de celle des menus de navigation à l'intérieur du logiciel. Même si les mots comme "Edit", "File", "Save"… ont leur équivalents bien connus, il y aura toujours des options de navigation qui seront nouvelles. Et c'est là où un spécialiste de la langue atteindra ses limites. De ce qui précède, une traduction suppose non seulement d'être linguiste mais aussi d'avoir une pratique réelle du logiciel que l'on veut traduire. Et si l'on ne dispose pas d'outils comme gettext, il faut être capable de se plonger dans le code source. Enfin un dialogue avec l'auteur du logiciel finira par devenir indispensable car il y aura la nécessité de synchroniser sa traduction avec les mises à jour du logiciel pour les intégrer dans son paquet. La connaissance d'une langue véhiculaire (le plus souvent l'anglais) et l'aptitude à communiquer directement (mail, par exemple) ou indirectement (push par GitHub…) est souhaitable. Il y a aussi la question du copyright des traducteurs ce qui est chose délicate dans le cas d'une traduction initiée par une structure publique au sein d'un collectif.

    • [^] # Re: Le point de vue d'un développeur

      Posté par  (site web personnel) . Évalué à 2.

      Aujourd'hui, grosso modo, il y a deux grandes familles de langage : le langage C avec ses multiples dérivés et les langages de script comme Python. Ces langages ont, au fil des ans, développés des procédures de traduction. L'une des plus connue est gettext.

      Je supplie tout le monde de ne pas faire cette classification "langages de script". Après on se retrouve avec des gens qui pensent que le "script" (python, ruby, …) ne sert qu'à initialiser des vrais programmes (En Java / C / C++)… Je l'ai déjà vécu en école d’ingénieur et cela fait mal de se prendre une sale note parce "qu'un script n'est pas un programme professionnel".

      D'autant que dans le contexte que tu donnes, la différence entre python et C d'un point de vu gettext est minimum…

      • [^] # Re: Le point de vue d'un développeur

        Posté par  (site web personnel) . Évalué à 1.

        Les langages compilés tournent tous (pour Linux) sous l'interpréteur ELF. Cet interpréteur, du point de vue du cycle de vie d'un logiciel, est éternel. Les langages de script ont chacun leur propre interpréteur et, presque toujours, le font évoluer. L'espérance de vie d'un logiciel sous langage de script est de l'ordre de quelques années.

        Il en ressort que dans le cas d'un langage compilé, une seule branche sur le repository suffit à sa seule maintenance contrairement au langage de script qui doit être maintenu dans l'ancienne version de l'interpréteur, celle en cours et celle à venir. Donc 3 branches au lieu d'une.

        Le point de vue du développeur est que si se voir proposer des traductions lui fait chaud au cœur, voir lesdites traductions ne pas être actualisées lors des mises à jour de son logiciel peut lui poser d'énormes problèmes. Et c'est typiquement la situation de l'auteur de ce journal qui tend à promouvoir une action ponctuelle alors que l’œuvre de traduction nécessite un accompagnement sur des années.

        • [^] # Re: Le point de vue d'un développeur

          Posté par  (site web personnel) . Évalué à 7.

          Pour le débat sur la traduction ponctuelle versus accompagnement longue durée, je suis tout à fait d'accord avec toi. Le monde de l'informatique est rempli de projet prometteur non maintenus.

          Concernant ta vision de la différence entre langage de script et langage compilé je ne suis absolument pas d'accord avec toi pour plusieurs raisons.

          En premier lieu, il n'y a pas que ELF dans la liste de dépendances d'un programme compilé, il y a une tonne de librairies qui peuvent changer d'ABI ou d'API et il y a aussi le compilateur et les librairies standards qui évoluent. Dernièrement, le passage à c++11 a cassé beaucoup de code. La librairie standard C++ a évoluée de façon non compatible avec l'existant. Pas plus tard que ce matin, j'ai fais évoluer la toolchain de notre entreprise de gcc 5 à gcc 6 et de clang 3.7 à clang 3.8 et j'ai réalisé une trentaine de commit lors de ce changement. Trois étaient nécessaires pour que cela compile !

          Tu fais la différence entre langages compilés et langages de script avec un interpréteur, mais il existent de nombreux langages compilés qui ont un interpréteur (ou une VM, un runtime), comme Java, ou haskell, … La pluspart des langages "de script" que je connais sont compilées d'une manière où d'une autre. Python est compilé en byte-code intermédiaire pour sa VM mais il existe des projets de génération de code natif. Il existe des interpréteurs pour le C… Bref, la définition de langage de script est plus que floue.

          Il en ressort que dans le cas d'un langage compilé, une seule branche sur le repository suffit à sa seule maintenance contrairement au langage de script qui doit être maintenu dans l'ancienne version de l'interpréteur, celle en cours et celle à venir. Donc 3 branches au lieu d'une.

          Actuellement il est "simple" de garantir une unique base de code pour des technologies comme python, ruby, haskell, … qui fournissent des gestionnaire de dépendances dans lequels tu peux spécifier la version de l'intepreteur à utiliser ainsi que la version spécifique de toutes les dépendances. Tu es presque garantie que cela compilera / s'executera à l'identique. Et souvent tu n'as qu'une seul projet d'intepreteur à supporter.

          D'un autre coté, en C++ par exemple, le roi des langages "compilé", il n'y a aucun consensus sur un outil de dependence / packaging / déploiement qui te donne les même garanties, il existe au moins 4 compilateurs différents que tu dois supporter (gcc / clang / visual studio / Intel cc) et des spécificité de programmation sur chaque système et des versions de compilateur différentes. Et crois moi (Je maintient une base de code C++ de plusieurs centaines de milliers de ligne qui tourne sur les 3 OS majeurs et sur plusieurs architecture matériel et sur les 4 compilateurs), on gère cela avec des directives de précompilation et c'est un enfer. Une des meilleure solution à l'heure actuelle c'est de distribuer ton logiciel dans une machine virtuelle, ou un conteneur léger (comme docker), mais ce n'est pas applicable à tous les projets.

          Donc ma conclusion c'est que j'aimerais que on arrête de catégoriser certains outils dans ce groupe magique des "langages de script" qui est très péjoratif et souvent sur des arguments qui ne tiennent pas.

          Petite histoire vraie vécue dans ma vraie vie de développeur. Etant à la R&D d'une boite, j'ai écris en python un prototype d'un outil. La solution a rapidement été validée et s'est posé la question de la mise en production du produit. Il fallait donc passer du prototype (100 lignes de python dans un seul fichier, pas de dépendance autre que l’interpréteur, portable sous linux / windows / mac OS) à la "vraie vie". Un ingénieur talentueux a donc réalisé le portage du langage de "script" en C++, parce que ce serait clairement plus rapide et plus robuste (compilé versus langage de script, y a pas photo non ?!). Quelques jour / homme plus tard, il revenait avec une version (quelques milliers de ligne de C++, qui ne marchait que dans visual studio, pas portable et avec 5 librairies en dépendance) et surtout un GROS problème. Quand ma version en python tournait en 2s, la sienne prenait 10 minutes. Impossible ! Bon, alors en fait, il avait utilisé un algo en O(N2) au lieu du mien qui était en O(N) pour la raison simple qu'il pensait que le C++ irait de toute manière plus vite. Une nouvelle dépendence plus tard (Pour avoir une hash map en C++ car il n'y en avait pas dans la standard libraire à cette époque, on aurait pu utiliser un std::set), son programme tournait en 3s… Toujours plus lent. Damned… Après profiling, c'était un problème d'allocation mémoire parce que l’algorithme créait énormément d'objet. Après avoir changé d'allocateur (à l'époque le gars a écrit un allocateur maison, mais bon, on aurait pu prendre un projet existant, je ne sais juste pas ce qui existait de bien à l'époque), le temps est passé à 2s. Pas plus rapide que la version python… Drame… En fait le temps était passé en entrée sortie avec le disque, donc il serait pas aller plus vite quoi qu'il arrive… Plus tard beaucoup de temps on été investis pour réaliser le portage de ce programme sous linux et sous mac os X et pour corriger les bugs dans l'allocateur custom. Encore plus tard, il a fallu corriger de nombreux problèmes liés à la portabilité sur différents compilateurs. Et pendant ce temps là la version python marchait toujours car elle servait de test de non régression ;)

          Alors oui, ce cas est extrême, mais c'est l’exemple même de la peur des langages de "scripts". On peut reprocher beaucoup de choses à tous ces langages qui ne sont pas tout roses (python 3 ;), mais de là à dire que du code "compilé" à une meilleure durée de vie… Cela n'a rien à voir ;)

          • [^] # Re: Le point de vue d'un développeur

            Posté par  (site web personnel) . Évalué à 1.

            Ma réponse était délibérément concise et, de ce fait, caricaturale. Je sais que tout n'est pas rose dans la pérennité d'un logiciel compilé ; j'en ai fait l'expérience dernièrement.

            Sinon, je suis à 100% d'accord avec toi sur tout ce que tu dis ! Je suis sous Gentoo, je compile tout, et les changements de version de lib et de compilo je me les prends dans la figure tous les jours.. Et je sais aussi que bien des langages compilés tournent (ou ont tourné) sous interpréteur. D'ailleurs la norme Fortran se refuse à prononcer le mot compiler au profit de processor (Fortran a été interprété jadis).

            Ma petite expérience de traduction repose essentiellement comme l'un des traducteurs du moteur de blog NanoBlogger qui est en Bash puis sur mon propre moteur de blog qui est en Fortran. Ayant vu la galère du maintien du code avec les différentes versions de Bash sur plusieurs plateformes (Mac, BSD, Linux…) j'ai bien été échaudé. Fortran, pour moi, apportait une plus grande stabilité. Quant à la préférence de tel ou tel langage, dans le monde actuel, que ce soit avec GNU ou Intel (pour C/C** vs Fortran) on est dans la traduction d'un langage normalisé vers un langage intermédiaire (non normalisé) qui génèrera ensuite de l'assembleur. Puis il y aura une édition de lien ; même ayant codé en Fortran, on se retrouve avec une libc intégré à l'exécutable…

            J'ai l'avantage de la décontraction sur tous ces sujets alors qu'ils mettent gravement en jeu des vies professionnelles entières : je suis retraité et pur autodidacte en informatique. (Autant dire, un hobbyiste…) Et je suis navré de l'influence des modes, du dogmatisme des cursus de formation en informatique et de l'oubli des vielles technos faute de l'enseignement d'une Histoire de l'informatique qui aurait l'avantage de relativiser ces passions.

  • # Le point de vue d'un traducteur

    Posté par  . Évalué à 3.

    Je me vois mal proposer de contribuer à la traduction de LibreOffice comme exercice d’apprentissage de la langue anglaise.
    Dans LibreOffice nous avons plusieurs domaines où interviennent des traducteurs :
    – l’interface graphique du logiciel ;
    – l’aide en ligne ;
    – la documentation.

    La traduction de l’interface graphique et celle de l’aide sont faites en utilisant Pootle. La traduction de l’interface ne ressemble pas à la traduction d’un texte, il y a en fait très peu de vrai texte dans une interface graphique. En pratique on ne traduit que des mots et des fragments de phrases dont il faut retrouver le contexte quand le sens n’est pas immédiat.
    L’aide contient de vrais petits textes mais pas seulement, par exemple aussi du code de mise en forme ou d’indexation. En revanche les textes en question, dans l’état actuel de la traduction (qui ne porte que sur ce qui ajouté dans la nouvelle version, le reste étant déjà traduit), portent surtout sur des questions très techniques qui sont largement au-delà des compétences d’un collégien ou d’un lycéen. Par exemple l’aide sur les fonctions statistiques ajoutées dans la version 5.

    La documentation se compose essentiellement du wiki et des guides qui sont des documents au format ODF. Les guides sont les seuls documents dont la traduction s’apparente à de la traduction « littéraire ». Mais franchement ce ne sont pas des textes dont les qualités littéraires et romanesques vont donner le goût de la langue anglaise à des collégiens ou lycéens. Pour cela il me paraîtrait bien plus efficace de faire trouver et traduire par les élèves les passages d’Harry Potter censurés par l’éditeur français. Harry Potter n’est qu’un exemple « personnel » : le constat d’avoir été flouées par le traducteur français a donné à plusieurs de mes filles le goût de relire la saga en anglais pour en retrouver toute la saveur, apparemment vraiment affadie par la traduction française. Il est probable que ce n’est pas le seul exemple de littérature jeunesse où la traduction trahit parfois le texte original.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.