Les traductions de balises générées par IA ne fonctionnent pas parfaitement

En parcourant les traductions des balises allemandes, j’ai remarqué une série de problèmes qui semblent découler du manque de contexte de l’IA : elle traite les balises comme des mots isolés plutôt que comme des références à des fonctionnalités, des plugins ou des composants spécifiques de Discourse.

Note : Les noms communs allemands sont toujours capitalisés, mais les balises sur Meta sont en minuscules. Les traductions dans ce post sont donc incohéremment capitalisées – j’ai glissé par habitude vers la capitalisation allemande correcte.

Commençons par la partie amusante

Avant d’aborder les problèmes pratiques, certaines traductions sont tout simplement divertissantes :

  • composer → “Komponist” – C’est la personne qui compose de la musique
  • auto-bump → “automatische-erhöhung” – “augmentation automatique”
  • fully-theme → “vollständig-thematisiert” – “pleinement abordé”
  • raspberry-pi → “Himbeere-pi” (“Himbeere” comme le fruit)
  • post-voting → “nach-der-Abstimmung” – “après le vote” (“post” lu comme le préfixe latin, et non comme un message de forum)
  • tablet → “Tablette” – “pilule” (le médicament, et non l’appareil)

Même traduction pour différentes balises

C’est le problème le plus impactant dans la pratique. Lorsque deux balises reçoivent la même traduction, elles perdent leur capacité à distinguer les sujets les uns des autres.

  • year-in-review & yearly-review → “Jahresrückblick” – Actuellement, le nom du plugin semble ne pas être traduisible (je vois le nom anglais dans la barre latérale d’administration et dans la liste des plugins installés), il est donc probable que vous utilisiez le terme anglais pour désigner le nom du plugin. Bien que j’espère qu’un jour tous les plugins auront des noms traduits, je pense que j’ajouterais “Metas” à celui regroupant les sujets de revue annuelle ici pour les séparer, donc “Metas-Jahresrückblick” (revue annuelle de Meta).
  • surveys & polls → “Umfragen” – Je pense que les traductions des deux plugins sont également identiques et personne ne l’a remarqué jusqu’ici. Je dois réfléchir davantage à une bonne solution pour celui-ci car il peut aussi facilement entrer en conflit avec “voting” :exploding_head:
  • docs & documentation → “Dokumentation” – Tout comme yearly-review docs n’a pas été traduit en allemand, je ne traduirais pas la balise (dans ce cas, une traduction future semble très improbable).
  • how-to & tutorial → “Anleitung” – Celui-ci a déjà été corrigé. J’ai trouvé cette traduction de https://diataxis.fr/ et j’ai suggéré le terme[1] utilisé là-bas.

Noms propres et noms de produits qui ne devraient pas être traduits

Certaines balises font référence à des outils, des frameworks ou des produits spécifiques. Les traduire rend la fonctionnalité méconnaissable.

  • raspberry-pi → “Himbeere-pi” (“Himbeere” comme le fruit)
  • mermaid → “Meerjungfrau” (“Meerjungfrau” comme la créature mythologique, et non l’outil de diagrammes)
  • ember → “Glut” (braises incandescentes d’un feu)
  • vanilla → “Vanille” (la saveur)
  • onebox → “einzige-box” – “seule boîte”
  • intercom → “Gegensprechanlage” (un interphone comme une sonnette de porte – bien que intercom-widget ait été correctement traduit)
  • passkey → “Passwort” – “mot de passe” (une clé d’accès n’est spécifiquement pas un mot de passe)
  • perspective-api → “Perspektiven-api”
  • backups → “Sicherungen”
  • design-experiment → “Experimententwurf” – peut être “design-experiment” mais aussi “expérience de projet”, je pencherais pour ce dernier car pour le premier j’aurais gardé “design” et parler de projets est assez courant dans Discourse.

Traductions de “Discourse”

La plupart des balises faisant référence à “Discourse” ont été traduites de sorte qu’elles ne contiennent plus le nom du logiciel. Une exception est discourse-hub.

“Theme” systématiquement mal traduit par “Thema” (sujet)

C’est un problème systématique pour toutes les balises liées aux thèmes. En allemand, à la fois “theme” et “topic” se traduisent par “Thema”, mais dans le contexte de Discourse, ce sont des choses très différentes. Cela fait que les balises de thème semblent parler de sujets de discussion spécifiques.

Cela affecte toutes les balises du groupe Official Themes.

Traductions où le contexte manquait

  • composer → “Komponist” – C’est la personne qui compose de la musique, comparé au champ de saisie que nous appelons habituellement “Éditeur” en allemand.
  • tablet → “Tablette” – “pilule” ou “comprimé”.
  • copy-post → “kopierbeitrag” – “frais de copie” (Le problème est la combinaison des mots. “Beitrag” pour post est correct, mais comme copy n’a pas été traduit comme verbe, cela se lit comme si Beitrag était utilisé dans le sens de frais ici).

Nom ou verbe

Certaines fonctionnalités ont été traduites comme des verbes au lieu de noms.

  • chat → “plaudern” – “discuter”
  • search → “suchen” – “chercher”

“post” lu comme le préfixe latin, et non comme un message de forum

  • post-voting → “nach-der-Abstimmung” – “après le vote”
  • post-badges → “nach-Abzeichen” – “après les badges”

Résultats de balises anglaises pas très claires

  • hosted-support → “gehosteter-support” (Cela se lit comme un support hébergé au lieu d’un support pour les clients hébergés)

Abréviation

  • pm-dropdown (identique en allemand) sans contexte, le m (message) n’a pas été remplacé par n (Nachricht)

Traductions qui ne correspondent pas à la terminologie propre à l’interface de Discourse

Ces traductions sont techniquement un allemand correct, mais l’interface utilisateur de Discourse utilise des termes différents. Cela rend les balises plus difficiles à trouver intuitivement, en particulier pour les utilisateurs qui naviguent selon la langue de l’interface.

  • impersonate → “nachahmen” – “imiter” (mais l’interface utilise Nutzersicht ou Nutzerrolle)
  • staged-users → “Staging-Benutzer” (mais l’interface dit vorbereitete Benutzer)
  • advertising → “Werbung” (mais l’interface se réfère à Anzeigen)
  • assign → “zuweisen” (mais la traduction du plugin utilise zuordnen)
  • hot-topics → “Top-Themen” (cela a été traduit par “sujets principaux”, qui est en fait une liste différente dans Discourse)
  • read-only → “nur lesbar”
  • bootstrap-mode → “Bootstrap-Modus” (mais les traducteurs ont initialement choisi Starthilfemodus)
  • post-notices → “Nachrichten” – “messages/actualités” (peut être trompeur car les messages sont une fonctionnalité différente, “avis officiel” utilise Mitteilung dans l’interface)
  • about-page → “über-Seite” (C’est une traduction littérale. Mais généralement, la traduction allemande est quelque chose comme “page à propos de nous”. Über ne signifie pas seulement “à propos” mais aussi “au-dessus”.)
  • auto-bump → “automatische-erhöhung” – “augmentation automatique”
  • tags → “Etiketten” (mais tag-groups et la plupart des balises contenant tag utilisent “tag”, le terme utilisé sur Crowdin est Schlagwort)

Traductions tronquées

C’est un type de problème différent – pas une erreur de traduction, mais une conséquence des noms composés allemands étant significativement plus longs que leurs équivalents anglais, combiné à la limite de caractères des balises.

  • content-security-policy → “inhalts-sicherheitsrichtl” (coupé, devrait être inhalts-sicherheitsrichtlinie)
  • ai-custom-prompt → “ai-benutzerdefinierte-auf” (coupé au milieu du mot, devrait être ai-benutzerdefinierte-aufforderung)
  • custom-category-boxes → “benutzerdefinierte-katego” (coupé au milieu du mot, devrait être benutzerdefinierte-kategorie-boxen, dans ce cas box manque complètement de la traduction)

Les balises contenant “custom” deviennent facilement trop longues car “benutzerdefiniert” est un mot assez long.

plus d'exemples

Ces exemples suggèrent que le processus de traduction a besoin de plus de contexte – idéalement savoir à quel plugin ou fonctionnalité appartient une balise, et avoir accès aux traductions existantes de l’interface de Discourse comme référence. Je suis ravi d’entendre si d’autres ont remarqué des modèles similaires dans d’autres langues.


@nat (sur demande personnelle)


  1. Lernunterlagen ↩︎

6 « J'aime »

Merci @Moin, je vais examiner cela et améliorer nos invites :smiling_face:

Aussi, LOL

Merci pour les rires :hugs:

4 « J'aime »

@nat et si on donnait à l’agent l’accès à l’outil de lecture, afin qu’il puisse rassembler le contexte lui-même ?

Ce serait trop coûteux pour les publications, mais relativement peu onéreux et cela améliorerait la qualité pour tous les modèles, notamment pour des cas ponctuels comme les balises et les catégories.

3 « J'aime »

Hmm, c’est une bonne idée @falco.

Une autre méthode que j’avais envisagée consistait à transmettre la description de l’étiquette en tant que contexte supplémentaire lors de la traduction du nom de l’étiquette. Peut-être que cette méthode est plus prévisible, qu’en pensez-vous ?

4 « J'aime »

Avoir accès au glossaire sur Crowdin pourrait être très utile pour le bot effectuant la traduction (pas pour tous les sites, mais particulièrement pour Meta). Si l’on y indique que nous traduisons « composer » par « Éditeur » et que l’IA le sait, elle pourrait l’utiliser dans les balises, mais aussi dans les titres de sujets et les publications.

J’avais déjà corrigé « composer » dans Introducing our new composer, making writing on Discourse easier than ever, ce qui a donné lieu à mon retour sur la modification des traductions ici : Feedback on the composer when translating a post to German. Cependant, le sujet a été modifié après que j’ai fait cela, et il ne semble pas que la traduction antérieure soit utilisée comme contexte, de sorte que le message indique à nouveau « composer ». (L’auteur de musique n’apparaît généralement pas dans les publications ; seuls des textes plus courts comme les titres de sujets et les balises sont concernés.)

Sur Meta, la description n’ajoute souvent pas beaucoup de contexte. Par exemple, celles des composants de thème contiennent simplement un lien vers le sujet du composant, et non la courte description figurant au début du sujet.

Bonne idée, faisons les deux !

L’idée est d’utiliser Meta comme terrain d’essai et proxy de ce que nos clients pourraient rencontrer dans la nature, afin d’améliorer la fonctionnalité pour tout le monde.

Obtenir une traduction parfaite sur Meta serait extrêmement simple en utilisant simplement le LLM le plus coûteux et en lui donnant accès à des outils tels que l’accès au code source et la recherche sur le web.

Je ne pense qu’aucun modèle ne choisirait les mêmes traductions pour Meta que les traducteurs allemands n’ont choisies pour l’interface de Discourse. « Mitarbeiter » est une traduction parfaite pour « staff ». Le fait que certains traducteurs aient décidé il y a des années que cela ne convenait pas aux petits forums de loisirs – où « staff » implique des employés rémunérés – et aient donc choisi « Team » est quelque chose qu’aucune IA ne devinera, car ce n’est tout simplement pas la traduction correcte. C’est exactement là que le glossaire Crowdin serait utile : sans lui, les termes générés par l’IA ne correspondront jamais à ce que les administrateurs voient réellement dans l’interface – non pas parce que l’IA ne peut pas traduire, mais parce qu’elle ne prend pas les mêmes décisions de localisation que les traducteurs humains. C’est la différence entre la traduction et la localisation.
Et c’est similaire pour d’autres termes comme « bootstrap mode » ou « impersonation ».

Il le ferait, car il aurait accès à ce même choix dans les fichiers config/locales/**/*.yml à titre de référence.

Tout à fait, et pour de petits groupes énumérables, comme les catégories et les balises, donner accès à l’agent aux traductions existantes, qui font partie du code source, l’aiderait à s’ancrer dans le contexte.

Nous ne pouvons pas faire cela pour les publications, car le coût serait trop élevé, mais c’est une option pour les petits sites ou les clients disposant de budgets de traduction plus importants.

Alors, peut-être devriez-vous désactiver la traduction par IA pour Documentation et News and Events > Announcements :wink: Je ne pense pas qu’il soit possible de garantir que ces traductions soient utiles, d’autant plus que les modifications suggérées ne relancent pas le sujet, il n’y a donc aucun moyen simple de remarquer qu’un sujet a été mis à jour.

En général, c’est le coût qui m’a poussé à suggérer d’utiliser le glossaire plutôt que les fichiers contenant toutes les traductions, car je m’attendrais à ce qu’il contienne les choix les plus pertinents une seule fois, sans ajouter chaque texte.

Ce n’est pas ainsi que cela fonctionne ; l’agent peut rechercher dans le code des fragments correspondants et ne charge jamais l’intégralité du contenu dans le contexte.

C’est un peu comme jeter le bébé avec l’eau du bain, n’est-ce pas ?

Je viens de vérifier Calendar subscription URLs for external calendar apps en PT-BR, et la traduction semble excellente, bien meilleure que de ne rien avoir.

Il y aura toujours des améliorations à apporter à un flux de travail de traduction automatique non supervisé, et @nat a déjà amélioré la situation aujourd’hui grâce à vos retours !

Personne ne s’attend à ce que ce soit parfait, et Meta est un endroit où nous pouvons adopter rapidement de nouvelles fonctionnalités et montrer ce qui est possible dans Discourse pour nos utilisateurs et clients.