L’internationalisation
WordPress est entièrement internationalisé. Le core est livré avec des fichiers .po et .mo qui servent à afficher le blog et l’admin dans une des 75 traductions proposées. Avec ce fichier, tous les messages et toutes les chaines de base sont traduites.
Les deux fichiers sont dans le dossier /wp-content/languages/ et identifiés par leur code iso sur 4 lettres (fr_FR pour le français) qui permet de gérer les variantes de langue (par exemple zh_CN pour le chinois et zh_HK pour le chinois de Hong-Kong). A noter que par défaut, WordPress ne différencie pas entre les différentes versions d’anglais (en_US, en_GB), la langue par défaut est l’anglais américain.
Pour les thèmes et les plugins, cela dépend du développeur, en général les développeurs étrangers pensent à internationaliser leur plugin tout de suite. Pour ceux développés aux Etats Unis… ce n’est pas toujours le cas ! En revanche, c’est très facile à faire.
WordPress a au départ été conçu comme un blog, et la plupart des blogs sont monolingues, surtout les blogs de particuliers. Rares sont les personnes qui prennent effectivement la peine de traduire tous leurs articles en plusieurs langues (moi y compris). Cet article (en anglais) du Codex donne différentes structures possibles pour un site multilingue.
- Un article par langue, avec un lien entre les traductions
- Enregistrer toutes les variations de langue dans un article
- Gérer les traductions dans la page générée, et pas au niveau de l’article
- Utiliser des services de traductions automatiques
On oubliera la dernière possibilité, qui donne des résultats souvent mauvais, et ne permet pas de faire indexer son site dans un contenu traduit.
Les différents plugins qui permettent de faire un site multilingue avec WordPress sont donc handicapés par la conception de base, et une structure de données qui ne facilite pas les choses.
Le plugin WMPL
C’est le dernier né des plugins de traduction. Fait par une société de traduction, son interface permet de leur commander des traductions de votre contenu.
Il est assez complexe, et travaille à plusieurs niveaux :
- la traduction des chaines de caractères, qui se trouvent dans le thème. On peut aussi utiliser les fichiers .po et .mo, et les gérer par l’interface d’admin
- les articles et les catégories
Il permet de gérer les urls, avec le choix entre des sous-répertoires (on ne peut pas choisir le nom du sous répertoire, c’est obligatoirement la langue codée sur deux caractères), des noms de domaine différents, ou la langue en paramètre de l’url.
Il faut choisir une langue par défaut. C’est celle qui correspond à l’url « normale » du blog. Les articles et les catégories existants au moment de l’installation du plugin sont affectés à la langue par défaut (mais cela peut être modifié).
Les utilisateurs peuvent paramétrer individuellement leurs préférences pour le langage d’admin.
Enfin il est possible de paramétrer l’affichage quand des traductions sont manquantes.
En ce qui concerne la traduction du thème, elle peut se faire directement dans l’admin de wordpress (ce que je trouve dommage, car c’est un travail perdu si on change de solution), ou par le biais d’un fichier .po et .mo
Dans ce cas, il faut indiquer manuellement le textdomain.
Or celui ci est déjà mentionné dans le thème.
D’autres chaines peuvent aussi être traduites, et notamment les titres des widget, le titre du blog et son slogan.
Petit défaut, l’interface ne montre que la version originale par défaut, il faut cliquer dessus pour voir la traduction.
La traduction des commentaires est possible, mais uniquement en activant la traduction professionnelle (et payante). Et si je veux traduire mes commentaires moi même ? Eh bien je les « refais » à la mimine.
Enfin, un aspect intéressant, c’est la possibilité de nettoyer entièrement la base de données, en cas de désinstallation.
Bien, et maintenant ce qui ne va pas, ou qui ne suffit pas ?
- Pas de doc en français, et pas de traduction du plugin en français.
Pas d’interface de traduction des tags. Les tags sont complètement oubliés. Cela veut donc dire qu’il n’est pas possible de proposer des articles « sur le même tag mais dans une autre langue ». Dommage. Surtout si les pages de tags sont référencées.- Une doc très légère
- des fonctionnalités ‘autres’, qui n’ont pas grand chose à voir avec la traduction, et notamment la mise en place de menus « de type CMS » et de fil d’ariane
- Pas de traduction des informations utilisateurs, qui peuvent être utiles, notamment sur la page auteur
- Pas de « base » traduite pour les pages catégories, tags, auteur (la base, c’est le répertoire virtuel qui est crée entre l’url du blog et le nom de la page
- L’apparition incompréhensible de @ de dans certains noms de catégories dans le thème (sans doute quand le nom est identique au nom français)
- L’interface de traduction ne coche pas la catégorie traduite de l’article d’origine -> risques d’erreurs d’affectation
- Aucune documentation pour la sélection éventuelle d’un thème différent par langue
- Une gestion des sélections d’articles sur la base de l’ID, et pas de l’ID maître, ce qui peut poser problème en cas d’utilisation d’un thème magazine
Je vais expliquer plus en détail les deux derniers points.
La plupart des thèmes magazines fonctionnent avec une identification des articles à mettre « en une », soit par un champs personnalisé, soit par une catégorie. Or ce type de requête bypasse manifestement les réglages du plugin. Avec un Mimbo, par exemple, j’ai deux fois l’article en featured (la version de base et la version traduite), et l’article Lead apparaît en version traduite dans les articles normaux (je précise que j’ai modifié mon Mimbo pour éviter les doublons d’articles).
Problème similaire pour la liste des catégories que je souhaite afficher dans le menu. J’ai utilisé certains paramètres pour mon wp-list-categories, en spécifiant notamment les catégories à inclure. Mais ces catégories sont francophones, et leur version traduite n’apparait pas dans la version allemande.
C’est un gros défaut, car cela veut dire qu’il faut modifier le thème à chaque fois que l’on rajoute une traduction.
Quant à la gestion des articles mis en lumière, je n’ai pas trouvé de solution.
WPML n’est pas une solution parfaite pour faire un site Wordpress multilingues et de plus, j’avoue que l’emphase mise sur la vente de leurs produits me gonfle un peu. Si, si. En dehors de cet aspect, je pense que leurs défauts tiennent à la structure de Wordpress.
Le plugin qTranslate
QTranslate lui n’a pas été développé par une société de traduction. Cependant, dans sa version 2, il intègre les services d’une société, Web Translations.
Il repose sur une technique de « quicktag », ajoutés dans chaque champ à traduire (nom de l’article, extrait, contenu, mais aussi nom de la catégorie).
Le quicktag est un code qui va indiquer dans quelle langue se trouve le texte.
Selon l’endroit où on se trouve (contenu textuel dans l’admin, comme le texte de ce post) ou fonction php, on utilisera la forme longue
english textgerman texttexte français
ou la forme courte
[:en]English[:de]Deutsch[:fr]Français
La forme courte n’a pas besoin d’être fermée, et elle n’est pas nettoyée par les fonctions de sanitization de Wordpress, on peut donc par exemple l’utiliser dans les titres de Widget.
Il vaut mieux rajouter des boutons dans l’éditeur visuel (et même dans l’éditeur html, même si hack is bad)
Les modifications sur la structure de la base de données sont légères (notamment élargissement du champs « titre » des catégories, pour pouvoir inclure les quicktags. En revanche les modifications du contenu sont extrêmement lourdes, et il vaut mieux ne pas désinstaller Qtranslate après l’avoir utilisé sur de nombreux posts !
L’autre aspect, c’est que les slugs, ou nicename, ou identifiants de posts et de catégories inclus dans l’url ne sont pas modifiés par rapport à la version initiale. Pas très SEO friendly.
Le thème, lui est traduit par rapport aux fichiers .mo et .po.
Par rapport à WPML, la doc de base est nettement plus développée, même si elle n’existe qu’en anglais et allemand (et chinois je crois). Il y a un forum utilisateur qui semble actif.
Le système de traduction fait qu’on n’a qu’une ID pour une catégorie ou un post. Il n’y a donc pas de problème avec les thèmes magazines. Le plus gros défaut que je vois est le contenu visible si le plugin est désactivé, et la nécessité de nettoyer la base. Or le plugin peut aussi être désactivé à cause d’une incompatibilité avec une future version de WordPress.
Le deuxième problème est l’impossibilité d’avoir des urls avec des mots clés traduits.
Le prochain article présentera deux autres plugins : Polyglott et Global Translator
Excellent article une fois de plus :p !
Pour rester dans le domaine de la traduction (et de WordPress), je conseillerai le plugin « CodeStyling Localization », qui permet de gérer la traduction de la majorité des plugin directement via l’interface de WordPress.
Des intéractions directes avec les .po/.mo permettent une traduction en temps réel, qui affiche les sources (ex. : « comment ») avec son champ équivalent dans la langue choisie (ex. = »commentaire »).
De plus, un outil intrinsèque permet de partager, d’importer, ou d’exporter lesdites traductions.