Discussion Utilisateur:Verdy p

Un article de Wikipédia, l'encyclopédie libre.

[modifier] Syntaxe dans les Infobox V2

Bonjour
Pourrais-tu donner un exemple (bref et concis) de problèmes de sauts de ligne liés à la syntaxe de ces infobox ? Merci. --Lgd (d) 1 juin 2008 à 07:28 (CEST)

tout d'abord la balise |- qui indique une nouvelle rangée (et qui porte les attributs de celle-ci) ***précède*** les cellules qu'elle décrit, elle ne la suit pas, si on la met après le serveur wiki doit bidouiller le code pour davoir quand générer une nouvelle rangée, et c'est pas propre de la mettre à la fin d'un #if ou en fin de tableau alors qu'il n'y a aucune cellule après (ça génère une rangée vide).

ensuite les sauts de ligne en trop génère des sauts de paragraphes supplémentaires qui sont nuisibles quand les cellules doivent déjà contenir des sauts de paragraphes, et on se retrouve avec des paragraphes vides (

<p></p>

) dans le HTML généré, et des espaces blancs verticaux supplémentaires.

ça ne se manifeste pas toujours aves toutes les infobox car cela dépend du nombre de sauts de lignes laissés. Mais comme tous les #if se succèdent et sont séparés par des sauts de lignes hors du if, ils se cumulent et finissent par générer des sauts de paragraphes qui s'ajoute soit à la dernière cellule précédente en cours, soit créent une cellule supplémentaire, soit ajoutent des paragraphes hors du tableau s'il n'y a pas de cellule avant.

ce problème a déjà été réglé dans le passé dans pas mal de modèles, et c'est dommage de l'oublier dans la conception des infobox v2 qui font table rase de tout ce qui a pu être fait avant et pourquoi, et sans même discuter avec ceux qui avaient écrit ces infobox que vous remplacez du jour au lendemain dans un petit groupe.

Bref, faire des reverts sans comprendre (même si en apparence cela ne change rien pour vous), et demander ensuite c'est assez malvenu... Verdy p (d) 1 juin 2008 à 15:03 (CEST)

Un exemple précis, bref, et pertinent, c'est à dire un article où apparaît le problème ? Merci. --Lgd (d) 1 juin 2008 à 15:07 (CEST)

Il serait dommage de devoir protéger ce modèle pour éviter des éditions hasardeuses, mais c'est ce qui va arriver. Merci de ne pas tenter de restaurer tes modifications problématiques avant que leur pertinence n'ait été vérifiée. --Lgd (d) 1 juin 2008 à 15:13 (CEST)

souviens-toi, l'hiver dernier. Les mêmes causes auront certainement les mêmes effets. Si on se rend compte que ses modifs posent problème, on discute avant de se lancer dans un guerre d'édition. Clem (✉) 1 juin 2008 à 15:22 (CEST)

Hors du sujet: personne n'est venu me demander quoi que ce soit (surtout pas toi qui cherches une fois encore la polémique dès le départ) et il n'y a pas eu de disussion avant. De plus je ne me suis pas énervé du tout et ai justement évite tout ton polémique; utiliser le passé quand un problème a été réglé est contraire à toute volonté d'apaiser les débats. Traitez les problèmes un par un, et ne mélangez pas tout pour un nouveau "problème" spécique et complètement séparé (et même pas encore discuté). Je veux bien qu'on me demande des explications, mais pourquoi cette habitude prise par certains de réverter tout ce qu'ils n'ont pas fait eux-même? Le revert normalement c'est contre le vandalisme destructif, ou quand la modification pose un problème technique ou produit des rsultats incohérents et des avis divergent sur la présentation. Je n'ai rien fait de tel ici. Verdy p (d) 1 juin 2008 à 15:52 (CEST)

Quelques précisions:

• par défaut, mediawiki ne génère pas d'élément tr en cas de ligne de tableau vide. En cas de bug sur ce point, il est impératif de connaître les exemples précis où cela se serait produit, afin de pouvoir y remédier. Mais ne pas modifier a priori la syntaxe des modèles sans avoir regardé plus avant.
• Par ailleurs, tu comprendras que je sois prudent avec tes interventions sur les modèles quand j'y trouve ce genre de chose

Le "position:float" était là depuis longtemps, je ne l'ai pas ajouté; il me semble que ça a été ajouté à un moment donné parceque que "float:right" ne fonctionait pas seul dans une cellule de table avec certains navigateurs (qui veulent un "position:" pour pouvoir déplacer et positionner un bloc flottant relativement à un bloc parent et non relativement à la page). Verdy p (d) 1 juin 2008 à 15:46 (CEST)

Juste pour info: outre que le position:float était dans le modèle dès sa création par toi-même, aucun navigateur n'a jamais eu besoin de positionnement pour faire flotter une boîte. On peut déplacer en position relative un élément flottant, ce qui n'a rien à voir. On ne peut pas faire flotter un élément positionné en absolu ou en fixe. Et la position float n'a jamais existé. enfin, pour ce qui est de positionner une boîte relativement à une boîte parente et non à la page, c'est un bug d'IE5-6 de type haslayout sans aucun rapport avec les flottants. Tu comprends pourquoi je suis prudent, pourquoi je demande des exemples précis que l'on puisse analyser, et non tes justifications embrouillées ? --Lgd (d) 1 juin 2008 à 17:51 (CEST)

Juste pour info : tu n'as pas tout suivi, car ce modèle créé très récemment est issu de la fusion de deux autres modèles qui utilisaient ça tous les deux (et qui maintenant utilisent ce modèle commun) ! Tu as donc oublié de regarder d'où venait le code que je n'ai pas modifié en faisant leur fusion (au passage ce modèle fusionné est maintenant utilisé aussi dans d'autres modèles présents pour certains portails). Les deux modèles concernés étaient ceux générant les "Lumière sur" de la liste de sélection pour l'accueil, et les "Lumière sur" des "Sélections" par thème (et d'autres modèles encore pour certains portails qui n'emploient pas le modèle des "sélections").

Ceci dit, je suis d'accord avec ton changement, je ne l'ai juste pas fait ou regardé quand j'ai importé le code à fusionner.

Mon explication n'a rien d'embrouillée, tu ne m'as juste pas demandé vraiement d'où venait ce code et c'est toi qui vient compléter en parlant de chose que je n'ai pas évoquées (si je me rappelle bien cela n'a rien à voir avec hasLayout sur IE5-6, mais à des d'anciennes versions de navigateurs spécifiques à Linux; il faudrait se souvenir de quand date ce code et où il avait été discuté, mais il était là depuis des mois ou des années bien avant que je crée ce modèle et apparemment personne n'avait rien trouvé à y redire).

Référence: modèle {{Lumière2}}, regarde http://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le%3ALumi%C3%A8re2&diff=30135622&oldid=18870172

Même chose pour le modèle {{Lumière3}}, regarde http://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le%3ALumi%C3%A8re3&diff=30135668&oldid=12143177

Tu verras que je n'ai rien touché du tout ! "float:right" a été utilisé depuis plus de 3 ans, et pas uniquement par moi qui avait créé un des deux, mais aussi d'autres notamment dans leurs portails ou leurs autres modèles de mise en forme... Mais je veux bien croire que les navigateurs ont été corrigés depuis de sorte qu'on ne voit plus pourquoi c’était là.

Donc c'est très bien si tu le corriges au passage, mais s'il te plait évite la polémique ou les questions personnelles, ou de préjuger de la compétence des personnes, car c'est assez désagréable, voire insultant quand cette personne s'attache à vouloir respecter les normes depuis longtemps mais se confronte à la réalité des choses, et la susceptibilitité des auteurs: même en changeant un minimum de choses (voire en ne changeant rien du tout comme c'est le cas ici), il est difficile de ne pas se faire incendier; ne donne pas des intentions aux gens en fonction de ce que tu lis immédiatement, et vouloir leur demander de justifier tout de suite est aussi dégradant, quand les solutions sont employées et ont été discutées des années avant (et il est difficile de remonter les historiques, ou on n'a pas envie ni le temps de le faire).

"Par ailleurs, tu comprendras que je sois prudent avec tes interventions sur les modèles" (comme tu l’écris toi-même de façon si... courtoise) quand je lis tes justifications qui montre que tu n'as pas cherché du tout au delà d'une seule page et une seule modif et aucun historique.

Je ne veux pas employer ce genre de phrase mais j'aimerais que tu arrêtes les expressions comme "modifications problématiques", "embrouillées", "mauvaise qualité du code" : tu fais immédiatement des jugements de valeur qui ne sont même pas démontrés, cr il il n'y a ni problème, ni embrouillement, ni mauvaise qualité, ni aucune destruction de code, et tu admettras que j'ai fait preuve de bien plus de prudence (en modifiant un minimum et en appliquant ce qui marche ou est démontré marcher déjà depuis des mois ou des années) que tu ne l'as vu au premier abord, et je veux bien admettre que les modifs te surprennent mais pas que tu y voies une volonté de nuire de ma part ou de te critiquer personnellement au vu de ce que tu fais à un instant donné; on peut ne pas être d'accord, mais pas s'insulter (même de façon détournée). Il faut être prudent quand on accuse quelqu'un de quelquechose et avoir fait d'autres vérifications. Verdy p (d) 1 juin 2008 à 17:59 (CEST)

• ou quand je lis tes exploits des jours précédents, toujours sur les modèles (voir les archives de ta page de discussion). --Lgd (d) 1 juin 2008 à 15:25 (CEST)

Merci d'éviter aussi le ton polémique. Je vois que dans votre projet il y a trop de gens passablement énervés, mais je n'y suis pour rien si vos discussions ont été houleuses, mais raison de plus pour être prudent avant d'imposer vos modèles partout ailleurs en faisant table rase de ce qui a été fait avant. Rappelez vous que votre projet est finalement récent et a eu très peu de visibilité jsusqu'à présent, et que des tas de gens ont travaillé sur des modèles depuis longtemps bien avant vous.

Je n'ai rien contre votre travail, je considère qu'il est utile, mais attention quand même à ne pas oublier trop vite le "pourquoi du comment" de certains bouts de codes qui ne vous paraissent pas à vos yeux comme joli. Certaines raisons motivent une écriture un peu plus compliquée des modèles si cela facilite aussi leur utilisation dans les pages. Verdy p (d) 1 juin 2008 à 15:46 (CEST)

Il serait dommage de devoir protéger ce modèle pour éviter des éditions hasardeuses, mais c'est ce qui va arriver. Merci de ne pas tenter de restaurer tes modifications problématiques avant que leur pertinence n'ait été vérifiée. --Lgd (d) 1 juin 2008 à 15:13 (CEST)

Il serait tout autant dommage de forcer les choix de votre petit groupe partout; les modifs ne sont pas "hasardeuses" mais bien destinées à éviter d'autres problèmes et maximiser la compatibilité (y compris au niveau du HTML généré et avec les différents navigateurs, ou de l'inclusion de contenus plus détaillés que ce que prévoient initialement les modèles).

Quant aux archives, je ne cache rien, ce n'est pas parce que quelqu'un écrit que cela veut dire qu'il y a un problème, ce peut être uniquement des demandes d'explication. J'ai fait bien assez de corrections depuis des années dans des modèles qui se mettaient mal en page, et mon but n'a jamais été d'en supprimer des focntionnalités mais bien de les faire fonctionner de la façon la plus simple possible, et de documenter les cas délicats ou moins évidents.

Je vois par exemple que vous avez réintroduit un modèle non nécessaire comme {{!-}} alors que {{!}} suffit (on met le signe moins après), on peut comprendre en revanche {{!!}} au lieu de {{!}}{{!}} ...

Je maintiens que {{!-}} doit être placé AVANT les cellules d'une même rangée, y compris la première rangée d'entête (la preuve: mettez des attributs de police ou de couleur commune à la rangée sur la ligne du {{!-}} ou du |-) et non APRES comme vous l'avez proposé (le fait que MediaWiki élimine les vide est une mauvaise solution à utiliser; il n'aurait pas à le faire si on plaçait les |- là où il faut, c'est-à-dire AVANT. On a déjà eu des tas de cas où ce travail de nettoyage supplémentaire de MediaWiki n'était pas toujours propre ou suffisant. autant ne pas lui laisser cette tâche ingrate. Il faut aussi comprendre que le code conditionnel généré dans un #if n'élimine pas le saut de ligne qui précède ou suit le #if: pour wikipédia ce saut de ligne est pertinent et est conservé puis analysé après substitution du #if; les sauts de ligne en excédent ne sont pas tous éliminés du code, seulement ceux au début ou à la fin de la valeur d'un paramètrede modèle. Les autres génèrent des sauts de paragraphe (MediaWiki évite seulement de générer une suite de paragraphe vides, mais il garde au moins un saut de paragraphe). Si on l'oublie, cela génère des espaces blancs verticaux suppémentaires dans le cas où tous les paramètres du modèle ne sont pas renseignés (ce qui arrivera fatalement avec ces modèle V2 qui ont beaucoup plus de paramètres optonnels pertinents seulement pour certains articles et pas sur tous, ou parceque la valeur du paramètre à indiquer n'est pas connue avec précision ou ambiguë ou sans signification pour l'article concerné. Des tas d'exemples ont été corrigés dans plein de boites dans les années passées, je ne vois pas l'intéret de revenir sur ces nombreuses corrections qui ont eu lieu en regénérant à nouveau les mêmes problèmes ou en ne faisant rien pour les prévenir là où ils se produisent (ou vont à nouveau se produire). Il y a eu effectivement des changements dans la syntaxe Wiki pour éliminer certains de ces problèmes, mais ce travail supplémentaire de nettoyage fait par MediaWiki n'est pas stable d'une version à l'autre, sauf si on les prévient à l'avance. Les sauts de ligne en trop sont donc à éliminer chaque fois que possible, au moins dans les modèles les plus utilisés. Verdy p(d) 1 juin 2008 à 15:38 (CEST)

Bon. Je n'ai pas lu ce qui précède et je ne lirai probablement pas. J'ai demandé l'URL d'un article où le problème motivant ton intervention sur le modèle peut être observé. --Lgd (d) 1 juin 2008 à 15:44 (CEST)

• Ne pas vouloir lire une réponse quand tu poses une question, c'est refuser de discuter. Libre à toi, mais ne viens pas dire que je n'ai pas voulu t'aider ou collaborer avec toi. J'ai voulu prévenir des problèmes qui se sont déjà posés dans nombre d'endroits dans le passé, pour ne pas les répéter dans des nouveaux modèles.
• J'aimerais aussi qu'on évite de lancer une polémique, ou que certains se sentent personnellement visés ou critiqués de ce qu'ils font. Je trouve votre projet v2 très bien, mais merci quand même d'acepter que d'autres viennent vous indiquer des syntaxes qui ont été et restent problématiques dans les modèles. Je sais que c'esdélicat à manipuler un modèle, mais ce n'est pas une raison pour lancer des incendies alors qu'il n'y a encore eu aucun dégat. Verdy p (d) 1 juin 2008 à 15:54 (CEST)

Verdy_p : si tu as éprouvé le besoin de modifier ce modèle, c'est bien parce que tu avais rencontré un problème de rendu dans un article, n'est-ce pas ? Dans ce cas, indiquer de quel article il s'agit est facile, non ? Permettre à d'autres contributeurs d'analyser le problème éventuel est tout aussi évident ? --Lgd (d) 1 juin 2008 à 16:01 (CEST)

Je veux bien mais il faut que je les retrouve dans des historiques sur plusieurs années. Sinon il faudra que je construise un exemple pour le montrer.

En attendant reconnais que les |- de rangées doivent être avant les cellules et non après, comme c'est voulu par la syntaxe wiki des tables, y compris pour la première rangée. Ca facilite le boulot du MediaWiki (et évitera certains de ses bogues qui apparaissent ou réapparaissent de temps en temps) et ce n'est pas compliqué à gérer quand même? Verdy p (d) 1 juin 2008 à 16:06 (CEST)

Bon, je te laisse chercher un exemple actuel. Pour les |-, là encore, un exemple de problème analysable. --Lgd (d) 1 juin 2008 à 16:09 (CEST)

Merci de ne pas considérer que je veuilles en faire une question personnelle ou contre ton travail ou celui de votre groupe de projet que je n'ai pas critiqué, bien au contraire, je me félicite de l'existence ce ce projet auquel je voulais seulement apporter ma petite pierre. Verdy p (d) 1 juin 2008 à 16:06 (CEST)

Rassures-toi, je considère d'autant moins quoi que ce soit que je ne fais pas partie des initiateurs de ce « projet infobox v2 ». En ce qui me concerne, tes modifications posent uniquement un problème de code et de qualité du code. --Lgd (d) 1 juin 2008 à 16:15 (CEST)

Quant aux sauts de lignes ils interviennent dans la généraatio nde paragraphes dans les cellules: même si cela ne génère pas forcément partout un espace vertical supplémentaire (avec des lignes vides visibles) cela change la structure du document (des paragraphes sot générés, qui ont aussi leur propre marge supplémentaire au dessus et en dessous, donc ça change l'interlignage visible pour certaines cellules et pas pour d'autres: l'espacement vertical entre cellules visible devient variable, ce qui n'est pas joli, et structurellement le docment généré a une structure logique différente (en terme d'encapsulation): cette structure logique de document intervient dans l'accessibilité des tables (lecteurs Braille ou oraux pour malvoyants par exemple, qui ont déjà beaucoup de mal à se retrouver dans les tables).

La "qualité" de code que tu définis me parait subjective, elle se confonte à certaines réalités techniques. Le code n'a pas forcément à être joli pour être correct. S'il faut compliquer le code c'est dans le modèle et non dans les articles qui les emploient.

Et je ne vois pas de quoi tu parles dans mes supposés "problèmes de code" qui ne posent effectivement aucun problème: ni technique, ni de rendu, ni de structure logique, ni d'éditabilité ou de lisibilité (sachant ce qu'on y cherche, la lisibilité dépend seulement de la stabilité des solutions techniques employées). Mais il est certain qu'il y a différentes façon de produire la même chose (mais il faut comprendre ce que veut dire "même chose", car il ne faut pas tenir compte de la seule apparence, mais aussi de la généricité et l'évitement de problèmes récurrents pour des tas de cas particuliers). Ma façon de coder proposée ici est nettement plus générale, pusique c'est bien celle qu'attend MediaWiki pour les tables, une fois les #if substitués. Verdy p (d) 1 juin 2008 à 16:26 (CEST)

De toute façon je suis sûr qu'à un moment ou un autre, tu reviendras sur ta solution en constatant que c'était finalement la meilleure façon (qui pluis est très simple) d'éviter les problèmes d'intégration qui ne vont pas tarder à se manifester (vu que vous voulez généraliser les v2 partout). Pour moi il n'y a aucun doûte que si une rangée est conditionnelle, le #if ne doit PAS inclure à la fois les cellules de cette rangée et le |- de la rangée suivante qui devrait pouvoir utiliser des attributs complètement indépendants de la présence ou non d'une rangée optionnelle placée avant.

Vous allez le voir avec les infobox comme celles de taxonomie, ou qui incluent des rangées de cartes ou géolocalisateurs après des tas d'autres rangées d'information optionnelle: la rangée doit avoir des attributs spécifique, et parfois contenir des sous-tables avec des groupes de cellules partageant des attributs commus qu'il vaut mieux ne pas avoir à regénérer pour chacune.

Et je me méfie comme de la peste du supposé travail de "nettoyage" fait par MediaWiki: on a déjà eu des surprises lors de changements de versions, et vouloir compter dessus c'est freiner ou empêcher le déploiement de ces nouvelles versions, alors que la syntaxe "normale" est connue et documentée depuis longtemps (et les autres syntaxes anormales nécessitant du nettoyage ne sont pas stables d'une version à l'autre). Verdy p (d) 1 juin 2008 à 16:37 (CEST)

Je vais m'arrêter là, en répétant mon antienne: des exemples en ligne de problèmes précis. Qu'il s'agisse d'analyser une question éventuelle d'accessibilité, ou le traitement d'une syntaxe par le parseur d'un CMS, ça ne se fait pas avec des généralités. --Lgd (d) 1 juin 2008 à 16:39 (CEST)

Je te renvoies déjà à la doc de MediaWiki pour les tables où |- a toujours signifié début de nouvelle rangée (ligne suivie d'attributs optionnels pour la rangée et les cellules codées après) et non fin de rangée même si accessoirement elle génère une éventuelle fin de rangée précédente, s'il y en avait une (comme le fait aussi |} en fin de table), car les fin de rangées ne sont porteuses d'aucun attribut supplémentaires (et sont même optionnelles en HTML de base, mais codées obligatoirement en XHTML).

Bref |-attributs devient toujours <tr attributs> et non </tr> (où iraient les attributs?)

Le principe dans la syntaxe MediaWiki est de ne jamais avoir à indiquer les fins, seulement les débuts par des caractères spéciaux placés prioritairement au début d'une ligne de code. MediaWiki générera les fins là où il faut, et ensuite tentera de joindre les lignes non marquées pour former un même paragraphe. Verdy p (d) 1 juin 2008 à 16:51 (CEST)

[modifier] Apostrophe(s)

Bonjour, Je viens de voir que tu es responsable de cette modification, elle est importante (peut-être démesurément) dans l’actuelle prise de décision Discussion Wikipédia:Prise de décision/Usage de l'apostrophe typographique. Y a-t-il eu une discussion à l’époque ? (je n’ai rien retrouvé). VIGNERON * ^discut. 2 juin 2008 à 16:41 (CEST)

Cet ajout est surtout un condensé de plusieurs débats qui ont eu lieu à l'époque (cette discussion revient régulièrement depuis le début du projet)

qui grosso modo ont toujours conduit à la situation du "laisser faire" pour permettre aux gens d'utiliser les apostrophes qu'ils veulent si cela leur facilite l'édition, et laisser aussi les autres les corriger, puisque ceux qui veulent des apostrophes droites ne voient pas la différence.

En revanche pour les titres d'articles, et uniquement pour eux, l'apostrophe courbe a déjà été critiquées et rejetée de nombreuse fois, mais si certains veulent des titres d'article avec apostrophe courbe, qu'au moins ils fassent en sorte que l'article reste accessible en tapant le titre avec un clavier de base de façon simple (sans avoir à utiliser un sélecteur qui n'est pas disponible hors de l'édition des articles eux-même).

C'est vrai que je préfère lire des apostrophes courbes, j'accepte le compromis sur le titre de l'article lui-même (où il y a encore d'autres contraintes relatives aux capitales et certains autres caractères techniquement interdits).

Je n'ai pas essayé de trancher la question dans cet ajout en 2007, juste d'expliquer où pouvaient se situer les problèmes, et en particulier pour l'établissement des liens, qui est le seul véritable problème à prendre en compte (l'autre problèmes de duplication possible de certains articles résulte de la négligence des auteurs qui ne sont pas conscient du problème et ne veulent pas créer les redirections recommandées depuis longtemps et déjà discutées et mises en œuvre par différents robots; ce peut être aussi fréquemment le résultat d'oublis, et on ne va pas se battre pour des oublis, ni les utiliser pour justifier une position ou une autre alors que l'action n'est pas forcément volontaire de la part de l'auteur de ces oublis).

Encore un fois je trouve cette question stérile, et fait juste perdre du temps; on a déjà beaucoup de mal à faire tenir la bonne humeur et l'esprit de coopération, pour ne pas imposer des règles trop strictes appliquées avec trop de zèle. Je pense sincèrement qu'on peut concilier les deux avis de ceux qui veulent pouvoir utiliser des apostrophes simples et ceux qui veulent lire des courbes, à condition de chaque camp accepte les corrections par l'autre camp, et notamment celles dans le texte des articles (oui il faut faire attention, mais les courbes ont d'autres avantages quand elles apparaissent à côte de mise en gras ou italique: les courbes ne nécesssitenet auxun espace qui serait incorrect; les courbes lèvent les ambiguités syntaxiques Wiki et facilitent le travail des robots correcteurs orthographiques qui doivent interpéter le code Wiki)...

On doit aussi prendre en compte le fait que nombres d'articles ne sont pas édités dans le formulaire web mais dans des éditeurs externes ayant des fonctionnalités plus avancées (y compris en correction orthographique, ou recherche par expression régulière), afin de s'assurer de l'homogénéité de l'écriture dans les articles (on voit trop d'articles ou le même terme apparait encore avec parfois une douzaine de graphies distinctes et éparpillées, ce qui ne facilite ni la lecture, ni la maintenance, même si ensuite une autre graphie est préférée et décidée car des tas d'endroits restent oubliés dans les corrections).

Si c'est un traitement de texte qui est utilisé, il propose la correction des apostrophes automatiquement. Je pense qu'on doit aller vers cette excellence si possible graduellement, car ces corrections ne sont pas toutes automatisables sans erreur pour traiter de grands volumes de textes. Verdy p (d) 3 juin 2008 à 15:56 (CEST)