Von KI generierte Tag-Übersetzungen funktionieren nicht perfekt

Beim Durchscrollen der deutschen Tag-Übersetzungen fiel mir eine Reihe von Problemen auf, die scheinbar darauf zurückzuführen sind, dass der KI der Kontext fehlt – sie behandelt Tags als isolierte Wörter anstatt als Verweise auf spezifische Discourse-Funktionen, Plugins oder Komponenten.

Hinweis: Deutsche Substantive werden immer großgeschrieben, aber Tags auf Meta sind kleingeschrieben. Die Übersetzungen in diesem Beitrag sind daher inkonsistent großgeschrieben – ich bin aus Gewohnheit immer wieder in die korrekte deutsche Großschreibung verfallen.

Zuerst der unterhaltsame Teil

Bevor wir zu den praktischen Problemen kommen, sind einige Übersetzungen einfach nur amüsant:

  • composer → „Komponist" – Das ist die Person, die Musik schreibt.
  • auto-bump → „automatische-erhöhung" – „automatische Erhöhung"
  • fully-theme → „vollständig-thematisiert" – „vollständig behandelt"
  • raspberry-pi → „Himbeere-pi" („Himbeere" wie die Frucht)
  • post-voting → „nach-der-Abstimmung" – „nach der Abstimmung" („post" als lateinische Vorsilbe gelesen, nicht als Forenbeitrag)
  • tablet → „Tablette" – „Pille" (das Medikament, nicht das Gerät)

Gleiche Übersetzung für verschiedene Tags

Dies ist das problematischste Problem in der Praxis. Wenn zwei Tags dieselbe Übersetzung erhalten, verlieren sie die Fähigkeit, Themen voneinander zu unterscheiden.

  • year-in-review & yearly-review → „Jahresrückblick" – Der Plugin-Name scheint derzeit nicht übersetzbar zu sein (ich sehe den englischen Namen in der Admin-Seitenleiste und in der Liste der installierten Plugins), daher würde man wahrscheinlich den englischen Begriff verwenden, um auf den Namen des Plugins zu verweisen. Ich hoffe jedoch, dass eines Tages alle Plugins übersetzte Namen haben, sodass ich denke, ich würde „Metas" zu der Gruppe hinzufügen, die die jährlichen Rückblicksthemen hier zusammenfasst, um diese zu trennen, also „Metas-Jahresrückblick" (Metas-Jahresrückblick).
  • surveys & polls → „Umfragen" – Ich denke, die Übersetzungen beider Plugins sind ebenfalls gleich, und bisher hat es niemand bemerkt. Ich muss noch mehr über eine gute Lösung für dieses Problem nachdenken, da es auch leicht mit „Abstimmung" kollidieren kann :exploding_head:
  • docs & documentation → „Dokumentation" – Genau wie „yearly-review" nicht ins Deutsche übersetzt wurde, würde ich auch dieses Tag nicht übersetzen (in diesem Fall scheint eine Übersetzung in der Zukunft sehr unwahrscheinlich).
  • how-to & tutorial → „Anleitung" – Dies wurde bereits behoben. Ich habe diese Übersetzung von https://diataxis.fr/ gefunden und den dort verwendeten Begriff[1] vorgeschlagen.

Eigennamen und Produktnamen, die nicht übersetzt werden sollten

Einige Tags beziehen sich auf spezifische Tools, Frameworks oder Produkte. Eine Übersetzung macht die Funktion unerkennbar.

  • raspberry-pi → „Himbeere-pi" („Himbeere" wie die Frucht)
  • mermaid → „Meerjungfrau" („Meerjungfrau" wie die mythologische Figur, nicht das Diagramm-Tool)
  • ember → „Glut" (glühende Glut aus einem Feuer)
  • vanilla → „Vanille" (der Geschmack)
  • onebox → „einzige-box" – „nur Box"
  • intercom → „Gegensprechanlage" (eine Gegensprechanlage wie eine Türklingel – obwohl intercom-widget korrekt übersetzt wurde)
  • passkey → „Passwort" – „Passwort" (ein Passkey ist speziell kein Passwort)
  • perspective-api → „Perspektiven-api"
  • backups → „Sicherungen"
  • design-experiment → „Experimententwurf" – kann „design-experiment" sein, aber auch „Entwurfsexperiment". Ich würde an letzteres denken, da ich für ersteres „design" beibehalten hätte und das Sprechen über Entwürfe in Discourse recht üblich ist.

Übersetzungen von „Discourse"

Die meisten Tags, die sich auf „Discourse" beziehen, wurden so übersetzt, dass sie den Namen der Software nicht mehr enthalten. Eine Ausnahme ist discourse-hub.

„Theme" systematisch falsch als „Thema" (Topic) übersetzt

Dies ist ein systematisches Problem bei allen themenbezogenen Tags. Im Deutschen bedeuten sowohl „theme" als auch „topic" „Thema", aber im Discourse-Kontext sind dies sehr unterschiedliche Dinge. Dies lässt Theme-Tags so lesen, als ob sie sich auf spezifische Diskussionsthemen beziehen würden.

Dies betrifft alle Tags in der Gruppe „Official Themes".

Übersetzungen, bei denen der Kontext fehlte

  • composer → „Komponist" – Das ist die Person, die Musik schreibt, im Vergleich zum Eingabefeld, das wir im Deutschen normalerweise „Editor" nennen.
  • tablet → „Tablette" – „Pille" oder „Tablet".
  • copy-post → „kopierbeitrag" – „Kopiergebühr" (Das Problem ist die Wortkombination. „Beitrag" für Post ist korrekt, aber da „copy" nicht als Verb übersetzt wurde, liest es sich so, als ob „Beitrag" hier im Sinne von Gebühr verwendet würde.)

Substantiv oder Verb

Einige Funktionen wurden als Verben statt als Substantive übersetzt.

  • chat → „plaudern" – „plaudern" (als Verb)
  • search → „suchen" – „suchen" (als Verb)

„post" als lateinische Vorsilbe gelesen, nicht als Forenbeitrag

  • post-voting → „nach-der-Abstimmung" – „nach der Abstimmung"
  • post-badges → „nach-Abzeichen" – „nach-Abzeichen"

Ergebnisse aus nicht ganz klaren englischen Tags

  • hosted-support → „gehosteter-support" (Dies liest sich so, als würde Support gehostet werden, anstatt Support für gehostete Kunden.)

Abkürzung

  • pm-dropdown (im Deutschen gleich) – ohne Kontext wurde das „m" (message) nicht durch „n" (Nachricht) ersetzt.

Übersetzungen, die nicht mit der eigenen Discourse-Oberflächenterminologie übereinstimmen

Diese Übersetzungen sind technisch korrektes Deutsch, aber die Discourse-Oberfläche verwendet andere Begriffe. Dies macht es für Benutzer, die sich an der Oberflächensprache orientieren, schwieriger, Tags intuitiv zu finden.

  • impersonate → „nachahmen" – „imitieren" (aber die Oberfläche verwendet „Nutzersicht" oder „Nutzerrolle")
  • staged-users → „Staging-Benutzer" (aber die Oberfläche sagt „vorbereitete Benutzer")
  • advertising → „Werbung" (aber die Oberfläche bezieht sich auf „Anzeigen")
  • assign → „zuweisen" (aber die Plugin-Übersetzung verwendet „zuordnen")
  • hot-topics → „Top-Themen" (dies wurde als „Top-Themen" übersetzt, was in Discourse tatsächlich eine andere Liste ist)
  • read-only → „nur lesbar"
  • bootstrap-mode → „Bootstrap-Modus" (aber Übersetzer wählten ursprünglich „Starthilfemodus")
  • post-notices → „Nachrichten" – „Nachrichten/News" (kann irreführend sein, da Nachrichten eine andere Funktion sind; „offizielle Mitteilung" verwendet im Interface „Mitteilung")
  • about-page → „über-Seite" (Dies ist eine wörtliche Übersetzung. Normalerweise lautet die deutsche Übersetzung jedoch etwas wie „Über-uns-Seite". „Über" bedeutet nicht nur „über", sondern auch „oberhalb".)
  • auto-bump → „automatische-erhöhung" – „automatische Erhöhung"
  • tags → „Etiketten" (aber tag-groups und die meisten Tags, die „tag" enthalten, verwenden „tag"; der auf Crowdin verwendete Begriff ist „Schlagwort")

Abgeschnittene Übersetzungen

Dies ist eine andere Art von Problem – kein Übersetzungsfehler, sondern eine Folge davon, dass deutsche Komposita deutlich länger sind als ihre englischen Entsprechungen, kombiniert mit dem Zeichenlimit für Tags.

  • content-security-policy → „inhalts-sicherheitsrichtl" (abgeschnitten, sollte „inhalts-sicherheitsrichtlinie" sein)
  • ai-custom-prompt → „ai-benutzerdefinierte-auf" (in der Mitte des Wortes abgeschnitten, sollte „ai-benutzerdefinierte-aufforderung" sein)
  • custom-category-boxes → „benutzerdefinierte-katego" (in der Mitte des Wortes abgeschnitten, sollte „benutzerdefinierte-kategorie-boxen" sein; in diesem Fall fehlt „box" vollständig in der Übersetzung)

Tags, die „custom" enthalten, werden leicht zu lang, da „benutzerdefiniert" ein ziemlich langes Wort ist.

weitere Beispiele

Diese Beispiele deuten darauf hin, dass der Übersetzungsprozess mehr Kontext benötigt – idealerweise die Kenntnis, zu welchem Plugin oder welcher Funktion ein Tag gehört, sowie Zugriff auf bestehende Discourse-Oberflächenübersetzungen als Referenz. Ich freue mich zu hören, ob andere ähnliche Muster in anderen Sprachen bemerkt haben.


@nat (auf persönliche Anfrage)


  1. Lernunterlagen ↩︎

6 „Gefällt mir“

Danke @Moin, ich werde mich damit befassen und unsere Prompts verbessern :smiling_face:

Außerdem LOL

Danke für die Lacher :hugs:

4 „Gefällt mir“

@nat, was wäre, wenn wir dem Agenten Zugriff auf das Lesetool geben, damit er den Kontext selbstständig sammeln könnte?

Für Beiträge wäre dies zu kostspielig, aber für einmalige Aufgaben wie Tags und Kategorien wäre es relativ günstig und würde die Qualität bei allen Modellen steigern.

3 „Gefällt mir“

Hmm, das ist eine gute Idee @falco.

Eine andere Möglichkeit, die ich in Betracht gezogen habe, bestand darin, die Beschreibung des Tags als zusätzlichen Kontext zu übergeben, wenn der Tag-Name übersetzt wird. Vielleicht ist diese Methode vorhersehbarer, was denkst du?

4 „Gefällt mir“

Der Zugriff auf das Glossar in Crowdin könnte für den Übersetzungs-Bot sehr hilfreich sein (nicht für alle Seiten, aber besonders für Meta). Wenn dort vermerkt ist, dass wir „composer" als „Editor" übersetzen und die KI dies weiß, könnte sie dies in Tags, aber auch in Themenüberschriften und Beiträgen verwenden.

Ich habe „composer" einmal in Introducing our new composer, making writing on Discourse easier than ever korrigiert, was mein Feedback zum Bearbeiten von Übersetzungen hier zur Folge hatte: Feedback on the composer when translating a post to German. Das Thema wurde jedoch nach meiner Korrektur bearbeitet, und es scheint, dass die vorherige Übersetzung nicht als Kontext verwendet wird, sodass im Beitrag erneut „composer" steht. (Der Komponist von Musik kommt in Beiträgen normalerweise nicht vor; nur kürzere Texte wie Themenüberschriften und Tags.)

Auf Meta fügt die Beschreibung oft nicht viel Kontext hinzu. Alle Beschreibungen für Theme-Komponenten enthalten beispielsweise lediglich einen Link zum Thema der Komponente, nicht aber die kurze Beschreibung aus dem Anfang des Themas.

Gute Idee, lass uns beides machen!

Die Idee ist, Meta als Testumgebung und Proxy für das zu nutzen, was unsere Kunden im echten Einsatz erleben könnten, und so die Funktion für alle zu verbessern.

Eine perfekte Übersetzung auf Meta wäre super einfach, indem man einfach das teuerste LLM verwendet und ihm Zugriff auf Tools wie den Zugriff auf den Quellcode und Websuche gewährt.

Ich glaube nicht, dass irgendein Modell dieselben Übersetzungen für Meta wählen würde, die deutsche Übersetzer für die Discourse-Oberfläche gewählt haben. „Mitarbeiter" ist eine perfekte Übersetzung für „staff". Die Tatsache, dass sich einige Übersetzer vor Jahren entschieden haben, dass dies nicht zu kleinen Hobbyforen passt – wo „staff" bezahlte Angestellte impliziert – und daher „Team" gewählt haben, wird keine KI erraten, da es schlichtweg nicht die korrekte Übersetzung ist. Genau hier würde das Crowdin-Glossar helfen: Ohne es werden KI-generierte Begriffe niemals mit dem übereinstimmen, was Administratoren tatsächlich in der Oberfläche sehen – nicht weil KI nicht übersetzen kann, sondern weil sie nicht dieselben Lokalisierungsentscheidungen trifft wie menschliche Übersetzer. Es ist der Unterschied zwischen Übersetzung und Lokalisierung.
Ähnlich ist es bei anderen Begriffen wie „bootstrap mode" oder „impersonation".

Das würde es tun, da es genau dieselbe Auswahl in den config/locales/**/*.yml-Dateien zur Referenz hätte.

Absolut, und bei kleinen aufzählbaren Gruppen wie Kategorien und Tags würde es dem Agenten helfen, wenn er Zugriff auf die vorhandenen Übersetzungen hätte, die Teil des Quellcodes sind.

Das können wir bei Beiträgen nicht umsetzen, da die Kosten zu hoch wären, aber es ist eine Option für kleinere Seiten oder Kunden mit größeren Übersetzungsbudgets.

Dann solltest du vielleicht die KI-Übersetzung für Documentation und News and Events > Announcements deaktivieren :wink: Ich glaube nicht, dass es möglich ist, sicherzustellen, dass diese Übersetzungen hilfreich sind, besonders da vorgeschlagene Änderungen das Thema nicht nach oben bringen, sodass es keine einfache Möglichkeit gibt, zu bemerken, dass ein Thema aktualisiert wurde.

Im Allgemeinen ist der Grund für meine Empfehlung, die Glossar-Datei anstelle der Dateien mit allen Übersetzungen zu verwenden, der Kostenfaktor. Ich gehe davon aus, dass dort die relevantesten Entscheidungen einmalig enthalten sind, ohne jeden Text aufzunehmen.

So funktioniert es nicht; der Agent kann im Code nach passenden Textteilen suchen und lädt niemals das gesamte Dokument in den Kontext.

Das ist doch ein bisschen wie das Kind mit dem Bade ausschütten, oder?

Ich habe gerade Calendar subscription URLs for external calendar apps auf PT-BR geprüft, und es sieht nach einer großartigen Übersetzung aus, viel besser als gar nichts zu haben.

Es wird immer Verbesserungen an einem unbeaufsichtigten Workflow für maschinelle Übersetzungen geben, und @nat hat dank eurer Rückmeldung heute bereits dafür gesorgt, dass es besser wird!

Niemand erwartet Perfektion, und Meta ist ein Ort, an dem wir Funktionen frühzeitig einsetzen und zeigen können, was in Discourse für unsere Nutzer und Kunden möglich ist.