Wie wir unsere gesamte Plattform mit KI übersetzt haben (und was Agilität damit zu tun hatte)

Ende 2025 existierte die Plattform der Agile Academy in zwei Sprachen: Deutsch und Englisch. Vier Monate später war sie in acht Sprachen verfügbar. Wir haben keine Übersetzungsagentur beauftragt. Wir haben KI eingesetzt. Und agile Prinzipien haben den entscheidenden Unterschied gemacht.

Der Ausgangspunkt

Eine Plattform, zwei Codebasen, zwei Sprachen und ein wachsendes internationales Publikum.

Die Agile Academy ist keine einzelne Anwendung. Sie ist ein Ökosystem:

• Kirby CMS Knowledge Base: 440+ Artikel in 10 Bereichen, jeweils mit komplexem Layout-JSON, Querverweisen und sprachspezifischem URL-Routing
• Ruby on Rails Plattform: Buchungsseiten für Trainings, E-Learning-Kurse, Checkout-Flows, Produktseiten, mit Locale-Dateien und Views
• Backend-Systeme: Mailing-Templates, Rechnungsstellung, transaktionale E-Mails
• UI-Übersetzungen: Menüs, Footer, Breadcrumbs, Buttons und der Sprachumschalter selbst – über beide Plattformen hinweg

All das existierte nur auf Deutsch und Englisch. Gleichzeitig konnten wir Nutzern, die weder Deutsch noch Englisch sprachen – ein wachsender Anteil unserer Zielgruppe – keine kuratierten Inhalte anbieten.

Die Übersetzung war nicht nur eine Content-Aufgabe. Jede Sprache erforderte:

• Neue Routen in Kirbys PHP-Konfiguration (Artikelübersichten, Section-Slug-Rewrites, Redirects)
• Section-Level Content-Dateien mit lokalisierten URL-Slugs
• Übersichtsseiten, Landingpages und strukturelle Seiten (Recht, Events, Autorenseiten)
• ROR-Locale-Dateien für Menüs, Footer, Trainingsseiten, E-Mails
• Mailing-Templates im Backend
• Plattformübergreifende Konsistenz: dasselbe Wort für „Artikel“ in URLs, dieselben Links zu rechtlichen Seiten, dieselbe Menüstruktur

Eine klassische Übersetzungsagentur hätte die Artikeltexte übernehmen können. Aber niemand hätte unsere PHP-Routen geschrieben, unsere JSON-Layouts repariert oder unsere Rails-Locale-Dateien aktualisiert. Wir brauchten einen anderen Ansatz.

Iteration 1: Spanisch

Copy-Paste, manuelle Code-Änderungen und ein Monat Knochenarbeit. Der Wasserfall-Ansatz.

Spanisch war unsere erste Erweiterungssprache. Der Prozess sah so aus:

1. Text eines Artikels in ChatGPT oder Claude kopieren
2. Die Übersetzung zurück in eine neue Datei einfügen
3. Das Layout-JSON manuell reparieren (in der Hoffnung, es nicht kaputt zu machen)
4. Das Ganze 440 Mal wiederholen – allein für Kirby
5. Separat ROR-Locale-Dateien, Views und Mailing-Templates übersetzen
6. Manuell Routen, Section-Dateien und Übersichtsseiten in Kirby anlegen
7. Manuell Locale-Dateien und Routen in ROR aktualisieren
8. Manuell Mailing-Templates im Backend erstellen

Es dauerte etwa einen Monat. Nur die wichtigsten Seiten wurden in beiden Systemen übersetzt. Die Qualität war inkonsistent. Manche Artikel verwendeten eine formelle Ansprache, andere eine informelle. Agile Begriffe wurden manchmal übersetzt, manchmal nicht. Querverweise zwischen Artikeln führten zu nicht existierenden Seiten.

Die Infrastrukturarbeit war noch schmerzhafter. Jede Route musste von Hand geschrieben werden. Jede Section-Datei musste von Grund auf erstellt werden. URL-Slugs waren inkonsistent. Die ROR- und Kirby-Plattformen mussten synchron bleiben (gleiche Menü-Links, gleicher Footer, gleiche rechtliche Seiten), und den Überblick zu behalten war ein Albtraum aus Spreadsheets.

In agilen Begriffen war das ein klassisches Wasserfall-Delivery: ein großer Batch, begrenzte Feedbackschleifen, keine Automatisierung, keine gemeinsamen Standards. Wir haben es ausgeliefert, aber wir wussten, dass dieser Ansatz nicht auf sechs weitere Sprachen skalieren würde.

Iteration 2: Portugiesisch

Erste Automatisierung, erste Skripte, erster Einsatz von Claude Code. Eine Woche statt eines Monats.

Für Portugiesisch änderten wir den Ansatz. Statt einen Artikel nach dem anderen per Copy-Paste zu übersetzen, schrieben wir Skripte, die die Übersetzung über API-Aufrufe automatisierten. Englische Quelle rein, übersetzte Kirby-Datei raus.

Noch wichtiger: Wir begannen, Claude Code einzusetzen – nicht nur für Artikelinhalte, sondern auch für die Infrastrukturarbeit. Claude Code konnte unsere bestehenden spanischen Routen lesen und die portugiesischen Entsprechungen generieren. Es konnte Section-Dateien, Übersichtsseiten erstellen und Konfigurationsdateien aktualisieren.

Auf der ROR-Seite generierte Claude Code Locale-Dateien auf Basis der bestehenden spanischen Übersetzungen. Es aktualisierte Mailing-Templates, erstellte neue Views bei Bedarf und hielt die plattformübergreifenden Referenzen konsistent.

Das Ergebnis: etwa eine Woche statt eines Monats. Aber die Fehlerquote war immer noch hoch.

Die Skripte verstanden keinen Kontext. Sie übersetzten „Sprint“ ins Portugiesische. Sie brachen Layout-JSON, indem sie Zeilenumbrüche in Strings einfügten. URL-Slugs waren manchmal falsch, weil die KI unsere Routing-Konventionen über beide Plattformen hinweg nicht kannte.

Wir verbrachten erhebliche Zeit mit Review und Korrekturen. Aber entscheidend war: Wir waren jetzt am Inspizieren und Anpassen. Jeder Fehler, den wir fanden, wurde zu einer Regel für die nächste Iteration. Wir begannen ein Glossar. Wir verfeinerten den Übersetzungsprompt. Wir dokumentierten die URL-Konventionen, die beide Plattformen einhalten mussten.

Iterationen 3–6: Französisch, Italienisch, Niederländisch, Polnisch

Spezialisierte Agenten, institutionelles Wissen und zwei Tage pro Sprache.

Als wir bei Französisch ankamen, war das System erheblich gereift. Den wirklichen Unterschied machte die Aufteilung der Arbeit.

Statt eines großen KI-Kontexts, der alles auf einmal bewältigen sollte, erstellten wir spezialisierte Agenten, die sich jeweils auf einen Teil des Systems konzentrierten:

• Content-Übersetzungsagenten, die Batches von Kirby-Artikeln bearbeiteten und dabei dem Übersetzungsprompt und Glossar folgten
• Infrastruktur-Agenten, die Routen, Section-Dateien und Übersichtsseiten in Kirby erstellten
• ROR-Locale-Agenten, die Locale-Dateien für die Rails-Plattform übersetzten und erstellten
• Verifikationsagenten, die Skripte ausführten, um kaputtes JSON, falsche URL-Slugs und fehlende Felder zu erkennen

Jeder Agent hatte ein reduziertes Kontextfenster, das auf seine spezifische Aufgabe zugeschnitten war. Das lieferte deutlich bessere Ergebnisse als ein einzelner Agent, der die gesamte Plattform im Gedächtnis halten musste.

Das institutionelle Wissen war jetzt kodifiziert:

• Ein Übersetzungsprompt (TRANSLATION_PROMPT.md) definierte Ton, Format, URL-Regeln und die Anforderung für den KI-Hinweis
• Ein Glossar (glossary.json) hielt agile Begriffe über alle Sprachen hinweg konsistent
• Verifikationsskripte fingen Fehler ab, bevor sie in die Produktion gelangten: kaputtes Layout-JSON, falsche Hreflang-Referenzen, fehlende Pflichtfelder
• Eine Checkliste in CLAUDE.md dokumentierte jeden Infrastrukturschritt, der für eine neue Sprache erforderlich war (Routen, Section-Dateien, Übersichtsseiten, strukturelle Seiten, Menü-/Footer-Synchronisation)
• Plattformübergreifende Konsistenzprüfungen stellten sicher, dass Kirby und ROR synchron blieben

Italienisch dauerte zwei Tage. Niederländisch dauerte zwei Tage. Polnisch dauerte zwei Tage. Jede Iteration war schneller und zuverlässiger. Die Fehlerquote sank mit jeder Sprache, weil das System aus jedem vorherigen Fehler lernte.

Vorher und Nachher

Dieselbe Aufgabe. Ein grundlegend anderes System.

Die agilen Prinzipien in Aktion

Das war nicht nur ein Übersetzungsprojekt. Es waren sechs Sprints organisationalen Lernens.

Iterative Verbesserung

Jede Sprache war ein Sprint. Spanisch war Sprint 1: langsam, manuell, voller Learnings. Polnisch war Sprint 6: schnell, automatisiert, ausgereift. Die Verbesserung war exponentiell. Jede Iteration fügte nicht nur eine Sprache hinzu. Sie verbesserte das System für alle zukünftigen Sprachen.

Inspect and Adapt

Jeder Fehler in einer Sprache wurde zur Präventionsregel für die nächste. Kaputtes JSON? JSON-Validator zum Verifikationsskript hinzufügen. „Sprint“ ins Portugiesische übersetzt? Ab ins Glossar damit. Falsche URL-Slug-Konvention? In der Checkliste dokumentieren. Das System wurde klüger, weil wir Feedbackschleifen eingebaut haben.

Selbstorganisierende Teams

Die spezialisierten Agenten waren im Grunde selbstorganisierende Teammitglieder. Jeder hatte eine klare Verantwortung, den richtigen Kontext für seine Aufgabe und definierte Schnittstellen zu den anderen. Der Content-Agent musste nichts über PHP-Routen wissen. Der Infrastruktur-Agent musste kein Layout-JSON parsen. Separation of Concerns. Das funktioniert für Software genauso wie für Teams.

Funktionierende Software über umfassende Dokumentation

Der Übersetzungsprompt, das Glossar, die Verifikationsskripte – nichts davon wurde vorab entworfen. Alles entstand aus realen Problemen, die wir bei der eigentlichen Arbeit getroffen haben. Der Prompt wurde fünfmal überarbeitet. Das Glossar wuchs mit jeder Sprache. Die Skripte entstanden aus Fehlern, die durch die manuelle Prüfung gerutscht waren. Lebendige Dokumentation, geformt durch tatsächliche Nutzung, erwies sich als weitaus nützlicher als jede Spezifikation, die wir vorab hätten schreiben können.

Reagieren auf Veränderung

Unsere Architekturentscheidungen wurden durch Fehler getrieben, nicht durch Vorausplanung. Wir haben nicht vorhergesagt, dass Layout-JSON die größte Fehlerquelle sein würde. Wir haben es bei Spanisch entdeckt und vor Portugiesisch eine Validierung dafür gebaut. Wir haben die Agentenspezialisierung nicht geplant. Wir sind dort angekommen, nachdem wir gesehen haben, dass ein großer Kontext schlechtere Ergebnisse lieferte als mehrere fokussierte. Am Ende hatten wir ein besseres Setup als alles, was wir am Whiteboard hätten entwerfen können.

Zentrale Erkenntnisse

KI ersetzt agiles Denken nicht. Sie verstärkt es.

1. KI verstärkt deinen Prozess – im Guten wie im Schlechten

Wenn dein Prozess chaotisch ist, produziert KI schneller Chaos. Wenn dein Prozess diszipliniert ist (klare Prompts, definierte Standards, Verifikationsschleifen), produziert KI Qualität in großem Maßstab. Dasselbe Tool, das in Iteration 1 unser JSON zerstört hat, lieferte in Iteration 6 einwandfreie Ergebnisse. Die KI hat sich nicht verändert. Unser Prozess schon.

2. Kontext ist alles

Das Glossar, der Übersetzungsprompt, die Checkliste, die plattformübergreifenden Konsistenzregeln – all das sind Formen von Kontext. Eine KI ohne Kontext ist nur ein schneller Übersetzer. Eine KI mit dem richtigen Kontext ist ein Teammitglied, das deine Konventionen, deine Randfälle und deine Qualitätsstandards versteht. Diesen Kontext aufzubauen ist die eigentliche Arbeit – und sie zahlt sich mit jeder weiteren Sprache mehr aus.

3. Die menschliche Rolle verschiebt sich vom Ausführenden zum Architekten

In Iteration 1 haben Menschen die Übersetzungen gemacht. In Iteration 6 haben Menschen das System entworfen, die Standards definiert, die Ergebnisse geprüft und den Prozess verbessert. Die Arbeit ist nicht verschwunden. Sie hat sich auf eine höhere Ebene verlagert. Weniger Copy-Paste, mehr Nachdenken darüber, was eine gute Übersetzung ausmacht, was ein konsistentes Nutzererlebnis schafft und wie man Fehler erkennt, bevor es die Nutzer tun.

4. Klein anfangen, ausliefern, lernen, wiederholen

Wir hätten Monate damit verbringen können, die „perfekte“ Übersetzungspipeline zu entwerfen, bevor wir einen einzigen Artikel übersetzt hätten. Stattdessen haben wir mit Copy-Paste angefangen und iteriert. Jede Sprache hat uns etwas gelehrt. Jeder Fehler hat das System verbessert. Als wir bei den späteren Sprachen ankamen, hatten wir eine Pipeline, die keine noch so gute Vorausplanung hätte hervorbringen können – weil sie durch reale Probleme geformt wurde, nicht durch hypothetische.