Réaliser un site multilingue

Préalable : qu’est-ce qu’un site multilingue ?

Il n’est pas question dans cet article de rédiger un tutoriel complet sur les sites multilingues : d’une part, il y a certainement plusieurs « visions » de ce qu’on appelle « multilinguisme » ; d’autre part, nous manquons toujours de recul pour pouvoir définir « la meilleure méthode ».

Vous trouverez donc ci-dessous une revue des différents outils que SPIP propose pour gérer des sites multilingues ; à vous de les utiliser, et discutons-en dans les espaces prévus à cet effet (forums, wiki, listes de discussion, etc.)

Mais avant de lire, oubliez un peu votre projet du jour, et pensez aux situations suivantes :
-  un site de poésies, classées par thèmes (rubriques) ;
-  un site de documentation pour, par exemple, un logiciel comme SPIP ;
-  un site institutionnel en 25 langues ;
-  un site corporate bilingue ;
-  le site d’une association bulgare avec quelques pages en anglais.

Le site de poésie choisira plutôt ses langues article par article ; la documentation de SPIP, pour sa part, les ventile par « secteurs » (rubriques de premier niveau), et affiche les traductions disponibles pour chaque article, quand ces traductions sont disponibles. Le site institutionnel en 25 langues ne pourra sans doute pas fournir les 25 traductions en même temps, mais cherchera tout de même à conserver des arborescences parallèles ; le site corporate bilingue aura obligatoirement une traduction en face de chacun des articles, et une arborescence de rubriques en deux parties, la partie anglaise étant « clonée » sur la partie en auvergnat ; l’association bulgare affectera l’anglais à un secteur particulier de son site, le reste des secteurs étant tous en bulgare (par défaut).

Principe

Pour pouvoir autoriser ces situations différentes, et d’autres encore, le modèle mis en place dans SPIP consiste à déterminer une langue pour chaque article, chaque rubrique et chaque brève. Dans l’espace public comme dans l’espace privé, cette langue détermine le mode de correction typographique qui est appliqué aux textes ; dans l’espace public cela détermine également la langue des élements insérés par SPIP autour de ces « objets » : dates et formulaires principalement.

Pour créer un site multilingue avec SPIP, il faut d’abord configurer le site en conséquence : dans la configuration du site, à la section « langues » bien entendu. Là vous pourrez activer la gestion du multilingue, et choisir les langues que vous utiliserez sur votre site.

Configurer l’espace privé

Pour gérer plus facilement le site, on peut choisir dans la configuration du site avec quelle précision s’effectuera le réglage des langues, ce qui permet de masquer l’interface là où elle n’est pas nécessaire et de limiter les risques d’erreurs [1]. SPIP propose trois niveaux d’interface différents pour choisir les langues affectées aux articles (et brèves, etc.) ; par ordre croissant de complexité :

-  Par secteur (rubrique de premier niveau) : à chaque secteur du site correspond une langue modifiable par les administrateurs, qui concerne toutes ses sous-rubriques ainsi que les articles et les brèves qui y sont publiés ; ce réglage devrait satisfaire les besoins de la plupart des sites multilingues tout en conservant une structure et une interface simples.

-  Par rubrique : de manière plus fine, avec ce réglage, on peut changer la langue pour chacune des rubriques du site, pas seulement celles de premier niveau.

-  Par article : la langue peut être modifiée au niveau de chaque article ; ce choix est compatible avec les précédents (on peut par exemple choisir la langue par rubrique mais appliquer des exceptions de-ci de-là à certains articles) et permet toutes les finesses imaginables, mais attention à ne pas produire un site à la structure incompréhensible...

Blocs multilingues

Certains objets, comme les auteurs ou les mots-clés, peuvent s’orthographier différemment selon qu’ils sont affectés à un article dans une langue ou dans une autre. Cependant, il serait absurde de concevoir des « traduction d’un mot-clé » ou « traduction d’un auteur », car c’est bien le même auteur qui signe les deux articles, ou le même mot-clé (même « concept ») qu’on leur attache. Ces objets n’ont donc pas de langue au sens de SPIP, mais il est tout de même possible, à l’aide des « blocs multi », de les faire s’afficher dans la langue du contexte dans lequel ils sont invoqués (pour le dire plus simplement : faire que le mot-clé « Irak » s’affiche « Iraq » quand il est affecté à un article en anglais).

Le « bloc multi » est un raccourci SPIP, dont la structure est relativement intuitive :

<multi>chaîne 1 [xx] chaîne 2 [yy] chaîne 3 ...</multi>

Pour reprendre l’exemple du mot-clé, son titre serait entré sous cette forme dans l’espace privé :

<multi>[fr]Irak [en]Iraq</multi>

Si un bloc multi est appelé à s’afficher dans une langue qui n’est pas prévue, c’est toujours la première partie du bloc qui s’affiche (« chaîne 1 » dans le premier exemple, « Irak » dans le second). Cela, afin de ne jamais avoir d’affichage vide [2].

Pour faciliter l’utilisation de ces blocs multi par les rédacteurs il est possible d’installer le plugin multilang. Ce plugin ajoute un menu de langues du type [fr] [en] [it] au dessus de chaque formulaire, en fonction des langues activées dans la configuration du site.

NB : les blocs multi peuvent aussi être utilisés, selon la même structure, dans les squelettes, cf. Internationaliser les squelettes.

Boucles et balises : comment faire

Une fois l’espace privé réglé aux petits oignons, passons maintenant au site public. Hé oui, même si chaque article dispose maintenant de sa propre langue judicieusement choisie (selon le mécanisme expliqué plus haut), les squelettes doivent bien pouvoir en tenir compte dans l’affichage du site.

1. Une bonne nouvelle pour commencer : le multilinguisme des squelettes est pour la plus grande part totalement naturel ; il n’est pas nécessaire de faire des squelettes différents pour afficher des articles de langues différentes. Un même squelette adapte automatiquement son affichage à la langue courante.

Ainsi tous les éléments affichés autour et dans un article d’une langue donnée, seront affichés dans cette langue. Cela concerne aussi bien la date de publication de l’article que les formulaires de réponse au forum, de signature d’une pétition, etc. Plus généralement : toute balise SPIP incluse dans une boucle ARTICLES sera affichée dans la langue de l’article (de même pour les rubriques et les brèves).

Exemple : si votre page d’accueil contient un sommaire affichant les dix derniers articles publiés ainsi que leur date de publication, la date des articles en vietnamien s’affichera en vietnamien, celle des articles en créole de la Réunion s’afficheront en créole de la Réunion, etc.

Note : ce fonctionnement suppose que la langue de l’article fait l’objet d’une traduction dans SPIP. Ainsi, si un article est écrit en volapück mais que votre version de SPIP n’est pas encore traduite en volapück (nous vous invitons bien évidemment à corriger cette lacune en participant à l’effort de traduction), la date de l’article s’affichera en toutes lettres certes, mais dans une langue par défaut - le français probablement.

2. Le sens de l’écriture

Si votre site contient des langues s’écrivant de gauche à droite (la plupart des langues) mais aussi des langues s’écrivant de droite à gauche (notamment l’arabe, l’hébreu ou le farsi), il faudra de petits compléments au code HTML pour que l’affichage se fasse sans accroc [3].

SPIP offre à cet effet une balise spécifique : #LANG_DIR, qui définit le sens d’écriture de la langue courante. Cette balise est utilisable comme valeur de l’attribut dir dans la plupart des tags HTML (cela donne donc « ltr » pour les langues s’écrivant de gauche à droite, et « rtl » pour les autres [4]).

Une boucle d’affichage du sommaire devient donc :

<ul>
<BOUCLE_sommaire(ARTICLES){par date}{inverse}{0,10}>
  <li dir="#LANG_DIR">
    [(#DATE|affdate) ]: <a href="#URL_ARTICLE">#TITRE</a>
  </li>
</BOUCLE_sommaire>
</ul>

Si la mise en page repose sur des éléments alignés à droite ou à gauche, ceux-ci devront être inversés pour les langues écrites de la droite vers la gauche : on peut tout de suite penser à remplacer tous [5] les éléments du squelette marqués left ou right par les balises #LANG_LEFT et #LANG_RIGHT. Pour ce qui est de la définition de la page elle-même, il est alors judicieux de commencer par indiquer la langue de l’élément demandé, et la direction générale de la page :

<html dir="#LANG_DIR" lang="#LANG">
  <head>
    ...
  </head>
  <body>
    ...
  </body>
</html>

3. Les liens de traduction

SPIP propose un système de traduction entre articles : on peut spécifier quelles sont les différentes traductions d’un article (note : ces traductions sont elles-mêmes des articles à part entière). Le critère {traduction} permet alors, dans une boucle ARTICLES, de récupérer toutes les versions d’un même article.

Par exemple, pour afficher toutes les traductions de l’article courant :

<BOUCLE_traductions(ARTICLES){traduction}{exclus}>
  [<a href="#URL_ARTICLE" rel="alternate" hreflang="#LANG">(#LANG|traduire_nom_langue)</a>]
</BOUCLE_traductions>

Notons le critère {exclus}, qui permet de ne pas afficher la version courante, et le filtre |traduire_nom_langue qui fournit le nom véritable de la langue à partir de son code informatique (cela permet d’afficher « français » au lieu de « fr », « English » au lieu de « en », etc.).

-  Un critère complémentaire {origine_traduction} (pour les plus acharnés) permet de sélectionner uniquement la « version originale » de l’article courant.

Une page du wiki de spip-contrib rassemble des exemples de boucles utilisant ces critères : http://www.spip-contrib.net/-Carnet....

4. Éléments supplémentaires

D’autres éléments permettent de fabriquer des sites multilingues :

— le critère {lang_select} sert à forcer la sélection de la langue pour la boucle (AUTEURS), qui normalement ne le fait pas (à l’inverse, le critère {lang_select=non} permet de dire aux boucles (ARTICLES), (RUBRIQUES) ou (BREVES) de ne pas sélectionner la langue).

Exemple pour afficher un texte incluant un bloc <multi> dans la langue du contexte lang du squelette avec une boucle ARTICLES :

<BOUCLE_a(ARTICLES){id_article}{lang_select=non}>
#TEXTE
</BOUCLE_a>

— la variable de personnalisation $forcer_lang. Elle indique à SPIP deux choses :

1. qu’il doit vérifier si le visiteur dispose d’un cookie de langue, et si oui le renvoyer vers la page correspondante. C’est ce que fait la page de connexion à l’espace privé livrée en standard avec SPIP
2. que les chaines de langue de l’interface doivent s’afficher dans la langue du visiteur, et non dans la langue des articles ou rubriques.

— les balises #MENU_LANG (et #MENU_LANG_ECRIRE) affichent un menu de langue qui permet au visiteur de choisir « cette page en ... ». La première balise affiche la liste des langues du site ; la seconde la liste des langues de l’espace privé (elle est utilisée sur la page de connexion à l’espace privé).

— enfin, les critères optionnels permettent d’utiliser une même boucle (en fait, un même squelette) pour afficher soit tous les articles du site dans toutes les langues, soit seulement les articles dans la langue passée dans l’URL. Ça peut être utile dans les backend, par exemple, ou dans les boucles de recherche :

<BOUCLE_recents(ARTICLES){lang?}{par date}{inverse}{0,10}>

<BOUCLE_recherche(ARTICLES){lang?}{recherche}{par points}{inverse}{0,10}>

Des squelettes internationaux pour un site massivement multilingue

Ce qui précède nous a permis de rendre multilingue la partie proprement SPIP de notre squelette : tout ce qui est issu des boucles s’affiche dans le bon sens, avec la bonne typographie, et les éléments produits par SPIP (formulaires, dates...) sont dans la langue demandée.

Pour un site présentant un nombre modeste de langues (bilingue par exemple), ou pour lequel il existe une langue principale et quelques langues annexes, on pourrait en rester là. Les textes figés présents dans les squelettes, c’est-à-dire les mentions écrites directement dans le HTML comme « Plan du site », « Espace de rédaction », « Répondre à ce message »... peuvent dans certains cas rester dans une seule langue ; ou alors, un site bilingue pourra utiliser des squelettes séparés pour chacune des deux langues.

Cependant, si vous voulez réaliser et gérer efficacement un site présentant beaucoup de langues à part entière, il devient illusoire de maintenir des squelettes séparés, ou d’imposer une navigation dans une langue unique (même en anglais ou en espéranto...). Pour réaliser un jeu de squelettes unique fonctionnant dans toutes les langues, il faut internationaliser les squelettes afin de modifier les textes indépendamment du code HTML qui les contient (qui reste, lui, figé d’une langue à l’autre). Cette tâche nécessite de mettre un peu « les mains dans le cambouis » et fait l’objet d’un article séparé.

Détails annexes

-  Les raccourcis typographiques <code> et <cadre> produisent toujours un texte écrit de gauche à droite, même si la langue de l’article s’écrit normalement de droite à gauche. En effet ces deux raccourcis sont destinés à afficher du code ou des données informatiques, qui sont à peu près toujours écrits de gauche à droite (et, la plupart du temps, en caractères occidentaux).

-  Toujours en ce qui concerne le sens d’écriture, notons que les attributs left et right du HTML sont aussi souvent présents dans les feuilles de style. Cela veut dire que vous devrez peut-être inclure la partie correspondante de la feuille de style dans vos squelettes (pour utiliser les balises #LANG_LEFT et #LANG_RIGHT) plutôt que de la placer dans un fichier séparé.

Voici un récapitulatif du comportement des balises SPIP liées au sens de l’écriture :

-  Un filtre |direction_css permet d’« inverser » un fichier CSS pour les langues s’écrivant de droite à gauche. Si la feuille de style CSS à inverser s’appelle par exemple style.css, ce filtre utilise (dans le cas où la langue courante s’écrit de droite à gauche) une éventuelle feuille style_rtl.css ; si celle-ci n’existe pas, il crée automatiquement une feuille RTL en remplaçant toutes les occurrences de left par right et vice-versa (et la stocke dans le répertoire IMG/cache-css/). Il s’applique le plus souvent sur une balise #CHEMIN, de cette façon :

[(#CHEMIN{style.css}|direction_css)]