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

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…