Bonjour,
je suis en train de développer un nouveau squelette pour spip 1.7.2.
J'essai donc d'utiliser $forcer_lang pour toujours avoir la variable lang
dans mes urls.
avec mon ancien squelette spip 1.7.1, j'ai un fichier article-14.html spécial
pour que tous les articles de la rubrique 14 affichent une galerie
photos.
voir: http://6v8.gamboni.org/article.php?id_article=31 (spip 1.7.1)
avec la version 1.7.2, si je ne spécifie pas la variable lang dans l'url ça
marche: http://6v8.gamboni.org/TEST/article.php?id_article=31
mais avec une variable lang, le squelette normal des articles est utilisé:
http://6v8.gamboni.org/TEST/article.php?id_article=31&lang=en
j'ai essayé de creer un fichier article-14.en.html pour palier au problème,
mais rien à faire.
Est-ce un bug? ou ai-je ratté quelque chose?
Merci
Pierre
je suis en train de développer un nouveau squelette pour spip 1.7.2.
J'essai donc d'utiliser $forcer_lang pour toujours avoir la variable lang
dans mes urls.
Oui, enfin... $forcer_lang n'est là que dans le cas où la page demandée n'a
pas de langue définie : donc ça n'est pas fonctionnel pour une page article,
brève, rubrique, etc.
avec mon ancien squelette spip 1.7.1, j'ai un fichier article-14.html
spécial pour que tous les articles de la rubrique 14 affichent une galerie
photos.
voir: http://6v8.gamboni.org/article.php?id_article=31 (spip 1.7.1)
avec la version 1.7.2, si je ne spécifie pas la variable lang dans l'url ça
marche: http://6v8.gamboni.org/TEST/article.php?id_article=31
mais avec une variable lang, le squelette normal des articles est utilisé:
http://6v8.gamboni.org/TEST/article.php?id_article=31&lang=en
Ca c'est un bug 
Il devrait utiliser le squelette article-14.html et
refuser de prendre en compte le paramètre 'lang', qui n'est pas pertinent.
Est-ce un bug? ou ai-je ratté quelque chose?
Les deux !
Moralité : n'utiliser $forcer_lang que dans des cas très particuliers (comme
la page de login ou une page auteur).
-- Fil
je suis en train de développer un nouveau squelette pour spip 1.7.2.
J'essai donc d'utiliser $forcer_lang pour toujours avoir la variable lang
dans mes urls.
Oui, enfin... $forcer_lang n'est là que dans le cas où la page demandée n'a
pas de langue définie : donc ça n'est pas fonctionnel pour une page article,
brève, rubrique, etc.
Comme avec mes problèmes précédent. Je veux utiliser les fonctions multilingues spip
pour afficher le plus possible dans la langue de l'utilisateur... alors je n'utilise que très
peu l'information de langue sur l'article etc...
J'ai donc, dans quasiment toutes mes boucles articles, rubriques, etc... le critère
{select_lang=non} pour utiliser la variable lang de l'url (pour traduire les chaînes
localisées par exemple, sinon il y a un mélange désastreux entre ce qui est
traduits dans la boucle et ce qui l'est en dehors), et je met un peu partout
$forcer_lang pour être sûr de toujours avoir le paramètre dans l'url.
mon site tourne en local, je le passerai sur le serveur sous peut (~1 semaine) et
là tu verras ce que je veux dire... (mais je sais qu'on est déjà pas d'accord :D)
Je pense aussi faire un article (sur mon site ou spip-contrib, en fonction de l'interet)
sur comment aborder le problème de la façon dont je le vois.
avec mon ancien squelette spip 1.7.1, j'ai un fichier article-14.html
spécial pour que tous les articles de la rubrique 14 affichent une galerie
photos.
voir: http://6v8.gamboni.org/article.php?id_article=31 (spip 1.7.1)
avec la version 1.7.2, si je ne spécifie pas la variable lang dans l'url ça
marche: http://6v8.gamboni.org/TEST/article.php?id_article=31
mais avec une variable lang, le squelette normal des articles est utilisé:
http://6v8.gamboni.org/TEST/article.php?id_article=31&lang=en
Ca c'est un bug Il devrait utiliser le squelette article-14.html et
refuser de prendre en compte le paramètre 'lang', qui n'est pas pertinent.
Je veux donc qu'il utilise mon squelette -14, mais qu'il prenne aussi en compte
le paramètre 'lang' quand je spécifier {lang_select=non} dans les boucles sensibles
au langage.
Est-ce un bug? ou ai-je ratté quelque chose?
Les deux !
Moralité : n'utiliser $forcer_lang que dans des cas très particuliers (comme
la page de login ou une page auteur).
comme moi je le vois, c'est juste un bug... et moi qui veux faire un site
"très particulier" par rapport à la philosophie spip ;).
Pierre
J'ai donc, dans quasiment toutes mes boucles articles, rubriques, etc...
le critère {select_lang=non} pour utiliser la variable lang de l'url (pour
traduire les chaînes localisées par exemple, sinon il y a un mélange
désastreux entre ce qui est traduits dans la boucle et ce qui l'est en
dehors), et je met un peu partout $forcer_lang pour être sûr de toujours
avoir le paramètre dans l'url.
Intéressant.
Je veux donc qu'il utilise mon squelette -14, mais qu'il prenne aussi en
compte le paramètre 'lang' quand je spécifier {lang_select=non} dans les
boucles sensibles au langage.
OK, mais la sélection du squelette est faite, par définition, {avant}
l'analyse des boucles.
comme moi je le vois, c'est juste un bug... et moi qui veux faire un site
"très particulier" par rapport à la philosophie spip ;).
Tu feras un petit patch pour désactiver le truc. On peut éventuellement
coupler le truc que tu demandes à la variable de personnalisaiton
$forcer_lang ; il faut voir s'il y a des implications désastreuses ou pas
-- Fil
OK, mais la sélection du squelette est faite, par définition, {avant}
l'analyse des boucles.
oui, c'est ce que je veux dire... mon squelette utilisera le critère
{lang_select=non}, il faut juste qu'il soit sélécrionné correctement 
Tu feras un petit patch pour désactiver le truc.
pour tout le reste, en combinant, {lang_select=non} et $forcer_lang=true,
ça marche, c'est juste pour la selection de squelette spécifique que ça bug.
Je pense donc ne même pas avoir à modifier le noyeau spip ici.
Pierre
pour tout le reste, en combinant, {lang_select=non} et $forcer_lang=true,
ça marche, c'est juste pour la selection de squelette spécifique que ça bug.
Si tu veux sélectionner par rubrique (article-14.html), la version CVS
corrige le bug, ça devrait coller ; si en revanche tu veux sélectionner par
langue (article.xxx.html) en utilisant $forcer_lang, SPIP resélectionnera la
langue de l'article demandé. C'est ça que tu pourrais éventuellement vouloir
patcher.
Je pense donc ne même pas avoir à modifier le noyeau spip ici.
Tant mieux !
-- Fil
Hello,
ça y est, j'ai passé mon site de test online à la version CVS: SPIP 1.8 alpha 1 CVS.
$forcer_lang en global dans mes_options.php3 marche nickel pour l'instant.
Mais, la sélection d'un squelette d'article (ou de rubrique) en fonction du numéros de rubrique ne marche pas.
J'ai 2 squelettes:
article-14.html
article.html
et
rubrique-14.html
rubrique.html
les squelettes -14 etant adaptés à la rubrique 14 ou se trouvent mes galeries. Si je mets le critère lang=.. dans l'url (ce qui est fait automatiquement par forcer_lang), la selection du squelette 14 ne se fait pas (même bug que celui cité avant).
Je ne veux pas sélectionner de squelette à partir de la langue, mais selon la rubrique (donc pas besoin de patcher quoi que ce soit).
voir:
http://6v8.gamboni.org/TEST/rubrique.php?id_rubrique=14
normalement, il doit y avoir le nombre de photos sous les titres. Là il essai d'afficher le nombre de mots (ce qui marche pas, vue que l'article est vide).
et
http://6v8.gamboni.org/TEST/article.php?id_article=31
normalement, on devrait avour une vraie galerie d'image (squelette WALMA2).
les originaux, qui marche sous 1.7.2pr2 sont là:
http://6v8.gamboni.org/rubrique.php?id_rubrique=14
http://6v8.gamboni.org/article.php?id_article=31
Une idée?
Pierre
moi ça marche, dans le sens où il met bien la variable dans l'url.
depuis la 1.7.2, j'ai des {lang_select=non} un peu partout. C'est peu être ça qui manque chez toi.
Pierre
Hello,
comme je l'ai mentioné plus tôt,
si je veux selectionner des squelettes en fonction de la rubrique (article-14.html ou rubrique-14.html, etc...)
tout en ayant $forcer_lang=true dans mes options, ça ne marche pas.
Je ne sais pas si j'ai mal compris tes explications, ou que le bug est réaparue avec la 1.8a. Enfin,
je suis allé un peu touillé dans le code et voici un patch pour que ça marche.
Je te laisse le valider.
Pierre
inc-calcul.patch (1.35 KB)
