Engineering//9 Min. Lesezeit

Hinter den Kulissen des AI Translation Tools: Wie 23 Agent-Tools und Human-in-the-Loop-Genehmigung die Übersetzungsqualität hochhalten

Eray Gündoğmuş
Teilen

Die meisten AI-Übersetzungstools folgen demselben Muster: Text einfügen, Übersetzung erhalten. Das funktioniert für eine schnelle E-Mail, aber es scheitert, wenn man Tausende von Übersetzungsschlüsseln in einer Produktionsanwendung mit mehreren Sprachen, einem Glossar mit Markentermini und einem Team verwaltet, das Änderungen vor dem Deployment prüfen muss.

Wir haben das AI-System von Better i18n anders aufgebaut. Anstelle einer einfachen Übersetzungs-API haben wir einen konversationsbasierten Agent mit 23 spezialisierten Tools, Human-in-the-Loop-Genehmigung für jeden Schreibvorgang und einer Architektur entwickelt, die für reale Übersetzungsmanagement-Workflows ausgelegt ist.

Dieser Beitrag erläutert die technischen Grundlagen dahinter.

Warum ein Agent und keine Übersetzungs-API?

Der typische maschinelle Übersetzungs-Review-Workflow sieht so aus: Strings exportieren, an einen Übersetzungsservice senden, Ergebnisse zurückerhalten, importieren, manuell prüfen, Probleme beheben, re-exportieren. Das ist langsam, fehleranfällig und trennt den Übersetzungsprozess von dem Kontext, der Übersetzungen präzise macht.

Ein agentbasierter Ansatz verändert das Modell grundlegend. Anstatt auf Dateien zu arbeiten, arbeitet die AI direkt auf Ihrem Projekt — liest Ihre Schlüssel, versteht Ihr Glossar, prüft Ihre Sync-Konfiguration und schlägt Änderungen vor, die Sie in Echtzeit genehmigen.

Die wichtigste Erkenntnis: Übersetzungsmanagement ist keine einzelne Aufgabe. Es ist ein Workflow, der das Lesen des Projektstatus, das Treffen von Entscheidungen, das Ausführen von Änderungen und das Verifizieren von Ergebnissen umfasst. Ein Agent mit mehreren Tools bewältigt das auf natürliche Weise. Eine Übersetzungs-API nicht.

Die 23-Tool-Architektur

Der Agent hat Zugriff auf 23 zweckgebundene Tools, aufgeteilt in zwei Kategorien mit sehr unterschiedlichen Berechtigungsmodellen.

Lese-Tools: Volle Autonomie

Zehn Tools geben dem Agent Lesezugriff auf Ihr Projekt. Diese werden automatisch ohne Genehmigung ausgeführt, da sie keine Daten ändern können:

  • getTranslations — ruft Übersetzungen mit Filterung nach Schlüssel, Namespace, Sprache und Status ab
  • getKeyDetails — ruft Metadaten für einzelne Schlüssel ab, einschließlich Kontextnotizen, Tags und sprachspezifischem Status
  • getLanguages — listet konfigurierte Sprachen mit Vervollständigungsprozentsätzen auf
  • getProjectStats — gibt projektweite Metriken zurück: Gesamtschlüssel, Sprachen, Übersetzungsabdeckung
  • getDoctorReport — führt Diagnosen durch, um fehlende Übersetzungen, ungenutzte Schlüssel, Pluralformprobleme und Terminologieinkonsistenzen zu identifizieren
  • getSyncs und getSyncDetails — untersucht GitHub/GitLab-Sync-Integrationen und deren jüngste Aktivität
  • getContentModels und getContentEntries — durchsucht CMS-Inhaltsstruktur und -einträge
  • createPlan — erstellt einen Ausführungsplan, wenn der Agent mehrere Schritte koordinieren muss

Der Agent verwendet diese Tools, um Kontext aufzubauen, bevor er Änderungen vorschlägt. Wenn Sie fragen „alle fehlenden Schlüssel ins Französische übersetzen", ruft der Agent zuerst getTranslations auf, um genau zu identifizieren, welche Schlüssel fehlen, dann getProjectStats, um den Umfang zu verstehen, bevor er einen einzigen gezielten Vorschlag erstellt.

Schreib-Tools: Human-in-the-Loop-Genehmigung

Elf Tools können Ihre Projektdaten ändern. Jedes einzelne davon erfordert eine ausdrückliche menschliche Genehmigung vor der Ausführung. Das ist der Kern unseres Ansatzes zur AI-Übersetzungsqualität — die AI schlägt vor, der Mensch entscheidet.

Übersetzungs-Tools:

  • proposeTranslations — generiert neue Übersetzungen für Schlüssel, die in Zielsprachen fehlen
  • proposeTranslationEdits — schlägt Verbesserungen bestehender Übersetzungen basierend auf Kontext, Glossar oder Ihrem Feedback vor
  • translateBatch — verarbeitet mehrere Schlüssel in mehreren Sprachen in einem einzigen Vorgang

Schlüsselverwaltungs-Tools:

  • proposeKeys — schlägt neue Übersetzungsschlüssel basierend auf der Codebase-Analyse vor
  • proposeDeleteKeys — identifiziert ungenutzte oder doppelte Schlüssel und schlägt Bereinigung vor

Sprachverwaltungs-Tools:

  • proposeLanguages — empfiehlt neue Sprachen, die basierend auf Projektanforderungen hinzugefügt werden sollen
  • proposeLanguageEdits — ändert Sprachanzeigenamen, Fallback-Ketten oder Konfiguration

Publishing-Tools:

  • publishChanges — überträgt genehmigte Übersetzungen an das CDN oder löst einen GitHub-PR aus

Content-Management-Tools:

  • proposeContentEntries — erstellt oder aktualisiert CMS-Inhaltseinträge
  • proposeContentModel — schlägt Schemaänderungen an Content-Modellen vor
  • proposePublishEntries — stellt Inhaltseinträge zur Veröffentlichung in die Warteschlange

Human-in-the-Loop: Der Genehmigungsflow im Detail

Der Begriff „Human-in-the-Loop" wird in der AI-Vermarktung oft verwendet. Hier ist, wie er in unserem System tatsächlich funktioniert.

Wenn ein Schreib-Tool aufgerufen wird, führt der Agent es nicht direkt aus. Stattdessen generiert er einen Vorschlag — ein strukturiertes Diff, das genau zeigt, was sich ändern wird. Der Vorschlag erscheint in der Chat-Oberfläche als überprüfbares Artefakt.

Bei Übersetzungsvorschlägen sehen Sie:

  • Den Quellstring in Ihrer Basissprache
  • Die vorgeschlagene Übersetzung in der Zielsprache
  • Alle angewendeten Glossarterminologien
  • Den Konfidenzkontext (ist das ein einfaches UI-Label oder ein komplexer Marketingsatz?)

Sie haben dann drei Optionen:

  1. Alle genehmigen — alle vorgeschlagenen Änderungen mit einem Klick akzeptieren
  2. Selektive Genehmigung — einige Übersetzungen akzeptieren und andere ablehnen
  3. Änderungen anfordern — dem Agent mitteilen, was zu korrigieren ist, und er erstellt einen überarbeiteten Vorschlag

Erst nach der Genehmigung wird der Schreibvorgang ausgeführt. Das ist kein „Bestätigen/Abbrechen"-Dialog — es ist ein echter Überprüfungsschritt, bei dem Sie prüfen, bearbeiten und iterieren können.

Warum das für die AI-Übersetzungsqualität wichtig ist

Die maschinelle Übersetzungsprüfung ist der Engpass in den meisten Lokalisierungs-Workflows. Teams überspringen entweder die Prüfung (und liefern Fehler aus) oder prüfen alles manuell (und kommen langsam voran). Unser HITL-Ansatz trifft die goldene Mitte:

  • Die AI übernimmt die 80 % der Übersetzungen, die unkompliziert sind
  • Menschen konzentrieren ihren Prüfaufwand auf die 20 %, die Urteilsvermögen erfordern
  • Jede Übersetzung hat eine klare Herkunft: AI-generiert, menschlich geprüft oder menschlich bearbeitet
  • Der Audit-Trail zeichnet auf, wer was genehmigt hat, was die Compliance unkompliziert macht

Progressive Rendering: Streaming-Übersetzungstabellen

Wenn der Agent Übersetzungen für eine Gruppe von Schlüsseln generiert, erscheinen die Ergebnisse nicht auf einmal. Die Übersetzungstabelle streamt progressiv in die Chat-Oberfläche — jede Zeile wird gerendert, sobald ihre Übersetzung abgeschlossen ist.

Das ist eine ingenieurstechnische Entscheidung, die von der Benutzererfahrung getrieben wird. Wenn Sie 150 Schlüssel in 6 Sprachen übersetzen, sind das 900 einzelne Übersetzungen. Auf alle 900 zu warten, bevor etwas angezeigt wird, würde bedeuten, minutenlang auf einen Ladekreisel zu starren. Progressive Rendering ermöglicht es Ihnen, sofort mit der Überprüfung der ersten Ergebnisse zu beginnen.

Die Implementierung verwendet Server-sent Events, um Tool-Ergebnisse zurück an die Chat-Oberfläche zu streamen. Das Frontend verwaltet eine veränderliche Übersetzungstabellen-Komponente, die Zeilen anfügt, sobald sie eintreffen.

Kontextverwaltung: Geerdet bleiben

Große Sprachmodelle neigen dazu, in langen Gesprächen den Kontext zu verlieren. Wir begegnen dem mit drei Mechanismen:

30-Sekunden-Projektkontexts-Cache

Wenn der Agent Ihre Projektdaten liest, werden die Ergebnisse 30 Sekunden lang gecacht. Wenn der Agent während einer mehrstufigen Operation mehrfach auf Ihren Projektstatus verweisen muss, trifft er den Cache statt redundante API-Aufrufe zu machen. Das reduziert die Latenz und verhindert, dass der Agent während eines komplexen Workflows einen inkonsistenten Zustand sieht.

Kontext-Stripping (slimToolResults)

Tool-Antworten von der Better i18n API können groß sein — ein Projekt mit 2.000 Schlüsseln und 12 Sprachen generiert erhebliche Payloads. Das slimToolResults-System entfernt automatisch nicht-essentielle Daten aus Tool-Antworten, bevor sie in den Gesprächskontext eingehen.

Wenn der Agent beispielsweise getTranslations aufruft, enthält die vollständige Antwort Metadaten wie Erstellungszeitstempel, Versions-IDs und Benutzerzuordnungen. Der slimToolResults-Durchlauf behält nur die Daten, die der Agent benötigt: Schlüsselnamen, Quellstrings und Übersetzungen. Das reduziert den Token-Verbrauch erheblich und verhindert Context-Window-Überlauf.

50-Schritt-Gesprächslimit

Jedes Gespräch unterstützt bis zu 50 Agent-Schritte (Tool-Aufrufe). Das reicht für komplexe Workflows — einen gesamten Namespace übersetzen, die Ergebnisse prüfen, Bearbeitungen vornehmen und veröffentlichen — während Endlosschleifen verhindert werden. Der Schrittzähler ist in der UI sichtbar, sodass Sie immer wissen, wie viel Kapazität noch verbleibt.

Chat-Verlauf: Dual-Storage-Architektur

Agent-Gespräche werden gleichzeitig an zwei Orten gespeichert:

  • IndexedDB (browserlokal) — ermöglicht sofortiges Laden von Gesprächen ohne Netzwerklatenz, wenn Sie zum Dashboard zurückkehren
  • Postgres (serverseitig) — führt einen dauerhaften, durchsuchbaren Audit-Trail jeder Agent-Interaktion

Der Dual-Storage-Ansatz löst zwei konkurrierende Anforderungen. Entwickler wollen sofortigen Zugriff auf aktuelle Gespräche (IndexedDB liefert Sub-Millisekunden-Lesevorgänge). Teams benötigen Audit-Trails für Compliance und Wissensaustausch (Postgres bietet dauerhaften, abfragbaren Speicher).

Wenn Sie den AI-Chat öffnen, werden Gespräche sofort aus IndexedDB geladen. Die Postgres-Kopie synchronisiert sich im Hintergrund und dient als Source of Truth, wenn der lokale Speicher gelöscht wird.

Realer Workflow: Koreanisch zu einer Produktions-App hinzufügen

Hier ist ein konkretes Beispiel, wie der Agent eine echte Aufgabe bewältigt.

Schritt 1: Sie fragen„Ich muss Koreanisch zum Projekt hinzufügen. Übersetze alles in den Namespaces common und settings."

Schritt 2: Agent liest — Er ruft getLanguages auf (sieht, dass Koreanisch nicht konfiguriert ist), getTranslations für den common-Namespace (findet 89 Schlüssel) und getTranslations für den settings-Namespace (findet 34 Schlüssel). Gesamt: 123 zu übersetzende Schlüssel.

Schritt 3: Agent schlägt Spracherweiterung vor — Er ruft proposeLanguages auf, um Koreanisch (ko) zum Projekt hinzuzufügen. Sie sehen den Vorschlag und genehmigen ihn.

Schritt 4: Agent übersetzt in Batches — Er ruft translateBatch für den common-Namespace auf, dann den settings-Namespace. Übersetzungen streamen progressiv in den Chat. Sie sehen die koreanischen Übersetzungen neben den englischen Quellstrings erscheinen.

Schritt 5: Sie prüfen — Sie scannen die Übersetzungen, markieren zwei, die für eine informelle App-UI einen zu formellen Register verwenden, und sagen dem Agent, diese anzupassen.

Schritt 6: Agent überarbeitet — Er ruft proposeTranslationEdits mit Ihrem Feedback auf und generiert überarbeitete Übersetzungen für die beiden markierten Strings. Sie genehmigen.

Schritt 7: Sie veröffentlichen — Sie sagen dem Agent zu veröffentlichen, er ruft publishChanges auf, und die koreanischen Übersetzungen sind live auf dem CDN.

Gesamtzeit: etwa 10 Minuten für 123 Übersetzungen, geprüft und veröffentlicht. Ohne den Agent erfordert dieser Workflow typischerweise stundenlange Export-Übersetzen-Import-Prüf-Zyklen.

Was wir bewusst nicht gebaut haben

Transparenz über Einschränkungen ist genauso wichtig wie Feature-Dokumentation.

  • Keine proprietäre Übersetzungs-Engine — wir verwenden Google Gemini als zugrunde liegendes Modell. Wir beanspruchen keine benutzerdefinierte „neuronale Übersetzungs-Engine" oder proprietäre AI.
  • Kein automatisiertes A/B-Testing von Übersetzungen — Sie wählen das Modell; es gibt kein Framework zum Vergleich von Ausgaben mehrerer Modelle.
  • Kein Translation Memory — wir verwenden glossarbasierte Termkonsistenz, kein TM-Fuzzy-Matching. Wenn Sie TM benötigen, ist Better i18n heute nicht das richtige Tool.
  • Keine garantierten Genauigkeitsmetriken — die AI-Übersetzungsqualität variiert je nach Sprachpaar und Inhaltstyp. Wir empfehlen menschliche Prüfung für alle kundenseitigen Inhalte, was genau der Grund ist, warum HITL in jeden Schreibvorgang eingebaut ist.

Probieren Sie es aus

Der AI-Agent ist in allen Better i18n-Plänen verfügbar. Öffnen Sie das Dashboard, klicken Sie auf das Chat-Symbol und beginnen Sie mit etwas Einfachem: „Zeig mir den Übersetzungsstatus für dieses Projekt."

Versuchen Sie von dort aus eine echte Aufgabe. Bitten Sie ihn, fehlende Übersetzungen zu finden, sie zu generieren und Sie durch den Genehmigungsprozess zu führen. Der Agent ist dafür konzipiert, konversationell erkundet zu werden — Sie müssen sich keine Tool-Namen oder API-Endpunkte merken.

Jetzt mit Better i18n starten →

Comments

Loading comments...