Ich habe 3,9 Millionen Wörter in 4 Tagen mit parallelen KI-Agenten übersetzt
493 Blogbeiträge aus 17 Jahren, übersetzt in 10 Sprachen, ~4.900 Dateien, ~3,9 Millionen Wörter. Claude Codes parallele Agenten haben es möglich gemacht — aber die Korea-Katastrophe, das Kantonsisch-Problem und die 5-stündige Nutzungssperre haben mich mehr gelehrt als die Erfolge.
Vor einem Monat habe ich DIALØGUE in 48 Stunden um 5 Sprachen erweitert und darüber geschrieben, warum Planungsdokumente das Geheimnis schneller KI-Ausführung sind.
Das waren 5 Sprachen für eine einzelne App mit vielleicht 400 UI-Strings.
Diese Woche habe ich etwas viel Größeres versucht: meinen gesamten Blog — 493 Beiträge aus 17 Jahren — in 10 Sprachen zu lokalisieren. Vietnamesisch, Indonesisch, Spanisch, Französisch, Portugiesisch, Deutsch, Japanisch, Koreanisch, vereinfachtes Chinesisch und Kantonesisch.
~4.900 übersetzte Dateien. ~3,9 Millionen Wörter. 4 Tage.
Das ist keine Geschichte darüber, wie magisch KI ist. Es ist eine Geschichte darüber, was wirklich passiert, wenn man Tausende von Übersetzungsaufgaben an parallele KI-Agenten übergibt — welche Orchestrierung funktioniert, welche Fehler erst beim Lesen des Outputs auffallen und welche unbequeme Wahrheit über Qualitätskontrolle gilt, wenn Maschinen in diesem Tempo produzieren.
Das Skalierungsproblem
Mein Blog reicht bis ins Jahr 2007 zurück. Manche Beiträge sind kurze 300-Wörter-Updates über Search-Marketing in Singapur. Andere sind 5.000 Wörter lange Tiefenanalysen zu US-China-Beziehungen oder Expat-Ratgeber. Das Archiv umfasst alles von Yahoo-SEM-Analysen über Buchrezensionen bis hin zu KI-Produktlaunches.
493 Beiträge manuell in 9 Sprachen zu übersetzen würde ein professionelles Übersetzungsteam Wochen kosten. Vielleicht Monate. Und es würde irgendwo zwischen „unangenehm teuer" und „Haus beleihen" liegen.
Aber ich hatte die i18n-Infrastruktur bereits aufgebaut — next-intl-Routing, lokalisierungsbewusste Komponenten, ISR für nicht-englische Seiten — als Teil eines umfassenderen Internationalisierungsprojekts. Der technische Stack war bereit. Ich brauchte nur noch den Inhalt.
Tag 1: Vietnamesisch und die ersten Lektionen
Ich fing mit Vietnamesisch an, weil es persönlich ist — es ist meine Muttersprache. Ich konnte jeden übersetzten Beitrag lesen und sofort erkennen, wenn etwas falsch klang.
Claude Code übersetzte alle 493 Beiträge in einer einzigen Session. Der Prozess sah sauber aus:
- Englische MDX-Datei einlesen
- Den Inhalt übersetzen und dabei die gesamte Frontmatter-Struktur erhalten
- URLs, Code-Blöcke und technische Begriffe unverändert lassen
- Die übersetzte Datei nach
content/blog/vi/YYYY/MM/DD/slug.mdxschreiben - Mit dem vietnamesischen Äquivalent von „Cheers, Chandler" abschließen
Der erste QA-Durchgang hat das Muster aufgedeckt, das jede Sprache heimsuchen sollte: URLs und Abschlussformeln. Der Agent würde interne Blog-URLs „übersetzen" (z. B. /blog/2024/... in vietnamesische Slugs umschreiben, die gar nicht existieren), „Chandler" durch eine vietnamesische Namensvariante ersetzen und gelegentlich das slug-Feld im Frontmatter ganz verlieren.
Ich habe eine QA-Checkliste erstellt:
- Dateianzahl stimmt mit der Quelle überein (493)
- Keine leeren oder Stub-Dateien
- Alle Frontmatter-Felder enthalten
slug,title,date,categories - Keine umgeschriebenen internen URLs
- Abschlussformel entspricht der Konvention des Zielgebiets
- Bei CJK-Sprachen: native Schriftzeichen tatsächlich vorhanden
Diese Checkliste wurde zum Rückgrat jeder weiteren Sprachversion.
Tag 2: Der Durchbruch mit parallelen Agenten
Mit Vietnamesisch fertig und der QA-Checkliste bewährt, musste ich schneller werden. Claude Codes Killer-Feature für diese Art von Arbeit ist der parallele Subagenten-Dispatch — man kann mehrere unabhängige Agenten starten, die jeweils gleichzeitig an verschiedenen Dateien arbeiten.
So sah die Orchestrierung für Spanisch aus:
Dispatching 30 translation agents...
├── Agent 1: 2007-2008 posts (42 posts)
├── Agent 2: 2009 posts (38 posts)
├── Agent 3: 2010-2011 posts (35 posts)
├── ...
├── Agent 28: 2025 Nov-Dec posts (12 posts)
├── Agent 29: 2026 Jan posts (8 posts)
└── Agent 30: 2026 Feb posts (9 posts)
Jeder Agent erhielt einen Stapel Beiträge, den Stilguide, die QA-Checkliste und die Abschlussformel. Sie liefen parallel und schrieben Dateien unabhängig voneinander. Keine Koordination nötig, weil jeder Agent andere Dateien bearbeitet.
Spanisch: 493 Beiträge in einer Session übersetzt. Dann Französisch. Dann Portugiesisch. Dann Deutsch. Dann Japanisch.
Fünf Sprachen in ungefähr 12 Stunden. Das ist der Teil, der sich wie die Zukunft anfühlt — zuzusehen, wie das Terminal mit 30 simultanen Fortschrittsanzeigen gefüllt wird, während jeder Agent ein Jahrzehnt an Blogbeiträgen abarbeitet und man sich nebenbei etwas zu essen macht.
Hier ist eine Simulation davon, wie die Kantonesisch-Übersetzungssession (zh-HK) tatsächlich aussah — von der Planung über den Dispatch bis hin zur QA:
Das Orchestrierungsmuster
Das Muster, das sich herausschälte:
- Alle Verzeichnisse vorab anlegen — Agenten scheitern lautlos, wenn das Zielverzeichnis nicht existiert
- Nach Jahrgangsbereich bündeln — 10–15 Beiträge pro Agent bei normalen Posts, 2–3 pro Agent bei Beiträgen über 3.000 Wörter
- Den Stilguide in jeden Dispatch einbeziehen — Agenten teilen keinen gemeinsamen Speicher, daher braucht jeder den vollständigen Kontext
- QA nach Abschluss jeder Sprache ausführen — Dateianzahl, leere Dateien, kaputtes Frontmatter, URL-Umschreibungen, konsistente Abschlussformeln
- Ausreißer mit gezielten Cleanup-Agenten beheben — es gibt immer 5–15 Beiträge, die vergessen oder fehlerhaft erstellt wurden
Die Korea-Katastrophe
Koreanisch sollte Routine sein. Dasselbe Muster wie bei den anderen 7 Sprachen. Agenten dispatchen, warten, QA, Ausreißer beheben.
Stattdessen war es die schlechteste Übersetzungsqualität aller Sprachen.
72 % der koreanischen Beiträge waren keine Übersetzungen — sie waren Zusammenfassungen. Die Agenten hatten 350+ Beiträge auf 2–3-Absatz-Abstracts gekürzt und dabei alle Details, alle Persönlichkeit, alle Nuancen verloren. Eine 4.000-Wörter-Analyse von Ray Dalios „Principles" wurde zu einer 200-Wörter-Übersicht. Ein detailliertes SEM-Tutorial wurde zu „Dieser Beitrag behandelt Strategien für Suchmaschinenwerbung."
Die UI-Strings-Datei (messages/ko.json) war noch schlimmer. Durchgängig Koreanisch und Englisch gemischt, mit korrumpierten Zeichen wie „Ch및ler" statt „Chandler." Das Zeichen 및 bedeutet auf Koreanisch „und" — irgendwie hat das Modell es mitten in ein Wort eingebaut.
Ich musste das gesamte Locale von Grund auf neu machen. Jeden einzelnen Beitrag. Der zweite Anlauf, mit strengeren Anweisungen zur vollständigen Inhaltstreue und zur Übereinstimmung mit der Länge des Quellbeitrags, war sauber.
Lektion: Parallele Ausführung verstärkt Fehler. Wenn dein Prompt einen subtilen Mangel hat, machen 30 Agenten denselben Fehler 30-mal schneller. QA ist kein optionaler Schritt — es ist das Einzige, was zwischen „fertig" und „Katastrophe" steht.
Das chinesische Problem: 43 Commits, um es richtig hinzubekommen
Vereinfachtes Chinesisch (zh) war das arbeitsintensivste Locale. Nicht wegen Qualitätsproblemen — die Übersetzungen waren gut — aber 493 Beiträge über 43 separate Commits zeigen, dass die Session immer wieder an Grenzen gestoßen ist.
Claude Code läuft auf Anthropics API, und es gibt eine Nutzungsbeschränkung. Selbst auf dem Max-Tier mit Sonnet 4.6 werden längere Sessions, die Dutzende von parallelen Agenten dispatchen, irgendwann eine 5-stündige Abkühlphase auslösen. Bei Chinesisch bedeutete das: in Wellen übersetzen — ~50 Beiträge, Limit erreicht, warten, weitermachen, Limit wieder erreicht.
Die chinesischen Übersetzungen erforderten auch am meisten QA, weil CJK-Inhalte eigene Fehlertypen haben:
- Zeichen aus dem falschen Schriftsystem (japanische Kanji gemischt mit vereinfachtem Chinesisch)
- Zu formeller Stil, der eher nach einem Behördendokument klingt als nach einem Blog
- Westliche statt chinesischer Interpunktion (，vs. , und 。vs. .)
- Übersetzte Namen, die nicht übersetzt werden sollten („Claude" bleibt auf Chinesisch „Claude", nicht 克劳德)
Das Kantonesisch-Stimmproblem
Als ich traditionelles Chinesisch mit kantonesischer Sprache (zh-HK) hinzufügte, stand ich vor einer ganz anderen Herausforderung. Die Übersetzungen mussten kantonesisch-spezifische Partikel verwenden — 嘅 (Possessiv), 咗 (Vergangenheit), 喺 (bei/in), 啲 (etwas), 冇 (nicht haben) — und den lockeren, gesprächigen Ton beibehalten, der kantonesisches Schreiben ausmacht.
Standardmandarin-Übersetzungen klingen in Hongkong bürokratisch. „本网站提供中文版本" ist korrektes Mandarin, aber ein kantonesischer Leser erwartet „呢個網站有中文版本." Gleiche Bedeutung, vollkommen andere Stimme.
Die Herausforderung liegt nicht in der Übersetzungsgenauigkeit — es ist Stimmauthentizität. Das Modell kann grammatikalisch korrektes Kantonesisch produzieren, greift aber auf einen Mandarin-Stil zurück, wenn man es nicht ausdrücklich anweist, umgangssprachliche Partikel und Code-Mixing-Muster zu verwenden.
Mein QA-Check für Kantonesisch beinhaltete, jede Datei nach kantonesisch-spezifischen Partikeln zu durchsuchen. 493 von 493 bestanden. Aber ich musste die gesamte messages/zh-HK.json-UI-Strings-Datei trotzdem manuell neu schreiben, weil die erste Version ~70 % Englisch enthielt — der Agent hatte die meisten Übersetzungen einfach ausgelassen.
Was ich mit OpenAI Codex ausprobiert habe
Irgendwo bei den deutschen Übersetzungen stieß ich an Claude Codes Nutzungsgrenze und entschied mich, während der Wartezeit OpenAIs Codex auszuprobieren. Ich hatte einen Gratismonat ChatGPT Plus, inklusive Codex-Zugang.
Das Gute: Codex erstellt solide Planungsdokumente. Die erste Codebase-Analyse und der vorgeschlagene Übersetzungsansatz waren gut strukturiert und vernünftig. Die Antwortzeiten waren schnell. Und Codex hält sich eng an Anweisungen — fast zu eng, was durchaus ein Feature sein kann.
Das Schlechte: Die Version, die ich verwendete (gpt-5.2-codex), konnte keine parallelen Subagenten ausführen. Sie verarbeitete Beiträge sequenziell — einen nach dem anderen. Bei 493 Beiträgen ist das nicht praktikabel. Außerdem arbeitete sie in kurzen Schüben, schloss 5–10 Beiträge ab und bat dann um Feedback. Jedes Mal musste ich „weiter" sagen, um den nächsten Stapel zu starten.
Als gpt-5.3-codex mitten in der Session verfügbar wurde, wechselte ich. Besser, aber immer noch keine parallele Ausführung. Der grundlegende architektonische Unterschied — Claude Code kann 30+ unabhängige Agenten dispatchen, die gleichzeitig laufen, während Codex als einzelner sequenzieller Prozess arbeitet — macht Claude Code für Masseninhaltsaufgaben dramatisch schneller.
Der ehrliche Vergleich: Codex eignet sich gut für fokussierte Arbeit an einzelnen Dateien. Es reagiert schnell und folgt Anweisungen gut. Aber für den massiven parallelen Betrieb, den ich brauchte — 4.437 Dateien über 9 Locales — ist Claude Codes Agentenarchitektur in einer ganz anderen Liga.
Die Checkliste, die alles gerettet hat
Jedes Locale durchlief dieselbe QA-Pipeline:
✓ File count: 493/493
✓ Empty files: 0
✓ Small files (<100 bytes): 0
✓ Missing slugs: 0
✓ Rewritten URLs: 0
✓ Broken frontmatter: 0
✓ Wrong sign-off: 0
✓ Native characters present: 493/493
Für CJK-Sprachen kam noch hinzu:
✓ Cantonese particles (嘅/咗/喺/啲/冇): 493/493
✓ No mixed-script contamination: PASS
✓ Chinese punctuation: PASS
Ohne diese Checkliste hätte ich die koreanischen Zusammenfassungen in die Produktion geschickt. Ich hätte die 70-%-englische kantonesische UI ausgeliefert. Ich hätte Blogbeiträge mit kaputten internen Links veröffentlicht, die auf übersetzte Slugs zeigen, die gar nicht existieren.
Die Checkliste ist keine Bürokratie. Sie ist das einzige verlässliche QA-Mittel, wenn deine Produktionspipeline Tausende von Dateien generiert, die man nicht persönlich lesen kann.
Die Abschlusszahlen
| Sprachen | 11 (Englisch + 10 Übersetzungen) |
| Übersetzte Beiträge | 493 pro Sprache × 10 = ~4.900 Dateien |
| Wörter | ~3,9 Millionen |
| Kalendertage | 4 (24.–27. Feb.) |
| UI-String-Dateien | 10 Locale-JSON-Dateien (~475 Keys je) |
| E-Mail-Vorlagen | 10 Locales |
| Journey-Daten | Milestones + Lernpfade über JSONB übersetzt |
| Nutzungsgrenze erreicht | Zu oft zum Zählen |
| Komplett neu gemachte Locales | 1 (Koreanisch) |
Was ich wirklich gelernt habe
1. Stilguides sind alles. Die kantonesische Stimme, das koreanische Formalitätsniveau, das portugiesische „Abraço" am Ende — das ist kein Dekor. Es ist der Unterschied zwischen „übersetzt" und „lokalisiert." Ohne Stilguide bekommt man grammatikalisch korrekten Inhalt, der sich liest wie ein Behördenformular.
2. Parallele Agenten sind ein Kraftmultiplikator — und ein Risikomultiplikator. Wenn 30 Agenten korrekt arbeiten, ist eine Sprache in einer Stunde fertig. Wenn 30 Agenten denselben Fehler machen, bekommt man 350 gekürzte Beiträge und einen kompletten Neustart.
3. QA ist bei dieser Größenordnung kein optionaler Schritt. Man kann 4.437 übersetzte Beiträge nicht manuell prüfen. Aber man kann strukturelle Überprüfungen automatisieren, die die häufigsten Fehler aufspüren: fehlende Dateien, kaputtes Frontmatter, umgeschriebene URLs, falsche Abschlussformeln, gekürzte Inhalte.
4. Das Schwierigste ist nicht die Übersetzung — es ist die Stimme. Jedes LLM kann Text übersetzen. Den Stil der Person klingen zu lassen, die das Original geschrieben hat — die Wärme, die Ungezwungenheit, die intellektuelle Neugier — über 9 Sprachen und 17 Jahre sich entwickelnden Schreibstils beizubehalten, das erfordert explizite Anweisung und iterative Verfeinerung.
5. Nutzungsgrenzen sind eine echte Einschränkung. Selbst auf dem höchsten Tier werden längere parallele Agentensessions an Limits stoßen. Plant mit Unterbrechungen. Strukturiert die Arbeit so, dass man dort weitermachen kann, wo man aufgehört hat.
6. Mit echten Lesern testen. Die vietnamesischen Übersetzungen konnte ich selbst QA-prüfen. Für Koreanisch oder Japanisch habe ich mich auf strukturelle Checks verlassen und dem Modell vertraut. Das ist eine bekannte Lücke. Wer bei Sprachen, die man nicht spricht, wirklich auf Qualität setzt, sollte Muttersprachler bitten, eine Stichprobe zu prüfen.
War es das wert?
Mein Blog erreicht Leser jetzt in ihrer Muttersprache in 11 Locales. Eine vietnamesische Marketing-Fachkraft in Ho-Chi-Minh-Stadt kann meine Analyse des Singapurer Suchmarkts von 2011 auf Vietnamesisch lesen. Ein japanischer KI-Forscher kann meine 2024er-Beiträge über den Aufbau von Sydney auf Japanisch lesen. Ein Kantonesisch-Sprecher in Hongkong bekommt Inhalte, die sich anfühlen, als wären sie für ihn geschrieben — nicht an ihm vorbeiübersetzt.
Ist jede Übersetzung perfekt? Nein. Maschinelle Übersetzung in diesem Maßstab hat raue Kanten. Manche Metaphern kommen nicht an. Manche Kulturverweise brauchen eine Lokalisierung, die über wortgetreue Übersetzung hinausgeht.
Aber die Alternative war, 493 Beiträge nur auf Englisch zu haben, zugänglich für vielleicht 20 % der Internetnutzer weltweit. Jetzt sind sie für über 60 % zugänglich.
Vier Tage. 3,9 Millionen Wörter. Die Infrastruktur steht. Jeder neue Beitrag, den ich auf Englisch schreibe, wird als Teil des Deployment-Prozesses in 10 Sprachen übersetzt.
Die eigentliche Frage ist nicht, ob KI-Übersetzung perfekt ist. Es ist die Frage, ob Perfektion der Feind von Zugänglichkeit ist.
Viele Grüße, Chandler
