Un an avec Spip pour construire un site multilingue

(Paolo, 15/11/05 : je viens de mettre à jour quelques points de cet article.)

J’ai découvert Spip à l’automne 2003. J’étais à la recherche d’un système permettant de gérer notre site : environ 1 000 pages, en 27 langues, toutes faites à la main. Chaque fois qu’on ajoutait une page, il fallait aussi modifier deux autres pages : celle d’un JavaScript qui produisait le menu, et celle qui présentait la liste des nouvelles pages.

Le site taize.fr sous SPIP n’est pas encore fini à l’heure d’écrire ces lignes, mais il fonctionne déjà. Si nous avions essayé de suivre une mise en route très planifiée pour ce site, nous n’y serions jamais arrivé, je crois. En fait, tout se fait de manière simultanée : les traducteurs se familiarisaient avec l’interface de l’espace privé en transférant le contenu de l’ancien site vers le nouveau, nous réfléchissions à la manière de structurer la navigation au fur et à mesure de sa construction, tout en essayant de résoudre les problèmes techniques et linguistiques qui se posaient — le plus souvent avec un recours aux trois listes Spip. Pour beaucoup des questions rencontrées, Spip a évolué parallèlement à notre site.

Au début, ayant essayé quelques boucles, je me suis dit que c’était assez facile ; cela n’allait pas prendre beaucoup de temps. Je me suis trompé ! Je n’avais pas pensé jusqu’au fond les questions du multilingue.

Structure du site

La conception multilingue du site est un peu différente de celle des autres sites que j’ai vu discutés dans les listes. Elle ressemble peut-être plus à spip.net que d’autre chose.

Chaque langue a un secteur (rubrique racine) propre. Et chaque langue possède les mêmes 9 rubriques au deuxième niveau qui correspondent chacune à un thème ou « chapitre ». 9 mots-clés correspondent à ces 9 chapitres. L’idée de base est que le visiteur peut choisir une langue, visiter les chapitres (menu horizontal) et les articles qu’ils contiennent (menu vertical), libre à (presque) tout moment de passer à une autre langue. Ce passage se fait par des passerelles faites des liens de traductions (entre articles) ou des mots mots-clés (entre chapitres, les rubriques ne disposant pas de liens de traduction).

Pour ce qui concerne les rubriques, seulement ces 9 chapitres s’affichent à l’écran. Si on tape l’URL d’une rubrique d’un niveau inférieur (en_rubrique11.html), on est redirigé vers la page d’accueil. Ces sous rubriques servent uniquement à faire des « dossiers » dans le menu dépliant à gauche (par exemple : « Africa », « Americas », etc. sur cette page).

Nous n’hésitons pas à obliger le visiteur de choisir manuellement dans une liste de langues. Je pense que montrer qu’il y a des articles disponibles dans beaucoup de langues constitue un attrait ; surtout que toutes les rencontres de jeunes qui se passent ici sont très internationales.

Les squelettes

Pour le visiteur, le site possède très sensiblement 4 « niveaux », qui correspondent à quatre squelettes :

• L’accueil du site (choix de langue) : home.html
• La page sommaire de chaque langue : toplevel.html
• La page de garde d’un chapitre : mainsection.html
• L’article : artnorm.html
  Ces squelettes se trouvent tous dans le sous-répertoire /squelettes.

Pour certains articles spécialisés (formulaires, etc.) j’ai dû créer des squelettes supplémentaires. Mais la plupart des pages du site, dans toutes les langues, n’utilisent que ces quatre squelettes.

La mise en page est très simple. Tous les squelettes ont été écrits dans un éditeur de texte. Les feuilles CSS ont sûrement besoin d’être nettoyées : ce sont les premières vraies feuilles de style que j’ai faites, et j’ai fait un peu n’importe quoi pourvu que ça marche. Pour ce qui concerne le positionnement, après quelques essais en css, j’ai baissé les bras et utilisé des tables.

Articles partagés

Jusqu’alors, vraiment simple de faire avec Spip. Il fallait juste ajouter un squelette (home.html) qui offre le choix de langues, et qui redirige vers le « sommaire » (toplevel.html) dans la langue désirée.

Mais que faire des articles qui n’avaient pas vraiment de « langue » mais que nous voulons quand même rendre disponibles au visiteur indépendamment de la langue qu’il a choisie ? Par exemple cet article est un gif ! Plus qu’une centaine de chants : mettre tout ça 27 fois (pour chaque langue) n’aurait aucun sens. Ou les horaires SNCF : tenir ça à jour si ces horaires se trouvent dans plus d’un article serait un cauchemar.

Alors j’ai crée un secteur supplémentaire, « shared », pour les articles qui doivent être accessibles depuis les menus de toutes les langues. Dans ce secteur il se trouve aussi les mêmes 9 chapitres, marqués des mêmes mots-clés, que dans les secteurs « de langue ».

Pas si simple

Et puis il y a des articles qui sont traduits dans certaines langues, mais que nous voulons faire apparaître même dans le menu des langues dans lesquelles ils ne sont pas traduites. La page « Taxis et bus » en est une bon exemple : le sélecteur de langues fait penser que cet article est traduit dans un nombre de langues impressionnant. En fait l’apparence est trompeuse. L’article est vraiment traduit dans une demi-douzaine de langues (it_article1131.html, de_article271.html,...), mais comme la version anglaise a été placée dans le secteur « shared », il est possible d’accéder à l’article (en anglais), tout en restant dans le cadre du menu d’une autre langue ; en estonien, par exemple : en_article21.html?lang=et. L’usage d’un bloc <multi> pour le titre de ces articles partagés, fait paraître au moins le titre de l’article dans la bonne langue, et sur la page même et dans les menus.

Le but était d’arriver à cette fonctionnalité tout en restant très simple dans l’espace privé pour l’équipe de rédaction. Je crois que c’est plus ou moins gagné. Si un article est publié dans le secteur anglais, il est visible seulement à partir du menu en anglais. Si, par contre, il est publié dans le secteur « shared », alors il devient visible à partir des menus de toutes les langues. C’est un choix très simple pour le rédacteur/administrateur à faire. Si quelqu’un traduit l’article « partagé » sur les taxis en estonien, alors les boucles du sélecteur de langue le détectent et le choix d’estonien dans le menu ne dirigera plus vers en_article21.html?lang=et, mais vers la nouvelle traduction.

Simple pour l’espace privé, mais une des choses un peu compliquée au niveau du squelette : 43 lignes de boucles et d’HTML pour produire le menu de langues.

Changement de mode de travail

Un des premiers articles sur spip.net que j’ai lu était « L’histoire minuscule et anecdotique de SPIP » [1]. C’était le « dessine sur un bout de la nappe en papier du restaurant la structure d’une base de données » qui me restait à l’esprit : voilà une façon de traiter l’informatique qui me plaisait : pas trop au sérieux.

C’est un peu fou en ce moment. Nous avons fait les choses tellement en hâte, que ce n’est pas encore très clair qui fait quoi. Mais les pages web sont devenues beaucoup plus faciles à ajouter, à corriger, à maintenir à jour. J’aime beaucoup voir dans l’espace privé qu’il y a deux ou trois autres connecté en même temps, souvent à des milliers de kilomètres de distance.

Je n’ai activé ni les statistiques ni la gestion des versions pour l’instant. Je ne suis pas sûr nous ayions besoin des statistiques — est-ce forcément bien pour nous de pouvoir quantifier exactement combien un article est lu plus en anglais et allemand, qu’en estonien ou slovaque ? La gestion des versions, par contre, pourrait peut-être nous aider beaucoup... je dois encore y regarder.

Notes techniques

Un site démo a été publié sur spip-contrib pour expliquer plus en détail le fonctionnement de cette méthode multilingue.

Deux techniques sont assez « de base » pour le fonctionnement multilingue du site :

La première (une idée de Fil) consiste à placer la ligne suivante dans le fichier article.php3

if (isset($_GET['lang'])) $forcer_lang = true;

Si lang=xx se trouve dans l’URL de l’appel cela va permettre de forcer la langue des menus à cette langue. Cela s’utilise pour appeler ces articles « partagés ». Si par contre il n’y pas de variable lang= dans l’URL, alors les menus de la page prendront la langue de l’article appelé.

La deuxième technique dépend d’une des avancées capitales du nouveau compilateur de Spip 1.8 : la possibilité de lire la valeur de balises dans d’autres boucles même les balises homonymes de celles de la boucle courante. Cela m’a amené à commencer tous mes squelettes « article » avec cette séquence de 4 boucles :

J’explique rapidement cette construction :

 La première boucle prend tout simplement l’article passé dans l’URL. Grâce à la syntaxe #_art0:TITRE, #_art0:LANG_DIR, etc. il est possible, à travers la page, d’accéder à toutes les balises de l’article ;

 La deuxième boucle cherche la rubrique au niveau « chapitre » (le niveau immédiatement en dessous du niveau racine) qui doit être marquée d’un des 9 mots-clés ;

 C’est l’identité de ce mot que nous cherchons avec la troisième boucle : alors nous savons en quel « chapitre » nous nous trouvons ;

 Et la 4ème boucle prend d’abord la langue {lang} — qui sera soit la langue passée dans l’URL, soit, s’il n’y en avait pas, la langue de l’article. Ensuite la boucle exclut le secteur 586 (c’est l’ID de mon secteur « shared » qui ne va pas changer). Enfin il cherche la rubrique qui est dans la bonne langue et qui porte le mot-clé du chapitre. Cette dernière boucle donne la langue en cours pour les deux menus, et pour les chaînes <: xxx :> — « Rechercher », « Version imprimable », etc..

Contributions utilisées

Je pensais pouvoir dire que j’ai utilisé du Spip vanille pour cela, mais je me rende compte qu’il y a six additifs essentiels au site :

 Les fichier inc-urls.php3 de spip.net et un fichier .htaccess pour l’URL rewriting, que Fil m’avait passés. Ces fichiers permettent d’avoir des URLs en .html préfixés par la langue de l’article/rubrique et surtout d’ avoir une page d’accueil par langue avec une adresse très simple à retenir — http://www.taize.fr/fr par exemple.

 Trad-lang v.0.3 de Florent Jugla — essentiel pour les traductions de textes occasionels dans le squelettes.

 J’utilise des mots-clés pour choisir les squelettes, après avoir reçu un encouragement de la part de BoOz. (Un développement de Spip depuis donne la possibilité aujourd’ hui de faire cela encore plus simplement.)

 La méthode décrite ici pour insérer un script PHP dans un article m’a vraiment beaucoup aidé, car j’ai des tables extérieures à Spip qui fournissent le texte pour certaines pages.

 Pour disposer de plusieurs niveaux d’intertitres, j’ai intégré la plus grande partie de cette contribution .

 Et pour donner une protection antispam aux adresses email, j’ai écrit quelque chose moi-même.