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
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.
