options de rendu visuel de la page d'accueil [Solved]
Solution Manager: Tof
Issue description
Suite au passage en 7.3beta19 du site APM, je souhaite faire remonter quelques modifications que j'ai faites liées à cette option :
1) dans le index.php, j'ai mis en commentaires le bloc de code qui charge uniquement les pages récentes de la section concernée par cette option.
En effet, la prise en compte des pages récentes à afficher en page d'accueil est déjà définie au niveau de chaque page et de chaque section; il est inutile de forcer la limitation à une seule section (d'autant plus que les pages récentes des sous-sections de celle indiquée sur l'option ne sont pas affichées par le Articles::list_by_date_for_anchor().
Par contre, cette option reste très utile pour ne présenter que les sous-sections d'une partie du site.
2) dans le configure.php, l'id de la section choisie était affecté dans le section_at_home. J'ai préféré garder "id" dans le sections_at_home et poster le champ section_id_at_home que j'ai également agrandi.
Le but est de pouvoir saisir un id ou un nickname, ce qui est utile dans le cas où on ne connait pas l'id, et surtout dans le cas d'un site multilingue où on affectera le même nickname sur plusieurs sections (dans mon cas un nickname "produits" sur ma section produits et ma section products).
J'ai modifié les traitements correspondants dans le index.php en remplaçant $target_section =& Sections::get($context['sections_at_home']); par $target_section =& Sections::get($context['section_id_at_home']); et les tests ((int)$context['sections_at_home'] > 0) par ($context['sections_at_home'] =='id')
3) dans les fonctions Articles::get() et Sections::get(), j'ai ajouté un test sur le langage dans le cas où un nickname est passé, pour ne traiter que les sections ou articles correspondant à la langue courante.
Il faudrait à mon avis étendre ce test sur les fonctions list_xxx pour n'afficher que les éléments de la langue courante.
En attendant, j'ai préféré ajouté les lignes suivantes dans mon Skin::layout_article() et Skin::layout_section() :
//language condition
if ($context['language'] != $context['preferred_language']) {
if ($item['language'] != $context['language']) return null;
}
elseif ($item['language'] != $context['language'] && $item['language'] != '') return null;
4) je joins également mes fichiers index_fr.php et index_en.php appelés par un clic sur des drapeaux qui positionnent une variable $user_language gérée la fin du global.php également joint.
Le tout permet de garder l'information de la langue choisie tout au long de la navigation.
Files
| yacs multi langue 79,058 bytes, 248 downloads Edited by Tof on May 14 2007 Zoom | |
| les fichiers concernés 72,123 bytes, 60 downloads /index.php /index_fr.php /index_en.php skins/configure.php sections/sections.php articles/articles.php shared/global.php Edited by Tof on Apr. 13 2007 Zoom |
Comments
Bernard, j'espère que tu as passé de bonnes vacances !
Comme tu le vois, nous n'avons pas chômé en ton absence et tu dois être débordé
.
Néanmoins, je te fais remonter ce post car j'aurais besoins de tes lumières assez urgemment pour valider ou non ce que j'ai fait pour APM.
Merci d'avance.
-----
Tof
Salut salut, tu as bien fait de remonter ce post, j'ai 140 messages en retard...
Ok, je vais regarder tout ceci en prévision d'une intégration douce d'ici la fin du mois dans la 7.4 définitive.
Peux-tu aussi formaliser ton besoin, de façon succinte, dans la zone réservée à cet effet s'il te plait ? Le but est de bien documenter les fonctions ajoutées à YACS au fur et à mesure, et c'est plus simple en fin de mois quand les pages d'information sont déjà là...
Merci de faire avancer le sujet du multi-linguisme aussi vite et longue vie à APM.
j'ai quasiment fini le passage en multi langue d'APM.
je joins les fichiers modifiés récemment.
A+
Tof
-----
Tof
Tof : Je viens de lire une grande partie des fichiers que tu as envoyé, et j'ai quelques questions de conception.
Q1/ Sélection de langue - Si j'ai bien compris, tu ranges l'information de langue dans la session. Pourquoi ne pas utiliser un cookie longue durée à la place ? Ceci aurait l'intérêt de simplifier encore plus la navigation, puisqu'il n'y aurait plus besoin de choisir la langue à chaque visite du site. Et puis, c'est le système que j'envisage d'utiliser pour tous les internautes, tout du moins pour ceux qui souhaitent utiliser une langue différente de celle indiquée par leur navigateur...
Q2/ Choix de contenu localisé - Dans le code proposé, tu limites la visibilité aux pages dont la langue correspond à celle choisie par l'internaute. Je pense que ce comportement correspond bien à certains types de site, et moins à d'autres. On pourrait peut-être en faire un paramètre global au site, à saisir dans un panneau de configuration ?
Q3/ Editeur multi-langue - Là, c'est trop compliqué pour mes petits neurones ... Comment se fait le lien entre les couples (id, langue) d'une page à l'autre ?
Hello Bernard,
Je rentre juste et répond rapidement :
R1 : tout à fait d'accord mais je ne sais pas comment on programme les cookies.
R2 : parfaitement ok avec toi.
R3 : je fais simplement un Articles::get sur le couple nickname, langue puisque deux articles équivalents de langues différentes ont le même nickname. Pour cela je déclenche un évènement javascript sur le onchange de la boite de sélection qui redirige vers la bonne langue. Cela ne fonctionne que si le javascript est activé sur le navigateur, j'en ai conscience, mais c'est tellement plus simple.
-----
Tof