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.

  1. Un article par langue, avec un lien entre les traductions
  2. Enregistrer toutes les variations de langue dans un article
  3. Gérer les traductions dans la page générée, et pas au niveau de l’article
  4. 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.

Edit 2013 : ce défaut n’apparait pas quand les thèmes utilisent correctement query_posts, conformément au Codex. Pour le reste, bad coding -> bad results.

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

9 commentaires

  1. d0r1an Auteur janvier 18, 2010 (3:51 )

    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.

  2. Marie-Aude Auteur janvier 18, 2010 (3:37 )

    CodeStyling Localization c’est juste une interface pour créer / modifier les fichier .po .mo si j’ai bien compris. Mais ça ne sert que si le plugin a déjà été internationalisé, car si il n’y a pas de .po / .pot de base, ça ne peut pas fonctionner, non ?

    En gros, c’est du plugin de plugin :D

    Personnellement, je préfère et de loin PoEdit, mais c’est dans la suite du tutorial

  3. d0r1an Auteur janvier 18, 2010 (4:01 )

    Personnellement, après l’avoir longuement utilisé, je peux t’affirmer qu’il relève bien plus du must have que du gadget =)

    Tous les plugins ne sont malheureusement pas internationalisés et il peut se révéler très utile pour des plugin peu connus mais devenant indispensable.

    PoEdit est excellent je n’en doute pas, mais c’est une application externe (et il faut pas mal de skills pour le maîtriser totalement).

  4. Marie-Aude Auteur janvier 18, 2010 (4:50 )

    « Pas mal de skills » euh non faut pas charrier ^^ c’est plutôt simple.
    C’est une question de philosophie et d’organisation du travail. Personnellement, je préfère passer par gettext / poedit même si cela prend un peu de temps à la mise en place, cela a énormément d’avantages. En tout cas en tant que développeuse

  5. Ric Auteur janvier 19, 2010 (12:03 )

    Voir aussi au niveau base de donné – qtranslate alourdie la base : il ajoute dans le meme post en séparant : ce qui fait des requetes monstre et encore plus monstrueuse avec beaucou de langues : ce qui veut dire très gros défaut de conception ( lié a wordpress) : au moin wplm améliore la gestion en base de ce point de vue.

    Et finalement : global translator peut aussi être utilisé en parallèle d’un autre : tiens voila la bonne idée ?

    Oui : le service de traduction de google se focalise sur l’anglais : et les autres traductions « on verra après ».

    Mais je vous conseil de prendre la traduction « automatique » avec intelligence artificiel ( ce que fait google de manière probabiliste : et avec apprentissage ) beaucoup plus au sérieux.

  6. acs04 Auteur janvier 27, 2010 (4:27 )

    concernant WMPL il est possible de traduire les ‘tags’… J’utilise se plugin sur plusieurs sites, et même s’il n’est pas parfait (et Marie-Aude a listé les principaux problèmes) c’est à mon humble avis la seule extension qui permet de créer un site réellement multilingue avec WordPress.
    Les limitations de WMPL et des autres plugins qui tentent de donner des fonctionnalités du même genre à un site WordPress viennent essentiellement des limitations de wordpress au niveau du modèle de données… une fois de plus ..

  7. Marie-Aude Auteur janvier 29, 2010 (2:51 )

    Pour les tags, je n’y suis pas arrivée. Je suis retournée voir dans mon installation WMPL, et je ne vois pas où je peux faire çà ? La traduction des catégories se fait dans le menu WP en créant une nouvelle catégorie et en indiquant qu’elle est la traduction de telle autre, mais il n’y a pas de menu WP pour gérer les tags ?

  8. acs04 Auteur janvier 29, 2010 (6:53 )

    Pour les tags : il faut aller dans le menu « mots clefs d’articles » et ensuite il suffit de sélectionner le tag à traduire…
    le menu « mots clefs d’articles » est un sous-menu du menu « articles » …
    :-)

  9. Marie-Aude Auteur janvier 29, 2010 (7:14 )

    Effectivement, je ne l’avais jamais repéré celui là !

Commenter

*

*

*Informations requises Merci de donner les informations requises

VotreNom@VotreMotClé, à utiliser avec tact et modération ! ( De toute façon, les spammeurs sont blacklistés )