Multilingue d'abord
La plupart des produits CMS traitent « prend en charge plusieurs langues » comme un add-on que l'on installe plus tard. Chinaski a été construit dans l'autre sens : la langue est une partie structurelle du modèle de données, des URL, de l'interface d'admin, et de chaque page que le builder génère. Cette page parcourt ce que « première classe » signifie en pratique, et ce qui n'aura pas besoin d'être greffé plus tard.
La langue vit dans le modèle de données
Chaque type de contenu (pages, posts, blocks, documents, catégories, éléments de navigation, formulaires) porte son propre champ de langue. Les traductions sont des lignes séparées reliées entre elles, pas des copies cachées. Là où les mises en page visuelles sont partagées entre langues, les contenus de blocks par langue vivent dans une table de traductions dédiée, pour qu'une pile hero, par exemple, puisse avoir une formulation différente par langue tout en partageant la structure.
L'interface d'admin parle la langue de l'utilisateur
L'UI d'admin elle-même est livrée avec des traductions intégrées, et chaque utilisateur peut choisir sa propre langue d'interface d'admin : elle vaut par défaut la langue du site mais se substitue par compte (cela inclut les personnes qui ne font qu'approuver des traductions). Quand les auteurs écrivent du contenu, le sélecteur de langue de chaque formulaire de contenu est la propre liste de langues configurée du site : rien d'inventé, rien de mal orthographié ; la liste vient du même réglage qui pilote les URL publiques.
Les langues de droite à gauche sont livrées d'origine
Arabe, hébreu, farsi, ourdou, pachto, kurde, sindhi, yiddish et divehi se rendent avec dir="rtl" défini sur chaque page générée (et avec lang correctement défini à la langue de chaque page dans chaque template de thème). Le RTL n'est ni un plugin ni un ajustement de thème ; il est dans le builder.
Une sortie tenant compte de la langue partout
- Arbres de sortie par langue. En mode URL chemin ou sous-domaine, chaque langue construit son propre arbre sous son propre préfixe/sous-domaine de langue, avec des URL canoniques par langue correctes (sous-domaines par langue inclus), des alternates hreflang, des entrées de sitemap et des chemins d'accueil de navigation.
- Labels de page d'accueil et avis cookies par langue. Le titre d'index du blog et le texte/labels de la bannière de cookies ont tous des réglages par langue : une source de configuration pour tout le jeu éditorial de langues d'un site.
- Simplification monolingue. Un site d'une seule langue ne reçoit jamais d'URL à segment de langue ; le mode se dérive automatiquement pour que les sites monolingues restent simples.
Un outillage éditorial multilingue, pas seulement conscient des langues
- La couverture de traduction est calculée par page et post et montrée pendant l'édition : quelles langues configurées ont ce contenu et lesquelles ne l'ont pas.
- Les modèles de workflow de traduction permettent de définir la langue source, les cibles et les types de contenu une fois, et de les réutiliser sur tout le site.
- Auto-création en un clic : un point de terminaison API (et surface admin) calcule les langues cibles manquantes d'un contenu et crée des brouillons traduits en lot, audités comme tout le reste.
- L'outillage assisté par IA emprunte les mêmes rails : le serveur MCP intégré expose des outils de traduction et d'audit (traduire du contenu, trouver les pièces manquant de traductions, trouver les lacunes de contenu comme les meta descriptions manquantes par langue), pour que la maintenance multilingue soit aussi scriptable.
Le comportement des pages publiques est natif de la langue
- Les index de recherche sont construits par langue ; chercher dans le contenu « es » cherche en espagnol.
- Les pages statiques elles-mêmes se trouvent sous des URL par langue avec des balises canoniques par langue.
- Les flux RSS et archives de catégorie sont générés par langue, ainsi le flux de chaque langue est un vrai flux, pas un flux étiqueté superficiellement.
- La publication planifiée utilise un seul fuseau horaire de site de façon cohérente, pour qu'un post espagnol et un post anglais publiés « à 9:00 » apparaissent réellement quand vous l'entendez.
Ce que « première classe » coûte
Rien ne se cache, mais la posture multilingue signifie que la complexité du modèle vit dans le modèle de données (les slugs diffèrent par langue ; la clé de traduction apparie les équivalents ; substitutions d'URL locales par langue). La règle pratique : décidez de vos langues avant le lancement (elles pilotent le mode URL), et traitez une traduction comme une sœur complète de la page source plutôt que comme une variante. Quand vous suivez ces voies, les moteurs de recherche reçoivent des signaux corrects et les visiteurs reçoivent des expériences complètes dans chaque langue que le site déclare.