guiderdoni.net

Bloc notes : spip, css, xhtml, web, standards, mac ...

Accueil > Spip > SPIP et le multilinguisme

Articles de cette rubrique

Articles

publie le samedi 19 juillet 2008 par Alexandra

SPIP et le multilinguisme

Petite synthèse sur le multilinguisme dans SPIP

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 ...

JPEG

- Cliquez sur le multilinguisme. Cochez les bonnes cases selon la structure multilingue que vous aurez retenue :

JPEG

- 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.

JPEG

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 (&eacute;)
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

On peut faire des filtres de test sur la langue :

[(#LANG|=={fr}|oui) ceci est du francais )]
[(#LANG|=={fr}|non) This is english )]
[(#LANG|=={ar}|?{#LOGO_SITE_SPIP_SURVOL,#LOGO_SITE_SPIP_NORMAL})]

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 :
<img src=”#CHEMIN”{images/lang-#LANG.jpg} alt="" />

Pour un logo dans chaque langue, on pourra aussi utiliser les multi :

<img src='IMG/png/<multi>MyLogo[fr]MonLogo</multi>.png' />

On pourra aussi utiliser une chaîne de langue pour un logo :
<:logo_of_my_site:>
et dans le fichier de langue correspondant, squelettes/lang/local_en.php :

ou si deux langues utiliser le logo normal pour la langue 1 et le logo de survol pour la langue 2

[(#LANG|=={"en"}|?{
#LOGO_SITE_SPIP_SURVOL
,
#LOGO_SITE_SPIP_NORMAL
})]

Le code langue, formé de deux lettres, correspond à de l’ ISO 639-2. Pour obtenir une liste complète des codes de langues, se référer à cette url http://www.loc.gov/standards/iso639-2/php/code_list.php. ( On utilisera plutôt des codes de langues pour l’internationalisation plutôt que des drapeaux, les langues n’étant en aucune manière liée à un pays).

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...

L’essentiel est de bien comprendre la différence entre #LANG (qui affiche la langue de l’objet SPIP s’il en a une ou sinon la langue par défaut du site) et #ENV{lang} qui affiche la langue de l’environnement (celle en paramètre dans l’URL par exemple). Il est assez subtil de savoir quand utiliser l’un ou l’autre. Le critère lang va se référer à l’un ou l’autre selon le contexte.

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)

Une révision importante de Fil 14554 (branche "dev" septembre 2009) apporte quelques modifications sur les multi dans les rubriques, au niveau de la gestion du multilinguisme dans les squelettes

L’idée est de permettre d’avoir des rubriques multilingues. Le principe est le même qu’avant, a une exception : si le titre de l’objet (rubrique, article, breve) contient un bloc multi, la langue n’est plus forcee sur cet objet.

Pour prendre un exemple, si j’ai l’arborescence suivante :

* racine
\-- <multi>rubrique [en]section</multi>
  \--- <multi>sous-rubrique [en]subsection</multi>
      \---  article 1 [en anglais]
        |-  article 2 [en français]

quand j’afficherai l’article 1, le fil d’ariane sera "section> subsection"
quand j’afficherai l’article 2, le fil d’ariane sera "rubrique > sous-rubrique"

Attention il faut que tous les titres des rubriques de l’arbre soient multi, le premier titre non multi sélectionnant (logiquement) sa langue pour la suite du fil d’ariane.
Si le titre ne se traduit pas (exemple : 2009), on peut l’écrire ainsi : "2009".

Ca devrait permettre de se passer du casse-tete de

$forcer_lang

dans la plupart des cas

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.

La boucle langue de Fil

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_SPIP

Pour 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...

b_b utilise aussi converser dans sa boucle de switch de langue :

On peut en SPIP 2 utiliser aussi #URL_ACTION_AUTEUR :

J’emprunte cette boucle à kent1 et à potter 64

Et en plus développé :

Explications :
si on es sur un article il récupère la traduction s’il y a une, sinon il reste sur #SELF , et il le passe dans le redirect tout en changeant la langue

kent1 a proposé également sur IRC un menu langue plat qui redirige vers la traduction de l’article si elle existe ... sinon sur l’article en cours mais en ayant changé de langue pour l’interface en multi :

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.

Bruno Bergot, dit b_b propose la boucle suivante pour récupérer le logo d’article d’origine. Notons qu’il convient d’utiliser les deux critères {traduction}{origine_traduction} pour que cela fonctionne :

Récupérer automatiquement les documents joints de la traduction

- Une boucle article englobante
- Une boucle documents avec {id_article=#ID_TRAD

Marcimat quant à lui propose la boucle suivante :

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}}

Erational a par ailleurs judicieusement trouvé une syntaxe extraite du core :

[(#TITRE|extraire_trad{#env{lang}})]

cf http://doc.spip.org/@extraire_trad

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.

titre documents joints

SPIP et le multilinguisme, clermont nov 2007 SPIP et le multilinguisme, clermont nov 2007 PDF 2.3 Mo

Forum

Répondre à cet article

1 commentaire

SPIP et le multilinguisme

Alexandra,

Super article qui répond à toutes mes interrogations !

Merci beaucoup et félicitations !
 :-)

11 juillet 2011, par Jean-Jean - repondre message
2005-2017 - Contenu en GPL http://www.guiderdoni.net - Site réalisé avec SPIP 
rechercher - plan du site - prive - alexandra.guiderdoni@gmail.com
CSS - XHTML - squelette