[SPIP Zone] Bug multilingue plugin diapo

Bonsoir,

Je revisite le plugin Diapo qui marche très bien. En essayant de l'utiliser dans un environnement multilingue je crois avoir découvert un bug qui est visible sur cette page : http://new.taize.fr/en_article6243.html?lang=fr

J'ai ajouté des titres en anglais et en français <multi> au 3 premières images.

Lorsqu'on l'affiche pour la première fois le titre de la première photo s'affiche correctement : "Dehors". Mais dès qu'on clique sur une des vignettes, même en restant avec la même photo, par ex. :
http://new.taize.fr/en_article6243.html?lang=fr#pagination2785
la langue est perdue (même si elle est dans l'URL), et on lit "Outside".

Le problème semble venir du fait que la page est affichée initialement par le modèle diapo/modeles/diapo.html - et la langue est bien.
Mais après cet affichage initial, l'affichage du bloc avec la photo *et son titre* se fait par diapo/diapo_img.html qui est appelé par diapo/diapo.js.html. Et langue ne semble pas passer à travers le javascript jusqu'à dans le squelette.

Si quelqu'un a une idée pour comment passer la langue, elle sera très appréciée !

Paolo

Paolo a écrit :

Bonsoir,
  
salut Paolo,

Je revisite le plugin Diapo qui marche très bien. En essayant de l'utiliser dans un environnement multilingue je crois avoir découvert un bug qui est visible sur cette page : http://new.taize.fr/en_article6243.html?lang=fr

J'ai ajouté des titres en anglais et en français <multi> au 3 premières images.

Lorsqu'on l'affiche pour la première fois le titre de la première photo s'affiche correctement : "Dehors". Mais dès qu'on clique sur une des vignettes, même en restant avec la même photo, par ex. :
http://new.taize.fr/en_article6243.html?lang=fr#pagination2785
la langue est perdue (même si elle est dans l'URL), et on lit "Outside".

Le problème semble venir du fait que la page est affichée initialement par le modèle diapo/modeles/diapo.html - et la langue est bien.
  
oui, la on est dans le cadre d'un modele (d'ailleurs si tu désactives le javascript, ca marche bien)

Mais après cet affichage initial, l'affichage du bloc avec la photo *et son titre* se fait par diapo/diapo_img.html qui est appelé par diapo/diapo.js.html. Et langue ne semble pas passer à travers le javascript jusqu'à dans le squelette.
  

oui en effet, bien vu.

Si quelqu'un a une idée pour comment passer la langue, elle sera très appréciée !
  
[18296] devrait resoudre ton probleme.
pas le temps de tester plus que ca, dis moi si c'est bon.

@++

Stephane wrote:

[18296] devrait resoudre ton probleme.
pas le temps de tester plus que ca, dis moi si c'est bon.

Bonjour Stéphane,

Merci d'avoir répondu si vite ! Pas tout à fait bon. J'ai trouvé 2 choses en tâtonnant :

1) Si je mets dans diapo.js.html à 3 endroits :
{page : mpage, id_article : mid_article, num : mnum, lang : "fr"},

alors langue "fr" passe. Le problème donc est que le mlang que tu y a mis dans ces lignes ne communique pas la langue.

2) En jouant avec le fichier diapo_html j'ai découvert que (en tout cas avec SPIP SVN) la boucle
  <BOUCLE_art(ARTICLES){id_article}>
n'est pas nécessaire. On peut le supprimer complètement et tout marche comme avant. N'est-ce pas la même chose pour la version 1.9.2 ?

Paolo

Stephane wrote:

[18296] devrait resoudre ton probleme.
pas le temps de tester plus que ca, dis moi si c'est bon.

Alors, je suis arrivé à le faire fonctionner :

http://svn.taize.fr/en_article4841.html

en changeant le lang="#LANG" que tu as ajouté à ligne 3 de diapo.html à :

lang="#ENV{lang,#LANG}"

-- lang en effet ne doit pas être simplement la #LANG de l'article, car on peut vouloir, comme dans ce cas, rester sur le même article mais changer de langue.

Par ailleurs - que penses-tu de cette idée de virer la boucle entourant dans diapo_img.html ?

Paolo

Paolo a écrit :

Stephane wrote:
  

[18296] devrait resoudre ton probleme.
pas le temps de tester plus que ca, dis moi si c'est bon.
    
Alors, je suis arrivé à le faire fonctionner :

http://svn.taize.fr/en_article4841.html

en changeant le lang="#LANG" que tu as ajouté à ligne 3 de diapo.html à :

lang="#ENV{lang,#LANG}"
  
ah oui, ok.
Mais je ne suis pas sur de comprendre les histoires de {lang_select} et autre forcer_lang.
N'est ce pas le cas particulier de ton squelette qui fait qu'il y a un lang dans l'environnement ?

Est ce le cas général ?
en gros il faut avoir le meme comportement qu'un <multi> dans le texte de l'article.
Est ce le cas ?

c'est pas plutot un critere {lang_select} dans la boucle article du modele qu'il faudrait ?
comme ca on retombe bien sur la langue de l'article si rien n'est précisé dans le contexte appelant.

-- lang en effet ne doit pas être simplement la #LANG de l'article, car on peut vouloir, comme dans ce cas, rester sur le même article mais changer de langue.

Par ailleurs - que penses-tu de cette idée de virer la boucle entourant dans diapo_img.html ?
  
oui et non...
deja en 1.9.2 je ne suis pas sur que seuls les documents des articles publiés soient pris et ca n'etait de toutes facons pas le cas dans des versions précédentes avec lesquelles le plugin marche.
Ca serait dommage d'exposer les documents.
Ensuite, il y en a une encore plus inutile dans plugins/diapo/diapo.html que j'avais laissé car je fait en fait :
<BOUCLE_art(ARTICLES){id_article}>
[(#MODELE{diapo}{id=#ID_ARTICLE}{align=#ENV{align}})]
</BOUCLE_art>
<BOUCLE_art_erreur(ARTICLES){id_article}{statut?}>
<:diapo:erreur_403:> [((#ID_ARTICLE))] : #URL_ARTICLE
</BOUCLE_art_erreur>
<:diapo:erreur_404:> [((#ENV{id_article}))]
<//B_art_erreur>

Mais on peut aussi considérer que la securité est gérée dans le modele, auquel cas l'appel au modele seul suffirait.
Je ne sais pas ce qui est le mieux, mais sans doute pas l'actuel, tu as raison.
il faudrait sans doute passer {lang} en plus à l'appel du modele de toutes facons (et du coup, soit lang_select dans la boucle si on la maintient, soit {lang=#ENV{lang}} à l'appel du modele

Pour celle de diapo_img, il faudrait verifier que la boucle document filtre bien les articles publiés en 1.9.2d et voir ce qui tombe dans #LANG si on enleve la boucle.
car j'ai peur que dans le cas général, on ne se retrouve avec la langue par defaut du site dans un article d'une autre langue.

qu'en dis tu ?
tu connais mieux que moi ces histoires de multi...

@++

Paolo

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Stephane wrote:

Est ce le cas général ?
en gros il faut avoir le meme comportement qu'un <multi> dans le texte de l'article.
Est ce le cas ?

Euh, je pense que oui. #LANG à l'intérieur d'une boucle ARTICLES donne toujours la langue de l'article, même si la boucle est marqué avec le critère {!lang_select}.

Mais si le texte de cet article contient un <multi> alors le texte rendu est celui de la langue environnante.

Ici on doit récupérer cette langue et la transmettre ailleurs. Je ne vois pas comment on va faire ça sans utiliser #ENV{lang}.

comme ca on retombe bien sur la langue de l'article si rien n'est précisé dans le contexte appelant.

C'est cela que permet #ENV{lang,#LANG}

oui et non...
deja en 1.9.2 je ne suis pas sur que seuls les documents des articles publiés soient pris et ca n'etait de toutes facons pas le cas dans des versions précédentes avec lesquelles le plugin marche.
Ca serait dommage d'exposer les documents.
Ensuite, il y en a une encore plus inutile dans plugins/diapo/diapo.html que j'avais laissé car je fait en fait :
<BOUCLE_art(ARTICLES){id_article}>
[(#MODELE{diapo}{id=#ID_ARTICLE}{align=#ENV{align}})]
</BOUCLE_art>
<BOUCLE_art_erreur(ARTICLES){id_article}{statut?}>
<:diapo:erreur_403:> [((#ID_ARTICLE))] : #URL_ARTICLE
</BOUCLE_art_erreur>
<:diapo:erreur_404:> [((#ENV{id_article}))]
<//B_art_erreur>

?? Il n'y pas tout ça dans la version sur la zone. Là, le contenu est seulement :

<BOUCLE_art(ARTICLES){id_article}>
[(#MODELE{diapo}{id=#ID_ARTICLE}{align=#ENV{align}})]
</BOUCLE_art>

Pour celle de diapo_img, il faudrait verifier que la boucle document filtre bien les articles publiés en 1.9.2d

Je ne suis pas sûr d'avoir un 1.9.2 installé : je vais regarder.

à+
Paolo

Paolo a écrit :

Stephane wrote:
  

Est ce le cas général ?
en gros il faut avoir le meme comportement qu'un <multi> dans le texte de l'article.
Est ce le cas ?
    
Euh, je pense que oui. #LANG à l'intérieur d'une boucle ARTICLES donne toujours la langue de l'article, même si la boucle est marqué avec le critère {!lang_select}.
  

ah OK, c'est ca que j'avais compris de travers (je n'utilise jamais ce critère), mais du coup je ne comprend pas tout à l'interet de la chose.

Mais si le texte de cet article contient un <multi> alors le texte rendu est celui de la langue environnante.

Ici on doit récupérer cette langue et la transmettre ailleurs. Je ne vois pas comment on va faire ça sans utiliser #ENV{lang}.

comme ca on retombe bien sur la langue de l'article si rien n'est précisé dans le contexte appelant.
    
C'est cela que permet #ENV{lang,#LANG}
  
OK, fait.

?? Il n'y pas tout ça dans la version sur la zone. Là, le contenu est seulement :
  

oups...
bon, voila une version un peu plus cohérente...

Pour celle de diapo_img, il faudrait verifier que la boucle document filtre bien les articles publiés en 1.9.2d
    
Je ne suis pas sûr d'avoir un 1.9.2 installé : je vais regarder.
  
ne t'embete pas, de toute facons, pour avoir la langue de l'article si aucune langue n'est passée lors de l'appel, il faut bien cette boucle englobante.
j'y ai ajouté la gestion d'erreur comme dans le modele.

ca marche comme ca (18303) ?

@++

Stephane wrote:

ca marche comme ca (18303) ?

A http://svn.taize.fr/en_article4841.html j'ai mis la version diapo 0.6 SVN [18303] telle quelle sans aucune intervention dans le modèle.

Le changement de langue marche bien, mais il y a quelques embellissements qui apparaissent au-dessus des vignettes :wink:

Et il y a une chose que je n'ai jamais compris - et c'est pourquoi j'ai changé les boutons sur la version sur notre site - quand on clique sur '>' pour démarrer le diaporama l'image reste sur '>' au lieu de passer à '||'.

Paolo

Stephane a écrit :

ca marche comme ca (18303) ?
  
chez moi (1.9.2d), ca ne marche que si la boucle (ARTICLES dans laquelle il y a le #TEXTE contenant le modele) a un critère {!lang_select}.
Et il faut mettre egalement ce {!lang_select} aux boucles du modele et de diapo_img, pas chez toi ?

j'ai une version qui marche en 1.9.2d si il y a bien le !lang_select dans le squelette et se calera sur la langue de l'article sinon.

c'est le mieux, non ?

ca se comporte differement en SVN ?

SVN en rad pour le moment, commit un peu + tard après 1 ou 2 tests supplementaires.

@++

Stephane wrote:

chez moi (1.9.2d), ca ne marche que si la boucle (ARTICLES dans laquelle il y a le #TEXTE contenant le modele) a un critère {!lang_select}.
Et il faut mettre egalement ce {!lang_select} aux boucles du modele et de diapo_img, pas chez toi ?

Faut-le mettre alors.

- Je pense (sans en être sûr) qu'il y a des différences entre 1.9.2 et 1.9.3 SVN à cet égard.

- Il est vrai aussi que j'ai ces lignes dans mes_options.php :

if (strstr($_SERVER['REQUEST_URI'], 'article')) {
  if (isset($_GET['lang'])) $forcer_lang = true;
}

que Fil avait conseillées à l'époque, et qui me sauvent de plein d'ennuis multilingues. Et dans certaines situations je pense que je peux me passer des {!lang_select} dont d'autres auront besoin !

Parfois on se demande s'il n'y aurait vraiment pas un façon plus simple de gérer les langues ! :slight_smile:

Paolo

Paolo a écrit :

Stephane wrote:
  

chez moi (1.9.2d), ca ne marche que si la boucle (ARTICLES dans laquelle il y a le #TEXTE contenant le modele) a un critère {!lang_select}.
Et il faut mettre egalement ce {!lang_select} aux boucles du modele et de diapo_img, pas chez toi ?
    
Faut-le mettre alors.

- Je pense (sans en être sûr) qu'il y a des différences entre 1.9.2 et 1.9.3 SVN à cet égard.

- Il est vrai aussi que j'ai ces lignes dans mes_options.php :

if (strstr($_SERVER['REQUEST_URI'], 'article')) {
  if (isset($_GET['lang'])) $forcer_lang = true;
}

que Fil avait conseillées à l'époque, et qui me sauvent de plein d'ennuis multilingues. Et dans certaines situations je pense que je peux me passer des {!lang_select} dont d'autres auront besoin !
  
bon, je pense que 18305 convient dans tous les cas et devrait marcher chez toi aussi.
En gros, sur /dist, si tu mets &lang=en, ca ne sera pas pris en compte et c'est voulu.
Si tu ajoutes {!lang_select} dans article.html, il en tiendra compte, tu peux donc le regler par boucle.
Si c'est le comportement toujours souhaité (ton cas) => forcer_lang=true dans mes_options
la, le modele suit bien le parametrage.

Parfois on se demande s'il n'y aurait vraiment pas un façon plus simple de gérer les langues ! :slight_smile:
  
Non, je crois au contraire que c'est très bien comme ca, je vois pas mal de cas ou c'est interessant d'agir par boucle.
Mais dans la majorité des cas, forcer_lang est plus adapté.

@++