Ca fait un bail que j'utilise SPIP un peu frusté par cette affaire de multilinguisme. Donc forcément j'ai testé la prochaine version 1.7
Eh bien en fait je suis tout dubitatif. Pour moi c'est pas du multilinguisme , c'est du 'tag-age'.
En gros si j'ai bien compris , chaque rubrique , article ou breve peut se voir affublé d'un tag qui précise sa langue...
Mais en aucun cas un article (au sens atomique , unique du terme) n'est multilingue. Du coup en gros faire du multilinguisme avec spip c'est se lancer dans le clonage... d'arborescence.
j'ai l'impression de voir une mécanique qui va éventuellement m'éviter d'installer deux SPIP... mais pas de dupliquer ma structure logique.
Ce que semble confirmer la définition des tables dans la base. Est-ce que j'ai bien compris comment la chose était conçue ou pas ?
Je suis ptet pas normal, mais pour moi le multilinguisme ça aurait été de pouvoir associer des traductions à un article... Et que celui ci s'affiche dans la langue préférée par le client quand c'est possible, sinon dans la langue dispo (genre pour mon navigateur : fr, en , es)
L'important étant à mon avis de conserver le lien logique entre un article et sa traduction, d'autant qu'il y a tout dans spip pour informer les rédacteurs des modifications de l'article original...
Evidemment techniquement c'est pas la même chose, je sais bien... mais de point de vue des rédacteurs est ce que c'est pas plus logique ?
Je suis ptet pas normal, mais pour moi le multilinguisme ça aurait été
de pouvoir associer des traductions à un article... Et que celui ci
s'affiche dans la langue préférée par le client quand c'est possible,
sinon dans la langue dispo (genre pour mon navigateur : fr, en , es)
Tu peux très bien faire ça avec les outils de la 1.7 et un peu d'astuce...
Supposons que tu as une fonction (à écrire) qui te donne le langue à
afficher en fonction de : 1) les langues disponibles pour l'article 2) les
langues préférées du browser (u le cookie de langue sélectionné par le
visiteur).
function ma_langue($langues_dispo) {
...
return 'la langue demandée';
}
Ensuite dans le squelette tu fais un truc du genre :
(ou bien avec des if (...) { ?> #TEXTE <?php } ?>)
C'est un peu brouillon car je n'ai pas le temps de détailler, mais je suis
sûr que c'est jouable ; si tu mènes le truc au bout ça mériterait une
contrib sur spip_contrib/
Oui oui, ca marche ce que tu proposes pour l'aspect visible par le visiteur, mais reste le pb de l'association que SPIP ne stocke pas (je crois hein entre un article et sa traduction. Je ne sais pas si c'est faisable, ça me semble pas correspondre à l'angle pris.
Un exemple, en fonction du contenu que j'ajoute (ou simplement des remarques des gens) je suis amené à déplacer des articles, à modifier la structure de mon site... Tu imagines l'horreur si je veux maintenir, par exemple la version anglaise plus ou moins cohérente avec ces changements...
En gros je ne considère pas les traductions comme des articles ... ce qui veut dire une table à part, avec une pêche à la bonne traduction , directement dans SPIP (c'est affreux ce que je dis
Un exemple, en fonction du contenu que j'ajoute (ou simplement des
remarques des gens) je suis amené à déplacer des articles, à
modifier la
structure de mon site... Tu imagines l'horreur si je veux
maintenir, par
exemple la version anglaise plus ou moins cohérente avec ces
changements...
En gros je ne considère pas les traductions comme des articles ... ce
qui veut dire une table à part, avec une pêche à la bonne
traduction ,
directement dans SPIP (c'est affreux ce que je dis
Effectivement dans ton cas, les modifications sont lourdes si elles doivent être gérées en même temps dans plusieurs langues.
<théorique>
Potentiellement tu verrais un changement dans quel sens ?
Chaque article aurait autant de champs de saisie pour chaque type de données que de langues disponibles sur le site ?
(je parle de ce qui est perçu par le "client", qu'il soit lecteur ou rédacteur, pas de champs de base... c'est juste pour faire avancer la réflexion)
</théorique>
Si: si tu actives dans la configuration la gestion des "liens de traduction", SPIP gère la relation entre un article dit "de référence" et ses traductions, avec l'interface qui va bien. Pour chaque article, tu peux donc connaître directement (dans l'interface privée et dans les boucles du site public):
- la liste des traductions de cet article,
- lequel de ces articles est l'article de référence (celui à partir duquel les traductions sont effectuées).
PS: j'ai vu que quand on dispose que du .php comme extension d'activée dans son serveur, il y a bien de prévu index.php à la racine et dans ecrire, mais le ecrire/index.php3 fait appel à install.php3 se qui stoppe tout net l'installation.
entre un article et sa traduction. Je ne sais pas si c'est faisable, ça me semble pas correspondre à l'angle pris.