Traductions

Afficher au format Markdown

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.

Pour ajouter une langue, copiez languages/blockstudio.pot vers languages/blockstudio-<locale>.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.
Traduisez les chaînes. Conservez les espaces réservés tels que %1$s dans la traduction.
Exécutez npm run i18n. Cette commande écrit les fichiers .mo, .l10n.php et .json que WordPress charge.
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 :

Shell

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.