Mehrere Sprachen

Die Oberfläche in mehreren Sprachen ausliefern — und die Seiten selbst übersetzen.

Die Zeichenketten des Themes sind in sieben Locales übersetzt. Eine Seite bedient die Teilmenge, die sie will, übersetzt die Zeichenketten, die sie selbst konfiguriert hat — und, wenn sie mag, auch die Seiten.

Schritte

Schränke die Liste mit duxt.locales ein.
```
locales: ['en-GB', 'de-DE']
```
Nicht i18ns eigenes locales-Array: Das führt über Ebenen hinweg zusammen, statt zu ersetzen — dort zwei zu deklarieren lässt die anderen fünf geroutet und in hreflang angekündigt.
Wähle die unpräfigierte in nuxt.config.ts mit i18n.defaultLocale. Sie ist URL-relevant: Sie später zu ändern verschiebt jede Seite in beide Richtungen zugleich.
Übersetze deine eigenen Zeichenketten. Für eine Handvoll kostet die Datensatzform weniger als eine Locale-Datei je Sprache:
```
sections: [
  {
    label: { 'en-GB': 'Guides', 'de-DE': 'Anleitungen' },
    to: '/guides',
    icon: 'lucide:book-open'
  }
]
```
Für mehr als eine Handvoll registriere eigene i18n-Schlüssel und schreibe den Schlüssel. Greife nicht zu duxt.defaults.* — das sind die internen Schlüssel der Ebene, und eine Umbenennung dort bräche deine Seite lautlos.
Setze den Ursprung. hreflang ist relativ nicht gültig, es braucht also i18n.baseUrl oder NUXT_PUBLIC_I18N_BASE_URL.
Übersetze die Seiten, wenn du magst. Ein Ordner je Sprache innerhalb der Quelle; die Standard-Locale bleibt, wo sie ist, und verschiebt keine URL:
```
sources: [{ path: 'docs', locales: ['en-GB', 'de'] }]
```

docs/

index.md
1.getting-started
index.md
de
index.md

Übersetze so wenige Seiten, wie du willst — alles andere fällt zurück, mit einem Banner, das dem Leser sagt, warum.

Öffne eine Seite unter jeder Locale und prüfe, ob die Oberfläche die Sprache gewechselt hat, der Pfad weiterhin auflöst und keine konfigurierte Beschriftung als roher Schlüssel erscheint.

Nur manche Versionen, oder ein anderes Repository

locales an einem Ref überschreibt das der Quelle, und das ist die übliche Form: Die aktuelle Version ist übersetzt, die zwei dahinter nicht.

{
  path: 'docs',
  locales: ['en-GB', 'de'],
  refs: [
    { tag: 'v2.0.0' },                     // beide Sprachen
    { tag: 'v1.0.0', locales: ['en-GB'] }  // nur das Original
  ]
}

Die Objektform verschiebt eine Sprache ganz woandershin — in ein eigenes Repository, mit eigenen Betreuern und eigenem Tempo:

locales: ['en-GB', { locale: 'de', repo: 'acme/docs-de', path: 'docs' }]

Genau das tun React und Vue außerhalb ihres Werkzeugs, mit de.react.dev und der Organisation vuejs-translations, weil Übersetzer nach eigenem Zeitplan und eigenem Review arbeiten. Hier ist es ein Quelleneintrag statt einer zweiten Website — ein Suchindex, ein Sprachumschalter.

Was eine Übersetzung im Build kostet

Grob zwei Sekunden Build und 0,6 MB Datenbank je Sprache × Version × Repository, gemessen linear bis mindestens 200 Collections. Jede Version jedes Repositories zu übersetzen multipliziert alle drei; nur die aktuelle Version zu übersetzen ist das, was die meisten Projekte tatsächlich tun.

Wenn eine Seite keine Übersetzung hat

Der Leser bekommt die nächstliegende Sprache, die sie hat, mit einem Banner, und die Seite trägt noindex plus ein Canonical, das auf die Sprache zeigt, in der sie wirklich ist. Die Kette — Locale, Basissprache, Geschwisterregion, fallbackLocale, Original — steht in Lokalisierung.

Checkliste

duxt.locales listet genau die Locales, die du bedienst
/sitemap.xml enthält einen Eintrag je Seite und Locale, und keine weiteren
hreflang-Links sind absolut
Keine konfigurierte Beschriftung erscheint als roher Schlüssel
Ein Sprachwechsel hält den Leser auf derselben Seite
Eine nicht übersetzte Seite zeigt das Rückfall-Banner, keinen 404
duxt.sourceOptions.defaultLocale passt zu i18n.defaultLocale

War diese Seite hilfreich?

#Schritte

#Nur manche Versionen, oder ein anderes Repository

#Wenn eine Seite keine Übersetzung hat

#Checkliste

Schritte

Nur manche Versionen, oder ein anderes Repository

Wenn eine Seite keine Übersetzung hat

Checkliste