Après une parenthèse de plusieurs trimestres, la poursuite des recherches et développement autour de la trilogie xili-language reprend progressivement. L’offre d’extensions pour créer des sites WordPress multilingues est pléthorique mais seules deux utilisent l’approche taxinomique. Sur ce site basé sur 2014-xili, thème enfant multilingue de Twenty Fourteen, restent les documents principaux concernant la trilogie. A la suite du WordCamp Europe Paris de juin 2017, le site basé sur 2017-xili, thème enfant multilingue de Twenty Seventeen, contiendra les dernières informations et actualisations.
M.
Tous les articles par Michel
xili-language version 2.21.0
L’extension coeur de sa trilogie xili-language poursuit son développement…
Le widget “liste de langues” ou sélecteur de language
Après la période consacrée à la gestion des menus et de leur style avec image (drapeau), voici le moment venu de revoir le widget “liste de langues” ou sélecteur de language (switcher).
L’adjonction d’images se fait sur la base d’une feuille de style intégrée dans le header si et seulement si ce widget est actif. (grâce à la fonction is_widget_active). Comme pour les menus, il faut que le thème supporte (add_theme_support) le “custom_xili_flag” introduit avec xili-language version 2.15.
Trois styles possibles : texte seul (comme avant), image + texte et image/drapeau seul (en liste horizontale compacte).
Les images peuvent avoir trois origines :
– celles prévues par la développeur du thème (donc dans un sous-dossier du thème et déclarées lors du setup du thème)
– celles introduits comme image de menu dans le catalogue média associée à une langue
– et en cas d’absence, pour quelques images prévues dans l’extension.
Importation des données multilingues d’une installation pilotée auparavant par Polylang
Quelques années après la naissance de xili-language, Polylang a choisi aussi la voie de la taxinomie “language” pour organiser les posts selon leur langue. L’implantation un peu différente de cette taxinomie est commentée ici. Cette approche conserve les posts (article, page) dans leur état initial. Dans une approche résolument simple avec une ergonomie efficace, son succès démontre qu’elle répond aux attentes dans un contexte multilingue très concurrentiel. Mais comme pour la musique, les voitures, le webmestre/développeur peut souhaiter des qualités différentes ou complémentaires, c’est pour cela, hormis d’autres raisons, que la trilogie xili-language continue son développement.
Si, cours de la vie d’un site internet, le besoin apparaît, xili-language version 2.1+ est capable de détecter la présence précédente de Polylang et de récupérer les données pour continuer le mode multilingue avec la trilogie (xili-tidy-tags, xili-dictionary). Attention, il faut simplement dans la liste des extensions, désactiver Polylang sans le supprimer car sinon, faute d’option prévue à cet effet par son auteur, toutes les données spécifiques à Polylang seront supprimées. Une fois, xili-language activée, un processus semi-automatique en plusieurs étapes se met en place… c’est l’objet d’un article spécialement dédié aux étapes à suivre.
Option de visibilité des widgets selon la langue courante
Si l’option est activée (5e onglet), le webmestre trouve dans l’interface de chaque widget un groupe de menus déroulants pour décider si ce widget doit apparaître ou non.
Cette option est accessible aussi dans la personnalisation.
corrections diverses
Chaque version est l’occasion de corriger et d’optimiser le code notamment en intégrant des fonctions apparues depuis WP 4.1. ou des versions de javascript récentes.
amélioration du code et des algorithmes
Ajout de filtres pour personnaliser le style de mise en place des images/drapeaux dans le sélecteur de langue.
Ajout du nouveau thème twenty sixteen dans la liste des thèmes de base livrée avec WordPress.
Les versions intermédiaires avant publication sur le dépôt WP (repository) sont disponibles sur GitHub
Importation des données multilingues d’une installation pilotée auparavant par Polylang
Préambule
TRES IMPORTANT : le changement d’extensions doit être précédé IMPERATIVEMENT par une sauvegarde de la base de données.
La réalisation de sauvegardes a été très utile dans les phases de développements de cette nouvelle fonctionnalité pour xili-language 2.21+ et permettait à tout moment de revenir à une phase antérieure.
Même si la taxonomie de xili-language et polylang ont le même nom, il y des différences expliqués dans cet article.
Ceci concerne des webmestres avec un bon niveau de connaissance de WordPress… et des raisons “CMS” qui les motivent à passer de Polylang à xili-language (2.21+).
Préparation
Installation SANS ACTIVATION des 3 extensions xili-language, xili-tidy-tags et xili-dictionary. Soit via FTP soit via la liste des extensions.
Ouvrir plusieurs onglets dans votre navigateur : deux sur la liste des extensions, un sur le site côté visiteur et un sur le tableau de bord
Désactivation de Polylang
Attention, il faut dans la liste des extensions, simplement désactiver Polylang sans le supprimer car sinon, faute d’option prévue à cet effet par son auteur, toutes les données spécifiques à Polylang seront supprimées.
Une fois, xili-language activée, un processus semi-automatique en plusieurs étapes se met en place et ouvre la page d’accueil
Une fois sur les pages de paramétrages, on voit que les éléments laissés par Polylang sont détectés et transformés pour la gestion multilingue par xili-language :
Régénération des éléments multilingues
La régénération des liens entre posts effectuées, le message indique d’aller dans l’onglet Réglages Expert.
Comme l’étape suivante concerne les taxinomies, aller dans l’onglet du navigateur préparé au préalable où il y a la liste des extensions et activer xili-tidy-tags :
Revenons à la page de réglages Expert de xili-language et à la fenêtre (meta-box) “actions et paramètres spéciaux”:
Les opérations liées aux taxinomies concernent les étiquettes (post_tag) avant tout:
avec l’écran dans le groupage xili-tidy-tags
Elles préparent les éléments pour les catégories qui sont gérées en mode traduction (sans clonage) par xili-language avec xili-dictionary. (voir l’article…)
Pour nettoyer la base WP avant de supprimer l’extension Polylang, il faut passer à l’étape suivante (ceci peut-être fait plus tard) :
ATTENTION :
Il va de soit que désormais, Polylang ne doit pas être réactivée. Pour revenir en arrière : utiliser les backups.
Les fichiers Polylang sont supprimables via la page de liste des extensions ou mieux via FTP. xili-language a fait en sorte toutefois de renommer le fichier uninstall.php en uninstall_XL_desactived.php afin qu’il ne détruise pas notamment la taxonomie “language” lors du processus suppression géré par WP.
Les taxinomies et les extensions multilingues
Depuis 2009, xili-language suivi deux ans après de Polylang sont deux extensions qui utilisent une taxinomie nommée “language”. Cela est possible depuis WP 2.3 – voir fichier taxonomy.php
Le principal avantage de cette approche ‘taxonomy‘ est que l’on ne détruit pas les enregistrements (post) originaux. (En effet, d’autres extensions modifient les champs ‘post_content’ et ajoutent des tables…)
Comme celles de base les catégories (category) et les mots-clés/étiquettes (post_tag), chaque élément (term) de la taxinomie est décrit par son nom, son raccourci (slug) et sa description. Les autres champs sont des éléments techniques (term_id, taxonomy_id,…)
Exemple de la catégorie “Recent News”
– Name : Recent News
– Slug : recent-news
– Description : the most recent news to be published
Dans xili-language et la taxinomie “language”, une langue est définie ainsi :
– Name : fr_FR (iso)
– Slug : fr_fr
– Description : French
et
dans Polylang, le choix est différent :
– Name : French
– Slug : fr (raccourci)
– Description : plusieurs données sérialisées d’un tableau (array) dont le nom iso (locale => fr_FR) utilisé par WP pour dénommer les fichiers de traduction.
Le point clé (pivot) est dans les deux cas, ce code iso qui décrit la langue et le pays de son utilisation : fr_CA est utilisé au Canada si l’on veut être précis.
L’utilisation de données sérialisées dans la champ description est une originalité de Polylang que l’on ne retrouve pas dans WP. De tels champs ne permettent pas de requête SQL.
Comme le montre le fichier locale.php de JetPack (utilisé par xili-language), la gestion des langues est très complexe et utilisent plusieurs codages. On peut y trouver d’autres éléments invariants comme le nom dans la langue citée (français) et son sens (ltr). En fait, il y a très peu de langues dites rtl.
Moyennant quelques centaines de lignes, xili-language (2.21+) peut récupérer les éléments multilingues d’une précédente installation pilotée par Polylang.
xili-dictionary est lui compatible avec Polylang (grâce à des filtres et une abstraction du modèle de taxinomie), pour, par exemple, traduire des fichiers de langue pour un thème ou une extension avec génération de fichiers pot, po, mo) mais aussi récupérer les chaînes.
Quoi de neuf avec xili-language version 2.20 ?
Tout d’abord la compatibilité de xili-language se vérifie avec WordPress 4.3 “Billie”.
Bien connues des donateurs, contributeurs, les fonctions liées aux permaliens présentes dans les thèmes enfant 201x-xili des thèmes de base sont maintenant incluses dans l’extension elle-même. Il est donc possible pour tous les thèmes respectant les règles du noyau (core) de WP d’avoir des permaliens avec insertion au début de langue en cours au lieu du paramètre ?lang=fr_fr en fin d’URI par exemple. Noter aussi que la langue peut-être un raccourci de son code ISO mais aussi un alias à votre convenance lié à l’activité du site ou sa géographie.
Premiers tests possibles avec le nouveau thème twenty sixteen (et son enfant multilingue).
D’autres corrections et améliorations du code continuent leur progression notamment pour des parties de parfois plus de 5 ans. 😉
Note : pour le moment, vue la sophistication des réglages, l’absence de filtre, l’approche php/javascript du customizer, ce dernier (en français = personnalisation) n’est pas actif notamment pour les menus (spéciaux avec insertion).
xili-language et WooCommerce – une boutique multilingue
Qu’est-ce qu’une boutique multilingue ?
- voir la liste des produits, son panier, sa page de commande dans sa langue,
- avoir des fiches produits lisibles dans chacune des langues du site.
WooCommerce est-elle une extension compatible multilingue ?
Oui, pour plusieurs raisons :
– le moteur WooCommerce repose sur les éléments clés du noyau (core) de WordPress (custom post type, canevas des thèmes (template)),…
Les produits (stocké en “custom post type”) pourront donc être affectés par la taxinomie ‘language’.
– comme BuddyPress, bbPress, l’objet “boutique” est étanche et permet un dialogue avec WP, les extensions via de nombreux filtres même pendant les process Ajax/JSON. Il s’insère par défaut dans des pages WP pré-définies.
– dans le contexte multilingue, il s’agit de passer la langue courante d’affichage dans les requêtes de WooCommerce. Via une petite dizaine de filtres, ce message ‘langue’ est passée.
Tout le travail d’adaptation consiste donc à identifier ces filtres dans WooCommerce pour que cette dernière puisse sélectionner le bon fichier langue à la volée pour l’affichage dans son container.
Réglages dans xili-language
- ajout du CPT Product pour être classable dans la taxonomie ‘language’ de XL
- réglages de gestion du domaine texte WooCommerce en mode filtre.
- ajout dans functions.php du thème de l’appel aux functions de filtrage de WooCommerce.
La ligne des temps du moteur WooCommerce dans WordPress + Xili-language
- les 2 filtres clé pour WooCommerce : “
before_woocommerce_init” et “plugin_locale“ - les filtres des liens et boutons :
'woocommerce_get_' . $pagename . '_page_id'
A suivre…
WP 4.3 et xili-language 2.19.3+
La sortie de WordPress 4.3 Billie est sortie imminente (version RC2 ce jour). Xili-language (version 2.19.3+), qui repose dès sa création sur la taxinomie “language” et la sélection de fichier de langue (.mo) continue à être compatible pour gérer un site multilingue.
Cette compatibilité se confirme, après bbPress, pour des extensions comme WooCommerce (qui est très bien écrite) : moyennant quelques réglages et un petit kit de quelques filtres, la création d’une boutique multilingue est possible et l’acheteur aura la vitrine, son panier et le bon de commande dans la langue choisie…
WordPress 4.3 introduit la possibilité de créer et ajuster des menus dans le personnalisateur (customizer) à l’ergonomie controversée reposant sur javascript. Pour le moment, faute de filtre (hook) efficace disponible, xili-language ne prend pas en compte cette aspect. Donc, pour des menus avec des points d’insertion sélecteur d’autres menus, continuez à utiliser la page Apparence/Menus qui est plus lisible.
La version 2.19.3 ajoute des améliorations pour gérer des langues moins courantes comme celles avec un ISO en trois (arq) ou six caractères (haw_US).
Le thème enfant twentyfifteen-xili contient un exemple de champ texte complémentaire (copyright) ajustable dans le personnalisateur (fonction theme_mod).
A suivre avec la version 2.20 incluant plusieurs améliorations…
xili-language mis à jour en version 2.19
La mise à jour de xili-language en version 2.19 améliore et ajoute des fonctionnalités et permet la compatibilité avec WP 4.3-beta et ses nouveaux apports
-
Côté admin (tableau de bord)
Ajoute des liens dans l’éditeur de post pour voir les traductions d’autres posts liés,
pre-tests avec WP 4.3-beta1: corrige des éléments pour le (nouveau) WP Theme Customizer Menus -
Editions
Ajout du shortcode comme ici[linked-post-in lang="fr_fr"]Voir cet article -
Développeur de Themes
Par ajout ciblé de filtre gère les valeurs dites theme_mod (comme dans config.xml) voir le thème enfant multilingue twentyfifteen-xili en exemple dans github
WordPress monosite multilingue : cahier des charges possible
Il y a dix huit mois, début 2014, une étude comparative poussée des solutions multilingues avait été commencée. Dans le contexte d’une installation mono-site de WordPress, est-il possible de définir un cahier des charges qui permette de faire un choix adapté ?
La première contrainte est celle d’un site installé avec un moteur WordPress mono-site. (l’approche sur une installation multisite n’est pas traitée ici même si elle a ses propres avantages.)
Tout en faisant du support technique et en faisant des analyses de site et d’extensions, à plusieurs reprises, dont récemment, nous avons attiré l’attention sur des extensions parfois anciennes ou réputées (gratuites ou commerciales) qui modifient profondément les données (cohérence et robustesse) et l’architecture de base. Bien sûr ces sites web fonctionnent mais qu’y a-t-il derrière ? Comment les données vont-elles supporter les approches de type Json Api etc… sans évoquer bien-sûr la compatibilité avec les extensions les plus courantes.
Retenons aussi qu’un site web multilingue n’est pas nécessairement un ensemble de pages dont chacune a son “clone” dans les autres langues du site. L’expérience utilisateur va aussi dépendre des populations ciblées (pays multilingue comme le Canada, la Belgique, …) ou site international “global”. Le caractère “multilingue” doit être pris en compte dans la stratégie éditoriale (content strategy) et les capacités de mise en place, d’exploitation et de maintenance.
Peu s’en faut, le caractère commercial d’une extension n’est pas un gage de solidité. La possibilité de lire les sources peut aussi éclairer les webmestres qui sur la base fournie pourront ajouter les personnalisations nécessaires et contribuer aux futures versions.
En vrac : quelques éléments clés du cahier des charges
Sur cette première liste, sont énumérés des éléments avant tout technique qui seront la base d’une installation solide qui pourra perdurer avec les versions successives de WP.
- taxinomie dédiée à la langue d’un post (article, page, custom post) avec 0, une ou plusieurs langues affectées à celui-ci,
- possibilité de décrire la langue avec les codes ISO et via un alias,
- utilisation des fonctionnalités gettext (.mo/.po) pour les textes structurels des thèmes et formulaires,
- dans le noyau, un thème, une extension : séparation des données concernant le côté visiteur et le côté admin/auteur, (encore imcomplet pour le noyau de WP – core)
- utilisation de fichiers .mo dédiés aux sites afin de ne pas modifier ceux livrés avec les thèmes et extensions,
- compatibilité default, short et perma links,
- requête avec wp_query simple pour sous-sélectionner les éléments,
- code compréhensible pour faire des potentielles adaptations
- lien inter-post visible (? serialization dans la description de taxonomie ou champ personnalisé ?),
- réversibité ( retrouver datas avec fonctions wp de base ) – taxonomie facilement utilisable
- sélecteur de langues (switcher) polyvalent (widget, menu, template tag)
- Mots clés (étiquettes) taxonomie – groupage (alias), custom taxonomies
- export / import via XML
- xmlrpc – json,
- filtres disponibles, personnalisation,
- pas de nouvelles tables,
- tableau de bord (dashboard) avec composants disponibles type metabox (minimum de js, onglet du browser),
- option images/drapeaux paramétrables (tout format, tout nom) – définissable par le créateur du thème et l’utilisateur
- documentation inline (aide, pointer js),
- cookies / domain : options à étudier,
En vrac : quelques éléments rédhibitoires qui incitent à aborder certaines extensions avec d’immenses précautions
- Modification des champs (titre, contenu,…) des posts (article, page) – en contradiction totale avec le modèle de données WordPress –
- Ajout de traduction de posts dans des nouvelles tables ou sous forme de custom post type
- Absence de descriptif explicite du modèle – toutefois souvent visible (devinable) dans le fichier uninstall.php
A suivre,
xili-theme select
Après deux ans d’interruption, le développement de l’extension xili-theme select a repris.
Cette petite extension permet à WordPress de générer un thème choisi selon des règles liés au périphérique/navigateur.
Pourquoi ?
– pour être prêt à la multitude des smartphones, tablettes, phablettes, etc…
– pour proposer une alternative moins gourmande en code aux offres “responsive” très en vogue mais le plus souvent basées sur la taille de l’écran.
– pour intégrer des règles plus pointues qui sélectionnent le thème voulu selon le périphérique/navigateur cible.
– pour mettre à jour l’approche avec les bibliothèques de code WP et autres.
La prochaine étape :
– ajout de la possibilité d’introduire ses propres règles personnalisées.
– proposer un thème WordPress smartphone de test basé sur la bibliothèque Framework 7.
