# Traductions Blockstudio fournit ses traductions dans le dossier `languages`. WordPress les utilise lorsque la langue du site ou celle du profil d’un utilisateur correspond à l’une d’elles. Cela fonctionne de la même façon lorsque Blockstudio est exécuté comme extension, extension obligatoire ou package Composer. ## Langues disponibles Blockstudio inclut des traductions pour les locales WordPress répertoriées dans son `languages/locales.json` inclus, y compris les variantes régionales et formelles ou informelles. L’anglais (`en_US`) est la langue source et ne nécessite pas de fichier de traduction. La liste regroupe les locales prises en charge par WordPress dans GlotPress et les variantes disponibles dans le WordPress de traduction du cœur de API. Les traductions existantes en allemand (`de_DE`) et en allemand formel (`de_DE_formal`) sont conservées. Les traductions supplémentaires sont générées par IA avec GPT-6 Luna et signalées comme générées par machine dans leurs en-têtes `.po`. Elles passent des vérifications automatiques d’exhaustivité et de format, mais n’ont pas toutes été relues par des locuteurs natifs. Les corrections sont les bienvenues. Les traductions couvrent les contrôles de champs de l’éditeur de blocs, la page d’administration, le canevas, la superposition des outils de développement et les messages des points de terminaison REST. Les libellés et textes d’aide de vos propres fichiers `block.json` relèvent de votre thème ou extension et utilisent son domaine de traduction. Sélectionnez la langue dans **Réglages > Général > Langue du site**, ou choisissez une langue personnelle dans votre profil WordPress. Blockstudio utilise automatiquement cette locale. Il n’ajoute pas de langues au sélecteur de langue de WordPress : une locale doit également être disponible dans votre installation WordPress. Aucun appel à l’IA, abonnement de traduction ou réglage d’exécution supplémentaire n’est nécessaire sur votre site. ## Remplacer une traduction Les fichiers de traduction dans `wp-content/languages/plugins` ont priorité sur ceux inclus, pour les chaînes PHP (`blockstudio-de_DE.mo` ou `blockstudio-de_DE.l10n.php`) ainsi que pour les scripts (un fichier par identifiant de script, par exemple `blockstudio-de_DE-blockstudio-blocks.json`). ## Contribuer à une traduction Chaque langue correspond à un fichier `.po` que vous pouvez modifier avec n’importe quel éditeur de texte ou un outil de traduction comme Poedit. Les corrections et les nouvelles langues sont les bienvenues sous forme de pull requests. 1. Pour ajouter une langue, copiez `languages/blockstudio.pot` vers `languages/blockstudio-.po`, par exemple `blockstudio-fr_FR.po`, puis renseignez les en-têtes `Language` et `Plural-Forms`. Pour améliorer une langue, modifiez son fichier `.po` existant. 2. Traduisez les chaînes. Conservez les espaces réservés tels que `%1$s` dans la traduction. 3. Exécutez `npm run i18n`. Cette commande écrit les fichiers `.mo`, `.l10n.php` et `.json` que WordPress charge. 4. Validez le fichier `.po` avec les fichiers générés, puis ouvrez une pull request. Si vous ne pouvez pas exécuter `npm`, une pull request contenant uniquement le fichier `.po` convient. Les fichiers générés peuvent être ajoutés avant la fusion. ## Générer les traductions manquantes Les responsables de la maintenance peuvent générer les entrées manquantes avec un Codex CLI authentifié. Il s’agit d’une commande de développement facultative, que WordPress n’exécute pas : ```bash npm run i18n:translate -- --dry-run npm run i18n:translate ``` Le modèle par défaut est `gpt-6-luna`. Pour travailler sur une seule locale, utilisez `npm run i18n:translate -- --locale fr_FR`. La commande extrait les chaînes sources les plus récentes, complète les traductions manquantes, puis compile les fichiers `.mo`, `.l10n.php` et `.json` pour chaque script. Seules les chaînes de l’interface publique, leur contexte et les formes existantes sont envoyés à Codex, et non le contenu du site ou les données des utilisateurs. Les traductions existantes non vides ne sont jamais remplacées. Les lots terminés sont enregistrés ; en cas d’interruption, une nouvelle exécution reprend le travail manquant. Les espaces réservés tels que `%1$s`, le balisage HTML, les identifiants techniques et les formes plurielles requises sont validés avant l’enregistrement. Les entrées approximatives et les formes plurielles sources modifiées restent à vérifier par un traducteur. Aucun autre modèle n’est utilisé si le modèle demandé n’est pas disponible. `npm run i18n:locales` actualise explicitement la liste des locales et les règles plurielles depuis WordPress/GlotPress. `npm run i18n:coverage` vérifie que chaque locale de la liste suivie dans le dépôt est complète. Ni les vérifications de couverture ni la CI habituelle n’appellent l’IA ou ne récupèrent de données de locales. Consultez le README du dépôt pour connaître les options de traitement par lots, de concurrence et de reprise. ## Chaînes traduisibles dans le code - PHP : utilisez les fonctions WordPress avec le domaine de texte `blockstudio`, par exemple `__( 'Invalid block.', 'blockstudio' )`. - JavaScript : importez `__` depuis `@/utils/__` et transmettez une chaîne littérale, par exemple `__( 'Add row' )`. Une chaîne construite à l’exécution ne peut pas être traduite ; utilisez donc une chaîne littérale par variante. - Un nouveau bundle de script contenant des chaînes traduisibles doit être déclaré dans `scripts/i18n.ts` et faire l’objet d’un appel à `wp_set_script_translations()` avec le même handle et `Translations::script_path()`. Après avoir modifié des chaînes, exécutez `npm run i18n`. Cette commande met à jour `languages/blockstudio.pot` et chaque fichier `.po`. Les nouvelles chaînes restent en anglais jusqu’à ce qu’un traducteur ou `npm run i18n:translate` les renseigne. La CI exécute `npm run i18n:check` et `npm run i18n:coverage`, qui rejettent les fichiers compilés obsolètes, les problèmes d’extraction ou une couverture locale incomplète. La génération reste une action explicite des responsables de maintenance.