<multi>[en]Recommended web sites [de]Empfohlene NetzstandorteSitios [es]web
recomendados [fr]Sites web recommandés [it]Siti web raccomandati
</multi>
Cela marche parfaitement dans la partie privée. D'ailleurs la petite icône
"multi" s'affiche. Si je change de langue, le titre change en fonction.
Par contre cela ne fonctionne pas dans la partie publique où j'ai des pages
en plusieurs langues et où j'ai le choix de langue sur la page sommaire.
Je suppose que j'ai omis un paramètre. Ou autre chose ?
J'utilise la balise <multi> .... </multi> pour le titre d'une rubrique,
... cela ne fonctionne pas dans la partie publique
Bonsoir,
A moins que tu n'empêches #TITRE de prendre la langue de
la boucle en cours il sera toujours dans cette langue.
Comment l'empêcher ? Deux façons à ma connaissance :
- soit ajouter {!lang_select} comme critère de la boucle
- soit ajouter $forcer_lang = true (en php ou dans l'URL)
Je rencontre le même problème mais de manière plus
étendue:
Mon but (comme bcp de monde j'imagine) est d'éviter
d'avoir à dupliquer toutes mes rubriques dans le site
donc de séparer par secteur ce qui duplique les
squelettes.
j'ai un fichier sommaire.php3 auquel je peux ajouter
le critère ?lang=fr ou ?lang=en
j'ai des rubriques traduites par des balises <multi>
lorsqu'on descend au niveau de l'article, on accède
à une liste mélangeant des articles en
- français(langue par défaut)
- english
Premier souci: même si le paramètre ?lang=en est
passé dans l'URL, une boucle (ARTICLES) imbriquée
dans une boucle (RUBRIQUES) me donne toujours la
liste des articles en français. Et passer le paramètre
{!lang_select} dans la boucle ne change rien.
Pour les fonctions multilingue - assez, je pense. Comme je n'utilise pas
pour le moment les forums, les statistiques, le calendrier, etc., mais que
j'ai absoluement besoin d'un système multilingue, j'ai pris le risque de
suivre la vesion CVS. Je tiens une copie teste du site installée en
parallèle avec la version CVS de Spip. Quand il y a une nouveauté ou un
changement, je le teste d'abord là
Peut-être "stable", mais il y a eu encore des bugs significatifs pour le
multilingue qui ont été fixés après la sortie de 1.8b1:
le 18/9 : $forcer_lang et le cache;
le 14/10 : #LANG_DIR (pas important, à moins qu'on publie aussi des pages en
arabe);
le 31/10 : #INTRODUCTION désormais sait lire les champs <multi>
... me donne invariablement un lien en fr même si mon url indique lang=en
avec {!lang_select} c'est pareil...
Moi je ferais comme ça :
1) mettre cette ligne dans article.php3 :
if ($_GET['lang']) $forcer_lang = true;
2) commencer ton squelette avec ta boucle articles:
<BOUCLE_contextep(ARTICLES){id_article}>
suivie d'une boucle Rubriques qui servira à attraper la langue passée dans
l'URL, par exemple:
<BOUCLE_lang(RUBRIQUES){tout}{lang}{0,1}>
Notes:
- il faut évidemment être sûr qu'il existe une rubrique dans cette langue
qui est passée;
- {tout} est seulement nécessaire si elle peut ne pas avoir d'article
publié;
- tu peux éventuellement attacher autre chose à cette boucle _lang et
l'utiliser non seulement pour "attraper la langue", dans la mesure où tu es
sûr que cela ne va pas "jurer" avec le critère {lang}
ensuite, où que tu te trouves dans le squelette, tu peux toujours attraper
la langue de l'URL :
- dans un critère, avec la syntaxe {lang = %lang} (lit directemment lang
depuis l'URL)
- comme balise : #_lang:LANG
et une grande paix s'instaure en matière de multilingue
Merci, je vais tester tout ça... et voir notamment
si ça fonctionne pour un système où les rubriques
n'ont pas de langue...
Car aujourd'hui, mon site fonctionne avec ses deux
secteurs mais c'est précisément ce que je veux abandonner
car pour deux langues, je trouve ça beaucoup trop lourd
(en termes de squelette, de navigation dans l'interface privé, etc.)
Non, tu n'es pas seul. J'ai signalé un problème sur la liste spip-dev la
semaine dernière.
Mon souci vient de ce que l'affichage de l'interface privée par IE ( 5.5 ou
6 ) provoque des requetes http intempestives sur les adresses IP
207.46.196.108 (activex.microsoft.com) et 207.46.248.96
(origin-codecs.microsoft.com)
Selon J. Pyrat, cela pourrait être à cause du .htc qui rend les png
transparent en utilisant un filtre DirectX (donc en interne, un activex).
Utilisant Spip sur un réseau dont l'accès Internet nécessite une
authentification itilisateur, la rédaction d'article avec Internet Explorer
devient malheureusement rebutante, puisque la mire d'authentification
s'affiche lors de tout affichage/réaffichage de page de l'interface privée.
Si quelqu'un a une solution de contournement ( autre qu'utiliser
Mozilla/Firefox puisque les rédacteurs de mon site ont un poste de travail
avec Internet explorer) ?
Non, tu n'es pas seul. J'ai signalé un problème sur la liste
spip-dev la semaine dernière.
Mon souci vient de ce que l'affichage de l'interface privée
par IE ( 5.5 ou
6 ) provoque des requetes http intempestives sur les adresses IP
207.46.196.108 (activex.microsoft.com) et 207.46.248.96
(origin-codecs.microsoft.com) Selon J. Pyrat, cela pourrait être à
cause du .htc qui rend les png transparent en utilisant un filtre
DirectX (donc en interne,
un activex).
Utilisant Spip sur un réseau dont l'accès Internet nécessite une
authentification itilisateur, la rédaction d'article avec
Internet Explorer
devient malheureusement rebutante, puisque la mire d'authentification
s'affiche lors de tout affichage/réaffichage de page de
l'interface privée.
Si quelqu'un a une solution de contournement ( autre qu'utiliser
Mozilla/Firefox puisque les rédacteurs de mon site ont un
poste de travail
avec Internet explorer) ?
Peut-être en mettant le site dans la zone de confiance de IE ?
Daniele
-----Original Message-----
From: spip-bounces@rezo.net [mailto:spip-bounces@rezo.net]On Behalf
Of ed Sent: mercredi 3 novembre 2004 18:29
To: spip@rezo.net
Subject: [Spip] Re: utilisation balise <multi>
En fait j'ai testé avec la v8:
{lang} ou {!lang_select} ne marche
pas pour les articles avec la v8b1
Avec la v8b2 ça fonctionne.
Par ailleurs, le site privé nouvelle
présentation est très pratique lorsqu'on
l'utilise avec Firefox mais inutilisable
avec Internet Explorer.
j'ai testé la méthode que tu m'as préconisée
en multilinguisme et ça fonctionne bien donc
merci.
Seul souci: la balise #_lang:LANG ne fonctionne
pas avec <INCLURE(monfichier.php-#_lang:LANG )>
autrement dit j'ai un fichier d'inscription
à une mailing list en français (inscription.php)
et un en anglais(inscription-en.php)
Mais la balise ne fonctionne pas dans ce contexte
(d'ailleurs il faudrait que mon fichier en français
s'appelle inscription-fr.php)
Essaie déjà : <INCLURE(monfichier-#_lang:LANG.php)>
Paolo
J'ai fait une erreur de syntaxe dans ma question
mais c'est bien cette solution que j'ai testée
et ne fonctionne pas...
Je vais poser la question dans un nouveau topic.