i18n de thèmes et plugins WordPress : rendre le code traduisible

Rendre un thème ou un plugin WordPress traduisible : text domain, __() et _n(), un fichier POT avec WP-CLI, puis charger les fichiers .mo, .json et .l10n.php.

Localisez cette application en allemand et en espagnol avec PTC.

Préparez votre thème ou plugin WordPress pour la traduction. Ce guide couvre les text domains, les fonctions gettext, la génération de POT et le mécanisme de chargement qui présente les traductions aux utilisateurs. PTC (Private Translation Cloud) traduit ensuite les fichiers de ressources et révise visuellement le thème ou plugin rendu dans chaque langue.

Vous souhaitez traduire un site WordPress que vous gérez, et non du code que vous avez écrit ? Utilisez WPML.

Ce guide s'adresse aux développeurs qui écrivent le code. Si vous avez déjà un fichier POT ou PO et que vous avez juste besoin de le traduire, consultez la page des fichiers PO pour découvrir le flux de travail en 3 étapes.

À la fin de ce guide, votre thème ou plugin sera :

• Internationalisé correctement selon les normes de codage de WordPress.
• Traduisible par PTC dans 40+ langues.
• Distribuable via les packs de langue WordPress.org.
• Vérifiable à chaque version grâce à la révision visuelle de la traduction de PTC.

Qu'est-ce que l'internationalisation WordPress ?

L'internationalisation (i18n) est le travail de préparation de votre code pour qu'il puisse être traduit. La localisation (l10n) est l'étape suivante. Elle produit les chaînes traduites réelles pour des langues spécifiques.

Pour les thèmes et plugins WordPress, l'i18n implique trois choses :

• Encapsuler chaque chaîne visible par l'utilisateur dans des fonctions gettext afin que WordPress puisse les échanger à l'exécution.
• Définir un text domain qui lie vos traductions à votre projet.
• Générer un fichier POT à partir duquel les traducteurs (ou PTC) travaillent.

Une fois ce travail terminé, vous avez tout ce dont vous avez besoin pour produire des fichiers PO, MO, JSON et .l10n.php traduits pour n'importe quelle langue.

PTC traduit les fichiers POT en MO, JSON et .l10n.php pour WordPress

Cinq extensions de fichiers apparaissent dans tout flux de travail de traduction WordPress. PTC traduit à partir de .pot (votre source) vers .po, .mo, .json et .l10n.php pour chaque langue cible. Chaque format a un rôle spécifique :

• POT (Portable Object Template). Le fichier source généré à partir de votre code. Il répertorie chaque chaîne traduisible sans aucune traduction associée. Vous transmettez ce fichier à PTC.
• PO (Portable Object). Une copie du POT avec les traductions ajoutées pour une langue spécifique. En texte brut, lisible par un humain. PTC renvoie un PO par langue cible.
• MO (Machine Object). La version binaire compilée d'un PO. WordPress lit les fichiers MO à l'exécution car ils se chargent plus rapidement que le texte PO.
• JSON. L'équivalent JavaScript du MO. WordPress ne peut pas lire le MO depuis JavaScript, le pipeline de compilation produit donc des fichiers JSON pour les chaînes côté navigateur.
• .l10n.php. Une alternative plus récente au MO, introduite dans WordPress 6.5. Il se charge plus rapidement et utilise moins de mémoire. WordPress le choisit automatiquement lorsqu'il en existe un à côté du fichier MO.

Activez .l10n.php pour les nouveaux projets. Il est strictement meilleur que le MO sur les versions de WordPress prises en charge.

Pourquoi la traduction communautaire ne suffit pas

WordPress.org propose la traduction communautaire via GlotPress. En pratique, cela couvre une petite fraction de ce dont la plupart des plugins et thèmes ont besoin. Une analyse de plus de 60 000 plugins et thèmes WordPress a révélé que la traduction communautaire couvre moins de 5 % des besoins de traduction dans 40 langues.

Deux problèmes structurels expliquent cet écart :

• Les bénévoles sont rares dans la plupart des locales. Une poignée de plugins avec des bases d'utilisateurs massives attirent les traducteurs. La plupart n'en ont pas.
• Les traductions peuvent mettre des mois ou des années à apparaître, si tant est qu'elles apparaissent. Si vous voulez que les utilisateurs voient votre plugin ou thème dans leur langue dès le premier jour, vous ne pouvez pas compter sur la communauté.

Ce guide suppose que vous souhaitez une couverture de traduction complète et cohérente selon un calendrier de publication que vous contrôlez. C'est ce que fournit PTC.

Préparer votre thème ou plugin WordPress pour la traduction

Un text domain incohérent ou une chaîne non encapsulée signifie que ce texte n'apparaîtra jamais dans votre résultat traduit. Les détails comptent.

Étape 1 : Définir votre text domain et votre chemin du domaine

Chaque thème ou plugin a besoin d'un text domain. Le text domain est un identifiant unique qui indique à WordPress quels fichiers de traduction appartiennent à votre projet. Il doit correspondre exactement au slug de votre plugin ou thème.

Déclarez-le dans l'en-tête du fichier principal de votre plugin :

<?php
/**
 * Plugin Name: My Plugin
 * Description: An example plugin.
 * Version: 1.0.0
 * Text Domain: my-plugin
 * Domain Path: /languages
 */

Ou dans le style.css de votre thème :

/*
Theme Name: My Theme
Text Domain: my-theme
Domain Path: /languages
*/

Le chemin du domaine indique à WordPress où se trouvent vos fichiers de traduction par rapport à la racine du plugin ou du thème. /languages est la norme.

Étape 2 : Encapsuler vos chaînes PHP dans des fonctions gettext

Toute chaîne que vous souhaitez rendre traduisible doit être encapsulée dans l'une des fonctions gettext de WordPress. À l'exécution, ces fonctions recherchent la traduction correcte. Si aucune n'est trouvée, elles se replient sur la chaîne d'origine.

Chaînes de base. Utilisez __() lorsque vous devez renvoyer une chaîne. Pour la sortie HTML, utilisez les variantes échappées. Les normes de codage de WordPress recommandent echo esc_html__() plutôt que _e(). La forme échappée rend l'échappement de la sortie explicite et empêche les failles XSS au point de sortie :

// Return a translated string
$label = __( 'Settings', 'my-plugin' );

// Echo a translated string, escaped for HTML
echo esc_html__( 'Settings saved.', 'my-plugin' );

Chaînes avec variables. Ne concaténez pas de variables dans des chaînes. Les traducteurs ne voient que des fragments et ne peuvent pas réorganiser les mots pour les langues ayant une syntaxe différente. Utilisez printf() ou sprintf() avec un espace réservé. Ajoutez un commentaire pour le traducteur afin que les traducteurs sachent ce que %s représente :

printf(
    /* translators: %s: the user's display name */
    esc_html__( 'Welcome back, %s.', 'my-plugin' ),
    esc_html( $display_name )
);

Formes plurielles. Les pluriels anglais sont simples (un commentaire, deux commentaires). Ce n'est pas le cas pour d'autres langues. Utilisez _n() pour gérer toutes les règles de pluriel connues de WordPress :

printf(
    esc_html( _n( '%s comment', '%s comments', $count, 'my-plugin' ) ),
    number_format_i18n( $count )
);

Chaînes nécessitant du contexte. Certains mots ont des significations différentes selon l'endroit où ils apparaissent. Utilisez _x() pour donner aux traducteurs le contexte dont ils ont besoin :

// "Export" as a noun (the file) vs. a verb (the action)
echo esc_html_x( 'Export', 'button label', 'my-plugin' );

Étape 3 : Internationaliser vos chaînes JavaScript

WordPress fournit le paquet wp-i18n afin que vous puissiez utiliser en JavaScript les mêmes fonctions gettext que vous utilisez en PHP. Lors de l'enregistrement de votre script, déclarez wp-i18n comme dépendance :

wp_register_script(
    'my-plugin-script',
    plugins_url( 'js/app.js', __FILE__ ),
    array( 'wp-i18n' ),
    '1.0.0',
    true
);

Puis, dans votre fichier JavaScript :

const { __, _n, sprintf } = wp.i18n;

const message = __( 'Settings saved.', 'my-plugin' );

Si vous utilisez un bundler comme Webpack, installez @wordpress/babel-plugin-makepot. Il extrait les chaînes traduisibles de votre bundle lors de votre compilation.

Étape 4 : Générer votre fichier POT

Une fois vos chaînes encapsulées, générez un fichier POT. Le POT est le fichier source à partir duquel PTC (ou tout traducteur) travaille. Il contient chaque chaîne traduisible mais aucune traduction.

wp i18n make-pot . languages/my-plugin.pot

WP-CLI analyse vos fichiers PHP, JavaScript et block.json à la recherche d'appels gettext. Il les compile en un seul POT. Si votre équipe utilise Composer, ajoutez cette commande comme script Composer. Cela maintient l'utilisation de WP-CLI cohérente au sein de l'équipe sans installation globale.

La suite complète de commandes wp i18n couvre le reste du pipeline :

Vous n'avez pas besoin de Poedit. Tout dans ce flux de travail passe par WP-CLI et PTC. WP-CLI gère la génération du POT et la compilation MO/JSON. PTC gère la traduction et renvoie tous les formats de fichiers dont WordPress a besoin. Poedit est un éditeur de bureau utile pour la traduction manuelle, mais il ne fait pas partie de ce flux de travail.

Traduire des fichiers POT avec PTC

PTC est conçu pour les développeurs WordPress. Commencez avec un fichier POT et récupérez des fichiers de traduction prêts pour la production. L'essai de 30 jours couvre jusqu'à 20 000 mots dans deux langues.

Configurer votre premier projet de traduction

Téléversez votre fichier POT. Choisissez les formats de sortie dont vous avez besoin. PTC renvoie n'importe quelle combinaison de :

• Fichiers .po pour chaque langue cible.
• Fichiers .mo, compilés et prêts à être publiés.
• Fichiers .json pour vos chaînes JavaScript.
• Fichiers .l10n.php pour un chargement plus rapide sur WordPress 6.5+.

L'assistant de configuration vous demande de décrire votre thème ou plugin. PTC utilise la description pour générer des traductions avec le ton et le contexte appropriés. Ajoutez des termes spécifiques à la marque au glossaire à ce stade. Le glossaire maintient la cohérence des noms, des libellés de fonctionnalités et de toute autre terminologie dans toutes les langues.

PTC analyse la structure gettext lors du téléversement. Il reconnaît les espaces réservés (%s, %1$s, %d), les formes plurielles (entrées extraites par _n() avec leur en-tête Plural-Forms) et les contextes (entrées _x() avec msgctxt). Il génère ensuite les catégories de pluriel correctes par langue. Le polonais obtient one / few / many / other. Le japonais n'obtient que other. L'arabe obtient six formes.

Passer à la localisation continue

Une fois vos premiers fichiers traduits, passez au Pay-As-You-Go. Connectez PTC à votre dépôt GitHub, GitLab ou Bitbucket. À partir de ce moment, vous ne téléversez plus de fichiers manuellement.

Faites un commit d'un fichier .ptc-config.yml indiquant le nom de votre fichier source et l'emplacement des traductions :

# .ptc-config.yml
source_locale: en
files:
  - file: languages/my-plugin.pot
    output: languages/my-plugin-{{lang}}.po
    additional_translation_files:
      - type: mo
        path: languages/my-plugin-{{lang}}.mo

Ajoutez ensuite l'action PTC Translate à votre flux de travail. Elle intègre une version épinglée de la CLI de PTC, de sorte que votre compilation ne télécharge rien à l'exécution :

# .github/workflows/translate.yml
name: Regenerate POT for PTC
on:
  push:
    branches: [main]
    paths:
      - 'languages/my-plugin.pot'
  workflow_dispatch: {}

jobs:
  translate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - name: Generate POT
        run: |
          wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin
      - uses: OnTheGoSystems/ptc-action@v1
        with:
          api-token: ${{ secrets.PTC_API_TOKEN }}
          create-pr: true

Vous avez deux façons d'automatiser cela. Avec l'intégration Git, PTC surveille votre dépôt et ouvre une merge request avec les traductions mises à jour chaque fois que le fichier source change. Pour exécuter la traduction à l'intérieur de votre propre tâche CI à la place, utilisez la CLI de PTC : elle téléverse le fichier modifié, attend la fin de la traduction et télécharge les fichiers traduits. Des modèles de flux de travail prêts à l'emploi pour GitHub Actions, GitLab CI et Bitbucket Pipelines se trouvent dans le guide de configuration du pipeline CI/CD.

L'un ou l'autre flux livre une merge request ou un téléchargement avec les fichiers .po, .mo, .json et .l10n.php mis à jour. Consultez la référence de l'API PTC pour l'API REST et les webhooks complets.

Le fait de commiter les fichiers .mo dans votre dépôt dépend de la politique de votre équipe. De nombreux plugins les génèrent plutôt au moment de la version. L'intégration CI de PTC les produit à chaque exécution de traduction. Ne les archivez que si vous souhaitez conserver les fichiers traduits dans l'historique des versions.

Chargement des traductions dans WordPress

Avec les fichiers traduits en main, placez-les correctement et indiquez à WordPress où les trouver. Le nom de fichier passe en premier. WordPress recherche les fichiers de traduction en utilisant un modèle de nommage spécifique. Un nom de fichier qui ne correspond pas signifie que le fichier ne se chargera pas.

Obtenir les bons noms de fichiers

Les codes de locale suivent le format language_COUNTRY. de_DE est l'allemand (Allemagne). fr_FR est le français (France). pt_BR est le portugais (Brésil). zh_CN est le chinois simplifié. Le portail de traduction de WordPress répertorie toutes les locales prises en charge.

Le nom de fichier attendu dépend de l'endroit où vous placez le fichier :

Les thèmes utilisent une convention de nommage plus courte lorsque les fichiers sont groupés dans le thème. Dans le répertoire global des langues, les plugins et les thèmes utilisent le modèle {text-domain}-{locale}.

Chargement des traductions pour les plugins (PHP)

Enregistrez les traductions auprès de WordPress sur le hook init. N'utilisez pas plugins_loaded. Cela déclenche un avertissement de dépréciation dans les versions actuelles de WordPress :

add_action( 'init', function () {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages/'
    );
} );

Chargement des traductions pour les thèmes (PHP)

Utilisez load_theme_textdomain() accroché à after_setup_theme :

add_action( 'after_setup_theme', function () {
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );
} );

Chargement des traductions JavaScript

Après avoir enregistré votre script (Étape 3 ci-dessus), appelez wp_set_script_translations(). WordPress charge alors les traductions JSON pour ce script handle :

add_action( 'init', function () {
    wp_set_script_translations(
        'my-plugin-script',
        'my-plugin',
        plugin_dir_path( __FILE__ ) . 'languages'
    );
} );

Vérifier le chargement

1. Définissez la langue de votre site WordPress sur une locale cible. Le paramètre se trouve dans Réglages > Général > Langue du site.
2. Rechargez le front-end et les pages d'administration que votre plugin ou thème rend.
3. Les chaînes encapsulées dans __() ou esc_html__() doivent apparaître dans la nouvelle langue.

S'il manque quelque chose, consultez Les traductions du plugin WordPress ne s'affichent pas ? Corriger les traductions manquantes pour connaître les causes les plus courantes.

Diffuser vos traductions aux utilisateurs : deux voies

Une fois que PTC a traduit vos fichiers, vous les publiez de l'une des deux manières suivantes.

Voie 1 : Publier les traductions via les packs de langue WordPress.org (CLPTE)

Temps total : 4 à 6 jours.

Étape 1 : Créer un compte CLPTE

Le rôle CLPTE (Cross-Locale Project Translation Editor) vous permet de soumettre des traductions au nom de votre thème ou plugin dans chaque langue cible à partir d'un seul compte. Un compte d'Éditeur de traduction ordinaire est par langue ; le CLPTE ne l'est pas.

Si vous avez déjà un compte sur WordPress.org, vous pourriez rencontrer un problème où votre nouveau compte CLPTE est désactivé. WordPress n'autorise pas les comptes multiples. Pour résoudre ce problème, envoyez un e-mail à forum-password-resets@wordpress.org et expliquez que vous essayez de créer un compte CLPTE. Partager la documentation Polyglots pertinente avec le modérateur et notifier l'équipe Polyglots sur Slack sont deux choses utiles.

Temps estimé : ~3 à 5 jours (inclut le temps d'attente si votre nouveau compte est désactivé).

Étape 2 : Demander l'accès CLPTE sur le blog Polyglots

Avec votre compte activé, publiez une demande sur le blog Polyglots de WordPress.org. Suivez leur modèle :

PTE/CLPTE Request

Plugin URL: https://wordpress.org/plugins/my-plugin/
Authors / Editors: @your-wp-username
Type of request: CLPTE

Vous recevez une notification lorsque votre demande est approuvée.

Temps estimé : ~1 jour (l'équipe mondiale Polyglots examine les demandes par lots).

Étape 3 : Importer les fichiers .po traduits

1. Connectez-vous à https://translate.wordpress.org/ à l'aide de votre compte CLPTE.
2. Accédez à la page du projet de traduction de votre plugin ou thème (par exemple, translate.wordpress.org/projects/wp-plugins/{your-plugin-slug}/).
3. Ouvrez le projet local pour chaque langue que vous avez traduite.
4. Faites défiler vers le bas et cliquez sur Importer les traductions.
5. Téléversez votre fichier .po (ou .mo).
6. Marquez les chaînes importées comme « current » dans l'éditeur de traduction. Les chaînes approuvées rejoignent la prochaine génération de packs de langue (généralement quotidienne).
7. Répétez l'opération pour chaque langue cible. Chaque locale possède sa propre page de traduction.

Temps estimé : ~10 à 30 minutes par langue.

Après une fenêtre de 24 à 48 heures pour les packs de langue, les sites exécutant votre plugin commencent à recevoir les nouvelles traductions via les mises à jour automatiques des packs de langue de WordPress. Les utilisateurs ne voient aucune invite de mise à jour. Les traductions apparaissent tout simplement.

Ce que le CLPTE fera et ne fera pas pour vous

• Vous ne pouvez pas remplacer les traductions communautaires existantes. Seules les chaînes non traduites sont importées. La mise à jour d'une traduction communautaire existante nécessite le processus standard et l'attente de la révision de l'équipe de la locale.
• Les mises à jour nécessitent des téléversements manuels pour chaque version. Chaque nouvelle version implique une nouvelle série de téléversements.
• La création et l'approbation du compte prennent généralement 4 à 6 jours au total.

Voie 2 : Inclure les fichiers .mo dans votre plugin ou thème

Si vous avez besoin que les traductions soient en ligne plus rapidement que ne le permet le CLPTE, ou si vous préférez ne pas dépendre du pipeline de distribution de WordPress.org, incluez les fichiers .mo directement dans la version de votre plugin ou thème. Temps total : 15 à 30 minutes.

Étape 1 : Ajouter les fichiers .mo au répertoire /languages/

Placez vos fichiers .mo compilés dans le répertoire /languages/ de votre plugin ou thème afin que WordPress les trouve lors du chargement de votre text domain :

my-plugin/
├─ my-plugin.php
├─ readme.txt
├─ languages/
│  ├─ my-plugin-es_ES.mo
│  ├─ my-plugin-es_ES.po
│  ├─ my-plugin-fr_FR.mo
│  ├─ my-plugin-fr_FR.po
│  ├─ my-plugin-de_DE.mo
│  └─ my-plugin-de_DE.po

Utilisez le même text domain dans vos noms de fichiers de traduction et dans vos appels load_plugin_textdomain() ou load_theme_textdomain().

Étape 2 : Préférer vos fichiers inclus aux traductions communautaires

Par défaut, WordPress donne la priorité aux traductions communautaires de WordPress.org par rapport à celles qui sont incluses. Pour vous assurer que votre plugin ou thème utilise plutôt les fichiers .mo inclus, ajoutez le filtre load_textdomain_mofile.

Pour les plugins, ajoutez ceci au fichier principal de votre plugin (par exemple, my-plugin.php) :

function my_plugin_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/plugins/' ) ) {
        $locale = apply_filters( 'plugin_locale', determine_locale(), $domain );
        $local_mofile = WP_PLUGIN_DIR . '/' . dirname( plugin_basename( __FILE__ ) ) .
                        '/languages/' . $domain . '-' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_plugin_load_embedded_translation_file', 10, 2 );

Pour les thèmes, ajoutez ceci au fichier functions.php de votre thème :

function my_theme_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/themes/' ) ) {
        $locale = apply_filters( 'theme_locale', determine_locale(), $domain );
        $local_mofile = get_template_directory() . '/languages/' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_theme_load_embedded_translation_file', 10, 2 );

Confirmez également que votre plugin ou thème charge le text domain sur le bon hook :

add_action( 'init', function() {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages'
    );
} );

Étape 3 : Vérifier que les traductions incluses se chargent sur un site de test

Installez votre plugin ou thème sur un site de test et basculez WordPress vers l'une des langues que vous avez fournies :

1. Allez dans Réglages > Général > Langue du site et sélectionnez une langue dont le fichier .mo se trouve dans votre dossier /languages/.
2. Chargez une page ou un écran qui contient des chaînes que vous savez traduites.
3. Confirmez que les chaînes apparaissent dans la bonne langue et correspondent aux traductions que vous avez ajoutées.

Si vous voyez toujours d'anciennes traductions communautaires, revoyez l'extrait de l'Étape 2. Il doit pointer correctement WordPress vers vos fichiers .mo inclus.

Commitez les fichiers .mo, créez un tag de version et poussez vers wordpress.org via SVN comme vous le faites normalement.

Le compromis entre rapidité et distribution canonique

• Avantage : instantané. Les nouvelles traductions sont en ligne dès que les utilisateurs mettent à jour votre plugin (ou l'installent pour la première fois). Pas d'attente de plusieurs jours pour le CLPTE. Pas de cycle d'approbation de l'équipe Polyglots.
• Avantage : vous contrôlez le flux de travail. La cadence de traduction correspond exactement à votre cadence de publication.
• Avantage : aucune dépendance au badge du plugin. Les traductions fonctionnent que votre plugin ait ou non les autorisations CLPTE.
• Inconvénient : la taille du fichier du plugin augmente. Chaque .mo est petit (5 à 50 Ko généralement), mais 20 langues ajoutent environ 500 Ko au téléchargement.
• Inconvénient : pas de mise à jour automatique des traductions entre les versions du plugin. Avec le CLPTE, les traductions mises à jour sur wordpress.org se propagent aux utilisateurs dans les 48 heures, même si vous ne publiez pas de nouvelle version. Avec l'inclusion, les traductions ne se mettent à jour que lorsque vous publiez une nouvelle version.
• Inconvénient : pas de badge « traduit ». WordPress.org affiche un badge de complétion de traduction sur les fiches de plugins en fonction de la couverture des packs de langue, et non des fichiers .mo inclus. L'inclusion seule ne permet pas d'obtenir le badge.

Quelle voie correspond à votre cadence de publication ?

L'approche double est courante : inclure les fichiers MO pour une disponibilité immédiate, et les soumettre au CLPTE pour une distribution canonique. Les utilisateurs obtiennent les traductions incluses lors de la mise à jour ; les packs de langue superposés les rafraîchissent entre les versions.

Langues écrites de droite à gauche et mises en page bidirectionnelles

Le flux de travail de traduction est le même pour les langues écrites de droite à gauche (RTL). L'arabe, l'hébreu, le persan et l'ourdou utilisent le même pipeline POT/PO/MO.

L'étape supplémentaire consiste à s'assurer que votre thème prend en charge les styles RTL. WordPress charge automatiquement un fichier rtl.css s'il en existe un dans le répertoire de votre thème. Utilisez la fonction is_rtl() pour appliquer conditionnellement des styles ou des scripts spécifiques au RTL.

Localiser les dates, les nombres et les devises

Une chaîne traduite n'est pas tout. Les dates, les nombres et les devises doivent également suivre la locale de l'utilisateur. Utilisez les fonctions de formatage intégrées de WordPress au lieu de celles natives de PHP :

• date_i18n() formate les dates en fonction de la locale active.
• number_format_i18n() formate les nombres avec des séparateurs de milliers et de décimales adaptés à la locale.

Ces fonctions ne font pas partie du flux de travail des fichiers de traduction. Elles sont importantes pour une expérience entièrement localisée.

Internationaliser les blocs de l'Éditeur de blocs (Gutenberg)

Les blocs ajoutent deux étapes supplémentaires au pipeline standard :

• Les traductions JavaScript nécessitent un fichier .json par locale. Générez-le à partir du .po avec wp i18n make-json.
• Le script de l'éditeur du bloc a besoin de wp_set_script_translations() en PHP. Cela indique à WordPress de servir le JSON au bloc.

La sortie rendue par le bloc sur le front-end utilise les mêmes appels __() que votre autre code PHP. Aucun travail supplémentaire n'est requis à ce niveau.

Traduire votre README et votre fiche WordPress.org

Votre readme.txt n'est pas un fichier de ressources. WP-CLI ne le détectera pas lors de la génération d'un POT. Pour le traduire, utilisez la fonctionnalité Paste to Translate de PTC. Collez le contenu, choisissez vos langues cibles et téléchargez le résultat. Les e-mails destinés aux clients envoyés depuis le plugin et la description de la page du plugin sur WordPress.org se traduisent de la même manière, tous dans le même projet afin que la terminologie reste cohérente.

Si votre plugin ou thème est répertorié sur WordPress.org, la description traduite apparaît dans l'onglet Détails du plugin dans la langue de l'utilisateur. Pour y mettre les traductions en ligne, suivez le processus d'importation de WordPress.org.

Traduire le contenu utilisateur du plugin avec l'API PTC

Les plugins qui stockent des données générées par les utilisateurs (plugins de forum, plugins d'avis, plugins de commentaires) peuvent traduire ce contenu au fur et à mesure qu'il arrive. L'API REST PTC traduit les publications, commentaires et avis des utilisateurs à la demande avec une authentification par jeton Bearer, en utilisant le même glossaire et la même voix de marque que vos fichiers .po.

Révision visuelle de la traduction de votre thème ou plugin rendu - publiez sans contrôle qualité manuel par langue

Un fichier .po traduit est nécessaire, mais il n'est pas suffisant. Le thème ou plugin traduit a toujours besoin d'être vérifié :

• Un libellé traduit peut déborder d'un bouton de la page de paramètres en allemand.
• « Submit » peut se traduire par un nom en français alors que l'action d'administration nécessitait un verbe.
• Une chaîne en dur en anglais en dehors de __() sera rendue non traduite, quel que soit le nombre de langues que vous publiez.

La révision visuelle de la traduction de PTC remplace la passe de contrôle qualité manuel. Les thèmes et plugins WordPress sont rendus dans le navigateur (à la fois wp-admin et le front-end). La bonne variante est l'extension de navigateur.

Installez-la une fois. Enregistrez un parcours guidé de votre thème ou plugin sur un site de test. Couvrez les pages de paramètres, les actions d'administration et la sortie front-end. PTC rejoue l'enregistrement dans chaque langue cible après chaque mise à jour de traduction. Il capture chaque écran et signale deux types de correctifs :

• Correctifs dans les fichiers .po lorsque PTC les contrôle. PTC retraduit un sens erroné, choisit un synonyme plus court qui s'adapte à un bouton, ou régénère une forme plurielle.
• Prompts Cursor ou Claude Code lorsque le problème réside dans votre code PHP ou JavaScript. Les exemples incluent un wrapper __() manquant, une chaîne en dur en anglais, ou une phrase construite par concaténation qui devrait utiliser sprintf( __( ... ) ).

Vous publiez un plugin multilingue vérifié à chaque version. Le reliquat de contrôle qualité manuel disparaît.

Tarification : essai de 30 jours, puis Pay-As-You-Go

L'essai couvre 20 000 mots dans 2 langues sans carte bancaire. À la fin de l'essai, PTC propose le Pay-As-You-Go. Sans abonnement. Sans engagement minimum. Les 500 premiers mots de chaque mois sont gratuits. Vous ne payez que pour le reste. La page de tarification dispose d'un calculateur de coûts. Inscrivez-vous avec une adresse e-mail professionnelle pour un essai prolongé pour les entreprises.

Prêt à publier un plugin ou un thème vérifié ?

PTC génère les traductions et révise le plugin rendu. Vous confirmez le résultat et publiez. La boucle complète s'exécute sans contrôle qualité manuel :

1. Générez votre fichier .pot avec wp i18n make-pot.
2. Téléversez-le sur PTC et récupérez les fichiers .po, .mo, .l10n.php et .json en quelques minutes.
3. Installez l'extension de navigateur pour vérifier le plugin en cours d'exécution dans chaque langue cible.

Commencez votre essai de 30 jours - 20 000 mots offerts, sans carte bancaire requise.

Articles liés :

• Traduire des fichiers PO en ligne avec l'IA - la page canonique de traduction PO/POT.
• GlotPress vs PTC pour la traduction de plugins/thèmes WordPress - quand choisir la traduction communautaire par rapport à PTC.
• Les traductions du plugin WordPress ne s'affichent pas ? Corriger les traductions manquantes - guide de dépannage.
• Comment importer des traductions de thèmes et de plugins dans WordPress.org - le processus CLPTE et une alternative plus rapide.
• Référence de l'API PTC - points de terminaison REST pour l'intégration CI.

Dernière mise à jour : 11 novembre 2026