RSS 2.0 Petite synthèse sur le multilinguisme dans SPIP, faite lors de la SPIP-Party à Clermont Ferrand, le 11 novembre 2007.
Les slides de la présentation au format.pdf
- SPIP et le multilinguisme, clermont nov 2007
Introduction
A l’origine SPIP n’était pas multilingue. Il l’est devenu progressivement. C’est ce qui contribue à faire sa force en offrant une très grande souplesse, mais aussi ce qui peut dérouter, parfois, quand on ne connaît pas encore toutes les subtilités.
Cela s’est construit petit à petit. Dès la 1.5 on a eu les traductions de l’espace privé, puis l’on a pu commencer à créer des sites multilingue à partir de la 1.7, et le multilinguisme c’est développé surtout à partir de la 1.8 et les versions ultérieures.
Le multilinguisme dans SPIP
On peut activer le multilinguisme dans l’interface d’administration. Le site a une langue principale qui est la langue affectée par défaut à tous les éléments. On peut définir une langue pour chaque rubrique, qui s’appliquera à tous les éléments de cette rubrique ainsi qu’aux sous-rubriques. Un système de traduction permet de gérer la traduction d’un article. Chaque traduction est en fait un nouvel article qui est lié à l’original.
Le ou les multilingisme(s) ?
Il est plusieurs façons de considérer un site multilingue. Il n’y a pas une approche qui soit forcément meilleure qu’une autre, tout dépend de ce que l’on veut faire. On a pas toujours non plus le recul suffisant pour pouvoir définir la meilleur méthode, mais il conviendra de se poser les bonnes questions avant de se lancer dans l’aventure du multilinguisme .
Se poser les bonnes questions ?
Quelle sera l’organisation de son site ?
Par secteur ?
Cela simplifie, pas trop d’intervention spécifique sur les squelettes de bases, simplification pour les rédacteurs dans l’espace privé, mais en contrepartie, cela implique de reproduire manuellement l’arborescence si on veut le même rubriquage dans toutes les langues.
Ou mélangée pour permettre une navigation commune dans le site.
Le site sera t-il symétrique dans chaque langue ou asymétrique ?
Tous les articles seront ils traduits ou pas ?
Devrais-je n’afficher que les articles de langue sélectionnée et cloisonner, ou choisirais-je de montrer aussi les articles non traduits dans d’autres langues partant du principe que mon lecteur est polyglotte ? ...
Les trois principales approches
La séparation en secteur-langue : Cloisonnement des langues dans une rubrique à la racine.
La méthode dite de la Tour de Babel avec le mélange des langues.
Un mixte des deux premières solutions
La configuration des langues
Pour pouvoir autoriser diverses situations multilingues, le modèle mis enplace dans SPIP consiste à déterminer une langue pour chaque rubrique, chaque article, chaque brève.
Cette langue détermine le mode de correction typographique qui est appliqué aux textes dans l’espace publique et privé.
Cela détermine aussi l’affichage des dates, des formulaires de l’espace publique etc ...
Première étape : configuration des langues
Pour créer un site multilingue, certains réglages sont requis. En effet, dans la configuration livrée par défaut, SPIP reste monolingue, même si les squelettes de la dist sont internationalisés.
Seul l’administrateur de site peut les faire dans l’espace privé de SPIP.
Cliquer sur Configuration, dans le bandeau supérieur, puis sur la Gestion des langues.
Cliquer sur la gestion des langues.
Choisir la langue principale du site public parmi les très nombreuses langues possibles, dont certaines sont exotiques. Ce choix est indépendant du choix que chaque admin ou rédacteur peut faire dans l’espace privée quant à ses préférences linguistiques.
Choisir son charset, par défaut désormais depuis SPIP 1.9 c’est l’utf-8, l’alphabet universel, ce qui est une très bonne chose pour un site multilingue. Ca permet de disposer d’une plus grande richessetypographique et d’utiliser des langues orientales telles que l’arabe, le chinois etc ...
Cliquez sur le multilinguisme. Cochez les bonnes cases selon la structure multilingue que vous aurez retenue :
Activer le menu de langue sur les articles : oui/non
Activer le menu de langue sur lesrubriques : oui/non
Seulement pour lesrubriques situées à laracine : oui/non
Gérer les liens de traductions : oui/non
On peut choisir dans cette configuration avec quelle précision s’effectuera le réglage des langues.
SPIP propose donc trois niveaux d’interface différents pour choisir les langues affectées aux articles, aux brèves etc... par ordre croissant de complexité.
Par secteur, c’est-à-dire les rubriques à la racine de premier niveau. À chaque secteur du site correspond une langue modifiable par les administrateurs, qui concerne toutes les sous-rubriques, ainsi que les articles et les brèves qui se trouvent publiées dans ce secteur.
Ce réglage est le plus classique et le plus fréquemment utilisé, il répond à la plupart des besoins des sites multilingues tout en conservant une structure et une interface simple.
Par rubrique : de manière plus fine, avec ce réglage, on peut changer la langue pour chacune des rubriques du site, et 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 deux précédents choix, à savoir l’activation du menu de langue sur les rubriques et sur les secteurs. (On peut par exemple choisir la langue par rubrique mais appliquer des exceptions ici et là sur certains articles ...) Ce choix permet toutes les finesses imaginables, mais il faut veiller toutefois à ne pas produire un site avec une structure incompréhensible.
Configurer son site
En dernier choix enfin, on a la possibilité de gérer des liens de traductions entre les articles si on le désire. Ce système de traduction permet de gérer la traduction des articles dans les différentes langues, et chaque traduction est en fait un nouvel article lié à l’article original.
Nous verrons plus tard comment les gérer dans les boucles des squelettes avec notamment les critères {traductions} et {origine_traduction}.
On pourra noter au passage l’absence native de lien de traduction pour les rubriques, absence volontaire du à une volonté de cohérence. Absence qui paradoxalement permet aussi de donner à SPIP une grande flexibilité sans être dans un système multilingue rigide.
Nous en reparlerons plus tard et nous verrons les différentes solutions utilisées pour contourner cette absence.
Ensuite, dans la même section, activer seulement les langues que l’on désire utiliser pour le site public. Donc ne pas oublier de décocher les langues qui le sont pas défaut.
Les langues soulignées bénéficient d’une traduction complète de toutes les chaînes de langues de l’interface.
Pour les chaînes des langues pas encore traduites, c’est à dire les langues pas soulignées, elles seront remplacées par celle de la langue principale du site.
L’onglet fichier de langue permet de visualiser les chaînes de traductions utilisées aussi bien dans l’espace privé que public qui se trouvent dans le répertoire ecrire/lang.
On dispose de trois type fichiers de langue, disponibles dans chaques langues traduites :
ecrire_codelang.php
spip_codelangue.php pour les traductions de l’espace privée
public_codelangue.php : pour les traductions de la partie publique des squelettes.
Créer ses propres fichiers de langues
On peut aussi, lors de l’internationalisation de ses squelettes vouloir créer ses propres fichiers de langues, soit pour créer de nouvelles chaînes de traductions qui n’éxistent pas encore, soit surcharger celles qui existent. On les mets alors dans un fichier que l’on crée, local_codelangue_php (local_fr.php).
Pour ne pas être écrasé lors d’une mise à jour, on met ses fichiers de langue perso dans /squelettes/lang depuis la 1.9.2. (squelettes en 1.9, et parfois squelettes/lang et ecrire/lang en 1.8).
Comment se présente un fichier de langue
La construction est la suivante au début du fichier
<?php
$GLOBALS[$GLOBALS['idx_lang']] =
array(A la fin du fichier :
);
?>La partie qu’il faut enrichir soi-même consiste en plusieurs lignes de définitions, sur le modèle :
'code' => 'ce que je veux ici',
Les accents sont en entités html (é)
Les apostrophes sont précédées d’un antislash.
Chaque ligne de définition se termine par une virgule, sauf la dernière ligne. Pour des langues comme l’arabe, il faudra les coder en entités numériques (é)
Des outils pour les fichiers de langues
Trad-lang, qui sert à traduire SPIP avec l’équipe des traducteurs, mais assez complexe à mettre en œuvre.
Le plugin admin_lang disponible sur la zone. Permet de faire ses fichiers de langues directement depuis l’espace privée dans configuration, gestion des langues, et de gérer les différentes chaînes des langues retenues. Très simple d’utilisation et bien conçu.
Le plugin supporte différents types de caractères et d’alphabet. On peut même imaginer faire cohabiter deux types de caractère dans un même champ.
Par sécurité la première intervention sur un fichier de langue génère une sauvegarde.
Pour plus de détails sur admin-lang, cf http://www.ambafrance.org/spip.php?...
Liste des éléments SPIP liés au multilinguisme
Les critères
les balises
les filtres
les variables de personnalisation
Les critères
{lang} filtrer avec la langue de l’url
{lang ?} critère optionnel, pas pris en compte si pas passé dans le contexte
{lang=fr} {lang!=en} {lang_select} {!lang_select} ou
{lang_select=non} sert à conserver le contexte de langue de
l’article et non sa langue originale pour afficher correctement les multi...
{lang!=#ENV{lang}} {lang=#ENV{lang}}
{par langue} {!par lang}
{fusion lang}
{traduction} {origine traduction}
{id_trad=0} Les balises
#LANG
#LANG_DIR
#LANG_LEFT
#LANG_RIGHT
#MENU_LANG
#MENU_LANG_ECRIRE
(Bloc multi)Les filtres
|parametre_url{lang,#LANG}
|parametre_url{lang,#ENV{lang}}
|parametre_url{lang,'fr'})]
|traduire_nom_langue Les variables de personnalisation
$forcer-lang=true dans config/
Adapter ses squelettes
Ajouter les paramètres de langues qui ne sont pas là déjà, et affiner selon ses besoins spécifiques.
Penser à faire passer le paramètre de lang dans les inclure {lang} :<INCLURE{fond=inc-truc}{lang}><code> pour passer la langue du contexte. <code>{#ENV{lang}} devrait marcher aussi.
Pour les squelettes qui n’ont pas de langue propre, ne pas hésiter à faire des liens avec les paramètres de la langue souhaitée :
[(#URL_PAGE{plan}|parametre_url{lang, #LANG})]
[(#URL_MOT|parametre_url{lang, #LANG})] ... A quoi servent les chaînes de langues ?
Elles ne s’utilisent que dans les squelettes. Pas dans les champs #TEXTE ou #TITRE #DESCRIPTIF ... de l’espace privée.
Elles permettent de n’avoir qu’un seul jeu de squelettes pour toutes les langues du sites.
Ainsi, en fonction du contexte de langue, la chaîne <:plan_site:> dans un squelette affichera soit Plan de site si le contexte est en français, soit Site Map si le contexte de langue est en anglais.
Comment fonctionnent les chaînes de langues ?
Dans les squelettes, quand on utilise le code <:bonjour:> alors SPIP affiche la traduction de "bonjour" dans la langue idoine.
Cette langue est déterminée par SPIP de façon automatique en fonction de trois paramètres :
la variable lang=xx passée dans l’url
la langue de l’élément principal de la page article, rubrique, brève etc...
un cookie
Les blocs multilingues
Voici une autre alternative aux chaînes de langues pour gérer les éléments de textes dans les différentes langues, les balises multi.
Cette méthode fonctionne partout aussi bien dans les contenus (#TEXTE, #DESCRIPTIF etc...) que dans les squelettes.
<multi>[fr]télécharger[en]download</multi>
10. <multi> [fr]Rubrique un[en]Section one</multi>Fonctionnement :
Chaque bloc multi à traduire est analysé par SPIP pour la renvoyer ensuite dans la langue demandée suivant le contexte, ou la première version rencontrée si ce bloc n’est pas disponible dans la langue en cours.
Dans l’espace privée, les blocs multi sont signalés par un petit micro qui flotte à côté d’eux. Le “title” de l’image offre une infobulle qui indique les langues du bloc.
Les avantages :
Ce système est très souple. On peut les utiliser partout. Ils sont indexables par le moteur de recherche. Avec cette méthode,on peut remplir par exemple le Nom du site SPIP dans la configuration du site, ainsi que le descriptif du site, traduire les mots clés etc...
En effet, dans le cas d’un site multilingue avec arborescence unique, l’usage des balises <multi> est nécessaire pour traduire dans les différentes langues, les titres des rubriques, le titre du site, les textes de rubriques.
Le multilinguisme sur les articles s’effectuant, quant à lui, avec les fonctions de traduction d’article de SPIP.
Dans un site organisé en secteur langue, les <multi> peuvent être utile pour traduire les mots clés.
Les inconvénients :
On atteint vite les limites des champs multi dès qu’on a plus de trois langues. La saisie n’est pas forcément facile pour un rédacteur. On peut quand même utiliser le plugin Barretypographique-multilingue pour se faciliter la tache, même si, d’après l’auteur, le plugin aurait du mal avec beaucoup de langue.
Les url propres ne marchent pas quand le titre de la rubrique est en multi.Elle prend par défaut le multi de langue du site.
Apache vient au renfort du multilinguisme de SPIP
Si besoin, des squelettes séparés pour chaque langue. Un seul jeu de squelette internationalisé est sans doute préférable par rapport à la maintenance à faire sur un squelette unique plutôt que sur chaque squelette de chaque langue.
Mais cela peut être utile sur la sommaire.html ou dans certaines inclusions :
sommaire.html pour la langue par défaut du site ou bien toutes celles qui n’ont pas de squelette spécifique
sommaire.en.html pour l’anglais
sommaire.ar.html pour l’arabe ...
La méthode apache sera très utile pour la bannière du site ou des images spécifiques à une langue dans un squelette.
Exemple dans squelettes/images deux images, une pour chaque langue :
lang-fr.jpg
lang-en.jpg
Et dans le squelette :
<imgsrc=”#CHEMIN”{images/lang-#LANG.jpg} alt="" />
Trois attributs pour internationaliser une page html
“lang” (le langage) l’attribut s’écrit lang=”fr”, lang=”ar” ...
“dir” (la direction) l’attribut s’écrit dir=”ltr|rtl” ca définit la direction de base d’un texte, et de gérer les langues comme l’arabe, l’hébreux etc ...
“charset” (character set)
Trois attributs que l’on retrouve dans les squelettes
SPIP gère automatiquement ces trois attributs : dir, lang et charset. Il les définit de façon dynamique pour permettre une gestion multilingue native.
Ainsi dans la dist : <html dir="#LANG_DIR" lang="#LANG"> <meta http-equiv="Content-Type" content="text/html; charset=#CHARSET" /> <body dir=”#LANG_DIR”>
Encore un plus dans SPIP pour la gestion RTL des langues
Le filtre |direction_css <link rel="stylesheet" href="[(#CHEMIN{habillage.css}| direction_css)]" type="text/css" media="projection, screen, tv" />
Celui-ci sert à "inverser" une feuille de style dans le cas où l’on est dans le système d’écriture RTL (de droite à gauche) comme l’arabe, l’hébreu, le farsi ...
Le filtre |direction_css
Le filtre regarde d’abord la langue courante pour savoir si l’on est en RTL ou pas ;
Ensuite, s’il n’y a rien à faire, il renvoie le chemin qui lui a été passé. S’il faut inverser, il regarde d’abord si une feuille habillage_rtl.css existe dans le même répertoire où se trouve déjà habillage.css,et le cas échéant retourne le chemin de cette feuille.
Si habillage_rtl.css n’existe pas, il va lire la feuille habillage.css et va l’inverser automatiquement en remplaçant "left" par "right" et vice-versa.
Plus d’info ici
La balise #LANG
Cette balise renvoi la langue par défaut du site telle qu’elle a été précisée dans la configuration des langues de l’espace privée.
Dans le cas du multilinguisme, si le menu de langue sur les articles ou sur sur les rubriques a été activé, cette balise aura un comportement complexe :
Pour les articles, rubriques, elle renverra la langue définie lors de la création de ceux-ci.
Pour les autres squelettes, sommaire.html, auteurs.html, plan.html etc ... elle affichera la langue par défaut du site sauf si une variable “lang=xx” est passée dans l’url.
L’héritage de la langue : une histoire de contexte.
Dans un squelette, on regarde d’abord s’il y a un contexte de langue dans la boucle englobante, et si oui, on prend cette valeur de langue.
Sinon, on remonte les boucles englobantes jusqu’à ce qu’on trouve une valeur.
Si on a toujours rien trouvé, alors on prend la valeur passée dans l’url (langue par défaut du site si rien n’est spécifié), ou bien encore celle d’une variable de langue passée dans l’url soit par le biais d’un menu de langue #MENU_LANG par exemple ou une autre méthode de switch, soit par un lien de type :
[(#URL_TRUC|parametre_url{lang,#ENV{lang}})]
[(#URL_TRUC|parametre_url{lang,'en'})]etc...
Le choix de la langue de navigation ?
Automatique en fonction des préférences du navigateur Un choix du visiteur grâce à un menu de langue ou une méthode de switch.
Automatique en fonction de la langue préférée du navigateur.
Il n’est en effet pas très utile qu’un visiteur anglophone arrive sur une page sommaire.html en français, pour qu’il rebascule ensuite sur la langue qu’il désire. Autant le mettre tout de suite dans de bonnes conditions et respecter le choix de langue de son navigateur.
Le choix de la langue de navigation ?
SPIP permet de proposer aux utilisateurs de choisir la langue de navigation.
Par défaut SPIP utilise la langue du contexte : Si on est dans une rubrique en français,la langue de la navigation est en français.Si on visualise un article en anglais la langue est donc l’anglais.
Mais l’on peut décider de laisser le visiteur choisir sa langue de navigation et faire que, d’où qu’il se trouve sur le site, il voit l’interface et les constantes affichées dans la langue qu’il a choisi,indépendamment du contexte de langue dans lequel il se trouve avec la variable($forcer_lang=true)
Une approche : une langue par secteur au contenu très différent
Isoler les langues afin de ne pas dérouter le visiteur.
Ces secteurs de langues (rubriques mères à la racine) sont divisées en sous-rubriques et la structure du site est différente d’une langue à l’autre.
Tout cela parce le contenu de chaque langue est très différent. Dans ce type de site, il y a donc une navigation hiérarchique par langue.
Arriver sur la bonne langue selon la langue préférée du visiteur
Dans Firefox, par exemple, cela se règle dans les préférences du navigateur, dans l’onglet Général/Langues/Choix de langue préférée pour l’affichage des pages.
Sinon cela se fait par défaut lors de l’installation des navigateurs en fonction de la langue du système d’exploitation et de la langue du navigateur.
On peut court-circuiter la page sommaire.html en s’en servant pour les redirections du bon secteur de langue en fonction de la langue préférée.
Il faudra aussi faire passer les cookies de langues,puisqu’on n ’utilise pas dans cette méthode le basculement des langues par l’intermédiaire du [(#MENU_LANG)].
L’intérêt de mettre en place ces cookies, c’est de par exemple afficher le plan.html ou les résultatsde la recherche.html dans la bonne langue sans avoir à faire passer les paramètres de langue dans les url, en dehors des rubriques et secteurs où les langues sont définies.
Si la langue préférée est le français, on renvoie vers la rubrique secteur id=1.
Si la langue préférée est l’anglais, on renvoie vers la rubrique secteur id= 2.
Si aucune de ses deux langues n’est sélectionnée, on renvoie sur la langue du site par défaut.
Pour le code voir l’article sur spipzine
Ou bien utiliser le plugin langue préférée
Cy_altern propose aussi un petit script pour mettre en place un transfert automatique vers la langue du navigateur. cf http://www.spip-contrib.net/Multili...
Le modèle alternatives
Avec les squelettes alternatives, deux organisations de rubriques sont possibles.
Une rubrique racine par langue
Créer à la racine une rubrique par langue en leur donnant la langue appropriée et y placer tous les articles, brèves sites dans cette langue (Ex Français, English, Espanol)
Plusieurs rubriques racines par langue
Créer à la racine autant de rubriques que désiré en leur donnant la langue appropriée et en les numérotant pour les ordonner. (Ex 110. Présentation 120.Actualités
210.About us. 220. News)
Cette deuxième options est plus souple que la première, beaucoup plus rigide.
Quand on affiche une page dans une langue, tout dans cette page est traduit dans la langue séléctionné. Le site se comporte comme si on avait un site pour chaque langue (exceptions pour le plan de site et le backend).
La page d’accueil ne présente que lesrubriques, articles, brèves sites de la langue sélectionnée. Langue du site par défaut lors de la première visite, changeable par un menu de langue qui renvoie sur la homepage.
L’accès à un article, à une rubrique ou à une brève dans une langue provoque aussi un changement de langue pour tout le site. (cookie valable pour tout le site tant que ne rebascule pas vers une autre langue)
Le menu déroulant des rubriques est toujours contextuel à la langue en cours et ne liste que les rubriques de la langue en cours.
Les articles disent s’il existe un lien de traduction, si ce lien a été établi lors de la rédaction de l’article.
Alternatives est donc à l’opposé des sites Tour de Babel que nous développerons tout à l’heure.
Alternatives conseille de restreindre l’attribution des langues aux rubriques racines seulement, et de l’interdire aux sous-rubriques ainsi qu’aux articles pour éviter toute confusion et se garder de l’effet Tour de Babel. (Conception liée au Quebec, loi contre l’envahissement de culture dominantes, dans un contexte ou la diversité culturelle est menacée. Idem pour un contexte belge...)
D’où parti pris de toujours associé un contenu dans une langue particulière à uncontexte (interface) dans la même langue.
Multilinguisme en forçant la langue
Cette méthode multilingue n’était pas au départ celle envisagée par les concepteurs de SPIP, mais cette façon de faire a aussi une certaine logique et cohérence.
Techniquement, cela a pour effet :
de désactiver la recherche du squelette en fonction de la langue de l’objet.
de désactiver le critère {lang_select} automatique sur les objets classiques (articles, brèves, rubriques etc ... )
Pour la langue par défaut du site, cela a pour effet d’activer le contexte [lang] comme si lang=xx était passé dans l’url.
Du coup, les blocs multi s’affichent toujours dans la langue demandée par le visiteur.
Les <:chaines:> sont toutes dans la langue du visiteur, et les dates aussi ...
Cette langue est indiquée dans toutes les urls des pages (sauf si c’est la langue par défaut du site)
Les méthodes de switch des langues
#MENU-LANG
Balise à insérer dans le squelette, qui appelle le formulaire menu_lang.html. Les langues apparaissent alors sous forme de menu déroulant, qui permet au visiteur d’obtenir la page en cours dans la langue choisie.
La liste des langues du menu déroulant correspond aux langues cochées dans la configuration du site. En principe pas besoin de cette balise sur un siteen secteur de langue, puisque cette méthode reste sur la page en cours mais traduit l’interface dans la langue choisie.
Utile en revanche dans les sites multilingues avec la méthode du (forcer lang true) vue plus haut, et une seule hiérarchie de rubrique en bloc multi, où le choix de langues se fait sur les articles et non sur les rubriques.
#MENU-LANG à plat
Le code traîne sur la zone, garde les mêmes fonctionnalités que le précédent mais permet d’afficher le code des langues sans menu déroulant, mais les unes à côté des autres. Exemple :EN FRAR ES
Notons le pendant pour les langues de l’espace privée, présent sur login.html, #MENU_LANG_ECRIRE
Les méthodes de switch des langues et des menus de navigation
Le menu langue à plat de Natalia sur contrib à la particularité de ne pas proposer de lien sur la langue en cours.
Il faut mettre un bout de code dans mes fonctions.php du répertoire squelette, on peut mettre le code langue, ou bien demander à traduire le nom des langues (filtre traduire_nom_langue) et appeler ce filtre dans les squelettes de la manière suivante :
[(#CONGIG{langues_utilisees}|url_lang)]
ENAR FR ES Le switch de langue du squelette alternatives
La méthode de switch chez alternatives repose sur une boucle langue. L’auteur dit que ca fonctionnemieux avec forcer lang true.
Si le site publie dans plus d’une langue, le menu affiche toutes les langues utilisées seulement.
La langue du contexte est mise en emphase forte, sans lien.
Cliquer sur une autre langue du site, renvoie vers lapage d’accueil et change le cookie de langue. La mise en forme et les couleurs du menu est contrôlée dans une feuille de style qu’on peut donc personnaliser à souhaît.
http://zone.spip.org/trac/spip-zone...
Explication de la boucle alternatives
On affiche d’abord la langue du contexte avec #LANG|traduire_nom de langue, sans lien dessus et en emphase avec stong.
Ensuite on liste les langues des rubriques racines {par langue} du site par le biais d’une boucle rubrique, sans prendre en compte la langue du contexte avec le critère {lang! =#ENV{lang)}.
On l’affiche en traduisant son nom, et on met un lien avec un cookie de langue qui renvoie sur la page d’accueil. Le cookie sera utile pour les pages comme plan.html, recheche.html qui n’ont pas de langues.
On pourrait très bien décider de renvoyer sur la page en cours en remplaçant #URL_SITE_SPIP par #SELF.
On pourrait très bien remplacer la boucle rubrique (menu de langue sur les rubriques/secteurs) par une boucle article.
La requête générée par la boucle d’Alternative utilise en fait le champ « lang » qui est unchamp indexé dans les tables MySQL. Laconsommation est donc assez faible. Cependant, ce calcul a déjà été fait par SPIP (via la fonction calculer_langues_utilisees) et donc on consomme quelques ressources inutiles.
La méthode de Fil plus économe
Pour ne pas parcourir l’ensemble l’ensemble des rubriques ou des articles lors de l’appel à un menu de langue, Fil propose d’utiliser un critère apparu récemment {fusion lang}.
Son menu renvoie lui aussi sur la sommaire, mais là encore libre à nous de mettre un #SELF dans l’url si on veut renvoyer sur la page en cours.
{fusion lang}, c’est un GROUP by lang, donc ca ne sort qu’un seul article dans chaque langue.C’est donc plus efficace, surtout sur un site qui aurait beaucoup d’article.
Pas de lien sur la langue en cours. Class on dessus.
Fil a peaufiné la méthode sur SPIP_EN en alliant la {fusionlang} et les cookies, avec une syntaxe bien plus propre que la méthode cookie du squelette alternative.
Cf http://article.gmane.org/gmane.comp...
Si on veut non pas renvoyer sur la page en cours (cas du forcer langue true unisecteur) mais sur la page d’accueil pour les sites en rubrique ou secteur langue, il suffit alors de remplacer le
<?php
echo urlencode(self()); ?> par #URL_SITE_SPIPPour les cas de figure où l’on ne veut pas séléctionner les langues avec une boucle, mais manuellement, pour utiliser des images de code langue en guise de lien, ou autre, voici ce que Fil propose :
La méthode spip.net
Un secteur par langue
Sur la home page, on liste les rubriques racine, on affiche la langue en la traduisant de cette rubrique racine, et on fait un lien sur la rubrique langue.
La rubrique a une langue, donc pas besoin de faire passer des paramètres de langue dans l’url.
La méthode de Kent1
Cf http://www.spip-contrib.net/MenuLan...
Méthode pour SPIP 2 uniquement. Parfait pour deux langues. Plus problématique au-delà
[(#URL_ACTION{'converser'}|parametre_url{var_lang,[(#ENV{lang}|=={fr}|?{'en','fr'})]}|parametre_url{redirect,#SELF})]
cf http://www.annelauremaison.com/sque...
Les traductions des articles
le critère {origine_traduction} dans une boucle article permet de sélectionner l’article d’origine d’une traduction. Seuls les articles originaux seront affichés.
le critère traduction permet de sélectionner les articles qui ont ou sont une traduction.
L’ajout du critère exclus exclut du résultat l’article déjà affiché.
Un exemple de boucle de traduction :
Explications : {traduction} renvoie les traductions d’un article donné. Il faut donc déjà être à l’intérieur d’une autre boucle (ARTICLES) pour que le critère traduction fonctionne.
Avec {traduction} et {origine_traduction} dans une boucle article, on peut aussi récupérer le #LOGO de l’article, ou les #DOCUMENTS etc ... Il peut être en effet fastidieux de les dupliquer pour chaque traduction.
Pour les “title” et les “alt”, les titres et les descriptifs, on pourra utilisera les champ multi. Il faudra penser à mettre un {! lang_select} sur la boucle car l’article a toujours une langue.
Le modèle article_traduction.html
SPIP fournit un modèle article_traductions.html
Il affiche les traductions disponibles d’un article.
La langue de l’article courant s’affiche en gras, sans lien.
Le lien <a rel="alternate" hreflang="xx" ...> indique qu’il s’agit d’une traduction (version alternative dans la langue xx)
Pour inclure le modèle dans le squelette article
#MODELE{article_traductions}
ou dans un incure du squelette article
#MODELE{article_traductions}{lang} {id=#ENV{id_article}}
L’absence native de traduction des rubriques
Lier des rubriques entre elles, ne concerne essentiellement que les types de sites multilingues qui sont intégralement traduit.
Ces sites conçoivent le multilinguisme en dupliquant le plan des rubriques de la langue principale dans les secteurs des autres langues.
Ca devient alors tentant et censé, dans cette optique, d’afficher à l’utilisateur une liste de liens vers les autres langues.
La plupart des sites multilingues ne fonctionnent pas ainsi, les articles sont traduits au fur et à mesure ou pas. Chaque langue vit sa vie propre.
Selon Arno* cette absence de lien de traduction dans SPIP est volontaire. Ce n’est pas une limitation liée a des choix techniques mais à des choix d’ergonomie et de logique de construction des sites.
La méthode des mots clés sur les rubriques
Méthode utilisée par Paolo.
http://www.taize.ch/demos.
Structure prédéfinie : deux niveaux de rubriques,les secteurs langues, puis les rubriques dedeuxième niveaux, dits thèmes ou chapitres du site.
Soit groupe mot : chapitre
Mot clé : chapitre sénégal, Note SPIP, autres
On rattache a chaque mot clé les sous-rubriques de chaque langue. Le mot clé a donc les 4 sous rubriques des quatres langues (+ la sous rubrique shared)
La méthode d’Arno* sur Paris Beyrouth
Méthode basée sur la numérotation identiques des rubriques de chaque langue et d’un filtre. _http://www.paris-beyrouth.org/Des-l...
La méthode boucle SPIP de Fil et Mortimer sur contrib.
Supposant que les traductions des rubriques sont les rubriques qui contiennent les traductions des articles de cette rubrique, ils proposent de faire une boucle qui trouve ces rubriques qui contiennent les traductions de cette rubrique.
En fait il y aurait même encore plus simple
D’après Paolo, il suffirait d’ajouter un champ id_trad sur la table spip_rubrique. D’après ses tests, il semblerait que le critère {traduction} marche sans rien faire d’autre.
Comme disait Fil, il faudrait “juste” faire l’interface des liens dans l’espace privé. Mais se repose alors les questions sur d’ergonomie et de logique des sites.
Cf à ce sujet la réponse édifiante d’Arno sur son forum
Problème d’ergonomie : Supposons que l’ on active à la fois les liens sur les articles et sur les rubriques
Est-ce qu’on doit autoriser des liens entre articles de rubriques qui ne sont pas elles-même liées ?
Si on dit Oui
Solution de facilité pour le développement système de lien un peu complexe ou plus simple.
Si on dit Non
Parce ce qu’un site qui autoriserait des liens entre articles de rubriques qui ne sont pas elles-même liées aurait rapidement de gros problèmes structurels et des sites incohérents.
Citons Arno* :
“SPIP ne gère pas le multilinguisme au niveaux des éléments eux-mêmes : on a pas une rubrique multilingue elle-même, et on a pas d’article lui même multilingue.
A la place on a plusieurs articles dans différente langue, reliées par un lien indiquant la traduction.”
Ca introduit des difficultés de cohérence des sites. En même temps ca autorise des sites multilingues avec des structures différentes dans chaque langue, et du contenu pas forcément traduit.
Donc une très grand liberté plutôt qu’une rigidité figée
Cf l’article de Dani sur contrib, et ses boucles
Les boucles présentées ont été conçues pour un site multilingue, mais sans multilinguismes tructuré a priori. Les traductions et articles en différentes langues peuvent être un peu partout. Plutôt tour de Babel, donc.
Si l’article n’est pas dans la langue de préférence, et comme on pense que notrevisiteur est un peu polyglotte, alors on montre la langue de référence de l’article.
Cf aussi l’article de Kent1, Multilinguisme non structuré
Une langue principale dans laquelle existe tous les articles
Un processus de traduction anarchique : tous les articles ne sont pas traduits, certains sont dans toutes les langues, d’autres ne sont traduits que dans certaines langues.
Navigation basée sur des rubriques sous rubriques qui peuvent n’avoir qu’un article et ses éventuelles traductions ou plusieurs articles fondamentalement différents.
On pourra par exemple chercher tous les articles d’une rubrique
Puis, pour chaque article, on vérifiera s’il y a une traduction dans la langue ;
si oui on l’affiche.
Si non, on affiche l’article d’origine.
Boucle que propose Cyril
<B_chaque_article>
[(#REM) Pour chacun des articles de la rubrique... ]
<BOUCLE_chaque_article(ARTICLES){id_rubrique}>
[(#REM) ... on regarde s'il existe une trad dans la langue demandée]
<BOUCLE_article_dans_la_langue(ARTICLES){traduction}{lang=#ENV{lang}}{doublons}>
[<h3 class="#EDIT{titre}"><a href="#URL_ARTICLE" title="[(#TITRE|supprimer_numero)]">(#TITRE|supprimer_numero)</a></h3>]
</BOUCLE_article_dans_la_langue>
</B_article_dans_la_langue>
[(#REM) Sinon, on affiche l'article d'origine ]
<BOUCLE_article_origine(ARTICLES){id_article}{origine_traduction}{doublons}>
[<h3 class="#EDIT{titre}" style="font-style:italic"><a href="#URL_ARTICLE" title="[(#TITRE|supprimer_numero)]">(#TITRE|supprimer_numero)</a></h3>]
</BOUCLE_article_origine>
<//B_article_dans_la_langue>
</BOUCLE_chaque_article>Ou celles de Kent1, un poil plus complexe http://www.spip-contrib.net/Multili...
Conclusion
Une très grande souplesse de SPIP qui permet d’envisager toutes les formes de multilinguismes souhaitées ...
Le multilinguisme en soit reste une chose complexe, avec une dimension linguistique, culturelle, commerciale, ethique etc ... autant de dimensions qui conditionne et influence les choix dans la réalisation d’un site multilingue.
cf le poste de tontonBP et l’article multilinguisme : arme efficace mais lourde à manier.
Vidéo de la présentation du multilinguisme dans SPIP à Clermont
Slides
- SPIP et le multilinguisme, clermont nov 2007