Discussion Wikipédia:Prise de décision/Crochets autour des appels de notes

Proposition

Ma proposition, avec cette PDD, est de restaurer par défaut les crochets autour des appels de notes. Cependant, rien n’interdit d’étudier d’autres propositions, comme l’usage des parenthèses plutôt que des crochets.

Par ailleurs, dans le cas où plusieurs notes sont utilisées à la suite^{1, 2, 3}, il est possible de réfléchir à un moyen d’afficher ^{[1, 2, 3]} plutôt que ^{[1], [2], [3]} ou ^[1][2][3]. Voir à ce sujet {{note/test}} et User:Pic-Sou/cite_note.css.

Dans tous les cas, il n’y aura normalement pas besoin de modifier d’autres pages que MediaWiki:Cite reference link et MediaWiki:Common.css. Peut-être tout au plus le passage d’un bot sera-t-il nécessaire.

Voir aussi à ce sujet mw:Extension:Cite/Cite.php, la documentation de l’extension (en anglais).

Cordialement --Pic-Sou 1 janvier 2012 à 12:11 (CET)

Quel problème pose l'absence de crochets ? Salutations. Gemini1980 oui ? non ? 1 janvier 2012 à 17:50 (CET)

même question que Gemini. En outre je préfère le modèle sans crochets, moins lourd à la lecture. - Bzh⁹⁹(d) 1 janvier 2012 à 20:10 (CET)

Même étonnement : quel est donc le problème ? En outre, j'ai le code typographique sous les yeux et j'ai beau chercher je ne vois nulle part qu’il faille composer les appels de notes entre crochets ou entre parenthèses. --Wikinade (d) 1 janvier 2012 à 21:14 (CET)

Le seul inconvénient qu'il m'est arrivé de rencontré concerne une référence après une unité de longueur (comme 25 m³ au lieu de 25 m). Ce genre de configuration n'arrive néanmoins pas souvent car seuls les numéros de référence 2 et 3 peuvent réellement porté à confusion. Ascaron ¿! 1 janvier 2012 à 21:24 (CET)

Ce qui a donné l'idée de ce changement possible est au départ la possibilité envisagée d'appels de notes en lettres latines : au contraire des exposants numériques qui ne sont pas trop en conflit avec le texte en lettres latines (sauf unités au carré etc.), les exposants en lettres latines peuvent avoir besoin de crochets pour la clarté de lecture dans un texte en lettres latines qui a déjà des exposants. Mais de ce point de vue, la question serait plutôt s'il faut donner la possibilité de choix avec ou sans crochets (actuellement il n'y a que l'ancien système de références "à la main" {{ref label}} si on veut les crochets), et la question du défaut avec ou sans crochets est indifférente. -- Oliv0 (d) 2 janvier 2012 à 00:59 (CET)

Les appels de notes en lettres latines ou grecques sont désormais possibles (cf DIMS) : <ref group=alpha>...</ref> puis {{references|group=alpha}} (ou idem grec). -- Oliv0 (d) 5 janvier 2012 à 07:55 (CET)

Gêné que j’étais par ces mouchetures bleues partout dans le texte, j'ai changé la couleur des notes pour un gris neutre : ^{Comme ça !} . C'est bien le seul changement qui me semblerait pertinent à effectuer, mais les goûts et les couleurs sont à la discrétion de chacun, aussi n'ai-je point proposé cela à tout le monde. Trizek ^bla 2 janvier 2012 à 11:44 (CET)

Pour info, l'historique de la situation actuelle de MediaWiki:Cite reference link (pas de crochets par <ref>) :

• En 2006, Moez suggère les crochets sur le Bistro et c'est fait via DIPP ;
• une semaine plus tard, Aoineko remet sans crochets puis explique sur le Bistro qu'il ajoute la possibilité de personnaliser : « Par défaut ils ne sont pas affiché (ce qui correspond à ce qu'on trouve dans la littérature francophone), mais ceux qui le souhaitent peuvent les faire apparaitre en ajoutant à leur style personnel la ligne : .cite_crochet { display: inline; }. »

Donc tout ça a été fait assez vite et la discussion a été très courte. -- Oliv0 (d) 8 janvier 2012 à 15:10 (CET)

Si le seul problème est la confusion avec l'exposant, pourquoi ne pas écrite en toute lettre « 25 mètres » quand on veut y ajouter une référence après ? Guillaume (bah?, qu'ai-je fait?) 17 janvier 2012 à 15:12 (CET)

Il y a aussi la difficulté du clic… --Pic-Sou 18 janvier 2012 à 15:54 (CET)

Quelques extraits du Lexique des règles typographiques en usage à l'Imprimerie nationale

Mon édition (2002, p. 23) distingue 2 cas :

Appel de notes de bas de page

Le Lexique reconnait 6 types d'appel :

• L'astérisque *
  • « de préférence sans parenthèses »
  • « on ne peut pas l'utiliser au-delà du triple sur une page » donc sur Wikipédia.
• Les chiffres supérieurs sans parenthèses ¹
  • notre solution actuelle
  • « le plus simple et le plus discret des renvois »
  • « on évitera [...] dans les ouvrages où la confusion est possible avec les exposants »
• Les chiffres supérieurs entre parenthèses ⁽¹⁾
  • « moins discret et plus facile à retrouver »
• Les chiffres du corps entre parenthèses (1)
  • « la solution de facilité »
  • « trop voyant »
  • « rencontre avec les parenthèses de texte [...] pas toujours heureuse »
  • « exclut de nombreux travaux scientifiques »
• Les lettres supérieures en romain sans parenthèses ^a
  • « dans les travaux d'érudition pour signaler des variantes de texte »
• les lettres italiques bas de casse entre parenthèses (a)
  • « en principe réservées aux sous-notes »

Appel de notes bibliographiques

« On les composera en chiffres du corps entre crochets, pour les distinguer des appels renvoyant aux notes de bas de page »
Ma conclusion
Le Lexique - qui n'est d'ailleurs pas une référence absolue (pour les Québécois en particulier) et qui est créé pour les documents imprimés, pas les pages Web - fait une distinction entre 2 types d'appel que Wikipédia ne fait pas. Mais la variante avec chiffres supérieurs entre crochets n'est jamais mentionnée.
Mon avis penche très largement pour le maintien de la solution actuelle. Zetud (d) 1 janvier 2012 à 22:00 (CET)

Il est dit aussi à propos de ⁽¹⁾ (d'après cette citation) « ne prêtant pas à confusion, utilité discutable » - on peut comprendre que c'est recommandé uniquement dans le cas évoqué juste avant « dans les ouvrages où la confusion est possible avec les exposants ». En tout cas, il s'agirait alors plutôt de la possibilité de notes entre parenthèses et pas entre crochets : les appels de notes en supérieur dans les pages web Wikipédia rentrent plutôt dans la catégorie des notes de bas de page. -- Oliv0 (d) 2 janvier 2012 à 00:59 (CET)

En marge pour ceux qui s'intéressent aux autres pays francophones, un point de l'Office québecois de la langue française. Cela semble, ma foi, fort proche du lexique de l'Imprimerie. Binabik (d) 10 janvier 2012 à 13:50 (CET)

A propos du Lexique... et des usages de l'imprimé

Un rappel semble nécessaire à propos des usages typographiques de l'imprimé et des fréquentes mentions qui y sont faites en général sur Wikipédia et en particulier dans ce cas. Ces usages sont ceux de l'imprimé et ne peuvent évident pas tenir compte des spécificités d'un tout autre media, qui est le document électronique, tout particulièrement quand il s'agit de contenus Web.

La question mérite un peu de finesse et surtout pas de prises de positions tranchées et a priori. Disons, en première approximation, qu'il y a au moins:

• une large part d'usages typographiques de l'imprimé évidemment tout à fait pertinents sur le Web
• certains usages à considérer avec plus de discernement, quant ils se heurtent aux contraintes et aux besoins de la consultation d'un document dans un media très différent de l'imprimé.

La redoutable question des crochets en est un bon exemple : quoi qu'en dise le Lexique..., qui ne parle que pour le papier, ces appels de notes et de références sont ici des hyperliens. Ce qui les soumet à deux impératifs classiques en matière d'ergonomie Web:

• faciliter l'identification immédiate des liens et de leur éventuel comportement spécifique ;
• faciliter le clic sur le lien en évitant les libellés qui aboutissent à une zone de clic minimaliste de quelques pixels sur quelques pixels.

Ceci plaide fortement en faveur du retour de la Wikipédia francophone au mode d'affichage de ces liens qui est celui par défaut dans mediaWiki (et ce n'est pas pour rien) :

• affichage par défaut des crochets ou de parenthèses (peu importe, quoique les parenthèses seraient peut-être préférables pour éviter la confusion avec le rendu des modèles du genre ^{[réf. nécessaire]})
• possibilité via les préférences utilisateurs de masquer ces crochets pour ceux qui le souhaitent.

Autrement dit, il s'agit simplement d'inverser la situation actuelle et de revenir au comportement par défaut de mediawiki, ce qui ne remet en rien en cause le respect des préférences personnelles puisque celles-ci continueraient à être gérées. Il s'agit juste de ne pas imposer par défaut à tous les visiteurs de la Wikipédia francophone la plus risquée des deux solutions possibles.

D'autre part, un autre rappel: la phase de discussion est surtout là pour permettre d'aboutir à une formulation de décision à proposer aux wikipédiens qui trancheront. La formulation actuelle de la PDD est, de ce point de vue, largement à améliorer : c'est là-dessus que la discussion devrait se concentrer.

Pour conclure : quand je parlais d'ergonomie Web, on peut tout aussi bien considérer que le Lexique... est un manuel d'ergonomie papier. Il serait regrettable que deux démarches identiquement soucieuses d'ergonomie ne parviennent pas à s'accorder, tout de même . --Lgd (d) 2 janvier 2012 à 07:02 (CET)

Sur le sujet de l'ergonomie, je tiens juste à rajouter que diverses études montrent que la lecture sur écran demande un effort cognitif plus important, est plus lente et/ou fatigue plus. De multiples facteurs sont en cause bien évidemment, mais il me semble que tout « alourdissement de la lecture » sur un site comme Wikipédia doit être mûrement pensé. (Source sur le sujet). Binabik (d) 2 janvier 2012 à 11:17 (CET)

Attention, « alourdissement de la lecture » est une expression très dangereuse à employer ici : dans deux secondes, des gens vont sauter sur l'occasion pour expliquer que justement les fichus crochets en question alourdissent la lecture . --Lgd (d) 2 janvier 2012 à 11:45 (CET)

J'ai mis entre guillemets ; je mentionnais juste ce point car il me semblait crucial sur le sujet de la lecture multimédia. Des contre-arguments seront d'ailleurs toujours possibles (par exemple, un texte plus clair est plus facile à lire), mais je crains qu'il y ait une grande part de subjectivité, sauf à conduire une expérimentation comparative . Binabik (d) 4 janvier 2012 à 17:25 (CET)

Il me semble que les crochets autours des appels de notes alourdissent la lecture. Visite fortuitement prolongée (d) 7 janvier 2012 à 22:31 (CET)

« faciliter l'identification immédiate des liens et de leur éventuel comportement spécifique ; » (Lgd) Dans le web, la norme est d'utiliser le soulignement pour ce faire. Personnellement, je n'ai aucune difficulté à distinguer km² et km². Visite fortuitement prolongée (d) 7 janvier 2012 à 22:31 (CET)

La différence entre les couleurs n’est pas évidente si le support de lecture a un faible contraste ou si l’utilisateur a besoin d’un plus fort contraste que la moyenne.

D’autant plus si la note a déjà été visitée (le lien est plus foncé), ce qui peut être le cas pour une note nommée à appels multiples déjà lue lors d’une occurrence précédente.
Ltrl G, le 7 janvier 2012 à 23:14 (CET)

Tiens, je croyais que ce qui expliquait nos appels de notes différents du Wikipédia anglais c'était nos règles typographiques très différentes, mais en fait je vois que chez eux aussi les crochets sont une innovation pour l'usage web et ne correspondent pas à un usage typographique classique :

• dans le très connu Chicago Manual of Style, 16th Edition, September 2010 : « Footnotes - Note numbers should begin with “1” and follow consecutively throughout a given paper. - In the text, note numbers are superscripted. » donc uniquement xxx¹ xxx² xxx³ ;
• dans le U.S. Government Printing Office Style Manual, 30th Edition, 2008 : « 15.12. For reference marks use: (1) Roman superior figures, (2) italic superior letters, and (3) symbols. » - c'est-à-dire dans l'ordre de préférence : xxx¹ xxx² xxx³ ; xxx^a xxx^b xxx^c ; xxx* xxx† xxx‡ xxx§.

Distinction entre note et référence

Actuellement, la rédaction des articles ne fait pas de différence (par défaut) entre note et référence. Dans les articles où une distinction est faite, c'est le groupe des notes qui est alourdi par un préfixe. J'aurais tendance à proposer plutôt que les appels de note restent discrets, en exposant (avec parenthèses ou non, même si je reconnais que la version sans parenthèses mène plus facilement à des confusions), et que les appels de référence soient mis entre crochets (ainsi que le préconise le Lexique, mais cela demande une modification du logiciel) ou munis d'un préfixe « Réf » (ce qui peut déjà se faire simplement). Ambigraphe, le 2 janvier 2012 à 11:05 (CET)

Réponse du comte Ɲemoi – Est discutée en même temps sur DIMS — mais il me semble que la discussion gagnerait à être déportée ici — la possibilité d’introduire une notation par lettres en plus de la notation par chiffres. En ce cas, cette nouvelle servirait vraisemblablement aux notes, et l’actuelles aux sources (plus nombreuses). Il me semble que cette prise de décision devrait être plus générale, et traiter des différents problèmes actuels des appels de note, dont celui-ci. Joyeuse année 2012, ce 2 janvier 2012 à 15:18 (CET).

De l'art d'enliser une éventuelle décision ciblée et précise (les crochets) en la transformant à vous deux en problème pandoresque et insondable (les notes, les références, oui mais, non, et encore, quoique) alors que ce sont déjà et d'abord deux sortes de questions bien distinctes. Restons sur des choses simples . Ouvrez une PDD distincte si vous souhaitez trancher par ailleurs sur ce que doit être le zig des notes, le zag des sources, le zob des autres, etc. --Lgd (d) 2 janvier 2012 à 15:25 (CET)

Je pense en effet qu’on gagnerait à séparer les discussions. Opportunité des crochets ici, éventuellement fusion des crochets plus tard, groupes prédéfinis en DIMS (si quelqu’un pouvait la traiter, maintenant, ce serait gentil) et utilité du modèle note sur sa PDD… Cordialement --Pic-Sou 2 janvier 2012 à 15:29 (CET)

Réponse du comte Ɲemoi – Je reste dubitatif — mais nous avons un spécialiste des prises de décisions dans la salle, je le laisse donc agir. Ce 2 janvier 2012 à 15:35 (CET).

Je ne cherche pas à enliser la décision, mais à préciser la question. Cette prise de décision concerne-t-elle les appels de notes et de références, ou seulement les appels de notes ou seulement les appels de références ? Plus explicitement, cela concernera-t-il tous les groupes de notes ou seulement le groupe par défaut ? Ambigraphe, le 4 janvier 2012 à 17:44 (CET)

Donc...

Je pense qu’il faudrait, plutôt que de débattre ici sur les crochets, commencer à réfléchir sur la proposition que l’on soumettra au vote. La question étant très simple (« êtes-vous pour que les crochets autour des notes soient affichés par défaut et soient désactivables dans les paramètres personnels ? »), je pense qu’on peut se contenter d’un simple vote à la majorité. À moins que quelqu'un n’ait de proposition à rajouter, auquel cas on pourra envisager une seconde question ou un vote Condorcet.

Par ailleurs, je pense qu’il serait bien ensuite seulement pour les pro- et anti-crochets d’ouvrir des sections avec les arguments.

Cordialement --Pic-Sou 4 janvier 2012 à 14:44 (CET)

Excellente proposition. Et je dis tout de suite que je suis pour. Ces temps-ci, je me promène pas mal sur les pages anglophones, et je trouve les crochets bien agréables, plus visibles peut-être.

Cordialement--ManiacParisien (d) 4 janvier 2012 à 15:39 (CET)

Ça me semble raisonnable, mais je suis traditionnellement contre les votes à la majorité pour tout ce qui concerne le main. Binabik (d) 4 janvier 2012 à 16:56 (CET)

C’est vrai, mais si l’on fixe la limite à 60% par exemple, que fait-on si 55% des votants sont pour le changement ? On laisse sans crochets ? --Pic-Sou 4 janvier 2012 à 17:02 (CET)

C'est effectivement le principe de la forte majorité (sans parler de consensus, 55, 60, 2/3...), et c'est également ce qui s'est passé ici (seulement 51,4 % de pour ; j'étais dans les pour). Il y a deux arguments pour moi : d'abord, le résultat est plus consensuel sur le long terme s'il n'y a plus de cinq votes d'écart, et ensuite, il est peu légitime de modifier un usage ancré de longue date pour une courte majorité à un instant t (les avis étant mouvants par nature) ; il vaut mieux envisager d'autres solutions. Puisque tout changement dans le main entraîne des nouveautés pour tous, contributeurs et lecteurs. Binabik (d) 4 janvier 2012 à 17:20 (CET)

Je croyais que l'usage des crochets était une règle de typographie de l'anglais, contrairement au français, et qu'on ne l'utilisait pas pour cette raison sur la wikipédia francophone. Tella (d) 4 janvier 2012 à 17:17 (CET)

Question du comte Ɲemoi – Je lis actuellement supra « Par ailleurs, dans le cas où plusieurs notes sont utilisées à la suite^{1, 2, 3}, il est possible de réfléchir à un moyen d’afficher^{[1, 2, 3]} plutôt que ^{[1], [2], [3]} ou ^[1][2][3] »… qu’est-ce qu’on met au vote, au juste ? la remise de crochets quelque soit le rendu choisi ? en ce cas, quels sont les liens ? comment on peut faire un vote à la majorité lorsqu’il y a quatre propositions ? qu’en est-il des parenthèses ? Ce 4 janvier 2012 à 17:43 (CET).

Heum, oui, on peut songer à deux questions :

• Plutôt rien, parenthèses ou crochets ?
• Si parenthèses ou crochets, plutôt [1][2][3]/(1)(2)(3), [1], [2], [3]/(1), (2), (3) ou [1, 2, 3]/(1, 2, 3) ?

Après, je ne sais pas si la deuxième question est primordiale. On peut aussi fusionner les questions et faire du Condorcet.

@Binabik : va pour 60%, si tout le monde est d’accord.

Cordialement --Pic-Sou 4 janvier 2012 à 18:59 (CET)

Autres possibilités (pas forcément à mettre au vote, juste comme élément de réflexion pour décider de ce qui est mis au vote) :

• Quel que soit le nouveau comportement par défaut (avec ou sans parenthèses/crochets), faut-il prévoir une façon de l'inverser (sans ou avec) dans un groupe de notes donné ? (pour le lecteur moyen non connecté et pas par paramétrage individuel vector.css)
• Ce nouveau comportement par défaut (et cette possibilité de l'inverser) doit-il concerner seulement les nouveaux groupes d'appels de notes non numériques davantage susceptibles d'entrer en conflit avec les exposants du texte (xxx^a xxx^b xxx^c ou xxx^(a) xxx^(b) xxx^(c) ; xxx^α xxx^β xxx^γ ou xxx^(α) xxx^(β) xxx^(γ)), ou bien aussi les anciens appels de note numériques ? (xxx¹ xxx² xxx³ ou xxx⁽¹⁾ xxx⁽²⁾ xxx⁽³⁾ ; xxxⁿ¹ xxxⁿ² xxxⁿ³ ou xxx⁽ⁿ¹⁾ xxx⁽ⁿ²⁾ xxx⁽ⁿ³⁾ etc.) -- Oliv0 (d) 5 janvier 2012 à 08:38 (CET)

Si vous souhaitez conserver la cohérence de l'affichage nécessaire pour permettre l'identification immédiate de ces liens, la mise en forme retenue (que ce soit crochets ou parenthèses ou rien) doit s'appliquer sans distinction à tous les appels de notes (numérique, groupes, alpha, etc.). Il ne doit pas non plus y avoir de dispositif permettant de l'inverser ponctuellement. --Lgd (d) 6 janvier 2012 à 07:47 (CET)

+1 Lgd. Par ailleurs, je ne pense pas que ce soit faisable techniquement… Les seules options possibles doivent être crochets ou rien. Cordialement --Pic-Sou 6 janvier 2012 à 09:20 (CET)

Alors nos habitudes typographiques françaises (règles ci-dessus) font que les crochets seront jugés moches et les parenthèses inutiles (sauf cas de confusion possible, mais cette distinction ne serait pas autorisée). Et de façon générale, si on sait exactement ce qu'on veut, la faisabilité technique suivra (quelqu'un imaginera un moyen). -- Oliv0 (d) 6 janvier 2012 à 10:19 (CET)

C'est bien compris, l'intendance. Signé : Mongénéral (d) 6 janvier 2012 à 14:35 (CET)

Oui, c’est exactement ça, l’intendance suivra ! Cordialement --Pic-Sou 6 janvier 2012 à 18:09 (CET)

Oui, ayons confiance. Ce n'est pas parce que moi, toi ou un autre ne savent pas le faire qu'il ne faut pas prendre une décision dans l'absolu, à charge pour les gens plus compétents d'atteindre petit à petit ce qui a été décidé. -- Oliv0 (d) 6 janvier 2012 à 19:07 (CET)

Attention: soyez conscients que, selon les cas, il peut s'agir d'une modification technique qui ne peut pas être réalisée localement et qui relève des développeurs de mediawiki. Or, l'acceptation d'une demande d'évolution sur bugzilla n'a rien d'évident. Les contributeurs qui se prononceront gagneront à savoir au moins si ce qui est proposé est immédiatement faisable ou si sa mise en place est totalement incertaine.--Lgd (d) 6 janvier 2012 à 19:51 (CET)

En tout cas, la proposition initiale qui consiste simplement à remettre les crochets ou les parenthèses en les rendant désactivables est facile à faire. --Pic-Sou 6 janvier 2012 à 19:54 (CET)

Tout à fait. Pour être précis, par ordre de difficulté :

• rétablir l'affichage crochets ou parenthèses et offrir une option dans les préférences pour les masquer est uniquement une modification locale très simple.
• en cas de rétablissement des crochets/parenthèses, un éventuel affichage des séries d'appels de notes sous la forme [1, 2, 3]/(1, 2, 3) au lieu du [1][2][3]/(1)(2)(3) par défaut peut se faire localement, mais sera déjà un peu plus délicat (cf ce dont nous avions discuté dans ta pdd, Pic-Sou).
• afficher ou non des crochets/parenthèses selon le type d'appel de note serait en revanche beaucoup moins évident, peut-être sans possibilité de le faire localement (à vérifier, il y a peut-être une solution à tester).

--Lgd (d) 6 janvier 2012 à 20:01 (CET)

Je suis d’accord. Le dernier est faisable localement en javascript, mais ça tiendrait plus du bidouillage qu’autre chose…

Je pense donc qu’on peut le faire en trois questions :

1. Situation actuelle, crochets ou parenthèses
2. Si crochets, juxtaposés, séparés par une virgule ou fusionnés ?
3. Si parenthèses, juxtaposées, séparées par une virgule ou fusionnées ?

Le tout en Condorcet. Les aspects techniques seraient discutés ensuite. Est-ce que ça convient à tout le monde ? Cordialement --Pic-Sou 6 janvier 2012 à 21:37 (CET)

Il y a un aspect technique à préciser explicitement dans la proposition soumise au vote, afin que gens se décident en connaissance de cause et qu'il n'y ait pas de mauvaise par la suite en cas d'adoption de l'option crochets/parenthèses : les appels de notes sous la forme [1, 2, 3]/(1, 2, 3) nécessiteront a priori un changement dans les modèles et leur utilisation dans les articles, avec le passage de <ref>...</ref>{{,}}<ref>...</ref>{{,}}<ref>...</ref> à quelque-chose comme {{Refs|<ref>...</ref>|<ref>...</ref>|<ref>...</ref>}}. Ce genre de changement concerne directement les contributeurs et doit leur être soumis. Sans compter que cela suppose également un énorme travail de bot pour modifier l'existant...

Évidemment, si quelqu'un a une solution technique permettant d'obtenir des [1, 2, 3]/(1, 2, 3) sans changement de l'usage actuel, ce sera plus simple. Mais il faut le savoir à l'avance et donc ne pas repousser à « ensuite » la mise au point des solutions techniques .--Lgd (d) 6 janvier 2012 à 21:49 (CET)

En effet, il faudra les prévenir. Mais il y a un point que je trouve très problématique avec ta proposition de modèle {{refs}} (en plus du nom qui ne veut rien dire en soi) : quoiqu’il en soit, il y aura une limite au nombre de références que l’on pourra juxtaposer… Et cumuler un tag et un modèle me paraît lourdingue… Cordialement --Pic-Sou 6 janvier 2012 à 22:02 (CET)

« quelque-chose comme... » : ce n'est qu'un exemple donnant l'idée générale . --Lgd (d) 6 janvier 2012 à 22:09 (CET)

Si on en est au point de faire {{Refs|...}}, au moins plus de problème pour "afficher ou non des crochets/parenthèses selon le type d'appel de note" : on met dedans par exemple <span class="lower-alpha"> autour des <ref>, et à la règle CSS actuelle .cite_crochet { display:none } on ajoute .lower-alpha .cite_crochet { display:inline } (et dire que je voulais éviter les détails de faisabilité technique...) -- Oliv0 (d) 6 janvier 2012 à 22:45 (CET)

<Conflit avec Edith /> Outre la remarque majeure plus haut sur la cohérence nécessaire du rendu de tous ces liens, êtes-vous sûr de simplifier les choses pour les contributeurs en compliquant cet éventuel modèle et en le rendant nécessaire dans le cas d'un seul appel et non plus d'une série : {{Refs|alpha|<ref group=alpha>...</ref>}} au lieu du <ref group=alpha>...</ref> actuel ? Je vous rappelle que les questions de complexité croissante de la syntaxe sont assez sensibles et que cela risque fort d'être très dissuasif. Je ne suis même pas certain que l'éventuel {{Refs|<ref>...</ref>|<ref>...</ref>|<ref>...</ref>}} pour masquer les crochets intérieurs ait une chance d'être accepté, à vrai dire (ce masquage n'étant pas lui non plus une bonne idée du point de vue ergo, ce n'est pas forcément un souci, cela dit ). --Lgd (d) 6 janvier 2012 à 23:11 (CET)

Pas plutôt simplement {{Refs|alpha|...|...}} au lieu du <ref group=alpha>...</ref> <ref group=alpha>...</ref> actuel ? -- Oliv0 (d) 7 janvier 2012 à 08:26 (CET)

Mais finalement, d'où est venu cette idée de fusionner ainsi dans les crochets ? Cela ne semble présenter que des désavantages, d'abord en ne facilitant plus le clic (cf. argumentaire de Lgd ci-dessus), ensuite en étant techniquement complexe, et enfin c'est une solution jamais vue de mémoire d'homme (du moins, pour moi) ! En bref, vous semble-t-il possible ou souhaitable de simplifier le vote en écartant cette proposition ? Binabik (d) 6 janvier 2012 à 22:59 (CET)

Pas faux… Dans ce cas, les questions 2 et 3 sont purement et simplement inutiles… --Pic-Sou 6 janvier 2012 à 23:19 (CET)

… ou pourraient être remplacées par : au cas on on décide de garder les appels de notes actuels (sans parenthèses ni crochets), que faire en cas de confusion possible avec les exposants ? donner la possibilité d'appels de notes du groupe entre parenthèses, ou entre crochets, ou aucune possibilité comme actuellement. -- Oliv0 (d) 7 janvier 2012 à 13:54 (CET)

Pourquoi pas, mais ça ferait un peu bizarre d’avoir par endroit des ¹ et dans l’autre des ^[2]… --Pic-Sou 7 janvier 2012 à 23:23 (CET)

Pas possible puisque c'est une possibilité pour le groupe: si c'est ¹ ce sera forcément ², mais ça pourrait être par ailleurs ^(a) et ^(b), ou ⁽ⁿ¹⁾ et ⁽ⁿ²⁾ (un truc à mettre avant le premier appel au groupe ? par exemple en début d'article - mais comme je disais : d'abord décider quoi faire, ensuite décider comment). -- Oliv0 (d) 7 janvier 2012 à 23:48 (CET)

Donc en gros, interdire le groupe decimal après un exposant ? Mais comment veux-tu sourcer correctement ce passage, si tu n’as droit qu’aux notes ? --Pic-Sou 8 janvier 2012 à 09:31 (CET)

Non je voulais dire qu'on aurait le choix ^{1 2} ou ^{(1) (2)} sans variation d'un endroit à l'autre ¹ puis ⁽²⁾ parmi les notes du même groupe de références, mais si tu veux dire variation d'un article à l'autre, effectivement seuls les articles avec exposants auraient des notes ^{(1) (2)} (comme semble le recommander le Lexique des règles typographiques). -- Oliv0 (d) 8 janvier 2012 à 10:58 (CET)

Autrement-dit, selon les articles, l'internaute sera face à des appels de notes et références qui seront dans l'un ^{1 2}, dans l'autre ^{(1) (2)} ? Boutade : tant qu'à créer de la confusion dans l'interface, autant proposer carrément dans la PDD la possibilité d'avoir selon les articles au choix ^{1 2}, ^{(1) (2)} ou ^{[1] [2]} .

Deux objections majeures :

1. Les contributeurs utiliseront de toute évidence ces possibilités de variation à leur sauce, avec des résultats imprévisibles compte-tenu de leur inventivité (souvent involontaire) ;
2. Du point de vue ergonomique, est-ce vraiment une amélioration ? Je le rappelle : on ne parle pas d'un document imprimé, mais d'une interface Web, dont les contraintes et les problématiques de qualité sont différentes.

J'insiste encore une fois sur le souci majeur de ne pas compromettre (mais d'améliorer au contraire) la lisibilité de l'interface pour les lecteurs, sur le risque d'effets de bords imprévus avec la multiplication des options offertes aux contributeurs, et enfin sur le souci également majeur de ne pas complexifier les choses pour les contributeurs à un moment où l'édition des articles est jugée déjà trop difficile. Sans compter les risques de confusion des votants au moment de la décision avec des options plutôt déroutantes sur lesquelles se prononcer.

Je vous recommande vraiment de faire au plus simple : une seule question, portant uniquement sur l'affichage par défaut de crochets ou de parenthèses autour de chaque lien d'appel de note/ref, quel que soit le type de lien (ref simple, ref group, ref alpha ou greek, refs successives).

D'autres options, si vous y tenez vraiment, pourront le cas échéant être envisagées plus tard, si cette étape plus importante est déjà franchie. --Lgd (d) 8 janvier 2012 à 11:52 (CET)

Bâbord, toutes !
Je ne peux que plussoyer ce que vient de dire Lgd. Pas besoin de chercher de midi à quatorze heures, pour complexifier une question qui était à la base simple… Maintenant qu’on a éliminé la proposition des refs fusionnées, la seule question qui reste est : rien, corchets ou parenthèses ? Cordialement --Pic-Sou 8 janvier 2012 à 13:02 (CET)

Taille des renvois

Question du comte Ɲemoi – Qu’en est-il de la taille des renvois ? il sont actuellement en 0.8em, les propositions suppriment ce changement de taille sans étudier la question. Il serait en effet facile de modifier la taille de la solution actuelle, s’il n’y a que cela qui gène  ; et à l’inverse, il me semble que la taille actuelle règle déjà une partie non-négligeable des confusions possibles… Ce 9 janvier 2012 à 03:13 (CET).

C'était une question de version de la proposition. --Lgd (d) 9 janvier 2012 à 09:34 (CET)

Je crois qu'il n'est pas proposé de toucher à class="reference" dans MediaWiki:Cite reference link, donc le CSS pour .reference dans MediaWiki:Common.css fonctionnerait toujours (interlignage et taille). -- Oliv0 (d) 9 janvier 2012 à 10:24 (CET)

Remarque du comte Ɲemoi – Mettez-vous d’accord ! Les références sont toujours en 1em dans les propositions, contre 0.8em dans le rendu actuel. Il faudrait donc choisir entre dire « on ne touche pas à la taille » et « on y touche car c’est mieux ». Je serais pour ma part prêt à dire que ce « marquage de taille » n’étant plus nécessaire, grâce aux parenthèses et/ou crochets, il est normal qu’il disparaisse (qui plus est, le « alpha » rend très moche chez moi en 0.8em) ; mais il faudrait que l’on soit d’accord à ce sujet. Ce 9 janvier 2012 à 17:56 (CET).

+1 Nemoi. Par ailleurs, le but des crochets/parenthèses étant avant tout de faciliter le cliq, autant que les refs soient en plus grandes ! --Pic-Sou 9 janvier 2012 à 19:11 (CET)

Les mêmes styles de taille, de position relative et d'alignement vertical sont à présents appliqués à la proposition et aux refs actuels. --Lgd (d) 9 janvier 2012 à 20:35 (CET)

Pour comparer : ce soir la proposition est^{[1],[note 2],[a],[α]} alors qu'actuellement l'appel de notes avec règle .cite_crochet { display:inline } est ; voici l'un juxtaposé à l'autre : ^[1],[2] -- Oliv0 (d) 9 janvier 2012 à 20:48 (CET)

Je ne vois pas de différence… --Pic-Sou 10 janvier 2012 à 09:23 (CET)

C'est normal, il n'y en a pas (c'est fait pour). --Lgd (d) 10 janvier 2012 à 09:49 (CET)

Depuis hier soir, mais hier matin il y avait une légère différence remarquée par Nemoi, pour comprendre voilà respectivement avec et sans le style pour .reference (codé ici par style=) : a^[α]a^[α] - le premier est en position imposée pour ne pas agrandir l'interligne (je le vois plus haut mais en plus gros il pourrait être plus bas), a ses caractères en taille 0,8 em au lieu de 1 em (je le vois plus resserré), et laisse 1 pixel à gauche (entre le texte et sa note). La même chose sans crochets avec le texte "a au carré" : a^2αa^2α montre que le but de ce style est aussi de faire une certaine différence avec les exposants du texte. -- Oliv0 (d) 10 janvier 2012 à 10:23 (CET)

<Maudite Edith /> Oui, je sais, c'est pour cela que j'ai fait hier la modification dans la page de la proposition, pour que les tailles et le reste soient identiques : il faut absolument évacuer ce genre de choses.

Comme je l'ai dit à Pic-sou ailleurs, l'idéal serait de mettre en place temporairement dans Common.css des classes permettant de mettre des « vraies ref » dans la proposition et non des simulations, pour éviter tout souci de ce genre et tout autre souci lié à des paramètres imprévus chez les votants. Pour la proposition « crochet », c'est très facile. Ce qui me freine, c'est que c'est beaucoup moins évident pour la proposition « parenthèses ». Si quelqu'un a une idée ? --Lgd (d) 10 janvier 2012 à 10:36 (CET)

Perte de la possibilité de choisir

Remarque du comte Ɲemoi – Les deux propositions nouvelles rendent de fait caduque le modèle {{,}} (voir aussi ci-dessous) ; or, celui-ci avait l’avantage de permettre à chacun de régler l’affichage comme il le souhaitait à condition de disposer d’un navigateur normal, puisque s’il est facile de passer de l’affichage actuel à l’un de ceux proposé (par l’ajout de codes CSS comme :

a[href^="#cite_note"]::before { content:"(" }
a[href^="#cite_note"]::after { content:")" }
.cite_virgule { display:none; }

), les nouvelles solutions empêchent toute configuration. (Lien connexe pour ceux qui savent décrypter mes délires de 5 h du mat’ : Virgule [contenu généré des références].) C’était une remarque, en passant, ce 9 janvier 2012 à 03:13 (CET).

C'était une question de version de la proposition. --Lgd (d) 9 janvier 2012 à 09:34 (CET)

Suppression du modèle {{,}} (58 000⁺ articles)

Question du comte Ɲemoi – Le modèle {{,}} se retrouve de fait caduque dans les nouveaux affichages proposés. Que va-t-il advenir de lui ? Va-t-il notamment y avoir un passage de robot sur les 58 000 et de poussières pages l’utilisant ? Ce 9 janvier 2012 à 03:13 (CET).

C'était une question de version de la proposition. --Lgd (d) 9 janvier 2012 à 09:34 (CET)

S'il fallait ne plus afficher la virgule entre notes, plutôt que le robot il y aurait la règle pour .cite_virgule dans MediaWiki:Common.css -- Oliv0 (d) 9 janvier 2012 à 09:39 (CET)

Réponse du comte Ɲemoi – Les propositions actuelles règlent le problème. Pour Oliv0 : ma question portait effectivement (entre autres) sur le fait d’avoir un modèle présent dans le code qui n’affiche absolument rien dans l’article. Ce 9 janvier 2012 à 18:04 (CET).

Rendus des groupes non chiffrés : latins^(a)(b)(c), grecs^(α)(β)(γ), nommés^{(note 1)(note 2)(note 3)}

Question du comte Ɲemoi – Ont récemment été ajoutés par Litlok la possibilité de faire apparaître des notes « alphabétiques », vraisemblablement pour le moment peu utilisés ; les groupes nommés sont en revanches très anciens et clairement très utilisés. Est-il bien question de les mettre entre (parenthèses|crochets), malgré le rendu absolument moche que cela produit ?

Question posée ce 9 janvier 2012 à 03:13 (CET).

C'était une question de version de la proposition. --Lgd (d) 9 janvier 2012 à 09:34 (CET)

Réponse du comte Ɲemoi – D’avoir introduit les diverses notations sur la page de vote règle effectivement la question ; ce 9 janvier 2012 à 17:59 (CET).

Effectivement le Lexique des règles typographiques cité plus haut ne mentionne les parenthèses qu'avec les chiffres. -- Oliv0 (d) 9 janvier 2012 à 11:18 (CET)

Perso je ne trouve pas le rendu si dégueulasse, et oui, il est bien question de produire l’affichage que tu dos. Et de faire de la pub pour les références alphabétiques et grecques ! --Pic-Sou 9 janvier 2012 à 19:13 (CET)

Formuler plus clairement la proposition

Je n'ai pas le temps de le faire moi-même, mais je pense qu'il faut reformuler plus clairement et plus complètement la proposition, avec les éléments suivants :

• la modification réside uniquement dans l'affichage de crochets ou de parenthèses, sans aucun autre changement par rapport à l'existant (virgule, etc.)
• elle est accompagnée de la possibilité de désactiver l'affichage des crochets et parenthèses via un gadget à cocher dans les préférences de compte
• elle s'applique indifféremment à tous les types d'appel de références et de notes, qu'ils soient numériques, avec groupe, alphanumériques ou grecs.

--Lgd (d) 9 janvier 2012 à 09:41 (CET)

(Reformulé plus tard) Le réglage individuel, c'est la même logique qui a mené à la situation actuelle sans crochets autour des appels de notes (cf. l'historique plus haut section Proposition) : quand l'extension <ref> est arrivée, on a commencé par mettre des crochets pour avoir plus d'espace pour cliquer sur les appels de notes, comme avaient fait les anglophones, puis un admin les a fait disparaître en disant que c'est mieux en français et que ceux qui les voulaient pouvaient toujours les faire réapparaître par réglage individuel avec une règle CSS pour la classe cite_crochet. Ainsi, dans cette logique où chacun fait ses propres réglages sur son compte pour mettre les crochets ou pas, la proposition de mettre le comportement par défaut avec ou sans crochets ne sert à rien. Pour que la proposition ait un sens, il faut être dans la logique inverse où on ne s'occupe que de ce qui apparaît sans aucun réglage, comme pour les lecteurs non connectés (d'ailleurs bien plus nombreux probablement). -- Oliv0 (d) 9 janvier 2012 à 11:10 (CET)

Pas compris, désolé. Les lecteurs non connectés n'ont accès à aucune forme de paramètrage, ni par les préférences ni par un common.css personnel. S'il est estimé via cette PDD que la solution crochets/parenthèses est la meilleure, ils auront ce rendu sans aucun choix. Si l'absence de crochets/parenthèses est jugée préférable, il auront de même ce rendu sans aucun choix.

La possibilité de réactiver/désactiver individuellement les crochets/parenthèses via les préférences du compte est là uniquement pour que les votants sachent qu'ils pourront dans tous les cas conserver le rendu qu'ils préfèrent personnellement. A ce propos : contrairement à ce qu'il me semblait, l'option actuelle de réaffichage des crochets n'est pas un gadget mais nécessite un ajout de code dans un common.css personnel, ce qui est loin d'être user-friendly. La création du gadget permettant de cocher une simple case dans les préférences sera un progrès. --Lgd (d) 9 janvier 2012 à 11:20 (CET)

On peut faire des gadgets CSS ? --Pic-Sou 10 janvier 2012 à 09:24 (CET)

Tu veux dire appliquer une CSS uniquement via l'activation d'un gadget dans les préférences ? Oui. Voir par exemple les gadgets « CoinsArrondis », « EbauchesOff », « Referencederoulante » etc. Un gadget est une combinaison fichier.js et fichier.css : si tu ne crées que fichier.css, tu obtiens un gadget qui applique juste une CSS, sans que le javascript ne joue aucun rôle. Merci d'avoir posé la question : je comprends mieux pourquoi ces discussions sont aussi confuses

Dans le même esprit que mon intervention plus haut sur la nécessité de créer des styles temporaires pour que les exemples de rendu proposés utilisent le code réel d'une ref, il faudra aussi créer le gadget pour que les votants puissent voter en l'ayant essayé : il vaut mieux AMHA faire voter sur des résultats constatables par tout le monde immédiatement dans son navigateur, pas sur des considérations ou des possibilités techniques.--Lgd (d) 10 janvier 2012 à 09:45 (CET)

En marge, je pense qu'il faudrait une introduction avançant les quelques enjeux et les quelques arguments pour/contre, de manière à centrer la question sur son énoncé et les modalités. Je fais une suggestion ci-dessous pour la question crochet/parenthèse/rien (il faudra rajouter des précisions si des gadgets sont proposés pour tester). Binabik (d) 10 janvier 2012 à 11:34 (CET)

Suggestion de formulation

Actuellement, les appels de notes sont affichés au moyen de chiffres en exposant. Par défaut, MediaWiki affiche des crochets^[1],[2]. Une troisième solution possible de notes en exposant sont les parenthèses^(1),(2).

La présente prise de décisions vise à choisir quel affichage serait le plus judicieux pour l'encyclopédie. La motivation initiale est un problème de compréhension qui se pose parfois avec le système actuel quand les notes en exposant suivent des chiffres ou des unités. Par exemple, « 13 km² » signifie-t-il treize kilomètres ou treize kilomètres carré ? Les seules solutions de clarification nécessitent en l'état un peu de bricolage (déplacer la note avant ou après par exemple).

Lors des discussions, quelques éléments ont été apportés et sont synthétisés ci-dessous. Ces arguments n'ont rien de définitifs ou d'exhaustifs, le but étant de résumer les échanges.

1. Les chiffres simples ont l'avantage d'être conforme à la typographie traditionnelle en usage à l'Imprimerie nationale (voir analyse) et d'être donc en usage dans l'édition papier en général. Ils ont le désavantage d'être parfois ambigus lorsqu'un exposant suit un chiffre ou une unité (ou peut-être d'autres cas).
2. Les crochets permettent premièrement d'éviter l’ambiguïté des chiffres. Ils améliorent ensuite l'accessibilité en permettant plus facilement d'identifier et de cliquer sur les références, puisqu'il s'agit bien de liens hypertextes (voir analyse). Cette solution serait plus harmonieuse avec le reste des projets Wikipedia/Wikimedia. Ils offrent le désavantage de ne pas être cités par le lexique de l'Imprimerie nationale, et d'être peu (pas ?) en usage dans l'édition papier traditionnelle.
3. Les parenthèses permettent également de lever l'ambiguïté des chiffres et de faciliter le clic sur les références, comme les crochets. Elles sont également citées dans le lexique de l'Imprimerie nationale (voir). Elles lèvent enfin toute ambiguïté pour le lecteur avec les liens du type ^{[réf. nécessaire]}.

Question

Quel affichage doit être utilisé par défaut pour l'ensemble des appels de notes et de références sur l'encyclopédie ?

Modalités

Le vote est un vote à la méthode Black à trois propositions : chaque votant classe les différentes propositions selon ses préférences. Ainsi, « A > B > C » signifie que la méthode A est préférée aux autres par le votant et que la méthode C est la moins appréciée ; le signe égal peut être utilisé pour signifier une égalité (« A > B = C » par exemple). Un vote non conforme pourra être normalisé.

1. Mettre par défaut des crochets autour des appels de notes^{[1],[note 2],[a],[α]}
2. Mettre par défaut des parenthèses autour des appels de notes^{(1),(note 2),(a),(α)}
3. Conserver les appels de notes sans caractères séparateurs (statu quo)

En cas d'adoption des crochets ou parenthèses :

• L'application de cette décision requerra une simple modification de MediaWiki:Common.css pour modifier l'apparence, et de MediaWiki:Cite reference link si les parenthèses remplacent les crochets.
• Les crochets ou parenthèses seront désactivables dans les préférences personnelles pour les utilisateurs enregistrés (gadget MasquerCrochets dans la section « Gadgets généraux », qui peut être testé dès aujourd'hui sur les exemples de la proposition).

Merci pour cette proposition  ; j'ai enlevé la mention de MediaWiki:Cite reference link qui n'est pas concernée, ainsi que celle de {{,}} puisqu'on l'a enfin évacué il me semble (aucun changement dans son usage). Je vais m'occuper du gadget si cette proposition de formulation convient globalement. --Lgd (d) 10 janvier 2012 à 11:53 (CET)

Il ne faut en effet pas hésiter à modifier ce brouillon . Binabik (d) 10 janvier 2012 à 12:08 (CET)

Je l'avais compris comme ça . Je viens également d'ajouter quelque-chose à propos des ^{[réf. nécessaire]}, peut-être pas évident pour le wikipédien, mais à l'usage constaté pas si simples pour le lecteur. Enlevez si cela vous semble trop inattendu pour les wikipédiens expérimentés qui vont être les seuls à se prononcer sur cette PDD . --Lgd (d) 10 janvier 2012 à 12:17 (CET)

Ce n'est pas que le logiciel Mediawiki est conçu pour les crochets, il est conçu pour mettre n'importe quel format d'appel de notes présent dans le fichier MediaWiki:Cite reference link qui actuellement a des crochets mais rendus invisibles par CSS, et ce fichier pourra être changé si on remplace crochets par parenthèses. La règle CSS est dans MediaWiki:Common.css, c'est là qu'on pourra rendre visible par défaut crochets ou parenthèses. -- Oliv0 (d) 10 janvier 2012 à 12:57 (CET)

On ne va pas recommencer à faire du sur-place, pitié . L'extension cite ainsi que d'autres extensions ou scripts associés à mediawiki, à la suite de mediawiki elle-même, utilisent nativement les crochets pour signaler différents types de liens à rôle particulier (refs, modifier, dérouler...). C'est, en ce sens, effectivement quelque-chose qui est présent nativement dans l'univers mediawiki. Il n'y a rien à redire à la formulation actuelle, suffisamment parlante pour les contributeurs. --Lgd (d) 10 janvier 2012 à 13:14 (CET)

Puisqu'on ne doit pas hésiter à modifier, pas de sur-place : je raccourcis cette phrase en mettant aussi les mêmes virgules entre notes que dans "Modalités" (d'ailleurs au pluriel non?), et je complète ce que requerrait la décision pour les parenthèses. -- Oliv0 (d) 10 janvier 2012 à 18:53 (CET)

Il faut juste que l’on dise ce que deviendra le modèle {{,}}… Bravo pour cette proposition ! --Pic-Sou 10 janvier 2012 à 19:34 (CET)

Merci d'avoir rectifié mon erreur pour MediaWiki:Cite reference link , j'avais oublié les parenthèses en effet.

Le gadget est en place : MasquerCrochets dans la section « Gadgets généraux », onglet « gadget » des Préférences. Son fonctionnement peut être testé sur les exemples de la proposition. Peut-être faut-il mieux le mettre en évidence dans la proposition (il fait partie du deal si j'ose dire).

Le modèle {{,}} : aucun changement en ce qui le concerne. --Lgd (d) 10 janvier 2012 à 19:42 (CET)

Comment ça aucun changement ? Si on met les crochets par défaut, on a plus besoin du modèle {{,}} ! Ou alors j’ai raté un épisode… --Pic-Sou 10 janvier 2012 à 20:50 (CET)

J'avais compris qu'on conservait les virgules (ce qui permet de n'avoir aucun changement pour ceux qui préfèrent la version sans crochets/parenthèses via le gadget) ? --Lgd (d) 10 janvier 2012 à 21:57 (CET)

Oui, mais c’est idiot : pour l’user standard, le modèle {{,}} ne changera rien. Il ne verra donc pas pourquoi l’insérer, et ne l’insérera évidemment pas ! --Pic-Sou 10 janvier 2012 à 22:27 (CET)

Mais il le verra. Les virgules restent présentes et affichées avec les crochets/parenthèses, tel le montre la proposition. Bref, on ne change rien aux virgules. Ou sinon, quelle est l'idée ? --Lgd (d) 10 janvier 2012 à 22:30 (CET)

C'est-à-dire donner plutôt le choix entre 1. crochets sans virgules, 2. parenthèses sans virgules, et 3. situation présente sans crochets mais avec virgules entre deux ? (avec toujours la possibilité de revenir individuellement à la situation présente par gadget ou CSS) Les virgules ne me gênent pas (ça va dans le même sens que les crochets : séparer les notes), mais on pourrait effectivement préciser qu'on peut avoir les crochets/parenthèses sans virgules par gadget ou CSS (en utilisant la règle CSS pour .cite_virgule). -- Oliv0 (d) 11 janvier 2012 à 10:17 (CET)

Je ne comprends pas l’intérêt de garder les virgules si on met les crochets ou les parenthèses… --Pic-Sou 11 janvier 2012 à 16:07 (CET)

L'intérêt est:

• de ne pas avoir à gérer le problème du retour des virgules pour les utilisateurs qui vont masquer les crochets/parenthèses (pas simple)
• de ne pas aboutir à des liens immédiatement adjacents

Si des utilisateurs souhaitent masquer la virgule, pour le coup, il me semblent qu'ils peuvent se contenter d'un style mis à la main dans leur common.css. Ce n'est pas comme l'affichage des crochets qui peut être carrément bloquant vu les retours évoquant les règles typographiques.

--Lgd (d) 11 janvier 2012 à 16:17 (CET)

Pour tenter de résumer, il y a deux solutions par défaut si crochets/parenthèses sont retenu(e)s : soit on garde les virgules et la possibilité de repasser à l'état actuel (gadget de Lgd), soit on ne garde pas les virgules, mais pas non plus la possibilité du gadget. Cela peut aussi faire l'objet d'une seconde question, puisque a priori, les deux aspects ne sont pas forcément interdépendants. Binabik (d) 11 janvier 2012 à 16:53 (CET)

Oui. Je cherche s'il y moyen d'avoir le beurre et l'argent du beurre, mais ça me semble mal parti... --Lgd (d) 11 janvier 2012 à 18:37 (CET)

On pourrait aussi simplement ajouter dans le common.css .cite_virgule {display: none;}, non ? --Pic-Sou 11 janvier 2012 à 19:42 (CET)

Demander aux gens de continuer à utiliser un modèle dont le rendu est totalement invisible, je ne pense pas que ce soit très réaliste ? Même si l'idée de lancer le culte de la virgule rose invisible me plairait beaucoup --Lgd (d) 11 janvier 2012 à 19:45 (CET)

Grumble ! Quel con ! Donc y’a pas de solution ? --Pic-Sou 11 janvier 2012 à 20:05 (CET)

Bon, après vérification, je ne vois aucun moyen d'obtenir via CSS l'affichage des virgules en cas d'utilisation du gadget dans l'hypothèse où le modèle {{,}} serait supprimé (générer les virgules en CSS est facile, le souci est de ne pas générer de virgule après la dernière référence d'une série, les séries n'étant pas balisées en tant que telles). Le recours à javascript me semble exclu par souci de performances. Conserver les virgules sans aucun changement me semble la bonne solution, d'autant que cela évite également de générer des liens immédiatement adjacents, ce qui n'est pas recommandé ergonomiquement. Mais on peut laisser la PDD trancher comme le suggère Binabik, comme vous voulez. --Lgd (d) 12 janvier 2012 à 11:49 (CET)

 Plutôt contre tant pis, pas besoin d’alourdir encore la PDD, on ajoutera au pire l’option de virer les virgules. --Pic-Sou 12 janvier 2012 à 18:36 (CET)

(retour à gauche) Une suggestion déjà mentionnée : option D. Conserver les appels de notes sans crochets/parenthèses autour, mais donner la possibilité de crochets/parenthèses pour un groupe de notes qui en aurait besoin, comme par exemple les notes d'un tableau. (Parce qu'à nouveau je me retrouve à préparer un tableau où ce serait plus clair avec les notes entre parenthèses, mais je ne veux pas forcément des parenthèses à toutes les références de tout le monde.) Ceci étant conforme aux règles typographiques : parenthèses si nécessaire seulement. L'objection mentionnée plus haut était que ça nuit à l'homogénéité de l'encyclopédie en laissant le champ libre au jugement arbitraire et éventuellement erroné du rédacteur : mais est-ce gênant qu'il puisse y avoir un groupe de notes ^(a) au lieu de ^a, quand de toutes façons il peut déjà y avoir ¹ ou ^n 1 ou ^Réf 1 etc. et maintenant aussi ^a ou ^α ? -- Oliv0 (d) 13 janvier 2012 à 13:55 (CET)

Je pense que l'important reste d'utiliser les groupes avec pertinence et une certaine logique (ne pas alterner les systèmes si cette logique n'est pas évidente ; par exemple, ^{note 1} pour une note se comprend, ^Réf 1 ne semble pas très explicite au contraire). Je suis neutre quant à poser une telle question, mais pour moi, il s'agit d'un problème différent : d'une part il s'agit de l'affichage par défaut pour tous et pour tout, d'autres part il s'agit d'une fonctionnalité d'affichage locale offerte aux contributeurs. Donc une seconde question plutôt qu'une option D à mon avis. Binabik (d) 13 janvier 2012 à 15:50 (CET)

L'existence de la fonctionnalité (dans l'écriture de la page, du genre un paramètre de modèle parenth=oui ou un modèle appelé avant {{parenth}} etc.) influe sur le choix de vote : si je suis partisan des parenthèses dans certains cas mais que je trouve excessif de les imposer partout, je choisirai "défaut sans parenthèses" si on me dit qu'on veut donner la possibilité de parenthèses par groupe de notes, et "défaut avec parenthèses" si on ne me le dit pas. -- Oliv0 (d) 13 janvier 2012 à 16:31 (CET)

Effectivement, il peut y avoir une influence directe... Je reste de toute façon assez neutre sur le fond . Binabik (d) 13 janvier 2012 à 16:51 (CET)

Quelle que soit l'influence que cela peut avoir sur ton vote, Oliv0, cela me semble trop spécifique et personnel. Quand tu expliques que « je me retrouve à préparer un tableau où ce serait plus clair avec les notes entre parenthèses, mais je ne veux pas forcément des parenthèses à toutes les références de tout le monde. », il me semble que cela illustre le fait qu'il s'agit d'une situation triplement bien particulière :

• présence de notes dans un tableau ;
• préférence personnelle pour des notes entre parenthèses dans ce cas ;
• préférence personnelle pour l'absence de crochets/parenthèses en règle générale.

Je ne dis pas que la question ne se pose pas et qu'il ne faudra pas voir comment y répondre. Mais AMHA pas dans un premier temps. Il y a déjà une seule question de portée beaucoup plus large à trancher : indépendamment d'éventuelles exceptions à traiter ensuite au cas par cas, décide-t-on ou non de revenir au rendu par défaut dans les Wikipédia en réaffichant systématiquement les crochets, ou bien d'y revenir avec la variante des parenthèses, ou bien de conserver la situation actuelle ?

Selon la réponse qui sera donnée à cette question, les exceptions éventuelles à envisager dans un deuxième temps ne relèvent pas des mêmes problèmes (au moins techniques). Il me semble donc préférable de procéder pas à pas, en s'en tenant à cette seule question dans le cadre de la présente PDD.

A ce stade, d'autres avis seraient sans doute profitables pour décider si la PDD doit ou non proposer déjà un système d'exceptions à la configuration par défaut avec/sans crochets/parenthèses, ou bien si ces exceptions seront à aborder plus tard, une fois que l'on saura quelle est la configuration retenue.

--Lgd (d) 14 janvier 2012 à 12:16 (CET)

Contre les exceptions --Pic-Sou 14 janvier 2012 à 12:18 (CET)

Pourquoi pas ^{[1, 2, 3]} ?

Tout d'abord merci pour les suggestions et désolé d'arriver si tard dans la discussion, mais je ne comprends pas pourquoi on a pas de proposition avec^{[1, 2, 3]} qui reste quand même ce qui se fait de plus proche de l'usage dans les publications scientifiques. Je suis d'accord le papier et le web c'est pas pareil, mais je pense que cela devrait être inclus dans les propostions de la PDD. Cordialement. PierreSelim ^{[let discussion = fun _ ->]} 16 janvier 2012 à 10:09 (CET)

Je me suis permis de créer une sous-section, pour faciliter la lecture. Je vais revenir sur les questions de faisabilité. Cordialement, --Lgd (d) 16 janvier 2012 à 10:25 (CET)

Pas de soucis ^^. PierreSelim ^{[let discussion = fun _ ->]} 16 janvier 2012 à 11:48 (CET)

Réponse du comte Ɲemoi – Vois un peu ce qui est cliquable dans ^{[1, 2, 3]} : c’est en fait probablement ^{[1, 2, 3]} auquel tu penses… Dit autrement, la facilité à cliquer ne serait augmentée que parce qu’on peut supprimer la différence de taille de fonte. Je n’ai pas vérifié la faisabilité de la chose, qui plus est ; et ça ne me semble pas évident du tout que ça le soit. Sympathiquement, ce 16 janvier 2012 à 19:10 (CET).

J’amais bien cette proposition, mais elle est très compliquée à mettre en œuvre… cela a conduit à l’abandonner --Pic-Sou 16 janvier 2012 à 19:29 (CET)

Quand on parle de rendu, la difficulté de mise en œuvre ne doit pas être le principal soucis. PierreSelim ^{[let discussion = fun _ ->]} 16 janvier 2012 à 21:25 (CET)

Réponse du comte Ɲemoi – Ben, si la seule solution consiste à faire tourner un javascript qui ralentisse donc l’affichage sur tous les terminaux — et notamment les téléphones portables —, ça me semble une difficulté bien suffisante pour l’abandonner sans autre discussion. On en parle demain si tu veux. Amicalement, ce 16 janvier 2012 à 21:30 (CET).

Petit aparté concernant « l'usage dans les publications scientifiques », il existe tellement de variantes selon les domaines/langues/revues/éditeurs que cela me semble difficile de généraliser. Binabik (d) 16 janvier 2012 à 22:38 (CET)

Oui en effet, je ne sais simplement pas ce qui se fait dans d'autres domaines. Cela pourrait être intéressant de regarder. Après personnellement, j'ai toujours utilisé quelque chose comme [Auteur1 01, Auteur2 03, Auteur2 04a, Auteur2 04b] dans mes publications si cela ne m'était pas imposé. Enfin les remarques de Nemoi (d · c · b) me paraissent convaincantes (même si je suis déçu pour le coup). --PierreSelim ^{[let discussion = fun _ ->]} 17 janvier 2012 à 10:04 (CET)

Une nouvelle fois, je recommande de s'en tenir dans un premier temps à la seule question principale (sans laquelle ce genre de questions de rendu ne se pose pas). En fonction du résultat de celle-ci, il sera toujours possible d'envisager d'aller plus loin par la suite dans une autre évolution ou PDD. --Lgd (d) 18 janvier 2012 à 20:00 (CET)

Donc en gros (sans position ni espacement précis) on peut comprendre le choix comme : A. ^{[1], [2]} et peut-être plus tard ^{[1, 2]}, B. ^{(1), (2)} et peut-être plus tard ^{(1, 2)}, C. ¹ et peut-être plus tard ⁽¹⁾ ou ^[1] pour un groupe d'appel de notes qui en aurait besoin. -- Oliv0 (d) 18 janvier 2012 à 20:55 (CET)

Oui. --Pic-Sou 18 janvier 2012 à 21:11 (CET)

Réponse du comte Ɲemoi – Sauf que jusqu’à preuve du contraire, la solution^{[1, 2, 3]} et celle^{(1, 2, 3)} ne sont pas faisables (avec le html généré par Mediawiki et du CSS). Ce 18 janvier 2012 à 23:06 (CET).

Ou aussi {{,}} peut être remplacé par un modèle multi-notes du genre {{Refs|group=n|note 1|note 2|...}} (pas tellement plus difficile que <ref group=n>note 1</ref>{{,}}<ref group=n>note 2</ref>). -- Oliv0 (d) 18 janvier 2012 à 23:29 (CET)

Il me semble que la question a été abondamment discutée (indépendamment des questions de faisabilité) ? --Lgd (d) 18 janvier 2012 à 23:58 (CET)

Oui je disais ça juste pour Nemoi et ceux qui auraient zappé les objections plus haut très à droite (complexité, et comme rappelé par Nemoi : ne facilite pas le clic). -- Oliv0 (d) 19 janvier 2012 à 07:41 (CET)

Ordre des choix et autres détails

Je viens de regarder le projet de question et il y a un détail à corriger pour éviter les confusions :

• dans la présentation on parle de : 1 chiffres simples, 2 crochets, 3 parenthèses ;
• dans la question, c'est : A crochets, B parenthèses, C chiffres simples.

Il faudrait que les trois options soient présentées dans le même ordre pour simplifier la lecture et éviter les confusions.

Par ailleurs, est-ce que « chiffre simple » utilisé dans la présentation est la bonne désignation puisqu'il peut aussi s'agir de lettres latines ou grecques ou encore de la composition d'un texte et d'un chiffre ? De plus je pense qu'il faudrait peut-être mieux mettre en évidence dans la présentation que les appels à note ne sont pas nécessairement des chiffres.

O.Taris (d) 19 janvier 2012 à 21:01 (CET)

J'ai appliqué ces suggestions. Pour « chiffre simple », j'ai remplacé par « caractères simples » pour être plus précis. Cela convient ? Les exemples sont de toutes façons assez explicites je suppose. Binabik (d) 19 janvier 2012 à 22:16 (CET)

Ça me convient, merci. O.Taris (d) 19 janvier 2012 à 22:42 (CET)

Lancement du vote

Ça vous dit si on lance le vote après-demain ? On se laisse une journée pour voir s’il y a des remarques particulières, et si non, on passe à l’action ?

Cordialement --Pic-Sou 18 janvier 2012 à 20:35 (CET)

Après demain c'est trop tôt, il faut un délai minimum de 48h entre la publication de l'annonce et l'ouverture du vote, voir Aide:Prise de décision#L'ouverture du vote. Udufruduhu (d) 18 janvier 2012 à 20:41 (CET)

En outre, il faudra au minimum mettre à jour la proposition . --Lgd (d) 18 janvier 2012 à 20:45 (CET)

Alors… lundi ? --Pic-Sou 18 janvier 2012 à 20:47 (CET)

Je viens de mettre la proposition à jour (selon le brouillon retravaillé ci-dessus). Si on fait l'annonce ce soir, il faut en effet laisser un peu de temps en cas d'objections imprévues. Lundi me convient. Binabik (d) 19 janvier 2012 à 20:06 (CET)

All right --Pic-Sou 19 janvier 2012 à 22:14 (CET)

Il me semble qu'il faut encore se mettre d'accord sur la durée du vote et également préciser les conditions requises pour voter. Je propose de mettre ce qui se fait habituellement :

• durée de 4 semaines
• peut voter tout contributeur inscrit depuis un mois et ayant au minimum 50 contributions dans l'espace principal à la date d'ouverture du vote

Udufruduhu (d) 19 janvier 2012 à 22:36 (CET)

’amva --Pic-Sou 19 janvier 2012 à 22:52 (CET)

J'ai fait l'annonce donc. Binabik (d) 20 janvier 2012 à 10:04 (CET)

Utilisateur pas content

Je n'avais pas suivi cette prise de décision, elle est sur un sujet tellement anecdotique que je m'attendais à y voter « Contre toute décision ».

Je constate que le mode de scrutin choisi ne permet pas cette possibilité : le contenu des pages MediaWiki:Common.css et MediaWiki:Cite reference link sera figé par le résultat du vote, et ce quel que soit ce résultat - certes pour une partie très faible du contenu, mais le principe ne me plaît pas.

Je me borne donc à ronchonner ici et écrire sur cette page le souhait que je ne peux faire valoir sur la page de vote : que, comme pour toutes les pages techniques ou non de Wikipédia, le contenu de ces pages se traite par discussion polie et ouverte sur Discussion MediaWiki:Common.css et Discussion MediaWiki:Cite reference link suivie (puisqu'il s'agit de pages spéciales) d'une demande éventuelle d'intervention d'un administrateur.

Bon après, il n'y a pas mort d'homme, ça reste une question horriblement mineure ; mais je ne comprends absolument pas pourquoi on la traite par la solennité d'une prise de décision plutôt que par le procédé usuel de la discussion localisée en un coin obscur de nos pages. Touriste (d) 23 janvier 2012 à 08:46 (CET)

La modification envisagée étant loin d'être transparente (visuellement), une décision prise par une petite poignée de contributeurs/admins sur des pages de maintenance technique aurait sans doute été fortement critiquée pour son absence d'avis communautaire... Je ne suis pas convaincu que l'avis des contributeurs soit très pertinent dans ce cas, mais c'est une autre question.--Lgd (d) 23 janvier 2012 à 08:58 (CET)

Ouaip, je comprends ça aussi. Bof je joue la drama queen mais je m'en fiche un peu au fond, c'est juste pour rappeler qu'une consultation bien fichue devrait en principe contenir systématiquement, sous une forme ou une autre, l'option « Ne rien décider du tout ». Note que dans cet exemple je pense que ses chances de victoire auraient été très minces, donc je râle surtout pour le plaisir de râler. Touriste (d) 23 janvier 2012 à 09:03 (CET)

Ne rien décider du tout, c’est il me semble la proposition C. Après, +1 Lgd, quand on voit le nombre de C sans raisons alors qu’on a clairement montré que la situation actuelle pose problème et que mettre des crochets ou des parenthèses est une solution envisageable… --Pic-Sou 24 janvier 2012 à 20:35 (CET)

Bof, le contexte, je suis toujours un peu pressé de lire cette partie et je dois généralement me forcer pour lire en entier l’intitulé d’une PDD. Autant dire que lire la discussion… (sauf quand je commence à lire en cours de discussion, comme c’est le cas cette fois-ci).
Ltrl G, le 24 janvier 2012 à 22:25 (CET)

Pic-Sou c'est une pdd requérant un vote pur et simple, pas besoin d'argumenter (la phase des argumentaires est dépassée, et si on vote contre ton "argument" c'est qu'on a nos raisons.--Loreleil ^[d-c] 10 février 2012 à 01:26 (CET)

Je suis bien d’accord que l’argumentation n’est pas obligatoire, mais le problème ici c’est qu’il n’y a pas d’argument en faveur de la C… --Pic-Sou 10 février 2012 à 10:39 (CET)

Tu estimes qu'il n'y a pas d'argument :) 70% actuellement ne sont pas d'accord. Loreleil ^[d-c] 10 février 2012 à 18:03 (CET)

Vas-y, quel est ton argument ? Je suis curieux --Pic-Sou 10 février 2012 à 18:08 (CET)

Ce n'est pas un débat mais un vote ! Crois tu une seconde qu'à l'élection de ton "maire" (ou équivalent) on va te demander des arguments pour justifier ton vote même s'il est incohérent (exemple voter pour un candidat anarchiste dans une élection républicaine ...). Loreleil ^[d-c] 10 février 2012 à 18:13 (CET)

Donc c’est bien ce que je pensais, il n’y a pas d’argument… --" --Pic-Sou 10 février 2012 à 18:31 (CET)

Tu interprètes comme tu veux, mais tu sous entends que 70% des personnes ne réfléchissent pas avant de voter... Loreleil ^[d-c] 10 février 2012 à 18:49 (CET)

Cf. la section suivante. Comme Lgd, ça ne m’étonne pas. --Pic-Sou 10 février 2012 à 18:57 (CET)

Autant fermer wikipedia et supprimer WP:FOI dans ce cas... Loreleil ^[d-c] 10 février 2012 à 19:17 (CET)

Je ne vois pas le rapport… --Pic-Sou 10 février 2012 à 19:31 (CET)

Décompte des votes au 20 février 2012 à 11 h 7

Votes normalisés (174 votes)

1. C > B > A | LPLT (d · c)
2. C > A > B | Udufruduhu (d · c)
3. C > A > B | Bibitono (d · c)
4. C = A > B | Symbolium (d · c)
5. C > B = A | Nemoi (d · c)
6. A > B > C | Padawane (d · c)
7. C > B > A | Sammyday (d · c)
8. A > C > B | Erkethan (d · c)
9. A = B > C | Bloody-libu (d · c)
10. C > A > B | Kertraon (d · c)
11. C > A = B | Gemini1980 (d · c)
12. C > A = B | Fabrice Ferrer (d · c)
13. C > B > A | Hadrianus (d · c)
14. B > A > C | Rigoureux (d · c)
15. A > B > C | Super Poirot (d · c)
16. A > C > B | Skull33 (d · c)
17. C > B > A | Fralambert (d · c)
18. C > A > B | Asram (d · c)
19. A > B > C | Dfeldmann (d · c)
20. C > B > A | Zertrin (d · c)
21. C > B > A | Woozz (d · c)
22. C > B > A | Tella (d · c)
23. C > B > A | Guillaume70 (d · c)
24. A > C > B | Riba (d · c)
25. A > B > C | Supertoff (d · c)
26. A = B > C | Lgd (d · c)
27. C > B > A | Le ciel est par dessus le toit (d · c)
28. C > B > A | Indif (d · c)
29. B > A > C | Cangadoba (d · c)
30. C > B > A | Sardur (d · c)
31. C > B > A | Morburre (d · c)
32. A > B > C | TaraO (d · c)
33. C > B = A | Wikinade (d · c)
34. C > B > A | Oliv0 (d · c)
35. C > A > B | Kyro (d · c)
36. A > B > C | Jules78120 (d · c)
37. C > A = B | Manoillon (d · c)
38. A > C > B | Égoïté (d · c)
39. C > B > A | Ursus (d · c)
40. A > B > C | Arnaudus (d · c)
41. C > A > B | Martin (d · c)
42. A > C > B | Eliane Daphy (d · c)
43. C > A > B | Sisyph (d · c)
44. B > A > C | VonTasha (d · c)
45. B > A > C | Ordifana75 (d · c)
46. C > A > B | Jean-Jacques Georges (d · c)
47. B > C > A | Ghiardini (d · c)
48. C > B > A | TiboF (d · c)
49. B > A > C | Chandres (d · c)
50. C > A > B | Les3corbiers (d · c)
51. A > B > C | Ælfgar (d · c)
52. C > B > A | Remy34 (d · c)
53. B > A > C | Perditax (d · c)
54. C > A > B | Mirgolth (d · c)
55. A > B > C | Indeed (d · c)
56. C > B > A | JÄNNICK Jérémy (d · c)
57. C > B > A | Buisson (d · c)
58. C > B > A | Ayack (d · c)
59. C > B > A | Ludo29 (d · c)
60. A = B > C | VIGNERON (d · c)
61. C > B > A | Mith (d · c)
62. C > A > B | Sebleouf (d · c)
63. A = B > C | Cymbella (d · c)
64. A = B > C | Lebob (d · c)
65. A > B > C | Nouill (d · c)
66. C > B > A | Olyvar (d · c)
67. C > B = A | Gdgourou (d · c)
68. A = B > C | Salix (d · c)
69. A = B > C | Schutz (d · c)
70. C > B = A | Barbetorte (d · c)
71. A = B > C | Gz260 (d · c)
72. B > A > C | Antaya (d · c)
73. B > A = C | Binabik155 (d · c)
74. C = B > A | Harmonia Amanda (d · c)
75. A > C > B | Jean-Christophe BENOIST (d · c)
76. C > B > A | Zetud (d · c)
77. C > B = A | LittleTony87 (d · c)
78. C > B > A | Guil2027 (d · c)
79. C > B > A | GwenofGwened (d · c)
80. A > C > B | Xfigpower (d · c)
81. C > A > B | Pethrus (d · c)
82. C > B = A | Xic667 (d · c)
83. A > B > C | Fantafluflu (d · c)
84. A > C > B | Abaddon1337 (d · c)
85. C > B > A | Kelam (d · c)
86. C > B > A | alcide talon (d · c)
87. A = B > C | Totodu74 (d · c)
88. C > A = B | Rhadamante (d · c)
89. A > B > C | ArséniureDeGallium (d · c)
90. A = B > C | Manuguf (d · c)
91. A = B > C | Père Igor (d · c)
92. A > B > C | Léna (d · c)
93. C > A = B | Amqui (d · c)
94. C > A > B | Racconish (d · c)
95. C > A > B | The Titou (d · c)
96. C > A > B | Defeder (d · c)
97. C > A > B | Edoli (d · c)
98. A > B > C | Pic-Sou (d · c)
99. A > B > C | Ltrlg (d · c)
100. A > B > C | Guillaume42 (d · c)
101. A > C > B | Matrix76 (d · c)
102. C > A > B | Cedalyon (d · c)
103. A > B > C | Esprit Fugace (d · c)
104. C > A > B | Hadrien (d · c)
105. B > A > C | Romano1246 (d · c)
106. A > B > C | Cantons-de-l'Est (d · c)
107. C > B > A | MicroCitron (d · c)
108. A = B > C | le sourcier de la colline (d · c)
109. C > A > B | Zunkir (d · c)
110. C > B > A | Jean Marcotte (d · c)
111. A > B = C | Pramzan (d · c)
112. A > C > B | Hlm Z. (d · c)
113. C > B > A | Christophe Dioux (d · c)
114. C > B > A | Ps2613 (d · c)
115. A > B > C | Vincent.vaquin (d · c)
116. A > B > C | ManiacParisien (d · c)
117. C > A > B | Hatonjan (d · c)
118. C > B > A | Bserin (d · c)
119. A > B > C | Kyah117 (d · c)
120. C > A > B | Adehertogh (d · c)
121. C > B > A | Cbigorgne (d · c)
122. C > A > B | Berdea (d · c)
123. C > A = B | Critias (d · c)
124. B > A > C | Toto Azéro (d · c)
125. B > A > C | Denispir (d · c)
126. C > B > A | O.Taris (d · c)
127. C > B > A | Zandr4 (d · c)
128. C > A = B | Necrid Master (d · c)
129. C > A = B | Teofilo (d · c)
130. C > B > A | Romuald 2 (d · c)
131. C > A = B | JLM (d · c)
132. C > A > B | Kropotkine 113 (d · c)
133. C > A > B | Saveur (d · c)
134. C > A > B | TiboQorl (d · c)
135. A > C > B | Toin out (d · c)
136. C > A > B | Rehtse (d · c)
137. C > B > A | Ickx6 (d · c)
138. C > B > A | HAF 932 (d · c)
139. B > C > A | Chaoborus (d · c)
140. C > B = A | Salsero35 (d · c)
141. C > B = A | Jmex (d · c)
142. B > A > C | Gérard (d · c)
143. C > A > B | Tomaas (d · c)
144. C > A > B | Bibisoul (d · c)
145. C > A = B | Guillaume85260 (d · c)
146. C > A = B | Chollux (d · c)
147. A = C > B | Domaina (d · c)
148. A > B > C | Speculos (d · c)
149. C > B > A | Trizek (d · c)
150. A > B > C | Boris Letcheff (d · c)
151. C > A > B | Superjuju10 (d · c)
152. C > A > B | Bruno2wi (d · c)
153. C > A > B | loreleil (d · c)
154. B > A > C | Cépey (d · c)
155. C > A > B | Koui² (d · c)
156. A > B > C | Adamantane (d · c)
157. C > A = B | Twilight-Brawl (d · c)
158. C > A > B | Aqw96 (d · c)
159. C > A > B | Dark Attsios (d · c)
160. C > B > A | Fabriced28 (d · c)
161. C > B > A | MHM55 (d · c)
162. C > B > A | Archaeodontosaurus (d · c)
163. C > B > A | Lomita (d · c)
164. C > B > A | Linedwell (d · c)
165. B > A = C | Sitanix (d · c)
166. A > C > B | Blackstar (d · c)
167. C > B = A | Pucesurvitaminee (d · c)
168. A > C > B | Pixeltoo (d · c)
169. B > A > C | Jastrow (d · c)
170. A = B > C | Ash_Crow (d · c)
171. A > C > B | Fandecaisses (d · c)
172. C > B > A | Nadin123 (d · c)
173. A > B > C | M0tty (d · c)
174. A > B = C | Ratachwa (d · c)

 

Décompte selon la méthode Condorcet

Options possibles :

• A — Mettre par défaut des crochets autour des appels de notes
• B — Mettre par défaut des parenthèses autour des appels de notes
• C — Conserver les appels de notes sans caractères séparateurs (statu quo)

Duels :

• Duel entre A et B ⇒ A (à 77 contre 63, 34 indifférents)
• Duel entre A et C ⇒ C (à 103 contre 67, 4 indifférents)
• Duel entre B et C ⇒ C (à 116 contre 55, 3 indifférents)

 

Vainqueurs potentiels :

• C — Conserver les appels de notes sans caractères séparateurs (statu quo)

Vous qui êtes humains, n'oubliez pas de prendre en compte les commentaires de vote.

Machinalement — Arkbot ^✉ [mes sources] 28 janvier 2012 à 14:07 (CET) — Mis à jour le 3 février 2012 à 15:40 (CET) — Mis à jour le 8 février 2012 à 12:11 (CET) — Mis à jour le 13 février 2012 à 16:27 (CET) — Mis à jour le 19 février 2012 à 15:38 (CET) — Mis à jour le 20 février 2012 à 11:07 (CET)

Bouah ! Manque 16 votes --Pic-Sou 28 janvier 2012 à 17:46 (CET)

16 votes ? S'agirait-il de votes invisibles ? — Arkanosis ^✉ 29 janvier 2012 à 21:29 (CET)

Manque 16 (maintenant 15) votes A > C pour que les crochets reviennent par défaut ! --Pic-Sou 29 janvier 2012 à 21:33 (CET)

Ah ah Et moi qui cherchais où mon bot avait bien pu se planter dans le décompte — Arkanosis ^✉ 30 janvier 2012 à 10:36 (CET)

Gnihihi je suis méchant ! --Pic-Sou 30 janvier 2012 à 19:14 (CET)

Au fait, quand pour comprendre on regardait le nombre de votes listés par le bot on voyait le même nombre que sur la page de vote, est-ce que ça veut dire qu'ils sont tous bons ou que le bot ne vérifie pas les votes ? (à moins que pour les PDD il n'y ait pas les conditions du genre nombre de contribs, ancienneté, pas IP etc. ?) — Oliv☮ ^{Éppen hozzám?} 30 janvier 2012 à 11:29 (CET)

Je crois que le bot vérifie et normalise les votes. Cordialement --Pic-Sou 30 janvier 2012 à 19:14 (CET)

Arkbot vérifie lors de la normalisation que chaque vote est valide (ie. que les options utilisées sont parmi celles proposées), mais il ne vérifie pas encore :

• qu'il n'y a pas d'usurpation d'identité lors d'un vote ;
• que les votants remplissent bien les « conditions » (ancienneté, nombre de contributions…) pour pouvoir voter.

Ce sont néanmoins des améliorations que j'ai prévu de lui apporter dans le futur. Amicalement — Arkanosis ^✉ 30 janvier 2012 à 19:21 (CET)

Ce sont plutôt les avis en faveur de cette modification qui me surprennent par leur ampleur relative. On pouvait s'attendre à beaucoup, beaucoup, beaucoup moins. C'est encourageant, dans l'absolu. --Lgd (d) 3 février 2012 à 15:48 (CET)

Une remarque à confirmer : plus une PDD durerait, plus les votes conservateurs se renforceraient ? Amusant, ça. Le choix du délai ne serait pas du tout innocent. --Lgd (d) 8 février 2012 à 12:31 (CET)

ça me fait penser qu'à l'occasion d'un référendum national j'avais entendu qq part une théorie expliquant que c'est toujours le vote non qui progresse avec le temps (baisse d'enthousiasme, méfiance accrue devant l'imminence d'un changement...), ce que semble confirmer l'écart considérable des résultats sur Google entre "Progression du non" (16 200 résultats) et "progression du oui" (1 780 résultats). --Amicalement, Salix ( converser) 8 février 2012 à 15:04 (CET)

Oui, un certain mécanisme associe le temps qui coule et le refus instinctif de regarder l'intérêt du changement.

Donc, concrètement, disons que pour faire avancer certaines choses et améliorer les processus de décisions dans WP, il faudrait pousser des PDD d'une semaine au plus ou au pire de 15 jrs ?

C'est effroyablement vrai, mais absolument pas politiquement correct. Mesurer le délai pertinent pour qu'un optimum d'avis mesurés soient en jeu est un vrai souci. Mais avoir cette idée est en soi déjà un souci pas du tout correct . Cordialement, --Lgd (d) 8 février 2012 à 15:17 (CET)

Je me demande plutôt s'il est opportun de laisser les votants commenter leur vote directement sur la page de vote. On peut supposer en effet que, par paresse ou manque de temps, les votants lisent moins attentivement l'explication de la proposition au fil du temps et se basent plutôt sur les commentaires des copains. --Amicalement, Salix ( converser) 8 février 2012 à 15:39 (CET)

C'est un peu un autre sujet, mais en moyenne une part non négligeable (disons au doigt mouillé 1/3) des votants n'ont en effet pas lu de quoi il s'agissait (j'ai vu passer un aveu touchant je ne sais plus où dans celle-ci, d'ailleurs : il disait qu'il s'était arrêté à la 3e ligne et qu'il avait voté). Interdire de commenter les votes n'y pourra rien : ils ne lisent pas plus ce qu'on en disent les autres qu'ils ne lisent de quoi il s'agit. Ce n'est pas un souci, c'est à la base de n'importe quelle consultation. Cordialement, --Lgd (d) 8 février 2012 à 15:48 (CET)

1/3 ! Là je crois que tu mésestimes un peu trop nos contributeurs, non ? --Amicalement, Salix ( converser) 8 février 2012 à 15:56 (CET)

Ce qui est rageant, aussi, c’est les votes hors-sujet parce que justement les votants n’ont pas lu la question… --Pic-Sou 8 février 2012 à 16:07 (CET)

@Salix : Les meilleures sont les plus courtes : une PDD doit poser au contributeur une question à laquelle il peut apporter une réponse instinctive. Il ne va pas plus loin. Ne serait-ce que parce que les questions longues sont compliquées, demandent de la lecture attentive ou demandent plus que l'attention usuelle d'un « j'aime/pas », ce qui est ce qu'on retient généralement sur le Web. L'internaute se prononce globalement avec ses pieds : pourquoi en serait-il autrement ici ? --Lgd (d) 8 février 2012 à 16:13 (CET)

Résultats

Est-ce que quelqu'un peut faire le dépouillement des votes pour qu'on publie les résultats ? Udufruduhu (d) 20 février 2012 à 09:19 (CET)

Dans la section du dessus. Amicalement — Arkanosis ^✉ 20 février 2012 à 11:10 (CET)

Merci à ceux qui y comprennent quelque chose d'afficher ça clairement en haut de la page de vote. C'est agaçant tous ces sondages clos dont le résultat est introuvable ou incompréhensible . --Amicalement, Salix ( converser) 20 février 2012 à 11:42 (CET)

C'est pourtant simple : le résultat prévue et prévisible est non mais avec un % de oui encourageant pour l'avenir. Que demander de plus  ? --Lgd (d) 20 février 2012 à 11:55 (CET)

 Fait. Udufruduhu (d) 20 février 2012 à 11:58 (CET)

Hélas, hormis la mention du rejet, encore une fois le résultat est formulé de façon inexploitable pour quelqu'un qui lit uniquement ceci. Aucun pourcentage permettant de mesurer clairement l'écart entre les trois choix, renvoi vers une page où on ne sait pas exactement où chercher, décomptes en pdd qui parlent de duels mais ne permettent pas de saisir qui gagne, si l'écart est important, etc. Si je lis « Duel entre A et C ⇒ C (à 103 contre 67, 4 indifférents) » j'en conclue que A=103 et C=67 et donc que A gagne. En dessous il y a la mention « Vainqueurs potentiels : C », ce qui ne veut rien dire de définitif. Bref, encore un résultat incompréhensible a posteriori par un lecteur qui ne souhaite pas tout lire. --Amicalement, Salix ( converser) 20 février 2012 à 20:16 (CET)

Si tu as une idée précise de ce qu'il faut mettre, fais-en une proposition cette page. Personnellement, je n'ai pas envie de passer plus de temps que ce que je n'ai déjà fait à décortiquer les résultats pour en faire sortir une analyse détaillée en %. Udufruduhu (d) 20 février 2012 à 20:33 (CET)

Tu n'es pas personellement visé Udufruduhu, c'est hélas le cas de nombreux résultats. --Amicalement, Salix ( converser) 20 février 2012 à 23:44 (CET)

C'est vrai que c'est loin d'être clair… 78.251.247.247 (d) 21 février 2012 à 16:12 (CET)

Suppression du gadget lié à la PDD

Bonjour,
Un gadget MasquerCrochets avait été mis en place dans le cadre de cette proposition. Il n'avait d'utilité que dans la mesure où l'une des proposition « parenthèses » ou « crochets »aurait été adoptée. Pas d'objection à sa suppression ? Ou bien préférez-vous qu'il soit transformé en gadget rétablissant les crochets ou les parenthèses pour ceux qui le souhaitent ? Cordialement, --Lgd (d) 20 février 2012 à 09:56 (CET)

Je pense que ce serait bien qu’il permette d’afficher les crochets. Cordialement --Pic-Sou 20 février 2012 à 10:01 (CET)

+1 Devrait être utile justement aux gens que l'affichage actuel dérange. --Amicalement, Salix ( converser) 20 février 2012 à 11:38 (CET)

+1 Et merci Lgd, très cordialement. le sourcier ^{[on cause ?]} 20 février 2012 à 20:58 (CET)

Mobile

Pour info, sur la version mobile, l'appel de ref est entre crochet. Exemple : ici. Les stats de décembre : ici indiquent 12,5% de consultation par mobile (mais on ne connait pas l'interface utilisée). - Drongou (d) 21 février 2012 à 00:24 (CET)