Cet article – ici en version anglaise – décrit le pourquoi et le comment des choix qui ont régit à la conception de l’extension xili-language pour gérer un site multilingue tout en conservant la cohérence et la robustesse du modèle de données de WordPress. La comparaison avec d’autres solutions et extensions disponibles illustrent l’approche originale de la trilogie xili-language.
Après avoir été utilisé depuis sa conception en 2009 par des webmestres responsables de site CMS multilingues, de plus en plus la trilogie xili-language est utilisé par des néophytes en WordPress. Cet article fait la synthèse de questions sur l’architecture et le modèle de données sous jacent, choisis dès sa conception et années après années qui se sont confirmées depuis la version WP 2.3. Dans ces lignes sont aussi détaillées des points exposés dans le Codex WordPress.
Quelques propriétés de base WP :
Le coeur de WP est la table des « posts » avec les principales colonnes telles que « title« , « content« , « author« , « date« ,…
Le classement des articles est basé sur les catégories et les mots clés.
La catégorie est comme un rayon dans une librairie. Les mots clés sont comme des fiches ou marques de couleur apposées au livre.
L’ajout des outils/bibliothèques logiciels de taxinomie depuis WP 2.3 apportent des moyens puissants pour créer de nouvelles régles de classement.
xili-language repose avant tout sur l’architecture robuste de WP :
xili-language depuis WP 2.3 (24 September 2007) ajoute une nouvelle taxinomie dénommée « language » avec la clé de requête « lang ».
xili-language NE MODIFIE PAS le contenu de chaque « post » (article ou page ou post adapté – custom post ). Il ne détruit pas la structure de base du modèle de données.
DB modified by qTranslate posts list
un exemple : que se passe-t-il dans l’extension qtranslate ?
dès l’activation de l’extension, tous les contenus des articles sont modifiés – nouvelles balises etc… – parce que le contenu d’un champ contient simultanément les textes des 2, 3 voir plus langues… tel que vous pouvez le voir dans cette copie d’écran de phpMyAdmin.
DONC après desactivation de l’extension, tous les contenus deviennent illisibles, inexploitables et inexportables (xmlrpc).
xili-language n’ajoute pas de table. (tel que près de 13 dans l’extension WPML – à comparer avec les 11 tables d’origine de WordPress) – il est alors très complexe de récupérer et exporter un site sous WPML (nous l’avons testé pour un très gros site depuis sous xili-language premium…
wpml tables
Pour organiser (relier selon la langue) les articles (post, page, custom post), que fait xili-language :
Seuls des champs personnalisés sont ajoutés aux posts et contiennent les identifiants vers les autres posts selon leur langue. La taxinomie reste utilisable même si l’extension est désactivée en utilisant les custom taxinomies introduites récemment. Avec quelques petites fontions, il est possible d’exporter aisément un ensemble de posts associés à une langue.
Quelques questions :
Pourquoi xili-language ne fournit pas les drapeaux associés à chaque langue ?
xili-language traite les contenus pas les aspects des thèmes. Que se passe-t-il si un pays a un seul drapeau mais trois langues officielles ?
Sur ce site, il y a un exemple de thème enfant du thème « officiel » twentyten.
Idem sur ce site, pour un exemple de thème enfant du thème « officiel » twentyeleven.
Pourquoi xili-language n’ajoute pas un interface spécifique pour avoir simultanément les différentes versions selon les langues d’un article ?
Parce que les bons navigateurs bien conçus ont des onglets et qu’en bon traducteur, on travaille aisément avec plusieurs écrans.
Pourquoi xili-language n’a pas inclut xili-tidy-tags dans la même extension pour gérer (grouper) les mots clés (tags) selon la langue ?
Parce que xili-tidy-tags peut être utilisée sur des sites en une seule langue afin de classer sémantiquement des grandes quantités de mots clés.
Pourquoi selon les extensions « pour sites multilingues », les quantités statistiques indiquées dans le dépot des extentions sont si différentes ?
Le meilleur moyen de comparer n’est pas de prendre en compte la quantité totale mais la somme des pics lors d’une mise à jour.
Pourquoi xili-language ne traduit pas ?
Il ne faut pas confondre traducteur/adaptateur qui oeuvre sur le contenu et outil (extension) de classement et d’aide à la navigation ou d’affichage des élements du thème dans la bonne langue selon le contenu de l’article (selection du fichier .mo du thème selon la langue).
L’article original dans le WordPress Codex n’est pas très explicite sur le sujet : une langue = une instance de WordPress network (multisite) ?
WordPress basiquement est traduisible mais non multilingue. La plupart des extensions sont actives dans une seule instance de WP et tous les posts sont dans le même site web. Pour modifier les comportements et les rendus pendant la navigation, les processus sont complexes et utilisent de nombreux filtres (hook, API) dans le code pour avoir des effets sur le thème, les widgets etc… L’arrivée de WP network depuis la version 3.0 permet une approche plus élégante… c’est la raison de la naissance de xili-language premium : voir cet article qui présente les spécifications essentielles.
Note: la toute récente extension Multisite Language Switcher est proche dans la méthode.
Comment choisir une extension multilingue ?
Comme une maison, une voiture, un objet… selon les qualités souhaitées, la réversibilité (après désactivation), les exigences de maintenance… et en cherchant à comprendre comme elle est conçue et comment les données sont classées, conservées modifiées… Une bonne façon de soutenir un auteur d’extensions de faire des donations mais aussi de faire appel à ses services pour faire une analyse préalable afin d’éviter de construire un site web sur du sable en bord de mer 😉
D’autres questions ? Utiliser le formulaire ci-dessous ou de préférence le forum !
Michel de dev.xiligroup
