Tag Archives: featured

Multilingual WP plugins and (custom) taxonomy

Since 2009, Xili-language followed two years later by Polylang are two plugins that use a taxonomy named “language”. This is possible since WP 2.3 – see file taxonomy.php
The main advantage of this approach taxonomy is that it does not destroy records (post) originals. (Indeed, other extensions modify the fields ‘post_content’ and add tables …)

Like those basic categories (category) and keywords / tags (post_tag), each element (term) of the taxonomy is described by its name, its shortcut (slug) and description. The other fields are the technical elements (term_id, taxonomy_id …)

Example of category “Recent News”
– Name : Recent News
– Slug : recent-news
– Description : the most recent news to be published

Inside xili-language and the taxinomy “language”, a language is defined as:
– Name : fr_FR (iso)
– Slug : fr_fr
– Description : French
with Polylang, the choice is different :
– Name : French
– Slug : fr (raccourci)
– Description : several serialized data in a table (array) whose name iso (locale => en_US) used by WP to name translation files.

The key point (pivot) is in both cases, iso code that describes the language and country of its use: fr_CA is used in Canada if we are to be precise.

Using serialized data in the description field is a Polylang originality that is not found in WP. Such fields do not allow SQL query. (need php functions)

As shown locale.php JetPack file (used by Xili-language), language management is very complex and use multiple encodings. You can find other invariant elements like the name cited in the language (French) and the writing direction (ltr). In fact, there is very little quantity of rtl languages.

With a few hundred lines, Xili-language (2.21+) can recover multilingual elements of a previous WP installation driven by Polylang. (see instructions post)
Xili-dictionary is also compatible with Polylang active (through filters and an abstraction of the taxonomy model). For example to translate language files for a theme or plugin with creation of pot, po, mo files.

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
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.

WP 4.3 and xili-language 2.19.3+

The release of WordPress 4.3 Billie is shipped imminent (version RC2 today). Xili-language (version 2.19.3+), based from the outset on taxonomy “language” and language of file selection (.mo) continues to be consistent to manage a multilingual site.
This compatibility is confirmed after bbPress for extensions like famous WooCommerce : with some settings and a few small kit of filters, creating a multilingual shop is possible and the buyer will the shop, his cart and his checkout in the chosen language…
WordPress 4.3 introduced the ability to create and adjust menus in the customizer with controversial ergonomics based on javascript. For now, lack of filter (hook) effective and available, Xili-language does not take into account these features. So for menus with insertion points of other menus selector, keep using the “Appearance/Menus” page which is more readable.
The 2.19.3 release adds enhancements for managing less common languages such as those with three (arq) or six characters (haw_US) of ISO name.
The child theme twentyfifteen-Xili contains sample additional text field (copyright) adjustable in the customizer (theme_mod function).
To be continued with 2.20…

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…

WordPress multilingual monosite: dreamed specifications

There are eighteen months, early 2014, a comparative study thrust multilingual solutions was begun. In the context of a mono-site WordPress installation, is it possible to define a list of specifications that allows to make an appropriate choice?

The first constraint is that a site with a WordPress installed single-site engine. (on the approach multisite installation is not addressed here although it has its own benefits.)

While technical supporting and doing site analysis and extensions, on several occasions, including recently, we have drawn attention to the sometimes old or deemed extensions (free or commercial) that profoundly alter the data (consistency and robustness) and the basic architecture.
Of course these web sites work but what he has behind? How will the data support the type approaches Json Api etc … without mentioning of course compatibility with the most common extensions.

Let us remember also that a multilingual website is not necessarily a set of pages, each of which has its “clone” in the other languages of the site. The user experience will also depend on the target population (multilingual country like Canada, Belgium, …) or International site “global”.

The “multilingual” character must be included in the editorial strategy (content strategy) and capabilities of establishment, operation and maintenance.
At it, the commercial nature of an extension is not a guarantee of solidity. The ability to read sources can also shed light on the webmasters who, with supplied base, will add the necessary customizations and contribute to future versions.

Bulk: some key elements of the specifications

On this first list, are listed below all technical elements that will be the basis of a strong installation that will continue with the successive versions of WP.

  • taxonomy dedicated to the language of a post (article, page, custom post) with 0, one or more languages assigned to it,
  • opportunity to describe the language with the ISO code and via an alias,
  • use of get text functionality (.mo / .po) for structural text themes and forms,
  • in the core, a theme, an extension: separation of data on the visitor side and admin side / author (not yet total for the core WP – core)
  • use of the sites dedicated .mo files that do not change those delivered with the themes and extensions,
  • Compatibility with default, shorts and perma links,
  • query wp_query simple for sub-selecting items,
  • code understandable to potential adjustments
  • cross-post visible link (? serialization in the description of taxonomy or custom field?)
  • reversibility (find datas with basic functions wp) – easily usable taxonomy
  • language selector (switcher) versatile (widget, menu, template tag)
  • Keywords (tags) taxonomy – grouping (alias), custom taxonomies
  • export / import via XML
  • xmlrpc – json,
  • available personalization filters,
  • no new tables (or few),
  • dashboard with components available such METABOX (minimum js, the browser tab)
  • pictures option / setable flags (any format, any name) – definable theme of the creator and the user
  • inline documentation (help, pointing js)
  • cookies / domain: options to be studied,

Bulk: some unacceptable elements that incite address some extensions with huge precautions

  • Modifying fields (title, content, …) posts (article, page) – in total contradiction with the WordPress data model

  • Translation posts added to the new tables or as custom post types

  • No explicit description of the model – however often visible (guessable) in the file uninstall.php (if available)

to be continued…

[update] this translation is done to contribute to this article in WordPress Core…

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,

Soon WP 4.2 : Maintenance update of trilogy xili-language !

WordPress 4.2-beta2 is shipped since few days. The three plugins of the xili-language trilogy must be tested. Some improvements are added. More details in each repository (“Changelog” tab).

  • xili-language : version 2.16.4
    – custom_xili_flag for admin side (admin side flag are uploadable – no need to take attention to name or type (.png, .jpg, gif)
    – custom_xili_flag (frontend): if not ready or declared in customised theme, search in subfolder theme/images/flags (only .png)
    – better selection of active widgets (new Categories widget with good counting if language selection must be enabled in 5th tab)
  • xili-tidy-tags : version 1.10.2 (Updated datatables js & css)
  • xili-dictionary : version 2.10.3 (Updated datatables js css – used in interactive table of tools)
    – can import msgid of get_the_archive_title (introduced in WP 4.1)
    – improves adding context only after draft state
    – now able to use flags available in Medias Library (if xili-language is active)

Notes: images set as flag can be png et jpg and also gif – not necessary to also format the name of the file !

As usual, contributors are welcome to improve documentations and more…

La trilogie xili-language mise à jour pour WordPress 4.1 “Dinah”

La sortie de WordPress 4.1 “Dinah” a été l’occasion depuis quelques semaines de revoir l’ensemble des extensions liées à la création d’un site multilingue avec xili-language (v.2.16.0), xili-tidy-tags (v1.10.0) et xili-dictionary (2.10.0) et de créer (comme exemple) le thème enfant multilingue TwentyFiften-xili et son site de démonstration.

Les modifications les plus importantes sont pour :

  • xili-language
    la prise en compte des fichiers .mo qui sont déposés dans le dossier wp-content/languages/themes s’il n’y a pas de fichiers .mo dans le dossier du thème lui-même.
  • xili-tidy-tags
    la correction d’une modification des assignations de langue quand on créait des groupes (alias) de mots-clés de même sens dans des langues différentes.
  • xili-dictionary
    Faciliter la récupération des termes liés aux commentaires (inclus dans le fichier wp-includes/comment-template.php) et rendre plus aisée donc leur traduction. En effet, WordPress, qui est de base traduisible mais pas multilingue, lie ces textes liés au formulaire de commentaires à la langue du tableau de bord uniquement et non au thème (qui a son propre textdomain).

Les améliorations du noyau (core) de WordPress ont été prises en compte (requête complexe). La réalisation du thème enfant TwentyFifteen-xili donne l’occasion de présenter un exemple avec différents astuces.


xili-language v. 2.15: une option pour gérer les drapeaux du sélecteur de langue !

xili-language version 2.15 introduit des nouvelles options pour webmestres et développeurs de thèmes.

Même si l’usage de drapeaux pour sélectionner une langue a ses limites (*), xili-language v. 2.15 ajoute une option qui facilite l’ajout des drapeaux car jusqu’à maintenant, il fallait utiliser la CSS pour substituer l’image choisie au nom de la langue.

(*) une même langue est souvent pratiquée dans plusieurs pays!

Quelques exemples sont livrés dans les thèmes enfant des 5 thèmes de base livrés avec WP (comme twenty fourteen xili qui est ici même en démo). Pour cette option introduite dans la v2.15, une nouvelle version de ces thèmes enfant est mise en ligne.

Grâce aux outils disponibles dans le noyau WordPress et leur intégration dans xili-language, on dispose maintenant :

  • une façon facile d’ajouter une image (drapeau) pour une langue,
  • une façon facile d’assigner une image (drapeau) à une langue,
  • un nouvel interface dans le menu Apparence pour ajuster les paramètres,
  • et un processus automatique pour générer les lignes CSS dans le header de la page HTML.

Les développeurs vont trouver:

  • un nouveau add_theme_support() dénommé ‘custom_xili_flag’,
  • des nouveaux filtres pour personnaliser leurs thèmes,
  • un nouveau shortcode pour pointer le drapeau d’une langue donnée (SRC).

Quelques copies d’écran : Extrait de la liste des médias – une image est affectée comme flag (drapeau) (la seconde comme header image)

flag example
exemple de drapeau (flag)

L’extrait ci-dessous montre l’option principale (drapeau ou nom), une liste des drapeaux téléchargés et disponibles dans la bibliothèque média et quelques lignes très techniques pour affiner les réglages de la CSS. Pour les 5 thèmes de base (comme 2014), des valeurs par défaut sont proposées:

xili-language flag settings
Réglages des drapeaux (flag) xili-language


  • le choix des images drapeaux est libre (et modifiable), pas nécessaire de prédefinir un nom ou un type de fichier identique (jpg, png, …)
  • L’extension choisit la bonne image qui a été téléchargée et assignée à la langue cible.
  • En utilisant les filtres ad’hoc, les développeurs peuvent régler les lignes de style par défaut. Voir le thème responsible-xili comme exemple.


  • encore plus de lignes de code dans les sources de l’extension !

xili-language V. 2.15: Der einfachste Weg Fahnen zur Sprachwahl zu verwalten!

In dieser Woche wird xili-language in der Version 2.15 ausgeliefert und erhält wichtige Neuerungen für Webmaster und Theme Entwickler.

Obwohl Fahnen einige Beschränkungen für die Sprachwahl mit sich bringen (*) erhält xili-language nun die Möglichkeit, Fahnen für die Sprachwahl auswählen zu können, bislang war es hierfür notwendig in CSS den Namen für eine Sprache durch eine Fahne ersetzen zu lassen.

(*) gleiche Sprachen werden oft in mehreren Ländern gesprochen!

Einige Beispiele für die Umsetzung mit Fahnen zur Sprachwahl wurden bereits in den fünf mitgelieferten mehrsprachigen Child Themes wie zum Beispiel dem twenty fourteen xili das hier live im Einsatz ist gezeigt. Die neueren Versionen der Child Themes werden nun direkt mit den neuen Funktionen der xili-language Version 2.15 zur Veranschaulichung ausgeliefert.

Mit den Mitteln der Grundfunktionen in WordPress und dem xili-language Plugin ist es nunmehr möglich:

  • eine vorhandene Fahne aus der Medienbibliothek auswählen zu können
  • diese Fahne einer Sprache zu zu ordnen
  • in einem neuen Dialog, der sich im Design Menü befindet, einige Anzeige-Parameter zu verwalten
  • sowie ein automatischer Prozess um Style Zeilen im Header zu setzen.

Entwickler erhalten zudem:

  • eine neue Funktion add_theme_support() mit dem Parameter ‘custom_xili_flag’
  • neue Filter um ihre Benutzerdefinierten Themes zu setzen
  • neue Shortcodes um Fahnen nutzen zu können die in der Medienbibliothek vorhanden sind und vorher durch den Webmaster hochgeladen wurden

Einige Bildschirmfotos:

Unten ein Ausschnitt aus der Medienliste, ein Bild wurde als Fahne zugeordnet  (das zweite als Kopfbild)

flag example
flag example

Das untere Bildschirmfotos zeigt die Hauptfunktion (ob eine Fahne oder der Name angezeigt werden soll), die Liste der verfügbaren Fahnen in der Medienbibliothek sowie einige sehr technische Zeilen für versierte und fortgeschrittene Benutzer. Für die fünf Beispiel Child Themes gelten diese Parameter als Stilvorlagen:

xili-language flag settings
xili-language flag settings


  • die Wahl der Fahne ist frei und nicht landesspezifisch abhängig, das Plugin wählt das richtige Format des zugewiesenen Bildes aus der Medien Bibliothek
  • Theme Entwickler können durch die Verwendung der Filter Standardoptionen und Einstellungen vorgeben


  • noch mehr Code-Zeilen