Pourquoi xili-dictionary ? Quel dictionnaire ? [mis à jour 0.9.7.2]

Pourquoi l’extension (plugin) xili-dictionary ? Depuis la première maquette fonctionnelle, quelles sont les changements ?

Pour faire un site multilingue, il faut bien-sûr des articles en différentes langues mais il est aussi nécessaire que le cadre (thème) général du site s’adapte à la langue du (des) article(s). 

Dans la première version, au lieu d’utiliser les fichiers .mo, l’extension disposait de sa propre base multilingue basée sur les tables taxonomy et terms de WordPress dont on a essayé de comprendre l’architecture apparue avec la version 2.3 de WP.  

Un inconvénient majeur, dans les fichiers du thème, il fallait remplacer les fonctions ‘internationales’ _e() et __(). Ce qui n’est pas très pratique et pose problème quand le plugin est absent.

L’extension xili-language a donc été modifiée pour lire à la volée le bon .mo selon la langue du post, tout en conservant l’utilisation d’un thème « internationa ». Elle est maintenant publié ici.

Que faire de xili-dictionary ? 

Un outil pour collecter les données à traduire qu’elles viennent du thème (par analyse et/ou lecture des .po existants) ou de la base (les catégories).

Un outil pour créer les fichiers .mo (et .po) du thème courant.

Bien sûr, il existe des outils comme PoEdit ou l’outil très pointu codestyling-localization qui s’intègre dans le tableau de bord de WP mais dans le deux cas, rien ne reste dans la base WP. Et de plus, en toute facilité, il est possible de changer rapidement une traduction « online » sans faire appel à Poedit installé sur votre propre ordinateur. 

Pour les développeurs, cette extension est aussi un exercice exigeant pour bien comprendre à la fois la taxinomie et l’interface d’administration. De même, comme à l’accoutumée, l’idée est de faire des extensions les plus légères possibles en réutilisant au maximum les fonctions, classes et « hook » existants du noyau WP.

La version « beta » est disponible sur le site des plugins WordPress.

. L’interface est petit à petit optimisée avec maintenant des sous-sélections en cas de grandes listes mais fonctionnel – La 0.9.5 inclut un codage en OOP et l’interface incluant les potentialités WP 2.7 (meta_box, js, options UI…). La 0.9.6 est corrigée W3C et redevient compatible avec la future version 2.8 de wordpress.

Un chapître réservé aux développeurs :

Les clés de la taxinomie sont dans le fichier documenté taxonomy.php (du dossier wp-includes). Depuis sa création (WP2.3), il a progressé et on peut considérer qu’il est à maturité avec la WP 2.7.

Quelques observations clés :

De base, WP contient plusieurs « classeurs » de termes : les catégories, les tags, les liens.

Un terme qui est unique (soit par son nom (name) soit par son « slug ») peut appartenir à plusieurs « classeurs » ou taxinomies. C’est ce qui se passe quand une catégorie est traduite par xili-dictionary. Ajouter ou détruire un terme de xili-dictionary n’ajoute ou ne détruit pas le terme mais son lien avec le classeur ‘dictionary’ créé par le plug-in.

Custom Taxonomies est un plugin intéressant à ce titre mais l’auteur a recréé un ensemble de fonctions qui, pourtant, se trouvent dans le noyau WP. Mais, on peut avec cet outil retrouver le « dictionnaire ». Mais il n’est pas fait pour cela.

Pour gérer les différentes langues, xili-dictionary utilise le slug comme identifiant pivot. Le nom du terme sert pour le catalogue mais le msgid (ou le msgstr) des .po est stocké dans la description du terme afin de conserver les attributs et tags html. 

Ainsi le terme ‘bad words » aura le slug « bad-words ». Sa traduction « mots incorrects » aura le slug « bas-words_fr_fr ».

De même le terme ‘<the <strong>good</strong> words » aura le slug « the-good-words ». Sa traduction « les mots <strong>exacts</strong> » aura le slug « the-good-words_fr_fr ». 

La colonne « slug » a été laissée dans la liste du dictionnaire afin de détecter facilement les termes qui vont nécessiter une traduction.

 A suivre… (avec le mode d’emploi…)

– mis à jour le 1/3/09 –