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 !

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.

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 !

Sortie de xili-language version 2.14

Petit à petit les améliorations se mettent en place :

xili-language version 2.14 apportent celles-ci :

  1. un nouveau shortcode pour sélectionner une partie du contenu selon la langue courante,
  2. De nouvelles règles (3) pour gérer le mode de sélection des langues (et fichier mo) pour les extensions traduisibles (3e onglets pour expert), voir détails ici…
  3. une meilleure gestion pour custom post type (CPT) et les custom taxonomy (CT) – Dès lors xili-language est quasi prêt pour woocommerce et créer une boutique multilingue.
  4. Le libellé des catégories s’affichent avec leur traduction selon la langue courante du tableau de bord des articles.

Bientôt d’autres infos dans la partie “Prise en main” !

Quoi de neuf avec xili-language 2.13.2 et xili-dictionary 2.7.2 ?

Petit à petit, la mise à niveau des extensions nées il y a 5 ans se poursuit !
WP évolue en permanence et les exigences des thèmes aussi…
L’incrémentation du 3e indice indique avant tout des corrections ou des optimisations du code, des textes d’aide.

xili-language : Liste des traductions d'un article
xili-language : Liste des traductions d’un article

Versant xili-language (2.13.2) :
– En cas d’activation du mode multilingue pour un CPT, suppression du warning visible en mode debug.
– Personnalisation du selecteur de la liste des msg (CPT) de xili-dictionary.
– Disparition des fichiers langue des widgets intégrés dans ceux de l’extension. (plus facile pour les traducteurs !)

La question sur xili-language :
Certaines variations des modes de lien dans la liste des langages (sélecteur de langue) existent dans les menus mais pas dans le widget. Pourquoi ? Pour obtenir le résultat d’une structure de menu, il suffit d’ajouter le widget ‘menu personnalisé’ 😉

Liste des mgs dans xili-dictionary
Liste des mgs dans xili-dictionary

Versant xili-dictionary (2.7.2) :
– plus de bouton Média pour l’édition des msg,
– sous-titre de description des msg,
– titre unique des messages avec numéro formaté sur 7 digits. (plus facile de détecter les plus récentes par tri sur titre).

La question sur xili-dictionary :
Doit-on laisser cette extension toujours active ? Non, une fois les fichiers mo créés (et po gardés en copie), on peut la désactiver.

Xili-language 2.13 : quoi de neuf ?

Etape par étape, xili-language, tout en conservant son efficacité et ses mécanismes de base, évolue et intègre (côté admin) les outils disponibles dans le noyau de WP qui évolue depuis la version 2.3 pour atteindre aujourd’hui 3.9.
Pour assister l’intégration des fichiers langues système, xili-language va chercher les fichiers dans le dossier dev de GlotPress car, par exemple, alors qu’on est aujourd’hui à la version 3.9.1, le dossier 3.9.x n’est pas encore ouvert.
Bien que l’usage soit moins courant, il est aussi possible d’importer via XML, un site multilingue exporté totalement en XML. Cela demande toutefois des précautions sur lesquelles on reviendra ultérieurement. Le point d’insertion Sélecteur Menus stocke maintenant les slugs ce qui facilitent l’export/import sans avoir à recréer ce sélecteur dans le site importé.
Des améliorations ont aussi été introduites pour prendre en compte des langues déjà présentes dans la taxonomie mais non groupées (réparation de la base).

A suivre…

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

xili-language: découverte d’un nouveau shortcode !

La dernière version de xili-language apporte un nouveau shortcode dénommé xili18n.

Comme tout shortcode, il est insérable dans le contenu d’un article.

Le but de shorcode nommé xili18n : insertion d’un texte qui sera traduit dans la langue du post. (la traduction doit bien sûr existe dans les fichiers .mo de chaque langue.

Pourquoi ?

Un contenu peut parfois être très complexe et riche (exemple: des tables) et quasi identiques pour quelques termes (mais à traduire). Par exemple, on va insérer les shortcodes aux entêtes de colonnes, le contenu sera simplement cloné dans chacun des posts des langues cibles… et les traductions des shortcodes se feront automatiquement.

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

Le résultat pour cette article en français est Modifier !

Autre effet bien sûr sur l’article en anglais 😉

xili-language v 2.13: Les réglages d’édition, traduction

Lors de la mise en place des contenus et notamment des traductions d’une page ou d’un article, il est intéressant de recopier des propriétés et contenus lors de la création comme par exemple le format, le statut des commentaires voir le contenu que l’on traduira alors ligne par ligne. Ces possibilités existaient auparavant la classe “theme-multilingual-classes” utilisées par les thèmes enfant exemple comme Twentyfourteen-xili. Elles sont maintenant disponibles pour tous les thèmes et la page de réglages est dans le 5e onglet.

5e onglet, Réglages édition / traduction
5e onglet, Réglages édition / traduction

Avant de cocher, il vaut mieux faire un choix en tenant compte de la politique éditoriale et de la façon avec laquelle sont définis les articles et pages. Par exemple, si une page peut utiliser le même template dans toutes les langues, son ordre logique peut être différent. Pour les articles, c’est par contre facile de dire que la traduction doit avoir les mêmes facultés pour être commenté ou ‘pingé’.

Informations pour les webmestres ou développeurs de thème

  • Noter que comme pour les menus, les réglages sont affectés/sauvegardés au thème courant. Pensez-y quand vous changez de thème
  • Par défaut, tous les éléments copiables ne sont pas disponibles. La fonction add_theme_support('xiliml-authoring-rules', $params); ajoutée dans le functions.php du thème permet de personnaliser à la fois les textes et d’ajouter des éléments comme le contenu tel quel ou avec un avertissement par exemple.
  • Lors de la création d’un post à partir de celui en langue d’origine, les éléments sont recopiés tel quel. Des filtres sont disponibles (xiliml_propagate_post_columns), il est donc possible de définir des règles plus ciblés, par exemple, changer le format selon la langue cible.
  • Cette page de réglages a été construite sur la base des nouveaux composants disponibles dans le noyau de WP.

un site internet multilingue avec WordPress et xili-language