Übersetzungsqualität und SEO

Auf dieser Seite wird die Aussage überprüft. Sie behandelt, was Docsbook tatsächlich über eine Übersetzung misst, wie man eine Übersetzung korrigiert, was Suchmaschinen und KI-Assistenten mit übersetzter Dokumentation machen und – am Ende – was maschinelle Übersetzung in technischer Prosa immer noch falsch macht, mit einer Quelle.

Was Docsbook misst und was nicht#

Docsbook veröffentlicht keinen Wert für die Übersetzungsqualität. Es gibt keinen BLEU-, COMET- oder TER-Wert und keine Bewertung durch Menschen für Ihre Seiten, und diese Dokumentation wird keinen solchen Wert erfinden. Stattdessen misst das Produkt Abdeckung und Aktualität: ob eine Seite in einer Sprache vorhanden ist und ob sie auf Grundlage der Version der Quelle erstellt wurde, die derzeit live ist.

Das ist eine engere Aussage als „unsere Übersetzungen sind gut“ – und es ist eine Aussage, die überprüft werden kann.

Abdeckung und Aktualität#

Jede gespeicherte Übersetzung enthält die Git-Blob-SHA der Quelldatei, aus der sie erstellt wurde. Die Abdeckung wird berechnet, indem der Repository-Baum bei HEAD gelesen und pro Pfad verglichen wird:

Die Abdeckung ist (current + manual) / total. Eine Sprache ist synchron, wenn behind und missing beide null sind. Wenn Ihr Repository nicht gelesen werden kann, ist die Abdeckung null – niemals eine verlässliche Null –, sodass eine durch Ratenbegrenzung eingeschränkte GitHub-Abfrage eine gesunde Sprache niemals als problematisch markieren kann.

Lesen#

• Im Panel. Jede Sprache hat ihre eigene Seite: einen Abdeckungsprozentsatz über einem nach der Art der Lücke unterteilten Balken, den Commit, auf dem sich Ihre Dokumentation derzeit befindet, einen Live-Fortschrittsbalken mit dem Namen der Person, die den laufenden Durchlauf gestartet hat, die letzten zwölf Durchläufe, farblich danach gekennzeichnet, wie sie jeweils endeten, und – wenn ein Durchlauf vorzeitig beendet wurde – den Grund in Worten. Darunter finden Sie Ihre Commits, die neuesten zuerst, jeweils mit einer Einschätzung, wie der Stand ihrer Seiten in dieser Sprache ist. So können Sie beispielsweise überprüfen, ob „die Überarbeitung der Preisseite am Dienstag veröffentlicht wurde“, anstatt dies anhand eines Dateinamens herausfinden zu müssen.
• Über MCP. get_translation_status liefert genau dies für jede Sprache: current / behind / missing / manual / orphaned, den Prozentsatz, in_sync, ob gerade ein Durchlauf läuft und wie weit er fortgeschritten ist, sowie was der letzte Durchlauf getan hat – einschließlich des Agenten-Durchlaufs, der ihn gestartet hat. Die Beschreibung des Tools selbst weist einen Aufrufer an, dies vor run_translation_pass zu lesen, da eine Sprache, die bereits auf dem Stand der Quelle ist, durch eine erneute Übersetzung Kosten verursacht und nichts verändert.
• Per Webhook. translation.needed wird ausgelöst, wenn eine Seite in einer aktivierten Sprache gerade übersetzt werden soll, translation.completed, wenn sie dauerhaft gespeichert wurde, und translation.outdated, wenn eine Übersetzung hinter ihre Quelle zurückfällt. translation.completed wird nur ausgelöst, wenn die Seite tatsächlich gespeichert wurde. Dadurch wird ein Listener, der ein CMS neu indiziert, niemals über eine Übersetzung informiert, die nicht existiert.

Die eine Zahl, die ein Vergleich ist, keine Messung#

Die Zahl Ersparnis im Übersetzungs-Dashboard gibt an, was ein menschlicher Übersetzer für dieselben Zeichen zu einem Satz von 5,00 $ pro 1.000 Zeichen berechnet hätte, abzüglich der tatsächlichen Kosten der KI-Übersetzung. Zwei Dinge dazu:

• Sie wird bewusst pro Zeichen, nicht pro Wort berechnet. Eine Wortanzahl ist eine Eigenschaft der Zielsprache — im Chinesischen und Japanischen gibt es keine durch Leerzeichen getrennten Wörter — daher fällt eine Messung pro Wort für genau die Sprachen, die sie messen sollte, nahezu auf null.
• Sie ist eine hypothetische Vergleichsgröße, keine Rechnung. Niemand hat einen der beiden Beträge bezahlt. Der Satz ist in Docsbook eine feste Konstante, kein Angebot, das Sie erhalten haben. Betrachten Sie die Zahl als Größenordnung.

Kann ich eine Übersetzung korrigieren, und bleibt die Korrektur erhalten?#

Sie können eine Übersetzung korrigieren, und die Korrektur ist davor geschützt, durch einen späteren Durchlauf überschrieben zu werden — dieser Teil wird bereits beim Schreiben in die Datenbank erzwungen. Ob den Lesern dann Ihr korrigierter Text ausgeliefert wird, ist eine separate Frage, und die ehrliche Antwort folgt weiter unten.

So korrigieren Sie eine Übersetzung. Bearbeiten Sie die Übersetzung im Übersetzungsbereich oder senden Sie sie mit upload_translation. Uploads kommen als Entwurf an; list_pending_translations zeigt die Entwürfe an und approve_translation veröffentlicht einen davon. Durch das Bearbeiten des Inhalts einer Übersetzung wird die Zeile als manueller Upload markiert.

Warum sie einen Durchlauf übersteht. Automatische Durchläufe schreiben über ein Datenbank-Upsert, dessen Konfliktklausel nur Zeilen überschreibt, deren Ursprung docsbook_ai ist. Eine als manueller Upload markierte Zeile wird von diesem Schreibvorgang übersprungen, und die Abdeckung zählt sie als manual — ein Zustand, der niemals „veraltet“ ist, denn die Aktualität einer von einer Person verfassten Seite liegt im Ermessen dieser Person und nicht in einem Hash-Vergleich. Das Ersetzen einer aktiven KI-Übersetzung auf diese Weise gibt dem Aufrufer außerdem replaced_ai_translation: true zurück, sodass ein Agent einen Menschen warnen kann, dass gerade etwas ersetzt wurde, das Leser bereits gesehen haben.

Offene Frage. In der Dokumentation von Docsbook hieß es, dass Docsbook nach dem Hochladen einer Korrektur „von da an Ihre Version ausliefert“. Was überprüfbar ist: Die korrigierte Zeile wird gespeichert, von einem späteren automatischen Durchlauf niemals überschrieben (die Konfliktklausel des Upserts schreibt nur über Zeilen hinweg, deren Ursprung docsbook_ai ist), und bei der Abdeckung als manual statt als veraltet gezählt. Was nicht überprüfbar ist: dass sie den Lesern ausgeliefert wird. Betrachtet man den derzeitigen Code, sprechen drei Dinge dagegen. Die leserorientierte Seite liest eine Übersetzung aus dem Hot-Cache und bei einem Fehlschlag aus gespeicherten Zeilen, die auf origin = 'docsbook_ai' gefiltert sind. Derselbe Filter entscheidet, ob eine Sprache zum hreflang-Cluster dieser Seite gehört und ob ihre URL in die Sitemap aufgenommen wird. Und der Cache-Invalidierungspfad stellt ausdrücklich fest, dass manuelle und externe Zeilen „niemals SSR-Redis-Seitenschlüssel schreiben“, sodass auch für den ersten Lesezugriff keine zwischengespeicherte Kopie vorhanden ist. Eine manuell hochgeladene oder von Hand bearbeitete Zeile erfüllt keine dieser Bedingungen. Wir haben keine Messung veröffentlicht, die belegt, dass eine korrigierte Seite ausgeliefert wird, und der derzeitige Mechanismus lässt dies nicht erwarten — betrachten Sie manuelle Uploads daher als Möglichkeit, eine Seite vor einer erneuten Übersetzung zu schützen und eine externe Pipeline anzustoßen, nicht als Möglichkeit, zu ändern, was ein Leser sieht. Wenn ein bestimmter Satz für Sie heute falsch ist, besteht die zuverlässige Lösung darin, die Quellseite zu ändern und sie durch den Durchlauf erneut übersetzen zu lassen.

Genau diese Art von Behauptung verlangt unsere Belegregel von uns zu kennzeichnen, statt sie stillschweigend zu löschen.

Was Suchmaschinen mit übersetzter Dokumentation machen#

Separate URLs pro Sprache und ein seitenweiser hreflang-Cluster#

Jede Sprache hat ihren eigenen URL-Pfad — niemals eine Subdomain und niemals einen Query-Parameter. Darüber hinaus gibt jede Dokumentationsseite eine hreflang-Menge als <link rel="alternate">-Alternativen aus, zusätzlich zu x-default und en, die auf die URL der Originalsprache verweisen.

Die Regel, die dies ermöglicht, ist die Gegenseitigkeit, und sie wird pro Seite und nicht pro Website durchgesetzt:

Docsbook erstellt den Canonical und die Alternativen mit derselben Funktion, die auch die URL routet. Dadurch ist die beworbene Adresse diejenige, die mit 200 antwortet, statt eine Weiterleitung auszulösen — ein Canonical, das auf eine Weiterleitung verweist, wird von Google verarbeitet, indem die Seite verworfen wird.

Unter derselben Regel greift noch ein weiterer Mechanismus. Google sagt ausdrücklich, dass es „den sichtbaren Inhalt Ihrer Seite verwendet, um deren Sprache zu bestimmen“ und „keine Informationen zur Sprache auf Codeebene wie lang-Attribute oder die URL verwendet“ — eine vollständig übersetzte Seite, die dennoch ein englisches <title> ausliefert, sendet daher ihr stärkstes On-Page-Signal in der falschen Sprache. Docsbook gewinnt den Titel aus dem bereits gespeicherten übersetzten HTML zurück, indem es das eigene übersetzte <h1> dieser Seite liest, ohne einen zusätzlichen Modellaufruf. Die Meta-Beschreibung bleibt in diesem Fall bewusst im Original: Eine Übersetzung dafür zu erfinden, ist keine Aufgabe, die ein Metadaten-Build übernehmen darf, und ein korrekter Titel zusammen mit einer Beschreibung in der Originalsprache ist besser, als wenn beides falsch wäre.

Warum jede dieser Regeln die richtige ist#

Beachten Sie, was die vorletzte Zeile in Bezug auf gültige Tags impliziert: es-419 ist ein vollkommen gültiges BCP-47-Tag — das W3C verwendet es als ausgearbeitetes Beispiel — und Google akzeptiert es in hreflang ausdrücklich nicht. Ein gültiger Sprach-Tag und ein gültiger hreflang-Wert sind nicht dieselbe Menge.

Verstößt maschinelle Übersetzung gegen Googles Richtlinien?#

Nein – und die Antwort ist genauer als jede der beiden Seiten der üblichen Debatte, daher lohnt es sich, sie genau richtig zu verstehen.

Übersetzte Seiten sind keine Duplikate. Google beschreibt die Grenze in einem Satz: „Lokalisierte Versionen einer Seite werden nur dann als Duplikate betrachtet, wenn der Hauptinhalt der Seite nicht übersetzt wurde.“ Eine vollständig übersetzte Seite ist eine eigenständige Seite. Eine Locale-URL, die den ursprünglichen Inhalt ausliefert, ist ein Duplikat – deshalb setzt Docsbook in diesem Fall das Canonical auf das Original, statt die Seite als Alternative zu veröffentlichen. Und in Bezug auf Duplikate im Allgemeinen lautet Googles langjährige Position: „Doppelter Inhalt auf einer Website ist kein Grund für Maßnahmen gegen diese Website, es sei denn, es scheint, dass der Zweck des doppelten Inhalts darin besteht, zu täuschen und Suchmaschinenergebnisse zu manipulieren“ (Die Strafe für doppelten Inhalt entmystifiziert, 2008).

Die alte Regel „maschinelle Übersetzung ist Spam“ gilt nicht mehr. Googles Spam-Richtlinien enthalten überhaupt keinen Punkt zu maschineller Übersetzung – die Begriffe „maschinelle Übersetzung“ und „automatisch übersetzt“ erscheinen auf der Seite nicht. Was dort steht, ist der Missbrauch durch Inhalte in großem Maßstab, definiert als „das Erstellen großer Mengen nicht origineller Inhalte, die Nutzern wenig oder keinen Mehrwert bieten, unabhängig davon, wie sie erstellt werden“. Das Wort Übersetzen findet sich nur in einem Beispiel für Scraping innerhalb derselben Richtlinie: „Das Scraping von Feeds, Suchergebnissen oder anderen Inhalten, um viele Seiten zu generieren (einschließlich durch automatisierte Transformationen wie das Ersetzen durch Synonyme, Übersetzen oder andere Verschleierungstechniken), wobei Nutzern wenig Mehrwert geboten wird“. Googles Änderungsprotokoll dokumentiert die Bereinigung vom 11. Juni 2025: „Wir haben einen Abschnitt aus unserer mehrsprachigen Dokumentation entfernt, in dem die Verwendung der robots.txt zum Blockieren aller automatisch übersetzten Seiten beschrieben wurde“, „um unsere Aktualisierung der Spam-Richtlinien vom März 2024 widerzuspiegeln“ (Aktualisierungen der Search-Central-Dokumentation).

Die aktuelle Position hängt von der Qualität ab, nicht von der Methode. Auf die direkte Frage, ob automatische Übersetzung das Ranking beeinträchtigt, antwortete Gary Illyes: „wenn die automatische Übersetzung von geringer Qualität ist, vielleicht“, und empfahl Websites, „sicherzustellen, dass ein Muttersprachler der jeweiligen Sprache die Übersetzungen überprüft (und möglicherweise korrigiert)“. In derselben Sitzung stellte John Mueller fest, dass es „kein spezielles Markup gibt, das Sie Ihren Seiten hinzufügen können“, um anzugeben, dass eine Übersetzung maschinell erstellt wurde, dass entscheidend ist, ob „die Seiten gut übersetzt sind“, dass „eine gute Lokalisierung viel mehr ist als nur eine Übersetzung von Wörtern und Sätzen“ und dass minderwertige Ausgaben ein Fall sind, in dem „Sie einfach das noindex-Robots-Meta-Tag auf ihnen einbinden könnten“ (Google SEO Office Hours, Juni 2024).

Die praktische Schlussfolgerung für ein Dokumentationsteam:

• Bestraft wird Umfang ohne Mehrwert, nicht das verwendete Tool. Die Übersetzung von hundert Dokumentationsseiten, die Ihre Leser tatsächlich benötigen, ist kein Missbrauch durch Inhalte in großem Maßstab; das Generieren von Locale-Seiten, nach denen niemand gefragt hat, schon.
• Die Überprüfung ist die von Google benannte Variable. Docsbook stellt Ihnen die entsprechenden Möglichkeiten bereit – die sprachspezifische Abdeckungsseite, list_pending_translations mit approve_translation und den external-Modus, um jede Seite vor der Veröffentlichung durch Ihre eigene Pipeline zu leiten – und zwingt Sie nicht, sie zu verwenden. Der auto-Modus veröffentlicht die Inhalte direkt während der Verarbeitung. Entscheiden Sie sich bewusst.
• Die günstigste sinnvolle Überprüfung besteht nicht darin, jede Seite zu prüfen. Es sind die Seiten, die für Ihren Umsatz entscheidend sind: der Schnellstart, alles in der Nähe von Preisinformationen, die meistbesuchten Seiten für diese Sprache in Ihrer Analyse sowie alles, bei dem eine falsch übersetzte Anweisung die Einrichtung eines Lesers verhindert. Wenn eine Sprache schlecht lesbar ist und Sie das nicht korrigieren werden, ist noindex eine zulässige Antwort.

Was KI-Assistenten damit machen#

Nichts Besonderes – und genau darum geht es. Eine generative Engine ruft dasselbe statische HTML ab, das ein Crawler liest. Durch das Öffnen einer Sprache werden Seiten in dieser Sprache erstellt, die ein Assistent abrufen und zitieren kann, wenn die Frage in dieser Sprache gestellt wird – was ein Korpus, das nur die Originalsprache enthält, nicht sein kann. Docsbook indiziert den übersetzten Text zusätzlich für die seiteninterne Volltextsuche unter dem jeweiligen Sprachcode, sodass Leser, die auf Deutsch suchen, deutsche Seiten statt der englischen Quelle finden. Siehe GEO für Informationen darüber, was der Seite selbst hinzugefügt wird.

Grenzen — was maschinelle Übersetzung in technischen Dokumentationen immer noch falsch macht#

Nehmen Sie diesen Abschnitt genauso ernst wie den Rest der Seite.

• Die Konsistenz der Terminologie wird nicht verwaltet, und das ist der nachweislich schwache Punkt des gesamten Bereichs. Docsbook verfügt über kein Glossar, keine Terminologiedatenbank und keine Liste von Begriffen, die Sie von der Übersetzung ausschließen können. Die Konsistenz beruht auf drei schwächeren Quellen: Anfragen werden mit Temperatur 0 ausgeführt, ein nicht bearbeiteter Abschnitt wird unverändert aus dem Cache ausgeliefert und kann daher nicht abweichen, und Navigationsbeschriftungen sowie Titel/Beschreibung werden als Gruppen übersetzt. Zwei verschiedene Seiten, die denselben Begriff verwenden, wurden unabhängig voneinander übersetzt und können voneinander abweichen.

  Wie wichtig das ist, wurde gemessen. Moslem et al. („Integration von Domänenterminologie in die maschinelle Übersetzung: Nutzung großer Sprachmodelle“, WMT 2023, arXiv:2310.14451) berichten, dass in Blinddatensätzen für DE-EN, EN-CS und ZH-EN „die Anzahl der in die Übersetzungen des Blinddatensatzes aufgenommenen Begriffe von durchschnittlich 36,67 % beim generischen Modell auf durchschnittlich 72,88 % am Ende des Prozesses steigt“ — „die erfolgreiche Nutzung von Begriffen verdoppelt sich über die drei Sprachpaare hinweg nahezu“. Lesen Sie die Metrik genau: Sie zählt, ob der erforderliche Begriff verwendet wurde, und 72,88 % sind das Ergebnis eines vierstufigen, eigens dafür entwickelten Prozesses, nicht eines allein stärkeren Modells.

  Die WMT25-Terminologie-Shared-Task beziffert die andere Seite derselben Medaille. Die Daten für Track 1 wurden von SAP aus seinem Online-Hilfeportal erstellt (EN→DE/RU/ES, 500 Testinstanzen pro Sprachpaar, 20 Systeme von 13 Teams), und „starke Systeme erreichen eine sehr hohe Terminologiegenauigkeit von über 97 %“ — jedoch nur, wenn dem System zum Zeitpunkt der Inferenz das richtige Glossar übergeben wird, und genau diese Eingabe hat Docsbook nicht. Die Aufgabe führt dieselben Systeme außerdem mit einem zufälligen Wörterbuch und ohne Wörterbuch aus: Das beste System erreicht 99,1 mit dem richtigen Glossar, 49,2 mit einem zufälligen und 44,4 ohne Glossar. Bei längeren Texten wird berichtet, dass „Systeme häufig hinter den Erwartungen zurückbleiben“ und dass „der Dokument-Track weiterhin eine anspruchsvollere Aufgabe darstellt“. Lesen Sie daraus: Die Terminologietreue wird gezielt entwickelt, nicht automatisch übernommen, und Docsbook hat sie bisher noch nicht gezielt entwickelt.

  Der allgemeine Rahmen ist derselbe. Die allgemeine Übersetzungsaufgabe WMT24 (Kocmi et al.), bei der Übersetzungen von „8 verschiedenen großen Sprachmodellen (LLMs) und 4 Online-Übersetzungsanbietern“ für 11 Sprachpaare gesammelt wurden, trägt den Titel „Das LLM-Zeitalter ist da, aber maschinelle Übersetzung ist noch nicht gelöst“. Die Domänen sind Nachrichten, Literatur, Sprache und soziale Medien — keine technischen Dokumentationen —, daher sollten Sie sie für „nicht gelöst“ zitieren und die beiden oben genannten Quellen für Aussagen über Domänentexte. Die Testsuiten weisen zwar ebenfalls auf Schwächen bei der Terminologie hin, aber nur in einem engen Rahmen: Der Satz bezieht sich auf eine Übersetzungsrichtung und ein System, „Für Englisch-Russisch ist Yandex bei benannten Entitäten und Terminologie schwächer“, und ist keine allgemeine Erkenntnis über LLM-Übersetzungen.

• Nackte Bezeichner im Fließtext werden nur durch eine Anweisung geschützt. Code innerhalb von Blöcken und Backticks wird aus der Anfrage entfernt und Byte für Byte wiederhergestellt — das ist mechanisch. Ein als gewöhnlicher Fließtext ohne Backticks geschriebener Parametername erreicht das Modell und bleibt nur deshalb in der Ausgangssprache, weil der Prompt dies vorgibt. Die Kennzeichnung von Bezeichnern als Code ist das Wertvollste, was Sie für Ihre eigenen Übersetzungen tun können. Wir haben nach einer veröffentlichten Messung gesucht, wie häufig LLM-Übersetzungen speziell Code-Bezeichner verfälschen, aber keine gefunden; die nächstliegende veröffentlichte Evidenz ist die oben zitierte Terminologiearbeit. Betrachten Sie das Ausmaß dieses Risikos als ungemessen und nicht als gering.

• Bildtext in alt wird nicht übersetzt. Es handelt sich um ein HTML-Attribut, und die Regel, die href und id schützt, schützt auch alt.

• Docsbook hat keine eigene Messung veröffentlicht. Keine Genauigkeitszahl, keine Fehlerquote, kein Ranking nach Sprache. Wenn Sie eine solche Zahl für Ihren Korpus benötigen, besteht der ehrliche Weg darin, eine Stichprobe Ihrer eigenen Seiten von einer sprachkundigen Person prüfen zu lassen — und die Abdeckung zeigt Ihnen, welche Seiten sich für eine Stichprobe lohnen.

• Das Modell kann sich ändern, ohne dass Sie etwas dagegen tun können. Das standardmäßige Übersetzungsmodell ist eine Konfigurationskonstante, und über die Auswahlfunktion können Sie es ändern. Eine Seite, die letzten Monat übersetzt wurde, wurde mit dem damals ausgewählten Modell übersetzt; nichts übersetzt eine Seite erneut, nur weil sich das Modell verbessert hat.

• Regionale Varianten werden nicht modelliert. Ein pt für Brasilien und Portugal, ein zh für vereinfachtes und traditionelles Chinesisch. Bei Produkten, für die diese Unterscheidung verkaufsentscheidend ist, handelt es sich um eine echte Einschränkung und nicht um einen Rundungsfehler.

Verwandte Themen#

• KI-Übersetzungen — die Pipeline selbst: Aufteilung in Abschnitte, Schutz, Fehlerbehandlung
• Übersetzungseinstellungen — Aktivieren einer Sprache, das Modell, der Modus, Locale-URLs
• SEO — kanonische URLs, Sitemap und strukturierte Daten auf jeder Seite
• GEO — was eine Seite für einen Assistenten zitierfähig macht
• Wie Docsbook seine Aussagen belegt — die Regel, nach der diese Seite verfasst ist