i18n ist kaputt: Hört auf, Übersetzungsschlüssel zu schreiben

Internationalisierung (oft abgekürzt als i18n), Lokalisierung (l10n) und mehrsprachige Unterstützung beschreiben alle dieselbe Idee: dein Produkt so anzupassen, dass Menschen es in ihrer eigenen Sprache nutzen können.

i18n ist immer noch gebaut, als wäre es 2005

Jedes Unternehmen erkennt irgendwann, dass es mehrere Sprachen unterstützen muss. An diesem Punkt lehnt sich das Produktteam zurück wie ein Mechaniker, zieht scharf die Luft durch die Zähne und sagt: „Wie viele Seiten reden wir hier? Das sind mindestens vier Sprints.“

Die grundlegende Art und Weise, wie wir i18n umsetzen, hat sich in 20 Jahren nicht geändert. Die meisten i18n-„Best Practices“ entstanden lange vor modernen Webarchitekturen, und alles, was danach kam, wurde einfach nur darauf aufgesetzt.

I18n ist der einzige Teil der modernen Webentwicklung, bei dem noch Dateien exportiert und an jemanden geschickt werden. Es gilt als modern eingerichtet, wenn man sie statt per E-Mail über eine API hochlädt.

In einer Welt von CI-Pipelines und Deployments, die in Minuten statt in Tagen gemessen werden, sollten wir uns wohl glücklich schätzen, dass wir nichts faxen müssen.

Warum i18n kaputt wirkt

Die moderne Webentwicklung hat sich unglaublich schnell weiterentwickelt.

Wir haben:

• servergerenderte Komponenten
• Streaming-UI
• Edge-Runtimes
• kontinuierliche Bereitstellung
• KI-native Werkzeuge

Dennoch fühlen sich Internationalisierungs-Workflows immer noch an, als gehörten sie in eine andere Zeit.

Schon relativ kleine Anwendungen enden schnell damit, dass sie jonglieren müssen mit:

• Übersetzungsschlüssel
• JSON-Übersetzungsdateien
• manuelle Übersetzungspipelines
• isolierte Lokalisierungslogik im Frontend vs. Backend
• Tools für das Übersetzungsmanagement

Entwickler machen sich nicht daran, solche Systeme zu bauen. Sie stolpern eher hinein, wenn ihnen die üblichen i18n-Hürden den Weg versperren, weil sie nicht damit vertraut sind, dass verschiedene Sprachen Sätze völlig anders strukturieren … und akzeptieren widerwillig den vor 20 Jahren festgelegten Status quo.

Mit der Zeit wird Internationalisierung zu einem der komplexesten Teile des Stacks.

Moderne UI passt nicht in Übersetzungsstrings

Betrachten wir eine einfache UI:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Das ist leicht zu verstehen. Es ist einfach.

Irgendwann entscheiden wir, es zu internationalisieren. Also extrahieren wir den Text in eine Übersetzungsdatei:

{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

Und wir verweisen in unserem Code darauf:

<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

Aber Moment, wir haben jetzt englischen Text sowohl in unserem Code als auch in unserer Übersetzungsdatei? Ja. Verschiedene i18n-Bibliotheken setzen unterschiedliche Akzente, aber den Versuch, Text zu übersetzen, der nur teilweise formatiert ist, indem man ihn in eine menschenlesbare JSON-Datei auslagert, ist ein aussichtsloser Kampf.

Moderne Benutzeroberflächen sind strukturiert, aber Übersetzungssysteme bauen auf dem Fundament flacher Zeichenketten auf.

Sobald Markup, Variablen und dynamische Inhalte ins Spiel kommen, beginnt die Abstraktion zu bröckeln.

Dynamische und nutzergenerierte Inhalte brechen traditionelle i18n

Es wird noch schwieriger, wenn Inhalte nicht statisch sind.

Nehmen wir dieses Beispiel noch einmal:

<b>{serverResponse.productDescription}</b>

Dieser String kommt aus einer API. Wie machen wir daraus einen Übersetzungsschlüssel?

Spoiler: Tun sie nicht. Jetzt muss auch dein Backend Internationalisierung unterstützen.

Dein Backend muss jetzt Folgendes verwalten:

• die ursprünglichen semantischen Daten
• Übersetzte Varianten
• Fallback-Logik
• Gebietsschemaerkennung

Übersetzer brauchen plötzlich auch Zugriff auf Backend-Systeme.

Und das Problem wächst nur noch, wenn nutzergenerierte Inhalte ins Spiel kommen.

Bewertungen. Kommentare. Marketplace-Einträge. Foren.

Traditionelle i18n-Pipelines gehen davon aus, dass Entwickler den gesamten Text kontrollieren. Immer öfter ist das einfach nicht mehr wahr.

Die Tatsache, dass Unternehmen wie Amazon 2026 begonnen haben, mit übersetzten Nutzerbewertungen zu experimentieren, sagt einiges darüber aus, wie langsam sich das i18n-Ökosystem entwickelt hat.

Die Erkennung des Locales ist immer noch ein ziemliches Chaos

Schon allein herauszufinden, welche Sprache ein Nutzer möchte, ist überraschend kompliziert.

Browser senden Spracheinstellungen über den Accept-Language-Header:

Accept-Language: en-GB,en;q=0.9,fr;q=0.8

Das teilt dem Server Folgendes mit:

1. Britisches Englisch bevorzugen
2. Dann irgendeine Form von Englisch
3. Dann irgendein Französisch

In der Praxis umfasst die korrekte Umsetzung Folgendes:

• Gewichtung der Parsing-Qualität
• Locales normalisieren (en, en-GB, en-US)
• abgleich unterstützter Sprachen
• Fallback-Logik handhaben
• explizite Benutzerüberschreibungen berücksichtigen

Viele Frameworks überlassen den Entwicklern den Großteil dieser Logik.

Schon die einfache Erkennung des Lokals wird oft zu maßgeschneidertem Anwendungscode.

Sprachwechsel ist ein nachträglicher Gedanke

Übersetzungsinfrastruktur ist nur die halbe Miete.

Nutzer brauchen trotzdem eine Möglichkeit, die Sprache zu wechseln.

Die meisten i18n-Bibliotheken stellen die Übersetzungsschicht bereit, überlassen den Rest des Problems aber dem Entwickler:

• Sprachumschalter
• Locale-Routing
• Cookie-Persistenz
• URL-Kanonisierung
• hreflang-Tags für SEO

Diese Details klingen klein, aber sie werden schnell zu einer beträchtlichen Menge an Anwendungs-„Klempnerarbeit“, besonders wenn man mit all den Feinheiten von i18n nicht vertraut ist. Die meisten Unternehmen und Entwickler sind das nicht.

Der Shortcut: Automatische Website-Übersetzung

Bei all dieser Komplexität greifen manche Teams zu automatischen Website-Übersetzungstools. Diese Plattformen versprechen, deine Website mit minimalem Aufwand automatisch zu übersetzen.

Mehrere Unternehmen bauen zunehmend ausgefeiltere Versionen dieser Idee. Leider bringen sie eine andere Reihe von Problemen mit sich:

• Übersetzungen finden oft clientseitig statt
• SEO geht kaputt
• dynamisch geladene Inhalte lassen sich ohne ein Aufflackern in der falschen Sprache nicht übersetzen
• die Kontrolle der Entwickler verschwindet

Das Ergebnis ist oft eine Seite, die technisch mehrere Sprachen unterstützt, aber ein deutlich schlechteres Nutzererlebnis liefert und für Entwickler eine Blackbox ist.

Wie wir hier gelandet sind

Wir haben mit etwas wunderschön Einfachem begonnen:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Und am Ende hatten wir Übersetzungsschlüssel, JSON-Wörterbücher, zersplitterte Pipelines, getrennte Lokalisierungsschichten für Backend und Frontend sowie externe Übersetzungswerkzeuge.

Moderne Web-Apps sind unglaublich ausgefeilte Systeme. Dennoch erwartet i18n-Werkzeugung Workflows, die für eine andere Zeit entworfen wurden – wie ein Ferrari mit Handkurbel zum Starten des Motors.

Das Modell neu denken

Wie wäre es, wenn Internationalisierung eher so aussehen würde?

<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

Keine Übersetzungsschlüssel.

Keine JSON-Wörterbücher.

Keine manuellen Pipelines.

Nur Text.

Ein anderer Ansatz

Diese Idee ist die Grundlage von 18ways.

18ways behandelt Übersetzung als optimierte Laufzeitaufgabe. Das Extrahieren von Übersetzungsschlüsseln und das Verwalten von Übersetzungsdateien ist ein Problem für Maschinen, nicht für Menschen.

Entwickler markieren einfach den Text, den sie übersetzt haben möchten.

Im Hintergrund macht 18ways:

• extrahiert die Zeichenfolgen
• erstellt Übersetzungen mithilfe von KI
• cached die Ergebnisse
• liefert übersetztes HTML direkt vom Server aus

Alles bleibt SSR-freundlich und SEO-sicher.

Kontextbewusste Übersetzungen

Traditionelle i18n-Systeme verlieren den Kontext.

Ein Übersetzer könnte so etwas sehen:

home

Aber was bedeutet das?

Im Deutschen erfordern diese Bedeutungen völlig unterschiedliche Wörter:

• Haus – ein Haus
• Startseite - die Homepage
• Start - ein Navigationslabel
• zum Anfang – zurück zum Anfang

Wenn du „home“ ins Deutsche übersetzen müsstest, was würdest du lieber sehen? Eine isolierte Zeichenkette oder die Seite, auf der es tatsächlich erscheint?

Übersetzungssysteme, die nur isolierte Strings sehen, tun sich mit diesen Unterschieden schwer.

18ways analysiert Übersetzungen im Kontext der tatsächlichen UI.

Unsere Backend-Agents prüfen Übersetzungen so, wie sie auf echten Seiten erscheinen, und optimieren auf:

• Kontext
• Konsistenz
• Layout-Einschränkungen
• Übersetzungsqualität

Falls du mit deutschen Komposita vertraut bist, keine Sorge – Überlauferkennung ist auch dabei.

Menschliche Übersetzer stärken

Alles, was KI dabei hilft, bessere Übersetzungen zu erzeugen, hilft auch menschlichen Übersetzern.

18ways bietet Übersetzern dieselbe kontextbewusste Umgebung, die auch unsere KI-Agenten nutzen.

Anstatt JSON-Dateien zu bearbeiten, prüfen Übersetzer den Text direkt in der UI, in der er erscheint.

Das verbessert die Übersetzungsgenauigkeit und die Effizienz des Workflows erheblich.

Wie bessere i18n aussieht

Internationalisierung braucht keine weitere Ebene aus Übersetzungsschlüsseln, String-Dateien und Pipeline-Klebstoff.

Moderne Anwendungen haben bereits die Struktur, den Kontext und die Laufzeitinformationen, die wir brauchen, um das besser zu machen.

Die nächste Generation von i18n sollte für serverseitig gerenderte Apps, dynamische Inhalte, KI-native Workflows und menschliche Übersetzer entwickelt werden, die Seite an Seite arbeiten.

Dorthin geht 18ways.