All posts by Michel

Latest news

After a couple of months, the research and development around the xili-language trilogy is gradually resuming. The offer of plugins to create multilingual WordPress sites is plethoric but only two use the taxonomic approach. On this site based on 2014-xili, multilingual child theme of Twenty Fourteen, remain the main documents concerning the trilogy. Following the WordCamp Europe Paris in June 2017, Twenty Seventeen’s site based on 2017-xili , will contain the Latest news and updates.

xili-language version 2.21.0 shipped

The plugin Xili-language (heart of his trilogy) continues its development …

Widget “language list” or “language selector”

After the period devoted to the management of menus and their style with image (flag), this is the appropriate time to review widget “language list” or language selector (switcher).
Adding pictures is based on an integrated style sheet in the header if and only if this widget is active. (thanks to the is_widget_active function). As with nav menus, the theme must support (add_theme_support) the “custom_xili_flag” introduced since Xili-language version 2.15.

Widget inside twenty sixteen
Widget inside twenty sixteen

Three possible styles: single text (as before), image + text and image / flag alone (in compact horizontal list).
Images/pictures can have three origins:
– Those provided by the developer of the theme (so in a theme subfolder and reported at the theme setup)
– Those introduced as nav menu image in the catalog media associated with a language,
– And in case of absence, for some images contained in the plugin.

Settings of style in widget Language list
Settings of style in widget Language list

Importing multilingual datas of a website previously controlled by Polylang plugin

A few years after the birth of Xili-language, Polylang also chosen the way of taxonomy “language” to organize posts according to their language. The slightly different implementation of this taxonomy is discussed here. This approach retains the posts (article, page) to their initial state. In a decidedly simple approach with an effective ergonomics, its success demonstrates that it meets expectations in a very competitive multilingual context. But as for music, cars, the webmaster / developer may want different or complementary qualities, that is why, apart from other reasons, the trilogy Xili-language continuing its development. If, during the life of a website, the need appears, Xili-language 2.1+ version is able to detect the presence of previous Polylang and recover data to continue the multilingual architecture with the trilogy (Xili-tidy- tags, xili-dictionary). Caution, in the list of extensions, just disable Polylang without removing it because otherwise, for lack of option provided for this purpose by the author, all specific data Polylang will be deleted. Once, Xili-language active, a semi-automatic multi-step process is fired … a specially dedicated post is published…

Widgets visibility option under the current language

widget visibility
widget visibility

If the option is activated (5th tab), the webmaster will see in the interface of each widget, a group of 2 dropdown menus to decide whether this widget should appear or not.

various fixes

Each version is an opportunity to fixe and optimize the code in particular by integrating functions appeared since WP 4.1. or recent versions of javascript.

improved code and algorithms

Add filters to customize the implementation style images / flags in the language selector.
Added new theme twenty sixteen in the list of bundled themes that came with WordPress.
Intermediate versions before publication on the WP repository are available on GitHub

Importing multilingual datas of a website previously controlled by Polylang plugin


VERY IMPORTANT: change of plugins must be preceded by IMPERATIVELY a backup of the database.

Performing backups has been very helpful in the phases of development of this new feature to Xili-language 2.21+ and allowed at any time to return to an earlier phase.

Although Xili-language taxonomy and that of Polylang have the same name, there are differences explained in this article.

This post concerns webmasters with a good level of knowledge of WordPress … and those who know the “CMS” reasons behind to move from Polylang to Xili-language (2.21+).


Installation WITHOUT ACTIVATION  to the 3 xili-language plugins, Xili-tidy-tags and Xili-dictionary. Either via FTP or through the list of plugins.

Open multiple tabs in your browser: two on the list of extensions, one on the visitor site side and one on the dashboard.

Desactivate Polylang

Caution, in the list of extensions, you must  only desactivate Polylang without deleting it because otherwise, for lack of option provided for this purpose by the author, all specific data Polylang will be deleted.

desactivate Polylang
desactivate Polylang
Activate xili-language
Activate xili-language

Once, Xili-language activated, a semi-automatic multi-step process is set up and opens the welcome page:

Welcome screen after activation
Welcome screen after activation

Once in the page settings, it is seen that the elements left behind by Polylang are detected and processed for multilingual management now by xili-language:

before regeneration
before regeneration

Regeneration multilingual elements

The regeneration of links between posts made, the message says to go to the Settings for Experts tab.

regeneration done
regeneration done

Because the next step is taxonomies, go to the previously prepared browser tab where there is the list of extensions and enable Xili-tidy-tags:

Activate xili-tidy-tags
Activate xili-tidy-tags

Going back to the settings page Expert Xili-language and the window (meta-box) “special actions and parameters”:

Start taxonomy groups recovering
Start taxonomy groups recovering

Operations related to taxonomies relate Tags (post_tag) primarily:

Tags list and languages
Tags list and languages

now screen xili-tidy-tags assign

xili-tidy-tags assigning done
xili-tidy-tags assigning done

They prepare the items for categories that are managed in translation mode (without cloning) by xili-language and Xili-dictionary. (see Article …)

To clean the WP base before removing the Polylang extension, you have to go to the next step (this can be done later):

To launch DB cleaning process
To launch DB cleaning process
Ready to delete plugin files
Ready to delete plugin files



It goes without saying that now Polylang should not be reactivated. To go back: use the backups.

The Polylang files are deletable via the page showing list of extensions or better via FTP. Xili-language, however, has made so renaming the file
 uninstall.php to uninstall_XL_desactived.php
so it does not destroy particular taxonomy “language” in the process “deleting” managed by  WP.


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.

What’s new in Xili-language version 2.20?

First: Xili-language compatibility is verified with WordPress 4.3 “Billie”.
Well known by donors, contributors, the functions related to the themes present in permalinks 201x-Xili child bundled themes are now included in the plugin itself.
It is therefore possible for all situations respecting the rules kernel (core) of WP to have permalinks integration with current language at the beginning of the URI instead ?lang = fr_fr at end of URI for example.
Note also that the language slug can be a shortcut to its ISO code but also an alias at your convenience associated with the activity of the website or its geography.
Possible to do tests with newest theme twenty sixteen (and his multilingual child theme).
Other fixes and code improvements continued to grow especially for parties of sometimes more than 5 years old. 😉
Note: for now, given the sophistication of settings, lack of filter, the approach php / javascript, the customizer is not active to create special navigation menus with insertion points (use page Appearance/Menus).
Thanks for your returns

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…

xili-language updated in version 2.19

xili-language is updated in version 2.19 to improve features and to be ready with WP 4.3-beta

  • Admin Side
    add link in post edit to view other posts during translation,
    pre-tests with WP 4.3-beta1: fixes for (new) WP Theme Customizer Menus

  • Authoring
    add shortcode as [linked-post-in lang="fr_fr"]Voir cet article

  • Theme’s developers
    ready to translate theme_mob values (like in config.xml) see multilingual child theme twentyfifteen-xili example in github

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…

xili-language updated in version 2.18

xili-language version includes fixes and integration of optional plugin xl-bbp-addon (used with multilingual bbPress)

  • integration of xl-bbp-addon (no more a plugin),
  • fixes/adds ‘menu-item-has-children’ class in menus built by selector (as used in twentyfourteen / twentyfifteen theme css for sub-menu on left sidebar to show small arrow),
  • fixes propagation options,
  • better management of dashboard language and user profil (thanks to Renoir),
  • selected value of languages in general settings set to get_option(‘WPLANG’) (and not filtered locale).