Moderne Apps haben ein Lokalisierungsproblem. Und es ist nicht die Übersetzung.
In den letzten zehn Jahren konzentrierte sich die Lokalisierungsbranche auf Übersetzungs-Workflows — Tools, die Teams helfen, Übersetzer:innen zu verwalten, Strings zu reviewen und mehrsprachige Inhalte auszuliefern.
Tools wie Phrase, Lokalise, Crowdin und Transifex sind hervorragend im Management von Übersetzungen. Aber sie alle setzen stillschweigend etwas Entscheidendes voraus: dass deine App schon internationalisiert ist. In Wirklichkeit sind das die meisten Apps nicht. Und mit dem Aufstieg von KI-generiertem Code wird diese Lücke gerade zu einem massiven Problem.
Was ist die versteckte i18n-Ebene, die Lokalisierungstools übersehen?
Lokalisierung und Internationalisierung werden oft verwechselt. Sie sind nicht dasselbe.
Lokalisierung (l10n) — Eine App in verschiedene Sprachen übersetzen.
Internationalisierung (i18n) — Die Codebase so vorbereiten, dass Übersetzung überhaupt möglich wird.
Internationalisierung bedeutet Dinge wie: UI-Strings extrahieren, Übersetzungsschlüssel generieren, Übersetzungsdateien anlegen, Pluralregeln unterstützen, Zahlen und Datumsformate formatieren, Rechts-nach-links-Sprachen unterstützen und hartcodierten UI-Text vermeiden. Die meisten Lokalisierungstools setzen erst nach diesem Schritt an. In vielen realen Codebases ist dieser Schritt aber nie passiert.
Wie richtig internationalisierter Code aussieht
In einer gut strukturierten App wird UI-Text über Übersetzungsschlüssel referenziert.
<button>{t("checkout.submit_order")}</button>
Der Text liegt in Übersetzungsdateien:
/locales/en.json
{
"checkout.submit_order": "Submit order"
}
Diese Struktur ermöglicht es Übersetzungstools und -engines, verlässlich zu arbeiten.
Wie die meisten Apps tatsächlich aussehen
In Wirklichkeit sehen viele Apps so aus:
<button>Submit order</button>
<h1>Welcome back</h1>
<p>Your payment was successful</p>
Auf den ersten Blick wirkt das harmlos. Aber multipliziere das mit Hunderten von Komponenten und Tausenden von UI-Strings. Jetzt geht die gesamte Codebase von einer rein englischsprachigen UI aus. In dem Moment, in dem man versucht, eine weitere Sprache zu unterstützen, tauchen überall Probleme auf.
- Deutscher Text ist rund 30 % länger. Buttons laufen über.
- Arabisch erfordert Rechts-nach-links-Layouts. Ganze Interfaces brechen zusammen.
- Pluralregeln unterscheiden sich je Sprache. Nachrichten werden grammatisch falsch.
Ohne Internationalisierungs-Architektur wird Lokalisierung schnell zu einem großen Refactoring-Projekt.
Wie hat KI-generierter Code die Lokalisierung schwieriger gemacht?
Moderne Entwicklung stützt sich zunehmend auf KI-Coding-Tools: Cursor, GitHub Copilot, ChatGPT, Replit, Lovable, Bolt. Diese Tools sind auf Geschwindigkeit und eine funktionierende UI optimiert, nicht auf Architektur.
Typischer generierter Code sieht so aus:
<button>Submit</button>
<h2>Welcome back</h2>
<p>Your order has been confirmed</p>
In einem typischen KI-generierten Projekt findet man häufig: Hunderte oder Tausende hartcodierte UI-Strings, doppelten Interface-Text, keine Übersetzungsschlüssel, keine Übersetzungsdateien, keine Unterstützung für Pluralregeln. Mit anderen Worten: perfekte Demos, katastrophale Lokalisierungs-Architektur.
Das Muster ist vorhersehbar. Teams bauen schnell, launchen, gewinnen an Fahrt — und merken dann: „Unsere gesamte UI ist hartcodiertes Englisch.“ An diesem Punkt erfordert das Hinzufügen von Lokalisierung, einen Großteil der UI-Codebase anzufassen.
Ein reales Muster, das wir beobachten
Beim Scannen kleiner, KI-generierter SaaS-Projekte zeigt sich das Muster schnell. In einem analysierten React-Prototyp: 1.284 UI-Strings über 312 Dateien verteilt, ohne jede Internationalisierungsstruktur. Beispiele dafür waren:
<h1>Welcome back</h1>
<button>Start free trial</button>
<p>Your payment failed</p>
Um Lokalisierung hinzuzufügen, musste das Team: UI-Strings aus Hunderten von Komponenten extrahieren, Übersetzungsschlüssel einführen, Übersetzungsdateien aufbauen, die UI-Logik umschreiben — bevor die Übersetzung überhaupt beginnen konnte. Dieses Muster sehen wir bei KI-generierten Projekten immer wieder.
Warum können klassische Lokalisierungstools KI-generierten Code nicht handhaben?
Die meisten Lokalisierungstools wurden für Übersetzungsteams entwickelt, nicht für Entwickler:innen. Ihre Workflows setzen voraus, dass das Entwicklungsteam bereits Folgendes umgesetzt hat: ein i18n-Framework, Übersetzungsschlüssel, Strukturen für Übersetzungsdateien, Pipelines zur String-Extraktion. Moderne Codebases — besonders KI-generierte — haben dieses Fundament aber oft überhaupt nicht. Teams stehen also vor einer unerwarteten Realität: Bevor sie überhaupt etwas übersetzen können, müssen sie erst die gesamte UI-Ebene refaktorieren.
Die fehlende Ebene im Lokalisierungs-Stack
Der heutige Lokalisierungs-Stack sieht typischerweise so aus:
Aber etwas Entscheidendes fehlt. Was tatsächlich passieren muss, ist:
Diese fehlende Ebene muss: die Codebase scannen, UI-Strings extrahieren, Übersetzungsschlüssel generieren, Übersetzungsdateien aufbauen, doppelte Strings erkennen, Terminologie-Glossare anlegen. Erst dann können Übersetzungs-Workflows starten.
Warum dieses Problem gleich explodiert
Drei große Trends kollidieren gerade.
- KI-first-Entwicklung. Immer mehr Apps entstehen mit KI-gestützter Programmierung. Manche Startup-Codebases sind inzwischen größtenteils KI-generiert. Architektur wird dabei oft zur Nebensache gegenüber schnellem Ausliefern.
- Indie-Hacker-Explosion. Jede Woche starten Tausende neue SaaS-Produkte. Die meisten starten zunächst nur auf Englisch.
- Globale Nutzer:innen von Tag eins an. Selbst kleine Produkte ziehen schnell Nutzer:innen aus Deutschland, Brasilien, Indien, Japan an. Sobald internationale Nutzer:innen da sind, wird Lokalisierung dringend. Aber die Architektur ist meist nicht bereit dafür.
Ein anderer Ansatz
Was, wenn sich Internationalisierung automatisieren ließe? Genau das passiert, wenn du dein Repository bei globalize.now verbindest. Die erste Konvertierung läuft einmalig in der App und meldet zurück, was gefunden wurde:
✔ Found 128 UI strings
✔ Generated 92 translation keys
✔ Created /locales/en.json
✔ Updated 41 files
Done in 2.7s
Das Tool würde: die Codebase scannen, nutzerseitige Strings extrahieren, strukturierte Übersetzungsschlüssel generieren, Übersetzungsdateien anlegen, UI-Code automatisch umschreiben. Und macht so aus diesem hier:
<button>Submit order</button>
Dieses hier:
<button>{t("checkout.submit_order")}</button>
Plötzlich ist die gesamte Codebase übersetzungsbereit.
Eine neue Kategorie: KI-fähige Lokalisierung
Die nächste Generation von Lokalisierungs-Tooling wird nicht bei Übersetzer:innen ansetzen. Sie wird bei der Code-Transformation ansetzen. Der Workflow wird eher so aussehen:
Die größte Lücke im Lokalisierungs-Ökosystem heute ist die Automatisierung dieses ersten Schritts: die Codebase für globale Nutzer:innen vorzubereiten.
Sieh dir an, wie globalize.now das für Entwicklungsteams automatisch übernimmt.
Für den historischen Bogen von CAT-Tools zu KI-nativen Workflows lies die drei Stufen der Lokalisierung im KI-Zeitalter.
Die Zukunft der Lokalisierung
Lokalisierung war früher ein Übersetzungsproblem. Im Zeitalter der KI-Entwicklung wird sie zu einem Problem der Code-Architektur. Die Teams, die diese Ebene lösen, werden bestimmen, wie globale Software im nächsten Jahrzehnt gebaut wird.
globalize.now konvertiert hartcodierte App-Texte in übersetzungsreife Locale-Dateien und hält sie aktuell, während Sie veröffentlichen.
Probiere globalize.now kostenlos