SaaS-Lokalisierung: international werden, ohne Ihre App neu zu schreiben (2026)
Die meisten SaaS-Produkte verschieben die Internationalisierung über Jahre — nicht weil sie unwichtig ist, sondern weil der konventionelle Ansatz ein vollständiges Engineering-Projekt erfordert, bevor auch nur ein Nutzer eine übersetzte Zeichenkette sieht. Dieser Leitfaden zeigt, wie die Alternativen in der Praxis aussehen.
Das SaaS-Lokalisierungsproblem
Die Standardempfehlung für SaaS-Lokalisierung lautet, eine i18n-Bibliothek einzuführen: react-i18next, i18next oder formatjs. Jede dieser Bibliotheken erfordert dieselbe mehrstufige Migration:
- →Jeden UI-Text in einen
t()-Aufruf wrappen, was Hunderte von Komponenten im gesamten Codebase betrifft. - →Eine JSON-Übersetzungsdatei pro Zielsprache erstellen und pflegen.
- →Typsichere Schlüsseldefinitionen hinzufügen, damit fehlende Übersetzungen bereits zur Kompilierzeit auffallen.
- →Pluralisierungsregeln implementieren — die sich zwischen Sprachen deutlich unterscheiden.
- →Einen Übersetzungsworkflow einrichten, damit neue UI-Texte vor dem Ausliefern übersetzt werden.
Für ein typisches SaaS-Produkt mit ein bis zwei Jahren Entwicklung im Rücken ist das ein 2–4-wöchiges Engineering-Projekt, bevor überhaupt ein Nutzer eine übersetzte Zeichenkette sieht. Teams verschieben es rational, bis internationale Umsätze nicht mehr ignoriert werden können.
Was tatsächlich übersetzt werden muss
Bevor Sie sich für einen Ansatz entscheiden, hilft es, aufzulisten, was „das Produkt“ in Übersetzungsbegriffen tatsächlich bedeutet. Für eine typische SaaS-Anwendung:
| Inhaltstyp | Im DOM? | Widget-Ansatz |
|---|---|---|
| UI-Texte, Navigation, Schaltflächen | Ja | Automatisch abgedeckt |
| Fehlermeldungen und Benachrichtigungen | Ja (wenn angezeigt) | Abgedeckt via MutationObserver |
| Onboarding-Abläufe und Hilfetexte | Ja | Automatisch abgedeckt |
| Dynamische Inhalte nach API-Antworten | Ja (nach dem Rendern) | Abgedeckt via MutationObserver |
| E-Mail-Vorlagen | Nein | Außerhalb des Umfangs — separate Lösung nötig |
| In JS-Bundles fest codierte Texte | Nur wenn gerendert | Abgedeckt, wenn ins DOM gerendert |
Zum Anzeigen aller Spalten horizontal scrollen.
Der Großteil dessen, womit Nutzer in einer Web-App interagieren, wird ins DOM gerendert. Das macht DOM-basierte Übersetzung zu einem praktischen Ausgangspunkt, auch wenn sie nicht jeden Grenzfall abdecken kann.
Die DOM-basierte Alternative
Ein Script-Tag-Übersetzungswidget verfolgt einen anderen Ansatz: Statt Ihren Quellcode zu instrumentieren, beobachtet es das gerenderte HTML im Browser und übersetzt es direkt an Ort und Stelle.
Der Mechanismus funktioniert so:
- 1Beim Laden der Seite durchläuft das Script das DOM und sammelt Textknoten, die es für effiziente API-Aufrufe in Blöcke gruppiert.
- 2Übersetzte Zeichenketten werden von der API zurückgegeben und ins DOM eingesetzt. Der Originaltext bleibt im Speicher erhalten.
- 3Ein MutationObserver beobachtet neue DOM-Knoten — ausgelöst durch Navigation, das Öffnen von Modals oder API-Antworten, die eine Liste befüllen — und übersetzt sie sofort.
- 4Gespeicherte Übersetzungen können wiederverwendet werden, ohne eine weitere Anbietergenerierungsanfrage auszulösen.
Testen Sie das Umschaltverhalten auf repräsentativen Geräten und Netzwerken. Der Script-Tag-Ansatz kann den Quellcode Ihrer Anwendung unangetastet lassen.
Worauf Sie achten sollten
Der DOM-basierte Ansatz deckt den 80–90 %-Fall gut ab, aber es gibt spezifische Situationen, die Sie für Ihr Produkt bewerten sollten:
Texte, die nie ins DOM gerendert werden
Wenn Ihre App eine Zeichenkette in JavaScript baut und an eine Toast-Bibliothek oder einen Alert übergibt, kann die zwischengeschaltete JS-Zeichenkette erstellt werden, bevor sie das DOM erreicht. Sobald sie einen DOM-Textknoten erreicht, deckt das Widget sie ab — aber wenn die Zeichenkette in einem nativen Browser- alert() oder einem Nicht-DOM-Overlay angezeigt wird, wird sie nicht übersetzt.
Nutzergenerierte Inhalte
Inhalte, die Nutzer schreiben — Kommentare, Notizen, Rich-Text-Editoren — werden beim Rendern übersetzt, was möglicherweise nicht erwünscht ist. Nutzen Sie die Ausschluss-Selektoren von Lingvit, um UGC-Container als nicht übersetzbar zu markieren.
Backend-E-Mail-Vorlagen
Transaktionale E-Mails (Willkommen, Rechnung, Passwort zurücksetzen) werden serverseitig gesendet und laufen nie durch das DOM. Diese benötigen eine separate Behandlung — entweder über die Lokalisierungsfunktionen Ihres E-Mail-Dienstes oder durch separate E-Mail-Vorlagen pro Sprache.
API-Antwort-Zeichenketten
Wenn Ihr Backend Zeichenketten zurückgibt, die direkt angezeigt werden (z. B. Statuslabels aus einer API), sind sie abgedeckt, sobald sie ins DOM gerendert werden. Wenn dieselben Zeichenketten in nicht gerenderten Kontexten erscheinen (heruntergeladene CSVs, Webhooks), liegen diese außerhalb des Umfangs.
Einrichtung für eine React/Next.js-SaaS
Lingvit zu einer bestehenden React- oder Next.js-Anwendung hinzuzufügen dauert drei Schritte und erfordert keine Codeänderungen an Ihren Komponenten.
- 1
Registrieren und ein Projekt erstellen
Erstellen Sie ein Projekt unter app.lingvit.com und registrieren Sie die Domain Ihrer Anwendung. Sie erhalten einen Projektschlüssel.
- 2
Das Script-Tag zu Ihrem Root-Layout hinzufügen
Fügen Sie es im Next.js App Router zu
app/layout.tsxhinzu:<Script src="https://cdn.lingvit.com/widget.bundle.js?v=1" strategy="afterInteractive" />Für Pages Router oder vanilla React fügen Sie das
<script>-Tag vor dem schließenden</body>ein. - 3
Zielsprachen im Dashboard auswählen
Wählen Sie Ihre Zielsprachen im Dashboard aus. Der Sprachumschalter wird automatisch eingefügt. Übersetzungen beginnen mit der Generierung beim ersten Seitenbesuch für jede Sprache.
Redaktionelle Kontrolle
Automatische Übersetzung bewältigt das Volumen — aber Produktnamen, Rechtsbegriffe und markenspezifische Sprache brauchen menschliche Aufsicht. Lingvit bietet mehrere Kontrollmechanismen:
Übersetzungs-Browser
Überprüfen Sie jede übersetzte Zeichenkette pro Sprache und überschreiben Sie jede automatische Übersetzung direkt im Dashboard. Überschreibungen werden dauerhaft gespeichert und haben Vorrang vor automatischen Übersetzungen für diese Zeichenkette.
Glossarbegriffe
Definieren Sie Begriffe, die nie übersetzt werden dürfen — Produktnamen, Funktionsnamen, markenspezifische Terminologie. Glossareinträge gelten global über alle Sprachen hinweg.
Veröffentlichungskontrollen
Übersetzungen gehen erst live, wenn Sie sie veröffentlichen. Erstellen und überprüfen Sie eine Sprache als Entwurf, bevor sie für Nutzer sichtbar wird, und veröffentlichen Sie dann ohne ein Code-Deployment.
Häufig gestellte Fragen
- Funktioniert das Widget mit React Concurrent Features und Suspense?
- Ja. Der MutationObserver-Ansatz ist framework-agnostisch — er beobachtet die finale DOM-Ausgabe unabhängig davon, wie React rendert. Concurrent Mode, Suspense-Boundaries und Streaming-SSR erzeugen alle DOM-Knoten, die der Observer normal handhabt.
- Was ist mit SSR — wird übersetzter Inhalt von Suchmaschinen indexiert?
- Clientseitige Widget-Übersetzung bedeutet, dass die Quell-HTML die Originalsprache enthält. Für SaaS-Dashboards hinter Authentifizierung spielt das selten eine Rolle. Für öffentliche Marketingseiten, bei denen mehrsprachiges SEO wichtig ist, ist ein Script-Tag-Ansatz weniger geeignet als serverseitig gerendertes i18n.
- Kann ich das neben einer bestehenden i18n-Bibliothek für neue Funktionen nutzen?
- Ja. Lingvit übersetzt, was immer im DOM steht — es ist egal, ob Zeichenketten aus einer i18n-Bibliothek, einem fest codierten String oder einer API-Antwort stammen. Sie können react-i18next für neue Funktionen nutzen und Lingvit den Rest während einer Migrationsphase abdecken lassen.
Weitere Anleitungen
Diese Woche international werden
Fügen Sie Ihrer SaaS Übersetzung hinzu, ohne eine Zeile Code zu ändern.