Google Analytics est un outil très intéressant. Il permet, par exemple, de connaître les origines géographiques des visiteurs. J’ai remarqué que beaucoup de mes visiteurs ne sont pas francophones: Pologne, Allemagne, Etats-Unis, Canada… Le taux de rebond étant assez mauvais, je suppose que ces visiteurs sont donc arrivés là par hasard (ou “attirés” par les mots-clés), et qu’ils sont repartis parce que l’article était en français.
La question d’un blog multilingue vient donc immédiatement. Avant de me décider, j’ai d’abord regarder les possibilités linguistiques de WordPress.
Multilinguisme
Avant de regarder les solutions techniques, définissons d’abord la notion de Blog multilingue. Il y a souvent beaucoup de confusion sur ce sujet. J’ai identifié deux principaux cas:
- Cas 1: Le blog publie l’intégralité du contenu en plusieurs langues. A un instant t, le blog ne s’affiche qu’en une seule langue, et propose des liens vers les différentes traductions. Si un article n’est pas disponible dans la langue demandée, alors il s’affiche dans la langue “principale”,
- Cas 2: Le blog affiche des articles dans différentes langues, sans qu’il y ai forcement des liens de traduction entre eux. Sur une même page, nous pouvons trouver des articles en français, en anglais, en italien … Une variante de ce cas, est l’affichage, au sein d’un même article, de paragraphes dans différentes langues.
Internationaliser un blog
Rendre un blog multilingue suppose de traiter deux choses:
- Le contenant: le thème
- Le contenu: articles, pages, catégories, liens, bookmarks …
Du point de vue internationalisation, WordPress fait les choses à moitié: tout est prévu pour les thèmes et les plugins, mais rien est prévu pour le contenu.
Les thèmes
J’ai déjà traité le sujet dans l’article WordPress: Internationaliser son thème.
Globalement le mécanisme d’internationalisation s’appuie sur le framework GNU gettext. Il est simple à comprendre et relativement simple à mettre en place.
Le contenu
Pour internationaliser le contenu d’un blog, il faut traiter tous les objets du blog, c’est-à-dire les articles et les pages, mais également les catégories, les tags, les titres, les liens, les catégories de liens …
Si l’on se place dans le cas 1, il faut, pour tout ses objets, disposer de leur traduction dans toutes les langues nécessaires, et avoir les liens entre les traductions.
Si l’on ajoute le fait de garder la compatibilité avec les plugins tels que Simple Tags ou les outils de cache, ou de SEO, on voit bien que le problème n’est pas simple.
Le cas 2 est un peu plus accessible, car nous n’avons pas forcement besoin de traduire tous les éléments de WordPress (tags, catégories …). Attention cependant à la clarté du site vis-à-vis des lecteurs.
Pour finir, il faut être attentif à quelques détails qui peuvent avoir leur importance:
- Le format des dates,
- Le sens de l’écriture,
- Les critères d’accessibilité, qui demandant notamment d’indiquer la langue du lien.
Nous pouvons internationaliser le contenu en utilisant deux méthodes: sans utiliser de plugin, ou en utilisant des plugins
Nous aborderons le premier cas dans cet article, et étudierons l’utilisation des plugins ultérieurement.
Internationaliser le contenu, sans plugin
Essayons donc d’internationaliser notre blog, sans utiliser de plugin.
Une seule instance
La première idée qui vient est de créer une arborescence de catégories par langue. Nous aurons donc des catégories racines du type fr, en, sp, … Il faut ensuite adapter le thème pour qu’il n’affiche pas les catégories racines, mais les catégories qui se trouvent immédiatement en dessous.
De façon tout aussi simple, les liens entre les traductions des articles peuvent se gérer avec les Custom Fields. Tout cela demande un peu de développement, mais rien d’insurmontable. Mais pour les autres objets, les choses se compliquent. Comment gérer
- Les pages? Une page mère par langue?
- Les liens (blogroll)? WordPress ne gère qu’un seul niveau de catégorie,
- Les tags? Comment n’afficher que les tags de la langue en cours?
Pour les tags, on pourrait utiliser la méthode d’internationalisation des thèmes ou des plugins, mais cela veut dire qu’il faudrait modifier les fichiers de langue, et les compiler à chaque fois que l’on ajoute un tag !!!
| Avantages | Inconvénients |
|---|---|
| - Une seule instance de WordPress, - Pas de modification de WordPress. |
- Thème complexe, et dédié à cette structure, - Tout n’est pas pris en compte |
Plusieurs instances
La seconde idée est donc d’installer autant d’instances de WordPress que l’on a de langues. La méthode est simple, avec un résultat quasi-immédiat.
La sélection du site en fonction de langue du visiteur peut s’effectuer de plusieurs façons. on peut imaginer, par exemple, la détection de la langue du navigateur, et une redirection vers le bon site.
Les difficultés portent sur la gestion des liens: faire des liens entre articles sera relativement facile, en utilisant encore une fois les Custom Fields. Mais les choses se compliquent pour les autres objets: comment faire des liens entre les catégories, pages de liens, les tags …
Avec une gestion extrêmement rigoureuse, on peut avoir les mêmes identifiants d’une instance à l’autre, mais cette façon de procéder ne supporte pas la moindre erreur.
| Avantages | Inconvénients |
|---|---|
| - Pas ou peu de modifications de WordPress et des thèmes, | - n moteurs, donc n jeux de tables, donc n fois les mises à jour, n fois les installations de plugin … - Liens de traductions -Rigide. |
Un seul moteur, n bases
Il s’agit d’une variante de la version précédente: on installe une seule instance de WordPress, mais plusieurs instances de la base de données (une par langue). Le choix de la base de données s’effectue au niveau du fichier wp-config.php, qu’il faut modifier pour cela.
Dans le jargon technique, on appelle cela une grosse bidouille.
| Avantages | Inconvénients |
|---|---|
| - Une seule instance à mettre à jour, - Modification limitée de WordPress, |
- Mêmes inconvénients, - Liens de traductions. |
Et pourquoi pas WordPress MU
WordPress MU (Mult-User) est une version modifiée de WordPress, permettant de créer, gérer, modifier plusieurs blogs depuis la même interface.
| Avantages | Inconvénients |
|---|---|
| - Gestion incorporée des multiples instances, | - Mêmes inconvénients que la méthode précédente,
- Liens de traductions, |
Première conclusion
Aucune des quatre méthodes listées n’est réellement idéale. La méthode la moins compliquée me semble être la seconde: utiliser une instance de WordPress par langue. Elle oblige à gérer plusieurs blogs, mais elle ne nécessite pas de modifier la structure de WordPress ou des thèmes.
Nous verrons dans l’article suivant si les plugins nous offrent de meilleures solutions.
Other posts of the serie
- WordPress: Blog multilingue - 3ième partie - 5 August 2008
- WordPress: blog multilingue - 2nde partie - 20 June 2008
- WordPress: blog multilingue - 1ière Partie (This post) - 18 June 2008
Français
Pingback: 30 minutes par jour
Merci beaucoup pour votre réponse. Je ferai les choses petit à petit. J’essaierai. Quand j’en aurai terminé, si j’y arrive un jour je vous tiendrai au courant.
Pour l’instant j’utilise ZdMultilang parce que je viens juste de demarrer l’ecriture de mes articles en deux langues, et je ne sais pas encore si je continuerai.
Je reste sur mon opinion de depart: deux blogs en parallele est la moins mauvaise des solutions. Il faut cependant trouver un moyen de rendre l’ensemble un peu plus ergonomique.
J’ai un peu réfléchi au problème, sans avoir trouve de solution vraiment ideale. Tout depend du niveau d’integration souhaite:
un seul lien pour tout le blog, pointant sur la homepage du blog “voisin”,
un lien par article pointant sur la traduction
des liens pour les categories, les tags, …
Le plus simple, serait que tous ces elements aient le meme ID dans les deux blogs, ce qui me parait completement illusoire, ou tres tres complique.
Pour l’instant, ce qui me semblait être le plus raisonnable:
Modifier le theme, en y ajoutant une table de correspondance entre les categories. En face de chaque ID du blog courant, nous avons le permalien de la categorie equivalente dans l’autre langue,
Utilisation d’un “champ personnalise” (custom field) pour les articles. En placant l’url de l’article traduit dans ce type de champ, il suffit ensuite, dans la template single.php, de tester la presence du champ, de recuperer sa valeur avec get_post_meta, et de creer un lien.
Cette demarche est assez rustique, mais robuste et tres simple a mettre en place. Elle laisse toute liberte d’ecrire dans l’une ou l’autre langue, sans devoir obligatoirement synchroniser les articles.
Merci pour ces articles très complets sur les blogs multilingues wordpress. Pour le moment sans pluggin spécial, je publie chaque article en français et anglais dans le même post. Par contre les lecteurs de langue anglaise fuient le site car ils n’ont pas le courage ou ne voient pas que les articles existent en anglais effrayés par l’apparence française du blog. Les surfeurs sont des gens pressés! Je vais passer je crois à la solution deux blogs partageant la mêle base de données car la nature de mon hébergement ne propose qu’une base. Quand je vais migrer les posts de langue anglaise dans le blog anglais mon premier souci (après la mise en place d’un thème homogène) va être de les poster de telle façon qu’ils soient archivés de le même façon avec la même date cela permettrait d’ailleurs de faciliter la gestion des permaliens entre les deux blogs : cela doit être possible et peut-être que vous avez une réponse à cela avant que je n’entreprenne une recherche fastidieuse à ce sujet? Merci