Coucou,
je viens de mettre dans le CVS les éléments qui me paraissent nécessaires et
suffisants pour gérer le multilinguisme de manière à la fois relativement
simple et la plus souple possible.
Attention on repasse en version alpha : ne pas utiliser en prod 
Comment ça marche ?
Exemple 1
Je viens d'ajouter une fonctionnalité suggérée il y a longtemps par Antoine:
si je change la langue d'une rubrique (par exemple en persan), cela affecte
immédiatement ses sous-rubriques et les articles qu'elles contiennent.
MAIS la langue qu'on indique alors dans les enregistrements "dépendants"
n'est pas 'fa' (persan) mais '.fa' (persan par héritage).
Cela permet, d'une part, de changer de nouveau la rubrique mère et de voir
les sous-rubriques la suivre ; d'autre part, de fixer la langue d'un article
donné sans que ce réglage soit écrasé par un changement de langue de sa
rubrique mère (ou plus haut dans la hiérarchie).
Le #LANG, lui, est nettoyé de ce '.', mais pas la base de données
évidemment; pour faire une boucle des articles en persan "marqué" ou "par
héritage" il faut donc faire
<BOUCLE_persan(ARTICLES){lang==^\.?fa$}>
C'est pas encore parfait
-- Fil
Où peut-on télécharger cette version ???
merci d'avance
Coyote
Salut,
Quelques remarques.
- cette pile de langue séparée, ça ne sert à rien, le $contexte est lÃ
pour ça (et ça résoud en même temps le problème des <INCLURE>)
- [(#LANG|select)] devrait être implicite quand on entre dans une boucle,
pareil pour la réciproque
- les formulaires devraient s'afficher dans la langue courante et non
celle du site, en plus ça simplifie le code (sous un article en anglais,
le formulaire de pétition est en anglais ;-)).
a+
Antoine.
- cette pile de langue séparée, ça ne sert à rien, le $contexte est là
pour ça (et ça résoud en même temps le problème des <INCLURE>)
Je ne crois pas. Si tu as un site avec des articles en français et anglais,
tu peux vouloir faire une page d'accueil en français et une autre en
anglais. Sur la page en français toutes les dates sont en français, sur la
page en anglais toutes les dates sont en anglais. Ou alors, comme spip.net,
la date est dans la langue de l'article. C'est au choix.
- [(#LANG|select)] devrait être implicite quand on entre dans une boucle,
pareil pour la réciproque
Même réponse. Ca n'est implicite QUE lorsque tu ouvres une page article : ça
se règle sur la langue de l'article).
- les formulaires devraient s'afficher dans la langue courante et non
celle du site, en plus ça simplifie le code (sous un article en anglais,
le formulaire de pétition est en anglais ;-)).
C'est déjà le cas.
-- Fil
Je ne crois pas. Si tu as un site avec des articles en français et
anglais,
tu peux vouloir faire une page d'accueil en français et une autre en
anglais. Sur la page en français toutes les dates sont en français, sur la
page en anglais toutes les dates sont en anglais. Ou alors, comme
spip.net,
la date est dans la langue de l'article. C'est au choix.
Il faut un comportement par défaut raisonnable vu que personne ne
saura utiliser [(#LANG|select)] (c'est un truc de programmeurs, une pile).
A mon avis il est préférable par défaut d'avoir la langue de l'objet
courant (par contre il faudra virer le #LANG pour les auteurs, c'est
un réglage privé qui n'a pas à se retrouver dans le site public).
- les formulaires devraient s'afficher dans la langue courante et non
celle du site, en plus ça simplifie le code (sous un article en anglais,
le formulaire de pétition est en anglais ;-)).C'est déjà le cas.
Hum, j'ai peut-être mal compris le bout de code suivant, alors...
+ $'.$nom_var.' = "<"."?php
+ include_local(\"inc-formulaires.php3\");
+ lang_select(\"$spip_lang\");
+ formulaire_signature($contexte[id_article]);
+ lang_dselect();
+ ?".">";
> tu peux vouloir faire une page d'accueil en français et une autre en
> anglais. Sur la page en français toutes les dates sont en français, sur
> la page en anglais toutes les dates sont en anglais. Ou alors, comme
> spip.net, la date est dans la langue de l'article. C'est au choix.Il faut un comportement par défaut raisonnable vu que personne ne
saura utiliser [(#LANG|select)] (c'est un truc de programmeurs, une pile).
A mon avis il est préférable par défaut d'avoir la langue de l'objet
courant
Mh, je vois, oui... si c'est désactivable, on peut faire comme tu
l'envisages, c'est vrai que ce sera plus simple pour celui qui fera ses
squelettes. En gros, la boucle(ARTICLES) passe chaque article dans sa
langue; sauf si tu as une <boucle(ARTICLES){nolang}> (enfin, un truc comme
ça). Mais il faut absolument qu'on puisse activer ou désactiver ce
comportement au niveau du squelette.
Par ailleurs ça serait pas mal de pouvoir changer de langue sur d'autres
critères que le champ lang (cf. "langue_intelligente" pour un exemple, un
peu délirant); c'est une question de souplesse.
Autre problème que je vois avec ton approche : pour que les brèves et les
sites syndiqués changent de langue, il faudra aussi leur créer un champ
lang. J'avais plutôt fait une autre hypothèse : que la langue d'une brève ou
d'un site serait indiquée autrement (via un mot-clé ou via le secteur, par
exemple), ce qui suppose de passer par un truc compliqué genre
<boucle(MOTS){id_breve}{type=langue}> [(#TITRE|lang_select)] </boucle>
Mais bon, c'eest vrai que c'est plus compliqué pour l'utilisateur, et que
tout "languer" n'est pas compliqué à coder... j'y allais mollo, pour voir si
ça marcherait
(par contre il faudra virer le #LANG pour les auteurs, c'est
un réglage privé qui n'a pas à se retrouver dans le site public).
Il serait idiot d'avoir deux champs de langue par auteur, et ça peut être
utile d'indiquer dans l'espace public, sur la page auteur par exemple, la
langue de référence de chaque auteur.
Par contre, évidemment, on ne peut pas avoir, dans la boucle(AUTEURS) par
défaut, un changement de langue automatique, car si tu gères un site
monolingue avec des auteurs qui s'amusent à essayer les différentes langues
de l'interface, tu ne veux pas que ça se voie dans l'interface... Donc,
déjà, on a là un cas particulier : pour la boucle(AUTEURS), il faudra un
critère inverse du {nolang} des autres boucles. Ca risque de devenir
compliqué.
>> - les formulaires devraient s'afficher dans la langue courante et non
>> celle du site, en plus ça simplifie le code (sous un article en anglais,
>> le formulaire de pétition est en anglais ;-)).
>
> C'est déjà le cas.Hum, j'ai peut-être mal compris le bout de code suivant, alors...
+ $'.$nom_var.' = "<"."?php
+ include_local(\"inc-formulaires.php3\");
+ lang_select(\"$spip_lang\");
+ formulaire_signature($contexte[id_article]);
+ lang_dselect();
+ ?".">";
Oui, tu as mal compris
En fait la spip_lang c'est la langue courante, qui a été affectée par les
divers appels à lang_select() et lang_dselect(). Tu es obligé de la
mémoriser "en dur" dans le squelette, au niveau des appels inc-formulaires,
sans quoi la langue peut changer entre le moment où tu calcules la page et
celui où tu ne fais qu'appeler le cache (sans donc repasser par tous les
lang_select()). Je pense qu'avec une gestion de la langue par le contexte,
il faudra aussi faire un hack de ce type...
-- Fil
Correction :
En fait la spip_lang c'est la langue courante, qui a été affectée par les
divers appels à lang_select() et lang_dselect(). Tu es obligé de la
mémoriser "en dur" dans le squelette, au niveau des appels inc-formulaires,
sans quoi la langue peut changer entre le moment où tu calcules la page et
celui où tu ne fais qu'appeler le cache (sans donc repasser par tous les
lang_select()). Je pense qu'avec une gestion de la langue par le contexte,
il faudra aussi faire un hack de ce type...
Lire : "tu es obligé de la mémoriser 'en dur' dans le CACHE" (et pas "dans
le squelette").
-- Fil
Par ailleurs ça serait pas mal de pouvoir changer de langue sur d'autres
critères que le champ lang (cf. "langue_intelligente" pour un exemple, un
peu délirant); c'est une question de souplesse.
Oui, on peut garder le filtre |lang_select dans un coin pour ceux qui
veulent l'activer à la main avec les données de leur choix.
Autre problème que je vois avec ton approche : pour que les brèves et les
sites syndiqués changent de langue, il faudra aussi leur créer un champ
lang.
Je dirais plutôt qu'ils prennent la langue de la rubrique, et puis zou...
Après tout même pour les articles, je pense qu'il sera plus courant
que tous les articles d'une rubrique soient écrits dans la même langue
(pour la navigation c'est plus pratique).
Il serait idiot d'avoir deux champs de langue par auteur, et ça peut être
utile d'indiquer dans l'espace public, sur la page auteur par exemple, la
langue de référence de chaque auteur.
Ben, pourquoi pas mais ça n'a rien à voir avec la langue sélectionnée
dans l'espace privé, donc il faudrait bien deux champs séparés (en fait,
la langue sélectionnée dans l'espace privé devrait réintégrer les $prefs
;-)). Ou plus simplement, les auteurs qui le désirent mentionnent
simplement leur(s) langue(s) dans le champ "bio" ("prière de m'écrire
en français, ou à défaut en kréyol de Beltégeuse").
a+
Antoine.
Après tout même pour les articles, je pense qu'il sera plus
courant que tous les articles d'une rubrique soient écrits dans
la même langue (pour la navigation c'est plus pratique).
Plus courant, sans doute, mais pas nécessairement tout le temps ... cf
http://www.gasteroprod.com/ qui mélange articles en français et en anglais ...
-Nicolas
Oui, on peut garder le filtre |lang_select dans un coin pour ceux qui
veulent l'activer à la main avec les données de leur choix.
S'il suffit que le binzz qui ajuste la langue dans le parcours de la boucle
utilise lui-même lang_select() et lang_dselect() [* sauf si le critère
{nolang} est présent], ça ne devrait pas être trop lourd à programmer ?
(Je n'ai plus le temps de regarder ça, le programmer, tester et tout avant
de partir en vacances, cela dit...)
Je dirais plutôt qu'ils prennent la langue de la rubrique, et puis zou...
Après tout même pour les articles, je pense qu'il sera plus courant
que tous les articles d'une rubrique soient écrits dans la même langue
(pour la navigation c'est plus pratique).
Non. Tu peux très bien avoir un rubricage films/disques/livres avec des
sous-rubriques polars/sf/essais..., et puis chaque article (livre, film) est
dans une langue particulière. Donc c'est pas "zou", il faut avoir la
possibilité de spécifier la langue objet par objet (si le webmestre en
décide ainsi, cf. la config prévue dans la partie "multilingue" de la
configuration avancée).
D'autant qu'il est toujours possible, avec cette méthode, de ne jamais
activer le changement de langue dans l'espace privé, mais de faire un script
extérieur à SPIP qui règle lui-même la langue de chaque objet en fonction de
considération métaphysiques...
> Il serait idiot d'avoir deux champs de langue par auteur, et ça peut être
> utile d'indiquer dans l'espace public, sur la page auteur par exemple, la
> langue de référence de chaque auteur.Ben, pourquoi pas mais ça n'a rien à voir avec la langue sélectionnée
dans l'espace privé, donc il faudrait bien deux champs séparés (en fait,
la langue sélectionnée dans l'espace privé devrait réintégrer les $prefs
;-)). Ou plus simplement, les auteurs qui le désirent mentionnent
simplement leur(s) langue(s) dans le champ "bio" ("prière de m'écrire
en français, ou à défaut en kréyol de Beltégeuse").
Là encore, il faut laisser le soin au webmestre de décider s'il veut ajouter
ce champ aux auteurs, ou pas. Pour le Diplo par exemple, il serait très
pratique d'indiquer, pour chaque auteur, sa langue de référence. Ainsi on
pourrait indiquer, sur la fiche auteur permettant de lui écrire, "prière
d'écrire de préférence en anglais/espagnol..." ; ce sont des auteurs sans
login, qui ne vont donc pas toucher à l'interface
Mais d'un autre côté tu ne peux pas demander aux rédacteurs avec login de
régler deux fois leur langue, une fois pour leur navigation dans l'espace
privé, et une autre pour on-ne-sait-trop-quoi. Donc on peut décider qu'il
s'agit du même champ. Je comprends que ce ne sont pas deux infos de la même
nature, en théorie, mais en pratique ne vois pas quel problème ça pourrait
poser, et ça paraît tellement plus simple à tous points de vue.
Le seul truc idiot s'il y a un menu "Cet auteur est en... [menu de langue]",
c'est que les admins pourront s'amuser à aller se modifier les langues
d'interface les uns les autres, ouarf ouarf ; ça mettra de l'ambiance.
-- Fil
Non. Tu peux très bien avoir un rubricage films/disques/livres avec des
sous-rubriques polars/sf/essais..., et puis chaque article (livre, film)
est
dans une langue particulière. Donc c'est pas "zou", il faut avoir la
possibilité de spécifier la langue objet par objet (si le webmestre en
décide ainsi, cf. la config prévue dans la partie "multilingue" de la
configuration avancée).
Oui mais on parlait des objets autres que les articles. Les brèves et
les sites ne sont pas aussi souples que les articles, d'une manière
générale, donc autant ne pas compliquer.
D'autant qu'il est toujours possible, avec cette méthode, de ne jamais
activer le changement de langue dans l'espace privé, mais de faire un
script
extérieur à SPIP qui règle lui-même la langue de chaque objet en fonction
de
considération métaphysiques...
Hmmpf
Là encore, il faut laisser le soin au webmestre de décider s'il veut
ajouter
ce champ aux auteurs, ou pas.
Ben il y a justement le #EXTRA pour ça.
Par défaut je ne trouve pas ça utile du tout (je veux dire, pour la
majorité des sites SPIP y compris multilingues).
> Là encore, il faut laisser le soin au webmestre de décider s'il veut
> ajouter ce champ aux auteurs, ou pas.Ben il y a justement le #EXTRA pour ça.
Oui, enfin, avec #EXTRA tu n'auras pas non plus de gestion intégrée de la
langue.
Par défaut je ne trouve pas ça utile du tout (je veux dire, pour la
majorité des sites SPIP y compris multilingues).
Non, on est d'accord, il ne faut pas que ça soit "par défaut". Mais plutôt
que d'appeler un #EXTRA pour la langue (on peut faire ça si on veut, de
toutes façons), on peut toujours décider que la boucle(AUTEURS){lang_select}
sélectionne la langue de l'auteur (celle qu'il a réglé dans l'espace privé).
Ah bin non, je suis con, il suffit d'utiliser [(#LANG|lang_select)] si on
veut échapper au comportement alingual de la boucle AUTEURS...!
Disons, donc, qu'on ne propose pas de menu permettant à tout admin de
modifier la langue des autres auteurs, et que la boucle (auteurs) ne switche
pas de langue à chaque auteur ; on a alors ce qu'on veut, aussi bien toi que
moi, à condition de laisser la possibilité d'utiliser la balise #LANG sur
les objets "auteurs".
-- Fil
Autre problème que je vois avec ton approche : pour que les brèves
et les sites syndiqués changent de langue, il faudra aussi leur créer
un champ lang.
Pour les sites, c'est plus simple s'ils sont syndiqués puisqu'il y a alors bien
souvent une indication de langue ...
-Nicolas
Pour les sites, c'est plus simple s'ils sont syndiqués puisqu'il y a alors
bien souvent une indication de langue ...
Oui, mais souvent, elle est fausse: c'est codé en dur dans les fichiers
backend. Les webmestres n'y regardent pas trop de prêt, ne le change pas et
on se retrouve avec des sites syndiqués français dans la section anglaise.
D'ailleurs, dans le backend de SPIP, on pourra maintenant, si j'ai bien
compris, introduire une balise de langue SPIP au lieu de:
<language>fr-fr</language>
Ce qui est vraiment bien.
André Vincent
Moyennement pratique pour les sélections (les expressions réguliÚres, c'est du parfait chinois pour la plupart des gens, et c'est pas les docs disponibles en ligne qui peuvent aider).
PlutÎt que de faire du "fa" (origine) et du ".fa) (hérité), ne vaudrait-il mieux pas ajouter un champ caché dans la base (genre lang_heritee)? De cette façon on travaille de maniÚre transparente toujours avec le champ "lang", le systÚme bidouillant dans "lang_heritee" pour faire ses constructions.
A*
Je voulais remercier toute l'équipe de SPIP
qui a fait un superbe travail, intelligent et
sensible et qui a eu la gentillesse de le
mettre à la disposition des autres !
Amicalement. Blaise Rosnay