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).
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 :
Le langage de chacun des posts (ou custom posts) est défini par la taxinomie “language”.
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.
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.
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 !
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
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
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
