Svelte i18n vs. automatische Übersetzung: Was sollten Sie nutzen?
SvelteKit hat über einfaches URL-Routing hinaus kein integriertes i18n. Die beiden Hauptoptionen sind eine String-Extraktionsbibliothek — svelte-i18n oder Paraglide-JS — oder DOM-basierte automatische Übersetzung. Die richtige Wahl hängt vom Zeitplan, der Teamgröße und der Content-Aktualisierungsfrequenz Ihres Projekts ab.
Der String-Extraktions-Ansatz: svelte-i18n und Paraglide-JS
svelte-i18n ist die am häufigsten genutzte i18n-Bibliothek im Svelte-Ökosystem. Sie funktioniert mit einem vertrauten Message-File-Modell: Sie speichern Übersetzungen in JSON-Dateien mit Locale-Schlüsseln und referenzieren Strings in Templates über die $_()-Syntax, gestützt auf einen reaktiven Svelte-Store.
// src/lib/i18n.js
import { addMessages, init, getLocaleFromNavigator } from 'svelte-i18n'
import en from './locales/en.json'
import fr from './locales/fr.json'
addMessages('en', en)
addMessages('fr', fr)
init({ fallbackLocale: 'en', initialLocale: getLocaleFromNavigator() })
In Svelte-Templates importieren Sie den $_-Store und rufen ihn als Funktion auf:
<script>
import { _ } from 'svelte-i18n'
</script>
<h1>{$_('home.title')}</h1>
<p>{$_('home.description')}</p>
Paraglide-JS von inlang verfolgt einen anderen Ansatz: Es ist Compile-Time-basiert, typsicher und generiert zur Build-Zeit vollständig typisierte Message-Funktionen aus Ihren Locale-Dateien. Das bedeutet, Sie erhalten IDE-Autovervollständigung für jeden Übersetzungsschlüssel und einen Build-Fehler, wenn Sie einen nicht existierenden Schlüssel referenzieren. Es ist neuer, gewinnt aber in der SvelteKit-Community schnell an Bedeutung als Alternative für Teams, die stärkere Garantien wünschen.
Beide Bibliotheken teilen denselben grundlegenden Workflow: jeden String aus Ihren Komponenten in Locale-JSON-Dateien extrahieren, eine Datei pro Sprache pflegen, diese Dateien bei jeder Textänderung aktualisieren und Plurale sowie Interpolation explizit in der Message-Syntax behandeln. Für eine mittelgroße SvelteKit-App dauert die initiale Einrichtung typischerweise ein bis drei Tage — und das, bevor die Übersetzungen selbst eingetragen werden.
Der Ansatz der automatischen Übersetzung
Die Alternative besteht darin, auf DOM-Ebene statt auf Komponentenebene zu arbeiten. Sie fügen einen Script-Tag zu src/app.html vor </body> hinzu, und Lingvit übernimmt den Rest:
<!-- src/app.html -->
<body data-sveltekit-preload-data="hover">
<div style="display: contents">%sveltekit.body%</div>
<script src="https://cdn.lingvit.com/widget.bundle.js"
data-project-id="YOUR_PROJECT_ID"></script>
</body>
Lingvits MutationObserver beobachtet DOM-Änderungen und übersetzt Textknoten, sobald sie erscheinen. Das deckt das gesamte Spektrum von SvelteKits Reaktivitätsmodell ab:
- →Routenübergänge. SvelteKits clientseitige Navigation ersetzt den Seitenkörper im DOM. Der MutationObserver erkennt den neuen Content sofort und übersetzt ihn, bevor der Nutzer ihn sieht.
- →Reaktive Store-Aktualisierungen. Wenn sich ein Svelte-Store ändert und eine DOM-Aktualisierung verursacht — ein Zähler, eine geladene Liste, ein bedingter Block — werden die neuen Knoten automatisch übersetzt.
- →
$derived-Werte. Svelte 5s Rune-basierte Reaktivität schreibt weiterhin ins DOM. Lingvit beobachtet die resultierenden Mutationen — die reaktive Primitive ist irrelevant. - →Keine String-Extraktion, keine Locale-Dateien. Neuer Content wird übersetzt, sobald er im DOM erscheint. Es gibt nichts in der Versionskontrolle zu aktualisieren, wenn sich Texte ändern.
Redaktionelle Überschreibungen sind über das Dashboard verfügbar, wenn Sie für einen bestimmten String eine von Menschen geprüfte Übersetzung wünschen, ohne Code anzufassen.
Wie sie sich vergleichen
Die beiden Ansätze unterscheiden sich in jeder Dimension, die in der Praxis zählt:
Einrichtungszeit
svelte-i18n oder Paraglide-JS zu einer bestehenden SvelteKit-App hinzuzufügen bedeutet, jede Komponente anzufassen, die Text rendert — wörtliche Strings durch $_('key')-Aufrufe zu ersetzen und Locale-Dateien aufzubauen. Für eine mittelgroße App ist das ein mehrtägiger Aufwand. Das Hinzufügen von Lingvit nutzt einen einzigen Script-Tag und einen geführten Einrichtungsablauf; die tatsächliche Einrichtungszeit variiert je nach App.
Laufende Wartung
Bei String-Extraktion bedeutet jede Textänderung, jede Locale-Datei zu aktualisieren. Verpassen Sie eine, fällt eine Sprache stillschweigend auf Englisch zurück. Automatische Übersetzung hat null laufende Wartung: Neue Strings werden beim ersten Rendering ohne Entwicklereingriff behandelt.
Entwicklererfahrung
Paraglide-JS bietet typsichere Übersetzungsschlüssel mit IDE-Autovervollständigung — eine echt gute DX, wenn Sie ein Produkt bauen, bei dem jeder String geplant ist. Für Marketing-Websites oder sich schnell ändernde SaaS-UIs ist das Ersetzen wörtlicher Strings durch Funktionsaufrufe überall Reibung, die die Iteration verlangsamt. Lingvit erfordert überhaupt keine Änderungen an Svelte-Komponenten.
SEO
Beide Ansätze können SEO-freundliche Locale-URLs unterstützen (/fr/, /de/). Lingvit verarbeitet dynamisch gerenderten Content automatisch — übersetzter Text, den SvelteKit über clientseitige Navigation oder asynchrone Daten einfügt, wird ohne zusätzliche Konfiguration erfasst.
Kontrolle
String-Extraktion gibt Ihnen Kontrolle pro Schlüssel: jede Übersetzung ist eine explizite, in der Versionskontrolle gespeicherte Entscheidung. Automatische Übersetzung gibt Ihnen Prüfung auf Dashboard-Ebene: Sie können einzelne Strings über die Lingvit-Oberfläche einsehen und überschreiben, ohne Code anzufassen. Welches Kontrollniveau Sie benötigen, hängt vom Risikoprofil Ihres Contents ab.
Wann Sie svelte-i18n oder Paraglide-JS wählen sollten
Sie benötigen Compile-Time-Typsicherheit
Paraglide-JS generiert typisierte Message-Funktionen aus Ihren Locale-Dateien. Wenn Ihr Team Wert darauf legt, fehlende Übersetzungsschlüssel zur Build-Zeit zu erkennen, und IDE-Autovervollständigung für jeden Schlüssel wünscht, ist der Compile-Time-Ansatz ein echter Produktivitätsgewinn — besonders in größeren Teams, in denen mehrere Entwickler Texte anfassen.
Ihre Übersetzer arbeiten mit Locale-Dateien
Wenn Sie einen etablierten Übersetzungs-Workflow haben — Übersetzer, die Crowdin, Weblate oder ein TMS nutzen, das sich in JSON-Locale-Dateien integriert — passt svelte-i18n natürlich. Das Locale-JSON-Format ist eine Lingua franca für professionelle Übersetzungstools.
Jeder String muss vor Veröffentlichung geprüft werden
Rechtliche, medizinische oder behördliche Anwendungen erfordern oft explizite Freigabe jedes übersetzten Strings, bevor er in Produktion geht. String-Extraktion gibt Ihnen diesen expliziten Audit-Trail pro Schlüssel — eine Übersetzung geht nur live, wenn ein Mensch den Locale-Datei-Eintrag freigegeben hat.
Sie haben dedizierte i18n-Engineering-Zeit
Locale-Dateien präzise über mehrere Sprachen zu pflegen, während sich das Produkt weiterentwickelt, erfordert kontinuierliche Engineering-Aufmerksamkeit. Wenn Sie jemanden haben, dessen Aufgabe es ist, Übersetzungen aktuell zu halten, ist der Aufwand handhabbar. Ohne diese Person tendieren Locale-Dateien dazu, hinter dem Produkt zurückzubleiben.
Wann Sie automatische Übersetzung wählen sollten
Sie benötigen mehrsprachige Unterstützung heute
svelte-i18n nachträglich in eine bestehende SvelteKit-Anwendung einzubauen bedeutet, jede Komponente anzufassen, die Text rendert. Ein DOM-basiertes Übersetzungs-Widget erfordert nur eine Script-Tag-Änderung — keine Komponenten-Neuschreibungen, kein Locale-Datei-Bootstrapping, keine Build-Pipeline-Änderungen.
Ihr Content ändert sich häufig
Blogs, Marketing-Websites und SaaS-UIs, die sich wöchentlich ändern, sind mit String-Extraktion schlecht bedient — jede Content-Änderung bedeutet, jede Locale-Datei zu aktualisieren, oder in Kauf zu nehmen, dass manche Sprachen veraltete Texte zeigen. Automatische Übersetzung verarbeitet neuen Content beim ersten Rendering ohne Entwicklereingriff.
Sie haben keine dedizierten i18n-Ressourcen
Die meisten Produktteams haben keinen i18n-Engineer. Ohne einen sammeln Locale-Dateien schnell technische Schulden an: fehlende Schlüssel, veraltete Strings, unübersetzte Platzhalter. Automatische Übersetzung entfernt den Wartungsaufwand vollständig — die Übersetzungsebene hält sich selbst aktuell, während sich das DOM ändert.
Sie fügen einer bestehenden SvelteKit-App Sprachen hinzu
Wenn Ihre App bereits existiert und Sie mehrsprachige Unterstützung als neue Anforderung hinzufügen, ist der Aufwand für den nachträglichen Einbau von String-Extraktion proportional zur Anzahl der bereits geschriebenen Komponenten. Lingvit erfordert null Änderungen an bestehenden Svelte-Komponenten — fügen Sie den Script-Tag hinzu und konfigurieren Sie Sprachen im Dashboard.
Häufig gestellte Fragen
- Funktioniert automatische Übersetzung mit SvelteKits dateibasiertem Routing?
- Ja. SvelteKits clientseitige Navigation ersetzt Seiteninhalte im DOM, was Lingvits MutationObserver sofort erkennt. Jeder Routenwechsel löst einen neuen Übersetzungsdurchgang für den neuen Content aus.
- Kann ich svelte-i18n für URL-Routing und automatische Übersetzung für Content nutzen?
- Ja. Die beiden Ansätze arbeiten auf unterschiedlichen Ebenen. Sie können svelte-i18n oder Paraglide-JS rein für Locale-bewusstes URL-Routing (/fr/, /de/) nutzen, während Lingvit die gesamte Übersetzung der Textinhalte übernimmt.
- Verarbeitet es aus Svelte-Stores abgeleiteten Content?
- Ja. Wenn eine Aktualisierung eines Svelte-Stores reaktive DOM-Mutationen verursacht, beobachtet Lingvit die resultierenden DOM-Änderungen und übersetzt die neuen Textknoten.
- Wie geht automatische Übersetzung mit Pluralen und interpolierten Werten um?
- Lingvit übersetzt den final gerenderten String — nachdem Svelte Variablen interpoliert und Plurale aufgelöst hat. Sie müssen keine Übersetzungsschlüssel für dynamische Strings schreiben; der vollständig gerenderte Text wird übersetzt.
Weitere Anleitungen
Fügen Sie Ihrer SvelteKit-App Sprachen hinzu
Funktioniert mit SvelteKit, Svelte-5-Runes und reaktiven Stores. Ein Script-Tag, keine Komponenten-Neuschreibungen.