Internationalisation

Motoko Base inclut une base d'internationalisation (i18n) complète construite avec next-intl. Vous obtenez cinq locales, des URLs marketing adaptées à la locale, un shell de dashboard traduit, une documentation et un changelog localisés, et un modèle clair pour étendre les traductions à vos propres fonctionnalités.

Cette page explique comment l'i18n est câblée. Pour les instructions pas à pas lors de l'ajout de copy, voir Ajouter des traductions.

Locales prises en charge

Les définitions de locale se trouvent dans src/i18n/routing.ts. Les libellés du sélecteur de langue proviennent de localeLabels dans le même fichier.

Modèle de routage hybride

Motoko Base utilise deux stratégies de routage volontairement :

Surfaces avec préfixe de locale (marketing)

Ces routes vivent sous src/app/[locale]/ :

• Page d'accueil et sections marketing
• Pages légales (/terms, /privacy, /licence)
• Documentation (/docs)
• Changelog (/changelog)

L'anglais utilise des URLs sans préfixe (localePrefix: 'as-needed'). Les autres locales reçoivent un préfixe (/fr, /de, /es, /pt-br).

Le sélecteur de langue marketing (MarketingLanguageSwitcher) navigue entre les chemins équivalents dans chaque locale en conservant le contexte de la page.

Surfaces app sans préfixe

Ces routes restent à des chemins fixes sans segment de locale :

• Dashboard et fonctionnalités démo (/dashboard/...)
• Flux d'authentification (/sign-in, /sign-up, mot de passe oublié/réinitialisation/vérification)
• Routes API, webhooks, redirections publiques (/api, /r/[slug])

La locale active est résolue à la requête — pas depuis l'URL.

Résolution de locale

Quand next-intl a besoin d'une locale, src/i18n/resolve-locale.ts applique cette priorité :

Utilisateur connecté  →  user_preferences.language (base de données)
Invité              →  cookie NEXT_LOCALE
Repli               →  en-tête Accept-Language
Par défaut          →  en

Première visite sur / : src/proxy.ts lit Accept-Language une fois. S'il correspond à une locale supportée autre que l'anglais, redirection vers l'URL marketing préfixée et cookie défini. Ensuite, les choix explicites (sélecteur ou Paramètres) priment.

Utilisateurs connectés : enregistrer la langue dans Paramètres → App → Apparence (/dashboard/settings/app/appearance) met à jour la base via updateLanguagePreferenceAction, définit le cookie et rafraîchit l'UI via LocalePreferenceSync.

Arborescence des fichiers

src/i18n/
├── routing.ts          # Locales, préfixes, nom du cookie
├── navigation.ts       # Link, useRouter, usePathname adaptés à la locale
├── request.ts          # Config serveur next-intl
├── resolve-locale.ts   # Résolution pour routes app/auth
├── load-messages.ts    # Import dynamique des catalogues
└── fumadocs.ts         # Locales contenu docs/changelog

messages/{locale}/      # Namespaces JSON par feature
content/docs/           # MDX localisé via suffixe dot
content/changelog/

Les helpers de formatage partagés sont dans src/lib/i18n/format.ts.

Catalogues de messages

Les traductions sont des namespaces JSON typés sous messages/{locale}/. Utilisez un namespace par feature ou zone (auth, settings, …). Gardez les clés stables dans toutes les locales.

Marketing : structure vs copy

Utiliser les traductions

Composants client

"use client";
import { useTranslations } from "next-intl";

export function MyPage() {
  const t = useTranslations("overview");
  return <h1>{t("welcome.title", { name: "Alex" })}</h1>;
}

Serveur et metadata

import { getTranslations } from "next-intl/server";

Liens adaptés à la locale

Importez depuis @/i18n/navigation — pas next/link — sur les pages marketing.

Docs et changelog localisés

Contenu Fumadocs avec parser dot (page.de.mdx, …). L'anglais est le fichier de base.

SEO

Canonicals par locale, alternates hreflang et entrées sitemap via src/lib/seo/metadata.ts.

Prochaines étapes

Ajouter des traductions — Guide pratique.

Structure du projet — Organisation du code.

Configuration — Nav dashboard et config produit.