Internationalisation

La publication multilingue est construite dans les os de Chinaski plutôt que greffée après coup : chaque élément de contenu porte sa propre langue, chaque schéma d'URL tient compte de la langue, et des sous-systèmes entiers (menus, formulaires, recherche, flux, l'interface d'admin elle-même) existent par langue. Cette page vous oriente dans le tableau ; les pages liées démontent chaque pièce.

Pourquoi la langue est « de première classe » ici

La langue n'est ni un plugin ni une réflexion après coup dans Chinaski ; c'est un fait structurel du modèle de données. Chaque ligne de contenu (page, post, block, document, catégorie, élément de menu, formulaire, stack, snippet) porte une langue, et le système l'impose :

• Le contenu vit de façon unique par langue : une page anglaise et une page espagnole peuvent partager un slug, et les deux éditions sont appariées (via des clés de traduction ou des slugs identiques) pour le SEO et la commutation.
• Les builders et les URL opèrent par langue : arbres de sortie, sitemaps, flux, URL canoniques et alternates hreflang respectent tous la configuration linguistique du site.
• L'admin lui-même parle votre langue : il est livré localisé, et chaque utilisateur choisit sa propre langue d'interface d'admin indépendamment du jeu de langues du site.

Chaque élément de contenu est soit publié, brouillon, planifié, ou parti (corbeille) ; c'est vrai pour chaque langue à chaque instant.

Les pièces que vous toucherez

• Active languages (Settings → General) : la liste des codes de langue dans lesquels votre site publie ; tout ce qui est en aval se cale sur cette liste.
• URL modes : comment le code de langue apparaît dans les URL : path (/en/about), none (langue unique, pas de préfixe), ou subdomain (en.example.com). Il se dérive de votre nombre de langues plutôt que d'être réglé à la main (multilingue → path ; monolingue → none), voir Modes d'URL.
• Réglages de permaliens : structure d'URL des posts et pages, choisie par site, avec des substitutions de préfixe de post par langue si vos langues ont besoin de leurs propres formes d'URL.
• Home redirect : la page ou fonctionnalité vers laquelle la racine de langue pointe.
• Appariement des traductions : slugs identiques ou clés de traduction explicites qui relient les éditions entre elles pour le hreflang et les liens de commutation.
• Textes de site par langue : titres de blog, textes de l'avis cookies et labels de boutons ont tous des réglages par langue, pour que votre site se lise naturellement dans chaque langue que vous avez configurée.

Où en savoir plus

• Modes d'URL : comment les URL sont façonnées par langue, et ce qui change.
• Hreflang et bascule : le signal SEO posé sur chaque page, plus le sélecteur de langue public.
• Multilingue d'abord : l'argument de conception et ses conséquences pour les workflows de contenu.

Où cela touche ce que vous connaissez déjà

Un site monolingue est le cas le plus simple : pas de préfixe de langue, pas d'alternates, pas d'options de langue d'admin au-delà de la préférence d'interface. Il se comporte comme un site statique à arbre unique dès le premier jour, et tout ce qui précède reste à l'écart jusqu'à ce que vous en ayez besoin.

Un site multisite et multilingue reçoit toute la machinerie : un jeu d'URL par langue, des URL canoniques alternées, une recherche partagée à résultats ciblés par langue, et un sélecteur de langue statique dans l'en-tête de chaque page. Le contenu vit sous l'URL propre de la langue ; le lien vers une version dans sa propre langue (hreflang) est émis automatiquement à partir d'appariements vérifiés, et la recherche est pareillement ciblée par langue.

Notes de migration pour les sites multilingues en transition : publier le contenu d'une langue dans l'admin pour la première fois met à jour la configuration linguistique du site. Les nouvelles langues sont additives ; rien ne casse. Si une langue est retirée alors que du contenu vit encore sous elle, l'admin refuse (vous verrez le nombre de pages/posts/blocks orphelins) : le chemin de nettoyage est de supprimer ou réaffecter ce contenu d'abord.

Le côté public en pratique

Les visiteurs voient un sélecteur de langue sur chaque page ; les moteurs de recherche voient des alternates hreflang, un sitemap ciblé par langue, et des URL canoniques par langue : chaque signal d'URL est d'accord avec tous les autres. Une fois les langues configurées, presque rien d'autre n'est nécessaire : la plupart des sites n'ont besoin de rien au-delà du choix des langues et (éventuellement) du mode sous-domaine, et les défauts intégrés se comportent correctement.

Ce qui n'est pas automatique

• Traduire est manuel (ou via les workflows de traduction documentés / outils MCP) ; une clé de traduction apparie des éditions ; elle ne traduit pas à votre place.
• Les menus sont par langue (une nav uniquement espagnole est normale) ; vous gérez le menu de chaque langue séparément.
• L'avis cookies, le titre du blog et les autres chaînes configurables ont des champs par langue ; ceux-ci prévalent plutôt que de retomber silencieusement : une langue avec son propre texte affiche le texte de cette langue.

Dans cette section

• Langues
• Modes d'URL
• Traduire le contenu
• Hreflang et bascule