# Traduire un configurateur e-learning de parcours pédagogiques personnalisés

> Un configurateur de parcours adaptatifs pose un problème que la traduction classique ignore : traduire une logique, pas seulement des phrases.

- Auteur : Clément Hadrot
- Publié le : 2024-11-28
- Mis à jour le : 2024-11-28
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/configurateur-elearning-parcours-traduction/

## L’essentiel

- Les conditions de branchement référencent des identifiants, pas des textes
- Un module traduit peut casser une règle écrite pour l'original
- Séparer la logique du contenu affiché simplifie tout

Un configurateur de parcours pédagogiques pose une question que la plupart des sites multilingues n'ont jamais à traiter : que traduit-on quand le contenu affiché dépend d'une logique conditionnelle invisible à l'écran ? Sur une plateforme de formation professionnelle construite autour de Tutor LMS et d'un plugin maison de branchement, cette question a structuré tout le projet de traduction.

Le principe du configurateur est simple à décrire : l'apprenant répond à un questionnaire de positionnement, et le système assemble un parcours à partir de quarante modules disponibles, selon des règles du type « si le score en gestion de projet est inférieur à 60 %, proposer le module 12 avant le module 7 ». Traduire les modules eux-mêmes relevait d'un travail multilingue classique. Traduire la logique de branchement en était un tout autre.

## Où vit la logique de branchement

Dans l'architecture d'origine, les règles de branchement étaient stockées en tant que métadonnées de champs ACF sur chaque module, sous forme de conditions faisant référence à l'ID du post d'un autre module en version française. Ce choix, cohérent tant que le site restait monolingue, posait un problème structurel dès l'ajout d'une deuxième langue avec Polylang : un module traduit reçoit un nouvel ID de post, distinct de l'original.

Résultat, une règle écrite pour la version française du module 7 continuait de pointer vers l'ID français même une fois la version anglaise consultée, cassant silencieusement le parcours pour les apprenants anglophones. Aucune erreur visible ne remontait : le configurateur affichait simplement le mauvais module suivant, ou aucun module du tout.

## Découpler l'identifiant logique de l'identifiant WordPress

> L'essentiel à retenir : Les conditions de branchement référencent des identifiants, pas des textes ; Un module traduit peut casser une règle écrite pour l'original ; Séparer la logique du contenu affiché simplifie tout

La correction structurelle a consisté à introduire un identifiant logique stable, indépendant de la langue, stocké dans un champ ACF texte nommé `module_key` et partagé par toutes les traductions d'un même module via `pll_get_post`. Les règles de branchement référencent désormais cette clé logique plutôt qu'un ID de post WordPress, quelle que soit la langue consultée.

```
function get_module_by_key( $key, $lang = null ) {
    $lang = $lang ?: pll_current_language();
    $query = new WP_Query( array(
        'post_type'  => 'module',
        'lang'       => $lang,
        'meta_key'   => 'module_key',
        'meta_value' => $key,
        'posts_per_page' => 1,
    ) );
    return $query->have_posts() ? $query->posts[0] : null;
}
```

Cette fonction résout, pour une clé logique donnée, le module correspondant dans la langue active. Les règles de branchement, elles, ne manipulent plus que des clés logiques comme `gestion-projet-avance`, jamais d'ID de post. Le contenu peut être traduit, dupliqué ou réorganisé sans jamais casser la logique du parcours.

### Traduire les libellés des conditions elles-mêmes

Un second niveau de traduction concernait les libellés affichés à l'apprenant pendant le questionnaire de positionnement, par exemple les intitulés des compétences évaluées. Ces libellés, gérés via WPML String Translation, ont dû être synchronisés avec la même rigueur que les clés logiques, sous peine d'afficher une compétence en français dans un parcours par ailleurs entièrement en anglais.

- Les identifiants de branchement doivent être indépendants de la langue.
- Les libellés de conditions se traduisent séparément du contenu des modules.
- Un test de parcours complet dans chaque langue reste indispensable après toute modification.

## Tester un parcours n'est pas tester un module

La recette qualité classique consistait à relire chaque module traduit indépendamment. Elle s'est révélée insuffisante : un module parfaitement traduit pouvait néanmoins provoquer un parcours incohérent si la règle de branchement associée n'avait pas été mise à jour avec la bonne clé logique. L'équipe a donc ajouté une étape de recette spécifique, consistant à dérouler le questionnaire de positionnement dans chaque langue et à vérifier que la séquence de modules proposée restait identique, module pour module, à celle de la version source.

> Un configurateur pédagogique se teste comme un parcours utilisateur complet, jamais comme une collection de pages traduites isolément.

## Ce que cette architecture a coûté, et ce qu'elle a évité

Le refactoring de la clé logique a demandé un peu plus de deux semaines de développement, migration des données existantes comprise. En contrepartie, l'ajout d'une troisième langue, l'espagnol, six mois plus tard, n'a nécessité aucune modification du système de branchement : seule la traduction des modules et des libellés a été nécessaire, sans toucher une ligne de logique métier.

## Pour aller plus loin

Toute plateforme pédagogique adaptative devrait, dès sa conception, séparer strictement trois couches : le contenu affiché, traduisible librement ; la logique de branchement, qui doit rester indépendante de la langue par construction ; et les libellés de configuration, qui se traduisent comme des chaînes de thème classiques. Confondre ces couches fonctionne tant que le site reste monolingue, et se paie cher dès la première traduction.