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 !