Un annuaire d’artisans locaux, construit autour d’un type de contenu personnalisé « Artisan » et d’une trentaine de groupes de champs Advanced Custom Fields (spécialités, zone d’intervention, horaires, certifications), avait été traduit en anglais et en espagnol via la configuration standard de WPML pour les champs personnalisés. Le résultat fonctionnait, mais la maintenance devenait pénible : chaque nouveau champ ajouté au groupe nécessitait une configuration manuelle supplémentaire dans les réglages WPML dédiés aux champs personnalisés, un écran distinct de celui où les champs eux-mêmes étaient définis.
Le client, gérant lui-même l’ajout de nouveaux champs pour de nouvelles catégories d’artisans, oubliait régulièrement cette étape de configuration côté WPML, ce qui produisait des champs visibles uniquement dans la langue source, jamais traduits ni traduisibles dans l’interface d’édition. La migration vers ACF Multilingual (ACFML), l’extension officielle développée par l’équipe d’Advanced Custom Fields en partenariat avec WPML, a permis de résoudre ce problème à la racine.
Ce que change ACFML par rapport à la configuration classique
Avec la configuration standard de WPML pour les champs personnalisés, la déclaration de traduisibilité d’un champ se fait dans un écran séparé (WPML → Réglages personnalisés), déconnecté de l’écran où le champ est défini dans ACF. ACFML inverse cette logique : chaque champ, au moment même de sa création dans le groupe de champs ACF, propose directement une option de traduction dans son propre écran de configuration, à l’endroit même où le champ est créé.
Ce changement, en apparence cosmétique, a un effet concret important : il devient impossible d’oublier de configurer la traduisibilité d’un nouveau champ, puisque cette option apparaît systématiquement lors de sa création, plutôt que dans un écran séparé qu’il faut penser à consulter après coup.
La méthode de migration retenue
Migrer l’intégralité des 38 groupes de champs d’un coup présentait un risque trop important d’erreur silencieuse sur un site en production avec plusieurs centaines de fiches déjà traduites. La migration a donc été menée groupe de champs par groupe de champs, en suivant cette séquence pour chacun :
- Export du groupe de champs concerné au format JSON, comme sauvegarde avant toute modification.
- Activation d’ACFML sur ce groupe précis, en configurant pour chaque champ son option de traduction (traduisible, copié tel quel entre langues, ou ignoré selon les langues).
- Vérification, sur un échantillon de cinq fiches existantes, que les traductions déjà saisies via l’ancienne configuration WPML restaient bien accessibles après activation d’ACFML.
- Test de création d’une nouvelle fiche complète, dans les trois langues, pour confirmer que le nouveau flux de traduction fonctionnait de bout en bout.
Cette approche progressive a permis d’isoler rapidement un problème mineur survenu sur le douzième groupe de champs migré : un champ de type relation (liant un artisan à ses certifications) affichait une liste vide côté traduction anglaise, un souci résolu en reconfigurant l’option de copie de valeur pour ce type de champ spécifique, qui devait rester identique entre langues plutôt que traduit.
Un exemple concret de configuration
// Champ ACF "specialite" : à traduire
// Champ ACF "zone_intervention" : à traduire
// Champ ACF "certifications" (relation) : copié, pas traduit
// Champ ACF "annee_creation" (nombre) : copié, pas traduit
Cette distinction, faite champ par champ dès la création du groupe, évite l’écueil rencontré précédemment avec la configuration WPML générique : un champ numérique ou une relation n’a en général aucune raison d’être « traduit » à proprement parler, il doit simplement rester identique entre les versions linguistiques d’une même fiche.
Ce que la migration n’a pas résolu automatiquement
ACFML facilite la configuration de nouveaux champs, mais ne corrige pas rétroactivement les champs déjà mal configurés dans l’ancien système : ceux-ci ont dû être revus manuellement un par un lors de la migration, plutôt que basculés automatiquement. La migration a également nécessité une formation courte du client, pour lui expliquer où trouver désormais l’option de traduction d’un champ, désormais intégrée à l’écran ACF plutôt que dans les réglages séparés de WPML.
Le vrai gain de cette migration n’est pas technique, il est organisationnel : le client ne peut plus oublier une étape qui n’existe simplement plus en tant qu’étape séparée.
Compatibilité et prérequis à vérifier avant de migrer
- ACFML nécessite une version récente d’Advanced Custom Fields Pro ainsi qu’une version compatible de WPML, à vérifier avant toute migration sur un site utilisant des versions anciennes non mises à jour depuis longtemps.
- Les groupes de champs utilisant des types de champs très spécifiques ou des extensions tierces d’ACF méritent un test isolé avant migration généralisée, certains types de champs personnalisés n’étant pas nativement pris en charge par ACFML.
- Une sauvegarde complète de la base de données avant chaque groupe migré reste indispensable, la migration modifiant la structure de stockage des traductions existantes.
En résumé
La migration vers ACF Multilingual n’a rien changé du point de vue du visiteur final : le contenu affiché reste strictement identique avant et après. Le bénéfice se mesure uniquement côté équipe éditoriale, avec une réduction nette des oublis de configuration constatés sur les mois suivant la migration. Sur un projet où le client gère lui-même l’ajout de nouveaux champs sans accompagnement technique permanent, ce type de migration mérite d’être envisagé dès que la configuration classique commence à montrer ses limites en usage réel.
