SPIP permet de publier des sites en plusieurs langues. Cette possibilité se caractérise notamment :
- par la possibilité de publier des informations dans plusieurs langues, en respectant les règles de la typographie de chaque langue (les règles de typographie sont différentes, par exemple, en français et en anglais), le sens de l’écriture (l’arabe et le persan s’écrivent de droite à gauche), l’affichage de certaines informations (afficher les dates dans la bonne langue, afficher les formulaires, par exemple l’interface pour écrire dans les forums, dans la langue qui convient...) ;
- par l’existence de liens entre les différentes traductions d’un article, permettant d’indiquer aux visiteurs qu’un article peut être consulté dans d’autres langues, et quel est l’article d’origine.
La liste des traductions de l’article "C’est quoi SPIP" de spip.net
Des structures très souples
Quoique simple à utiliser, le multilinguisme de SPIP autorise des structures diverses et très souples. On peut cependant conseiller les configurations suivantes pour faciliter le travail des rédacteurs et des administrateurs :
- Sur un site destiné à publier de nombreux articles dans plusieurs langues, le plus simple est de définir des langues par grandes rubriques (par exemple : une grande rubrique en français, une grande rubrique en espagnol et un grande rubrique en polonais) ; c’est, par exemple, le fonctionnement du présent site ; de cette manière, les rédacteurs voient leur travail simplifié, et la structuration du site (la définition de la hiérarchie des rubriques) n’est pas compliquée ; de plus, cela permet de définir plus facilement des administrateurs chargés d’une seule langue (« administrateurs restreints à une rubrique »).
- Sur un site proposant très occasionnellement des traductions d’articles, on peut préférer définir la langue pour chaque article, en regroupant par exemple les traductions d’un article dans la même rubrique (puisqu’ils concernent le même thème). On n’a pas alors besoin de définir des langues pour les rubriques.
- La solution qui consiste à mélanger les deux méthodes (définir la langue à la fois pour les rubriques et pour les articles) est à réserver aux cas extrêmement spécifiques : si cela offre une très grande souplesse, elle peut rapidement compliquer la gestion du site, la création des squelettes, et induire des incohérences dans la structure logique de votre site.
Un « truc » très simple permet de se simplifier la vie, d’alléger l’interface de l’espace privé et d’éviter les mauvaises manipulations par les rédacteurs : vous pouvez activer les fonctions de multilinguisme lorsque vous définissez les rubriques (ou les quelques articles traduits occasionnellement), puis les désactiver lorsque vous avez terminé. Le multilinguisme ne sera pas supprimé pour autant : simplement il fonctionnera de manière transparente pour les participants au site.
Par exemple : dans le cas d’un site structuré par grandes rubriques de langue, et sur lequel les articles ne sont pas des traductions les uns des autres, on peut activer les fonctions de multilinguisme ponctuellement, le temps de définir la langue de chaque grande rubrique, et ensuite désactiver l’ensemble. Les rubriques seront « figées » dans leur langue (le menu permettant de modifier la langue disparaît), mais les articles installés dans ces rubriques adopteront la langue correspondante. Et on pourra évidemment réactiver ultérieurement ces fonctions lorsqu’on en aura besoin.
Les squelettes eux-mêmes multilingues
L’interface publique d’un site sous SPIP est réalisée avec un système de « squelettes ». SPIP offre un ensemble de possibilités pour que ces squelettes soient eux-mêmes multilingues (par exemple, dans la partie française, la présente documentation affiche le texte « Télécharger la dernière version » ; dans la partie en anglais du site, cette mention devient « Download the latest version »).
Ces éléments, plutôt techniques, sont décrits dans un article de la présente documentation.
SPIP n’est pas massivement multilingue
À l’inverse de quelques autres logiciels de publication de sites (CMS), SPIP n’est pas massivement multilingue.
Dans un système massivement multilingue, absolument tous les éléments peuvent être traduits et bénéficient d’une interface adaptée pour réaliser cette opération. Dans SPIP, le choix a été de limiter essentiellement le système de traduction à la traduction des articles (des méthodes existent pour contourner cette limitation, mais elles sont volontairement réservées aux utilisateurs très expérimentés).
Ce choix s’explique de plusieurs manières.
- Avant tout, par l’histoire de SPIP : SPIP au départ n’était pas du tout multilingue, il s’agit donc d’une évolution introduite tardivement. Le transformer en système massivement multilingue aurait nécessité des modifications de fond extrêmement lourdes : c’est-à-dire des temps de développement interminables et des risques de bugs énormes.
- Le fondement de SPIP est la recherche d’une ergonomie immédiatement compréhensible par un utilisateur débutant. Ergonomie dont certains principes sont désormais bien « rodés ». Il a donc été préféré une évolution qui poursuive dans la logique de SPIP (des articles clairement identifiés et séparés dans des rubriques, et non différentes version d’un même article dans différentes version d’une même rubrique), et la recherche d’une évolution ne remettant pas en cause les principes ergonomiques du système.
- Un système massivement multilingue doit bénéficier d’une interface entièrement orientée autour des fonctions de traduction. Or, un très grand nombre de sites réalisés sous SPIP sont soit en une seule langue, soit constitués d’articles qui ne sont pas des traductions les uns des autres. Le choix a donc été fait d’introduire le multilinguisme sans que la traduction soit l’orientation principale de l’interface.
- Si le choix de SPIP semble moins souple qu’avec un système massivement multilingue, il permet cependant, par de nombreux aspects, une plus grande liberté pour les webmestres. Ainsi de la possibilité d’avoir à la fois des articles qui sont des traductions les uns des autres et des articles qui sont dans des langues différentes mais sans lien entre eux ; des rubriques séparées pour les différentes langues et des rubriques regroupant plusieurs langues...
La langue du visiteur
Par défaut, un site multilingue sous SPIP ne s’adapte pas à la langue du visiteur (par exemple : afficher directement les articles en français aux visiteurs francophones, et les articles en anglais aux visiteurs anglophones). Il est possible, dans une certaine mesure, de réaliser de tels sites avec SPIP, mais l’utilisation de ces fonctionnalités n’est pas simple.
Il s’agit d’un choix volontaire.
— Avant tout, il est extrêmement rare que les utilisateurs configurent leurs butineurs pour indiquer leurs langues de prédilection. L’utilisateur est donc identifié dans la plupart des cas comme parlant uniquement la langue dans laquelle il a installé son butineur ; ainsi, puisqu’il n’a pas reconfiguré son butineur, il sera considéré comme ne parlant en général qu’une seule langue ; ou, pire, il utilisera un logiciel téléchargé en anglais, alors qu’il est francophone... Dans tous les cas, les sites reposant sur la détection automatique de la langue ne lui proposeront qu’une seule langue, ou même une langue qu’il ne parle pas.
— Il est fréquent qu’un visiteur comprenne plusieurs langues, mais avec des compétences différentes (couramment une langue, arrivant à lire lentement une autre langue...). Et, lors de sa visite, plutôt qu’un choix automatique, il préférera adapter sa lecture en fonction de ses compétences : ainsi, lire de préférence en français mais, pour les articles non traduits en français, se référer à l’anglais (et, faute d’anglais, à l’espagnol...). Les automatismes peinent à rendre ces usages.
— Pour le webmestre qui réalise l’interface du site, il est extrêmement complexe de créer une navigation reposant sur des automatismes de langue, sauf à rester dans le choix imposé par le logiciel ; à l’inverse, réaliser une interface, certes multilingue, mais dans laquelle c’est le visiteur qui adapte lui-même sa navigation en fonction des choix qui lui sont proposés, reste très abordable. L’écart de difficulté s’accentuant lorsque le webmestre veut, de plus, conserver une certaine souplesse dans la structuration de son site.
