Traduction de KDE : une activité essentielle portée par la communauté KDE francophone

45
16
mai
2023
KDE

La communauté francophone de KDE vous propose un tour d’horizon concernant le processus de traduction de KDE, notamment sa mise en œuvre vers le français. En effet, nos développeurs et développeuses sont disséminés sur toute la planète, la langue commune est l’anglais. Vouloir proposer à tout le monde des logiciels libres, avec de larges possibilités et de nombreuses fonctionnalités, est un défi : il faut prendre en compte de nombreuses spécificités locales : alphabets, conventions de notation (date, heure, monnaie, etc.), sens d’écriture, etc. avant même de traduire.

Konqi, mascotte de KDE

Ce processus, référencé sous les termes « d’Internationalisation » et de « Localisation », nécessite un fort engagement de nombreuses et plus ou moins importantes équipes de traduction. Il est tout aussi complexe que les processus de développement. En amont, les équipes de développement doivent isoler les éléments concernant la langue. En aval, les équipes de traduction… traduisent ! Entre les deux, la coordination repose sur une infrastructure importante, notamment pour les mises à jour à la sortie de nouvelles versions. Ces activités d’internationalisation sont réalisées de nombreuses façons. Cet article présentera plus en détail le fonctionnement pour tous les logiciels, applications, documentations et pages de site web pour un des environnements graphiques parmi les plus populaires, associé à tout son écosystème d’applications : KDE.

Cet article est coécrit par Xavier Besnard, le traducteur le plus actif de l’équipe qui aide aussi à la coordination et l’accueil des nouveaux bénévoles.

Sommaire

Environnement KDE et internationalisation

De nombreux environnements graphiques existent, chacun ayant ses propres concepts d’ergonomie, de charte graphique, etc. KDE Plasma est l’un d’entre eux, avec une très longue histoire, commençant par son émergence timide, il y a 25 ans (déjà). Son développement intensif est soutenu par une communauté très active. Il atteint aujourd’hui une très grande maturité pour un bureau simple, élégant et puissant. Si vous voulez en savoir plus sur l’histoire de KDE, une page d’historique vous fera revivre cette incroyable épopée, pour un environnement graphique qui se voulait « Kool Desktop Environment ». Les initiatives autour de KDE continuent, comme indiqué dans sa page d’anniversaire, pour développer tout un écosystème d’applications construites à partir des environnements de développement de KDE et reposant notamment sur la bibliothèque Qt.

Qu’y a-t-il à internationaliser dans KDE ? En fait, beaucoup de choses :

  • tous les éléments faisant partie de l’interface graphique (titres, messages, boutons, infobulles, listes déroulantes, menus, etc.) ;
  • tous les éléments permettant l’affichage des pages web pour les applications (la page des annonces de KDE, la page d’historique, les sites d’applications comme Kdenlive/Krita, les pages de l’initiative kde-eco, etc.) ;
  • tous les éléments de documentation des applications (manuel utilisateur).

Pour des raisons historiques, les deux premiers éléments font partie de la branche messages et le dernier de celle docmessages.

L’élément essentiel reste la branche messages, contenant :

  • toutes les chaînes de caractères du bureau KDE Plasma et son interface graphique ;
  • toutes les chaînes associées aux plus de 250 applications, faisant partie de l’écosystème de KDE ;
  • toutes les chaînes associées aux différentes pages de sites web associées aux applications ou aux sites d’annonces ou de promotion de KDE.

Mais qu’est-ce que cela représente en volume ?

  • plus de 240 000 chaînes de caractères à traduire ;
  • plus de 500 dossiers, regroupant les chaînes par application ou module ou page ;
  • plus de 650 fichiers (comportant de une à plus de 12 000 chaînes pour l’application KStars).

Pour la branche docmessages, les volumes sont plus réduits et la fréquence de mise à jour moins importante, soit quand même :

  • plus de 60 000 chaînes de caractères à traduire ;
  • plus de 650 fichiers, contenant la documentation des applications ;
  • plus de 200 dossiers (certaines applications restant à documenter).

La traduction est une activité itérative, se construisant à partir d’une primo-traduction, suivie de mises à jour au fur à mesure. Au cours des années, l’équipe de traduction francophone a été plus ou moins nombreuse et active, pour se répartir la charge de travail. Au début des années 2000, la communauté active de KDE francophone comptait plus d’une vingtaine de personnes. Aujourd’hui, la communauté s’est insuffisamment renouvelée et compte moins d’une dizaine de membres actifs. Fort heureusement, les mises à jour itératives permettent de maintenir un niveau de traduction proche des 91 %. Malgré ses ressources limitées, la communauté de KDE francophone reste dans le top 10 des équipes d’internationalisation, ce qui reste une très bonne nouvelle pour toute personne utilisatrice. Malgré tout, cela laisse à ce jour environ 26 000 chaînes à traduire en français, ce qui représente une charge notable.

Notre ambition est de vous présenter une forme de contributions moins connue que le développement de code, mais ouverte à toute personne ayant un niveau intermédiaire en anglais et une capacité à utiliser quelques outils informatiques. La communauté KDE francophone sera toujours prête à accueillir, former, accompagner et aider toute personne à maintenir la traduction de KDE la plus complète possible et avec le meilleur niveau de qualité.

Internationalisation

Comme beaucoup de projets Linux, les logiciels de KDE sont portés par une large communauté, très internationale. Dès ses débuts, KDE a intégré dans ses processus de développement la possibilité d’offrir tous les logiciels de la communauté dans le maximum de langues. KDE prend en charge 112 langues à ce jour, dont les équipes peuvent être contactées sur leurs listes de diffusion. Parmi elles, 57 ont été actives l’an dernier. Vous pouvez donc choisir votre langue, qu’elle soit latine ou pas. En effet, il ne faut pas oublier que 9 langues sur 10 n’utilisent pas un alphabet latin et que l’anglais n’est utilisé que par une quinzaine de pourcent de la population mondiale. Pour proposer cette « Localisation (l10n) » ou « Internationalisation (i18n) », les équipes de développement isolent dans leurs codes sources tous les éléments en anglais (textes ou éléments contenant du texte) affichés sur un écran. Cela regroupe beaucoup de choses comme :

  • les menus, les boutons, les listes déroulantes, les titres de fenêtres ;
  • les messages d’erreurs, les infobulles d’aide ;
  • la documentation des applications ;
  • les sites et les pages web associées aux applications ou aux communications de KDE.

Bien évidemment, avoir une version localisée est possible dans la mesure où une communauté de traduction est suffisamment nombreuse et active. Les figures ci-dessous illustrent ce que donne l’internationalisation :

Panorama général de la traduction de KDE

Les statistiques de toutes les équipes de traduction sont consultables. Au jour où a été écrit cet article, l’équipe francophone se place huitième avec un taux de traduction de 91 %, loin de l’équipe ukrainienne (100 %), et derrière les communautés néerlandaise, catalane, portugaise, italienne, espagnole et suédoise. Ce classement existe aussi pour la partie documentaire, qui reste largement en retrait pour la communauté francophone, faute de ressources.
Chaque jour, les équipes de développement effectuent des modifications dans les textes à afficher. De nouvelles chaînes de caractères apparaissent, nécessitant des traductions à partir de zéro, d’autres sont modifiées et la traduction doit être ajustée, enfin certaines chaînes deviennent obsolètes. La traduction est donc un processus calé sur les développements et en évolution permanente qui a besoin d’une équipe nombreuse, active et réactive.

Processus gérant la traduction

La traduction concerne deux types de projets : les logiciels de KDE (le bureau et les applications) ainsi que les documentations associées. Contrairement à d’autres projets libres utilisant une interface web pour gérer leurs traductions, les traductions de KDE reposent sur des fichiers de traduction stockés dans un dépôt SVN et traduits hors ligne.

Il existe deux branches de traduction : « trunk » et « stable ». La branche « trunk » correspond au code actuel (qui varie quotidiennement) et la branche « stable » correspond à la dernière version officielle du logiciel. Chaque équipe de traduction est autonome dans sa façon de gérer les fichiers. Certaines équipes préfèrent directement modifier à la fois les chaînes dans ces deux branches mais dans le cas de plusieurs langues dont le français, nous utilisons une troisième branche nommée « summit » qui agrège les chaînes de « trunk » et « stable » dans un seul fichier à traduire et des scripts poussent quotidiennement dans chaque branche la traduction à appliquer pour cette branche. On peut voir l’état de la traduction de la branche « summit » sur les pages d’applications et de documentations. Des scripts tournent tous les jours afin de mettre à jour les différents fichiers de traduction avec les chaînes mises à jour dans les applications. Chaque jour, ces scripts permettent de donner un état à chaque chaîne des fichiers de traduction. Deux états nécessitent des actions de l’équipe de traduction :

  • la chaîne de traduction en français est vide, indiquant l’apparition d’une nouvelle chaîne dans le fichier source ;
  • la chaîne de traduction est étiquetée « Fuzzy », indiquant que la chaîne du fichier source a été modifiée et nécessite une reprise de traduction.

Fort heureusement, ces états sont directement gérés de façon graphique, par l’outil KDE supportant le processus d’internationalisation et décrit dans le chapitre suivant : Lokalize.

Le processus de traduction en images

Après avoir annoncé la prise en charge d’une traduction sur la liste de diffusion, la première étape consiste à récupérer le fichier « .po » à traduire sur le site des traductions de KDE ou avec SVN directement en mode anonyme.

KDE propose un outil spécifique pour soutenir le travail des personnes traductrices, Lokalize. Sa documentation est accessible à https://docs.kde.org/stable5/fr/lokalize/lokalize/index.html. Dans la capture ci-dessous, nous avons récupéré l’ensemble des fichiers de KDE à traduire. Avec un paramétrage correct, Lokalize donne accès à tous les répertoires et les fichiers. Grâce à la fonctionnalité « Cacher les éléments complétés », Lokalize présente dans l’onglet « Vue d’ensemble du projet », la liste des fichiers du projet, sur lesquels des travaux de traductions sont possibles.

Lokalize
En cliquant sur un fichier à traduire, Lokalize présente, dans la fenêtre supérieure, la chaîne originelle en anglais et permet la saisie de la traduction en français. Le travail de traduction est facilité par un glossaire, qui compile les éléments des traductions antérieures et propose des chaînes proches ainsi qu’une mémoire de traduction. Ceci est un point capital pour proposer des traductions homogènes.

Le second onglet « Mémoire de traduction » est un élément essentiel de notre processus. Il compile les traductions déjà effectuées sur tous les fichiers et fait des propositions de traduction. Cela permet d’avoir une certaine homogénéité entre traductions mais aussi de ré-utiliser des formules/termes/phrases déjà validés :

Exemple sur Bonsai

Le processus de contrôle de traduction

Toute personne est sujette à des fautes de frappe, des erreurs de copier-coller… Chaque personne en charge de traduction a quelques outils à sa disposition pour filtrer ces coquilles. Tout d’abord, Lokalize prend en compte le correcteur orthographique Aspell, ce qui permet d’identifier certaines coquilles.

Un autre outil important est Pology, un ensemble de scripts permettant d’interagir avec les fichiers de traduction, qui dispose d’une présentation très complète.
Ces scripts permettent d’harmoniser l’orthographe, le choix de certains mots plutôt que d’autres et la grammaire dans les fichiers en fonction des règles choisies par la communauté KDE Francophone. Comme la mémoire de traduction, Pology peut analyser un fichier à la recherche des mots en dehors de son dictionnaire. En lançant en ligne de commandes posieve check-spell-ec bonsai.po, il est possible d’identifier des erreurs sur les mots utilisés :

check-spell sur Bonsai

Le dernier outil de l’équipe francophone est aussi un script de Pology, mais avec un ensemble de règles compilées tout au long des activités de l’équipe de traduction. En lançant en ligne de commandes posieve check-rules bonsai.po, un grand nombre de cas de figures sont testés dont par exemple, les règles de typographie. D’autres règles ont des portées plus importantes, faisant suite à des choix de l’équipe de traduction, comme la traduction générale de repository par dépôt :

check-rules sur Bonsai

L’équipe francophone fait tourner ces scripts régulièrement pour centraliser les résultats des fichiers d’applications et de documentations et pour éviter que chaque traducteur ait à le faire manuellement.

Il est important que toutes ces vérifications soient faites pour limiter les « coquilles ». Il existe aussi un dictionnaire simplifié en ligne sur les principaux termes à utiliser pour harmoniser. Cependant, les relectures des traductions sont nécessaires, car ces outils ont des faux positifs, ne gèrent pas tous les cas, mais surtout ne remplacent pas une compréhension humaine.

Enfin, car, malgré toutes ces mesures, il peut arriver que la traduction dans son contexte soit discutable, inadaptée ou carrément erronée, il est toujours possible d’ouvrir un rapport de bug, assigné à l’équipe de traduction. N’hésitez pas à documenter la chaîne incriminée et à faire une/des propositions, qui nous permettront de trouver la chaîne à modifier et la mettre en ligne dans les meilleurs délais.

Comment contribuer

Contribuer à un logiciel libre peut se faire de différentes façons. Le développement de code est certes la plus importante, mais nécessite de multiples compétences techniques. Cependant, il y a beaucoup d’autres activités permettant de contribuer : la traduction, la conception graphique, la communication, le traitement de bugs et d’autres. La traduction de l’environnement KDE et de son écosystème d’applications est tout aussi importante que le développement. Cette activité ne nécessite que des connaissances générales sur l’environnement KDE, mais surtout une certaine maîtrise de l’anglais et une capacité à exprimer dans un français correct ce que l’équipe de développement a codé dans son texte initial. Pour la traduction en français, la plus grande partie de ce travail est faite par une seule personne, toute aide est donc la bienvenue : vous pouvez aider soit en devenant responsable de la traduction d’une application (un amateur d’astronomie a traduit et continue de traduire KStars et l’ensemble de sa documentation), soit en étant relecteur des fichiers, en remontant des erreurs ou améliorations de traductions. La page d’accueil de la traduction française a été mise à jour récemment et permet de connaître les premiers pas pour se lancer dans la traduction. Il ne faut pas hésiter à d’abord commencer avec des petits fichiers, de préférence dans un domaine que l’on connaît bien et, ensuite, une fois à l’aise, s’attaquer soit à de plus gros morceaux, soit à des fichiers plus techniques. Dans tous les cas, il ne faut pas hésiter à s’appuyer sur la communauté pour mettre le pied à l’étrier ou s’il y a le moindre doute sur une traduction. Les fichiers de traductions ont été regroupés sur les pages Applications et Documentation.

Pour remonter des idées d’améliorations, des bugs ou des commentaires, l’équipe francophone est accessible via différents moyens de communications :

Conclusion

KDE est une communauté de bénévoles qui offrent de leurs temps et de leurs compétences pour son amélioration. La traduction présente un avantage simple : elle est facilement accessible en fonction du temps que vous souhaitez y consacrer et les sujets qui vous intéressent. Pourquoi rejoindre le groupe de traduction ? La réponse la plus simple est simplement de soutenir un logiciel libre et participer à une communauté car traduire est aussi une activité cruciale. C’est aussi une opportunité d’améliorer ses connaissances en anglais, y compris en partant d’un niveau d’anglais réduit et améliorer son vocabulaire. Les membres des équipes de développement ne maîtrisent pas forcément l’anglais, aussi vous avez une grande latitude pour traduire au mieux pour être compréhensible en français. Enfin, si vous avez des applications qui vous intéressent en particulier, et/ou vous avez des connaissances spécifiques (vidéo, audio, mathématiques, astronomie, etc.), vous pouvez améliorer largement les traductions de celles-ci (KStars pour l’astronomie, Krita pour la peinture numérique, LabPlot pour les tracés de fonctions, RkWard pour les statistiques, etc.).

Pour nous rejoindre et améliorer l’état de la traduction de KDE, contactez-nous sur la liste de diffusion et suivez la procédure pour réserver vos fichiers !

Aller plus loin

  • # Fichier .po

    Posté par  . Évalué à 6.

    Merci pour cette dépêche très complète et instructive. À sa lecture, une question m'est revenue.

    Les logiciels KDE (tous ?) sont basé sur Qt. Lorsqu'on développe un logiciel avec Qt, les fichiers de traductions sont des fichiers XML qui ont une extension.ts

    Aussi, n'ai-je jamais compris (ni chercher à comprendre) pourquoi les logiciels KDE n'utilisent pas ces fichiers .ts mais des fichier .po à la place.

    À quel moment de l'histoire de KDE l'utilisation de fichiers PO (et pas de fichiers TS) a-t-elle été décidé et pourquoi ?

    • [^] # Re: Fichier .po

      Posté par  . Évalué à 7.

      J'ai trouvé cette réponse sur le site de KDE :

      Even Qt-translated frameworks use .po files rather than Linguist source files (.ts). This make it possible for translators to use the same tools for all frameworks.

      • [^] # Re: Fichier .po

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

        Il y a deux raisons principales pour moi :

        • il y a beaucoup d'outils permettant de travailler avec les fichiers .po (https://www.gnu.org/software/gettext/manual/gettext.html) ;

        • et surtout il n'y a pas que les applications développées en Qt qui ont besoin de traduction. Par exemple, les sites internet (par exemple, le site internet de GCompris utilise pybabel pour extraire les chaînes d'un site généré statiquement en Jinja2) ou la documentation qui est au format docbook.

  • # Un peu fait il y a 10 ans

    Posté par  . Évalué à 10. Dernière modification le 16 mai 2023 à 11:25.

    Je recommande. C'est une activité utile, on y dédicace le temps qu'on veut en s'occupant de plus ou moins de traductions, l'équipe est accueillante et agréable.

    Et traduire des chaînes ça a un petit côté méditatif / vaguement addictif je trouve (mais c'est peut-être que moi). Ça peut peut-être aisément remplacer un peu de scrolling de réseaux sociaux / d'actualités pour un meilleur état mental et pas forcément plus de fatigue à la fin.

    • [^] # Re: Un peu fait il y a 10 ans

      Posté par  . Évalué à 6.

      Exactement : c'est une activité que j'ai pratiqué des heures dans les transports en commun !
      Pas besoin d'une concentration énorme (un peu comme faire des mots croisés, du sudoku ?). Le soir, ça ne provoque pas des insomnies comme bien d'autres activités devant l'écran.

      Et oui, se fixer l'objectif de passer tout un dossier à 100%, de gagner des places dans le classement… ça peut être un petit jeu, un défi personnel qui donne des satisfactions simples (que peu comprennent).

  • # Super dépêche

    Posté par  . Évalué à 5.

    Merci pour cette dépêche, ça m’a donné envie d’essayer. Je viens d’installer Lokalize, je vais essayer de faire ça en fin de semaine. Et concernant le fichier .po j'ai pas bien compris mais une seul une seule personne peut le modifier en même temps ?

    • [^] # Re: Super dépêche

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

      Comme pour tous les fichiers, si plusieurs personnes les modifient en même temps, il risque d'y avoir des conflits au moment de la fusion des fichiers avec ceux du dépôt.

      En général, c'est assez rare que plusieurs personnes travaillent sur le même fichier en même temps, et pour éviter ça, nous préférons que les personnes "réservent" des fichiers pour être sûr d'éviter de dupliquer du travail (car une personne qui a pris le temps de faire une traduction et voit son travail échangé va avoir moins d'envie de contribuer).

      Après, s'il y a des conflits au niveau du fichier (car la version récupérée par le traducteur est trop vieille par exemple et il y a eu pas mal de changements sur les chaînes en anglais entre temps), selon le niveau technique de la personne qui traduit, les coordinateurs vont gérer eux-mêmes les conflits, committer le fichier sous SVN et ensuite demander au traducteur de repartir du dernier fichier en conf.

      • [^] # Re: Super dépêche

        Posté par  . Évalué à 5.

        committer le fichier sous SVN

        vous ne gérez pas avec Git ?

        • [^] # Re: Super dépêche

          Posté par  . Évalué à 4.

          (Troll poilu en vue)

          Il y a 10 sortes de gens dans le monde – ceux qui comprennent le ternaire, ceux qui ne le comprennent pas et ceux qui le confondent avec le binaire.

        • [^] # Re: Super dépêche

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

          C'est une discussion assez récurrente qui revient (entre Git et les interfaces en ligne pour traduire) : il y a une tâche avec énormément d'aller-retours.

          De ce que je comprends, après un passage rapide :

          • migrer les scripts actuels, il faut un volontaire ;
          • même si cela permettrait d'avoir plus de contributeurs, cela n'assurerait pas une meilleure qualité ;
          • SVN reste un outil "interne" dans le sens où, si quelqu'un veut faire une modification, ce sont en général les mainteneurs ;
          • d'un point de vue sysadmins, l'équipe préférerait évidemment que la traduction migre à Git car c'est le dernier cas d'utilisation de SVN ;
          • il faudrait peut-être revoir la structure du/des dépôts, pour le moment, toutes les traductions sont dans le même dépôt SVN et on peut cloner seulement une langue. Avec Git, soit il faut splitter les dépôts, soit tout télécharger…

          La discussion est très longue donc j'ai seulement pris quelques arguments rapidement, mais il y en a d'autres…

          Récemment, il y a aussi eu la migration des scripts Pology qui étaient en Python 2 en Python 3. Étant donné que c'est un gros code avec peu de tests unitaires, que le but est de toucher pas mal de chaînes de caractères, la volonté de changer était présente, mais les compétences moins donc ça a pris plusieurs années.

  • # Traduction des images

    Posté par  . Évalué à 9.

    Dans la documentation ou le site web, il arrive parfois qu'il y ait des captures d'écrans (par exemple ici pour Okular). Y a-t-il un moyen de « traduire » aussi ces captures d'écran afin que le texte affiché sur l'image apparaisse dans la langue de l'auteur ?

    A priori, c'est très lourd à gérer, mais

    1. y a-t-il un moyen de fournir des images « internationalisées » ?
    2. y a-t-il des « outils KDE » pour simplifier cette étape ?
    • [^] # Re: Traduction des images

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

      Pour les manuels utilisateurs (accessibles ici), on peut les remplacer pour chaque langue si quelqu'un fait le travail. Par exemple, pour KStars :

      Pour cela, il faut mettre les images traduites dans le SVN.

      Je suis en train de me renseigner, c'est à priori possible de faire pareil pour les sites web (au moins ceux codés en Hugo) en mettant dans le git une image traduite (j'imagine en postfixant avec "-$locale") mais je n'ai pas trouvé d'exemple où c'est réalisé

Suivre le flux des commentaires

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