Dans un site schéma multilangue, avec des rubriques en multilinguisme (contenant des articles en français et leurs traductions).
Classiquement, lors de la traductions, on réutilise les mêmes images dans l'article et ses traductions.
Alors logiquement on utilise les champs <multi> pour les différents titres/legendes de l'image.
Mais je ne vois pas comment afficher le titre du document dans la bonne langue :
- la langue de l'environnement est la langue de consultation du site, et non la langue de l'article consulté.
- la langue de l'article ne semble pas passer dans l'environnement jusqu'à l'image.
Un moyen pour que les images incluses à l'article aient leur titre dans la langue de l'article et non du site, ce qui paraitrait un comportement plus logique ??
salut,
j’ai cette boucle qui fonctionne sur un SPIP 2 avec Z…
dans /contenu/article.html un appel par INCLURE à /inclure/article.html qui contient :
<BOUCLE_contenu_article(ARTICLES){id_article}{lang} >
…
[(#REM) Gestion du portfolio et des documents ]
<BOUCLE_origine(ARTICLES) {id_trad} {origine_traduction} >
[(#INCLURE{fond=inclure/documents}{id_article}{id_document}{lang})]
< / BOUCLE_origine>
…
< / BOUCLE_contenu_article>
donc la langue est bien passée au documents
Le 18/07/2012 16:33, Alex-OnirisProductions a écrit :
Bonjour,
Dans un site schéma multilangue, avec des rubriques en multilinguisme (contenant des articles en français et leurs traductions).
Classiquement, lors de la traductions, on réutilise les mêmes images dans l'article et ses traductions.
Alors logiquement on utilise les champs <multi> pour les différents titres/legendes de l'image.
Mais je ne vois pas comment afficher le titre du document dans la bonne langue :
- la langue de l'environnement est la langue de consultation du site, et non la langue de l'article consulté.
- la langue de l'article ne semble pas passer dans l'environnement jusqu'à l'image.
Un moyen pour que les images incluses à l'article aient leur titre dans la langue de l'article et non du site, ce qui paraitrait un comportement plus logique ??
Normalement elles l'ont sans problème, en tous cas sur mon site (voir en signature si nécessaire) (squelette Escal). Mais, dans l'interface privée, on ne voit le titre dans la bonne langue que quand on bascule sur la langue en question (de français vers espagnol par exemple), et cette bascule est devenue plus compliquée sur Spip 3.
Le 18/07/2012 16:33, Alex-OnirisProductions a écrit :
Bonjour,
Dans un site schéma multilangue, avec des rubriques en multilinguisme
(contenant des articles en français et leurs traductions).
Classiquement, lors de la traductions, on réutilise les mêmes images
dans l'article et ses traductions.
Alors logiquement on utilise les champs <multi> pour les différents
titres/legendes de l'image.
Mais je ne vois pas comment afficher le titre du document dans la
bonne langue :
- la langue de l'environnement est la langue de consultation du site,
et non la langue de l'article consulté.
- la langue de l'article ne semble pas passer dans l'environnement
jusqu'à l'image.
Un moyen pour que les images incluses à l'article aient leur titre
dans la langue de l'article et non du site, ce qui paraitrait un
comportement plus logique ??
Normalement elles l'ont sans problème, en tous cas sur mon site (voir en
signature si nécessaire) (squelette Escal). Mais, dans l'interface
privée, on ne voit le titre dans la bonne langue que quand on bascule
sur la langue en question (de français vers espagnol par exemple), et
cette bascule est devenue plus compliquée sur Spip 3.
Par contre du côté public, aucun problème.
Bon en fait je n'avais pas bien compris le problème. Oui le titre est dans la langue de l'environnement, ce que je trouve logique d'ailleurs.
Normalement elles l’ont sans problème, en tous cas sur mon site (voir en
signature si nécessaire) (squelette Escal). Mais, dans l’interface
privée, on ne voit le titre dans la bonne langue que quand on bascule
sur la langue en question (de français vers espagnol par exemple), et
cette bascule est devenue plus compliquée sur Spip 3.
Par contre du côté public, aucun problème.
Bon en fait je n’avais pas bien compris le problème. Oui le titre est dans la langue de l’environnement, ce que je trouve logique d’ailleurs.
Merci de ton retour.
Ca ne m’apparait pas si logique.
Les images sont plutôt reliées, pour leur langue, au sous-ensemble article plutôt qu’à l’environnement général.
Le cas que j’évoque est :
Je consulte en environnement français, la traduction d’un article, une version anglaise de l’article (donc interface en français affichant un article en anglais)
En tant qu’internaute, je m’attends à lire les légendes en anglais pour les images associées à l’article en anglais, quelque soit l’environnement.
Les mêmes images, mais associées à l’article en français, légendées en français.
Le 19/07/2012 09:28, Alex-OnirisProductions a écrit :
Merci de ton retour.
Ca ne m'apparait pas si logique.
Les images sont plutôt reliées, pour leur langue, au sous-ensemble
article plutôt qu'à l'environnement général.
En fait c'est la conception du multilinguisme qui change. Chez moi il y a des secteurs pour chaque langue et on n'accède, en fonction de l'environnement linguistique choisi qu'aux articles dans la langue en question, ce qui n'empêche évidemment pas de cliquer sur les autres drapeaux. Donc c'est logique d'avoir tout l'article dans la langue de l'environnement.
Le cas que j'évoque est :
Je consulte en environnement français, la traduction d'un article, une
version anglaise de l'article (donc interface en français affichant un
article en anglais)
En tant qu'internaute, je m'attends à lire les légendes en anglais pour
les images associées à l'article en anglais, quelque soit l'environnement.
Les mêmes images, mais associées à l'article en français, légendées en
français.
Parce que là, on choisit la langue et on a accès tout le site, c'est une autre logique.
Les deux se valent et ont leurs raisons. Pour mon site aiguilles magiques la solution de multilinguisme d'Escal est parfaitement adaptée par exemple alors que celle fournie avec Zpip n'est pas terrible et cela d'autant plus que je dois ajouter les documents en téléchargement à chaque traduction.