Discussion modèle:Etc./Admissibilité

L'admissibilité de la page « Modèle:Etc. » est débattue.

Consignes quant à cette procédure :

Qui peut participer ?

Le créateur de la page et les contributeurs ayant un compte ayant fait au moins cinquante contributions aux articles (espace principal) de fr.wikipedia.org au lancement de cette procédure peuvent exprimer leur avis.

Les avis des personnes n’ayant pas de compte ou un compte ayant moins de 50 contributions sont déplacés dans « Avis non décomptés » et ne sont en principe pas pris en considération. Lors de la clôture, les avis sans argumentaire sont également déplacés et ne sont pas pris en compte.

Durée de la consultation

Si un consensus clair s'est dégagé le 15 novembre après l'expiration de sept jours pleins de débat (168 heures), un contributeur ayant réalisé au moins 500 modifications et ayant 3 mois d'ancienneté (utilisateur autopatrolled) qui n'aura pas pris part au débat peut clore la proposition et indiquer si la page est conservée ou supprimée (la suppression devant être demandée à un administrateur). Dans le cas contraire, la discussion se poursuit et peut être close à partir du 22 novembre.

Voir toutes les procédures en cours

Important

• Copiez le lien *{{L|Modèle:Etc.}} et collez-le dans la section du jour de la page principale « Débat d'admissibilité ». Attention, un décalage d'un jour est possible en fonction de la mise en page.
• Avertissez le créateur, les principaux contributeurs de l’article et, si possible, les projets associés en apposant le message {{subst:Avertissement débat d'admissibilité|Modèle:Etc.}} sur leur page de discussion.

Modèle:Etc.

Proposé par : Esprit Fugace (d) 7 novembre 2012 à 19:54 (CET)

Rapport service rendu/ inconvénients générés trop proche de zéro. Esprit Fugace (d) 7 novembre 2012 à 19:54 (CET)

Comme d'habitude les rédacteurs de ce modèle ne sont pas prévenus de cette PaS... Daniel*D 7 novembre 2012 à 23:55 (CET)

Je l'ai donc fait, et → [1], il en résulte → [2], forcément. Daniel*D 12 novembre 2012 à 10:43 (CET)

Conclusion

Le débat a abouti à la conservation de cette page.

Conservation traitée par Superjuju10 ^{[Contacter la Aubline]}, le 22 novembre 2012 à 13:36 (CET)

Raison : Résumé des modifications : certains estiment d'un coté que ce modèle, comme d'autres, est une complexification de l'édition de Wikipédia n'apportant rien, tandis qu'un autre « groupe » met en avant un respect des conventions typo (espace insécable) et la non obligation d'utilisation.

Si on analyse par les chiffres selon la méthode [Pour/(Pour+contre)] cela donne :

• 46 % de votes pour la conservation ;
• 54 % de votes pour la suppression.

Conclusion : considérant d'une part l'absence de consensus clair, d'autre part que les différentes discussions n'ont pas abouti à ce qu'un wikipédien change d'avis, et que chacun d'entre nous est « libre » d'appliquer ou non un modèle tant que les recommandations de WP:Typo sont respectées (sachant que dans ce cas, d'autres solutions existent), je clos cette page en Statu quo.

Explication plus détaillée du diff : typographie (pas de majuscule après un deux-points sauf dans le cas d'un nom propre ou d'une citation), LRTUIN, p. 38 et 147. Ce n'est pas moi qui « pense que ce serait une faute », mais les sources. Et nul besoin d'aucun « modèle » pour cela, ni de « complication du code ». Daniel*D (d) 22 novembre 2012 à 23:08 (CET)

Explication de la suggestion : aboutit est la troisième personne du singulier de l’indicatif présent ou du passé simple du verbe aboutir ; abouti en est le participe passé. --Rigoureux (d) 23 novembre 2012 à 16:18 (CET)

Explication d'une autre suggestion : le mot discussion est féminin. --Rigoureux (d) 23 novembre 2012 à 16:42 (CET)

Discussions

Toutes les discussions vont ci-dessous.

Daniel*D 9 novembre 2012 à 12:12 (CET)

Si j’ai bien compris, ça sert :

1. à insérer une espace insécable ;
2. à afficher une infobulle ;

Me trompè-je, ai-je oublié quelque chose ? FF 07.11.12 20:00 CET.

Réponse du comte Ɲemoi – Oui, c’est un équivalent de « , {{abréviation discrète|1=etc.|2=et cetera}} » (l’infobulle sert à garantir une bonne lecture par les lecteurs d’écran). Il a un bizarre paramètre « virgule= » qui, n’ayant a priori aucun intérêt, pourrait être supprimé. Amicalement, ce 7 novembre 2012 à 20:05 (CET).

Si on le garde on pourrait au moins mettre en italique la locution latine. --PierreSelim ^{[let discussion = fun _ ->]} 7 novembre 2012 à 20:45 (CET)

Réponse : voir l'historique. Daniel*D 7 novembre 2012 à 23:51 (CET)

J’ai spécifié que l’abréviation était latine, tant qu’à faire ! Cordialement --Pic-Sou 8 novembre 2012 à 15:36 (CET)

« à ajouter une espace insécable » et une virgule.

Le paramètre {{etc.|virgule=non}} sert à désactiver la virgule et l'espace (oui tout ça pour obtenir un simple « etc. »), par exemple pour les listes :

• A
• B
• etc.

Un lecteur d'écran digne de ce nom saura lire correctement « etc. », c'est quand même le béaba, exemple testable sur internet (en bas à gauche). –Akeron (d) 7 novembre 2012 à 21:16 (CET)

Vous n'avez pas compris le rôle principal du modèle : en effet, en typographie, il faut éviter que cette abréviation, qui, dans une énumération, doit toujours être précédée d’une virgule, soit reportée au début d’une ligne selon le Lexique des règles typographiques en usage à l’Imprimerie nationale, France, Imprimerie nationale, 2002 (réimpr. 2007, 2008, 2011), 6^e éd. (1^re éd. 1975), 197 p. (ISBN 978-2-7433-0482-9), p. 6 et 146, qui sert de référence à nos recommandations en matière de typographie. Daniel*D 8 novembre 2012 à 01:27 (CET)

Non, j'avais très bien compris cela, voir mon message au bistro et la première ligne de mon texte ci-dessus. Ce que je dénonce entre autres, c'est cette application à la lettre de recommandations faites pour l'édition sans tenir compte des spécificités de Wikipédia. On remarquera au passage que le « il faut éviter » semble être interprété comme une obligation et que le « toujours être précédée d’une virgule » est manifestement faux. –Akeron (d) 8 novembre 2012 à 02:01 (CET)

Voici le texte du Lexique, page 6 : « On proscrira la répétition des signes ou des lettres pour indiquer la pluralité [suivent les exemples concernant §, p. et f.] La même observation s'applique à « etc. », abréviation qui ne doit jamais être renvoyée au commencement de la ligne (particulièrement à la fin d'un alinéa), ni répétée, ni suivie de points de suspension. » Pour la virgule, voir l'article « Et cetera », qui ne fait que respecter les règles classiques de la ponctuation française, règle qui d'ailleurs est reprise dans le Lexique, page 146 : « On ne mettra pas de virgule avant une parenthèse, un tiret ou un crochet, à moins que le crochet annonce une restitution. On fera précéder « etc. » d'une virgule. » Daniel*D 8 novembre 2012 à 03:03 (CET)

Concernant votre a priori sur « des recommandations qui seraient faites pour l'édition », je vous conseille la lecture de l'avant-propos du Lexique (ou à défaut le l'introduction desdites recommandations qui en reprend l'esprit) qui dit, entre autres choses : « Comme les règles de savoir-vivre, les règles de typographie s'adaptent aux nouvelles techniques de communication, mais l'on ne saurait se soustraire à certaines contraintes sans lesquelles la vie deviendrait rapidement insupportable à chacun [...] Séduire le lecteur et faciliter la lecture résument les qualités d'une bonne typographie. [...] Sans prétendre à la rédaction d'un traité de typographie, c'est afin d'étendre l'usage de ce Lexique aux opérateurs de saisie des textes qu'on été ajoutés quelques conseils de composition [...] »

Daniel*D 8 novembre 2012 à 03:31 (CET)

Tout le problème est de vouloir appliquer aveuglément la moindre de ces règles sans se soucier de l'accessibilité pour les éditeurs, qui sont pourtant le cœur de Wikipédia. Encore une fois, l'espace insécable avant « etc. » devrait être automatiquement géré par MediaWiki, comme c'est déjà le cas pour les deux-points, le pourcentage, les guillemets, etc. En attendant il n'y a rien de grave à ce que quelques « etc. » se retrouvent parfois à ligne. –Akeron (d) 8 novembre 2012 à 12:19 (CET)

On attend depuis plusieurs années que ce soit le cas, mais rien ne bouge. Si, on s'en prend aux palliatifs sans rien mettre en à la place, c'est on ne peut plus constructif ! Daniel*D 8 novembre 2012 à 12:47 (CET)

Comme si le simple fait d'attendre allait régler le problème !? Où sont les demandes aux développeurs ? à moins que vous ayez préféré vous contenter d'un pis-aller avec des modèles au lieu de chercher une vraie solution. –Akeron (d) 8 novembre 2012 à 12:58 (CET)

Ce n'est pas d'aujourd'hui que j'ai soulevé cette question. Daniel*D 8 novembre 2012 à 14:27 (CET)

Aucune chance que les développeurs suivent cette page. –Akeron (d) 8 novembre 2012 à 15:26 (CET)

Non, pour moi, le cœur de Wikipédia, ce n'est pas les contributeurs. C'est l'encyclopédie elle-même. C'est nous qui sommes au service de Wikipédia, pas Wikipédia qui est à notre service. Ensuite, par ordre d'importance, pour moi, je mettrais les lecteurs. Et seulement ensuite les contributeurs que nous sommes 78.251.237.169 (d) 15 novembre 2012 à 12:08 (CET)

Sans contributeur il n'y aurait jamais eu de lecteur, c'est toute de même la base du projet et sa force. « Bienvenue sur Wikipédia - Le projet d'encyclopédie libre que vous pouvez améliorer ». Et il ne faut pas oublier les enjeux, combien de lecteur on perd parce qu'une espace n'est pas insécable, par rapport à combien d'éditeur on perd parce que le wikitext est de plus en plus complexe avec des modèles partout... –Akeron (d) 15 novembre 2012 à 15:22 (CET)

Peu importe, cela tient dans ce cas du bidouillage. Tant que le W3C dit qu’il faut expliciter les abréviations par des infobulles, on le fait, on a pas le choix. Donc c’est simple : soit un programmeur motivé implante un patch mediawiki qui remplace les « etc. » dans le texte par « <abbr xml:lang="la" lang="la" title="et cetera">etc.</abbr> » et insère automatiquement une espace insécable, soit on garde celui-ci. Cordialement --Pic-Sou 7 novembre 2012 à 21:26 (CET)

« Tant que le W3C dit qu’il faut expliciter les abréviations par des infobulles^{[réf. nécessaire]} »

Ce n'est pas du tout ce que je lis sur http://www.w3.org/wiki/HTML/Elements/abbr :

« Abbreviations for which the author wants to give expansions, where using the abbr element with a title attribute is an alternative to including the expansion inline. »

« Abbreviations that are likely to be unfamiliar to the document's readers, for which authors are encouraged to either mark up the abbreviation using a abbr element with a title attribute or include the expansion inline in the text the first time the abbreviation is used. »

Il est clair qu'une abréviation comme « etc. » est suffisamment connue pour ne pas avoir à être explicitée et qu'il n'y a aucune obligation. –Akeron (d) 7 novembre 2012 à 21:39 (CET)

Soit, mais dans les WCAG 2.0, je lis : « 3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA) ». Ici, il n’est pas précisé quelles abréviations sont concernées. --Pic-Sou 7 novembre 2012 à 21:50 (CET)

Je me demande quel niveau d'accessibilité on atteint pour les éditeurs avec ce genre de modèle... –Akeron (d) 8 novembre 2012 à 12:26 (CET)

WCAG 2.0 dit bien « lorsque l'abréviation ne fait pas encore partie de la langue courante ». –Akeron (d) 15 novembre 2012 à 15:30 (CET)

Traduction ? 78.251.237.169 (d) 15 novembre 2012 à 12:08 (CET)

Il n'y a pas d'obligation, c'est le choix de l'auteur et c'est recommandé pour les abréviations non courantes et lors de la première occurrence. –Akeron (d) 15 novembre 2012 à 15:28 (CET)

Au passage, je me demandais, pour le problème des virgules : ne pourrait-on pas faire en sorte que {{etc.}} rende « etc. » sans la virgule, et créer un modèle {{, etc.}} qui rendrait « , etc. » avec la virgule et l’espace ? Ce serait peut-être plus simple. Cordialement --Pic-Sou 7 novembre 2012 à 21:28 (CET)

O_ô deux modèles au lieu d'un, plus simple ? Esprit Fugace (d) 7 novembre 2012 à 21:42 (CET)

Bah je pense que cela permettra d’éviter les double-virgules et double-espace… Cordialement --Pic-Sou 7 novembre 2012 à 21:50 (CET)

Si le modèle est ainsi fait, c'est que c'est le seul moyen de faire en sorte que « etc. » ne soit pas reporté en début de ligne dans un texte et qu'il soit bien précédé d'une virgule. L'option sans virgule n'est qu'une option qui a été ajoutée ensuite pour des cas où cette abréviation arrive en fin d'une liste. Daniel*D 8 novembre 2012 à 00:12 (CET)

Quelques articles qui contiennent le modèle mal utilisé du type « mot, , etc. », « mot,, etc. » ou « mot , etc. » :
Particule (onomastique), Acier inoxydable, Influence sociale, Terre (électricité), Commentaire littéraire au baccalauréat français, Agboville, Alpes scandinaves, Arabes, Stéphane Lupasco, Dégoût, Véhicule tout-terrain, Le Phény, Grue médiévale, Warehouse 13, Régression hédonique, Construction en terre, Lexique de la charpente, Kilo, Kenya, Science-fiction, Dragon Ball, Conducteur (physique), Transcription et translittération, etc.  –Akeron (d) 7 novembre 2012 à 22:52 (CET)

On ne pourra jamais empêcher la mauvaise utilisation de n'importe quoi, même d'un modèle aussi simplissime. Regardons plutôt tous les articles où le modèle améliore les choses. Daniel*D 8 novembre 2012 à 00:17 (CET)

Voila, environ quinze minutes sans forcer, et toutes ces horreurs sont corrigées (plus quelques trucs, au passage, mais il reste du travail dans ces articles...). Daniel*D 8 novembre 2012 à 19:42 (CET)

sc

scriptiocontinua

Lesespacesontdénaturélatranscription
deslangues.Jemilitecontrel’utilisation
decetartificeinutile.

Ce n'est pas parce qu'« On ne pourra jamais empêcher la mauvaise utilisation de n'importe quoi » qu'il faut créer des trucs aussi peu intuitifs qui génèrent de ce fait des erreurs. –Akeron (d) 8 novembre 2012 à 01:54 (CET)

Compte tenu du nombre d'erreurs que j'ai corrigées grâce à ce modèle (et à WikEd) je suis bien placé pour dire qu'il a réparé bien plus d'articles qu'il n'en a détériorés. Et je l'ai fait au début très simple pour remplacer ceci : {{nobr|, etc.}}, qui était un autre pis-aller que j'avais rencontré au fil de mes lectures, ce n'est qu'ensuite que les choses ont été complexifiées, comme souvent avec les modèles. Les articles cités ci-dessus ne sont pas entachés que de la mauvaise utilisation du modèle, que je me ferais un plaisir de rectifier, sauf bien entendu si je ne peux plus utiliser l'outil. Ou bien par un autre moyen plus simple et visible dans le code. De toutes façons en cas de suppression il faudra bien réparer les dizaines de milliers de liens rouges, j'attends donc le robot qui le fera, et par la même occasion sur toutes les pages de Wikipédia où « etc. » est mal introduit, indépendamment de la mauvaise utilisation du modèle. Ce qui est bien plus fréquent, sinon bien entendu, je n'aurais pas éprouvé le besoin de cette création. Daniel*D 8 novembre 2012 à 02:25 (CET)

Les gens utilisent mal Wikipédia, supprimons Wikipédia : voilà résumée cette PàS. Daniel*D 8 novembre 2012 à 08:31 (CET)

N'importe quoi et si le modèle est supprimé il y aura évidemment 0 liens rouges, le modèle sera effectivement supprimé que lorsqu'il ne sera plus utilisé, il suffit qu'un robot remplace ses occurrences. Je veux bien m'en occuper et même corriger au passage les mauvais usages et mettre l'espace insécable directement dans le wikitext. Encore une fois, la bonne solution c'est de faire comme pour les deux-points, les point-virgules, etc. En attendant il n'y a rien de dramatique et ce n'est pas ce pis-aller actuel qui va motiver ceux qui y tienne à faire évoluer MédiaWiki. –Akeron (d) 8 novembre 2012 à 12:35 (CET)

Et votre espace insécable sera visible dans le code ? Daniel*D 8 novembre 2012 à 12:51 (CET)

Avec l'éditeur standard non, mais ça n'empêche pas le rendu correct par le navigateur, ce qui est le but. –Akeron (d) 8 novembre 2012 à 13:02 (CET)

Insérer des espaces insécables invisibles (par toutes sortes de moyens pas forcement pérennes selon les navigateurs) c'est faire en sorte que le rédacteur qui repassera derrière n'ait pas d'autre moyen pour voir la bonne typographie (évidemment en dehors de ce qui saute aux yeux dans le texte de l'article) qu'en regardant la page HTML (Ctlr U) ou en réduisant la fenêtre d'édition afin de constater les sauts de lignes inopportuns. Il est bien évident qu'un modèle bien utilisé ou tout autre moyen visible dans le code répond à ce problème, tant que MediWiki n'est pas corrigé et que les utilisateurs en sont informés. Daniel*D 8 novembre 2012 à 13:49 (CET)

Je suggère de supprimer également le LaTeX qui encombre inutilement le code dans les articles scientifiques, en rend la lecture difficile et empêche les nouveaux de contribuer intelligemment, dans le même esprit. Daniel*D 8 novembre 2012 à 08:42 (CET)

Encore du grand n'importe quoi, comme si supprimer les équations mathématiques des articles scientifiques était comparable à l'absence d'une espace insécable avant « etc. ». D'autre part, je connais un mathématicien qui ne comprend rien à l'informatique, et bien le seul truc qu'il connaît c'est LaTeX, car c'est le meilleur moyen d'écrire proprement des équations mathématiques sur un ordinateur. L'apprentissage de LaTeX doit simplement faire partie des cursus récents, il s'agit donc juste d'un langage technique standard dans ce domaine. –Akeron (d) 8 novembre 2012 à 12:53 (CET)

On a encore le droit de plaisanter, non ? Daniel*D 8 novembre 2012 à 13:46 (CET)

Mes excuses, mais tu utilises tellement de sophismes sur cette page que j'ai cru à un raisonnement par l'absurde avec un homme de paille. –Akeron (d) 8 novembre 2012 à 15:20 (CET)

Pffff. Pas d'autres arguments que les attaques personnelles ? Daniel*D 8 novembre 2012 à 15:34 (CET)

De nombreux arguments de bon sens ont été donnés auxquels tu réponds souvent par un simple homme de paille, par exemple le dernier avec Marc Mongenet qui résume bien la situation, ta réponse « Les règles et recommandations de Wikipédia, c'est du pipeau. Intéressant. »... Dire qu'il y a beaucoup de sophismes dans tes propos n'est pas une attaque personnelle. –Akeron (d) 8 novembre 2012 à 15:51 (CET)

En cette matière, vous êtes expert. En ne retenant qu'une partie de la discussion et en faisant mine de ne pas voir ma réponse argumentée, pertinente et directement en rapport avec la remarque précédente de Marc Mongenet, arguments auxquels il ne répond pas, bien entendu. D'où ma conclusion. En ce sens vos remarques sont bel et bien des attaques personnelles. Daniel*D 8 novembre 2012 à 17:26 (CET)

Je parlais justement de sa réponse à ce message que tu indiques, il résume bien la situation. Au fond c'est juste que tu refuses de comprendre que les règles typographiques ne doivent pas forcément être appliquées aveuglément sans tenir compte de tout le reste, notamment l'accessibilité pour les nouveaux contributeurs. Non il n'y a pas d'attaques personnelles, ça commence à bien faire ces fausses accusations. –Akeron (d) 8 novembre 2012 à 21:24 (CET)

« Pas obligatoire »

Plusieurs avis conserver semblent penser que puisque ce modèle n'est pas obligatoire, il n'y a pas de problème. Pourtant les problèmes signalés ne viennent pas de là. L'existence du modèle fait qu'il est introduit à la chaîne dans les articles, donc tout le monde risque d'être confronté à son usage en voulant modifier un texte. D'une part ce modèle ajoute de la complexité pour pas grand chose, d'autre part son fonctionnement contre-intuitif engendre de nombreuses erreurs. –Akeron (d) 8 novembre 2012 à 16:08 (CET)

Cette affirmation « engendre de nombreuses erreurs » est largement abusive, en quelques minutes j'ai corrigé très facilement toutes celles signalées sur le bistro et quelques-unes ci-dessus. J'ai aussi mieux documenté le modèle. Daniel*D 8 novembre 2012 à 17:26 (CET)

Qu'elles soient corrigeables n'empêche pas qu'il y en ait beaucoup et il y a en a bien plus que ce qui a été donné ici. La documentation du modèle est une bonne chose mais il est illusoire de croire que quelqu'un qui édite simplement un article va aller lire la doc de tous les modèles, son fonctionnement contre-intuitif restera une source perpétuelle d'erreurs. –Akeron (d) 8 novembre 2012 à 21:32 (CET)

Comme je viens de bleuir le lien de Picsou {{, etc.}} et de compléter la doc, ton argument recevable, en effet (bien que la façon pour moi la plus simple soit de taper {{etc}} ou d'ajouter d'un seul un clic de souris les accolades sur un « ,etc », « etc. » ou « etc » déjà présent dans le texte — les deux dernières formes étant extrêmement fréquentes, et là ce sont tout simplement des fautes de ponctuation ou d'orthographe normalement prohibées —, afin de se conformer à la bonne typographie, en ajoutant simplement l'espace insécable manquante) ne tient plus. Il faudrait un peu de mauvaise foi pour prétendre le contraire. Il ne restera plus que la « prise en otage » d'un modèle pris au hasard — dans une « croisade » qui se trompe de cible sur la complexité du code wiki —, parmi une multitude de trucs infiniment plus complexes et le plupart du temps imbitables pour prétendre le contraire. Cordialement, Daniel*D 9 novembre 2012 à 12:09 (CET)

La création d'une redirection ne change strictement rien au fonctionnement non intuitif de {{etc.}} qui reste utilisé dans des milliers d'articles. La documentation, comme indiqué précédemment, ne changera rien pour la plupart des utilisateurs qui découvrent ce modèle dans le texte d'un article. Tu dépasses encore les bornes en m'accusant de mauvaise foi. –Akeron (d) 9 novembre 2012 à 14:06 (CET)

C'était juste une supposition mise au conditionnel et qui n'était pas nominative, mais tu sembles vouloir me donner raison. Daniel*D 9 novembre 2012 à 14:11 (CET)

Je trouve moi aussi que tu dépasses les bornes. Une page de discussion de WP n'est pas un ring pour échanger des accusations en feignant de les mettre au conditionnel, mais des arguments. --Rigoureux (d) 9 novembre 2012 à 14:40 (CET)

La mise au conditionnel n'est pas feinte : « il faudrait » : conditionnel présent du verbe falloir. Ou alors c'est me faire un procès d'intention. Pour le reste, je sais assez bien ce qu'est une pdd, en particulier d'une PàS et surtout celle-là, merci. Daniel*D 9 novembre 2012 à 17:15 (CET)

Tu prétends avoir résolu le problème alors que ça ne change quasiment rien et tu ajoutes qu'« Il faudrait un peu de mauvaise foi pour prétendre le contraire », c'est bien une attaque en accusant d'emblée ceux qui ne sont pas d'accord avec toi d'être de mauvaise foi, pour le restes tu ne fais que jouer sur les mots. –Akeron (d) 9 novembre 2012 à 17:58 (CET)

Comment faire plus intuitif, mystère. J'ai bien compris qu'à part la suppression du modèle, rien ne trouvera grâce à tes yeux. Je propose donc qu'on en reste là. Daniel*D 9 novembre 2012 à 18:08 (CET)

La suppression est la solution la plus simple vu le peu qu'apporte ce modèle et les problèmes qu'il cause. Difficile de le rendre plus intuitif avec ce système car on est très limité, ce qu'il faudrait c'est qu'il détecte tout seul s'il faut ajouter la virgule ou non, mais ce n'est pas possible avec un modèle, ça devrait être fait au niveau de MediaWiki. Sinon, il serait plus clair dans le wikitext pour éviter les problèmes de virgules que toutes les occurrences qui ajoutent la virgule utilisent {{, etc.}} et non {{etc.}}. –Akeron (d) 9 novembre 2012 à 18:25 (CET)

Ok avec {{, etc.}} et non {{etc.}}. Daniel*D 9 novembre 2012 à 19:05 (CET)

Il serait peut-être utile de préciser que dans l'hypothèse où ce modèle serait conservé, le « pas obligatoire » implique qu'il peut être librement retiré si le contributeur ne le juge pas nécessaire. Je ne parle pas de le faire à la chaîne, bien qu'il soit souvent introduit de cette manière. Dans l'idéal, le contributeur informé, devra prendre soin de mettre l'espace insécable après la virgule afin de perpétuer le stricte respect de la typographie. –Akeron (d) 9 novembre 2012 à 18:12 (CET)

Parfaitement d'accord. À la condition que ladite espace ne soit pas invisible, car il va de soit que dans l'impossibilité de s'apercevoir qu'elle est effectivement présente, le retour au modèle serait justifié. Daniel*D 9 novembre 2012 à 18:21 (CET)

Par extension la même remarque s'applique à tous les modèles créés pour mettre des espaces insécables là où elles doivent être et dont on pourrait se débarrasser sans aucun remord le jour béni ou cette fameuse espace sera enfin visible dans le code, comme dans tout bon traitement de texte qui se respecte. Daniel*D 9 novembre 2012 à 18:34 (CET)

Le but d'une espace insécable n'est pas d'être visible mais d'éviter un éventuel retour à la ligne. Le fait qu'elle ne soit pas visible dans des configurations de base des navigateurs ne l'empêche pas de fonctionner correctement, ce qui est le but. –Akeron (d) 9 novembre 2012 à 18:29 (CET)

Encore une fois je suis bien d'accord, mais c'est tourner en rond et se voiler la face (cela dure sans doute depuis toujours avec cette question sur WP) que de vouloir ignorer le fait que si ces foutues espaces sont invisibles dans le code, on ne peut matériellement pas faire autrement que les ignorer et donc les remettre, soit par un modèle, soit par « &nbsp; » (truc qui a été retiré des caractères disponibles sous le fenêtre de modif depuis pas mal de temps, pourquoi ?), résultats visibles et pérennes. Soit par toute autre manip, combinaison de touches, clavier enrichi, etc., moyens qui peuvent conduire à insérer une insécable qui sera transformée en espace simple, involontairement, par une prochaine visite du code par le navigateur d'un autre contributeur, ce qui n'aura donc rien résolu. Daniel*D 9 novembre 2012 à 19:05 (CET)

À toi d'utiliser une éditeur qui gère ce genre de chose si tu y tiens, il y a par exemple une extension Firefox [3] qui permet d'utiliser un éditeur externe. Je pense que la plupart des navigateurs actuels n'effacent pas les insécables, elles seront plutôt perdues lors d'un copier/coller ou d'une modification du texte à cet endroit, je compte faire des tests prochainement. Il faut pas trop se faire d'illusions, Wikipédia est une encyclopédie faite pour le plus grand nombre, les priorités de la WMF sont clairement de simplifier l'édition pour attirer plus de contributeurs, pas d'avoir une typo irréprochable. Je n'ai rien contre une bonne typo, mais pas au prix où on nous l'impose actuellement. –Akeron (d) 9 novembre 2012 à 19:44 (CET)

Je n'ai strictement aucun problème pour insérer le bidule en question (je connais au moins quatre façons de la faire et mon clavier est enrichi) mais je pense que mon cas personnel n'intéressera personne. Pourtant je trouve sensé de faire en sorte que les espaces insécables soient visibles de tous afin qu'il n'y ait aucun doute sur leur présence, en attendant que la question ne se pose plus. Que la WMF fasse en sorte de résoudre les problèmes techniques que son MediaWiki génèrent et tout le monde sera satisfait (ce qui ne doit pas être si difficile que ça, puisque déjà en place pour d'autres cas), au lieu d'imposer un mode de contribution contraire aux usages normaux et aux sources (ce qui est un comble), aux bénévoles qui n'imposent rien, eux. C'est le monde à l'envers. Il va de soi que si le besoin d'avoir recours à un modèle pour mettre des insécables n'existait pas il faudrait être vicieux pour le faire. J'ai moi-même supprimé un nombre considérable de modèles {{unité}} utilisés à tord pour %, entre autres. Daniel*D 9 novembre 2012 à 20:15 (CET)

L'outil que je t'ai indiqué c'était pour que tu puisses les voir. Ce n'est pas « le monde à l'envers », c'est une encyclopédie accessible au plus grand monde, donc avec l'éditeur par défaut des navigateurs internet, qui n'affichent pas les espaces insécables. Ce que tu désire c'est de la typo au niveau professionnel, qui se fait avec des logiciels adaptés, mais WP n'a pas été conçue dans ce but, ça viendra peut-être un jour mais le problème est qu'en attendant vous bricolez des trucs qui causes d'autres problèmes et qui sont imposés à tout le monde, notamment au détriment de l'ouverture aux nouveaux. –Akeron (d) 10 novembre 2012 à 01:44 (CET)

OpenOffice Writer, par exemple, disponible sur le moindre PC en version familiale (donc non « professionnelle »), permet d'éditer beaucoup plus simplement que MediaWiki et entre autres choses affiche les espaces insécables. Pas étonnant que les nouveaux soient surpris en arrivant sur WP. Même en 2006, lorsque j'étais nouveau, donc bien avant l'inflation du référencement puis des modèles qui vont avec, des infobox diverses et variées, des tableaux et de leur syntaxe absconse, des drapeaux, sans oublier les bandeaux dispensables, c'était loin d'être simple. Mais si tous ces trucs ont été ajoutés il doit bien y avoir une raison, mon petit doigt me dit qu'il faudrait plutôt la chercher dans la médiocrité de l'outil qui nous est imposé, pas dans la perversité des contributeurs qui ont, peu à peu, installé des machins pour y pallier.
Sur les éventuels problèmes et « l'imposition à tout le monde », comme c'est du bis repetita placent, je n'y reviens pas.
Pour revenir à nos moutons, il n'y a rien de bien compliqué, je suppose (en vérité à la main c'est bien plus compliqué, avec WikEd, c'est enfantin), dans l'éventualité ou le modèle serait supprimé et en attendant les calendes grecquesl'évolution de notre bien aimé logiciel, à ce que ton bot (au hasard) insère des « &nsbsp; ». Bon le risque c'est que quelqu'un les enlèves en éditant (se disant, c'est quoi ce truc horrible) et dans ce cas... Décidément, un modèle c'est mieux, en l'état actuel.
Daniel*D 10 novembre 2012 à 02:55 (CET)

Ooo w est un traitement de texte, il est fait pour ça... MediaWiki est un CMS qui tourne sur des serveurs, ensuite tu utilises un navigateur internet pour communiquer avec, ce navigateur n'est pas un traitement de texte. Tu crois vraiment que ce qui surprend les nouveaux sur Wikipédia c'est l'absence de visibilité de l'espace insécable ? c'est ridicule. Il faudrait peut-être réaliser que les typographes à la retraite, nostalgiques des caractères en plomb, sont une infime minorité. La plupart des gens se foutent complètement qu'il y ait ou non une espace insécable avant « etc ». Tu trouves MediaWiki médiocre, mais il fait plutôt bien ce qu'il est censé faire. La gestion de la typo française n'est pas parfaite, mais c'est le même principe que pour Wikipédia, c'est facile de critiquer alors que tout le monde peut l'améliorer. –Akeron (d) 10 novembre 2012 à 04:01 (CET)

Argumentum ad personam, bravo ! Et, en vérité que sais-tu de moi ? Et puis ta dernière phrase est en parfaite contradiction avec ta position. Daniel*D 10 novembre 2012 à 09:31 (CET)

et pas de contradiction à rappeler que MediaWiki est un logiciel libre que tout le monde peut améliorer, utiliser des modèles à la place de cela est un pis-aller qui crée d'autres problèmes. –Akeron (d) 10 novembre 2012 à 11:56 (CET)

Akeron, j’ai du mal à suivre ta position. « le même principe que pour Wikipédia, c'est facile de critiquer alors que tout le monde peut l'améliorer » : bah justement, ce modèle que tu insistes pour supprimer est une proposition d’amélioration faite par Daniel*D, pour gérer cette norme typographique ! Donc il ne fait justement pas que critiquer, contrairement à toi qui n’a pour l’instant rien fait pour régler le problème de typographie. Cordialement --Pic-Sou 10 novembre 2012 à 14:00 (CET)

Cf ma précision, je parle d'améliorer le logiciel MediaWiki, pas de créer un pis-aller qui crée d'autres problèmes (solution pire que le mal). –Akeron (d) 10 novembre 2012 à 14:39 (CET)

Proposition d’extension

Bonjour. Suivant la proposition infra d’Od1n, j’ai contacté une développeuse, Karima Rafes, pour savoir s’il serait possible de développer une extension permettant de gérer une liste de remplacements automatique lors du parsage des pages. Par exemple, en définissant la règle "/, ?etc(\.{0,4}|…\.?)/" => ", <abbr lang="la" xml:lang="la" title="et cetera">etc.</abbr>",, les chaînes de caractères « ,etc.. », « , etc…. » et « , etc. » seraient toutes les trois remplacées par la syntaxe correcte, sauf bien sûr entre balises <nowiki>. Pensez-vous que cela conviendrait pour gérer tant les problèmes de typographie, d’accessibilité et de simplicité de l’édition ?

Cordialement --Pic-Sou 10 novembre 2012 à 14:24 (CET)

Je pense qu'il faudrait juste se limiter à l'espace. Vouloir intégrer d'autres corrections à ne niveau ne me semble pas pertinent, quelque chose comme « etc… » doit être corrigé dans le wikitext, pas au niveau du rendu. Et pour l'abréviation, je pense toujours qu'expliciter la moindre occurrence d'une abréviation aussi connue n'est pas utile. –Akeron (d) 10 novembre 2012 à 14:59 (CET)

Assez d'accord avec ça. Mais aussi, pourquoi pas, avec l'intégralité de ce que propose Pic-Sou puisque ça remplacerait tout ce que le modèle actuel fait (alors qu'à sa création son seul effet était typographique) tout en satisfaisant la demande de moins de modèles dans le code. Il restera peut-être ceux qui oublient la virgule. Daniel*D 10 novembre 2012 à 15:28 (CET)

Bah la regepx que je propose permet d’éviter notamment les « etc… ». Mais bon, peut-être que cela risque de créer des faux-positifs…

En ce qui concerne la pertinence ou non de l’abréviation, « quod abundat non vitiat ». Ne nous privons pas d’apporter une correction, aussi minime soit-elle, quant elle ne coûte rien.

Cordialement --Pic-Sou 10 novembre 2012 à 23:56 (CET)

Ce n'est pas à ce niveau (rendu du parser) que doit se faire une correction comme « etc… », il faut simplement corriger le wikitext, avec AWB par ex.

Expliciter l'abréviation n'est pas une « correction » et son coût n'est pas nulle, « le mieux est l’ennemi du bien ». –Akeron (d) 11 novembre 2012 à 02:00 (CET)

Et pourquoi la correction ne se ferait-elle pas ici ? Ce serait quand même plus simple que de pourrir les listes de suivi avec des centaines de « relectures » faites avec AWB, non ?

Quant au fait que le coût de l’abréviation « n'est pas nulle »… Tu peux détailler, stp ?

Pic-Sou 11 novembre 2012 à 11:28 (CET)

Parce que ce n'est pas le bon endroit pour faire ces corrections, rendre une espace insécable dans certains cas, pourquoi pas, car ça ne change que de façon très minime la mise en page. Faire automatiquement des corrections du texte à ce niveau serait une mauvaise chose, le texte affiché doit correspondre le plus possible à ce qui est utilisé. Cela empêcherait de repérer facilement certaines erreurs, ça rendrait l'affichage correct du texte complètement dépendant de cette extension, ça provoquerait des confusions pour les contributeurs qui ne verraient plus certaines des choses qu'ils ont pourtant entrées. Si on commence à faire ce genre de correction, il n'y a pas de raison de se limiter à « etc. », d'autres seront introduites, donc des débats, des critères à définir... Il faudrait que chaque changement soit indiscutable, ce qui est loin d'être évident avec la diversité des usages dans le monde. Des faux positifs à ce niveau serait très dommageables et provoquerait sans doute de l'exaspération chez les contributeurs. Bref, le plus simple est de très loin de corriger l'erreur à la source, juste en changeant le texte. Il suffit d'utiliser le bot flag pour ne pas pourrir les listes de suivi.

Pour l'abréviation, déjà ça serait se compliquer la vie et rendre obligatoire quelque chose qui n'est pas nécessaire. Ensuite il y a forcément un coût supplémentaire à ajouter quelque chose. D'un part par la méthode d'introduction : avec un modèle (complexification du wikicode, gourmand en ressource pour les serveurs, cible de choix pour les vandalismes) ; avec une extension c'est moins coûteux mais c'est plus long et difficile à développer/maintenir et il y tout de même du temps passé à exécuter ce code. D'autre part, le résultat augmente la taille du code html : « etc. » prend 4 octets, « <abbr lang="la" xml:lang="la" title="et cetera">etc.</abbr> » 59 octets, donc plus de 14 fois plus gros. Ces surcoûts restent faibles individuellement mais en multipliant par de nombreux cas et de nombreux articles, cela peut devenir non négligeable, particulièrement dans certaines situation, par exemple connexion bas débit comme décrit récemment ici. Tout cela, je le rappelle, pour quelque chose qui n'est pas nécessaire... –Akeron (d) 11 novembre 2012 à 14:36 (CET)

« [...] le texte affiché doit correspondre le plus possible à ce qui est utilisé. Cela empêcherait de repérer facilement certaines erreurs [...] »

« [...] ça provoquerait des confusions pour les contributeurs qui ne verraient plus certaines des choses qu'ils ont pourtant entrées [...] »

Sur cette ligne, je rentre un certain nombre d'espaces insécables invisibles dans le code wiki           

Question, sans aller voir la page HTML, combien en ai-je mis ?

Sur cette ligne, je rentre des caractères dont je sais que MediaWiki les précède ou les fait suivre automatiquement par lesdites espaces, de façon correcte :  ;  !  ?  % «   »

Je peux en déduire à l'œil nu qu'il y en a sept. Dans le cas précédent il est impossible, uniquement en regardant la page code wiki, de donner la réponse.

 

D'où la nécessité de palier à ce manque, soit en améliorant le logiciel (par exemple, pour le cas particulier de « etc. » en faisant comme pour les exemples ci-dessus, plus généralement en rendant l'espace insécable visible par, par exemple, un petit rectangle gris), soit en tapant &nsbsp; (seule combinaison reconnue par tous les navigateurs), soit en utilisant des modèles.

C'est ainsi qu'un grand nombre de modèles ont vu le jour, dont probablement le plus connu et le plus utilisé est le modèle Unité, mais il est loin d'être le seul. Prétendre résoudre ce problème en proposant, plus ou moins au hasard, un modèle à la suppression, en le chargeant de tous les maux, tout en refusant toutes les propositions de remplacement sensées (en dehors des arguments comme — je résume — : « même si ça ne se voit pas ça rempli son rôle » — il faut être devin, ou un peu spécialisé en informatique et faire des acrobaties pour s'en assurer —, « on s'en fout de mettre la virgule ou l'espace insécable » — autant encourager les fautes —, « c'est difficile de taper quatre accolades » — pourquoi pas n'importe quel caractère du clavier —, « ça introduit des erreurs » — comme si on pouvait empêcher quelqu'un de ne pas comprendre des choses simples —, « il n'y a qu'a remplacer « etc. » par des points de suspension » — autant interdire l'usage de certains mots —, « c'est trop compliqué », « encore un truc de geek », etc.) est tout à fait contre productif.

Daniel*D 12 novembre 2012 à 11:42 (CET)

Akeron : là encore, j’ai du mal à vous suivre. Un coup, il faudra éviter de sur-utiliser l’extension parce qu’elle pourrait être longue à exécuter et que le code HTML produit sera plus long (au passage : « 14 fois plus gros », la belle affaire, sur des pages dix-mille fois plus lourdes, c’est loin d’être significatif…), mais ensuite, ça ne pose aucun problème de devoir faire passer des armées de robots pour remplacer les « etc… » par des « etc. » qui, là, chargeront sans aucun doute bien plus le serveur. Une extension comme celle-ci serait une occasion de faire disparaître d’un coup tous les « pp. », les « " », les « etc... » et autres incorrections graves, pourquoi ne pas vouloir en profiter ? Cordialement --Pic-Sou 12 novembre 2012 à 12:36 (CET)

Au passage : il faut quand même spécifier que « etc. » est un mot latin… Cordialement --Pic-Sou 12 novembre 2012 à 13:31 (CET)

Ce n'est pas ce qu'ai dit, c'était juste une réponse à ton affirmation fausse que ça « ne coûte rien » et à ta demande de précision « le coût de l’abréviation « n'est pas nulle »… Tu peux détailler, stp ? ». J'ai donné les autres raisons principales pourquoi c'est une mauvaise idée de faire ce type de correction à ce niveau (en dehors des espaces insécables). Après si tu y tiens de tu peux toujours essayer de faire implémenter et accepter un tel truc, bon courage...

Daniel*D, le cas des espaces insécables est différent, ils s'affichent de la même façon qu'une espace normale, le changement est donc invisible pour le lecteur, ce qu'il voit correspond bien à ce qu'il tape. Alors que si quelqu'un tape volontairement « etc... » et ne le voit pas s'afficher, il ne va pas comprendre pourquoi, revenir en arrière, s'énerver... D'autre part il y aura des faux positifs avec ce genre de correction, par exemple des titres d'œuvres, des liens externes... La visibilité de l'espace insécable en mode édition serait surtout utile pour ceux qui connaissent bien son utilisation, pour la très large majorité des gens je doute que ça fasse la moindre différence, voire même que ça les dérange. L'idéal serait d'avoir l'option avec le futur éditeur visuel wysiwyg. Pour ceux qui y tiennent vraiment, il est actuellement possible de configurer un éditeur externe, par exemple en un clique j'obtiens ça dans mon éditeur externe, il est alors facile de compter tes 6 espaces insécables qui sont soulignées en gris. –Akeron (d) 12 novembre 2012 à 16:00 (CET)

Quant à « faire passer des armées de robots », ils passent déjà pour d'autres choses, donc il peuvent faire ce genre de correction mineure au passage sans le moindre surcoût, c'est déjà le cas pour de nombreuses modifications qui ne sont jamais faites toutes seules, comme mettre une majuscule au début d'un modèle ou de la destination d'un lien. D'autre part, une correction dans le wikitext corrige un seul fois l'erreur, alors que le faire à l'exécution nécessite de le refaire à chaque fois, ce qui est bien plus coûteux dans le temps. –Akeron (d) 12 novembre 2012 à 16:14 (CET)

C'est gentil, mais j'ai écrit : « uniquement en regardant la page code wiki », ce que la grande majorité des contributeurs se contentent de faire.

« [...] ce qu'il voit correspond bien à ce qu'il tape », hélas. Et ce n'est pas le cas ailleurs, comme je l'ai déjà dit et comme tu le prouves toi-même ici (c'était le but ).

« si quelqu'un tape volontairement « etc... » et ne le voit pas s'afficher, il ne va pas comprendre pourquoi, revenir en arrière, s'énerver... », alors cela sera parfait, et très didactique, encore mieux que ne l'est déjà le modèle.

Aucune réponse argumentée sur la question globale des modèles existants versus l'insécable, en dehors de la suppression de celui-ci, simplement pour l'exemple.

Daniel*D 12 novembre 2012 à 16:42 (CET)

Tu as écrit « Question, sans aller voir la page HTML, combien en ai-je mis ? », je te donne juste une solution possible et c'est bien le code wiki qui s'affiche dans l'éditeur. Ça ne m'étonne pas que tu trouves « parfait » que quelqu'un s'énerve parce le logiciel change ce qu'il fait sans lui dire et en lui laissant aucun contrôle, et ne pas oublier que dans certains cas, ça peut être parfaitement justifié (titres d'œuvres, liens externes, etc.). « Aucune réponse argumentée », ça a déjà été plusieurs fois expliqué, pour l'essentiel c'est une question de rapport coût/bénéfice. –Akeron (d) 12 novembre 2012 à 17:06 (CET)

Oui, en effet, il ne s'énervera qu'une seule fois, quand il aura compris son erreur, on peut espérer qu'il ne reproduira plus, ce qui sera un bénéfice pour lui et pour les autres, qui n'auront plus à corriger derrière lui. C'est un des principes de l'acquisition des savoirs. D'ailleurs c'est ainsi que l'on apprend sur Wikipédia : après avoir galérer pour trouver comment plein de trucs fonctionnent, généralement, c'est acquit. Sinon, anecdotiquement, les œuvres commençant par « Etc. » ne doivent pas encombrer les rayons. Daniel*D 12 novembre 2012 à 17:29 (CET)

Je doute que ce soit une seule fois et qu'il comprenne sans la moindre explication. Interdire définitivement par le logiciel toute œuvre ou lien externe que aurait le malheur de ne pas respecter certaines règles typographiques, alors que ça peut très bien avoir été voulu pour l'auteur, représenter autre chose, suivre un usage différent, etc., est juste une aberration de plus. –Akeron (d) 12 novembre 2012 à 17:46 (CET)

Il est évident qu’une telle extension ne s’exécuterait pas entre balises nowiki… Cordialement --Pic-Sou 12 novembre 2012 à 18:04 (CET)

Des fois on comprend des trucs sans la moindre explication écrite ou verbale. Daniel*D 12 novembre 2012 à 18:07 (CET)

Mettre des nowiki sur tous les titres d'œuvres qui posent problème et les autres faux positifs ? bon courage pour les détecter. –Akeron (d) 12 novembre 2012 à 18:22 (CET)

On le fait bien lorsqu’il s’agit de mettre des accolades, des chevrons des crochets, des apostrophes à la suite ou si pour une raison X ou Y, il ne faut pas qu’il y ait d’espace insécable quelque part… --Pic-Sou 12 novembre 2012 à 19:32 (CET)

Pour ces cas, ça sautent plus aux yeux, texte rouge ou gras, et souvent ça ne suffit pas pour les nouveaux qui laissent tel quel. Tu auras en plus tout l'existant à gérer qui a été introduit sans cette contrainte. –Akeron (d) 13 novembre 2012 à 00:41 (CET)

Avis

Entrez ci-dessous votre avis sur l’admissibilité du thème à l’aune de l’existence de sources extérieures et sérieuses ou des critères d'admissibilité des articles. Il est recommandé d'accentuer l'idée principale en gras (conserver, fusionner, déplacer, supprimer, etc.) pour la rendre plus visible. Vous pouvez éventuellement utiliser un modèle. N’oubliez pas qu’il est obligatoire d’argumenter vos avis et de les signer en entrant quatre tildes (~~~~).

Sources pour les règles typographiques

• Lexique des règles typographiques en usage à l’Imprimerie nationale, France, Imprimerie nationale, 2002 (réimpr. 2007, 2008, 2011), 6^e éd. (1^re éd. 1975), 197 p. (ISBN 978-2-7433-0482-9), p. 6 et 146, qui sert de référence à nos recommandations en matière de typographie

• Jacques André, Petites leçons de typographie, Institut de recherche en informatique et systèmes aléatoires (IRISA), Rennes, Éditions du jobet, 3 novembre 2012, 52 p. [PDF]

« etc. » : pages 12, 32, 33, 36 et 37.
Page 47 : « Ces conventions sont à appliquer pour les documents imprimés mais aussi pour ceux numérisés, le support (papier, écran...) n’ayant rien à voir. »

Conserver

1.  Conserver, selon le comte Ɲemoi – Évidemment. Ce 7 novembre 2012 à 19:56 (CET).

   Petits compléments de ce 15 novembre 2012 à 19:53 (CET) par le comte Ɲemoi – À présent que tout le monde a donné ses arguments, je m’explique : ce modèle est simple d’usage et est nécessaire pour rendre proprement un texte, si l’on ne veut pas surcharger de modèle : Nobr (ou de «   ») le code déjà assez complexe et illisible comme ça. Le gain d’accessibilité est également non-négligeable. Bien sûr, une modification de MediaWiki aiderait beaucoup, ça viendra d’ici dix ans j’en suis certain, mais nombre de personnes vont consulter des pages d’ici-là, et c’est à eux que l’on doit penser.

2.  Conserver Même si c'est chiant, ça rend le texte final propre. Tinodela ^[Tinodici] 7 novembre 2012 à 20:01 (CET)
3. Vois pas le problème. Il y a des modèles bien plus compliqués et bien moins pertinents que celui-là. SM ** ようこそ ** 7 novembre 2012 à 20:32 (CET)

   C’est un peu du WP:PIKACHU ça. --Pic-Sou 7 novembre 2012 à 21:17 (CET)

4.  Conserver. On ne peut pas se payer le luxe de passer outre les normes de typographie et surtout d’accessibilité. Ce modèle, contrairement à ce que prétendent ceux qui souhaitent sa suppression, simplifie énormément l’édition : il est beaucoup plus simple de taper « choux, hiboux{{etc}} » que « choux, hiboux, {{abrd|etc.|et cetera|la}} »… Cordialement --Pic-Sou 7 novembre 2012 à 21:17 (CET)

   Il n'est pas plus simple de taper "choux, hiboux, etc." ? Comme 99,999% du web français y arrive très bien ? Comme tape spontanément à peu près tout contributeur normalement constitué (car même ici les utilisateurs de ce genre de modèles de typo sont minoritaires parmi les rédacteurs) ? Esprit Fugace (d) 7 novembre 2012 à 21:44 (CET)

   C’est plus simple. Mais c’est incorrect. Nivelons par le bas, nivelons par le bas… --Pic-Sou 7 novembre 2012 à 21:51 (CET)

   Meuh non, le bas écrit "chous, hibous, etc..." ^^. Au fait, on a déjà un modèle pour faire le signe "..." plutôt que de taper trois points, ce qui risquerait d'être trop simple ? Esprit Fugace (d) 7 novembre 2012 à 22:04 (CET)

   Quel intérêt aurait un tel modèle ? Aucun. Contrairement à celui-ci. --Pic-Sou 7 novembre 2012 à 22:06 (CET)

   Les règles de typo (celles-là par exemple) n'exigent-elles pas que de tels points soient suivis d'une espace insécableOn me signale dans l'oreillette que j'aurais lu trop vite et mal compris la chose. Mes excuses. ? Sans compter les hérétiques qui en mettent quatre au lieu de trois.... Esprit Fugace (d) 7 novembre 2012 à 22:27 (CET)

   Pour appliquer une règle, encore faut-il qu’elle existe. --Pic-Sou 7 novembre 2012 à 22:34 (CET)

   Je propose de créer un modèle pour insérer une espace insécable avant le mot « On ». Martin // discuter 7 novembre 2012 à 22:57 (CET)

5.  Conserver idem Pic-Sou. De plus, ce modèle est utilisé dans plus de 10 000 pages . Le bruit généré par le remplacement du modèle en cas de suppression serait bien supérieur au prétendu problème qu'il ne pose pas. TED 7 novembre 2012 à 23:10 (CET)
6.  Conserver. Je ne vois pas le problème, il n'est marqué nulle part que ce modèle est obligatoire. Par contre il est bien pratique quand on le connaît. Gonzolito ^Pwet 7 novembre 2012 à 23:23 (CET)
7.  Conservation immédiate comme créateur du modèle et pour les raisons énoncées ci-dessus et ci-après. Daniel*D 8 novembre 2012 à 00:56 (CET)

   En pratiquant comme le dit Esprit Fugace, l'ennemie des modèles de typographie, ci-dessous (qui, je suppose, souhaite que Wikipédia respecte l'orthographe et donc ne verra pas d'inconvénient à ce que d'autres souhaitent que Wikipédia respecte aussi la typographie et qui au passage traite ceux-ci d'hypocrites) : on tape « etc. » avec quatre touches du clavier et ce faisant on introduit deux erreurs dans le texte : pour faire correctement son travail de rédactrice elle aurait dû taper une virgule, suivie d'une espace insécable (de son choix, par exemple &nbsp;), puis alors et seulement alors les quatre touches, ce qui fait un total de onze frappes... Que le modèle réduit à affectivement quatre plus les accolades qui se trouvent dans toute bonne boîte à outils du contributeur de base. Rappelons que l'utilisation de modèles n'est pas obligatoire sur Wikipédia mais que, par contre, certains modèles ont été créés par des contributeurs (qui ont droit aussi au respect et ne sont généralement pas des hypocrites) pour faciliter la tâche de ceux qui veulent bien se donner la peine d'améliorer sachant que dans le domaine de la présentation des articles il y a énormément de travail. Ce genre de suppression peut être ressenti comme une suppression d'outil voire une remise en cause de leur travail. Ce qui n'est pas encourageant à tout le moins. Daniel*D 8 novembre 2012 à 00:51 (CET)

   Ce ne sont pas les partisans d'une typographie "correcte" que j'ai qualifié d'hypocrites, ce que sont ceux qui prétendent qu'il est absolument nécessaire de se compliquer la vie pour ce faire, au point de dénier aux autres le droit d'avoir un avis contraire (comme l'a fait Pic-Sou). Certains modèles sont bien utiles : ils facilitent la vie pour un bénéfice évident. Celui-ci, non. Esprit Fugace (d) 8 novembre 2012 à 07:13 (CET)

   Personne n'oblige quiconque à se compliquer la vie avec ce modèle. Je vois bien que vous ne m'avez pas lu concernant la complication. Au contraire en supprimant ce modèle vous nous obliger à la complication. Mais sans doute le mieux, pour avoir une vie plus simple est-il de ne plus contribuer à Wikipédia, au moins on ne sera plus ainsi traité. Sinon, pour respecter la typographie correcte dans ce cas, comment faites-vous ? Daniel*D 8 novembre 2012 à 08:22 (CET)

   Qu'il y ait un retour à la ligne avant "etc." est à mes yeux un non-problème. Je saisi bien que plusieurs parmi cette section estiment qu'une typo correcte est primordiale. C'est une cause comme une autre, mais elle me semble entrer en conflit avec d'autres buts tout aussi valables et à mon sens prioritaires : la lisibilité des articles, même en mode édition, et un usage modéré des modèles. Dans des pages comme Liste_des_monuments_historiques_de_Bruges/S-Sint-Len, l'abus de modèle conduit à ce que ceux-ci ne soient plus traités par le logiciel, ce qui détruit toute l'utilité qu'ils pourraient avoir. Des pages avec plein de modèles mettent plus de temps à se charger dans les navigateurs. C'est mon avis, après réflexion, que l'internaute moyen préfère accéder à un article avec une erreur de typo mineure qu'il ne remarquera probablement pas en deux secondes plutôt que d'accéder à un article correct en dix secondes (les pages comme celles sus-nommée mettent entre 20 et 30 secondes à se charger avec ma connexion, pourtant assez rapide). Les jours où WP rame agacent bien plus de monde qu'un retour à la ligne inapproprié. Je suis consciente que ce modèle n'est bien sûr pas seul en cause : mais il participe à ce problème, comme d'autre très utilisés pour un bénéfice qui me semble négligeable. Esprit Fugace (d) 8 novembre 2012 à 08:34 (CET)

   Ce non-problème, d'après vous, consiste à encourager le laisser-aller et pourquoi pas les fautes d'orthographe et les erreurs en tout genre. Pourquoi ne pas continuer dans votre lutte contre les modèles et en demander le retrait total, en même temps que le bannissement de ceux qui les ont fait et de ceux qui les utilisent ? Je suis certain que ce modèle ne ralentit rien du tout. Par contre cette PàS, sans aucun doute. Daniel*D 8 novembre 2012 à 08:55 (CET)

   Remarquons que l'exemple caricatural indiqué ici : Liste des monuments historiques de Bruges/S-Sint-Len ne comporte pas une seule fois le modèle {{etc.}}, mais que vous ne demandez rien en ce qui concerne ceux que cette liste utilise. Autrement dit, courage, encore quelques efforts et vous améliorerez votre ciblage. Daniel*D 8 novembre 2012 à 10:23 (CET)

   Huuh ? Ce qui est long dans une page pleine de modèles, c’est pas leur affichage chez le client mais leur parsage sur le serveur. En gros : la page mettra peut-être 20 secondes à s’afficher après une édition, mais une fois qu’elle a été parsée, elle est très rapide à charger (chez moi : six secondes + le temps que mes gadgets JS chargent). --Pic-Sou 8 novembre 2012 à 10:26 (CET)

   Battu ! deux secondes . Daniel*D 8 novembre 2012 à 10:41 (CET)

   Après avoir pris soin de supprimer préalablement tout historique, vidé la mémoire cache contenue dans chaque browser et fermé la connexion puis redémarré la mécanique dans le but de tester comparativement l’entièreté ce qui précède, j’ai obtenu un temps de chargement équivalent quasi-instantané de la page inhérente aux modèles susmentionnés, à l’exception de Google Chrome qui, curieusement, a mis un peu plus de temps (environ 4-5 secondes) pour parachever son ostension. Cependant, une amie expressément contactée à cet effet m’a informé que cette page compilant différents modèles lui aurait pris environ douze secondes avant de réussir à se matérialiser complètement sur son écran. Cette constatation me fait trouver d’autant plus intéressante l’observation soulevée par Esprit Fugace, car j’ignorais que l’inclusion de modèles pouvait s’avérer à ce point gourmande en ressources. Jusqu’ici, j’avais ingénument cru que seules les inclusions d’images étaient associées à un ralentissement sensible du processus d’affichage. — euphonie ^bréviaire 8 novembre 2012 à 12:18 (CET)

   C'est (entre autres) l'effet poupées russes : ce modèle fait appel à d'autres modèles qui font appel à d'autres modèles qui... On oublie souvent où commence l'imbrication (vérifier en édition la liste des modèles utilisés sur la page, elle n'est pas là pour rien). Blinking Spirit (d) 8 novembre 2012 à 15:19 (CET)

   Tiens, je croyais, sans doute naïvement, qu'il n'était pas souhaitable d'intervenir dans une discussion sous deux identités, me trompé-je ? Sinon, dans sa version primitive le modèle ne faisait appel à presque rien. Daniel*D 8 novembre 2012 à 15:28 (CET)

8.  Conserver : je découvre l’existence de ce modèle à la faveur de cette PàS. Ne l’ayant encore jamais utilisé jusqu’ici, je regretterais néanmoins qu’il disparaisse, sauf si son maintien statutaire devait s’avérer préjudiciable à wp pour des raisons insoupçonnées qui risqueraient de faire « bugger » la mécanique. Toutefois, la lecture des messages de cette page ne me paraît pas avoir fait état d’un éventuel scénario apparenté, hormis une éventuelle économie des ressources énergétiques dont profiterait l’élision quadratique. La conservation de ce modèle impliquerait-elle donc une quelconque phagocytose de la fluidité circulatoire ? Pas à ce qu’il m’a semblé comprendre ! Alors pourquoi se priver d’un atout qui, dans certains cas, pourrait quand même s’avérer accessoirement utile ? Au moins qu’il puisse figurer dans le panel des options envisageables, dussions-nous le mettre à profit ou non, pour autant que puisse en subsister le choix d’une possible utilisation dans la perspective où quelque circonstance inductrice pourrait subsidiairement suggérer d’y avoir recours. — euphonie ^bréviaire 8 novembre 2012 à 02:04 (CET)
9.  Conserver : Je ne comprend pas très bien pourquoi cette question est venue sur la table, mais je trouve que ce modèle a l'avantage évident de respecter la syntaxe officielle, sans avoir a se creuser les méninges, et de ne pas se retrouver tout seul sur une ligne ... je n'y vois donc que des avantages.Pano38 (d) 8 novembre 2012 à 07:55 (CET)
10.  Conserver : Ce modèle n'étant pas obligatoire, il n'y a pas de raison impérieuse de le supprimer. Geralix (d) 8 novembre 2012 à 11:46 (CET)
11. Idem Geralix, Gonzolito, et surtout parce qu'Esprit Fugace n'a pas clairement précisé le problème dans son argumentaire : en quoi est-il gènant d'avoir accès à un modèle tel que celui-ci ? Je comprends bien que tout le monde ne peut pas l'utiliser, ou ne le souhaite pas, mais ce n'est pas parce que je ne sais pas programmer un bot que je ne veux pas qu'on l'utilise... Ça ou le Java, c'est quoi la différence ?--SammyDay (d) 8 novembre 2012 à 12:42 (CET)

    Le problème est que ce modèle, comme d'autres du même type, participe à la complexification de l'édition de Wikipédia et rebute les nouveaux (et un bon nombre d'anciens). Un code-source difficilement lisible devient de fait difficilement éditable. Un gadget java, c'est toi qui va l'activer au choix dans tes préférences, c'est pas un problème. Un bot ne dérange personne en faisant plus vite des modifications que n'importe qui peut faire. Là, c'est une "pollution" avec laquelle tout le monde doit vivre alors que tout le monde ne l'a pas choisie. Par ailleurs, comme tout les modèles très utilisés, c'est soit une entorse au principe d'ouverture de Wikipédia car protégé (et dans ce cas difficilement améliorable, non modifiable par tous, et tout ça), soit une faille de sécurité (je rappelle que cette année a vu deux vandalismes majeurs de la page d'accueil via ce type de modèle - y compris au moins un modèle semi-protégé). Esprit Fugace (d) 8 novembre 2012 à 12:50 (CET)

    Je comprends parfaitement ton point de vue. Malheureusement, la conclusion qui s'impose à mes yeux est la suivante : il faut supprimer l'intégralité des modèles pour éviter les soucis que tu cites. Et ça c'est juste hors de question.--SammyDay (d) 8 novembre 2012 à 12:56 (CET)

    Tu crois pas qu'il y a un juste milieu ? un usage modéré, où avant de créer un modèle, on se demande si c'est vraiment la solution la plus adaptée et que les problèmes qu'il ajoute valent les bénéfices ? À la vitesse où ce modèle est ajouté à la chaîne dans les articles, tout nouveau contributeur sera confronté à son usage, qu'il le veuille ou non et comme son fonctionnement est non intuitif ({{etc.}} se transforme en « , etc. »), il a toutes les chances d'engendrer des erreurs pire que l'absence d'une espace insécable. –Akeron (d) 8 novembre 2012 à 13:15 (CET)

    Selon les arguments d'Esprit Fugace, non. Chaque modèle présente une faille de sécurité, qu'il soit ou non semi-protégé. L'utilisation des modèles participe à la complexification du code des pages, et en rebute plus d'un. Et si ce sont les modèles "très utilisés" qui sont un problème, c'est déjà un souci de le corriger. Après je ne suis pas dans l'idée que si ce modèle est supprimé, il faut en supprimer plein d'autres. Il faut juste avoir des arguments précis selon chaque modèle, et non pas des arguments généraux qui peuvent être utilisés contre chaque modèle utilisé ! {{formatnum:}} est tout aussi bizarre et tout aussi utile et utilisé...--SammyDay (d) 8 novembre 2012 à 14:03 (CET)

    Remarque du comte Ɲemoi – {{formatnum: peut être agréablement remplacé par {{nombre|, beaucoup plus naturel. Ce 8 novembre 2012 à 14:18 (CET).

    Non, je suis parfaitement d'accord avec Akeron : il y a un juste milieu à trouver. La plupart des gens verrouillent leur porte, mais ne vont pas jusqu'à la blinder. C'est le même principe : il y a un équilibre à trouver entre vulnérabilité et utilité (c'est exactement ce que je voulais dire en parlant de rapport bénéfices/inconvénients). J'ai proposé ce modèle à la suppression, mais pas tous ceux de sa catégorie. Est-ce si difficile d'admettre une position modérée ? Les inconvénients que j'ai mentionnés sont, à mon avis, contrebalancés dans beaucoup de cas par un bénéfice rendu appréciable. Mais pas pour CE modèle, qui ne sert qu'à mettre une espace insécable et une virgule (ou pas), plus expliciter une abréviation qui n'en a pas besoin. Blinking Spirit (d) 8 novembre 2012 à 14:25 (CET)

    Notez que j’ai déjà fait une proposition pour rendre le fonctionnement de ce modèle plus intuitif… Cordialement --Pic-Sou 8 novembre 2012 à 14:30 (CET)

    C'est effectivement simple d'admettre une position modérée. Mais le propre de la position modérée, c'est qu'elle n'est pas tout l'un ou tout l'autre. Donc la ligne de séparation est subjective. Pour moi, dans ce cas, il n'y a pas de raison évident de supprimer ce modèle. Et c'est une position modérée, même si elle ne rejoint pas la votre. Quant au fait que l'abréviation n'a pas besoin d'explication, là je doute... Nombre de nos lecteurs doivent trouver utile celle-ci.--SammyDay (d) 8 novembre 2012 à 14:30 (CET)

    Sérieusement, des lecteurs qui se demanderaient au milieu d'un article ce que signifie « etc. » et qui après avoir mis la souris dessus seraient satisfaits d'apprendre que cela signifie et cetera ? À mettre en perspective avec les réels difficultés rencontrées par les éditeurs face à une avalanche de modèles dans les articles... –Akeron (d) 8 novembre 2012 à 15:05 (CET)

12.  Conserver. Idem Geralix et plein d'autres au-dessus. Puis bon, vu certaines réactions d'en dessous.... Au pire, si ce modèle est supprimé, je suis pour une suppression d'un bon nombres d'autres qui peuvent être considérés comme tout aussi "inutiles" que celui-là ! --Cordialement. -- Coyote du 86 ^{[Me contacter]} 8 novembre 2012 à 13:39 (CET)
13.  Conserver je ne vois pas le problème de ce modèle. Son existence ne le rend pas obligatoire. Ceux qui veulent continuer à taper simplement etc. continueront à le faire. L'ajout de l'espace insécable et de l'infobulle sont des plus qu'il sera toujours plus difficile décrire avec la syntaxe de base de wiki. Udufruduhu (d) 8 novembre 2012 à 15:06 (CET)
14.  Conserver J'ignorais l'existence de ce modèle et je continuerai probablement à l'ignorer. D'un côté il apporte à certains éditeurs consciencieux une vraie aide ; de l'autre, il ne gêne que très mineurement l'édition. Je crois donc qu'il est plutôt utile. (Par ailleurs, ce modèle a vocation à être très peu utilisé, car le style encyclopédique tend à l'exhaustivité et devrait donc éviter cette abréviation. Le modèle aurait donc au moins une utilité : faciliter l'identification des articles mal rédigés .) Seudo (d) 8 novembre 2012 à 16:55 (CET)
15.  Conserver Ce modèle n'est pas obligatoire (il y en a probablement des milliers d'autres du même genre), il n'est pas non plus très compliqué et gène peu l'édition. Artvill (d) 8 novembre 2012 à 17:59 (CET)
16.  Conserver. Modèle simple et permettant notamment d'éviter des retours à la ligne inesthétiques. On pourra le supprimer quand MediaWiki mettra une espace insécable devant "etc.". GabrieL (d) 9 novembre 2012 à 11:08 (CET)
17.  Conserver Nivellement par le bas pour… attirer des contributeurs ? Totodu74 (devesar…) 9 novembre 2012 à 11:29 (CET)

    Bien sûr que c'est pour les contributeurs. Qui d'autre ? Marc Mongenet (d) 10 novembre 2012 à 02:05 (CET)

    Au détriment des lecteurs, peut-être ? Daniel*D 10 novembre 2012 à 03:00 (CET)

    Les fameux lecteurs qui fuient parce l'espace avant « etc. » n'est pas insécable ? –Akeron (d) 10 novembre 2012 à 04:08 (CET)

    Pas seulement, Daniel*D 10 novembre 2012 à 09:40 (CET)

    Je ne parle pas que de l'espace, mais aussi de l'abréviation discrète. M'enfin si ça peut être géré par Mediawiki... Totodu74 (devesar…) 10 novembre 2012 à 13:48 (CET)

18.  ConserverFranchement pratique, surtout l'infobulle, j'avoue à ma grande honte ne pas connaitre toutes les abréviation latine (pas plus de tous les éléments du tableau périodique de Mendeleïev, et de tous les noms des variétés de plante ou d'animaux), donc, ça peut aider, surtout si l'infobulle contient un hyperlien vers la définitionPopolon (d) 10 novembre 2012 à 10:43 (CET)

    Tu as besoin de ce modèle pour savoir qu'"etc." est l'abréviation d'"et cetera" ? --Guil2027 (d) 10 novembre 2012 à 14:23 (CET)

19.  Conserver accessibilité et respect du W3C. Crochet.david (d) 10 novembre 2012 à 10:52 (CET)

    Pourtant cela aggrave l'accessibilité pour les contributeurs (une des priorités de la WMF) et ce n'est pas ce que demande le W3C. –Akeron (d) 10 novembre 2012 à 14:44 (CET)

    D’une, l’idée que « cela aggrave l'accessibilité pour les contributeurs » est une assertion sans source. De deux, le W3C dit que les balises <abbr> devraient être utilisées dans certains contextes, mais ne les proscrit pas le reste du temps. Et les WCAG, encore une fois, demandent à ce que l’on explicite chaque abréviation. Il faut y tendre, même si, à l’avenir, on peut espérer qu’il ne faille pas passer par un modèle pour cela. Cordialement --Pic-Sou 11 novembre 2012 à 00:00 (CET)

    La complexité du wikicode, dont notamment les modèles, est bien connue pour rebuter les nouveaux, tas vraiment besoin d'une source pour quelque chose d'aussi évident ? Le Web content accessibility guidlines suggère de très nombreuses choses, qu'on n'a aucune obligation d'appliquer à la lettre et certainement pas aveuglément sans prendre en compte nos contraintes particulières. –Akeron (d) 11 novembre 2012 à 01:50 (CET)

    « Et les WCAG, encore une fois, demandent à ce que l’on explicite chaque abréviation » : non, justement. Seuls sont concernées les cas où « l'abréviation ne fait pas encore partie de la langue courante ». Lisez WCAG, s'il-vous-plaît, avant d'en parler et surtout avant d'en user comme d'un argument dans vos querelles. Etc n'entre tout simplement pas dans le champ d'application du critère WCAG. La seule question posée ici est LTRUIN v. KISS.
    Pire : même si on faisait entrer Etc. dans le champ d'application du critère WCAG, les solutions retenues pour l'accessibilité par la norme WCAG sont loin de se limiter à ce que fait ce modèle. Il suffit par exemple qu'il existe un article etc. atteignable via le moteur de recherche interne du site pour qu'il soit inutile d'expliciter l'abréviation. Or, cet article etc. existe.
    A vrai dire, toutes les abréviations ou sigles qui font l'objet d'un article (atteignable au besoin via un redirect) sont gérées de manière accessible sans ce genre de modèle.
    Vous pouvez donc sans doute passer en SI d'autres abréviations (typographiques comme et al. vu qu'il existe et al., par exemple) et vous poser la question de créer plutôt de nouveaux articles courts, en dépassant les vieilles querelles stériles sur la différence entre Wikipédia et Wiktionnary (vol. par exemple)...
    Lire les spécifications avant de les évoquer peut aider à s'apercevoir que le problème est connu par ailleurs et que des solutions existent.
    Et sinon, il serait peut-être, par exemple, plus profitable de s'exciter sur d'autres problèmes où on ne parle plus de couillaminis mais de blocages immédiats à la contribution. Par exemple, le Captcha totalement non accessible imposé aux IP quand leur intervention comporte un lien externe. C'est un peu couillon quand on demande au gens d'apporter des sources... --94.140.9.43 (d) 11 novembre 2012 à 10:31 (CET)

    « Activating a link will open up a new window to an online dictionary site with the specific vocabulary word defined. » Je vois bien ça appliqué sur toutes les abréviations figurant dans un article, comme liens redondants ce n'est pas mal. Par ailleurs je ne vois pas la différence pour le soit-disant argument « fuite des nouveaux devant la complexité du code » entre [[ ]] et {{ }}. Daniel*D 11 novembre 2012 à 13:15 (CET)

    Aucune obligation de faire un lien sur chaque abréviation, déjà il n'est pas nécessaire d'expliciter les abréviations qui sont entrées dans le langage courant, d'autre part un formulaire de recherche visible sur toutes les pages et permettant d'accéder à la définition est suffisant. Et même si ça n'a donc rien à voir ici, d'une façon générale les liens sont plus simples à utiliser que les modèles. –Akeron (d) 11 novembre 2012 à 15:17 (CET)

    « d'une façon générale les liens sont plus simples à utiliser que les modèles » : c'est sûr, que pour « etc. », en généralisant, c'est beaucoup plus difficile de taper {{ }}, que [[ ]], quod erat demonstrandum = belle démonstration de la prise en otage du modèle qui nous préoccupe, . Daniel*D 12 novembre 2012 à 00:14 (CET)

    Non, ce n'est pas particulièrement le caractère mais la syntaxe, le nombre de paramètre, le très grand nombre de modèles différents, etc. Rien à voir avec les liens qui sont les mêmes partout, n'ont maximum que 2 paramètres très simples à comprendre, n'ont pas tous les inconvénients habituels des modèles... et ils sont tout simplement indispensables, donc encore une fois, le débat n'est pas du tout là. –Akeron (d) 12 novembre 2012 à 02:56 (CET)

    « le très grand nombre de modèles différents » + « le débat n'est pas du tout là » = en effet, le débat sur cette page porte sur le modèle {{, etc.}}, qui n'a que deux paramètres, dont un pourrait être supprimé sans problème. Donc, généraliser c'est le prendre en otage pour une démonstration, en langage Wikipédia cela s'appelle un WP:POINT, si je ne m'abuse. Daniel*D 12 novembre 2012 à 10:31 (CET)

    N'importe quoi, évidemment aucun POINT, c'est uniquement toi qui compare de façon fallacieuse avec les liens alors que personne ne met sérieusement en doute leur rapport coût/bénéfice. Pour rappel, le débat porte sur la suppression du modèle {{etc.}}, qui d'une part partage les défauts de tous les modèles (gourmand en ressource, complique l'édition, cible de choix pour les vandalismes), d'autres part est non-intuitif tel qu'il est utilisé sur des milliers de pages et provoque de ce fait des centaines d'erreurs, du type espace avant la virgule et double virgule. Tout cela pour un bénéfice extrêmement faible. –Akeron (d) 12 novembre 2012 à 16:26 (CET)

    Des centaines d'erreurs, ce qui reste encore à prouver, par rapport aux plus de 12 000 pages où il est utilisé (souvent plusieurs fois par page) et où il a introduit les espaces insécables de façon pérenne et visible, c'est un bénéfice réel. Daniel*D 12 novembre 2012 à 16:49 (CET)

    Oui des centaines d'erreurs qui sont bien réelles et qui étaient prévisibles mais que tu n'as pas du tout anticipées, actuellement 8634 articles utilisent ce modèle. Le bénéfice est extrêmement minime, il n'est visible que lorsque'« etc. » arrive à la fin de l'écran, au lieu d'être tout seul à la ligne, le mot précédent le sera aussi, la belle affaire sur un écran... Je doute que les chances que ça arrive soient plus grandes que le nombre d'erreurs engendrées par l'usage non intuitif de ce modèle, qui lui, provoque des erreurs bien visibles à tous les coups. Mais je suppose qu'on n'est pas à une aberration près. –Akeron (d) 12 novembre 2012 à 17:30 (CET)

    « Je doute que les chances que ça arrive soient plus grandes que le nombre d'erreurs engendrées par l'usage non intuitif de ce modèle [...] ». Je doute du contraire (les multiples tailles d'écran le montrent) et sur les soit-disant centaines d'erreurs j'ai corrigé les quelques exemples pointés plus haut (sur 24 articles), par contre le modèle a aussi corrigé des milliers d'« , etc.» mal écrits : « etc » « etc. » » «, etc... » » « ,etc... » « etc... » « ,etc » « ,etc. » en plus d'ajouter l'espace correcte. Daniel*D 12 novembre 2012 à 18:01 (CET)

    Je n'ai donné que les premières erreurs trouvées, à titre d'illustration, il y en a beaucoup plus qui restent. Il n'y a pas besoin d'un modèle pour corriger les erreurs que tu indiques, il suffit de la faire dans le texte, tout simplement. –Akeron (d) 12 novembre 2012 à 18:14 (CET)

    J'ai écrit : « a aussi corrigé [...] en plus [...] ». Daniel*D 12 novembre 2012 à 18:20 (CET)

20.  Conservation immédiate cf. les nombreux arguments développés ci-dessus. — MetalGearLiquid ^{[m’écrire]} 11 novembre 2012 à 13:57 (CET) PS : Si j’ai bien compris, la personne ayant proposé cette PàS a omis de le signaler au créateur du modèle, qui plus est, elle est administratrice ; j’ose espérer qu’il s’agissait-là d’un simple oubli, car dans le cas contraire, ce serait un bien triste exemple de manque de savoir-vivre dans le cadre d’un projet collaboratif, paraît-il…
21.  Conserver à la lonnngue lecture des arguments, attaques personnelles et autres ci-dessus, mon avis se range à la conservation de ce modèle qui améliore la typographie complexe de la langue française. Même si « le bénéfice est bien maigre » comme le précise Wikinade (d · c · b) (cf. 27ème avis de suppression), il n'en reste néanmoins un bénéfice. Mith (What ? You're talkin' to me ?) - Angers, le 12 novembre 2012 à 13:09 (CET)
22.  Conserver Personnellement, taper qq caractères en plus ne me pose pas de problème. Meodudlye (d) 12 novembre 2012 à 13:28 (CET)
23.  Conserver que c'est compliqué d'ajouter des accolades autour de "etc.". Ce modèle à une fonction qui est utile. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 14 novembre 2012 à 21:21 (CET)

    Un avis non motivé risque de ne pas être pris en compte. -- Speculos ^✉ 14 novembre 2012 à 22:27 (CET)

24.  Conserver ceci est ma motivation quoi qu'on en dise. --EoWinn (Causerie) 15 novembre 2012 à 06:16 (CET)
25.  Conserver Vraiment pas compliqué à utiliser, et utile. LittleTony87 (d) 15 novembre 2012 à 18:34 (CET)
26.  Conserver faible. Pour le respect de la typo et de l'accessibilité. Même si je trouve cela une petite complexité, elle reste surmontable. J'ai du mal à être sensible aux arguments de suppression. Néanmoins, si médiawiki propose mieux, on pourrait en reparler, mais en attendant... Hatonjan (d) 15 novembre 2012 à 18:54 (CET)

Supprimer

1.  Supprimer Sert à rien. Si on veut écrire "etc.", on tape quatre touches du clavier et c'est fait. Prétendre qu'il est absolument nécessaire de faire autrement relève de l'hypocrisie. Esprit Fugace (d) 7 novembre 2012 à 19:54 (CET)

   Mais on ne respecte pas les normes d’accessibilités qui veulent que l’on explicite toute abréviation, ni celles de typographie qui nécessitent de mettre une espace insécable dans ce cas. Cordialement --Pic-Sou 7 novembre 2012 à 21:20 (CET)

   Au moins, on respecte le rédacteur. Esprit Fugace (d) 7 novembre 2012 à 21:46 (CET)

   Voir ma réponse ci-dessus. Daniel*D 8 novembre 2012 à 02:40 (CET)

2.  Supprimer La complexification de l'édition de Wikipédia, et l'effet de répulsion que cela entraîne sur les nouveaux contributeurs (et même les anciens), est causé en partie par ce genre de modèle, où le gain est faible par rapport à l'effet obtenu. Or, la plus grande richesse de Wikipédia étant ses contributeurs, et leur renouvellement, il me semble qu'on peut très bien se passer de ce modèle, et probablement de plusieurs autres. - Boréal (:-D) 7 novembre 2012 à 20:16 (CET)

   Le renouvellement se fait pas trop mal. Mis à part la persistance localisée de certains inclusionnismes béats qui font fuir pas mal de contributeurs très compétents - rebutés par ce qu'ils perçoivent à juste titre comme étant un manque de sérieux - il n'y pas de problème particulier à déplorer. SM ** ようこそ ** 7 novembre 2012 à 20:33 (CET)

   "Le renouvellement se fait pas trop mal"^Refnec. Et vos agressions inutiles et hors sujet sur les "inclusionnistes béats", on s'en passerait. - Boréal (:-D) 8 novembre 2012 à 14:33 (CET)

   Les statistiques de la Foundation qui indiquent, si j'ai bien compris, un nombre stable de contributeurs assidus. Et pour le reste, merci de bien me lire et de ne pas voir des agressions là où il n'y en a pas : j'ai bien parlé d'inclusionnisme béat, et non d'inclusionnistes, et n'ai donc stigmatisé personne. Juste certaines attitudes à mon avis contre-productives du point de vue du recrutement des experts (ce qui ne les empêche pas d'être respectables sur le fond. Comme l'est le suppressionnisme ultra). SM ** ようこそ ** 8 novembre 2012 à 16:02 (CET) Mais puisque vous n'aimez pas les attaques personnelles, « maniaques » pour qualifier ceux qui veulent conserver le modèle en est bien une, par contre. N'hésitez pas à le déplorer ou à agir... SM ** ようこそ ** 8 novembre 2012 à 16:06 (CET)

3.  Supprimer, ne garanti même pas qu'on n'a pas de faute de typo (double virgule, notamment). --MGuf (d) 7 novembre 2012 à 20:55 (CET)

   Ce n’est, je pense, pas possible… --Pic-Sou 7 novembre 2012 à 21:20 (CET)

   Si, oui, yes, da, , etc.... --MGuf (d) 7 novembre 2012 à 21:32 (CET)

4.  Supprimer absolument ridicule. Deansfa 7 novembre 2012 à 20:57 (CET)

   Un argument, peut-être ? --Pic-Sou 7 novembre 2012 à 21:20 (CET)

5.  Supprimer, cf mon avis sur Wikipedia:Le Bistro/7 novembre 2012#Surutilisation des modèles typo, inutile, provoque de nombreuses erreurs comme « mot, , etc. », complique l'édition des articles et surcharge les serveurs. –Akeron (d) 7 novembre 2012 à 21:04 (CET)

   Wikipédia:Ne vous préoccupez pas de performance --Pic-Sou 7 novembre 2012 à 21:18 (CET)

   S'il n'y avait que ça... et même ce n'est pas une raison pour gaspiller et mettre des modèles partout parce que ce n'est pas strictement interdit, et lorsque Wikipédia est trop lente, ça gêne tout le monde. –Akeron (d) 7 novembre 2012 à 21:27 (CET)

6.  Supprimer Totalement contre-productif. En accord avec les précédents. Hadrianus (d) 7 novembre 2012 à 21:26 (CET)
7.  Supprimer Pas bien saisi en quoi « l'accessibilité » imposerait de faire des trucs compliqués pour un résultat identique. Abeille noire (d) 7 novembre 2012 à 21:31 (CET)

   Bah non, le résultat n’est pas identique, justement. Cordialement --Pic-Sou 7 novembre 2012 à 21:35 (CET)

   Ben alors, tu ferais mieux d'expliquer clairement en quoi en discussion, plutôt que de ponctuer ainsi chaque avis pour la suppression. Abeille noire (d) 7 novembre 2012 à 21:43 (CET)

   OK, je t’explique. Les recommandations du W3C pour l’accessibilité du contenu du web, dans leur version 2.0 [lire en ligne] disent clairement que pour qu’une page soit accessible, « un mécanisme pour identifier la signification détaillée des abréviations est présent (niveau AAA) ». Ce modèle permet de générer une infobulle explicitant l’abréviation « etc. » par sa signification latine « et cetera ». Pour l’utilisateur lambda qui possède un système graphique et un navigateur comme IE, cela ne change pas grand chose. Pour les robots, les lecteurs d’écran… cela donne un sens à l’abréviation. Raison pour laquelle ce modèle doit être utilisé.

   Précisons aussi que ce modèle permet d’insérer facilement une espace insécable après la virgule pour respecter non plus une norme d’accessibilité, mais de typographie française.

   Je suis d’accord que cela complexifie un peula syntaxe. Mais, sans aller jusqu’à créer un patch pour MediaWiki gérant les abréviations courantes automatiquement (je ne sais pas faire), il est possible, en changeant le titre du modèle, de simplifier tout ça, comme je le propose ci-dessus.

   En espérant t’avoir aidé. --Pic-Sou 7 novembre 2012 à 21:58 (CET)

   Je ne suis pas sûre que les normes d'accessibilité aient été pensées pour ce type d'abréviation. Exemple : cf. est l'abréviation de confer. Et pourtant, moins de personnes connaissent "confer" plutôt que cf. Dans ce type de cas, l'explicitation est non seulement inutile : elle embrouille ce qui est clair sans elle. Esprit Fugace (d) 7 novembre 2012 à 22:32 (CET)

   Une source peut-être ? Là encore, ne prenons pas le lecteur pour un idiot… --Pic-Sou 7 novembre 2012 à 22:36 (CET)

8.  Supprimer contre emmerder les contributeurs avec des combinaisons de touches ou des modèles à la noix pour pallier aux insuffisances de mediawiki. — Rhadamante 7 novembre 2012 à 21:46 (CET)
9.  Supprimer Usine à gaz qui apporte plus de problèmes typographiques que de solutions. Martin // discuter 7 novembre 2012 à 22:38 (CET)
10.  Supprimer Honnêtement, je ne vois pas très bien ce que ça apporte de plus, en dehors de l'espace insécable (soit dit en passant, ce serait bien d'avoir un symbole simple pour générer ce dernier, car la bouillie n&s… je ne sais plus comment n'est pas beaucoup plus compréhensible). Alexander Doria (d) 7 novembre 2012 à 23:51 (CET)

    nbsp = non-breaking space. TED 8 novembre 2012 à 00:47 (CET)

11.  Supprimer Modèle peu intuitif, utilité limitée (Ce type de modèle pourrait en revanche être plus utile pour d'autres abréviations). Elfix ↝ ^discuter 7 novembre 2012 à 23:56 (CET) Cependant, je déplore le fait que le créateur du modèle n'a pas été prévenu... Elfix ↝ ^discuter 8 novembre 2012 à 09:47 (CET)

    Merci. Sinon, ce type de modèle est (très) utilisé pour d'autres abréviations (je ne dirai pas lesquelles pour des raisons évidentes), je n'ai donc rien inventé, je m'en suis juste inspiré. J'aurais mieux fait de trouver une occupation plus saine, ce que je vais sans doute faire, d'ailleurs. Cdlt, Daniel*D 8 novembre 2012 à 09:56 (CET)

12.  Supprimer Typiquement un truc de geek ou comment se compliquer la vie. --Guil2027 (d) 8 novembre 2012 à 00:25 (CET)

    Merci pour le qualificatif, je me sens rajeunir . Daniel*D 8 novembre 2012 à 01:05 (CET)

13.  Supprimer Selon, moi, il n'y a aucune raison valable pour qu'un texte d'un article encyclopédique possède cette locution adverbiale, (sauf pour l'article Et cetera), (je sais aussi que etc. est utilisé dans des milliers d'articles, mais ceci reste mon avis au sujet de la présence des etc. dans les articles aucun besoin de me répliquer à ce sujet), aussi, pour ceux qui voit l'utilité du terme etc. dans les textes, ce type de modèle rend inutilement plus complexe l'édition de texte pour le contributeur pour un gains très faible sur la typographie. - Matrix76 (d) 8 novembre 2012 à 01:39 (CET)
14.  Supprimer. Comme beaucoup de modèles qui intègrent ou gèrent (plus ou moins bien) la typographie fine. Wikipédia est sur Internet. Pensons AUSSI à l'accès à WP de ceux qui ont des vieux ordis et qui ne sont pas geek pour un centime d'€ (ou d'euro). Faisons simple. Wikipédia, pour l'instant, n'a pas l'obligation d'être "ready to print" mais bien d'être un truc avec du sens sur l'écran de l'ordi. Le fait de n'avoir qu'un espace informatiquement parlant normal à la place de l'espace insécable n'est pas un drame sur l'écran, contrairement à ce que voudraient nous faire croire les adeptes de la typographie sur ordi, armés de leurs petits livres rouges du bien-faire. Savoir que « etc. » signifie « et cetera » ou que « cf. » signifie « confer » par le simple fait de passer la souris dessus, être sûr que le lecteur d'écran fera son travail sans erreur, autant de gadgets ici inutiles : les abréviations sont fixées de longue date et il suffit de les réinjecter dans la recherche de Wp pour connaître leur signification (au pire, faire un lien : etc. -les lecteurs de WP connaissent-) ; un bon lecteur d'écran devrait savoir restituer correctement ce genre d'abréviation sans plus d'indication. Et puis on pourrait ergoter encore sur un peu tout, comme la taille des tirets : simple tiret ? Cadratin ? Demi-cadratin ? Autre signe ? Obliger à utiliser les macrons même quand on ne peut qu'utiliser les accents circonflexes ? Interdire l'accès à l'écriture sur WP à tous ceux qui failliront à cela ? Vite, encore des règles à imposer à tous, sous peine de blocage ! Il vaut mieux apprendre aux nouveaux (et anciens) les règles les plus simples de la typographie, voire de la seule orthographe et plus souvent encore celles qui privilégient le sens de ce qu'on écrit, avant de jouer à "faire dans la perfection". --Warp3 (d) 8 novembre 2012 à 05:04 (CET)

    Ce modèle n'impose rien, par contre il corrige le problème que vous ne voyez pas : empêcher le report à la ligne de « etc. » comme le préconisent les règles de typographie, et ceci très simplement. Daniel*D 8 novembre 2012 à 08:11 (CET)

15.  Supprimer Aucun intérêt si ce n'est de compliquer encore plus. --'toff ^[discut.] 8 novembre 2012 à 07:31 (CET)
16.  Supprimer Contre tout ce qui complique l'édition des articles, tout comme la plupart des tableaux d'ailleurs. C'est au logiciel de gérer ce genre de choses (je n'y connais rien mais il doit bien y avoir moyen)… -- Sire Enguerrand Un bref ou une missive? 8 novembre 2012 à 08:58 (CET)

    Non, il n'y en a pas. Daniel*D 8 novembre 2012 à 09:09 (CET)

    Bien sûr que si c'est possible, MediaWiki met déjà automatiquement des espaces insécables dans les guillemets et avant les caractère « % : ; ? ! », voir Aide:Caractères spéciaux problématiques#Espace insécable. –Akeron (d) 8 novembre 2012 à 13:27 (CET)

    Mais comme il ne le fait pas pour « etc. », c'est, en l'état, impossible. Daniel*D 8 novembre 2012 à 13:43 (CET)

    Ce n'est pas parce qu'il ne le fait pas déjà qu'il faut causer d'autres problèmes avec ce genre de bricolage, surtout pour un gain aussi mineur. –Akeron (d) 8 novembre 2012 à 15:37 (CET)

    Raisonnement par l'absurde : le modèles est mal utilisé par quelques personnes, surtout ne rectifions pas, supprimons le modèle. Daniel*D 8 novembre 2012 à 15:42 (CET)

    Il est mal conçu, rejeter ça sur les gens qui l'utilisent mal est un peu facile et les problèmes d'usages ne sont pas les seuls motifs de suppression. –Akeron (d) 8 novembre 2012 à 16:14 (CET)

17.  Supprimer mais faible. C'est tout le débat entre utilisation de modèles que les contributeurs présents depuis longtemps sur Wikipédia pensent simple et la complexité grandissante du code-source des articles qui est un frein de plus en plus croissant à l'arrivée de nouveaux contributeurs. Ludo ^{Bureau des réclamations} 8 novembre 2012 à 10:02 (CET)

    Ce modèle existe depuis février 2010, est d'une simplicité biblique comparé à certains (inutile de donner des exemples tout le monde les connait) et la démonstration est loin d'être faite qu'il serait responsable de la fuite des nouveaux, pour celle des anciens au vu de ce genre de PàS, c'est plus sûr. Daniel*D 8 novembre 2012 à 10:08 (CET)

    Quand on cherche, on trouve toujours plus simple ou plus compliqué ; mais ce n'est pas vraiment ça le cœur du débat.

    Je reprends mes propos « [...] la complexité grandissante du code-source des articles qui est un frein de plus en plus croissant à l'arrivée de nouveaux contributeurs », quand tu transformes en « [...] serait responsable de la fuite des nouveaux ». Pour que les nouveaux partent, il faudrait déjà qu'ils soient arrivés. Me semble-t-il. Pour ma part, pour préciser un peu plus mon propos, il m'arrive de faire des ateliers de découverte à Wikipédia. L'année passée, j'en ai réalisé une série avec des universités du troisième âge sur Lausanne. De ces ateliers, j'en ai notamment gardé comme constat qu'un code trop compliqué freine réellement ces personnes pour contribuer. Un code source épuré est beaucoup plus accueillant. Voilà pourquoi j'ai exprimé un avis supprimer mais faible. Ludo ^{Bureau des réclamations} 8 novembre 2012 à 10:19 (CET)

    Les premiers utilisateurs de Wikipédia ne sont-ils pas les lecteurs ? Le code source n'est pas leur affaire, par contre la présentation des pages qu'ils lisent, oui. En dehors de cette question, appréhender Wikipédia, à mon avis, est en premier lieu bien plus compliqué qu'un simple problème de rédaction, commencer par les principes fondateurs et tout ce qui en découle est une toute autre complication. Ce vers quoi on devrait diriger les nouveaux. Moi qui suit bientôt du troisième âge, je trouve ces questions bien plus importantes. Quant à la « complexité » du code voir mes échanges sur cette page : vers la fin de la section. Daniel*D 8 novembre 2012 à 10:38 (CET)

    Oui, les premiers utilisateurs sont les lecteurs. La présentation des page est effectivement leur affaire. En poussant cette réflexion, il apparait nécessaire de supprimer le bouton modifier de toutes les pages de l'encyclopédie et de ne l'accorder qu'à un comité de rédaction dûment recruté. En effet, cette édition pour tous amène la possibilité, au lecteur, de tomber sur des erreurs ou des vandalismes.

    Les principes fondateurs et le code source sont deux sujets aussi importants l'un que l'autre, mais absolument pas à comparer. Dans le cadre des ateliers que j'ai animé, j'ai évoqué ces problématiques de principes fondateurs et de critères d'admissibilité. Ces points ont été perçu très positivement comme gage de crédibilité et qualité. Mais cela reste le cadre, les règles du jeux. Une fois que ces règles sont assimilées, on peut se mettre à contribuer. Et ça là que le code source de certains articles apparait comme une véritable usine à gaz et fait faire demi-tour à certaines personnes. Ludo ^{Bureau des réclamations} 8 novembre 2012 à 11:56 (CET)

    Ou pas, nous en sommes les exemples. Daniel*D 8 novembre 2012 à 12:27 (CET)

    Tu es une personne particulière. À moins d'avoir une prétention sans limite, j'espère que tu ne considères pas ton cas particulier comme généralisable à l'ensemble de l'humanité ?

    Pour ma part, j'ai bien précisé dans mon propos que je parlais de certaines personnes, sous-entendu que l'expérience que je décrivais n'avait pas la prétention d'être dressée comme un cas général. Ludo ^{Bureau des réclamations} 8 novembre 2012 à 12:35 (CET)

    Pas d'inquiétude, je t'ai lu attentivement, inutile d'utiliser le gras. Ni d'ailleurs d'exagérer en évoquant la suppression du bouton modifier. « Ou pas » : certains s'en vont, d'autres restent, pour de multiples raisons. Daniel*D 8 novembre 2012 à 12:39 (CET)

    Bonjour Ludo ! Tu écris (je cite) : « Il apparait nécessaire de « supprimer » le bouton modifier … et de ne l’accorder qu’à un comité de rédaction dûment recruté ». Est-ce une option que tu envisages au conditionnel — dans le sens : « Il « apparaitrait nécessaire » — ou un souhait que tu voudrais vraiment voir se concrétiser ? Ou peut-être ai-je mal compris ?

    Par ailleurs, l’argument que tu développes — cf. « le code source de certains articles apparait comme une véritable usine à gaz et fait faire demi-tour à certaines personnes » — m’interpelle, car il m’a également été plusieurs fois objecté. Peut-être une future version what you see is what you get pourrait-elle solutionner cet impondérable induisant quelque réticence ? — euphonie ^bréviaire 8 novembre 2012 à 13:02 (CET)

    Bonjour Euphonie,

    Sur la suppression du bouton modifier, il s'agissait de ma part d'un raisonnement par l'absurde dans l'optique de dire : « Attention à ne pas suivre aveuglément tout ce qu'on pense comme modification positive pour Wikipédia ».

    Si je peux être franc avec toi, oui certains codes-sources d'articles que tu as rédigés m'ont fait très peur. J'ose à peine imaginer l'effet sur des personnes n'ayant qu'une maitrise très embryonnaire du code MediaWiki. Comme tu l'évoques, j'attends avec impatience le WYSIWYG. Ludo ^{Bureau des réclamations} 8 novembre 2012 à 13:32 (CET)

    Merci Ludo pour ta réponse et ta sympathique franchise ! Je rejoins d’autant plus ton observation quant à l’article auquel je présume tu fais référence que je m’étais moi-même demandé, à l’époque, comment j’allais réussir à me dépatouiller d’une succession d’imbrications alambiquées sans pour autant porter atteinte à l’équilibre architectural de la page, tant l’inclusion des appels de notes en était devenue complexe. C’est là que des avis extérieurs et l’aide fournie par quelques conseils avisés — grâce à l’entremise diligente d’un ensemble de contributeurs tiers qui ont spontanément proposé diverses solutions palliatives — ont permis de simplifier le code source précédemment évoqué de telle façon à le rendre aussi accessible que possible. Maintenant, je me pose la question de savoir ce qu’il pourrait advenir de modèles tels que article, ouvrage ... au regard de leur nécessaire présence si l’on tient à rendre les harvsp fonctionnels. Pourtant, leur introduction dans le code source est aussi potentiellement en mesure de rebuter le nouveau-venu au cours de ses premiers élans. Le wysiwyg permettrait-t-il accessoirement une insertion apparentée ? Ou faudra-t-il plutôt se résoudre à envisager d’autres alternatives transitoires ? — euphonie ^bréviaire 8 novembre 2012 à 16:10 (CET)

18.  Supprimer Bonjour. Je suis sans hésitation pour la suppression de ce modèle. Il ne fait que compliquer les choses et diminuer la lisibilité et l'accessibilité des pages de code.
    Cordialement, Ediacara (d) 8 novembre 2012 à 11:34 (CET).
19. Ce n'est probablement pas le modèle le plus gênant, mais sur le principe, on a plus besoin de rédacteurs (et de contenu) que d'une typo parfaite. Je suis pour limiter l'usage des modèles au maximum.Hadrien (causer) 8 novembre 2012 à 11:38 (CET)

    Raison pour laquelle, sans doute, il serait souhaitable que les contributeurs anciens qui corrigent les erreurs, entre autres, des nouveaux ne puissent plus le faire. Daniel*D 8 novembre 2012 à 11:44 (CET)

    ? Hadrien (causer) 8 novembre 2012 à 14:24 (CET)

    Lire la partie Discussions. Daniel*D 8 novembre 2012 à 14:34 (CET)

    J'avais lu. Je ne comprends toujours pas. Mais je pense que dans un projet d'encyclopédie ouverte à tous, avec des articles en perpétuelle évolution, et qui en est à un niveau aussi balbutiant en matière de contenu, la correction typographique est accessoire, et qu'il faut faciliter autant que possible les contributions, et donc limiter l'usage des modèles. Tout ça devrait être réglé dans le logiciel, comme dit par ailleurs. Et en attendant ? on attend, et on fait autre chose.Hadrien (causer) 8 novembre 2012 à 14:46 (CET)

20.  Supprimer D'accord avec Esprit Fugace. --Jack^rs le 8 novembre 2012 à 11:39 (CET)
21.  Supprimer ou transférer sur maniaquesfr.wikipedia.org. Moyg hop 8 novembre 2012 à 12:05 (CET)

    Et voici l'inévitable attaque personnelle si attendue. Bon ce n'est que le deuxième sur cette page... Daniel*D 8 novembre 2012 à 12:31 (CET)

22. etc...--Chandres (✉) 8 novembre 2012 à 14:18 (CET)

    Exemple parfait de typographie déplorable. Daniel*D 8 novembre 2012 à 14:32 (CET)

    jecri ptetre pas bien la france mais moua je pace pa mon tant a gonflé les zotres ai a fère malle o mouches!--Chandres (✉) 8 novembre 2012 à 17:19 (CET)

    Moi non plus, tant que l'on ne cherche pas. Daniel*D 8 novembre 2012 à 17:42 (CET)

23. Ce modèle est tellement nuisible qu'il cause des erreurs typographiques, en plus du problème évident d'accessibilité en écriture. D'ailleurs, tous les modèles typographiques devraient être remplacés par du HTML, qui est très largement plus connu dans le monde. Remplaçons tous les {{etc.}} par &nbsp;etc. C'est aussi moche, mais au moins c'est universel sur le Web. Marc Mongenet (d) 8 novembre 2012 à 14:39 (CET)

    Et largement plus difficile à écrire, en particulier pour les nouveaux. Daniel*D 8 novembre 2012 à 14:43 (CET)

    Sur mon clavier romand, le caractère & est bien plus facile à obtenir que les {}. Marc Mongenet (d) 8 novembre 2012 à 14:46 (CET)

    En outre, je remarque que des arguments très ressassés pour ce modèle semblent faire passer l'intérêt de normes tierces devant l'intérêt de Wikipédia. Comme on est sur Wikipédia, ça me gène. Marc Mongenet (d) 8 novembre 2012 à 14:46 (CET)

    Pour ce qui concerne l'espace insécable, il ne s'agit pas de normes tierces, mais d'un détail sourcé par un ouvrage de référence, comme il se doit sur Wikipédia. Cette PàS se moque donc d'une règle → WP:V et de deux recommandations → WP:CT et WP:CVS. Daniel*D 8 novembre 2012 à 14:56 (CET)

    Bof, en conclusion, tout le monde s'accorde pour trouver que les normes, la typographie, l'accessibilité, Wikipédia, etc., c'est bien. La différence, c'est entre ceux qui pensent que ce modèle améliore notablement Wikipédia avec des inconvénients négligeables, et ceux qui pensent que ce modèle n'améliore pas significativement Wikipédia, avec des inconvénients notables. C'est une question de rapport de service rendu sur inconvénients générés, comme l'a parfaitement résumé Esprit Fugace. Marc Mongenet (d) 8 novembre 2012 à 15:04 (CET)

    Les règles et recommandations de Wikipédia, c'est du pipeau. Intéressant. Daniel*D 8 novembre 2012 à 15:09 (CET)

    Oh mais si l'on veut chercher de ce côté, allons directement aux principes fondateurs (en version originale pour faire bonne mesure). The principles and spirit of Wikipedia's rules matter more than their literal wording, and sometimes improving Wikipedia requires making an exception to a rule. A ce propos, Ludo t'a gentiment répondu plus haut il apparait nécessaire de supprimer le bouton modifier. Je serai plus direct ; pour écrire commencer par les principes fondateurs et tout ce qui en découle est une toute autre complication. Ce vers quoi on devrait diriger les nouveaux. je pense qu'il ne faut rien avoir compris à l'approche wiki qui permet l'existence de Wikipédia. Marc Mongenet (d) 8 novembre 2012 à 16:00 (CET)

    Je pense avoir parfaitement compris le principe, au contraire. De mon expérience, il résulte que le système wiki, attrayant qu'il est pour un débutant, lui dissimule en réalité les complications réelles de Wikipédia qui sont par exemple : la compréhension de la question du sourçage, des droits d'auteurs et des nombreuses règles très difficiles à découvrir et à appréhender. Mais cela est voulu chacun le sait. Daniel*D 8 novembre 2012 à 17:38 (CET)

24.  Supprimer Je ne suis ni un débutant ni un vieux briscard. Il m'arrive souvent de renoncer à une modification sur le sens duquel je suis certain qu'elle est nécessaire, simplement parce que j'y vois un nombre trop important de {, de |, de [ ou de<, entourés de ou entourant des lettres, et dont je crains de ne pas comprendre la logique et donc surtout de craquer l'ordonnancement. Cette profusion de signes n'est pas seulement inutile, elles est nuisible car elle rebute beaucoup de contributeurs de bonne volonté, et pas seulement des débutants.
    Le mieux est l’ennemi du bien : WP fourmille d'erreurs, d'affirmations approximatives et/ou non sourcées, et la tâche urgentissime serait de le rendre formellement conforme au Lexique des règles typographiques en usage à l’Imprimerie nationale, France, Imprimerie nationale, 2002 (réimpr. 2007, 2008, 2011), 6^e éd. (1^re éd. 1975), 197 p. (ISBN 978-2-7433-0482-9), p. 6 et 146, qui sert de référence à nos recommandations en matière de typographie. Même en ne s'en tenant qu'à la forme, n'y a-t-il pas suffisamment de fautes d'orthographe et de grammaire, de phrases incompréhensibles, de paragraphes dont le mauvais agencement rend le texte incohérent pour privilégier l'impeccabilité des espaces entourant ou n'entourant pas une abréviation latine d'usage courant comprise par tous ? Et pour ne s'en tenir qu'à la ponctuation, n'y a-t-il pas pléthore d'articles dont l'approximation de nombreux contributeurs rend la compréhension difficile, parfois même contraire au sens recherché, pour s'intéresser aux points et virgules entourant ces trois lettres, alors que l'erreur éventuelle de cette ponctuation n'en affecte en rien le sens ?
    Le mieux est l’ennemi du bien : à répondre à chaque opinion, avec la certitude absolue d'avoir raison contre chaque argument, tu marques des buts contre ton camp modèle, Daniel*D. Tu ne donnes pas envie d'être d'accord avec toi. Quand tu reliras à tête reposée, hors ton emportement actuel, tes réponses et tes commentaires dans les boîtes de dialogue, tu t'apercevras sans doute que les mots souvent durs que tu emploies vis-à-vis de tes contradicteurs peuvent aussi bien s'appliquer à toi-même.--Rigoureux (d) 8 novembre 2012 à 21:30 (CET)

    Je suis bien d'accord avec tes remarques sur les défauts des articles et mes contributions ne se limitent évidemment pas à la caricature que tu indiques : « tâche urgentissime, etc. » un exemple. N'étant l'auteur que d'une infinitésimale partie des trucs qui te rebutent (le modèle en question étant lui-même très simple), je trouve toutes les critiques de cette page surréalistes (sans oublier les commentaires de diff de mes petits camarades). Mais je ne suis en aucune façon « emporté », en plus de six ans de Wikipédia on en a vu d'autres . Bien cordialement, Daniel*D 8 novembre 2012 à 22:23 (CET)

    Au moins un point d'accord : ce n'est pas parce qu'il y a d'autres problèmes qu'il ne faut pas s'occuper de ceux que l'on perçoit. Mais des fois, ça m'interpelle tout de même : là, par exemple : deux etc. , il y en a un de remplacé par le modèle, mais pas l'autre, et la "correction" introduit au moins une erreur évidente ("comme apprenti" devenant "comm de naissancee apprenti"). Je ne sais pas à quel point le bilan de cette modif peut être considéré comme positif (considérant par ailleurs que vu l'état de l'article, il était visible que 90% était à jeter et qu'il y aurait au minimum une réécriture en profondeur). Après, ces jours-ci j'ai peut-être une dent contre la typo à cause de ce genre de tracas. La typo devrait être au service de la lisibilité, par l'inverse... Esprit Fugace (d) 8 novembre 2012 à 23:08 (CET)

    Totalement ok avec ta première phrase. La correction avec le modèle sans virgule (version du modèle en effet inutile-confusionnante-à supprimer... mais pas de mon fait) est bien entendu stupide, il est évident que le contributeur n'a pas lu la doc (bon moi j'ai gardé l'habitude de prendre un bouquin avant de construire quoi que ce soit, ce qui doit expliquer que je sois encore de ce monde, compte tenu de mes activités passées ). Par contre pas compris la relation qu'il y aurait avec le cafouillage/ gargouillis que tu indiques et un quelconque abus de modèle. C'est sûr que comme les clefs de tri ne sont à peu près expliquées nulle part (ou dans un recoin caché qui, jusqu'ici ne m'a pas intéressé) les gens corrigent, en croyant probablement bien faire. Encore une fois d'accord avec ta dernière phrase : la typo est bien au service de la lisibilité sinon elle ne sert à rien, le bémol c'est qu'elle s'occupe de la lisibilité des pages ce qui est parfaitement son rôle et c'est bien ainsi que les typowikipédiens l'entendent, mais que, comme les outils mis à leur disposition sont très déficients (comme déjà dit, entre autres ici et sur le bistro) il peut en résulter les inconvénients dans le code, qui t'irritent. Reconnais qu'il est tout de même énervant aussi de toujours se voir accuser de toutes sortes de maux dont la responsabilité échoit en premier lieu aux défauts du logiciel de WP. Tu te trompes de cible, tu décourages certaines bonnes volontés (je pense, par exemple à MGL, mais tu n'es pas la seule responsable) et le schmilblick ne progresse pas dans le sens que nous souhaitons tous. Bien cordialement tout de même. Daniel*D 8 novembre 2012 à 23:59 (CET)

    En effet, je confirme, 90 % étaient bien à jeter et que voila une modif salutaire → [4]. Bon il faudrait encore en nettoyer la présentation, mais comme Wikipédia est avant tout un plaisir, on ne va pas abuser non plus, ce serait du masochisme . Daniel*D 9 novembre 2012 à 00:11 (CET)

25. Quant un modèle concerne le langage courant, je crois qu'il doit concerner essentiellement la sémantique et non la syntaxe.--Contacter Yodaspirine(Qui?) 9 novembre 2012 à 16:50 (CET)
26. comment dire... Non. cf notamment Akeron et les 2 premiers points de 94.140.9.4. Ne brandissez donc pas des "LA W3C DIT QUE" à tord et à travers. Pour la reste, ça complique l'édition et je n'y vois aucun avantage. - DarkoNeko ^(mreow?) 10 novembre 2012 à 10:53 (CET)
27.  Supprimer. Son intérêt tient essentiellement à l’ajout de l’espace insécable qui évite le renvoi à la ligne en fin d’énumération. Bien qu’étant très « typophile », ça me paraît tout de même un peu maigre comme bénéfice — en tout cas pas suffisant pour contrebalancer l’inconvénient d’une moindre lisibilité pour un potentiel nouveau contributeur. D'autres modèles pourraient sans doute être remis en question, mais c’est à discuter au cas par cas et je me garderais bien de vouloir généraliser cet avis. --Wikinade (d) 10 novembre 2012 à 20:20 (CET)
28.  Supprimer L'analyse du rapport bénéfice/inconvénients, c'est-à-dire "maigre avantage" (espace insécable) / "forts inconvénients" (complexité pour les nouveaux) penche pour une simplification de la syntaxe dans ce cas précis, sachant que la correction des erreurs de typographie résiduelles dans les articles est faisable par un bot. -- Speculos ^✉ 14 novembre 2012 à 16:19 (CET)

    Question du comte Ɲemoi – Heu… en disant « la correction des erreurs de typographie résiduelles dans les articles est faisable par un bot », tu penses à quoi ? à l’insertion massive de «   » dans les articles ? bien sûr, un robot pourrait le faire, mais ça ne me semble pas vraiment un gain au niveau de la simplicité… Ce 14 novembre 2012 à 16:37 (CET).

    Non, je pensais aux cas évoqués par Daniel ci-dessus: « etc... », « ,etc... », « ,etc. », « ,etc » par exemple, qui relève du même traitement que les fautes d'orthographe et ne nécessite pas l'utilisation d'un modèle. -- Speculos ^✉ 14 novembre 2012 à 16:45 (CET)

    Modèle que j'ai justement créé pour corriger beaucoup plus facilement ces erreurs très courantes, tout en ajoutant l'espace insécable pérenne. Avec WikEd cela devient un jeu d'enfant au lieu d'une opération fastidieuse. Si corriger ce que tu déclares relever simplement du même traitement que les fautes d'orthographe était si simple, bien évidemment, jamais je n'aurais réalisé un tel modèle. Par ailleurs l'espace insécable étant indispensable comme déjà répété sur cette page — selon les sources, essentiel les sources, sur Wikipédia —, tout avis contraire se révèle invalide. Il va de soit que «   », seule façon correcte et pérenne d'insérer des espaces insécables, en dehors de l'utilisation de modèles, est beaucoup plus rebutant pour un novice que quatre accolades et comme l'écrit Nemoi ci-dessus, ce n'est pas vraiment un gain au niveau de la simplicité. Daniel*D (d) 14 novembre 2012 à 19:34 (CET)

    Absolument pas convaincu, désolé. -- Speculos ^✉ 14 novembre 2012 à 22:46 (CET)

29.  Supprimer Source d'erreurs et de complexité inutile. Ljubinka (d) 15 novembre 2012 à 13:36 (CET)
30. Supprimer à terme. Mauvaise solution à un problème d'affichage. Heureusement mediawiki a quelques règles déjà codées, sinon je crains que des pour auraient ajouté {{?}} pour ajouter une espace insécable, et le présenteraient comme « seule solution ». FrançoisD 15 novembre 2012 à 18:31 (CET)

    Bien vu. Mais là, je pense que les partisans de la suppression de ce modèle auraient été plus faciles à convaincre : l’usage de l’expression « etc. » n’étant pas très fréquente, les cas où, si l’espace après la virgule n’était pas rendue insécable grâce à ce modèle, l’abréviation latine se retrouverait à la ligne resteraient, admettons le, assez rares ; autant les points d’interrogation, d’exclamation, et les guillemets sont beaucoup plus fréquents, et c’est franchement désagréable de les retrouver en début de ligne, sur certains sites ne tenant aucun compte des règles de typo (d’ailleurs, pour ceux qui disent que le LRTUIN n’a aucune valeur sur le web, vous noterez que, même sur les écrans, avoir un point d’interrogation en début de ligne est très moche). L’utilité aurait été beaucoup plus évidente. Cordialement --Pic-Sou 15 novembre 2012 à 22:20 (CET)

Neutre

1.  Neutre Une espace avant une virgule ou deux virgules gênent certainement plus le lecteur lambda que l'absence de virgule ; de plus, les bénéfices en accessibilité sont quasi-nuls. Mais les 10000 modifications nécessaires pour enlever ce modèle, alors qu'il est tout de même souvent bien utilisé, ont aussi un rapport signal/bruit bien faible. Bibitono ^_^ 8 novembre 2012 à 00:24 (CET)
2.  Neutre je milite pour « … » qui est un signe typographique tout à fait rentré dans les mœurs il me semble, et avec lequel on a pas à se prendre la tête sur les espace insécables et les infobulles. Pourquoi vouloir faire pompeux en mettant des abréviations latines ? schlum ^{=^.^=} 8 novembre 2012 à 02:02 (CET)

   J'allais suggérer, à demi-sérieusement, de remplacer toutes les occurrences du modèle (hors citations) par « … », mais après coup, je me suis demandé si Mediawiki remplaçait automatiquement l'espace précédant ce caractère par une insécable, comme c'est le cas pour les signes de ponctuation doubles (?, !, ; et :). Je n'ai pas su trouver la réponse. – Swa cwæð Ælfgar (d) 10 novembre 2012 à 00:54 (CET)

   Normalement, il n'y a pas d'espace avant les points de suspension… donc pas de problème à ce niveau. –Akeron (d) 10 novembre 2012 à 01:51 (CET)

   Il n'en met pas, j'ai vérifié. Il ne manquerait plus qu'il en mette là et pas où il devrait ! Sinon etc. et ... n'ont pas tout à fait le même sens et en interdire l'usage me semble limite, mais on voit tellement du choses étranges sur WP. Daniel*D 10 novembre 2012 à 03:09 (CET)

   Pas tout à fait le même sens, effectivement, « … » ne pouvant pas toujours être remplacé par « etc. » ; l’inverse par contre, si. Sinon, oui, pas d’espace avant « … ». schlum ^{=^.^=} 15 novembre 2012 à 11:37 (CET)

3.  Neutre Idem schlum — Arkanosis ^✉ 8 novembre 2012 à 02:31 (CET)
4. Pas mieux, modèle qui complique un peu la vie pour 99% des gens, mais l'argument de l'accessibilité est un peu imparable, comme d'hab. --Nouill (d) 8 novembre 2012 à 06:26 (CET)

   D'après Akeron dans la discussion, l'accessibilité n'est pas un problème, etc. (sans modèle) étant correctement lu par les lecteurs d'écran et conforme aux normes W3C. Esprit Fugace (d) 8 novembre 2012 à 08:41 (CET)

   Voir ma réponse à l’argument d’Akeron. Le W3C ne demande d’utiliser la balise <abbr> que dans certains cas (première apparition d’une abréviation peu courante) mais impose d’expliciter d’une manière ou d’une autre chaque abréviation. Si tu préfère : t’es pas obligée d’utiliser {{etc}} mais si tu le fais pas, il faudra expliciter l’abréviation autrement. --Pic-Sou 8 novembre 2012 à 10:32 (CET)

   Ce sont des "guidelines" et non des règles pour une bonne raison. Présente-moi une personne, une seule, qui ait rencontré la plus petite difficulté à comprendre "etc." parce que cette abréviation n'était pas explicitée, et j'admettrais l'utilité de cette explicitation. Dans le cas contraire, c'est respecter des directives pour l'amour des directives. Esprit Fugace (d) 8 novembre 2012 à 11:34 (CET)

   Il faut être pragmatique dans l’interprétation des recommandations du W3C — qui est d’ailleurs une institution dont le travail est basé essentiellement sur le pragmatisme même s’il y a eu quelques écarts à une époque. Illustration : le lien que tu donnes plus haut pour le niveau d’exigence le plus haut en termes d’accessibilité contient plusieurs occurences de « etc. » (5, très exactement), et aucune d’entre elles n’est encadré par des balises abbr… Lorsqu’on fait de l’accessibilité, c’est pour résoudre de vrais problèmes, pas pour le plaisir de pouvoir dire qu’on a suivi à la lettre la moindre des recommandations. L’esprit critique est au moins aussi important que les recommandations dans ce domaine — probablement plus, même ; et à vouloir trop en faire, on risque surtout d’avoir des effets opposés à ceux recherchés. Je sais de quoi je parle : j’ai beaucoup péché par excès de suivi de diverses « bonnes pratiques » par le passé. Amicalement — Arkanosis ^✉ 8 novembre 2012 à 11:59 (CET)

   Toutafé et j'ajoute que l'accessibilité a bon dos puisque celle concernant les éditeurs est complètement ignorée et même aggravée au passage. –Akeron (d) 8 novembre 2012 à 14:41 (CET)

5.  Neutre Plutôt pour la suppression. Je pense que nous avons atteint un seuil d'excès de qualité, en témoignent les nombreux pestages sur le bistrot au sujet des modèles et les soucis fort rébarbatifs rencontrés par les débutants. Pour moi la seule solution acceptable serait l'implémentation d'un système de remplacements automatiques, un peu comme ça se fait déjà pour certains signes de ponctuation, et dont la liste serait définissable sur le wiki. Une liste de règles du genre /, ?etc\./ et /(?<!\w|, ?)etc\./. Ayant un peu réfléchi à l'idée, ça me paraît tout à fait envisageable. Des développeurs MediaWiki seraient motivés pour écrire une telle extension ? od†n ↗^blah 8 novembre 2012 à 16:42 (CET)

   Je suis persuadé aussi que ce serait largement plus simple, si l’on avait une extension qui définisse une liste de remplacement automatique : les espaces insécables, mais aussi les infobulles sur les expressions couramment utilisées, les apostrophes (je l’ai pas dit, je l’ai pas dit ). Le problème, c’est que « yakafaukon » : pour l’instant, on a pas cette extension. Il faut donc faire sans. Mais si tu sais programmer des patches, c’est une bonne idée ! Cordialement --Pic-Sou 8 novembre 2012 à 18:42 (CET)

   Le problème c'est ça, le nombre de développeurs MediaWiki sur le wiki fr: se compte sur les doigts d'une main d'un mafieux qui a du mal à payer ses dettes à temps. od†n ↗^blah 9 novembre 2012 à 08:07 (CET)

   Tu peux me les donner, stp ? --Pic-Sou 9 novembre 2012 à 12:26 (CET)

   <délation> IAlex, Hashar, Karima Rafes… </délation> od†n ↗^blah 9 novembre 2012 à 14:21 (CET)

   Bon bah j’irais lui faire une gentille petite demande ! --Pic-Sou 9 novembre 2012 à 14:39 (CET)

6.  fort les modèles typographiques restent quand même des caches misères. --PierreSelim ^{[let discussion = fun _ ->]} 15 novembre 2012 à 12:44 (CET)

Avis non décomptés

Exception étant faite pour le créateur de l’article, les avis d’utilisateurs récemment inscrits, ayant moins de cinquante contributions ou non identifiables (IP, opinions non signées...) ne sont en principe pas pris en compte. Si vous êtes dans ce cas, vous pouvez toutefois participer aux discussions ou vous exprimer ci-dessous pour information :

1. Que de confusions...
   1. Sur la question d'accessibilité : la norme internationale d'accessibilité suivie sur fr.wikipedia.org exclut du champ des abréviations à expliciter celles qui sont entrées dans le langage courant. C'est le cas de « etc. ». La présence ou l'absence du modèle pour « etc. » n'est pas un enjeu décisif pour cette PàS et ne devrait pas être pris en compte : suppression ou conservation sera à peu près indifférent de ce point de vue.
      Par contre, affirmer que la question ne se pose pas parce que les lecteurs d'écran gèreraient cette abréviation, en s'appuyant sur un produit qui n'est pas un lecteur d'écran et qui est totalement confidentiel, en ignorant tout de la question des dictionnaires dans les lecteurs d'écran, il faudrait éviter. Donner un avis d'accessibilité comme quoi ce serait une obligation, sans maîtrise du sujet, pareil. L'accessibilité n'empêche pratiquement, rien, mais encore faut-il la connaître.
   2. Sur la question de la typographie : tant qu'une réflexion de fond n'aura pas été engagée sur les limites inhérentes des usages historiques de la typographie de l'imprimé sur des medias où les conditions de production et de restitution sont totalement différentes, le débat sera réduit à l'affrontement frontal et stérile des gens qui brandissent tel ou tel code de l'imprimé qu'il faut appliquer jusqu'à la dernière lettre (parfois mal lue, qui plus est) et de ceux qui brandissent un besoin de simplicité de l'édition évident mais mal géré (voir point suivant). Là encore, on y va au jugé sur des bases approximatives, sans évaluation, sans documentation, sans priorisation, ce qui ne peut guère aboutir qu'à des décisions hasardeuses et à des Ko de polémiques personnalisées. Bref, la question typographique ne devrait pas être prise en compte en l'état de son traitement frontal sur fr.wikipedia.org.
   3. Sur la question posée par le projet KISS : aucune évaluation, aucune recherche de méthode ni d'identification précise et opérationnelle des problèmes rencontrés, aucun outillage par critères, aucune priorisation. On jette en pâture au gré des jours et du hasard, parfois par mouvement d'humeur tel ou tel modèle, à des gens qui n'ont aucun avis réellement motivable sauf s'ils sont visionnaires. On ne leur propose que l'alternative proposition/suppression sans s'être posé la question de l'amélioration éventuelle du modèle (dont le besoin est criant) ni de ses règles d'usage. Là encore, il faudrait dans ce genre des cas plutôt renvoyer le projet KISS sur le banc de l'école avant de le prendre en compte.
      Mais ainsi est la Wikipédia francophone : il y a ici au moins trois projet à l'état embryonnaires, qu'il faudrait mettre enfin vraiment en place, travailler et faire collaborer...
      Pour cela, il faudrait aussi déjà dégager les querelles de personnes qui s'illustrent dans cette page (SM et Esprit Fugace donnent beaucoup à rire jaune).
      Bref, il faut croire qu'on peut faire quelque-chose dans les limites de Wikipédia, ce qui n'est pas évident du tout. --94.140.9.43 (d) 9 novembre 2012 à 12:03 (CET)

      Bonjour Lgd, je souscrirais bien volontiers à tout cela si l'affirmation selon laquelle « des gens [brandiraient] tel ou tel code de l'imprimé qu'il faut appliquer jusqu'à la dernière lettre (parfois mal lue, qui plus est) » n'y figurait pas. Il ne s'agit pas, concernant la référence citée, d'un code uniquement réservé à l'imprimé, il suffit d'en lire l'avant-propos pour s'en convaincre. Et le gens en question ont bien lu, annoté et utilisé en référence dans de nombreux endroits de Wikipédia (conformément à nos principes), cet ouvrage fort bien fait, très simple et que tout Wikipédien soucieux de la bonne présentation des articles devrait se procurer. Ils ne le brandissent pas et ne prétendent pas l'imposer, voir l'introduction de nos conventions. Cordialement, Daniel*D 9 novembre 2012 à 12:34 (CET)

      Il y a au moins deux objections majeures à cette pétition de principe :

      1. Un phénomène classique sur fr.wikipedia.org, rencontré constamment : on prend beaucoup de soin à définir une recommandation (pas une règle, etc.) ; on y met toutes les précautions oratoires possibles pour qu'il soit clair qu'il ne s'agit même pas d'une objectif à atteindre dans un futur identifiable, mais juste d'une image souhaitable de ce qu'il faut avoir en tête dans l'absolu si on pouvait, à prendre avec toute la tolérance nécessaire... Et cela se traduit concrètement par des contributeurs qui ne retiennent qu'un « la règle, c'est ça, taisez-vous » et qui y vont à la masse façon maoïste en brandissant, ici, leur code typographique en guise de Petit Livre rouge. Bref, aucune priorisation (et en sens inverse, KISS est en train de tomber exactement dans ce travers, à vrai dire).
         C'est une énorme erreur de poser ici une page meta de « règles à prendre avec précautions ». Il ne faudrait y poser que des pages à l'application très simple, immédiate et qui puisse être frontale sans problème.
      2. Le fameux Lexique n'a, malgré toutes les citations répétées d'une phrase extraite son introduction, aucune pertinence en dehors de l'imprimé, faute d'avoir posé l'amorce d'une réflexion sur la typographie Web. La réflexion en question est à l'heure actuelle un champ totalement ouvert, que personne ou presque n'a abordé. En l'état, ce n'est pas une référence immédiate à retenir ici sans recul et précautions. --94.140.9.43 (d) 10 novembre 2012 à 10:32 (CET)

Juste une remarque : le projet KISS n'a pas initié cette PàS, JE l'ai fait. J'existe encore en tant qu'individu, merci (et les bancs de l'école, j'y suis). A posteriori il m'a semblé que cette page pouvait intéresser les membres de ce projet, et j'y suis passée mettre un mot. Rien de plus. Je m'abstiendrais de répondre aux arguments du genre "le problème est entre la chaise et le clavier". Esprit Fugace (d) 10 novembre 2012 à 10:48 (CET)

Écrire que le Lexique « n'a aucune pertinence en dehors de l'imprimé », c'est, peut-être, ne pas l'avoir lu. Une très grande partie de ce qui y figure est applicable sans aucun problème — et appliquée d'ailleurs dans les articles bien écrits, heureusement —, même sans avoir recours à aucun modèle. Est-ce qu'un dictionnaire ou un traité de grammaire a « posé l'amorce d'une réflexion sur la typographie Web » ? Non, pourtant les fautes d'orthographes et de grammaires ne sont pas « recommandées » dans Wikipédia. Pourquoi les fautes de typographie le seraient-elles ? Daniel*D 10 novembre 2012 à 11:47 (CET)

Il est faux de dire que le LTRUIN n’a aucune pertinence en-dehors de l’imprimé. En fait, il reste la référence mais, simplement, on peut envisager de transgresser certains points lorsqu’il s’agit de respecter d’autres règles contradictoires plus importantes. Un exemple parmi tant d’autres : la forme des appels de notes : aujourd’hui, on respecte une des syntaxes recommandées par le LTRUIN mais on nuit aux principes, plus importants encore, de clarté et d’accessibilité (liens trop petits pour cliquer dessus), qui recommanderaient plutôt de mettre les numéros d’appels de notes entre crochets, parenthèses, ou en taille normale plutôt qu’en exposant. Ici, y a-t-il une vraie raison de ne pas respecter la norme ? Une justification autre que « je pense que ça fait fuir les nouveaux » ? Je ne crois pas, donc il faudrait la respecter. Cordialement --Pic-Sou 10 novembre 2012 à 14:12 (CET)

+1, sans surprise. Daniel*D 10 novembre 2012 à 15:28 (CET)

 Conserver Utile pour respecter au mieux les conventions 78.251.237.169 (d) 15 novembre 2012 à 12:08 (CET)