Lien entre la base des articles et les lecteurs, un thème WordPress est en fait un ensemble de fichiers qui organisent la présentation des articles selon qu’ils soient affichés – en liste, seuls, en résultat d’une recherche,.. – et la présentation des pages qui structurent (contact, infos générales,…)
Dans certains cadres de présentation (avec des thèmes comme default-i18n – fusion – gear), les intitulés et les termes (menu, titre,…, pied de page, liens etc…) ne sont pas codés en dur . Il est donc possible de personnaliser la langue du site web en concordance avec la langue du créateur du site tel qu’il a réglé son interface d’administration car des fichiers (.mo) contiennent compilée la liste des termes dans chacune des langues disponibles.
Mais, la langue est choisie une fois pour toute. Et donc le titre d’un menu, les rubriques sous un article seront toujours dans la même langue même si l’article est dans une autre que la structure générale du site.
Ce que fait xili-language : ce n’est plus le réglage du site qui donne la langue mais, selon des règles définies, c’est la langue de l’article affiché (ou sa catégorie) qui choisit cette langue. Exemple : un internaute identifie un article via un moteur de recherche en anglais, et bien sur ce site bilingue, l’apparence (menu, entête, etc…) sera en anglais.
Autre example : si l’internaute arrive sur la page d’accueil, si c’est défini comme tel, c’est la langue de son ordinateur / navigateur qui orientera sur la bonne langue donc la bonne page d’accueil qu’elle soit composée d’un article ou d’une liste de textes récents.
Techniquement l’extension xili-language utilise les potentialités de WordPress que sont les ancrages ‘hooks’ (ou API – interface de programmation) qui permettent de personnaliser les fonctions du noyau et donc la dynamique de navigation entre les article du site et leur présentation dans le thème (l’apparence graphique et textuelle).
Pourquoi refaire une extension alors que d’autres plus ou moins sophistiquées existent dans le catalogue WordPress ?
Ces recherches et évaluations ont débutées lors de l’apparition de la version 2.3 de WP où les tables de taxinomie sont apparues dans le modèle de données. Idéal pour ranger et classer des mots de façon transversale en sus des catégories et des mots clés. De plus, la création de thèmes spécifiques avec des fonctions spécifiques à ajouter pour chaque terme étaient exclue. La seule exigence est que ces thèmes soient i18n c’est à dire « localisable ».
D’autres exigences se sont imposées : pas de modification de la struture de la base, conservation de l’entité article et de ses composants habituels (titre, contenu, résumé,…). conservation de l’organisation par catégorie quelque soit la langue de l’article. Offrir aux webmestres et web-designers une grande liberté de personnalisation autour d’un noyau dur (core) que constitue l’extension elle-même. Et enfin le code le plus léger possible par la réutilisation maximum du code php présent dans WordPress.
Quelques détails sur la trilogie des extensions xiligroup dev pour un site multilingue :
xili-language est le coeur qui gère les changements dynamiques (live) du thème selon des règles et selon la langue de l’article affichée (langue définie par l’auteur). Cette extension a une fille pour les widgets pour les menus définissables sans codage php.
xili-tidy-tags est une extension initiée pour compléter xili-language mais peut servir dans des sites plus courants. Elle offre la possibilité de classer, regrouper les mots-clés selon la langue et/ou dans un groupe commun comme les marques qui sont intraduisibles et ainsi d’afficher des nuages de ses sélections aux bons endroits. xili-tidy-tags propose aussi un widget ‘pluriel’ à la différence du nuage de base de wordpress affichable en un seul exemplaire.
xili-dictionary est un outil en ligne pour manipuler les fichiers de langue .po et .mo. Il est ainsi plus aisé de compléter les fichiers livrés par le concepteur du thème et d’y ajouter les descriptifs d’autres éléments comme les intitulés de catégories, les autres descriptifs des menus et widgets. La création des fichiers .mo peut donc se faire sans poEdit installé sur l’ordinateur du webmestre.
L’article suivant proposera deux angles pour approcher la création d’un site multilingue : celle d’un webmestre aguerri en php html et celui d’un webmestre utilisateur averti de WordPress.
A bientôt
