Langues de l’interface
Choisir sa langue, installer un catalogue signé et garder la langue du site indépendante.
Sur cette page
Choisir sa langue de travail
Le français est fourni avec Bracten. Dans le menu du compte ou dans Mon compte, choisissez une langue installée, ou suivez celle du navigateur. Votre choix est enregistré pour votre compte. Vous pouvez le changer sans quitter l’éditeur : les champs restent ouverts et leur saisie est conservée.
Avant la connexion, le sélecteur utilise le choix local du navigateur, puis sa langue. Le CMS recherche d’abord le code régional exact, ensuite sa langue de base, puis le français. Avant la configuration de PostgreSQL, seul le catalogue français embarqué est disponible.
| Réglage | Ce qu’il change |
|---|---|
| Langue du compte | Les commandes, messages, dates et nombres de l’administration. |
| Langue du site | Les libellés système du site public et sa langue déclarée. |
| Langue d’un contenu | Les données éditoriales, gérées séparément par le site et ses extensions. |
Installer et mettre à jour un pack
La page Langues affiche les catalogues disponibles, leur version et le nombre de clés traduites. La gestion des packs exige la permission settings.manage. Un pack est un fichier JSON signé par un éditeur dont la clé publique a été approuvée sur le serveur ; il ne contient aucun programme exécutable.
- Téléchargez un pack vérifié depuis la page Télécharger de Bracten ou auprès de son éditeur. Faites vérifier sa clé publique par l’exploitant du serveur, via un canal indépendant.
- Ouvrez Langues, choisissez le fichier signé et conservez le canal stable, sauf si vous souhaitez explicitement installer une bêta.
- Importez le fichier. Bracten vérifie la signature, l’empreinte, la compatibilité avec le cœur, les clés et les variables des messages.
- Choisissez la nouvelle langue dans le menu du compte. Pour une mise à jour, importez une version supérieure provenant du même éditeur et conservant le même identifiant.
Un catalogue peut être incomplet : chaque clé absente utilise le français. La couverture affichée mesure les clés du catalogue de référence, pas la traduction des données du site ni des extensions tierces. Le français embarqué ne peut pas être remplacé par un pack.
Revenir à une version précédente
L’historique conserve les installations, mises à jour et restaurations. Le bouton de retour arrière réactive la version précédente seulement si sa signature, sa provenance et sa compatibilité sont toujours valides. Une réimportation identique de la version active ne crée pas une nouvelle installation.
Après une mise à jour du cœur, un ancien pack devenu incompatible peut être remplacé par une nouvelle version compatible du même éditeur. Il ne peut plus être affiché ni restauré. Si une clé approuvée manque ou si un pack est altéré, Bracten utilise le français sans effacer la préférence du compte.
Les catalogues, l’historique et les préférences sont conservés dans PostgreSQL. Conservez séparément le répertoire privé trusted-publishers : il n’est pas inclus dans la sauvegarde applicative. Après restauration, replacez les clés depuis une source approuvée avant de réactiver un catalogue devenu indisponible.
Langue du site et personnalisation du thème
Les libellés système du site public suivent la langue du site, ou celle explicitement fournie par une extension de contenu multilingue. La préférence du compte connecté n’intervient pas. Recherche, pagination, pages vides et autres commandes utilisent le même mécanisme de catalogue et de repli.
Le thème Starter associe explicitement certains textes de ses blocs par défaut à des clés de traduction. Dès que vous enregistrez une partie ou un template personnalisé, ses textes deviennent vos données, même s’ils sont encore identiques au texte livré. Bracten ne les remplace plus automatiquement.
Les pages publiques d’extensions adaptées ont une négociation distincte, décrite ci-dessous : elles peuvent suivre la langue demandée par le navigateur du visiteur. Cela ne change ni la langue enregistrée d’un contenu ni la règle des templates du site.
Traduction des quatorze extensions officielles
Après installation des packages adaptés et d’un catalogue signé contenant leurs clés, les pages, menus, widgets, réglages et champs déclarés suivent votre langue d’administration. Le registre est rechargé lorsque vous changez de langue, en conservant les formulaires ouverts et leurs saisies modifiées. Un ancien pack ou un catalogue incomplet utilise le français pour chaque message absent.
Analytics, Catalog, Comments, Directory, Forms, GraphQL, Membership, Multilingual, Redis, S3, Search, Security, SEO et SMTP utilisent des clés stables. Les noms et métadonnées signés des packages conservent leur identité. Les titres, réponses, termes, groupes et champs créés par un client ne sont jamais remplacés. Les libellés de taxonomie livrés par une extension ne sont traduits que s’ils n’ont pas été personnalisés.
Les pages publiques d’extensions utilisent d’abord la préférence principale Accept-Language du visiteur, puis sa langue de base si elle est disponible, la langue du site et enfin le français. Une préférence française explicite reste française. Une page anglaise ne traduit pas les contenus saisis dans le CMS. Les textes de secours d’un bloc sont composés dans la langue de son auteur à l’enregistrement et restent ensuite des données du document.
Les notifications de Forms et Comments suivent la langue du site, puisque leur destinataire est configuré par le site. Le diagnostic SMTP suit le compte qui le demande. Security conserve le choix personnel français ou anglais de ses alertes, distinct de la langue du formulaire. Les e-mails de sécurité et de confirmation d’adresse du noyau suivent la préférence enregistrée du destinataire, avec repli français ; un nouveau compte sans préférence reçoit donc le français. La langue envoyée par un visiteur ne décide pas des e-mails de sécurité d’un autre compte.
Adapter les textes d’une extension
Le SDK expose defineLocalizedPlugin(factory). La factory produit la définition canonique française, puis une définition de présentation avec { locale, t }. PluginContext.language reste facultatif pour préserver les anciennes extensions. Le cœur injecte la langue dans les lectures de pages, widgets, registre et réglages, ainsi que dans les endpoints, le rendu des blocs et les validations déclenchées par un compte. Les définitions non adaptées gardent leurs textes d’origine.
La factory doit être pure : seules les présentations varient. Le cœur revalide les définitions et refuse une modification des identifiants, permissions, méthodes HTTP, visibilité, migrations, champs, options machine, schémas, tâches ou événements. Les libellés, descriptions et confirmations peuvent changer. Ce contrôle déclaratif ne constitue pas un bac à sable pour les callbacks de code approuvé.
Activation, désactivation, migrations, providers, commandes et traitements de fond utilisent la définition canonique. Les notifications de site choisissent explicitement context.siteLanguage() ; une tâche différée ne possède pas de navigateur à consulter. Le catalogue des extensions reste séparé du catalogue complet dans leurs modules autonomes, et aucun schéma ou contenu n’est réécrit pour changer de langue.
docs/languages.md décrit la recette tests/integration/plugin-languages.test.mjs : compilation et activation des quatorze packages, invariance des contrats FR/EN, droits, pages publiques, conservation des données, notifications capturées et repli. Le parcours Chrome vérifie aussi la conservation d’une saisie Forms pendant une bascule de langue. Ces preuves locales ne démontrent ni la version déployée sur une instance ni la délivrabilité de son transport SMTP.
Publication et maintenance sur le serveur
L’exploitant place la clé publique Ed25519 de l’éditeur dans CMS_DATA_DIR/trusted-publishers/<publisher>.pem après avoir vérifié sa provenance. Le pack est limité à 512 Kio ; la signature couvre le manifeste et les messages. Les mises à jour conservent les versions immuables et leur provenance.
cms language:sign languages/en.cms-language.json /secure/releases/en.cms-language publisher.languages /secure/signing/languages-private.pemLes commandes de maintenance directe nécessitent l’arrêt du CMS. CMS_OPERATOR_EMAIL désigne un compte actif disposant des permissions nécessaires. Consultez docs/languages.md pour le format canonique de l’empreinte, les règles de signature et la recette reproductible.
CMS_OPERATOR_EMAIL=admin@example.com cms language:import /secure/releases/en.cms-language
cms language:list
CMS_OPERATOR_EMAIL=admin@example.com cms language:history 1
CMS_OPERATOR_EMAIL=admin@example.com cms language:rollback en