# WordPress 6.5 pour les extensions : traductions .l10n.php et autres changements

> WordPress 6.5 change le format de traduction recommandé et ajoute plusieurs évolutions utiles aux auteurs d'extensions, au-delà de l'Interactivity API très commentée.

- Auteur : Clément Hadrot
- Publié le : 2024-05-17
- Mis à jour le : 2024-05-17
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/wordpress-6-5-extensions-traductions-l10n-php/

## L’essentiel

- Le format .l10n.php se charge plus vite que les .mo classiques
- Aucune action requise, la génération reste automatique côté WordPress.org
- Plusieurs fonctions de dépréciation et de journalisation gagnent en précision

WordPress 6.5, sortie en avril 2024, a surtout fait parler d'elle pour l'Interactivity API et les block bindings, deux nouveautés destinées principalement aux développeurs de blocs. Mais côté auteurs d'extensions plus classiques, une évolution plus discrète mérite l'attention : le nouveau format de fichiers de traduction `.l10n.php`, qui remplace progressivement les `.mo` comme format recommandé pour la distribution des traductions.

Cet article couvre ce changement et les quelques autres évolutions de 6.5 directement pertinentes pour qui maintient une extension, sans revenir sur les dépendances entre extensions via `Requires Plugins`, déjà traitées ailleurs en détail.

## Pourquoi un nouveau format de traduction

Le format `.mo` (Machine Object), hérité de gettext, exige un parsing binaire à chaque chargement de traduction. WordPress le fait depuis toujours via `load_textdomain()`, avec un coût mesurable sur des sites qui chargent beaucoup de domaines de traduction (extensions, thème, et leurs éventuelles dépendances). Le format `.l10n.php` encode les mêmes données sous forme d'un tableau PHP natif, que `include` charge directement sans étape de parsing supplémentaire — le gain vient de la nature même du format, plus proche de ce que PHP sait exécuter sans conversion.

Concrètement, un fichier `.l10n.php` ressemble à ceci une fois généré :

> L'essentiel à retenir : Le format .l10n.php se charge plus vite que les .mo classiques ; Aucune action requise, la génération reste automatique côté WordPress.org ; Plusieurs fonctions de dépréciation et de journalisation gagnent en précision

```
<?php
return array(
    'domain'       => 'mon-extension',
    'plural-forms' => 'nplurals=2; plural=(n > 1);',
    'messages'     => array(
        'Enregistrer les réglages' => 'Enregistrer les réglages',
        'Une erreur est survenue'  => 'Une erreur est survenue',
    ),
);
```

## Ce qui change réellement pour un auteur d'extension

Rassurons tout de suite : aucune action de code n'est requise pour la majorité des extensions. Les traductions hébergées sur les serveurs de traduction de WordPress.org (GlotPress) génèrent désormais automatiquement les fichiers `.l10n.php` en plus des `.mo` et `.po` existants, et WordPress choisit lui-même le format le plus performant disponible au chargement via `load_textdomain()`. L'appel classique dans le fichier principal de l'extension reste inchangé :

```
add_action( 'plugins_loaded', function() {
    load_plugin_textdomain( 'mon-extension', false, dirname( plugin_basename( __FILE__ ) ) . '/languages' );
} );
```

Là où une action est utile, c'est pour les extensions qui gèrent elles-mêmes la distribution de leurs traductions en dehors de WordPress.org — par exemple une extension pro vendue en direct, avec des fichiers de langue livrés dans le paquet. Dans ce cas, générer soi-même le fichier `.l10n.php` à côté du `.mo` habituel accélère le chargement pour les utilisateurs, via l'outil `wp i18n make-php` de WP-CLI :

```
wp i18n make-json languages/ --no-purge
wp i18n make-php languages/
```

## Autres évolutions utiles côté extensions

### Une fonction dédiée pour signaler des dépréciations avec plus de contexte

WordPress 6.5 affine le mécanisme de journalisation des messages de dépréciation et d'erreur interne, avec des informations plus précises sur l'origine de l'appel dans les traces de débogage, ce qui facilite le diagnostic quand une extension appelle une fonction dépréciée du cœur ou d'une autre extension.

### Amélioration de la détection des plugins actifs pour le multisite

Le comportement de certaines fonctions de vérification d'activation d'extension a été précisé pour les configurations multisite, réduisant certains cas où une extension activée uniquement sur le réseau n'était pas correctement détectée par du code tiers s'appuyant sur `is_plugin_active()`.

### PHP 8.3 officiellement pris en charge

WordPress 6.5 marque la prise en charge officielle de PHP 8.3 par le cœur. Pour un auteur d'extension, c'est le signal qu'il faut désormais tester activement sur cette version, en particulier si l'extension utilise des fonctionnalités de typage strict ou manipule des propriétés dynamiques — un point qui rejoint les dépréciations déjà en vigueur depuis PHP 8.2.

## Vérifier la compatibilité de sa propre extension

- Confirmer que `load_plugin_textdomain()` est appelé au bon moment (dès `plugins_loaded` depuis WordPress 4.6, plus besoin de le faire plus tôt).
- Régénérer les fichiers de traduction avec WP-CLI si vous distribuez vos propres `.mo` hors WordPress.org, pour bénéficier du gain de performance du format `.l10n.php`.
- Lancer une suite de tests sous PHP 8.3, en particulier sur les parties de code qui manipulent des tableaux typés ou des objets de valeur.
- Vérifier qu'aucun code ne dépend d'un comportement non documenté de `load_textdomain()`, comme un accès direct au tableau interne des traductions chargées.

> Un conseil qu'on donne systématiquement : ne jamais coder en dur un chemin de fichier `.mo` dans une extension. Passer par les fonctions officielles de chargement de domaine garantit que les futurs formats, comme celui-ci, sont pris en charge sans rien changer au code appelant.

## En résumé

Le format `.l10n.php` introduit par WordPress 6.5 est une évolution largement transparente pour la majorité des extensions, portée par WordPress.org lui-même pour les traductions hébergées sur GlotPress. Elle mérite néanmoins un geste actif pour les extensions qui distribuent leurs propres fichiers de langue en dehors du répertoire officiel, où la régénération via WP-CLI apporte un gain de performance réel au chargement. Associée à la prise en charge officielle de PHP 8.3, cette version confirme la tendance de fond : les auteurs d'extensions ont intérêt à suivre chaque version majeure de près, même quand les titres marquants concernent d'abord l'éditeur de blocs.