S’il y a beaucoup de choses qu’on peut revoir, modifier, améliorer, si votre site internet n’a pas été pensé dès le début pour être multilingue, il ne pourra pas le devenir.

Je parle là d’un site vraiment multilingue, pas d’un site qui mélange les langues, comme par exemple Climb To the Stars où le français et l’anglais sont mélangés sur les pages, et dans les commentaires. Ça ce n’est pas un site multilingue, c’est un site Babel, au bon sens du terme.

Préparer un site multilingue, c’est se poser avant des questions sur la clientèle (quelle version de langue), sa structure, en noms de domaines, sous domaines, répertoires, l’organisation des contenus d’une langue à l’autre (y aura-t-il une langue maître ou pas), la qualité et le rythme des traductions, à rapprocher du rythme de production du contenu, la mise en page, car le même texte occupera rarement la même place d’une langue à l’autre, sans toucher aux problématiques de directionnalité, et une fois qu’on a répondu à tout ça, la solution technique, qui doit aussi convenir aux autres besoins du site.

Internationalisation et localisation

Ou pour les geeks, i8n et L10n.

Internationalisation

L’internationalisation, c’est la préparation d’un système pour qu’il puisse être traduit ultérieurement. Organiser la structure de données, éviter de coder les chaines de caractères en dur, prévoir les routines qui vont permettre la traduction. On l’abrège souvent en i8n, et c’est notamment le nom qui a été donné au module de traduction dans Drupal.

Localisation

C’est le fait de traduire, au sens large, mais aussi d’adapter à la culture d’une langue ou d’un pays. Le format des chiffres, des dates, doit être adapté, par exemple. Cela peut aller plus loin, comme une modification des images, ou de la taille des boutons et des zones de saisie (avec l’exemple bien connu de l’allemand qui a besoin de plus de place que l’anglais). On l’abrège souvent en L10n.

Les contenus à traduire

La solution technique doit permettre de traduire tous les contenus du site, et, si possible en plusieurs langues (en gros il est techniquement nettement plus simple de faire un site avec deux langues qu’avec plusieurs, surtout quand le nombre de langues n’est pas connu à l’avance).

Les contenus

Bien sûr, en premier, devront être traduits les contenus. C’est à dire, soit les pages, soit pour les CMS la base, la table wp-posts par exemple pour WordPress.
Ce contenu doit pouvoir être traduit par le biais d’une interface web à laquelle les traducteurs auront accès, soit en important des traductions.
Il s’agit d’une traduction de texte pour le web : les balises html contenues dans le texte doivent elles aussi être traduites, et notamment les alt, ou les titles. Pour le référencement comme pour l’internaute.

Les qualifiant du contenu

Par « qualifiant » du contenu, j’entends tout ce qui va être balise meta, balise title, description, mots clés (même si ils sont peu utiles en terme de référencement, mais si on en met, c’est pour les traduire), mais aussi l’url, et enfin tout ce qui est du domaine des tags et des catégories.
Déjà un peu plus difficile selon les cas.

Les contenus « annexes »

Pour des CMS comme WordPress ou Drupal, les taxonomies (c’est à dire au sens large, tout ce qui permet de classer un contenu) sont en fait des contenus eux-mêmes, puisqu’on peut y ajouter une description (elle aussi à traduire), et qu’on affiche les articles s’y rapportant, par le biais d’url, avec des metas, etc…
De la même façon, la biographie de l’auteur d’un article, le pavé ou la page « a propos », le slogan, tout cela sont des éléments entrés dans la base de données, qui doivent pouvoir être traduits.

L’interface

L’interface, c’est le thème, tout ce qui apparait à l’utilisateur. C’est là que les graphistes incluant du texte sous forme d’images, ou pire sous forme de flash, se font bénir.
En fait l’interface comprend toutes les chaines textuelles incluses dans les templates, mais aussi dans les scripts php ou javascripts utilisés pour le site.
Et tant qu’à faire, l’admin du site.

Les contraintes du multilinguisme

Le multilinguisme impose une structure de données

Et c’est pour cela qu’il doit être pris en compte dès le départ.

On peut tout de suite oublier les sites faits en HTML pur et dur. A moins qu’ils n’aient que quelques pages, la tâche de traduction, et de mise à jour simultanée des pages en cas de changement d’un élément, sera tout simplement impossible.

Pour un CMS, quel qu’il soit, la base de données devra obligatoirement être structurée de façon un peu plus complexe que pour un site monolangue.

En gros, un site monolangue pourra parfaitement, comme WordPress, stocker directement dans sa table de contenu l’identifiant du contenu, le texte, et tout ce qui y est attaché.

Pour un site multilangue, il faudra stocker dans deux tables différentes, d’une part les éléments qui ne changent pas en fonction de la langue (donc l’ID) et dans une deuxième table, dont la clé sera la combinaison de l’ID et de la langue, tout le texte, et tout ce qui dépend de la langue. L’auteur du post peut par exemple être double (un « auteur » attaché à tous les articles, et un « traducteur » pour chacune des traductions). On peut aussi avoir une ID différente pour chaque post, et une relation entre les ID.
Le classement du post (menu) peut aussi être attaché au post de base, ou pouvoir être différent selon la langue.

Le statut du post, brouillon, publié, etc… peut être attaché à l’une ou l’autre des tables, ou les deux. Cela a une influence sur la notion de langue maitre

L’identification des chaines de texte à traduire

En gros, deux solutions existent, qu’on verra en détail après. Le fichier de variables, ou on saisit toutes les traductions, ou l’utilisation de gettext.
Dans les deux cas, le résultat pour les scripts et les templates est le même : on n’affiche plus directement la chaine de caractères, mais on l’identifie d’abord comme une variable à traduire, puis on va chercher sa traduction.

Les solutions possibles

Après cette introduction, on va passer à un comparatif de trois CMS (WordPress, Joomla et Drupal), pour voir dans quelle mesure ils ont été internationalisés (i18n) et quelles sont les différentes solutions possible pour localiser un site fait avec chacun de ces CMS.

La dernière partie de cette série sera un tutoriel très détaillé sur l’utilisation de gettext po, en général et pour son propre CMS. Gettext est une librairie pour php (notamment, mais c’est juste à cet aspect là qu’on va s’intéresser), beaucoup plus efficace que la gestion du fichier de variables, et souvent ignorée.