Astro-Internationalisierung: i18n-Routing vs. automatische Übersetzung
Astro v3.5 führte natives i18n-Routing ein — URL-Präfixe wie /fr/, /de/, Spracherkennung und getRelativeLocaleUrl(). Das ist solide Infrastruktur. Aber Routing ist keine Übersetzung. Astros i18n-Routing zeigt Besuchern, wohin sie gehen sollen; es übersetzt nicht, was sie dort sehen. Dieser Artikel behandelt, was Astro-i18n tatsächlich bietet, was nicht, und wie Sie echte Content-Übersetzung hinzufügen.
Was Astros integriertes i18n-Routing leistet
Seit v3.5 liefert Astro einen First-Party-i18n-Konfigurationsblock in astro.config.mjs. Wenn Sie dort Ihre Locales deklarieren, erhalten Sie sofort URL-basiertes Routing:
Mit dieser Konfiguration generiert Astro automatisch Locale-präfixierte URL-Pfade — Seiten unter src/pages/fr/ werden unter /fr/about, /fr/pricing ausgeliefert, und so weiter. Die Routing-Ebene stellt außerdem zwei URL-Helfer bereit:
getRelativeLocaleUrl(locale, path)— erstellt einen Locale-präfixierten Pfad relativ zum Site-Root.getAbsoluteLocaleUrl(locale, path)— dasselbe, aber mit vorangestelltem vollständigen Origin — nützlich für Canonical-Tags und Sitemaps.- Spracherkennung über den
Accept-Language-Header im Server-Modus (SSR) — Astro kann Besucher automatisch zu ihrer bevorzugten Locale weiterleiten.
Was es nicht leistet: Ihren Content übersetzen. Das Aktivieren des i18n-Konfigurationsblocks liefert Ihnen URL-Struktur und Routing-Helfer. Der eigentliche Content unter /fr/about muss weiterhin auf Französisch geschrieben werden — entweder durch Erstellen von src/pages/fr/about.astro mit manuell übersetztem Text oder durch Content Collections mit Locale-spezifischen Einträgen. Die Routing-Ebene ist rein strukturell.
Der traditionelle Ansatz: Content Collections pro Locale
Das gängigste Muster für mehrsprachige Astro-Websites kombiniert die Routing-Ebene mit Locale-spezifischen Content-Verzeichnissen. Für einen Blog bedeutet das, die Content-Collection nach Sprache zu strukturieren:
Dieser Ansatz funktioniert gut unter bestimmten Bedingungen: Die Website ist klein, ein fest zugeordneter Übersetzer betreut jedes Locale-Verzeichnis, und der Content ändert sich selten. Die Struktur ist explizit und die Ausgabe nachvollziehbar — jede übersetzte Datei ist ein eigenständiges Artefakt mit eigener Versionshistorie.
Die Wartungsrechnung wendet sich schnell gegen Sie. Zwanzig Seiten über fünf Sprachen bedeuten 100 separate Dateien, die synchron gehalten werden müssen. Jedes Mal, wenn die englische Version einer Seite aktualisiert wird, hinken die vier Locale-Varianten hinterher, bis ein Übersetzer nachzieht. Content-Drift — bei dem die englische Seite neu geschrieben, aber die französische Version sechs Monate veraltet ist — ist das häufigste Fehlermuster dieses Ansatzes. In großem Maßstab neigt der Aufwand für die Locale-Parität dazu, in gutartige Vernachlässigung überzugehen.
Automatische Übersetzung: ein Script, alle Sprachen
Die Alternative erfordert keine Content-Duplizierung. Fügen Sie Lingvits Script vor dem schließenden </body>-Tag zu Ihrem Astro-Layout hinzu:
Das ist die vollständige Integration. Von dort aus beobachtet Lingvit das gerenderte DOM und übersetzt es in die Zielsprachen, die Sie im Dashboard aktiviert haben. Ein paar Eigenschaften dieses Ansatzes sind erwähnenswert:
Funktioniert über alle Astro-Ausgabemodi hinweg
Statische Ausgabe (output: "static"), serverseitig gerendert (output: "server") und Hybrid-Modus erzeugen allesamt HTML, das Lingvit übersetzen kann. Das Widget arbeitet clientseitig, nachdem die Seite geladen wurde, sodass der Ausgabemodus keinen Einfluss auf die Funktionsweise hat.
Übersetzt Astro-Islands
Mit React, Vue, Svelte oder Solid gebaute Islands hydratisieren clientseitig und rendern ihre Ausgabe in das DOM. Lingvits MutationObserver erfasst diese Knoten, sobald sie erscheinen — unabhängig davon, welches Framework die Island antreibt oder welche Hydration-Direktive (client:load, client:visible usw.) verwendet wurde.
Neuer Content wird automatisch übersetzt
Wenn Sie einen neuen Blogbeitrag veröffentlichen oder eine Landing-Page aktualisieren, spiegeln die übersetzten Versionen die Änderung beim nächsten Seitenaufruf wider. Es gibt keine Locale-Dateien zu aktualisieren und keine Übersetzer-Warteschlange zu entblockieren.
Redaktionelle Kontrolle über das Dashboard
Jeder automatisch übersetzte String kann im Lingvit-Dashboard geprüft und überschrieben werden. Überschreibungen bleiben bestehen — wenn Sie einen Produktnamen oder einen Markenbegriff auf Französisch korrigieren, gilt diese Korrektur jedes Mal, wenn dieser String erscheint.
Können Sie Astro-i18n-Routing mit automatischer Übersetzung kombinieren?
Ja, und das ist der empfohlene Ansatz für SEO-bewusste Websites. Die beiden Systeme arbeiten auf unterschiedlichen Ebenen und ergänzen sich sauber.
Astros integriertes Routing übernimmt die URL-Struktur. URLs wie /fr/about und /de/pricing sind das, was Suchmaschinen beim Indexieren mehrsprachiger Inhalte nutzen — jede Locale erhält ihre eigene crawlbare URL, ihre eigene Canonical und ihre eigenen hreflang-Signale. Das ist die richtige Grundlage für mehrsprachiges SEO, und Astros Routing-Ebene liefert sie gut.
Lingvit übernimmt die eigentliche Content-Übersetzung innerhalb dieser URLs. Statt eine separate src/pages/fr/about.astro mit handübersetztem Text zu pflegen, behalten Sie eine einzige Quelldatei und lassen Lingvit ihre gerenderte Ausgabe automatisch übersetzen. Das Ergebnis sind SEO-indexierte URLs pro Sprache mit automatischer Content-Übersetzung und redaktioneller Kontrolle — ohne Ihre Quelldateien zu duplizieren.
Zusammenfassung der kombinierten Einrichtung
- 1Konfigurieren Sie Astros
i18n-Block inastro.config.mjsmit Ihren Zielsprachen. Dies legt die URL-Struktur fest. - 2Fügen Sie den Lingvit-Script-Tag zu
src/layouts/Layout.astrovor</body>hinzu. Dies übernimmt die Content-Übersetzung. - 3Behalten Sie eine einzige Quelldatei pro Seite. Schreiben und pflegen Sie Content in einer Sprache; Lingvit übernimmt alle Locale-Varianten automatisch.
Wann welcher Ansatz sinnvoll ist
Die Wahl ist nicht immer automatische Übersetzung. Es gibt Situationen, in denen der traditionelle Locale-Datei-Ansatz eindeutig die richtige Wahl ist:
Astro-Routing + Locale-Dateien
- ✓Kleine Website mit fest zugeordnetem Übersetzer pro Sprache
- ✓Content, der sich nach Veröffentlichung selten ändert
- ✓Rechtlicher oder regulierter Text, der explizite Freigabe pro String erfordert
- ✓Community-übersetztes Open-Source-Projekt
Astro-Routing + automatische Übersetzung
- ✓Größere Websites, bei denen die Parität von Locale-Dateien schwer zu pflegen ist
- ✓Content, der sich häufig ändert (Blog, Changelog, Doku)
- ✓Teams ohne eigene Übersetzungsressourcen
- ✓Sprachen zu einer bestehenden Astro-Website ohne i18n hinzufügen
Häufig gestellte Fragen
- Funktioniert automatische Übersetzung mit Astro-Islands?
- Ja. React-, Vue-, Svelte- und Solid-Islands hydratisieren clientseitig und rendern ihre Ausgabe in das DOM. Lingvits MutationObserver erkennt diesen Content, sobald er erscheint, und übersetzt ihn — unabhängig davon, welches Framework die Island nutzt.
- Funktioniert es mit Astros statischer Ausgabe (SSG)?
- Ja. Lingvit läuft vollständig clientseitig, nachdem die Seite geladen wurde. Bei statischer Ausgabe wird das HTML vorab erstellt, und Lingvit übersetzt es im Browser. Bei SSR läuft Lingvit nach der Hydration. Beides funktioniert aus Lingvits Sicht identisch.
- Wie interagiert Lingvit mit Astros integriertem i18n-Routing?
- Sie arbeiten auf unterschiedlichen Ebenen. Astro-Routing übernimmt die URL-Struktur (/fr/, /de/) und Weiterleitungen. Lingvit übernimmt die tatsächliche Übersetzung der Textinhalte. Sie können beides zusammen nutzen: Astro für Routing, Lingvit für Content.
- Übersetzt es Astro Content Collections?
- Ja. Content-Collection-Inhalte (MDX, Markdown) werden von Astro zur Build-Zeit in HTML gerendert. Dieses HTML wird dann von Lingvit clientseitig beobachtet und übersetzt, wenn die Seite im Browser eines Besuchers geladen wird.
Weitere Anleitungen
Fügen Sie Sprachen zu Ihrer Astro-Website hinzu
Funktioniert mit statischen, SSR- und Hybrid-Astro-Projekten. Ein Script-Tag, keine Content-Duplizierung.