> 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