Salut,
je constate une erreur d'affichage des caractères spéciaux lors de l'installation des plugins sous SPIP 2.1.
Voici une capture d'écran :
http://www.spip.de/IMG/png/20100624_spip_erreur_codepage_install_plugin.png
Et le scripte :
/ecrire/?exec=charger_plugin
Comme vous pouvez constater ca concerne le francais comme les autres langues.
Est-ce qu'il y a un patch disponible ?
klaus++
le problème vient du plugin.xml du plugin concerné qui contient des accents en iso-truc alors que ton site est en utf.
Il faut utiliser des entités html pour eviter ce problème.
Cédric
Merci Cédric, je viens de constater qu'avec Social tags c'est bon.
Alors que faire pour éviter que cela n'arrive ?
Est-ce qu'il faut obliger tous les auteurs de plugin à n'écrire plus que des entités html ?
J'ai l'impression qu'il y a des choses à faire non pas au niveau technique mais au niveau de la gestion des plugins qu'on met à disposition de tout le monde.
Je crois qu'un catalogue des choses à respecter avant publication serait le bienvenu.
klaus++
Ça a toujours été marqué :
Ancienne doc :
http://doc.spip.org/@Plugin-xml
"Le fichier plugin.xml doit être écrit en XML valide si possible. En conséquence , il faut bien penser à utiliser les entités (e.g. à ou à pour à) à la place des caractères accentués."
Nouvelle doc :
http://programmer.spip.org/plugin-xml-minimum
"Les caractères hors ASCII sont échappés"
Super, merci pour les liens.
Je voulais aussi faire allusion aux règles assez strictes chez certains projets open source où on ne publie des modules qu'une fois qu'ils ont passé des tests.
J'aime beaucoup la devise SPIP "on fait d'abord et on s'engeule ensuite", mais je pense aussi qu'un mécanisme qui s'adresse aux webmestres non-techniciens (notamment plugins/auto) doit garantir un niveau de qualité et de compatibilité très élevé si on ne veut pas les decevoir.
klaus++
P.S. on passe à spip.zone, d'accord ?
Je confirme ce bug. Y compris sous SPIP 2.0.
Pat
Cédric a fait remarquer dans sa réponse qu'il ne s'agissait pas d'un bug mais d'un problème du côté plugin.xml.
Quand les auteurs et traducteurs n'utilisent pas les entités html pour les textes à afficher cela se traduit un faux rendement des caractèrs spéciaux quand ils ne sont pas codés avec la même codepage que celle utilisée par SPIP (OSI vs. UTF-8 etc.)
klaus++
Pat wrote:
Je sais lire klaus++ et il ne faut pas tout croire !
Il s'agit bien d'un bug que l'on peut voir aisément sur un site iso-8859-1 par exemple.
Les caractères du plugin.xml n'ont rien à voir, il doit manquer un filtre tenant compte du charset du site.
Pat
Où est le patch?
Si tu es capable de proposer un patch propre qui ne mette pas à plat les serveurs … je pense qu’il sera particulièrement apprécié …
Cependant il a toujours été dit de mettre ses textes dans les plugin.xml en entités html et ce depuis les premiers plugins … Je ne pense pas que cela soit pour rien … et je ne pense pas non plus que cela demande énormément d’efforts de la part des contributeurs qui le font également pour les fichiers de langue…
kent1…
Si tu es capable de proposer un patch propre qui ne mette pas à plat les
serveurs ...
Cette ironie me passe bien au-dessus de la tête !
Cependant il a toujours été dit de mettre ses textes dans les plugin.xml en
entités html et ce depuis les premiers plugins ... Je ne pense pas que cela
soit pour rien ... et je ne pense pas non plus que cela demande énormément
d'efforts de la part des contributeurs qui le font également pour les
fichiers de langue...
Tu as raison. MAIS CE N'EST PAS LE SUJET, j'ai même tendance à croire que vous ne comprenez rien volontairement.
Depuis sa créaton, cy_altern a bien utilisé les entités HTML, comme la très grande majorité des créateurs de plugin d'ailleurs.
Pour aller même plus loin, il faut utiliser sous XML les caractères digitaux de type é et non les entités HTML, ce que peu de codeurs font en fait.
Je répète donc : *un site en iso-8859-1 affiche mal cette page* d'installation de plugin, entités HTML OU NON.
Il s'agit donc d'un réel bug, pas méchant certes mais pas très bon pour l'image, qu'un gentil dev pourra corriger facilement -- ou peut-être même l'auteur de ce code incomplet --, par amour des choses bien faites et des gentils utilisateurs de SPIP !
Pat
24/06/10, klaus++:
Je voulais aussi faire allusion aux règles assez strictes chez
certains projets open source où on ne publie des modules qu'une fois
qu'ils ont passé des tests.J'aime beaucoup la devise SPIP "on fait d'abord et on s'engeule
ensuite", mais je pense aussi qu'un mécanisme qui s'adresse aux
webmestres non-techniciens (notamment plugins/auto) doit garantir un
niveau de qualité et de compatibilité très élevé si on ne veut pas
les decevoir.
Je pense la même chose depuis la première fois où j'ai été confronté
aux plugins dans SPIP.
Le truc bizarre, c'est qu'avec l'empaqueteur sur la zone et le système
de tags, on peut déjà en théorie générer des .zip différents, et donc
proposer par exemple une version stable et une version de dev.
Le problème est que pour 99% des paquets ce n'est pas le cas
(compter le nombre de lignes "tags" dans archiveliste.txt)... il
faudrait donc comprendre pourquoi et/ou trouver un moyen pour inciter
les auteurs de plugins à le faire.
Le processus de développement pourrait (devrait ?) être le suivant :
1. à la création du plugin, utiliser dans plugin.xml l'état "dev"
2. on développe son plugin par commits successifs
3. quand on est sur une version stable, on change en "stable", on commit
et on copie dans tags/. La première fois, on ajoute une ligne spécifique
dans l'empaqueteur.
4. on remet l'état à "dev", et on reprend à 2.
En vrai c'est un peu lourd, ce qui explique peut-être pourquoi personne
ne le fait. On pourrait peut-être trouver un moyen d'automatiser des
choses, mais je ne vois pas bien comment.
Pourtant ça serait nickel : un petit filtre dans la page de plugins qui
ne montre que les plugins stables par défaut, ou même un fil RSS
distinct avec juste les versions stables, et c'est bon. La grosse
question reste de comment simplifier le process aux auteurs de plugins
pour les inciter à indiquer la dernière version stable.
--
davux
Salut Davux et merci pour ton commentaire.
Je crois qu'il "suffit" de faire le ménage dans ce qui existe et de proposer un exemple de la démarche désormais "officielle".
Après il faudrait éventuellement ouvrir une zone "officielle" dont le contenu respecterait les normes tout en laissant la zone "bordelique" ouverte tel qu'elle l'est aujourd'hui.
Cette manière de procéder comporte un danger : la perte d'une liberté et d'une partie de l'ambiance qui constituent une bonne partie du projet SPIP.
... il
faudrait donc comprendre pourquoi et/ou trouver un moyen pour inciter
les auteurs de plugins à le faire.
klaus++
C'est lidée derrière plugins.spip.net, non ?
A bientôt
Simon
klaus++ a écrit :
Salut Davux et merci pour ton commentaire.
Je crois qu'il "suffit" de faire le ménage dans ce qui existe et de proposer un exemple de la démarche désormais "officielle".Après il faudrait éventuellement ouvrir une zone "officielle" dont le contenu respecterait les normes tout en laissant la zone "bordelique" ouverte tel qu'elle l'est aujourd'hui.
Cette manière de procéder comporte un danger : la perte d'une liberté et d'une partie de l'ambiance qui constituent une bonne partie du projet SPIP.
... il
faudrait donc comprendre pourquoi et/ou trouver un moyen pour inciter
les auteurs de plugins à le faire.klaus++
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone