Il y a plus de 5 ans, quand xili-language a été créée, en gros il y avait deux extensions d’architecture très différentes WPML et qTranslate et aucune des deux ne respectaient l’architecture du noyau WordPress puisque la première ajoutait de nombreuses tables et la seconde modifiait le contenu des posts en compactant les différentes languages dans chacun des champs. C’est vrai que les taxonomies venaient d’apparaître avec WP 2.3. Aujourd’hui, l’offre est pléthorique comme la comparaison en cours tente de le montrer.
Deux extensions sont apparues récemment et leur architecture, une fois installée vont compromettre plus ou moins gravement la base de données. “Multilanguage” ajoute des tables pour mettre les traductions des posts donc sans extension, impossible de les récupérer. WPGlobus “Multilingual everything” lui modifie comme qTranslate (et ses successeurs qTranslateX) les contenus comme le montre les tables de la base ci-dessous:
et quand on rend multilingue (via les onglets), on note la modification importante des champs de la table post… chaque champ contenant ici les trois langues entre {} ! Comment vont alors se faire les requêtes ? En tout cas pas selon les règles de WP_Query 🙁
“Babble” n’utilise pas les taxonomies mais les custom post types pour ranger les posts selon la langue. Pas facile pour les requêtes… à suivre car par encore officiellement dans le dépôt des plugins (repository).
Travailler avec un gestionnaire de contenus (CMS) tel que WordPress nécessite quelques principes dont le premier est de conserver l’intégrité des données avant et après l’ajout d’étiquette qui spécifie le langage (taxonomie) ou les liens avec des articles correspondants dans d’autres langues (champ personnalisé). C’est le principe de base de la trilogie xili-language établi dès sa création et qui perdure de la version de WP 2.3 à la 4.2 qui va bientôt sortir.
