What new in xili-language 2.13.2 and xili-dictionary 2.7.2 ?

Step by step, updating continues…
Increment of third digit indicates minor fixes, improvements in sources and texts.

XILI-LANGUAGE translation box
XILI-LANGUAGE translation box

Side xili-language (2.13.2) :
– fixes settings for new CPT, (warning in debug mode) if CPT multilingual mode was set in 2.12, refresh the settings
– better selector (msgid for XD), XD again in bar admin,
– widget language file merged in main file of plugin.

dictionary msg list
dictionary msg list

Side xili-dictionary (2.7.2) :
– disable media button,
– subtitle of msg,
– formatted title (based on id with 7 digits)

xili-language v 2.13: new rules, new features and improvements…

This week, xili-language plugin (and xili-dictionary) were improved and shipped…

  • tested and improved with WP 3.9.1
  • 2nd tab in settings UI reorganized to adjust front side (visitor side).
  • 5th tab to set dashboard side (authoring and various technical settings).
  • includes authoring propagate options previously available only in theme’s class (see new 5th tab in settings UI).
  • WARNING : users of child theme examples (bundled series like twentyten to twentyfourteen-xili) must update and use latest releases now available in github – backup before langs subfolder to keep previous translations –
  • widgets adapted for theme customize appearance screen (WP 3.9+).
  • improved choice in parent/child .mo files priority,
  • try to search local-xx_YY in wp-content/languages/themes (WP_LANG_DIR)
  • improved All content xml export for all authorized CPTs.
  • fixes – returns from developers and webmasters are welcome.
  • code cleanup.

More about .mo

xili-language multilingual plugin, since his creation five year ago, is based on two main things:

  1. the language of post (and custom post) is defined by the custom taxonomy “language”.
  2. the ‘live’ translation of terms is mainly based on .mo file of current theme (like translation in a localized website) of the current language. The plugin choose the right language according the current language assigned to the single displayed post, the home page or a list of posts.

Case of a standalone theme (w/o parent)

With a current theme with textdomain twentyfourteen (without child), for a french context, the file fr_FR.mo is loaded. (and if created by xili-dictionary or by hand with poEdit, the local-fr_FR.mo).
If the files are not found in a sub-folder of the theme, if, available in subfolder wp-content/languages/themes, the files twentyfourteen-fr_FR.mo and twentyfourteen-local-fr_FR.mo are loaded.
Be aware about that:
if a term or sentence (msgid) and his translation (msgstr) are in the fr_FR.mo and in the local-fr_FR.mo, the translation of local-fr_FR.mo has priority. It is a good thing if you are not satisfied by the translation delivered by the theme’s author!
local-xx_YY.mo currently contains translations of terms et sentences from the website itself (title, date format, categories,…).

Case of child and parent themes:

By default, only the .mo files availables in child theme are loaded.
To help translation strategy and versioning, it is now possible to use also files from parent theme languages folder. xili-language is able the define how will be done the merging between child and parent files.
As in above case, a local file is loaded from the current (here child) theme and has full priority.
For the other files (child and parent), you can define the priority, child or parent… By example, if you don’t want to modify the parent .mo files, so define child files as a priority.

The form is inside the screen under the 4th tab of xili-language settings.

merging .mo files option
merging .mo files option

xili-language: a new shortcode revealed !

The latest version of xili-language provides a new shortcode named xili18n.

The short code is usable at the content of a page or post.

The purpose of the short code xili18n is to bring translatable terms inside of a text body. The translation for each language ist stored in the languages .mo file.

What is the goal?

Content can be very rich and complex nowadays (for example a table or form) same counts for specific terms. The idea is creating a clone-able version of a table or form for each language by inserting the shortcode for example at the table header of each column. So you simply need to copy the content into the different languages without translating these again and again.

Here is how the short code is used:

<strong>[xili18n msgid="Edit"]</strong>

The result in English is of course  Edit !

But go to the French or German post to see the result in a foreign language.  😉

Question 1: is is possible to define a context ? Yes with param ctxt !

Question 2: is is possible to choose the text domain ? Yes with param textdomain !

Question 3: Limitations in msgid or msgstr ? Yes only html tags like <strong>, <em> and <br> are possible. See the source code of the xili-language plugin for more details.

Tip of the day: import translators comment from php to poEdit

Context

By default poEdit (here version 1.6.4 for Mac OSX 1O.9) forget to import translators comment in po file.
like here

/* translators: added in child functions by xili */
$to_post_column = sprintf (__('The content in %1$s below must be translated in %2$s !', 'twentyfourteen'), $from_lang, $to_lang ) ;

to obtain this result in .po file:

#. translators: added in child functions by xili
#: ../functions.php:408
#, php-format
msgid "The content in %1$s below must be translated in %2$s !"
msgstr "Le contenu %1$s ci-dessous doit être traduit en %2$s !"

After some researches, it seems that a command must be added to the php parser “–add-comments=translators”. No need to modify via terminal the config… just go to preferences of poEdit and the line in php parser config tab:

poedit parsers preferences
poedit parsers preferences
poedit php parser
complete command with –add-comment=…

As in WP codex ‘translators’ is low case !

Enjoy !

M.

How to: A multilingual navigation menu

Preamble

Navigation Menu is a theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for introducing customized navigation menus into a theme.
The dashboard interface has made great progress for users (and newbies) from version to version.
Inside a theme, a navigation menu appears at a location, currently near the header. A menu has a structure made with menu items to redirect to webpage containing (as WordPress describes them) a static page, a list of posts in a category, of a target date, or resulting of a query…
In dashboard side, we find in “appearance/menu” page, the location settings and how to set the menu with his structure.
Note: A menu structure can be attached to a widget.

In multilingual context on a standalone WordPress install,
for developers, it is possible to create a virtual location for each language (as presented in child theme Twentyfourteen-xili or other previous embedded (bundled) themes of WP install).

A menu location contains
   one menu structure with
      various menus items.

But there are (huge) thousand of themes (free or commercial) following or not following the codex rules of development.

Since 5 years, on the long way to work in the thousands of lines of WP source, it was recently possible to use powerful pieces of code to create menu item like insertion points replaced by navigation list elements.

A multilingual navigation menu with xili-language with menus insertion point.

In the content strategy of the example, we decide that the contents of menu are not similar in each language.
First step: a menu (structure) per language
These structures should not be attached to a location to remain free to be used by menus insertion point.
Second step: a core menu attached to the menu location of the theme.
Third step: a menus insertion point and a language list insertion point inside the core menu.

Limitation: a menu structure associated to an insertion point must not contains another insertion points.

Some screenshots:

English menu w/o location
English menu w/o location
Menus Insertion item
Menus Insertion item before adding to structure
Core menu after insertion
Core menu after insertion

Plugin JetPack: what about with class Featured_Content from theme TwentyFourteen ?

Plugin JetPack has a strange behavior with class Featured_content of TwentyFourteen theme and child theme like here TwentyFourteen-xili!

Feedback after investigations

In TwentyFourteen, in sub-folder inc file featured-content.php contains class Featured_Content. It is possible to copy (and modify) inside child theme (as done in TwentyFourteen-xili to include sub-selection and cache according current language). As here in frontpage, only featured posts in a language are displayed. Because functions from functions.php are fired before those of parent theme: no problem, modified class has priority!

All is working well until JetPack will be installed… no sub-selection 🙁
By tracing, the modified class is not used
In JetPack settings, no way to disable (not load) Featured_Content Class, only a class with same name loaded before is possible !
How to force to download the child theme Featured_Content Class ?

In sources below (theme-tools.php – extrait ci-dessous) : no filter, only test with class_exists

// Featured Content has an internal check for theme support in the constructor.
// This could already be defined by Twenty Fourteen if it's loaded first.
// Be sure to not load this on the plugin page in case another plugin is activating
// with the same class name in an attempt to override Jetpack's Featured_Content
if ( ! class_exists( 'Featured_Content' ) && 'plugins.php' !== $GLOBALS['pagenow'] ) { 
    require_once( JETPACK__PLUGIN_DIR . 'modules/theme-tools/featured-content.php' );
}

Only possible solution, creating a plugin with a filter before the time where JetPack load the modules (plugins_loaded – priority 100).

Remember it is impossible to add filters “plugins_loaded” inside functions.php of a theme. It is too late according timeline of wp_settings.

The code below show that featured-content.php file will be required before JetPack requires its modules:

function xili_jetpack_disable_featured () {

    if ( ! class_exists( 'Featured_Content' ) && 'plugins.php' !== $GLOBALS['pagenow'] ) {
        if ( file_exists( get_stylesheet_directory() . '/inc/featured-content.php' ) ) {
            require get_stylesheet_directory() . '/inc/featured-content.php'; // this one will disable others
        }
    }
}

if ( class_exists ( 'jetpack' ) ) { // inited by init filter but without modules (priority 100 in jetpack)
    
    add_action( 'plugins_loaded', 'xili_jetpack_disable_featured', 17 ); // after XL and XTT

}

This example code lines are easy to insert in a very simple plugin.
For multilingual context, these lines (with options) are now inside xili-language (v 2.11.1+). Here, you will see in real time that TwentyFourteen-xili multilingual recovers his behavior and sub-select featured posts in frontpage.

M.

xili-language version 2.11 shipped

Latest release (2.11) of xili-language shipped today.

Some new things for theme’s developers:

A conditional function – is_xili_curlang():
/**
* Test the current language of displayed page.
*
* @since 2.11
* use for other function elsewhere
* @param "" for undefined, slug of tested language alone or an array list
* @return true or false
*/
function is_xili_curlang( $lang = false ) {

This function is also usable in plugin xili-postinpost widget.

The oldest function of xili-language – the_curlang() – is improved and now is able to return the desired property of current language. Useful for choosing condition of part display according language.
/**
* Return the current language of theme.
*
* @since 0.9.7
* @updated 2.11.0
* use by other function elsewhere
* @param slug, iso, full name, alias, charset, hidden, count
*
* @return by default the slug of language (used in query).
*/
function the_curlang( $by = 'slug' ) { // soon obsolete
return xili_curlang( $by );
}
function xili_curlang( $by = 'slug' ) {

More available preset languages in list:

Now using list provided by jetpack, an almost complete list of languages is available with english name, native name and more…
In the list, if the native name is followed by a *, the language is not associated with wp_locale (an official language managed by WP.)

xili-dictionary version 2.6 shipped

xili-dictionary extension is shipped (2.6) and include now plugin language file management.
With taxonomy “Origin”, msgid and msgstr are assigned to the target plugin and it is easy to import terms in dictionary and to create, update language files of the target plugin.

xili-dictionary analyse header of plugin’s sources and this two items ‘Text Domain’ and ‘Domain Path’. If author omits to define them, xili-dictionary try to specify them according language files yet available in plugin’s folder.

M.