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,