SPAs machten i18n unnötig schwer

10 Min. Lesezeit

Internationalisierung kommt früher, als Teams erwarten

Der erste Fehler ist meist ein Fehler des Managements, nicht der Technik.

Teams behandeln i18n als spätere Skalierungsfrage, selbst wenn der Markt den Bedarf von Anfang an sichtbar macht. Das funktioniert genau so lange, bis das Produkt eine zweite Sprache braucht und jemand entdeckt, dass Texte, Routing, Metadaten, Support-Abläufe und redaktionelle Verantwortung alle so gebaut wurden, als bleibe Englisch für immer der Standard.

Für CTOs ist das vor allem kein Streit über Frontend-Stil. Es geht um Lieferfähigkeit. Wenn Mehrsprachigkeit eine normale Geschäftsanforderung ist, lautet die richtige Frage nicht „Welches Framework wirkt modern?“ Sondern: „Welches Anwendungsmodell hält diese Anforderung so langweilig, dass wir sie liefern und betreiben können?“

Warum i18n sehr schnell unverzichtbar wird

Europa ist das offensichtliche Beispiel. Die EU hat 24 Amtssprachen, und die Europäische Kommission sagt, ihre Websites auf europa.eu seien im Allgemeinen in allen 24 verfügbar. Mehrsprachige Nutzer sind in europäischer Unternehmenssoftware normal: Menschen wechseln zwischen lokaler Sprache, Englisch und manchmal der Sprache eines Nachbarlandes, ohne das bemerkenswert zu finden. Ein deutsches Unternehmen kann nach Spanien verkaufen, in Polen einstellen, an eine niederländische Mutter berichten und Lieferantentermine auf Englisch führen. Das Produkt kann lokal sein. Der Ablauf ist es selten. EU-Politik zur Mehrsprachigkeit, Sprachgebrauch der Kommission.

Die Vereinigten Staaten sind anders, aber nicht so einfach, wie viele behaupten. Vom Census Bureau am 3. Juni 2025 veröffentlichte Daten sagen, dass im Zeitraum 2017–2021 22 % der Menschen ab fünf Jahren zu Hause eine andere Sprache als Englisch sprachen. Viele US-Geschäftsanwendungen kommen mit Englisch zuerst durch, weil Käufer und Büroanwender meist ausreichend sicher Englisch sprechen und Sprachreibung den Verkauf am ersten Tag nicht verhindert. Das ist eine Abkürzung des Markts, keine technische Wahrheit. Veröffentlichung des U.S. Census.

Dann gibt es den postsowjetischen Wirtschaftsraum, in dem sich das Bild erneut verschiebt. Lokale Staatssprachen zählen, Russisch bleibt jedoch in weiten Teilen der Region geschäftliche Verkehrssprache. Von der University of Colorado hervorgehobene Forschung beschreibt Russisch als „significant commercial lingua franca“ in postsowjetischen Staaten. Zusammenfassung der Forschung zur Geschäftssprache.

Es geht hier nicht um Soziolinguistik um ihrer selbst willen.

Es geht darum, dass viele Unternehmen in Märkten arbeiten, in denen Sprachunterstützung früh kommt und bleibt. Wenn dieser Bedarf vorhersehbar ist, sollte die Architektur ihn als normal behandeln, statt so zu tun, als lasse er sich nachträglich ankleben, sobald das Produktmodell schon ausgehärtet ist.

Warum SPAs zunächst klug wirkten

Der Verkauf war verführerisch, weil er eine echte Frustration traf.

Seitenneuladen fühlte sich klobig an. Mobile Apps wirkten flüssiger. JavaScript-Engines wurden schneller. Frameworks versprachen eine gemeinsame Anwendungshülle, unmittelbare Übergänge, wiederverwendbare Komponenten und eine Nutzererfahrung, die mehr nach Software und weniger nach einem Stapel verlinkter Dokumente aussah.

Das war emotional überzeugend und manchmal wirklich nützlich.

Eine Zeit lang folgerten viele Teams, das Dokumentmodell des Browsers sei die alte Welt und die SPA die Zukunft. Wenn die Seite am Leben blieb und der Client die Koordination übernahm, würde alles schneller, reichhaltiger und moderner wirken.

Dann kamen normale Geschäftsanforderungen.

Schon das SPA-Glossar von MDN ist weniger romantisch als der Konferenzzirkus. Es beschreibt eine SPA als einzelnes Dokument, das über JavaScript aktualisiert wird, und nennt die Abwägungen offen: SEO-Probleme, mehr Aufwand für Zustandsverwaltung, Navigation und aussagekräftiges Performance-Monitoring. Und das noch bevor Recht, Finanzen oder Kundensupport verlangen, dass Deutsch, Spanisch und Englisch im selben Ablauf konsistent funktionieren. Selbst MDN benennt den Zielkonflikt.

Das ist die erste nützliche Tatsache.

Die zweite ist unangenehmer.

i18n ist in SPAs nicht schwer, weil Entwickler dumm wären. Es ist schwer, weil die SPA Aufgaben, die der Browser auf Dokumentebene erledigte, in Anwendungscode verschoben hat. Sprachunterstützung landet direkt auf dieser Entscheidung.

Warum der SPA-Kompromiss bei i18n zurückschlägt

Browser können bereits sehr viele Dinge, die die SPA-Kultur ein Jahrzehnt lang für zu primitiv erklärte:

• Links verfolgen
• Verlauf erhalten
• Formulare absenden
• Dokumente darstellen
• Ressourcen cachen
• Apps installieren
• bei passendem Entwurf offline funktionieren

Die History API ist seit Juli 2015 breit verfügbar. PWAs erweitern dieselbe Plattform dort, wo der Browser sie unterstützt, um Installierbarkeit, Offline-Fähigkeit und Geräteintegration. Das ist keine Spielzeugplattform.

Wenn also jemand sagt, die SPA sei nötig gewesen, weil „Nutzer App-ähnliches Verhalten erwarten“, lautet die offensichtliche Antwort: Ja, und die Webplattform hat diese Lektion vor Jahren gelernt.

Der Browser ist erwachsen geworden.

Die Frontend-Branche hat weiter abgerechnet, als wäre er es nicht.

Der Browser ist leistungsfähiger, als die Framework-Gewohnheit zugibt. Was viele Teams noch immer moderne Webentwicklung nennen, ist oft nur ein umständlicher Weg, der Plattform nicht zu vertrauen.

Das Ergebnis ist vorhersehbar. Sobald ein Produkt mehrere Sprachen braucht, muss die SPA Routenbedeutung, Spracherkennung, Textladen, Fallback-Verhalten, Metadaten und das Überleben des Zustands in einer dauerhaft laufenden Client-Anwendung koordinieren. Was früher Dokumentbereitstellung war, wird Laufzeit-Choreografie.

Framework-Dokumentation gibt das auf unterschiedliche Weise zu.

Angular liefert eine vollständige Pipeline für Extraktion und lokalisierte Builds. React überlässt dir meist einen Ecosystem-Stack aus Backends, Spracherkennung, Namespaces und Ladeverhalten. Vue legt eine eigene i18n-Schicht darüber, mit eigener Migrationslast. Next.js hilft bei internationalisiertem Routing und sagt dann ausdrücklich, diese Unterstützung solle externe i18n-Bibliotheken ergänzen, nicht ersetzen. Die Frameworks verstecken die Komplexität nicht. Sie dokumentieren sie.

Die Frameworks verraten sich selbst

Angular verdient Anerkennung, weil es nicht so tut, als entstehe i18n durch Feenstaub auf Komponenten.

Die offizielle Dokumentation fordert @angular/localize, mit i18n-Attributen oder $localize markierte Zeichenketten, ng extract-i18n, Übersetzungsdateien je Sprache, übersetzte Pluralformen und Alternativen sowie die Build-Option localize, um pro Gebietsschema eine vollständige Anwendungsvariante zu erzeugen. Sie nennt auch die unterstützten Austauschformate: XLIFF, XLIFF 2, XMB, JSON und ARB. Angular i18n-Übersicht, Paket hinzufügen, Übersetzungsdateien, lokalisierte Varianten zusammenführen.

Das ist keine Kritik an Angular.

Angular ist ehrlich.

Wenn die gesamte UI in einer dauerhaft laufenden Client-Anwendung lebt, wird Lokalisierung zu Build-Pipeline, Extraktionspipeline, Lebenszyklus für Übersetzungsdateien und Bereitstellungsproblem. Angular hat diese Last nicht erfunden. Angular dokumentiert sie nur klar genug, dass niemand so tun kann, sie sei kostenlos.

Das Netteste, was man über dieses Modell sagen kann: Es zentralisiert den Schmerz.

Weniger nett: Der Schmerz bleibt.

Und Angular ist das Framework mit echter eingebauter Unterstützung. Die anderen beweisen denselben Punkt mit anderen Werkzeugen. Die übliche React-Antwort ist react-i18next mit Backend-Laden, Browser-Spracherkennung, Fallback-Sprache und Ladeverhalten, das Suspense auslösen kann, während Übersetzungen noch eintreffen. Offizielles Instanz-Setup, offizielles Hook-Verhalten. Vue nutzt eine eigene vue-i18n-Schicht und trägt weiter Migrationsdruck von der Legacy API zur Composition API. Einstieg in Vue I18n, Composition API, Breaking Changes in v11. Next.js verbessert Routing, sagt aber in seiner Pages-Router-Dokumentation ausdrücklich, die i18n-Routing-Unterstützung ergänze bestehende i18n-Bibliotheken, statt sie zu ersetzen. Pages Router i18n, App Router i18n.

Die versteckte Abgabe ist nicht nur Übersetzung

Die Falle besteht darin zu glauben, i18n bedeute „Zeichenketten in Dateien legen“.

Das war nie die ganze Geschichte, und SPA-Architektur macht die Geschichte darum herum größer:

• URLs brauchen Sprachbedeutung.
• Tiefe Links müssen die Sprache erhalten.
• Der Browserverlauf darf beim Sprachwechsel nicht seltsam reagieren.
• Metadaten müssen die aktuelle Sprache widerspiegeln.
• Ladezustände dürfen nicht kurz die falsche Sprache zeigen.
• Fehlerzustände dürfen nicht versehentlich auf Englisch zurückfallen.
• Zahlen, Daten und Pluralformen brauchen sprachgerechte Formatierung.
• Suchmaschinen und Social Previews müssen die richtige Sprache der richtigen Route zuordnen.
• Inhalt und Komponentenstruktur müssen längere Übersetzungen überstehen, ohne das Layout zu zerbrechen.

Der letzte Punkt verdient die Ohrfeige, die die Frontend-Kultur braucht.

Wenn dein Designsystem nicht aushält, dass Deutsch länger als Englisch wird, liegt das Problem nicht an der Übersetzungsqualität. Das System wurde für einen Screenshot gebaut, nicht für Sprache.

Der breitere Punkt bleibt trotzdem: Eine dokumentenzentrierte Anwendung kann den Server das richtige Sprachdokument vollständig zurückliefern lassen. Eine SPA macht Sprache eher zu einem weiteren reaktiven Subsystem, das zu spät lädt, seltsam ausfällt oder erst mit Suspense-Zeremonie fertig wird, bevor der Nutzer die Seite überhaupt richtig sieht.

Das ist kein Fortschritt.

Das ist Framework-Miete.

Eine bessere Alternative für CTOs

Die Alternative ist nicht, zu einem Gewirr kopierter Server-Templates ohne wiederverwendbare UI zurückzuschwingen.

Die ruhigere Option lautet:

• Sprachgrenzen auf Dokument- und Routenebene halten
• den Server die richtige Sprache als vollständige Seite liefern lassen
• progressive Erweiterung einsetzen, wo reichere Interaktion nützt
• Web Components für wiederverwendbare Interface-Elemente nutzen, ohne die ganze Anwendung in eine permanente Client-Laufzeit zu verwandeln

Dieses Modell lässt sich nach oben leichter erklären, weil es Verantwortung an den Geschäftsbedarf bindet. Eine sprachspezifische URL liefert ein sprachspezifisches Dokument. Ein wiederverwendbares UI-Element bleibt wiederverwendbar, ohne die gesamte Anwendung in SPA-Verhalten zu zwingen. Komponentisierung bleibt erhalten. Moderne Browser-Fähigkeiten auch. Du zahlst nur nicht die volle Architekturabgabe der SPA, wenn das Produkt sie nicht braucht.

Für einen CTO zählt das, weil es bewegliche Teile genau an der Stelle reduziert, an der sie politisch werden. Mehrsprachigkeit sollte eine Frage von Inhalt und Ablauf sein, mit etwas technischer Disziplin darum. Sie sollte nicht zur fragilen Verhandlung zwischen Routing-Strategie, Übersetzungs-Bundles, Laufzeitzustand und den Frontend-Bibliotheken werden, die dieses Jahr gerade in Mode sind.

HTML5 plus PWA deckt mehr ab, als SPA-Fans zugeben

Die PWA-Dokumentation von MDN beschreibt den Funktionsrahmen klar: Eine PWA kann eine Codebasis über mehrere Plattformen teilen und dort, wo Browser und Gerät es unterstützen, installiert werden, offline oder im Hintergrund arbeiten und sich ins Gerät integrieren. Die aktuelle Checkliste von web.dev sagt, eine gute PWA funktioniere in jedem Browser, passe sich jeder Bildschirmgröße an, biete Offline-Verhalten und sei installierbar. MDN-Überblick zu PWAs, PWA-Checkliste von web.dev.

Das ist das meiste von dem, was Geschäftsbeteiligte meinen, wenn sie „App-Verhalten“ sagen.

Sie meinen selten:

• clientseitiges Nachbauen von Routing
• Orchestrierung von Übersetzungs-Bundles
• Hydration-Mismatches
• ein Lokalisierungs-Plugin, dessen Legacy API gerade ausläuft
• Suspense, weil die Beschriftung eines Buttons noch nicht geladen ist

Sie meinen:

• Die Seite soll schnell sein.
• Der Ablauf soll schlechte Verbindung überstehen.
• Die Anwendung soll sich installieren lassen, wenn es nützt.
• Das Interface soll reaktionsschnell wirken.
• Die Sprache soll stimmen.
• Links sollen funktionieren.
• Nutzer sollen sich nicht verlieren.

Das sind Webanforderungen.

Keine SPA-Anforderungen.

Die Branche hat beides jahrelang verwechselt, weil die SPA nach Moderne aussah und der Browser nach gestriger Installationsarbeit.

Jetzt erledigt der Browser den größten Teil der respektablen Arbeit, und Teams schleppen Framework-Schulden noch immer wie ein Erbstück herum.

Web Components passen sauber dazu, weil sie das Nützliche am Komponenten-Denken erhalten, ohne den vollständigen SPA-Kompromiss zu verlangen. Ein Date Picker, eine Preiskarte, ein Statusfeld für Abläufe oder ein lokalisiertes Konto-Widget kann eine Komponente sein. Die ganze Geschäftsanwendung muss nicht zu einer riesigen Client-Laufzeit werden, nur weil einzelne Teile interaktiv sind.

Wann eine SPA wirklich gerechtfertigt ist

Das ist der Teil, in dem der übliche Einwand eine faire Antwort verdient.

Einige Anwendungen wollen tatsächlich eine schwere Client-Laufzeit:

• stark interaktive lokale Werkzeuge
• kollaborative Editoren
• reichhaltige visuelle Modellierungssoftware
• komplexes Offline-first-Verhalten mit viel lokalem Zustand
• Fälle, in denen der Browsertab wirklich mehr wie ein Arbeitsplatzwerkzeug als wie ein Dokumentablauf funktioniert

Gut. Bau die Anwendung, die du wirklich brauchst.

Aber sei ehrlich darüber, was du gekauft hast.

Du hast eine größere Frontend-Oberfläche gekauft. Du hast Zustandsorchestrierung gekauft. Du hast Routing-Logik gekauft. Du hast i18n als Laufzeitarchitektur gekauft. Du hast mehr Chancen auf Lade-Mismatches, mehr Bibliothekskoordination, mehr Migrationen und mehr Arbeit gekauft, um URLs, Metadaten, Barrierefreiheit und Übersetzungen in Einklang zu halten.

Das kann weiterhin der richtige Tausch sein.

Für eine mehrsprachige Business-Webanwendung mit Formularen, Listen, Detailansichten, Freigaben, Rechnungen und Dashboards ist es aber nicht der richtige Standardtausch.

Diese Systeme sind meist Dokumente mit Ablauf, keine Miniatur-Betriebssysteme.

Behandle sie so, und die mehrsprachige Geschichte wird sofort vernünftiger.

Hör auf, das falsche Problem zu lösen

SPAs wurden oft als unvermeidliche Antwort auf „moderne Webanwendungen“ verkauft.

Dieser Anspruch ist schlecht gealtert.

Die Webplattform wurde stärker. PWA-Fähigkeiten reiften. Browser standardisierten mehr nützliches Verhalten. Die Framework-Welt hat sich wieder zu Server-Rendering, Routenbewusstsein und selektiver Client-Ausführung bewegt, weil der Traum vom reinen Client zu viele gewöhnliche Probleme verschlimmert hat.

i18n ist einer der deutlichsten Belege.

Die Rechnung für Mehrsprachigkeit zeigt, ob die Architektur dem Produkt dient oder das Produkt leise der Architektur dient.

Wenn Deutsch und Spanisch hinzuzufügen zu Wochen aus Routenverhandlung, Bundle-Choreografie, Fallback-Debugging und Framework-Bibliotheksdiplomatie führt, ist das Problem nicht, dass Übersetzung von Natur aus unmöglich wäre.

Das Problem ist, dass das Anwendungsmodell zu viel Verantwortung in den Client verlagert hat.

Die meisten Business-Webanwendungen brauchten diesen Kompromiss nie.

Sie brauchten solides HTML, vernünftige URLs, serverseitig gerenderte Sprachgrenzen, progressive Erweiterung dort, wo sie hilft, und PWA-Funktionen dort, wo sie echten Wert schaffen.

Dieser Stack ist weniger modisch.

Gut.

Mode ist, wie Teams am Ende Suspense für die Beschriftung eines Buttons erklären.