# is_rtl() contre un simple test de locale : ce que vérifie la fonction cœur

> Tester si une locale commence par "ar" ou "he" pour deviner le sens de lecture semble logique. La fonction native is_rtl() ne fait pourtant pas ce test-là.

- Auteur : WordPress Développement
- Publié le : 2022-01-10
- Mis à jour le : 2022-01-10
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/is-rtl-locale-difference/

## L’essentiel

- is_rtl() ne compare aucune chaîne de caractères à une liste de codes
- Elle s'appuie sur une propriété déclarée dans le fichier de langue chargé
- Une locale personnalisée sans cette déclaration reste considérée LTR

Faut-il comparer manuellement le code de langue actif à une liste de langues s'écrivant de droite à gauche pour savoir dans quel sens afficher une interface ? La tentation est grande d'écrire une condition du type `in_array( get_locale(), array( 'ar', 'he', 'fa' ) )`, mais ce n'est pas ainsi que WordPress détermine réellement le sens de lecture d'une langue installée sur un site.

La fonction native `is_rtl()` existe justement pour éviter ce genre de liste codée en dur, fragile et incomplète dès qu'une nouvelle langue s'ajoute au projet. Comprendre ce qu'elle vérifie réellement évite de la dupliquer inutilement avec une logique maison, souvent moins fiable que le mécanisme déjà prévu par le cœur.

## Ce que is_rtl() vérifie concrètement

La fonction `is_rtl()` ne compare aucun code de langue à une liste prédéfinie. Elle interroge un objet global représentant les métadonnées de la locale active, et vérifie une propriété précise, `text_direction`, définie directement dans le fichier de langue chargé pour le site. Cette propriété vaut `rtl` pour les langues qui s'écrivent de droite à gauche, et `ltr` dans tous les autres cas, y compris pour une langue absente de toute liste codée en dur par un développeur tiers.

Concrètement, chaque fichier `.po` officiel d'une traduction fournie par le projet WordPress déclare cette information dans son en-tête, sous la forme d'un commentaire structuré que l'outillage de traduction sait renseigner correctement pour chaque langue prise en charge.

## Pourquoi une simple comparaison de code de langue échoue

> L'essentiel à retenir : is_rtl() ne compare aucune chaîne de caractères à une liste de codes ; Elle s'appuie sur une propriété déclarée dans le fichier de langue chargé ; Une locale personnalisée sans cette déclaration reste considérée LTR

Une comparaison manuelle du type suivant paraît raisonnable au premier abord :

```
function wpm_est_rtl_mauvaise_version() {
    $langues_rtl = array( 'ar', 'he', 'fa', 'ur' );
    $code_langue = substr( get_locale(), 0, 2 );

    return in_array( $code_langue, $langues_rtl, true );
}
```

Cette fonction fonctionne pour les cas les plus connus, mais oublie forcément des langues moins courantes, comme le divehi ou certaines variantes régionales, et surtout ne reflète jamais un fichier de langue personnalisé ou communautaire qui n'aurait pas encore été ajouté à cette liste manuelle. La bonne pratique reste d'utiliser directement la fonction native :

```
if ( is_rtl() ) {
    wp_enqueue_style( 'mon-theme-rtl', get_template_directory_uri() . '/rtl.css' );
}
```

Cette approche reste valable quelle que soit la langue installée, du moment que son fichier de traduction déclare correctement sa direction d'écriture, sans jamais nécessiter de mise à jour du code du thème pour une nouvelle langue ajoutée par la suite.

## Un point important : la locale de l'administration diffère parfois

Sur un site multilingue où un utilisateur peut choisir une langue d'administration différente de la langue générale du site, `is_rtl()` reflète la locale réellement active au moment de l'appel, pas nécessairement celle du site public. Un thème qui charge une feuille de style RTL selon cette fonction doit donc bien distinguer le contexte d'exécution, entre le rendu public du site et l'écran d'administration, pour éviter d'inverser le sens de lecture au mauvais endroit.

- `is_rtl()` reflète la locale active au moment précis de l'appel, pas une configuration globale figée.
- Elle s'appuie sur une déclaration du fichier de langue, jamais sur une déduction du code de langue lui-même.
- Une locale personnalisée sans fichier de traduction correctement renseigné sera traitée par défaut comme LTR.

> Un repère utile pour un thème international : ne jamais dupliquer une liste de langues RTL dans son propre code, la fonction cœur fait déjà ce travail correctement et reste à jour avec chaque nouvelle langue officiellement prise en charge.

## En résumé

Le sens de lecture d'une interface ne se déduit pas d'un simple code de langue à deux lettres, mais d'une propriété explicitement déclarée dans le fichier de traduction chargé. S'appuyer sur `is_rtl()` plutôt que sur une liste maison garantit un comportement cohérent avec l'ensemble de l'écosystème WordPress, y compris pour des langues moins courantes qu'un développeur pourrait facilement oublier d'ajouter à sa propre liste.