Le WordPress d'aujourd'hui, décodé pour les développeurs

Multilingue

Traduire un configurateur de devis BTP avec des champs conditionnels

Étapes concrètes pour traduire un configurateur de matériaux et de surfaces dont certaines options n'existent que dans certains pays, sans casser la logique conditionnelle.

Par Clément Hadrot • 19 mai 2024 • 4 min de lecture • Aucun commentaire
Traduire un configurateur de devis BTP avec des champs conditionnels

Un fabricant de matériaux de construction propose sur son site un configurateur permettant à un artisan d’estimer la quantité et le type d’isolant nécessaire selon la surface, le type de toiture et la région climatique. Ce configurateur, construit avec des champs ACF conditionnels, dessert quatre pays, et une contrainte s’impose rapidement : certaines options de matériaux autorisées dans un pays n’existent tout simplement pas dans un autre, pour des raisons de normes locales.

Traduire ce type d’outil ne consiste pas à traduire du texte affiché, mais à traduire une logique conditionnelle entière sans la casser. Voici les étapes suivies pour y parvenir proprement.

Étape 1 : séparer la clé technique du libellé affiché

La première règle, souvent négligée, consiste à ne jamais coder la logique conditionnelle sur le texte affiché à l’utilisateur. Chaque option de matériau porte une clé technique stable (laine_de_verre, pare_vapeur_renforce) et un libellé traduit séparément via Polylang String Translation ou un champ ACF traduisible. Le champ conditionnel du configurateur compare toujours les clés, jamais les libellés.

if ( in_array( $option_selectionnee['cle'], $options_disponibles_pays, true ) ) {
    afficher_champ_suivant( $option_selectionnee );
}

Étape 2 : déclarer une liste d’options par pays

Chaque pays dessert une liste distincte d’options disponibles, stockée dans un champ ACF de type relation rattaché à une taxonomie pays_norme, indépendante de la langue Polylang. C’est une distinction importante : le pays de norme et la langue de l’utilisateur sont deux axes séparés, un artisan francophone en Belgique et un artisan francophone en France ne voient pas la même liste d’options bien qu’ils partagent la même langue d’affichage.

$options_disponibles_pays = get_field( 'options_isolant', 'pays_norme_' . $code_pays_selectionne );
L'essentiel à retenir : Séparer la liste d'options disponibles de leur libellé traduit ; Chaque pays garde sa propre liste de choix valides ; La logique conditionnelle se code sur des clés, jamais sur des libellés

Étape 3 : gérer l’option absente sans casser le parcours

Quand un artisan change de pays en cours de configuration et qu’une option précédemment choisie n’existe plus dans la nouvelle liste, le configurateur doit réinitialiser proprement ce champ plutôt que de laisser une valeur invalide en mémoire :

  • Détecter le changement de pays via l’événement de changement du sélecteur.
  • Vérifier si la clé actuellement sélectionnée figure dans la nouvelle liste d’options disponibles.
  • Si absente, réinitialiser le champ et afficher un message expliquant que cette option n’est pas disponible dans le pays choisi, dans la langue courante de l’utilisateur.

Étape 4 : traduire les messages d’indisponibilité sans les coder en dur

Le message « cette option n’est pas disponible dans votre pays » doit lui-même passer par le mécanisme de traduction du site plutôt que d’être écrit en dur dans le JavaScript du configurateur :

const messages = window.monConfigurateurI18n;
afficherMessage( messages.option_indisponible );

Ces chaînes JavaScript sont exposées via wp_localize_script(), en s’appuyant sur des traductions gérées côté PHP avec pll__(), ce qui évite de dupliquer un fichier de traduction JavaScript en parallèle du système de traduction du site.

Étape 5 : tester chaque combinaison pays/langue

Avec quatre pays et deux langues courantes par pays en moyenne, la matrice de test compte une dizaine de combinaisons. Un tableau de recette simple, coché manuellement avant chaque mise à jour du configurateur, a permis d’éviter la régression la plus fréquente sur ce type d’outil : une option devenue disponible dans un nouveau pays mais oubliée dans la liste ACF correspondante, ce qui bloquait silencieusement une partie du parcours.

Un configurateur multilingue et multi-normes se pense d’abord comme un arbre de décision sur des clés stables, la traduction n’intervenant qu’en toute dernière couche, sur l’affichage.

En résumé

La difficulté de ce type de projet ne se situe jamais dans Polylang lui-même, mais dans la modélisation des données : séparer strictement la clé technique de son libellé, et séparer le pays de norme de la langue d’affichage, sont les deux décisions qui déterminent si le configurateur reste maintenable sur la durée.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi