Aller au contenu
duxt

Plusieurs langues

Servir l’interface en plusieurs langues, et traduire les pages elles-mêmes.

Les chaînes du thème sont traduites dans sept locales. Un site sert le sous-ensemble qu’il veut, traduit les chaînes qu’il a lui-même configurées et — s’il le souhaite — les pages aussi.

Étapes

  1. Restreignez la liste avec duxt.locales.
    locales: ['en-GB', 'fr-FR']

    Pas le tableau locales d’i18n : celui-là fusionne entre les couches au lieu de remplacer, donc en déclarer deux là laisse les cinq autres routées et annoncées dans hreflang.
  2. Choisissez celle sans préfixe dans nuxt.config.ts avec i18n.defaultLocale. Elle est déterminante pour les URL : la changer plus tard déplace toutes les pages dans les deux sens à la fois.
  3. Traduisez vos propres chaînes. Pour une poignée, la forme d’enregistrement coûte moins qu’un fichier de locale par langue :
    sections: [
  {
    label: { 'en-GB': 'Guides', 'fr-FR': 'Guides' },
    to: '/guides',
    icon: 'lucide:book-open'
  }
]

    Au-delà d’une poignée, enregistrez vos propres clés i18n et écrivez la clé. N’allez pas chercher duxt.defaults.* — ce sont les clés internes de la couche, et un renommage là-bas casserait votre site en silence.
  4. Indiquez l’origine. hreflang n’est pas valide en relatif : il faut donc i18n.baseUrl ou NUXT_PUBLIC_I18N_BASE_URL.
  5. Traduisez les pages, si vous le voulez. Un dossier par langue à l’intérieur de la source ; la locale par défaut reste où elle est et ne déplace aucune URL :
    sources: [{ path: 'docs', locales: ['en-GB', 'fr'] }]
docs/
  • index.md
  • 1.getting-started
  • index.md
  • fr
  • index.md

Traduisez aussi peu de pages que vous voulez — tout le reste retombe sur l’original, avec un bandeau qui en explique la raison au lecteur.

  1. Ouvrez une page dans chaque locale et vérifiez que l’interface a changé de langue, que le chemin se résout toujours et qu’aucun libellé configuré ne s’affiche en clé brute.

Seulement certaines versions, ou un autre dépôt

locales sur une ref l’emporte sur celui de la source, ce qui est la forme habituelle : la version courante est traduite et les deux précédentes non.

{
  path: 'docs',
  locales: ['en-GB', 'fr'],
  refs: [
    { tag: 'v2.0.0' },                     // les deux langues
    { tag: 'v1.0.0', locales: ['en-GB'] }  // l’original seulement
  ]
}

La forme objet déplace une langue entièrement ailleurs — son propre dépôt, avec ses propres mainteneurs et son propre rythme :

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

C’est ce que font React et Vue en dehors de leur outillage, avec de.react.dev et l’organisation vuejs-translations, parce que les traducteurs travaillent selon leur propre calendrier et leur propre relecture. Ici, c’est une entrée de source plutôt qu’un second site — un index de recherche, un sélecteur de langue.

Quand une page n’a pas de traduction

Le lecteur reçoit la langue la plus proche qui l’a, avec un bandeau, et la page porte noindex ainsi qu’un canonical pointant vers la langue dans laquelle elle est réellement. La chaîne — locale, langue de base, région sœur, fallbackLocale, original — est dans Localisation.

Liste de contrôle

  • duxt.locales liste exactement les locales que vous servez
  • /sitemap.xml contient une entrée par page et par locale, et aucune autre
  • Les liens hreflang sont absolus
  • Aucun libellé configuré ne s’affiche en clé brute
  • Changer de locale garde le lecteur sur la même page
  • Une page non traduite affiche le bandeau de repli, pas un 404
  • duxt.sourceOptions.defaultLocale correspond à i18n.defaultLocale
Cette page vous a-t-elle été utile ?