# Polices adaptées à chaque écriture dans un thème bloc multilingue

> La même police latine sur la version japonaise d'un site multilingue rendait le texte illisible. Voici comment adapter les styles globaux d'un thème bloc par langue.

- Auteur : Clément Hadrot
- Publié le : 2025-05-07
- Mis à jour le : 2025-05-07
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/polices-styles-globaux-theme-bloc-multilingue/

## L’essentiel

- theme.json ne prévoit pas nativement de variation par langue
- La solution passe par un filtre PHP côté rendu
- Chaque écriture a ses propres contraintes de graisse et d'interlignage

Un éditeur de contenus B2B nous a contactés après le lancement de la version japonaise de son site : le texte, bien que correctement traduit, était perçu comme « cheap » et difficile à lire par ses contacts locaux. Le coupable n'était pas la traduction elle-même mais la police. Le thème bloc utilisait une police latine élégante, une slab serif assez fine, appliquée telle quelle aux caractères japonais via la pile de polices de secours du navigateur. Résultat : des kanjis rendus dans une police système par défaut, sans aucune cohérence avec l'identité visuelle du site.

Ce n'est pas un cas isolé. Dès qu'un site multilingue mélange écritures latines et non latines (japonais, coréen, arabe, thaï), les styles globaux définis dans `theme.json` doivent être adaptés, car ce fichier ne prévoit aucune variation par langue nativement. Voici la méthode que nous avons retenue pour ce projet, sans revenir sur la question du sélecteur RTL que nous avons déjà traitée par ailleurs.

## Pourquoi theme.json ne suffit pas

Le fichier `theme.json` définit une pile de polices globale via `settings.typography.fontFamilies`, appliquée uniformément à tout le contenu du site, quelle que soit la langue affichée. Il n'existe pas de mécanisme natif permettant de dire « si la langue est `ja`, utiliser telle police et tel interlignage ». Le thème bloc génère ses styles CSS une fois pour toutes lors du build, sans notion de contexte linguistique côté rendu.

Deux approches sont possibles : générer des feuilles de styles conditionnelles par langue, ou injecter une surcharge CSS ciblée via l'attribut `lang` présent sur la balise `html`. Nous avons opté pour la seconde, plus légère et plus facile à maintenir dans la durée.

## Étape 1 : identifier la police adaptée à chaque écriture

Avant tout code, il a fallu choisir des polices réellement conçues pour le japonais plutôt que de compter sur le rendu par défaut. Nous avons retenu Noto Sans JP pour sa couverture complète des kanjis et sa cohérence graphique avec la police latine du site (Inter). Pour l'interlignage, la littérature typographique recommande généralement un ratio proche de 1.7 pour le japonais contre 1.5 en français, car les caractères CJK sont visuellement plus denses et nécessitent plus d'air vertical pour rester lisibles.

## Étape 2 : surcharger les styles globaux par langue

> L'essentiel à retenir : theme.json ne prévoit pas nativement de variation par langue ; La solution passe par un filtre PHP côté rendu ; Chaque écriture a ses propres contraintes de graisse et d'interlignage

Plutôt que de modifier `theme.json` à la main pour chaque langue (ce qui casserait l'édition visuelle dans l'éditeur de site), nous avons ajouté une feuille de style conditionnelle enqueue via un hook PHP, ciblant l'attribut `lang` :

```
add_action( 'wp_enqueue_scripts', function () {
    $langue = apply_filters( 'wpml_current_language', null );

    if ( 'ja' === $langue ) {
        wp_enqueue_style(
            'theme-typo-ja',
            get_theme_file_uri( 'assets/css/typo-ja.css' ),
            array( 'wp-block-library' ),
            wp_get_theme()->get( 'Version' )
        );
    }
} );
```

Le fichier `typo-ja.css` cible les sélecteurs générés par le thème bloc pour surcharger uniquement la police et l'interlignage, sans toucher aux couleurs ni aux marges héritées de `theme.json` :

```
body[lang="ja"] {
    font-family: "Noto Sans JP", "Inter", sans-serif;
    line-height: 1.7;
}

body[lang="ja"] h1,
body[lang="ja"] h2,
body[lang="ja"] h3 {
    font-weight: 700;
    letter-spacing: 0.02em;
}
```

### Vérifier l'attribut lang côté HTML

Ce mécanisme suppose que la balise `html` ou `body` porte bien l'attribut `lang` correspondant à la langue affichée. Sur un site WPML, ce comportement est natif via le filtre `wpml_current_language` et la fonction `get_language_attributes()` présente dans la plupart des thèmes. Sur un thème bloc plus récent, il est parfois nécessaire de vérifier que le fichier `header.html` du template n'a pas été modifié pour retirer cet attribut, ce qui arrive plus souvent qu'on ne le pense sur des thèmes personnalisés.

## Étape 3 : traiter le cas des variations de blocs

Un piège fréquent : certains blocs Gutenberg (citation, groupe avec fond coloré) définissent leur propre `font-size` en valeur fixe dans leurs styles enregistrés. Ces valeurs, pensées pour du texte latin, écrasent parfois la police de langue si la spécificité CSS du bloc est supérieure à celle de la surcharge. Nous avons dû ajouter `!important` sur la propriété `font-family` uniquement — jamais sur `font-size`, pour ne pas casser la fluid typography définie ailleurs dans le thème.

- Testez systématiquement les blocs de citation, table des matières et galerie, qui embarquent souvent leurs propres styles ;
- Vérifiez le rendu des caractères CJK dans les champs de formulaire (Contact Form 7, Gravity Forms), souvent oubliés dans ce type d'adaptation ;
- Contrôlez l'affichage sur mobile, où l'interlignage augmenté peut pousser du contenu sous la ligne de flottaison plus vite qu'en desktop.

## Résultat pour le client

Après mise en production, le taux de rebond sur la version japonaise a diminué de façon notable dès le premier mois, sans autre changement que cette adaptation typographique. Ce cas illustre un point souvent sous-estimé dans les projets multilingues : la traduction du texte n'est qu'une partie du travail, l'adaptation de la mise en forme à l'écriture cible en est une autre, tout aussi déterminante pour la perception de qualité du site par des visiteurs natifs.

## Notre verdict

Sur tout projet multilingue mélangeant écritures latines et non latines, nous recommandons désormais de prévoir cette adaptation dès le cahier des charges, plutôt que de la découvrir après lancement via les retours d'utilisateurs. Le coût de mise en œuvre est faible — une feuille de style conditionnelle et un hook d'enqueue — comparé au coût de perception d'un site jugé négligé par son public cible.