Archives de catégorie : Mode d'emploi

Comment mettre en place et faire les réglages d'un thème enfant multilingue.

Mode d'emploi

Importation des données multilingues d’une installation pilotée auparavant par Polylang

Laisser un commentaire

Préambule

TRES IMPORTANT : le changement d’extensions doit être précédé IMPERATIVEMENT par une sauvegarde de la base de données.

La réalisation de sauvegardes a été très utile dans les phases de développements de cette nouvelle fonctionnalité pour xili-language 2.21+ et permettait à tout moment de revenir à une phase antérieure.

Même si la taxonomie de xili-language et polylang ont le même nom, il y des différences expliqués dans cet article.

Ceci concerne des webmestres avec un bon niveau de connaissance de WordPress… et des raisons “CMS” qui les motivent à passer de Polylang à xili-language (2.21+).

Préparation

Installation SANS ACTIVATION des 3 extensions xili-language, xili-tidy-tags et xili-dictionary. Soit via FTP soit via la liste des extensions.

Ouvrir plusieurs onglets dans votre navigateur : deux sur la liste des extensions, un sur le site côté visiteur et un sur le tableau de bord

Désactivation de Polylang

Attention, il faut dans la liste des extensions, simplement  désactiver Polylang sans le supprimer car sinon, faute d’option prévue à cet effet par son auteur, toutes les données spécifiques à Polylang seront supprimées.

Désactivation Polylang
Désactivation Polylang
Activation xili-language
Activation xili-language

Une fois, xili-language activée, un processus semi-automatique en plusieurs étapes se met en place et ouvre la page d’accueil

Accueil de l'activation xili-language
Accueil de l’activation xili-language

Une fois sur les pages de paramétrages, on voit que les éléments laissés par Polylang sont détectés et transformés pour la gestion multilingue par xili-language :

Lancer la récréation des liens entre posts
Lancer la récréation des liens entre posts

Régénération des éléments multilingues

La régénération des liens entre posts effectuées, le message indique d’aller dans l’onglet Réglages Expert.

fin de la régénération
fin de la régénération

Comme l’étape suivante concerne les taxinomies, aller dans l’onglet du navigateur préparé au préalable où il y a la liste des extensions et activer xili-tidy-tags :

Activation xili-tidy-tags
Activation xili-tidy-tags

Revenons à la page de réglages Expert de xili-language et à la fenêtre (meta-box) “actions et paramètres spéciaux”:

Lancement des importations de taxinomies
Lancement des importations de taxinomies

Les opérations liées aux taxinomies concernent les étiquettes (post_tag) avant tout:

Les étiquettes et leur groupement
Les étiquettes et leur groupement

avec l’écran dans le groupage xili-tidy-tags

groupage xili-tidy-tags réalisé
groupage xili-tidy-tags réalisé

Elles préparent les éléments pour les catégories qui sont gérées en mode traduction (sans clonage) par xili-language avec xili-dictionary. (voir l’article…)

Pour nettoyer la base WP avant de supprimer l’extension Polylang, il faut passer à l’étape suivante (ceci peut-être fait plus tard) :

Lancer le nettoyage
Lancer le nettoyage
La base est nettoyée des éléments spécifiques de Polylang
La base est nettoyée des éléments spécifiques de Polylang

ATTENTION :

Il va de soit que désormais, Polylang ne doit pas être réactivée. Pour revenir en arrière : utiliser les backups.

Les fichiers Polylang sont supprimables via la page de liste des extensions ou mieux via FTP. xili-language a fait en sorte toutefois de renommer le fichier uninstall.php en uninstall_XL_desactived.php afin qu’il ne détruise pas notamment la taxonomie “language” lors du processus suppression géré par WP.

 

Mode d'emploi

Les taxinomies et les extensions multilingues

Laisser un commentaire

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

Mode d'emploi

xili-language et WooCommerce – une boutique multilingue

Laisser un commentaire

Qu’est-ce qu’une boutique multilingue ?

  • voir la liste des produits, son panier, sa page de commande dans sa langue,
  • avoir des fiches produits lisibles dans chacune des langues du site.

WooCommerce est-elle une extension compatible multilingue ?

Oui, pour plusieurs raisons :
– le moteur WooCommerce repose sur les éléments clés du noyau (core) de WordPress (custom post type, canevas des thèmes (template)),…
Les produits (stocké en “custom post type”) pourront donc être affectés par la taxinomie ‘language’.
– comme BuddyPress, bbPress, l’objet “boutique” est étanche et permet un dialogue avec WP, les extensions via de nombreux filtres même pendant les process Ajax/JSON. Il s’insère par défaut dans des pages WP pré-définies.
– dans le contexte multilingue, il s’agit de passer la langue courante d’affichage dans les requêtes de WooCommerce. Via une petite dizaine de filtres, ce message ‘langue’ est passée.

Tout le travail d’adaptation consiste donc à identifier ces filtres dans WooCommerce pour que cette dernière puisse sélectionner le bon fichier langue à la volée pour l’affichage dans son container.

Réglages dans xili-language

  • ajout du CPT Product pour être classable dans la taxonomie ‘language’ de XL
  • réglages de gestion du domaine texte WooCommerce en mode filtre.
  • ajout dans functions.php du thème de l’appel aux functions de filtrage de WooCommerce.

La ligne des temps du moteur WooCommerce dans WordPress + Xili-language

  • les 2 filtres clé pour WooCommerce : “before_woocommerce_init” et “plugin_locale“
  • les filtres des liens et boutons : 'woocommerce_get_' . $pagename . '_page_id'

A suivre…

Mode d'emploi

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,

Mode d'emploi

WP-Settings en action : attention à ne pas filtrer n’importe comment !

Version 2014–12–08

Une première relecture en prévision du MeetUp du 9 décembre à Lyon.

Pour suivre, il suffit d’avoir un éditeur de texte et lire les fichiers du kit WordPress (ici version 4.1)

Contexte

Le fichier wp-settings.php est lancé à la fin de wp-config.php

wp-config.php est lancé par wp-load.php qui lui même arrive après la succession index.php, wp-blog-header.php et avant template-loader.php qui contient l’importante action do_action( ‘template_redirect’ ); en ligne #12

Lecture ligne par ligne, les étapes clés

Imprimé, le fichier wp-settings.php tient sur six pages ou 375 lignes (WordPress Version 4.1). Dans les deux premières pages (#156), il déclare les constantes et met en place les fichiers (et classes) indispensables notamment ceux qui sont dans le dossier “wp-includes”. Ensuite, si l’installation est multisite, sont mis en place les extensions obligatoires (mu) puis les fichiers des extensions (sans qu’elles à ce stade activée – si elles sont bien écrites #212)

Les “do_action” majeurs

ligne #237 : premier “do_action” nommé “plugins_loaded”

Puis déclaration des GLOBALS dont la fameuse $wp_query

deuxième “do_action” nommé “setup_theme”

puis mise en place de l’internationalisation

Mise en place des fichiers fonctions.php (theme enfant avant theme parent) du thème courant.

troisième “do_action” nommé “after_theme_setup”

L’utilisateur courant est déclaré (donc connu). Souvent on en profite pour activer et enregistrer des fonctionnalités du thème actif.

quatrième “do_action” nommé “init”

C’est le fourre-tout mais qui mérite mieux si l’on veut mieux séquencer les activations

cinquième et dernier “do_action” nommé “wp_loaded” à la fin où tout est en place et où les ajax peuvent être lancés. (#374)

avant la requête (loop)

Le lancement de la requête se situe dans le fichier wp-blog-header et juste avant le template-loader (bien sûr si on veut afficher le thème). La fonction wp() est en fait la fonction main de la classe WP qui contient le do_action_ref_array( ‘wp’, array( &$this ) );

après la requête (juste avant la boucle / loop )

Sous réserve que l’on veuille afficher le thème, le do_action( ‘template_redirect’ ); en ligne #12 est la première action une fois la query effectué (en dehors des actions et filtres de la classe WP_Query elle-même).

Les éléments clés pour les développeurs d’extensions

De cette lecture rapide de wp_settings, on retire qu’il faut choisir dans une extension les bons filtres et au bon moment. Dans des versions précédentes de JetPack, certaines actions étaient faites trop tôt et interdisaient toute filtrage possible par une extension.

versant utilisateur – visiteur (frontend)

La réalisation de l’extension xili-language pour afficher un site multilingue avec une traduction correcte des termes du cadre du thème permet de préparer le chargement des bons fichiers .mo une fois bien connu ce qui doit être affiché (un single, une liste,…) et la langue qui doit être utilisée en concordance avec les contenus (c’est le filtre ‘wp’ dans la classe WP. Cette connaissance du bon filtre (action) au bon moment se substitue aux tâtonnements du début où on utilisait un filtre comme dans une autre extension sans avoir analysé sa position.

versant administrateur auteur (backend)

Quand on se connecte sur la partie admin, le trajet est un peu différent, il indique qu’on est côté admin (WP_ADMIN à true) mais passe toujours par wp-config.php donc par wp-settings.php etc…

La première action importante sera do_action( ‘admin_init’ ); en ligne #127 du fichier /wp-admin/admin.php. C’est là que par exemple on va définir à la volée la langue courante de l’administrateur qui veut en changer sans changer celle de base qu’il a défini dans son profil.

En guise de conclusion transitoire

“le source, le source, le source” comme me disait Amaury rencontré au 2e BarCamp à Paris est en effet, le plus important à explorer avant et pendant le développement d’une extension ou d’un thème. L’utilisation de la fonction “error_log” avec des drapeaux permet aussi de valider les découvertes et d’afficher l’existence ou des valeurs visibles sur la console au fil du démarrage de WP jusqu’à son affichage.

Mode d'emploi, Actus

xili-language v. 2.15.1: La possibilité pour le développeur de déclarer ses drapeaux

Laisser un commentaire

xili-language v. 2.15.0 a introduit la fonction add_theme_support ( 'custom_xili_flag') pour ouvrir l’utilisation de drapeaux présents dans la bibliothèque Médias.
En ajoutant le paramètre array ($args), xili-language v. 2.15.1 ajoute un moyen de déclarer des drapeaux présents par défaut dans le dossier du thème. Une façon élégante de proposer des images/drapeaux adaptés au design et au graphisme du thème. Dès lors plus besoin de mettre ces éléments dans la bibliothèque Médias sauf si le webmestre veut introduire les siennes.

Exemple de code à mettre dans une function appelée par un add_action ‘after_setup_theme‘ (priority set to 12)

$listlanguages = array(
'ar_ar','ar_ma', 'ar_xx', 'cn_cn',
'de_de', 'en_us', 'es_es', 'fr_be', 'fr_ca', 'fr_fr',
'it_it', 'ja_ja', 'ja', 'km_kh', 'pt_pt', 'ru_ru', 'zh_cn') ;

$args = array();
foreach ( $listlanguages as $one_language ) {
$args[$one_language] = array(
'path' => '%2$s/images/flags/'.$one_language.'.png',
'height' => 16,
'width' => 11
);
}
add_theme_support ( 'custom_xili_flag', $args );

%2$s est utilisé dans ‘path’ parce que les png sont dans le theme enfant pour cette exemple. Ici, faute de test, on suppose que tous les png sont présents. (%1$s pointe sur le thème parent)

Pour présenter divers exemples, twenty fourteen-xili est géré exceptionnellement dans l’extension xili-language elle-même en n’utilisant que la liste des langues disponibles et en testant la présence de png dont le nom est basé sur le slug (fr_fr.png…). La dernière version de twenty thirteen-xili utilise une autre approche.

A suivre.

Mode d'emploi, Actus

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

Avantages:

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

Inconvénients:

  • encore plus de lignes de code dans les sources de l’extension !
Mode d'emploi

Une nouvelle extension pour gérer l’attachement des médias : xili re/un-attach media

Cette huitième extension déposée sur le dépôt WordPress s’appelle xili re/un-attach media.
Elle résulte d’un agacement à propos de l’obligation de supprimer le media pour le détacher d’un article et l’impossibilité de faire un ré-attachement.
Après une recherche sur les extensions existantes et examen de leurs sources soit anciens, soit non construit en mode objet (Davidn.de), soit trop complexes, le défi est lancé : faire une extension a minima en OOP, sécurisée (nonce), documentée en ligne (Onglet Aide, Pointeur/PostIt) avec réutilisation maximum des composants disponibles dans WordPress notamment le javascript media.

Les deux nouvelles actions sont disponibles sur la liste

mais aussi dans une “metabox” dans l’écran pour gérer un média.

Etat des attachements en mode single edit
Etat des attachements en mode single edit

Elle est testée pour WP 3.8.3+ et aussi 4.0-alpha…

Lien vers le dépot Github [Github by dev.xiligroup].

xili-re-un-attach-media est sur le dépot WP plugin repository.

Mode d'emploi

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 !

Mode d'emploi

Un peu plus d’infos sur les fichiers .mo selon xili-language.

Depuis sa création il y a cinq ans, l’extension xili-language repose sur deux mécanismes essentiels pour gérer un site web bilingue ou multilingue :

  1. Le langage de chacun des posts (ou custom posts) est défini par la taxinomie “language”.
  2. La traduction dynamique des éléments (titre, mot, phrase, msgid,…) repose sur les fichiers .mo (compilés à partir des fichiers textes .po (comme ceux utilisés pour la localisation) du langage courant. L’extension choisit la bonne langue selon le contexte (et les règles) de la langue de l’article, de la page d’accueil ou de la liste d’articles.

(pré-étude comparative des extensions pour site web bi ou multilingue)

Cas d’un thème habituel (sans parent)

Avec ce thème (ici avec le textdomain twentyfourteen et sans parent), dans un contexte en français, le fichier fr_FR.mo est chargé. S’il existe après création par xili-dictionary ou poEdit, le fichier local-fr_FR.mo est aussi chargé.

Si les fichiers ne sont pas présents dans un sous-dossier du thème et s’ils existent dans le sous dossier wp-content/languages/themes, les fichiers twentyfourteen-fr_FR.mo et twentyfourteen-local-fr_FR.mo sont chargés.

Soyez bien attentif aux faits suivants :

Si un élément ou une phrase (msgid) et la traduction (msgstr) sont à la fois dans fr_FR.mo et dans le local-fr_FR.mo, c’est la traduction dans local-fr_FR.mo qui sera prise en compte.
C’est utile pour préférer sa propre traduction (dans local) à celle fournie par l’auteur du thème original.
Le fichier local-xx_YY.mo contient les traductions des termes, textes et phrases liés au site lui-même (titre, date, catégories,…).

Le cas d’un thème enfant et de son parent :

Par défaut, seuls les fichiers contenus dans le thème enfant courant sont chargés.
Pour assister la gestion des versions et les processus de traduction, il est possible d’utiliser les fichiers de langue (.mo) qui sont disponibles dans le thème parent.
L’extension xili-language permet de définir comment se fera la fusion entre les données des fichiers venant du thème enfant et du thème parent.
Comme dans le cas décrit auparavant, le fichier local- est chargé du dossier enfant et a toute priorité.

Pour les autres fichiers .mo habituels disponibles, vous pouvez définir la priorité entre les données issues du fichier parent ou du fichier enfant (le thème actif). Il est ainsi possible de laisser tel quel le fichier parent sans avoir à le modifier.

Ci-dessous, extrait de la zone de réglages présente dans le 4e onglet des réglages xili-language.

merging .mo files option
Option de fusion des fichiers .mo