La deuxième page affiche "erreur sur le site" ; en tant qu'admin tu dois
pouvoir lire cette erreur ; par ailleurs pourquoi est-ce que la page
article82 ne fonctionne pas, alorss que, par exemple, http://www.taize.ch/spip18/hr_article607.html a l'air correct ?
Ne change pas tes squelettes, je pense que c'est le bug multilingue qui
est
revenu dans la 1.8b1. Je vais regarder ce qui se passe
Merci !
Pour comprendre ces squelettes, cela peut aider de savoir que mon principe
est le suivant :
- il y a un secteur dans chaque langue avec des articles (certains liés par
des liens de traduction). Chaque secteur a 9 sous-rubriques. Ces "chapitres"
s'affichent en permanence à travers le site juste en dessous de la bannière
orange.
- en plus il y a un secteur (il se trouve qu'il a le numéro 586) avec des
articles "partagés". Ce secteur possède les mêmes 9 sous-rubriques. La
langue de ce secteur est anglais aui est aussi la langue par défaut du site.
- A cause du manque des liens de traduction des rubriques, chacun de ces 9
chapîtres est marqué avec un mot-clé à travers tous les secteurs.
Quand on est "dans" un chapitre le squelette cherche à afficher un menu à
gauche de la manière suivante:
1. Montrer l'arboresence des articles dans cette langue dans ce chapitre.
2. Ensuite chercher si dans ce chapitre il y a aussi des articles dans le
secteur 586.
3. Si oui, on teste chacun de ces articles, avec les liens de traduction,
pour voir si une traduction dans la langue en cours existe. Si oui, pas la
peine de l'afficher. Mais dans le cas contraire l'article est ajouté au
menu.
Quand le visiteur clique sur un de ces articles "partagés", cela devient
plus compliqué. Il veut garder la langue en cours mais juste regarder
l'article partagé. Pour pouvoir faire cela, j'ai choisi dans ce cas de
passer lang=xx dans l'URL.
Le problème qu'on voit avec mes squelettes sous 1.8 se produit dans le cas
où l'article en cours est dans ce secteur partagé (no. 586). On voit le même
chose avec un autre squelette: http://www.taize.ch/spip/en_article260.html?lang=it (affiche bien)
Correct - oui. (sauf que l'admin hr ne comprends pas encore comment mettre
les chiffres devant le titres
Les deux articles utilisent le même squelette (t_artnorm.html). Seulement
hr_article607.html est "natif" au secteur croate, tandis que
en_article82.html?lang=hr est un article dans le secteur 586, qui contient
les articles à afficher dans toutes les langues, le lang=hr dans l'URL doit
être pris par le squelette pour mettre les menus et d'autres textes (même
parfois le titre de l'article - avec l'usage de <multi>) en croate.
Alors le deuxième article passe par les boucles dans le squelette qui
testent pour {id_secteur=586}.
Utilises-tu $forcer_lang ?
Non, pas du tout. Mais un peu de {!lang_select} dans certaines boucles.
Je crois qu'il faut distinguer deux différences de comportement :
- la première, c'est que lang=nl ne modifie pas la langue de la page ; ça,
c'est une modification normale, et tu peux rattraper le coup en mettant
dans le fichier d'appel article.php3 une ligne du genre
if ($lang) $forcer_lang = true;
Mais il est apparemment appelé autant de fois qu'il y a de langues !
Peux-tu ajouter (sur les deux sites !) des balises #ID_MOT et #ID_RUBRIQUE à
l'intérieur de la boucle _kword2 et _id, respectivement, de manière à
savoir laquelle des deux "bégaie" ?
Là où tu as <BOUCLE_kword2(MOTS){id_rubrique}{type=SectionLogo}>, ajoute,
juste après : <!-- _kword2 #ID_MOT -->
de même dans la boucle _id ajoute <!-- _id #ID_RUBRIQUE -->
(Autrement dit : sélectionner la bonne rubrique, puis appeler le menu, au
lieu d'appeler le menu pour chaque rubrique et d'espérer que le menu ne
s'affiche que s'il est appelé avec la bonne langue en paramètre)
car l'INCLURE a aussi besoin d'avoir {lang} passé dans l'appel, il semble.
Avec la ligne dans article.php3 que tu suggères, cela améliore les choses
sensiblement. Je pense qu'il y a encore des choses tordues. Je vais pouvoir
regarder de plus près, changer les autres squelettes et faire des tests,
lundi après-midi.
OK, mais si je l'enlève, comme je l'ai fait il y a quelque temps, la langue
(nl) n'est plus passée à l'inclure et le menu horizontal est en anglais, au
lieu d'être en néerlandais.
J'ai essayé plusieurs choses pour passer la langue, mais ne vois pas du tout
comment le faire.
J'ai ajouté les commentaires que tu suggérais hier dans les boucles.
<!-- Article is shared; lang = nl ; forcer_lang = 1 -->
<!-- _checkshared; lang = en ; forcer_lang = 1 -->
<!-- _main2; lang = en ; forcer_lang = 1 -->
<!-- _kword2 17; lang = en ; forcer_lang = 1 -->
<!-- _id Rubrique: 44 ; lang = en ; forcer_lang = 1 -->
Ce que je ne comprends pas, c'est pourquoi est-ce que la boucle
_checkshared1 change la valeur de #LANG ?
Il y a et $forcer_lang=true et {!lang_select} pour l'empêcher d'agir de
cette façon.
Est-ce un bug, ou y a-t-il quelque chose qui se passe que je ne comprends
pas ?
Ce que je ne comprends pas, c'est pourquoi est-ce que la boucle
_checkshared1 change la valeur de #LANG ?
Il y a et $forcer_lang=true et {!lang_select} pour l'empêcher d'agir de
cette façon.
Oui, mais l'idée est que *même si tu ne veux pas modifier la langue de
travail de SPIP*, #LANG représente toujours la langue de l'objet... et
{lang} correspond à la langue de l'objet. A mon avis c'est plus sain comme
ça, mais effectivement ça fait planter ton exemple.
Il va falloir trouver une astuce et modifier les squelettes, ou inventer un
nouveau critère d'inclusion. Mais ça demande un peu de réflexion.
#LANG représente toujours la langue de l'objet... et {lang} correspond à
la langue de l'objet.
C'est sûr que j'aimerais un critère qui répresente une langue sur lequel
j'ai plus de prise. Car je ne sais pas comment je vais arriver au bout
sinon...
Il va falloir trouver une astuce et modifier les squelettes,
Je promets de continuer à réfléchir !
ou inventer un nouveau critère d'inclusion. Mais ça demande un peu de
réflexion.
l'idée est que *même si tu ne veux pas modifier la langue de
travail de SPIP*, #LANG représente toujours la langue de l'objet.
Je vise à l'aveuglette : cette "langue de travail de Spip" - Spip doit le
connaître quelque part.
Et si elle pourrait être rendu disponible sous forme de balise, ne
pourrait-on écrire - avec les nouvelles possibilités de Spip 1.8 - quelque
chose comme:
<INCLURE(ti_hmenu.php3){id_rubrique}{lang = #LANG_SPIP>
> l'idée est que *même si tu ne veux pas modifier la langue de
> travail de SPIP*, #LANG représente toujours la langue de l'objet.
Je vise à l'aveuglette : cette "langue de travail de Spip" - Spip doit le
connaître quelque part.
Et si elle pourrait être rendu disponible sous forme de balise, ne
pourrait-on écrire - avec les nouvelles possibilités de Spip 1.8 - quelque
chose comme:
<INCLURE(ti_hmenu.php3){id_rubrique}{lang = #LANG_SPIP>
A la réflexion, la situation actuelle est un bug : en effet avec
forcer_lang, on veut que la langue de l'URL soit prise comme langue "forcée"
pour tous les éléments, donc y compris pour les INCLURE. C'est ça qu'il faut
changer... à tout à l'heure
