Archives par mot-clé : .mo file

Xili-language 2.14 : des règles enrichies pour les traductions des extensions

Pour répondre aux multiples situations provoquées par les extensions et l’affichage traduit des éléments du côté visiteur dans un site multilingue, xili-language 2.14+ propose dorénavant 3 approches :

  • l’utilisation des traductions disponibles dans le fichier local-xx_YY.mo du thème courant,

  • l’utilisation des traductions disponibles dans le fichier plugintextdomain-xx_YY.mo du thème courant, (woocommerce-fr_FR.mo par exemple),

  • l’utilisation des traductions qui vont être gérées par un filtre personnalisé (bbPress par exemple) comme dans l’extension add-on.

Pourquoi ces trois approches ?
1) parce que souvent les fichiers de traduction des extensions sont mis en place très tôt et avec comme langue celle du webmestre et du tableau de bord. Mais dans un site multilingue, il faut que la langue change au gré des visiteurs et de la navigation.
2) parce que il y a des extensions avec très peu de termes à traduire côté visiteur.

Que faut-il choisir et pourquoi ?
(n’oubliez pas que le pré-requis essentiel est que l’extension soit traduisible)

a) solution local-xx_YY.mo : quand il n’y que quelques termes, donc WP ne charge pas tout le fichier proposé par l’extension avec ses éléments utilisés dans l’admin.
b) solution plugintextdomain-xx_YY.mo : recommandée pour une grosse extension complexe comme woocommerce. Ainsi par exemple le bon de commande ou le panier contient bien les nombreux libellés dans la langue de la page contenante.
c) solution par filtre personnalisé (réservé pour les experts programmeurs : c’est celle qui est utilisée par le add-on bbPress spécial pour xili-language.

NB: attention certains termes ne sont pas codés en dur et dépendent de ce que va saisir le webmestre. Mais l’affichage n’est pas filtré (hook), donc impossible de traduire à la volée avec une fonction gettext comme __('text', 'textdomain');. Seule solution corriger les sources !

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