Une taxonomie de « catégories de matériaux » partagée entre trois langues peut se construire de deux façons radicalement différentes en base de données, sans qu’aucune des deux ne soit universellement meilleure : dupliquer chaque terme par langue (un terme « Bois » en français, un terme « Wood » en anglais, reliés entre eux), ou conserver un terme unique multilingue, dont les libellés par langue sont stockés en term meta plutôt que dans le terme lui-même.
Ce comparatif s’appuie sur un projet réel de catalogue de matériaux de construction, où les deux architectures ont été testées successivement avant qu’un choix définitif ne soit tranché — l’occasion de comparer leur comportement sur des critères concrets plutôt que sur des principes abstraits.
Architecture A : un terme distinct par langue
Dans cette approche, chaque langue possède son propre terme dans la taxonomie, avec une table de correspondance annexe (semblable à celle décrite dans un précédent article sur l’indexation des traductions) qui relie les termes équivalents entre eux via un identifiant de groupe.
wp_terms
├─ term_id 12, name "Bois" (groupe traduction 5, locale fr)
├─ term_id 13, name "Wood" (groupe traduction 5, locale en)
└─ term_id 14, name "Holz" (groupe traduction 5, locale de)Chaque article est associé au terme correspondant à sa propre langue, ce qui rend les requêtes de filtrage par catégorie strictement natives : un simple tax_query classique suffit, sans logique additionnelle, exactement comme sur un site monolingue.
Architecture B : un terme unique, libellés en term meta
Dans cette seconde approche, un seul terme existe réellement dans la taxonomie, et chaque langue dispose d’un libellé stocké en term meta sous une clé dédiée par langue :
wp_terms
└─ term_id 12 (slug technique "bois-generique")
wp_termmeta
├─ term_id 12, meta_key "label_fr", meta_value "Bois"
├─ term_id 12, meta_key "label_en", meta_value "Wood"
└─ term_id 12, meta_key "label_de", meta_value "Holz"Ici, chaque article, quelle que soit sa langue, est associé au même terme unique. Le filtrage par matériau devient trivial et cohérent (un seul comptage d’articles par terme, sans avoir à additionner plusieurs variantes linguistiques), mais l’affichage du libellé traduit nécessite une résolution supplémentaire à chaque rendu.
Comparatif chiffré sur le catalogue réel
| Critère | Architecture A (terme dupliqué) | Architecture B (term meta) |
|---|---|---|
| Requête de filtrage par catégorie | Native, sans logique additionnelle | Native également, une seule table de termes |
| Comptage d’articles par matériau, toutes langues confondues | Nécessite une somme sur les variantes du groupe | Direct, un seul terme à compter |
| Ajout d’une nouvelle langue | Créer un nouveau terme par catégorie existante | Ajouter une clé de term meta, aucun nouveau terme |
| Affichage du libellé traduit | Direct, le terme porte déjà le bon nom | Résolution supplémentaire à chaque affichage |
| Risque de désynchronisation entre langues | Élevé si la table de correspondance externe se corrompt | Faible, un seul terme, pas de correspondance à maintenir |
Ce que le volume d’articles par terme a changé dans la décision
Sur ce projet, la taxonomie comptait une quarantaine de termes, mais chacun regroupait potentiellement plusieurs centaines d’articles. Les statistiques de fréquentation par catégorie, affichées sur une page d’agrégation, nécessitaient un comptage précis et rapide, toutes langues confondues — un besoin qui a fortement penché en faveur de l’architecture B, où ce comptage reste natif et rapide, sans somme à calculer sur plusieurs variantes.
Ce qui a fait pencher la balance dans l’autre sens sur un projet précédent
Sur un projet antérieur, une taxonomie de « types d’événement » comptait peu de termes mais avec des libellés très différents d’une langue à l’autre, pas de simples traductions littérales mais des catégorisations culturellement distinctes. Dans ce cas, l’architecture A (terme dupliqué) s’est révélée plus adaptée, car elle permettait à chaque langue de disposer d’une hiérarchie de termes réellement indépendante plutôt que contrainte à un même terme unique sous-jacent.
- Beaucoup d’articles par terme, besoin de comptages fiables : architecture B (term meta) recommandée
- Peu de termes, hiérarchies culturellement distinctes par langue : architecture A (terme dupliqué) recommandée
- Volume et structure imprévisibles à long terme : commencer par l’architecture B, plus facile à faire évoluer sans dupliquer de structure
Aucune des deux architectures n’est fausse en soi : le choix dépend presque entièrement de ce qu’on interroge le plus souvent — le comptage global ou l’indépendance des hiérarchies par langue.
Notre verdict
Pour un catalogue à fort volume par terme, l’architecture par term meta l’emporte nettement sur la duplication de terme, en particulier pour tout ce qui touche aux statistiques et aux comptages agrégés. La duplication garde son intérêt quand les catégories elles-mêmes diffèrent structurellement d’une langue à l’autre, un cas moins fréquent qu’on ne le pense au moment de concevoir l’architecture initiale.
