Wikipédia:Prise de décision/Adoption du balisage dfn dans les introductions d'articles

Adoption du balisage dfn dans les introductions d'articles Présentation de la prise de décision Phase actuelle : Résultat / Phase suivante : proposition rejetée Cette prise de décision concerne l'utilisation d'une nouvelle syntaxe dans les introductions d'articles, pour en améliorer la sémantique Web. Ouverture de la discussion : le 03 avril 2011 Clôture de la discussion : le 17 juillet 2011 Début du vote : 20 juillet 2011 à 00h00 (CEST) Fin du vote : 16 août 2011 à 23h59 (CEST)

Wikipédia:Prise de décision Prises de décisions Vote ouvert Phase de discussion Refonte du processus de labellisation d'articles Modalités de gestion des conflits Sondages Vote ouvert Phase de discussion Liens internes sur le jour et le mois d'une date Boîtes utilisateur d’opinion Points de formulation pour les biographies des personnes trans Code de bonne conduite Procédure de contestation Recommandation portant à placer le premier paragraphe introductif avant toute image ou infobox Mettre à jour

Le vote est clos

Explications

En bref

Cette PDD propose l'adoption limitée d'une nouvelle syntaxe, à ce stade uniquement dans le cadre des paragraphes introductifs d'articles. Elle est destinée à améliorer la sémantique des pages Wikipédia et leur indexation ou exploitation par des outils internes ou externes.

Wikipédia:Résumé introductif indique que :

« La première phrase est primordiale dans un article encyclopédique. Il est conseillé de produire une définition du sujet de l'article en rappelant explicitement son titre »

— Wikipédia:Résumé introductif

C'est cette définition ou description dont nous vous proposons d'améliorer la sémantique en remplaçant la mise en gras du terme défini (code wiki '''...''') par un nouveau balisage implémenté par MediaWiki 1.17 en février 2011, sans changement du rendu visuel, sous la forme du modèle {{terme défini|...}} ou directement du balisage <dfn>...</dfn>.

Cette PDD n'entre volontairement pas dans certains détails qu'il est préférable de ne pas figer, tels que d'éventuelles redirections permettant de donner des alias plus courts au modèle {{terme défini}}, ou encore ce qu'il conviendrait de faire en cas d'adoption simultanée des deux syntaxes et de désaccord dans un article, etc. S'agissant d'une question essentiellement technique, il est préférable de conserver une certaine souplesse lors de l'application, pour ajuster selon les besoins via la page Aide:dfn.

Changement proposé en détail

Un usage bien ancré veut qu'on mette en gras le ou les termes désignant le sujet de l'article dans son introduction (souvent la simple reprise du titre de l'article). Par exemple, dans l'article Wikipédia :

'''Wikipédia''' est une [[encyclopédie]] multilingue, universelle, [[contenu libre|librement diffusable]],
disponible sur le [[World Wide Web|Web]] et ...

Qui donne :

« Wikipédia est une encyclopédie multilingue, universelle, librement diffusable, disponible sur le Web et ... »

Le balisage HTML qui en résulte n'est à vrai dire pas optimal, bien que cela ne pose pas de souci majeur dans l'immédiat et pourrait rester en l'état. La mise à jour en février 2011 de MediaWiki permet cependant d'envisager une amélioration d'ordre technique et sémantique, sans aucun changement sur le rendu (cela restera en gras, éventuellement en italique pour un titre d'oeuvre, etc.) ni sur les contributions (on peut semi-automatiser la correction par la suite si un contributeur crée un article avec le balisage actuel).

Cette modification consiste à remplacer le balisage wiki '''...''' de la ou des mentions du sujet par un balisage <dfn>...</dfn> ou bien, si les contributeurs le préfèrent, par {{Terme défini|...}} qui produit le même résultat.

Dans notre exemple, cela conduirait à écrire :

<dfn>Wikipédia</dfn> est une [[encyclopédie]] multilingue, universelle, [[contenu libre|librement diffusable]],
disponible sur le [[World Wide Web|Web]] et ...

ou bien :

{{terme défini|Wikipédia}} est une [[encyclopédie]] multilingue, universelle, [[contenu libre|librement diffusable]],
disponible sur le [[World Wide Web|Web]] et ...

Qui donnent :

« Wikipédia est une encyclopédie multilingue, universelle, librement diffusable, disponible sur le Web et ... »

Lorsque plusieurs termes sont mentionnés dans l'introduction pour désigner le même sujet d'article, chaque terme serait balisé. Par exemple, dans l'article Alces alces :

{{terme défini|Alces alces}}, appelé {{terme défini|orignal}} ou {{terme défini|élan}} au sein de la francophonie, est la plus grande des espèces de cervidés...

Qui donne:

« Alces alces, appelé orignal ou élan au sein de la francophonie, est la plus grande des espèces de cervidés... »

Qu'est ce balisage <dfn>...</dfn> ?

Sa définition technique n'est pas très abordable, mais l'idée à retenir est qu'il est utile quand un paragraphe de texte donne une définition de « quelque chose », pour indiquer quel est le « quelque chose ». Cette notion de « définition » peut ici être vue de manière élargie et correspond également aux différents mode de description du sujet dans le premier paragraphe introductif d'un article de Wikipédia.

À quoi cela sert-il ?

Ce balisage HTML ne date pas de la récente norme HTML5, mais son usage est longtemps resté incertain. À vrai dire, le fait que Wikipédia s'en serve va aussi aider à consolider celui-ci :

• Cela peut servir au sein des projets Wikimedia à extraire des articles des définitions de notions, et à bâtir des index : pour faire cela, il faut pouvoir localiser les termes définis (ce qui est dans le {{terme défini|...}}) et ce qui les définit (le paragraphe qui comporte un {{terme défini|...}}).
• Cela va aider les moteurs de recherche externes (comme Google) qui comportent déjà des fonctionnalités de recherche de définition de notion, comme Google define. Celle-ci ne bénéficie pas actuellement de ce balisage sémantique dans Wikipédia : cette modification serait une amélioration ou une consolidation potentielle du référencement des articles.
• C'est également une technique favorisant l'accessibilité du contenu (voir Using the dfn element to identify the defining instance of a word pour les aspects techniques).

Google define, un exemple concret

Un exemple d'extraction de contenus, parmi d'autres possibles, en montre la nécessité : Google extrait des définitions accessibles spécifiquement via Google define, par exemple avec la requête define: Accessibilité du Web:

Définitions de Accessibilité du Web sur le Web :
L'accessibilité du Web est la problématique de l'accès aux services et contenus en ligne pour les handicapés et les seniors...
fr.wikipedia.org/wiki/Accessibilité_du_Web

Dans ce cas, en s'appuyant uniquement sur le titre de l'article, Google indexe correctement l'expression « Accessibilité du Web » et une définition de celle-ci.

Mais, faute d'un balisage sémantique assez précis, il arrive à Google de fournir une définition erronée en ne pouvant s'appuyer que sur les titres de pages. Par exemple celle-ci :

Définitions de WCAG sur le Web :
L'accessibilité du Web est la problématique de l'accès aux services et contenus en ligne pour les handicapés et les seniors...
fr.wikipedia.org/wiki/Accessibilité_du_Web)

Or, « WCAG » désigne tout autre chose (c'est le sigle d'une norme technique spécifique liée à l'accessibilité du Web, mais sans confusion possible avec ce champ beaucoup plus vaste). Google indexe le même contenu que pour l'exemple précédent, parce qu'il ne peut se fier qu'aux seuls titres de pages et que le titre WCAG est une redirection vers accessibilité du Web. Lui fournir un balisage pertinent permettrait d'éviter ce genre d'erreurs.

Quelles seront les règles d'usage ?

La page Aide:dfn précise les usages de ce nouveau balisage. Les points clés sont :

• qu'il est réservé au seul premier paragraphe introductif des articles ;
• qu'il est exclu des articles où le terme et sa définition ou description ne figurent pas ensemble dans ce premier paragraphe (il est donc exclu notamment des pages d'homonymies).

Comment va-t-on s'y prendre ?

Potentiellement, la quasi-totalité des articles actuels de Wikipédia est concernée par ce sujet. Il est évident que le ressort sera le recours aux bots. La question ayant été posée aux dresseurs de bots, il s'avère que le remplacement est pour une large partie automatisable (voir les discussions sur le sujet) : le respect quasi-général des recommandations sur les introductions d'articles permet de procéder à un remplacement automatique des mises en gras dans chaque premier paragraphe par le balisage dfn sous la forme qui sera retenue ici, en procédant ensuite à des corrections manuelles.

Le traitement d'une telle masse d'articles devra évidemment se faire par tranches et être soigneusement organisé avec les dresseurs de bots et prendra du temps. Pour mémoire, il a déjà été procédé avec succès à au moins une opération de très grande ampleur par les bots, bien que celle-ci aille au-delà : l'application de Wikipédia:Prise de décision/Sous-pages de discussion des articles en 2009.

Par la suite, un filtre peut aisément signaler la création ou la modification d'un article sans ce balisage, permettant ainsi à des wikignomes d'intervenir pour améliorer la syntaxe. Le Projet:Correction syntaxique pourrait également intégrer la détection et la correction des introductions de nouveaux articles ne faisant pas appel à dfn ou à son modèle.

Une page d'aide explique le rôle et l'usage de ce balisage : elle permettra d'ajuster les règles techniques d'usage si nécessaire.

La syntaxe finalement retenue (<dfn></dfn> ou le modèle {{terme défini|...}}équivalent) pourront être ajoutés aux raccourcis fournis en dessous de la fenêtre d'édition (dans la ligne de liens « [[Catégorie:]] [[Fichier:]] [[Media:]] #REDIRECTION[[] » etc. lorsque vous éditez une page).

Serait-il pertinent de s'en servir plus largement ?

Non, en tout cas pas dans un premier temps : les contraintes techniques et sémantiques liées à ce balisage sont complexes, et un usage plus général entraînerait très probablement trop d'erreurs, pour un bénéfice potentiel improbable. L'application aux résumés introductifs d'articles est un cas à la fois simple et que l'on peut aisément guider. Il faut déjà faire ce premier pas avant d'envisager plus.

Un dispositif « léger » (uniquement via des styles CSS ajoutés à Mediawiki:common.css) permettra d'avertir le contributeur qui utiliserait ce balisage en dehors du cadre défini (pour plus de détails techniques voir ce code). En cas d'usage impropre, il produirait quelque-chose comme : foo .

Dans les articles comportant des sections de « glossaire » avec des séries de définitions de termes, un autre balisage sémantique suffisant est déjà en place : celui des listes de définitions (voir par exemple Glossaire du cinéma).

Vote

Acceptez-vous l'utilisation systématique du balisage dfn dans les paragraphes introductifs d'articles, selon l'usage décrit dans les explications ci-dessus et sous l'une des formes proposées ci-dessous ?

Question A. Adoption du balisage ?

Un seul vote est possible. La proposition sera adoptée si les votes « pour » ci-dessous atteignent au moins 60% des votes « pour+contre ».

Pour

1. Udufruduhu (d) 20 juillet 2011 à 01:21 (CEST)
2. Pour Totodu74 (devesar…) 20 juillet 2011 à 01:23 (CEST)
3. --Hercule ^Discuter 20 juillet 2011 à 01:37 (CEST)
4. – Bloody-libu (ö¿ô) 20 juillet 2011 à 01:51 (CEST)
5. --Nouill 20 juillet 2011 à 03:21 (CEST)
6. Pour A une utilité et ne complexifie pas : <dfn>texte</dfn> (s'il est choisi) remplace '''texte''' --'toff ^[discut.] 20 juillet 2011 à 05:09 (CEST)
7. Pour Mith avec une signature pourrie sans image pour ne pas faire mal aux yeux de certains (What ? You're talkin' to me ?) - Angers, le 20 juillet 2011 à 07:10 (CEST)
8. Sardur - allo ? 20 juillet 2011 à 07:23 (CEST)
9. --TaraO (d) 20 juillet 2011 à 07:33 (CEST)
10. Pour Beaucoup de débutants déjà ne mettent pas en gras le terme défini. Utiliser dfn ou le modèle est juste un changement dans les habitudes des patrouilleurs et wikignomes, allant dans le sens d'une meilleur utilisabilité du contenu. Litlok (m'écrire) 20 juillet 2011 à 07:54 (CEST)
11. Après les catégories, une seconde avancée vers l'ordre. TIGHervé 20 juillet 2011 à 08:48 (CEST)
12. MicroCitron ^{un souci ?} 20 juillet 2011 à 09:01 (CEST)
13. Pour--Chandres (✉) 20 juillet 2011 à 09:22 (CEST)
14. Pour Modification qui ne doit impacter que très faiblement les articles, et qui plus est sur une partie qui doit très peu changer : la définition du sujet. Ne devrait donc pas perturber les rédacteurs. Freewol (d) 20 juillet 2011 à 09:52 (CEST)
15. Pour Je trouve que c'est une bonne chose de remplacer une indication de formatage typographique ( ' ' ' ou < b > ) par une indication sémantique qui renseigne sur le contenu. mb2011 (d) 20 juillet 2011 à 10:05 (CEST)
16. Pour Pour une meilleure visibilité et une incitation à mettre un paragraphe introductif. Kelam (Qu'est-ce que c'est ?) 20 juillet 2011 à 10:15 (CEST)
17. Pour, un pas de plus vers le web sémantique. --MGuf (d) 20 juillet 2011 à 10:28 (CEST)
18. Pour --Benj05 (d) 20 juillet 2011 à 10:39 (CEST)
19. Pour Après avoir regardé le code de quelques intros au hasard, ce n'est pas ça qui va le complexifier réellement (même après avoir retiré les bandeaux et infobox). Moyg hop 20 juillet 2011 à 10:50 (CEST)
20. Pour Remplacer de la « forme » par du « sens », c'est tout bon. Chacun n'est pas obligé de se soucier de cette syntaxe, d'autres passeront derrière. — Arkanosis ^✉ 20 juillet 2011 à 11:30 (CEST)
21. Pour l’utilité est peut-être pas flagrante mais la complexité encore moins (+1 à Moyg ; et vous êtes jamais allé sur Wikisource ou le Wiktionnaire pour parler de complexité). Vigneron * ^discut. 20 juillet 2011 à 11:33 (CEST)
22. Pour FF 20 juillet 2011 à 12:53 (CEST)
23. Pour L'accessibilité, c'est important, tant pis si c'est un peu plus pénible à écrire. D'autre part, mettre le titre en gras n'a pas de sens particulier. Avec ce balisage, chacun pourra personnaliser le rendu dans son CSS (plus grand, en jaune fluo, etc.) Peter17 (d) 20 juillet 2011 à 13:24 (CEST)
24. Pour modéré, parce que le niveau de complexité atteint par le source des pages commence à être rédhibitoire. Bibi Saint-Pol (sprechen) 20 juillet 2011 à 13:36 (CEST)
25. Pour la lisibilité de la syntaxe wiki est un autre problème et touche aussi tous les modèles couramment inclus dans les pages.--Y▬Spirine@causer 20 juillet 2011 à 15:09 (CEST)
26. Pour favoriser et affiner les modalités d'exploitation par les moteurs de recherche. Kertraon (d) 20 juillet 2011 à 16:09 (CEST)
27. Plutôt pour. Autant je suis convaincu de l'intérêt dans le code final, autant je ne suis pas sûr que ce soit au contributeur de s'en soucier : à lui la rédaction et la mis en forme, au logiciel le parsing et le rendu. Dans le cas présent, les balises usuelles '''def''' pourraient très bien être traduites en <dfn>def</dfn> dans le résumé introductif par Mediawiki (par exemple). Binabik (d) 20 juillet 2011 à 16:55 (CEST)
28. Pour Utilité démontrée. od†n ↗^blah 20 juillet 2011 à 17:00 (CEST)
29. Pour Convaincu de l'utilité. Pymouss |Parlons-en| 20 juillet 2011 à 20:36 (CEST)
30. Pour utile et pertinent même si cela complique un peu les introductions pour les contributeurs.--Bapti ✉ 20 juillet 2011 à 22:05 (CEST)
31. Pour selon ƝEMOI – Aussi simple–aberrant que de mettre le premier terme en gras, avec de nets avantages concernant la sémantique. A voté ce 20 juillet 2011 à 23:13 (CEST).
32. Pour Plus logique, plus utile et plus sensé qu'un mot simplement mis en gras, et ce n'est pas pour autant plus lourd ni plus compliqué. Le tout sera de s'y habituer. Nadin123 [discuter] 21 juillet 2011 à 01:05 (CEST)
33. Pour Utile et presque sans effort. À 5 octets de plus par article, c'est une fonctionnalité additionnelle à bas prix! — Bouchecl (dring) 21 juillet 2011 à 06:12 (CEST)
34. Pour Moez ^m'écrire 21 juillet 2011 à 14:29 (CEST)
35. Semble être une réelle amélioration, et pas bien compliqué quand même (l'oubli fréquent du gras par les nouveaux contributeurs est déjà bien souvent corrigé par la suite, pourquoi n'en serait-il pas de même avec ce nouveau système ?). p-e 21 juillet 2011 à 15:13 (CEST)
36. Pour… indiscutablement ! — MetalGearLiquid ^{[m’écrire]} 21 juillet 2011 à 20:54 (CEST)
37. Pour Gérard (d) 22 juillet 2011 à 10:58 (CEST)
38. Pour Tout est dit je pense, voilà l'inconvénient d'arriver à la bourre... ~Hlm Z. [@] 22 juillet 2011 à 12:37 (CEST)
39. Pour Pas pire que ça, ça ou ça que chaque contributeur utilise constamment... --Indeed ^{[knock-knock]} 22 juillet 2011 à 12:55 (CEST)

    Constamment, ça me paraît franchement exagéré et surtout ils sont sur tous les claviers.--Guil2027 (d) 23 juillet 2011 à 11:17 (CEST)

    Exagéré ? Ha oui ? En tand que contributeur, je le répète, quasi à chaque édition on utilise [|{, non ? j'ai faux ? --Indeed ^{[knock-knock]} 25 juillet 2011 à 12:40 (CEST)

    Ben oui, c'est quand même pas tous les jours qu'on les utilise. A chaque édition ? Mais à quel moment ? A la limite le { (j'ai voulu mettre un par exemple) --Guil2027 (d) 26 juillet 2011 à 21:18 (CEST)

    Remettons les choses dans leur contexte, nous parlons de contributions dans l’espace principal (ie, les articles, pas les PDD, ni le bistro, ni les pages ou les gens s’écharpent à qui mieux-mieux^{[non neutre]}). Si tu regardes tes propres contributions, tu verras très certainement que tu utilises ces signes à quasi chaque fois (pas pour les révocations, ni les corrections ortho, je te l’accorde volontiers), alors remplacer des '''texte''' par des <dfn> …</dfn> ou des {{Terme défini|...}}, et ce uniquement dans l'intro de l'article, ne me semble pas la mer à boire. En tous cas pardon, mais mon avis qui semble te causer une si grande contrariété, je le conserve, et je le motive comme je veux. --Indeed ^{[knock-knock]} 27 juillet 2011 à 11:04 (CEST)

    Non je maintiens que je les utilise très très peu, mais ton avis ne me cause aucune contrariété, je me demandais dans quelles circonstances ça t'arrivait de les utiliser constamment. Simple étonnement de ma part si tu préfères. --Guil2027 (d) 27 juillet 2011 à 15:00 (CEST)

40. Pour le web sémantique, et un plus non négligeable pour l'accessibilité (qui ne se limite pas aux aveugles, sourds et tétraplégiques, mais concerne aussi les outils informatiques, robots, les appareils mobiles, etc.) La complexité ajoutée n'est pas tellement plus grande que les ''''' et autres balisages qui se développent de toutes façons déjà dans les intros. — Calimo ^{[á quete]} 22 juillet 2011 à 16:51 (CEST)
41. Jean-Fred (d) 22 juillet 2011 à 21:07 (CEST)
42. Pour : bonne utilité.--Morphypnos^[Dormir...]. 22 juillet 2011 à 22:17 (CEST)
43. Pour--pixeltoo (discuter) 23 juillet 2011 à 00:17 (CEST)
44. Pour quand même ! ce n'est pas si dur de comprendre <dfn> -> définition ! --Pic-Sou (d) 23 juillet 2011 à 16:08 (CEST)
45. Pour --Cbyd (d) 23 juillet 2011 à 18:14 (CEST)
46. Pour et idem Pic-Sou. --Égoïté (d) 24 juillet 2011 à 15:17 (CEST)
47. Pour--Rosier (d) 24 juillet 2011 à 23:20 (CEST)
48. Pour Goodshort (d) 25 juillet 2011 à 14:11 (CEST)
49. Pour Hadrianus (d) 25 juillet 2011 à 14:28 (CEST)
50. Plutôt pour Peut éloigner un peu plus le néophyte mais si c'est mieux pour l'extractibilité.. -- Xfigpower (pssst) 25 juillet 2011 à 17:37 (CEST)
51. Pour mieux que le gras--Remy34 (d) 26 juillet 2011 à 09:15 (CEST)
52. Pour, en contrepied aux opposants : pas convaincu de l'inutilité. Skippy le Grand Gourou (d) 26 juillet 2011 à 09:53 (CEST)
53. Pour pas plus compliqué que le gras, et au moins ça porte une sémantique, contrairement au gras (qui ne porte qu'un usage wikipédien) Hexasoft (discuter) 26 juillet 2011 à 11:07 (CEST)
54. Pour CQui (d), avec preference pour le modele, je n'aime pas les <> quand un modele marche aussi bien. Si on trouve ce dispositif trop compliqué pour les nouveaux, alors il faut commencer par virer toutes les infobox, tous les bandeaux et autres machins entre accolades. --27 juillet 2011 à 09:58 (CEST)
55. Pour Je n'ai pas le sentiment que cela soit atrocement compliqué et je pense que l'utilité est certaine, à défaut d'être évidente. Martin // discuter 27 juillet 2011 à 11:15 (CEST)
56. Pour Pour rendre l'encyclopédie encore plus réutilisable. — Mirgolth 27 juillet 2011 à 13:25 (CEST)
57. Pour Le modèle ne me paraît pas plus compliqué à utiliser que les « triples ' » (voire quadruples quand le terme défini est précédé par « l' » ou « d' ». FrançoisD 27 juillet 2011 à 14:46 (CEST)
58. Pour La complexification est nulle (un "dfn" est aussi abscon pour un nouveau qu’un triple guillemet). Le gain sémantique est loin d’être négligeable et améliorera la finesse du référencement. Tpt (d) 27 juillet 2011 à 22:16 (CEST)
59. Pour Utile pour l’accessibilité, plus logique et compréhensible que la mise en gras, et pas plus compliqué. Un vrai progrès à mon sens. — Moipaulochon (@) 28 juillet 2011 à 01:09 (CEST)
60. Pour Trafalguar ^[✉] 28 juillet 2011 à 18:47 (CEST)
61. Pour --Prosopee (d) 28 juillet 2011 à 18:54 (CEST)
62. Pour Marquage sémantique utile ; je suis partisan du WYSIWYM (What you see is what you mean), car cela facilite le traitement du contenu par les machines (qui sont, par définition, stupides) pour les humains. En contrepartie, une charge négligeable pour le contributeur. —C.P. 29 juillet 2011 à 09:58 (CEST)
63. Pour. Iorek (d) 29 juillet 2011 à 18:25 (CEST)
64. Pour Cela améliorera l’accessibilité au niveau des articles. --Newyork60 30 juillet 2011 à 10:59 (CEST)
65. Pour --Juju2004 (d) 31 juillet 2011 à 12:12 (CEST)
66. Kelson (d) 3 août 2011 à 22:46 (CEST)
67. Pour Si cela permet de mieux retrouver les articles et d'améliorer la diffusion de l'information. Rebmat (d) 4 août 2011 à 14:09 (CEST)
68. Pour car ça n'a pas l'air bien compliqué, ça ne concerne qu'un mot ou une expression par article et il paraît que c'est utile.--Ps2613 (d) 6 août 2011 à 17:01 (CEST)
69. Pour Pas très compliqué et c'est utile! Tsunami330 ^[blabla] 6 août 2011 à 17:55 (CEST)
70. Pour Gz260 (d) 6 août 2011 à 23:13 (CEST)

    Pour </>Moez ^m'écrire 8 août 2011 à 19:49 (CEST) vote double voir 31 comme signalé dans les derniers votes contre

71. Pour Kyro ^{me parler} le 9 août 2011 à 02:04 (CEST)
72. Pour Xavier Combelle (d) 10 août 2011 à 19:57 (CEST)
73. Plutôt pour Cynddl ^{( ⌧ )} 11 août 2011 à 16:49 (CEST)
74. Pour Pas bien compliqué, donc si c'est utile... LittleTony87 (d) 11 août 2011 à 22:49 (CEST)
75. Pour Zakke (d) 12 août 2011 à 00:28 (CEST)
76. Pour--Rehtse (d) 12 août 2011 à 10:38 (CEST)
77. Pour. Je ne crois pas qu'il soit bien plus difficile d'écrire <dfn>titre</dfn> que '''titre'''. Néanmoins je peux concevoir que certains ne veulent pas de complication, mais même dans ce cas, le contributeur qui ne sait pas le faire, hé bien il utilise l'ancienne mise en forme (en gras) ou pas de mise en forme du tout, et les autres corrigeront derrière lui, en même temps qu'ils corrigeront autre chose de plus visible. Là il y a un gain en accessibilité qui ne s'obtient qu'au prix d'une modification mineure, je trouverais dommage de s'en priver. Il y a bien d'autres gadgets moins utiles dont on pourrait se passer aisément, commençons par ceux-là plutôt que d'empêcher une amélioration objective. — Hr. Satz 12 août 2011 à 16:32 (CEST)
78. Pour Ca ne change guère les habitudes _ une mise en gras pourra toujours être remplacée automatiquement, pour quelques bénéfices. Topeil (d) 13 août 2011 à 10:51 (CEST)
79. Pour Parfaitement dans la logique visant à séparer le fond et la forme. Le gras et l'italique n'étant que des tentatives de mise en exergue visuelle, je préfère une mise en exergue dans le texte (balise dfn par exemple) qui est ensuite rendu sous forme de gras (ou tout autre moyen en fonction de l'accessibilité). Eric schreiner (d) (d) 16 août 2011 à 13:07 (CEST)

Contre

1. Contre Apport somme toute limité qui complique encore plus la syntaxe pour les non-initiés. Chris93 (d) 20 juillet 2011 à 01:36 (CEST)

   j'ai voté pour car justement ce n'est pas une question de syntaxe (=la forme) mais de sémantique (le contenu) : ( ' ' ' ou < b > c'est du formatage typo, < dfn > c'est une information sur la signification. MB (d) 20 juillet 2011 à 11:06 (CEST)

2. Contre encore une complication de la syntaxe, qui s'ajoute à beaucoup d'autres. C'est va à l'encontre de l'idée initiale qui était de donner accès à un maximum de contributeurs, voir [1].Dingy (d) 20 juillet 2011 à 04:46 (CEST)

   Il me semble que l'accessibilité de wiki à un maximum de lecteurs prime sur celle donnée aux contributeurs, le but premier de l'encyclopédie étant d'être lisible et accessible par un maximum de personnes. Udufruduhu (d) 20 juillet 2011 à 10:08 (CEST)

   Ah ? Les lecteurs handicapés se sont multipliés, depuis ? Quid des contributeurs handicapés ? On peut leur ajouter des contraintes, alors ? --Warp3 (d) 8 août 2011 à 04:42 (CEST)

   Le contenu devrait primer sur la lisibilité. C'est il me semble le sens du lien donné par Dingy. -- Perky ♡ ✍ 20 juillet 2011 à 10:19 (CEST)

   Pendant 6 ans l'encyclopédie a été lisible et accessible sans toutes les complications qui ont été introduites ces dernières années. Ce qu'on a gagné c'est d'être corrigé en permanence par des spécialistes des dernières nouveautés dans le domaine de la syntaxe, et c'est pénible et décourageant pour le créateur d'articles que je fus. Dingy (d) 20 juillet 2011 à 10:27 (CEST)

   Accessible pour toi mais pas pour les personnes présentant un handicap physique ou technologique. Il est bon parfois de voir au-delà de sa petite sphère personnelle. Udufruduhu (d) 20 juillet 2011 à 10:39 (CEST)

   @Perky : oui le contenu est important mais ne sert à rien pour les personnes qui ne peuvent pas le lire... Udufruduhu (d) 20 juillet 2011 à 10:41 (CEST)

   Pour les personnes qui ne peuvent pas lire à cause d'un handicap il y avait, je ne sais pas si c'est encore en cours, des versions audio. Pour les personnes qui ne peuvent pas lire sur leur téléphone... là c'est vraiment accessoire et peu philanthropique ;-) Enfin, je dis ça sans avoir lu le mode d'emploi du bidule, parce que perso je suis allergique. -- Perky ♡ ✍ 20 juillet 2011 à 11:15 (CEST)

   Juste une précision : les « versions audios » des articles Wikipédia ne sont pas une solution d'accessibilité suffisante, même de manière minimale. Voir à ce sujet notamment FAQ accessibilité ainsi que ces explications plus récentes sur le Bistro. Enfin, le handicap ne se réduit pas aux aveugles et les versions audio sont par exemple d'une rare inutilité pour les sourds, si je puis me permettre un exemple un peu direct --Lgd (d) 20 juillet 2011 à 11:29 (CEST)

3. Contre Complication de la syntaxe inutile --charly (d) 20 juillet 2011 à 05:47 (CEST)
4. Contre Comme Chris93, apport limité ; j'aurais voté Pour si une syntaxe wiki avait pu être adoptée. Ascaron ¿! 20 juillet 2011 à 07:48 (CEST)
5. Contre : complexification d'une syntaxe qui ne pose pas de problème (« Le balisage HTML qui en résulte n'est à vrai dire pas optimal » : en quoi ?). Par ailleurs, le principal argument de la PdD se base sur l'indexation par les moteurs de recherche : c'est au moteur de recherche de remédier à ses défauts et c'est à l'internaute à faire le tri dans ce qui lui est proposé comme résultat de recherche, tant pis pour lui s'il ne sait pas lire et trouve des informations erronées. Rémi ✉ 20 juillet 2011 à 08:58 (CEST)

   Ce point n'a en effet pas été détaillé dans la proposition, étant un peu pointu. Pour y remédier : la syntaxe actuelle '''...'''produit le code HTML <b>...</b> qui est en fait uniquement destiné à des mises en gras ayant une valeur typographique sans équivalence spécifique en HTML. Ici, cette équivalence précise existe : avant tout le terme défini et dfn, mais à défaut l'emphase et la balise <em>...</em> (du point de vue HTML5, l'italique produit par défaut devant alors être restylé via un modèle) ou <strong>...</strong> (alternative à em en XHTML1.0 dont le vocabulaire est plus approximatif). Dans tous les cas, le balisage actuel ne répond pas à la règle normative qui est d'utiliser le balisage ayant la sémantique la plus précise à chaque fois que c'est possible. Il ne s'agit donc pas d'un défaut des moteurs de recherche, mais bien du code produit dans Wikipédia. Cordialement. --Lgd (d) 20 juillet 2011 à 09:13 (CEST)

6. Contre l'ajout de code dans le corps du texte - le gain en terme d'accessibilité me semble faible, voir négatif. Popo le Chien ^ouah 20 juillet 2011 à 09:32 (CEST)
7. Contre Pas convaincu que l'apport compense l'ajout de complexité. Touriste (d) 20 juillet 2011 à 09:41 (CEST)
8. Contre. Finalement il ne s'agit que de préciser que le titre est le titre et que le paragraphe introductif le définit (en résume la présentation), puisque cette proposition de balisage ne s'applique qu'au paragraphe introductif. Ce n'est pas au rédacteur de s'inquiéter de cela, ni plaisant de se voir automatiquement corrigé après coup d'un balisage dont l'intérêt n'est pas évident. J'aurais mieux compris ce balisage pour des définitions pouvant figurer pour d'autres termes dans le corps de l'article, mais elle est proscrite par cette proposition. --Michel Barbetorte (d) 20 juillet 2011 à 09:50 (CEST)
9. Contre Geekerie indigeste et pas sexy du tout, au prétexte croquignolesque d'« accessibilité ». -- Perky ♡ ✍ 20 juillet 2011 à 10:08 (CEST)
10. Contre Apporte une complexité superflue pour un gain limité (euphémisme). De plus, les termes définis peuvent être multiples dans un même article (on choisit lequel ?) lu. Enfin, je ne trouve pas que cela aille dans le sens d'une vulgarisation de l'édition Wikipédia à même de favoriser l'arrivée de nouveaux contributeurs. --Agamitsudo (d) 20 juillet 2011 à 10:26 (CEST)
11. Totalement Contre J'ai l'impression que certains rêvent que chaque mot sur wikipédia soit entouré de code, modèles ou autres. --Guil2027 (d) 20 juillet 2011 à 16:25 (CEST)

    Moi oui je confirme et c'est plus qu'un rêve ! Pour le moment, on mélange le « factuel » et le baratin, sans même prévenir d'ailleurs. On a bien inventé la ponctuation qui pouvait être considérée alors comme du code inutile et on peut continuer ainsi à complexifier le texte pour une meilleure fiabilité. On peut donc rêver aujourd'hui de texte(s) avec chacun une partie très chargée de code parce que la consistance de l'information le justifie et une autre optionnelle restant plus libre et proche du commentaire. (PS : les infobox assument cette fonction). TIGHervé 20 juillet 2011 à 17:36 (CEST)

    Je suis désolée mais je n'ai absolument rien compris à ta remarque.--Guil2027 (d) 20 juillet 2011 à 20:00 (CEST) Deuxième version : j'ai lissé mon texte...

    Je ne partage pas du tout ton rêve. Je trouve même que rajouter des codes informatiques à tout-va sans tenir compte des souhaits et des attentes des utilisateurs est en fait assez égoïste car cela contribue à exclure volontairement les personnes qui ne sont pas familiers de l'informatique purement technique (le commun des mortels en gros). Je pense qu'il faut commencer à freiner les ardeurs de certains parce qu'ils n'en sont pas capables eux-mêmes. En voyant l'ouverture de cette prise de décision, j'ai même cru que c'était limite une blague. --Guil2027 (d) 22 juillet 2011 à 00:36 (CEST)

    Ok je voulais dire que pour moi ce n'est pas du code informatique. Ce n'est pas autre chose que du soulignement ciblé et transparent (ce que ne serait pas de l'informatique, comme tu dis pour non-initié). TIGHervé 22 juillet 2011 à 11:24 (CEST)

    Tu vois même "soulignement", je ne connais pas ce terme technique. Alors tu penses bien que <:dfn>, c'est du chinois. --Guil2027 (d) 22 juillet 2011 à 14:13 (CEST)

    Soulignement ici n'est pas un terme technique . C'est juste une image prise par Hervé pour donner une idée de la manière dont est interprété dfn par un outil informatique analysant le code de la page. Litlok (m'écrire) 22 juillet 2011 à 14:23 (CEST)

    Ah d'accord ! Mais justement, où est l'humain dans tout ça ? --Guil2027 (d) 23 juillet 2011 à 11:13 (CEST)

12. Contre Assez d'accord avec Agamitsudo. Puce Survitaminée (d) 20 juillet 2011 à 18:56 (CEST)
13. Contre Absolument pas convaincu par les éventuels avantages que l'on pourrait tirer de ce changement. Parmi les inconvénients, une plus grande lourdeur dans le code html de la page, et plus de complexité à modifier.Thémistocle (d) 20 juillet 2011 à 19:35 (CEST)

    En réalité le code HTML produit est moitié moindre que le code actuel quand la langue est indiquée, et de... 4 octets de plus quand elle n'est pas indiquée. --Lgd (d) 20 juillet 2011 à 19:48 (CEST)

    Merci donc de confirmer ce que je disais supra : une plus grande lourdeur, via un accroissement en taille, ainsi que, surtout, la transformation d'un code simple (les 4 apostrophes) en une balise, plus complexe. Je suis déjà suffisamment agacé, quand je veux modifier un texte, de me perdre dans du contenu de balises références pour ne pas applaudir un truc qui ne sert objectivement à rien, quels que soient les prétextes avancés par ses partisans. Par ailleurs, il existe une page qui s'appelle discussion, et vos remarques me sembleraient être plus à leur place sur ladite page.Thémistocle (d) 20 juillet 2011 à 19:54 (CEST)

    La préparation d'une PDD ne peut pas anticiper toutes les informations à donner pour éviter les erreurs ou les confusions : il me paraît donc normal de donner les précisions nécessaires quand cela se produit, comme à propos du poids du code HTML. Et il me semble préférable de le faire dans cette page, pour que cela bénéficie à tous. --Lgd (d) 20 juillet 2011 à 20:00 (CEST)

    Ah, parce qu'il y avait "erreur" ou "confusion" à propos du code HTML? Je parlais dans ma première intervention de "plus grande lourdeur", ce que vous-même avez confirmé en mentionnant 4 octets de plus. En fait, s'il y a erreur ou confusion, cela vient plutôt de votre côté; en effet, les 4 octets supplémentaires, c'est si la balise dfn est adoptée. Si c'est le balisage Terme défini, on arrive à 17 caractères contre 6, soit un quasi-triplement du nombre de caractères nécessaires. Ainsi, si vos interventions se limitent à évoquer des prétendues erreurs et confusions, ou à désinformer soigneusement les lecteurs en ne mentionnant que la possibilité la plus favorable, ou plus exactement la moins défavorable, je ne pense pas que cela améliorera la discussion. Mais encore une fois, je déplore également l'invasion par les balises, parfois peu maniables et créées en dépit du bon sens, par rapport à un code extrêmement simple à comprendre et à utiliser, qui aura inévitablement pour effet de dissuader ou empêcher certains à contribuer. Enfin, dernier argument que je n'ai pas évoqué : le recours aux robots pour effectuer les modifications. L'utilisation du robot, pour autant nécessaire qu'elle soit, n'est pas sans risque.Thémistocle (d) 20 juillet 2011 à 20:16 (CEST)

    Tu parlais plus haut de « code HTML de la page », c'est à dire du code HTML produit à partir de la source wiki, et non de la source wiki. C'est du moins ce que j'ai cru comprendre ?

    • La différence pour le code HTML produit est minime dans l'usage par défaut (4 octets), et dfn permet au contraire de réduire de moitié le poids du HTML lorsque la mention de la langue intervient en plus de la mise en gras (il y a une imbrication de balises HTML en moins dans ce cas, c'est une petite mais non négligeable amélioration pour les navigateurs Web qui vont traiter et afficher la page).
    • En revanche, si c'est de la source wiki dont tu parles, le modèle comporte évidemment nettement plus de caractères que les '''. Mais la quantité de données hébergée sur les serveurs n'est pas une contrainte.

    J'espère que c'est plus clair à présent. --Lgd (d) 20 juillet 2011 à 20:57 (CEST)

    Que ce soit l'utilisation du modèle ou de la balise, le code HTML produit est strictement le même. Et pour relativiser les choses, une page d'ébauche comme Ferdinand Chaussebourg par exemple (que j'ai prise au hasard), tout compris (feuille de style, code JavaScript, etc.) fait environ 1Mo. 4 octets, cela représente donc pour cette page très basique une augmentation de 0,0004%. Litlok (m'écrire) 20 juillet 2011 à 21:02 (CEST)

    Bon, alors du code wiki si vous y tenez (je parle du code Html parce que je n'y connais pas grand chose dans tout cela, raison de plus pour vouloir conserver quelque chose de simple). Et puis c'est facile de prendre une page de 1 Mo, la prochaine fois prenez une page comme Wondo Genet. Bref, bilan des courses, et quoi que vous disiez, il y a plus de caractère, et une ignoble balise au lieu d'apostrophes. Et de toute manière je suis contre, c'est mon avis, et je le partage. Fin de la discussion, soliloquez si cela vous amuse.Thémistocle (d) 20 juillet 2011 à 23:00 (CEST)

    Même poids. Ce qui pèse le plus dans nu article Wikipédia, outre évidemment les images, c'est le javascript. Le HTML est tout à fait négligeable. Litlok (m'écrire) 20 juillet 2011 à 23:58 (CEST)

14. Contre Il est expliqué dans cette page que le remplacement du premier terme en gras par le balisage <dfn>...</dfn> se fera par des bots. Donc les bots de Wikipédia sont capables de détecter sans balisage la définition de l'article, et pas les moteurs de recherche. Et c'est à nous de palier à leur souci. Non. Deansfa 20 juillet 2011 à 20:08 (CEST)

    En fait les bots seront capables d'en remplacer une grande partie, mais pas forcément tous. Et ce n'est pas vraiment les bots qui en sont capables, mais leurs dresseurs qui ont une très bonne connaissance de Wikipédia et qui savent exactement comment faire, où chercher, quelles pages exclure (homonymies par ex). Ce n'est pas imaginable pour des personnes totalement extérieures à Wikipédia de faire un travail si précis (ou alors autant qu'ils rentrent directement toutes leurs définition à la main, sans passer par WP). Moyg hop 21 juillet 2011 à 15:39 (CEST)

    Les bots de Wikipédia travaillent à partir du code wiki, qui ne donne accès qu'au contenu d'un article. Le texte à reconnaître automatiquement est au début du code. À l'inverse, les moteurs de recherche doivent analyser le code HTML du fichier dans son ensemble. Il est alors extrêmement difficile pour eux de « reconnaître » le bout de phrase en gras perdu dans tout ce fatras. De plus, il est difficile d'envisager demander de la part des éditeurs de moteurs de recherche un traitement « à part » des pages Wikipédia par rapport à leurs procédés d'indexation du Web, car, indépendamment de toute autre considération (Knol par exemple...) la plus grande partie du contenu HTML (menus de navigation et de connexions, footer, etc.) varie d'un projet de la Foundation à un autre... et changent même parfois pour un projet donné ! En remplaçant <b> par <dfn>, ils trouvent instantanément ce bout de phrase. Litlok (m'écrire) 21 juillet 2011 à 15:41 (CEST)

    D'une manière plus générale, ce qui permet aux sites, aux navigateurs, aux moteurs de recherche etc. de « collaborer » en tirant le meilleur parti possible des contenus au bénéfice des utilisateurs, ce sont les standards du Web adoptés d'un commun accord par ces différents acteurs : les moteurs en tiennent compte et s'attendent donc légitimement à ce que les sites en fasse autant. Dans ce cas précis, dfn relève de ces standards et c'est bien à Wikipédia qu'il revient de s'y conformer en retour. Mediawiki a déjà fait une partie du chemin en l'implémentant, mais Wikipédia a encore un pas à faire en l'utilisant. Cordialement, --Lgd (d) 21 juillet 2011 à 16:19 (CEST)

15. Contre Grimlock 20 juillet 2011 à 21:21 (CEST)
16. Contre. Mix de Guil2027 (d · c · b), Perky (d · c · b) et Chris93 (d · c · b). SM ** ようこそ ** 20 juillet 2011 à 23:04 (CEST)
17. Contre GLec (d) 21 juillet 2011 à 08:03 (CEST) En pensant d'abord aux littéraires ici qui veulent simplement éditer en leur langue et qui ne doivent rien comprendre à cette PDD au point de devenir furax avec tout le code marginal qui apparaît la plupart du temps dans les articles en termes de fenêtre d'édition pour éditer simplement.
18. Contre Les articles deviennent de plus en plus illisibles en mode édition. Alors rajouter de plus en plus de complications pour un gain dont l'intêret est plus que discutable, non merci. Meodudlye (d) 21 juillet 2011 à 10:36 (CEST)
19. Contre Pas convaincu de l'utilité, et pas d'accord avec une utilisation systématique. Dans beaucoup d'articles, le premier terme en gras (quand il y en a un) ne correspond pas au titre de l'article, au hasard: Interféromètre du plateau de Bure, Scott Moore (baseball), Tentative d'invasion de l’Angleterre de 1806, Liste de langues, Liste des conseillers généraux de Loir-et-Cher ... Quel sens cela aurait'il d'introduire un "terme défini" dans ces cas? -- Speculos ^✉ 21 juillet 2011 à 16:53 (CEST)

    Je pense que les bots passeront en plusieurs fois pour éviter les erreurs, en ne traitant par exemple que les cas où le terme est exactement le titre de l'article dans un premier temps. Une partie sera à faire à la main (ou de manière semi-automatique). Sinon, je crois que tu n'as pas bien compris comment ça marchait. Pour l'exemple de Scott Moore (baseball) (et tous les autres cas d'homonymies avec parenthèses), ce qu'on cherche à définir c'est bien le terme "Scott Alanboyd Moore" et non "Scott Moore (baseball)". Moyg hop 21 juillet 2011 à 17:01 (CEST)

    C'est pour cela que le remplacement n'est pas prévu pour être entièrement automatisé, ni fait en aveugle. La page Utilisateur:Lgd/Déploiement dfn (emplacement et titre temporaire), créée lors des discussions préliminaires, est là pour qu'on y traite ce genre de questions. N'hésite pas à la compléter. Cordialement, --Lgd (d) 21 juillet 2011 à 17:02 (CEST)

    J'ai suivi et participé un peu au débat et je pense avoir compris ce que cela implique, merci. Ce que je conteste c'est ce qui est marqué ci-dessus dans la question : « Acceptez-vous l'utilisation systématique du balisage... », et qui d'après vos réponses ne semble plus être le cas. Soit on fait un remplacement systématique par bot, soit on juge au cas par cas (soit on fait la plus grosse partie par bot et le reste à la main, mais alors ce n'est plus systématique...). Ce que je veux dire c'est qu'il y a des articles qui ne contiennent pas de terme à définir; et dans l'exemple Liste des conseillers généraux de Loir-et-Cher un bot va mettre en terme défini le terme en gras « Nom du Canton », ce qui n'a pas vraiment de sens. Il faudrait ajouter au moins un contrôle sur le fait que le terme à définir corresponde au titre de l'article (hors parenthèses) il me semble. -- Speculos ^✉ 21 juillet 2011 à 17:15 (CEST)

    Ainsi que cela a déjà été discuté lors de la préparation (et acquis, cf le lien ci-dessus), les pages de listes sont exclues de cette mesure. Sinon, le « systématique » signifie évidemment dans tous les articles où c'est pertinent, c'est à dire dans la plus grande partie d'entre-eux... --Lgd (d) 21 juillet 2011 à 17:22 (CEST)

    OK, j'ai bien noté, mais je reste peu convaincu de l'utilité. -- Speculos ^✉ 21 juillet 2011 à 17:26 (CEST)

20. Contre pas convaincu de l'utilité --Garfieldairlines^{Miaou ? =^.^=} 22 juillet 2011 à 11:30 (CEST)
21. Ce balisage est cité dans un document qui n'est qu'une proposition, et non une recommandation du W3C. Je suis pour attendre que le draft devienne une recommandation avant de proposer quoi que ce soit, sinon on aura l'air malins si la spécification change radicalement (si par exemple il est décidé que le balisage peut s'appliquer aux titres)... Je partage également les craintes sur la complexification du code wiki. Pwet-pwet · (discuter) 22 juillet 2011 à 11:42 (CEST)

    Seul le format HTML5 a en effet été cité dans le texte de la PDD, pour ne pas entrer dans des questions normatives trop pointues. Mais cet élément est déjà défini dans le format HTML4.01 et par suite XHTML1.0 qui constituent la référence actuelle du code produit par Mediawiki. D'autre part, sans entrer ici dans des explications pour le coup vraiment très techniques, dfn fait partie des éléments de HTML5 qui sont acquis et qui ne relèvent pas des travaux actuellement en cours pour finaliser ce draft au W3C. Enfin, si cela peut rassurer : la prise en compte de l'élément dfn par MediaWiki n'aurait pas eu lieu s'il y avait eu un doute sur ce point : l'équipe de développement de MediaWiki n'est (à juste titre) pas particulièrement réputée pour son aventurisme . Cordialement, --Lgd (d) 22 juillet 2011 à 11:59 (CEST)

    Ok, merci de ces précisions. Cela dit, ma remarque sur la complexification du code tient toujours. Sans compter que ce balisage n'est pas toujours applicable à des articles d'encyclopédie : les introductions de Guerre d'Irak ou de Flottille de la Liberté II ne sont pas des définitions, par exemple. Ça va demander beaucoup de corrections manuelles... En plus les moteurs de recherche se passent déjà très bien de ce balisage : [2]. Bref, complexification du code, beaucoup de corrections manuelles sans doute nécessaires, utilité pas évidente... il me semble que les inconvénients dépassent les avantages. Pwet-pwet · (discuter) 22 juillet 2011 à 12:52 (CEST)

    Pour la question de la complexité de la syntaxe, c'est l'un des point clés de la question et la raison d'être du passage en PDD, en effet. Les moteurs de recherche, disons que c'est un peu plus compliqué : ils ne demandent qu'à profiter d'un balisage standard plus précis (et ils ne sont pas la seule raison d'être de cette proposition). Enfin, n'hésite pas le cas échéant à signaler sur Utilisateur:Lgd/Déploiement dfn (emplacement et titre temporaire) les cas qui devront être traités spécifiquement si c'est appliqué, ce sera délicat à l'évidence et toutes les infos seront utiles si cela se fait. Cordialement, --Lgd (d) 22 juillet 2011 à 13:05 (CEST)

22. Contre Encore un peu plus de complication. Addacat (d) 22 juillet 2011 à 16:11 (CEST)
23. Contre Complication inutile qui va contribuer à décourager un peu plus les nouveaux contributeurs. --Chouca 22 juillet 2011 à 21:17 (CEST).
24. Contre La syntaxe wiki est déjà assez complexe notamment pour les débutants. --Superjuju10 ^{Auboisement à votre écoute} 23 juillet 2011 à 11:28 (CEST)
25. Contre. Bien qu’avec regret, et en souhaitant que ça ne décourage pas ceux qui cherchent à faire progresser les choses (qu’il faut de toute façon remercier de faire des propositions). Mais, puisque Google indexe en s'appuyant sur le titre de l’article, comme le rappelle supra la section « Google define, un exemple concret », ça me semble amplement suffisant. Après lecture (assez consciencieuse) des débats, l’intérêt d'affiner encore les réponses des recherches faites via les moteurs de recherche ne me paraît pas contrebalancer l’inconvénient de perdre des contributeurs qui ne parlent pas les nouvelles langues informatiques. Car il faut, à mon sens, être bien sûr de soi et bien peu respectueux du travail d'autrui pour entrer avec ses gros sabots dans la fenêtre d’édition d’un texte dont on ne comprend pas du tout comment il a été composé, au risque d’exploser, par ignorance du code, toute cette belle ordonnance de balises et modèles, chevrons et parenthèses, infoboxes, modèles ouvrages et autres tableaux, bien pratiques en ce qu'ils évitent de faire des phrases mais peu propices à la modification enthousiaste de l’encyclopédiste néophyte. Dans quelques temps, on y viendra j’espère, car on peut quand même escompter que la curiosité intellectuelle des érudits leur fasse sauter le pas et apprendre ce nouveau langage. Bon, tl;nr, j’imagine, tant pis. --Wikinade (d) 23 juillet 2011 à 14:15 (CEST)
26. Contre encore une complication de la syntaxe. WP va devenir un site de contribution d'experts informatiques, alors qu'il nous faut au contraire encourager les nouvelles volontés. Matpib (discuter) 23 juillet 2011 à 16:25 (CEST)
27. Contre Je pense qu'au stade où en est wikipédia, il vaut mieux faciliter l'édition que la consultation, particulièrement un truc qui concerne tous les articles, et notamment les ébauches.Hadrien (causer) 24 juillet 2011 à 13:54 (CEST)
28. Contre Enchantée au départ, puis relativement contre en lisant plusieurs avis : usine à gaz en perspective, complications évidentes pour les nouveaux inscrits (il m'a fallu déjà du temps pour comprendre les "small", "br", "s", etc. Là, c'est trop) et enfin déni de la grande variété des introductions (on se base sur une introduction au titre simple, alors que pour nombre d'articles aux titres complexes, les bots risquent de se retrouver perdus et de saccager l'ensemble : travail pour nous autres contributeurs humains en perspective). Si une proposition plus simple venait à apparaître, je m'y rallierai, car le principe d'accessibilité depuis Google me plaît assez. Cordialement, Celette (d) 25 juillet 2011 à 10:28 (CEST)
29. Contre L'intérêt me paraît presque nul : dans la très grande majorité des cas, les trois apostrophes autour de l'objet défini sont les seules du résumé introductif ; les moteurs de recherche peuvent très bien utiliser la présence de ces apostrophes, aussi bien qu'une balise dfn. C'est donc aux moteurs de recherche d'affiner leurs algorithmes, ajouter une balise ne servirait pratiquement à rien et complexifie encore l'édition. --Pethrus (d) 25 juillet 2011 à 18:30 (CEST)

    Les moteurs de recherche ne le feront pas. Il est illusoire d’espérer qu’ils vont commencer à appliquer un traitement privilégié d’analyse du code HTML pour quelque site que ce soit, Wikipédia ou pas. Litlok (m'écrire) 25 juillet 2011 à 22:10 (CEST)

    Il est plus que probable qu'il font déjà des "traitements spécifiques" pour Wikipédia. --Pethrus (d) 26 juillet 2011 à 21:00 (CEST)

30. Nécessaire peut-être, mais hélas inadaptée aux nouveaux. On multiplie les étages et les difficultés. Trizek ^bla 26 juillet 2011 à 10:48 (CEST)
31. Contre. Inutile, la syntaxe actuelle fonctionne et est admise par tous. Une usine à gaz supplémentaire et du temps de perdu.-- LPLT ^[discu] 26 juillet 2011 à 21:32 (CEST)
32. Contre Je ne comprends pas l'intérêt du balisage dfn car dans la très forte majorité des cas, cette balise va s'appliquer à un contenu qui est identique au titre de l'article. J'ai l'impression que c'est être puriste pour être puriste, normaliser pour normaliser. Si je n'ai aucun soucis à utiliser "dfn" si la communauté le décide, je suis plus que dubitatif sur tout le temps et l'énergie consacré à quelque chose dont les conséquences pratiques m'échappent. --Laurent N. ^[D] 26 juillet 2011 à 23:10 (CEST)
33. complexification non justifiable pour un gain incompréhensible. Si un besoin se fait ressentir de distinguer dans une intro le mot clef, la syntaxe actuelle nous le permet à 90% (voir plus), sans effort supplémentaire. Je pense que cela doit se faire de manière innée dans le moteur de CMS et non en rajoutant des tags qui rendent l'accès à la contribution de pire en pire. De plus l'introduction supplémentaire de code type XML est vraiment rébarbatif pour tous les non initiés à l'ordinateur (et pourtant je suis perso fan de cette forme de langage). Loreleil ^[d-c] 26 juillet 2011 à 23:29 (CEST)

    pour une présentation sur les moteurs de recherche j'avais eu à étudier la question : dans les plus connus on retrouve quasiment systématiquement un parsing partiel du texte formaté à la "wiki" et l'introduction est d'ailleurs particulièrement ciblé (autant par les moteurs "normaux" que les moteurs utilisant des analyses sémantiques "approchés" (vectorielles)). Wikipédia est une des bonnes sources pour eux pour compléter les analyses de "mots amis" dans une approche "plus naturelle" que les dictionnaires. Donc je plusois Pethrus sur le fait que le traitement spécifique existe déjà et ils nous en remercient bien. Loreleil ^[d-c] 26 juillet 2011 à 23:45 (CEST)

    Un exemple immédiat montre que l'exploitation actuelle du code HTML (et non de la syntaxe wiki, encore une fois) par Google est défectueuse dans le cas des définitions: :define:Histoire de France. Justement parce que Google en est réduit, faute du balisage HTML approprié, à indexer grossièrement le titre de l'article associé au premier paragraphe trouvé. Un autre exemple montre que l'introduction n'est pas spécifiquement ciblée, mais qu'il s'agit simplement d'une récupération du tout contenu contenu textuel (paragraphe, liste etc.) placé en début de contenu : :define:2007 en littérature (dans ce cas, la recherche de définition est absurde, mais l'exemple est révélateur de ce que fait le bot d'indexation). D'autre part, comme expliqué à propos de l'intervention des bots, le mécanisme n'est pas automatisable : la substitution systématique par Mediawiki produirait des résultats aberrants. Cordialement, --Lgd (d) 27 juillet 2011 à 08:02 (CEST)

    Comme indiqué cela couvre potentiellement déjà plus de 90% du besoin, c'est pourquoi l'ajout du tag est parfaitement inutile => ajout de complexité pour un gain négligeable. Et ce n'est pas ce FAMEUX SUPER TAG qui changera quoi que ce soit au problème de 2007 en littérature : il suffit de respecter le principe de résumé introductif. De même pour Histoire de France, le résumé introductif ni le reste de contenu introduit de quoi on va parler, l'actuel intro est un résumé du reste. Donc tu ne résous aucun problème "complexe" en rajoutant ce tag parfaitement inutile : au lieu d'utiliser la technique pour résoudre nos manques, il suffit de corriger le problème de formalisme structurelle, qui permet de couvrir tous les cas.Loreleil ^[d-c] 27 juillet 2011 à 10:08 (CEST)

34. Contre Je n'arrive déjà pas à lire les dates en format {{date|...}} sur mon smartphone dans les paragraphes introductifs, alors je crains de ne même plus pouvoir lire le titre avec le balisage proposé! La Reine d'Angleterre (d) 27 juillet 2011 à 12:12 (CEST)

    le problème des dates est bien réel, mais il n'a d'une part pas de rapport avec le sujet de cette prise de décision (ce n'est pas parce qu'il y a un modèle qu'un contenu ne sera pas affiché sur un smartphone), et il n'a d'autre part apparemment pas encore été traité côté développement (il me semble que ce n'est pas ici que nous pouvons y faire quelque-chose). Cordialement, --Lgd (d) 27 juillet 2011 à 12:18 (CEST)

35. Contre Une syntaxe supplémentaire pour pas grand chose. De plus, certaines introduction ont plusieurs paragraphes: comment le système gère-t-il cela ? De plus cela ne concerne en rien l'amélioration de Wikipédia, mais juste l'accès par des outils informatiques externes. Snipre (d) 27 juillet 2011 à 17:59 (CEST)

    Seul le premier paragraphe introductif, qui est censé définir le sujet, est pris en compte.

    Certes, cela s'adresse aux outils, mais les lecteurs de Wikipédia n'y accèdent qu'à travers des outils (que ce soient les navigateurs, les moteurs de recherche, etc.) : la qualité de l'information et de l'accès à l'information dépendent aussi de la qualité du balisage sémantique destiné aux outils . Cordialement, --Lgd (d) 28 juillet 2011 à 09:05 (CEST)

36. Contre Tel que présenté, j'estime que c'est plutôt une limitation des outils de recherche (moteurs) qui devrait être résolue par Traitement automatique du langage naturel. Et j'ai plutôt l'impression que c'est déjà le cas d'ailleurs. Xiawi (d) 30 juillet 2011 à 18:27 (CEST)

    C'est vrai, mais ce marquage ne vise pas spécifiquement les moteurs de recherche. Le traitement du langage naturel est un domaine très complexe, où il n'existe pas de « solution » et donc lourd à mettre en place et sans fiabilité garantie. C'est inimaginable pour 99 % des outils susceptibles d'exploiter la balise dfn (ce qui inclut certains moteurs de recherche — à commencer par le moteur interne de Wikipédia). Il s'agit ici de remplacer un marquage déjà existant, mais vide de sens (une mise en gras) par un marquage sémantique. Amicalement — Arkanosis ^✉ 30 juillet 2011 à 20:11 (CEST)

37. Contre — N ^[66] 30 juillet 2011 à 23:08 (CEST)
38. Contre Encore une amélioration userunfriendly. Ne mordez pas les nouveaux, compliquez leur suffisamment la tache. Ο Κολυμβητής (You know my name) 1 août 2011 à 18:18 (CEST)
39. Totalement Contre Pour avoir fait des initiations à l'édition de Wikipédia, je peux dire que la syntaxe actuelle rebute déjà des personnes motivées, désireuses d'apprendre. Rajouter une couche de complexité en visant paradoxalement un gain d'accessibilité me paraît contre-productif, voire même dangereux pour l'amélioration du contenu de Wikipédia car cela va continuer à écarter les "non-geeks". o2 ^[Allo?] 3 août 2011 à 10:36 (CEST) Et +1 au passage pour l'argumentation de Loreleil ci-dessus.
40. Contre Pour moi, c'est la goutte qui fait déborder le vase de la complexité wikipédienne, en balançant un modèle ou un tag dès la première phrase de l'article. WP n'a fait que se complexifier depuis mes débuts, dans tout ses aspects, il ne faut pas se demander pourquoi la courbe d'apprentissage est de plus en plus ardue, et qu'il y a de moins en moins de gens qui se lancent comme nouveaux contributeurs. - Boréal (:-D) 3 août 2011 à 16:08 (CEST)

    Bof, je suis assez d'accord avec ton constat, sauf que dans les articles les plus consultés la première phrase est précédée d'une infobox de trois pages. À côté de ça, la modification proposée dans cette PDD est insignifiante. Commençons par migrer les infoboxes en fin d'article. Skippy le Grand Gourou (d) 4 août 2011 à 14:29 (CEST)

41. Contre Pas convaincu de l'utilité Ben76210 (d) 3 août 2011 à 19:04 (CEST)
42. Contre La syntaxe est suffisamment compliquée pour les nouveaux utilisateurs, aucune raison de rendre cela plus compliqué avec ce genre d'ajouts. Simplifier les méthodes d'éditions devraient être une priorité et non l'inverse. - Matrix76 (d) 4 août 2011 à 21:10 (CEST)
43. Contre C'est génial dans un esprit Web Sémantique, mais c'est chiant, ça alourdi encore et encore la syntaxe des articles. N'y a-t-il pas un moyen détourné de le faire qui ne nécessiterait pas d'actions de l'utilisateur ? Exemple : parser jusqu'au premier point. Je sais, c'est pas aussi simple que ça. Argos - oO 4 août 2011 à 22:49 (CEST)
44. Contre Moche, inutile. La forme actuelle est beaucoup plus rapide à écrire Pixel ^[Yoshi] 4 août 2011 à 23:50 (CEST)
45. Contre Une exclusivité WP.fr dont on se passera volontiers. OxIxO (d) 5 août 2011 à 22:04 (CEST)
46. Contre tout ce qui complique la publication par le plus grand nombre va à l'encontre du projet de cette encyclopédie. Cette prproposition est avant tout une difficulté de plus pour le contributeur qui doit déjà passer un temps trop important à comprendre un fonctionnement chaque jour plus complexe au lieu d'être de plus en plus intuitif. Quoique (d) 6 août 2011 à 05:20 (CEST)
47. Contre comme o2. David Berardan 6 août 2011 à 17:14 (CEST)
48. Contre Zetud (d) 6 août 2011 à 23:40 (CEST)
49. Contre Et une complexification supplémentaire, d'autre part l'explication : « À vrai dire, le fait que Wikipédia s'en serve [de ce balisage] va aussi aider à consolider celui-ci » me pose problème : on utilise les contributeurs de Wp pour faire avancer d'autres projets avec lesquels ils n'ont rien à voir. --Xavier (d) 7 août 2011 à 07:49 (CEST)
50. Contre Si c’est pour le référencement, et que cette PdD est là pour mettre des dfn autour des premiers mots en gras des paragraphe, il me semble que c’est inutile, ces mots étant également les titres d’articles / sections et donc, de ce fait, déjà très bien référencés. Complication pour ne pas apporter grand chose, donc. schlum ^{=^.^=} 7 août 2011 à 18:12 (CEST)
51. Contre D'accord avec l'argument de Rémih. Si c'est juste pour faire plaisir à g***le, non merci. — Michka O. (d) 7 août 2011 à 18:26 (CEST)
52. Contre Je n'en comprend pas vraiment l'utilité, étant donné que dans ma version de Firefox, j'ai une jolie barre en haut à droite qui me permet de choisir les moteurs de recherche et que WP y est proposé au même titre que google, preuve que WP est devenu une référence. Donc on a plus besoin de faire plaisir à google puisqu'on a plus besoin de google. Ne nous compliquons pas la vie... Buisson (d) 7 août 2011 à 23:50 (CEST)
53. Contre L'intro des articles est suffisamment lourde en syntaxe, mais ça n’empêche pas d'ajouter ce modèle sous une autre forme, invisible, en bas d'article j'imagine. Frakir 8 août 2011 à 00:07 (CEST)
54. Contre ; intérêt limité et recherche d'une complexité inutile (entre ça et les modèles bizarroïdes illisibles…) Necrid Master (d) 8 août 2011 à 01:45 (CEST)
55. Contre ; marre des modèles, quand ils ne sont pas top à écrire comme à lire dans la fenêtre d'édition... Et tout ça pour faciliter la tâche des brouteurs ? --Warp3 (d) 8 août 2011 à 04:02 (CEST)

    Une réponse unique à plusieurs commentaires similaires. Pas uniquement. Il s’agit de faire en sorte que le code HTML des articles soit plus facilement réutilisables par des applications et des outils -cela inclut les moteurs de recherche, des outils de consultation des personnes en situation de handicap, mais aussi tous les services tiers désireux de réutiliser (conformément à la licence ) le contenu de Wikipédia pour l’intégrer à leurs propres outils informatiques. En fait, tout ce que permet le fait d’exploiter au mieux les possibilités d’un langage de structuration de l’information comme l'est le HTML. Litlok (m'écrire) 8 août 2011 à 07:47 (CEST)

56. Contre après hésitation. Les arguments ayant fait pencher la balance en faveur du contre sont : 1. C'est un changement qui concerne une des bases de la rédaction ; 2. Ce changement complique un peu plus les choses qu'il ne les simplifie ; 3. Toute complexification même légère des opérations élémentaires de wikipédia ajoute de la difficulté à la démarche de contribution. Dans le cas où cette mesure serait toutefois adoptée, j'espère qu'on préférera un terme comme {{entrée|...}} (car c'est bien d'une entrée qu'il s'agit non ?) plutôt que le barbare <dfn>...</dfn> ou l'alambiqué {{terme défini}}. Ça me semblerait déjà plus clair et concis (et donc acceptable) ainsi. Enfin une requête, étant nouveau contributeur, je ne suis pas familiarisé avec le système de vote et je saurais gré quiconque m'expliquera l'origine des modalités du vote (60%) - j'ai cherché mais en vain. --Laurent Verset (d) 10 août 2011 à 00:19 (CEST)

    Il n'y a pas d'origine aux modalités de vote. C'est un peu d'habitude, beaucoup de consensus : le seuil est modulé en fonction de l'impact général sur le projet. Plus le changement apporté est important et surtout aux conséquences incertaines (plus la discussion préalable a été "chaude"), plus le seuil est élevé. Il n'y a pas de problème de ce côté maintenant. Bonne continuation. TIGHervé 10 août 2011 à 11:13 (CEST)

    pas de problème ? actuellement il y a moins de 56% en faveur de la proposition, le moins que l'on puisse dire c'est qu'il n'y a pas de consensus en faveur de la proposition. Dingy (d) 10 août 2011 à 17:36 (CEST)

    C'est justement le rôle d'une PDD : savoir s'il y aura plus de X % de gens pour, ou moins. Et adopter ou non selon ce résultat. Cordialement, --Lgd (d) 10 août 2011 à 17:39 (CEST)

    ce n'est pas une réponse tant que X n'est pas défini. Dans un organisme international que je connais bien et dont les décisions sont basées sur le consensus X= 2/3 soit 66% pour que le projet soit accepté. Dingy (d) 11 août 2011 à 17:34 (CEST)

57. Contre trop compliqué pour les nouveaux Binousours (d) 10 août 2011 à 17:13 (CEST)

    Au risque de me répéter : les très nouveaux de toute manière ne mettent pas en gras. Et une infobox, à mon humble avis, est beaucoup plus compliquée… Litlok (m'écrire) 10 août 2011 à 17:26 (CEST)

    oui, mais les nouveaux pourraient avoir envie d'éditer une page déjà existante. Et si ils voient ( en plus de l'infobox, je suis d'accord) des horreurs entre balises, cela risque peut-être de leur faire peur.

58. Pour l'instant contre. Pour moi, compliquer le code source des articles c'est aller dans le mauvais sens. Je plaide coupable, je mets aussi des modèles partout, genre {{unité}} etc. Pour parfois montrer le code source à des gens que j'aimerai faire contribuer et voir leur désarroi je suis vraiment très réticent à appuyer une complexification de la chose. Dans un monde parfait, j'aimerai qu'on mette le paquet sur une interface d'édition simple : infobox, bandeau de portail, catégories et interwikis hors de l'interface classique d'édition et ensuite le machin WYSIWYG pour le code texte. Une fois qu'on a ça, on peut rajouter toutes les saloperies invisibles au contributeur. Ludo ^{Bureau des réclamations} 11 août 2011 à 15:26 (CEST)
59. Contre En accord avec pas mal d'avis ci-dessus, une complication inutile de la syntaxe qui apparaitrait encore plus rébarbative aux nouveaux. --Cordialement. -- Coyote du 86 ^{[Me contacter]} 11 août 2011 à 18:38 (CEST)

    @Coyote et quelques autres : au sujet de cette complication pour les nouveaux, s'agit-il de l'écriture du wikitexte ou de sa compréhension ? Si c'est l'écriture, l'absence de balise sur un article créé par un nouveau n'est pas dramatique, puisque l'article sera (le plus souvent) juste un ébauche. Dès que l'article aura été vu et revu par plusieurs contributeurs, il y en aura bien un pour mettre la balise ou le modèle. Si c'est la compréhension, quelque chose comme {{Sujet | blabla}} me paraît aussi compréhensible que '''blabla''' et finalement plus explicite.--Juju2004 (d) 11 août 2011 à 19:02 (CEST)

    Mouais, je pense surtout que c'est rajouter une balise peu utile. Parce que si on accepte ça, pourquoi ne pas dire que ''blabla'' , c'est bof pour l'italique alors autant mettre un nouveau truc, et ainsi de suite ... --Cordialement. -- Coyote du 86 ^{[Me contacter]} 11 août 2011 à 19:19 (CEST)

60. Plutôt contre. Il me semble précipité d'ajouter une nouvelle couche de complexité pour un résultat nul puisque pour l'instant non exploité ou relativement peu. Je ne suis pas trop d'accord non plus pour que fr; serve de test grandeur nature. — Rhadamante 11 août 2011 à 20:52 (CEST)
61. Contre pourquoi faire compliquer lorsque l'on peut faire simple --Lomita (d) 11 août 2011 à 22:03 (CEST)
62. Contre et Contre son utilisation pure et simple. Après on s'étonne qu'on perd des contributeurs, qu'on se batte pour savoir si les références se mettent avant ou après les annexes/voir aussi/pour approfondir, qu'on en vienne à faire des sondages/prises de décisions pour savoir si ce que Y a fait est mieux que ce que A a fait, qu'on se retrouve avec des articles qui ressemblent à des album photos. Ça va encore être un sujet à se taper dessus. TiboF® 12 août 2011 à 00:41 (CEST)

    bien d'accord, il faut supprimer tous ces gadgets qui n'apportent rien aux articles et permettent seulement à quelques geeks de corriger des articles avec la nième version de modèles qu'il faudrait mettre à la place de la version n-1 que l'on trouve dans l'immense majorité des articles, qui ne pose aucun problème et qui par sa simplicité est à la portée des nouveaux contributeurs. La perte de contributeurs, y compris d'anciens, n'est pas une invention de journalistes, il y a un réél problème et cette PDD est l'occasion de manifester un désaccord avec l'évolution de la syntaxe. Dingy (d) 12 août 2011 à 06:07 (CEST)

    Pour un futur projet de simplification de la syntaxe qui serait en effet manifestement d'actualité, tu es le bienvenu pour proposer plus précisément des « gadgets » à supprimer (pour le moment, sur ma page discussion par exemple). --Lgd (d) 12 août 2011 à 06:52 (CEST)

    OK je te donnerai un exemple récent d'article, que je n'ai pas écrit mais rédigé par un contributeur confirmé, qui a été largement wikifié. Dingy (d) 12 août 2011 à 08:10 (CEST)

63. Contre tout usage, car les phrases d'introduction sont rarement des définitions, mais des descriptions ou des inclusions (exemple :Baudricourt est une commune française, située dans le département des Vosges et la région Lorraine; comme 514 autres....) --Dreoven (d) 12 août 2011 à 19:06 (CEST)
64. Sebleouf (d) 13 août 2011 à 21:26 (CEST)
65. Contre. Complexification de la syntaxe et dans la majorité des cas, le balisage ne ferait que reprendre le titre de l'article. Les3corbiers (d) 14 août 2011 à 04:38 (CEST)
66. Contre Parce que Moez a voté deux fois pour (34 et 71) et que c'est pas bien (non je plaisante mais il faudrait corriger cette erreur de double vote). Olyvar (d) 15 août 2011 à 12:22 (CEST)

     Fait. Tu peux changer ton vote. TIGHervé 15 août 2011 à 14:11 (CEST)

67. Contre. N'apporte pas grand chose par rapport à la mise en gras, et complique la syntaxe (beaucoup plus simple de faire une mise en gros via l'onglet graphique, tandis qu'ici il va falloir chipoter pour trouver les bons caractères). Cordialement, Piston (discuter) 15 août 2011 à 22:46 (CEST).

Neutre

1. mon coeur balance, je pense que l'idée est louable, mais la balance complexité/apport me semble équilibré et je ne sais vers quel côté pencher. Hatonjan (d) 20 juillet 2011 à 16:38 (CEST)
2.  Neutre Un peu idem Hatonjan, en rajoutant que je ne suis pas spécialement opposé au changement, mais ne sachant pas si cela sera véritablement utile ou pas je préfère ne pas prendre position (et puis si ça se fait on verra cette question de l'utilité à l'usage, sans-doute..) --Floflo (d) 20 juillet 2011 à 16:44 (CEST)
3.  Neutre. Semble plutôt utile, mais complexifie trop. --LeJC ^{[Remixez-moi]} 21 juillet 2011 à 08:35 (CEST)
4. J'en connais qui vont me passer un savon pour avoir voté dans cette section. :D Autant je suis convaincu de l'intérêt et même de la nécessité, autant son déploiement dans un fratras de code wiki confus (en dépit des efforts faits pour cadrer dfn à l'intro) me convainc beaucoup moins. Sachant qu'on aura probablement jamais de meilleure issue que celle-ci, je vote neutre en espérant que la PDD passe. Mais je ne peux me résoudre à voter pour. Dodoïste ^{[ dring-dring ]} 22 juillet 2011 à 12:11 (CEST)
5.  Neutre pour le moment, au moins. Cette mesure un peu compliquée pour les contributeurs rencontre beaucoup d'oppositions motivées avec bonne foi sur un point qui demande plus d'attention (l'évolution du résultat depuis les tous premiers jours supposés souvent décisif est révélatrice : après avoir culminé à une toute petite majorité, ce résultat ne cesse de s'éroder). Le souci évoqué est particulièrement délicat : c'est celui de la complexité croissante de l'édition de Wikipédia. C'est un motif erroné dans ce cas précis, mais le malentendu est compréhensible et sera difficile à dissiper. Manifestement, dans un système où ces décisions sont laissées à l'appréciation de tous, cette modification ne rencontre pas un besoin suffisant mais se heurte plutôt à un autre souci auquel remédier d'abord.
   Peut-être serait-il finalement préférable de commencer par traiter ce problème des excès d'autres syntaxes compliquant l'édition, avec des résultats très évidemment perceptibles par les contributeurs, avant de pouvoir proposer des améliorations de ce type.
   Enfin, il n'y a rien de pire qu'une PDD adoptée de justesse comme celle-ci semble devoir l'être (au mieux) : entre les rancoeurs et les chicaneries qui suivent, on ne peut guère avancer. Rien ne presse, il faut aussi savoir remettre à demain ce qui ne peut être fait aujourd'hui . --Lgd (d) 24 juillet 2011 à 15:36 (CEST)

   De toute manière, cela n'empêche pas, en passant et quand l'occasion se présente, d'utiliser ce nouvel outil, tout comme on utilise déjà code... Litlok (m'écrire) 24 juillet 2011 à 16:20 (CEST)

   Il ne faut pas le dire (ce n'est pas correct), mais les réponses aux besoins échappent largement aux procédures sur Wikipédia, et sont avant tout déterminées par les usages . Cordialement, --Lgd (d) 24 juillet 2011 à 16:24 (CEST)

   Alors Lgd quoi ? La frilosité des autres est maintenant un motif d'avoir froid ? même pas d'être frileux ? Tu as lancé cette PDD dans une vision d'avant-garde et tu te ranges à 180 degrés avec les conservateurs par principe ?
   Oui « conservateurs par principe » puisque tu le dis toi-même, si l'argument allégué a un fondement indéniable, il n'est pourtant pas de poids ! Ne voir que lui est une prime à l'immobilisme, une prime à la verbosité qui croît sans cesse en au détriment de la cohérence, à l'amateurisme triomphant contre la compétence acquise, etc. Ce n'est pas la facilité de rédaction qui est en cause, contrairement à ce qui est soutenu, mais la spontanéité ! Nuance !
   Comme si, une balise de plus ou de moins pouvait avoir un impact sur tout internaute qui a vraiment « quelque chose à faire avec Wikipédia » ! Non pas l'internaute-ami tiré par la manche un dimanche après-midi pluvieux dans une sorte de poussée d'angélisme encyclopédique ; celui auquel je ne crois pas du tout au-delà de quelques contributions sceptiques... Non, le futur est d'avancer dans l'amélioration conjointe du fond et de la forme et ici c'est de se débarrasser d'une scarification digne de l'âge des cavernes (les trois ' fois deux), par un balisage, une pratique qui existe depuis des décennies déjà et aux vertus reconnues pour donner de la valeur aux mots ! Le début de l'article est bien pourtant là où il faut commencer à dire aux gens : "eh, un article n'est pas une fosse dans laquelle on décharge des mots comme on vide ses poubelles de tris sélectifs ! Vous le savez ? Si oui, vous verrez vous ne serez pas déçu ("sources"...), Non, eh bien renseignez-vous et revenez avec des apports que vous ne mettriez nulle part ailleurs, parce que nulle part ailleurs vous trouverez les exigences de qualité de Wikipédia !". Non, on ne perd pas de contributeurs, on en gagne de sérieux, ceux prêt à se coltiner la masse himalayesque des contenus informes pour en faire des textes pertinents ; et ils n'ont sûrement pas peur de repères aussi élémentaires qu'une définition.
   et ça t'apprendra à commenter les votes sans conviction finalement ! TIGHervé 24 juillet 2011 à 16:36 (CEST)

   Oui oui oui, tout cela est très vrai. Mais, à nouveau: en réalité, nous savons bien que ce n'est pas la pdd qui est essentielle, une fois l'idée lancée. Par ailleurs, je n'ai pas un âme de porte-flambeau et nul n'est irremplaçable ni même symbolique . Cordialement, --Lgd (d) 24 juillet 2011 à 16:52 (CEST)

6.  Neutre Mal à la cabeça... Je comprends l'idée, mais je suggérerais très fortement de mettre à l'oeuvre l'idée d'abord sur un échantillon d'articles sélectionnés pour voir ce que ça change, et pouvoir revenir plus facilement en arrière si nécessaire. Par ailleurs, le principe même de contraindre un rédacteur lambda à parler couramment le ouiqui et à se rappeler d'une façon ou d'une autre des dizaines de modèles et d'astuces pour aboutir à un article formaté "correctement" (si ça existe) me paraît aux antipodes des règles élémentaires de l'ergonomie. On devrait disposer d'une interface conviviale qui générerait elle-même le zigouigoui ad hoc, quelle que soit sa forme finale dont le rédacteur n'a rien à faire (comme ça, il pourrait se concentrer sur le contenu...) Mais je crains qu'alors on ne doive réécrire tout le logiciel. Bref, c'est peut-être le logiciel Wiki (me rappelle plus comment il s'appelle) qui est fondamentalement mauvais et inadapté à son objectif. Mais comme je ne suis pas un spécialiste de la question, j'ai bien conscience que mon avis de simple utilisateur n'a absolument aucune importance et que de toutes façons la décision se prendra sans moi. M'en fous. Oblomov2 (d) 27 juillet 2011 à 14:21 (CEST)

   1. C'est déjà le cas par la force des choses : Pages liées à Modèle:Terme défini ;
   2. Le rédacteur lambda n'est contraint à rien du tout : « Par la suite, un filtre peut aisément signaler la création ou la modification d'un article sans ce balisage, permettant ainsi à des wikignomes d'intervenir pour améliorer la syntaxe. Le Projet:Correction syntaxique pourrait également intégrer la détection et la correction des introductions de nouveaux articles ne faisant pas appel à dfn ou à son modèle. » ;
   3. Si, cet avis est décisif, justement . Cordialement, --Lgd (d) 27 juillet 2011 à 14:29 (CEST)

7.  Neutre Pas convaincu du tout - notamment parce que je pense à la distinction que fait Umberto Eco entre "définitions de dictionnaires" (en gros, "balisables") et "définitions d'encyclopédies" (grosso-modo "non balisables") - mais assez déstabilisé par le fait que certains utilisateurs, que je crédite d'une compréhension de ces questions sémantico-informatiques très supérieure à la mienne, y voient une amélioration importante. Alors, dans le doute... neutre. --Christophe Dioux (d) 28 juillet 2011 à 00:40 (CEST)
8.  Neutre Comme Floflo. Le changement ne me gêne pas mais bon, j'ai l'impression que le changement lui-même dans les intros fera plus de bruit que les conséquences positives qui devraient en découler. --Twilight-Brawl ^Plop 1 août 2011 à 03:06 (CEST)
9.  Neutre Je pense avant tout que c'est juste une question d'habitude, tout comme la mise en gras des mots qui définissent l'article. Gardons en tête deux choses: 1/ Wikipédia est une encyclopédie, et à ce titre chacun de ses articles est défini (brièvement) par son introduction. 2/ Wikipédia est un site internet dont les pages sont rédigées (générées) en langage xHTML, et comme dans tout langage il y a des règles à respecter, dont la mise en évidence des définitions par la balise <dfn> fait partie. Cependant, je partage l'inquiétude des utilisateurs (rédacteurs) face à cette nouvelle syntaxe qui alourdit et complexifie un peu plus le code source des articles. Mon opinion est qu'à force de vouloir tout sémantiser on finira par avoir un code source tellement complexe que 1/ les rédacteurs se feront de plus en plus rares, 2/ qu'il vaudra mieux rédiger les articles en xHTML, qui finalement est mieux adapté à la sémantique du Web. Je terminerai par souligner deux choses liées à la sémantique défendue par la balise <dfn>: 1/ ce cas de figure est encore relativement simple à traiter, mais qu'en sera-t-il de la sémantique des formules mathématiques gérées par le langage MathML (par exemple)? On va drôlement s'amuser s'il va falloir tout wikifier! 2/ la sémantique est à la mode ces temps-ci, et je comprends parfaitement, mais pour plus de crédibilité il faudrait également se pencher sur les autres problèmes liés à la sémantique dans les articles, comme par exemple la mauvaise utilisation des tableaux pour la mise en forme des pages (cf. portails), ou encore l'absence des balises <article>, <figure>, <section> ou encore <aside> (pour les taxobox et infobox), et j'en passe. --92.162.235.155 (d) 1 août 2011 à 09:59 (CEST)

   Disons que c'est une politique des petits pas : on commence par ce qui est le plus simple pour les contributeurs (justement), puis on regardera s'il est pertinent d'aller plus loin et comment (il y a en effet une limite rapide à la wikification).
   Concernant la remarque très juste sur la crédibilité : c'est un travail de longue haleine, relativement discret, mais cela fait longtemps qu'il est engagé  : la prise en compte de cite ou d'abbr, l'utilisation correcte de blockquote, de del dt dd ou encore les efforts pour que les contributeurs et les auteurs de modèle utilisent correctement les éléments de tableaux ne nécessitent simplement pas de PDD ou d'autres choses aussi voyantes...
   Enfin, pour les éléments de landmark (et autres) HTML5, le passage de mediawiki à HTML5 ne relève pas actuellement des wikipédia locales : c'est également un développement à long terme déjà engagé du côté des développeurs (cela dit, infobox et taxobox ne relèvent pas AMHA de aside, mais il est un peu tôt pour en parler Cordialement, --Lgd (d) 1 août 2011 à 10:12 (CEST)

   « politique des petits pas  » ... qui mèneront les rédacteurs à contribuer enfin comme à Citizendium --Warp3 (d) 8 août 2011 à 05:19 (CEST)

10. Si les spécialistes de l’accessibilité rendent cet ajout accessible (l'utilité compréhensible pour tous), pourquoi pas. sebjd 3 août 2011 à 22:51 (CEST)
11.  Neutre aucune raison de m'opposer aux spécialistes de l'outillage informatique, même si j'ai du mal à en comprendre la finalité, et en dépit du fait que les outils de recherche actuels comblent tout-à-fait les besoins en la matière du néophyte que je suis. Mais je ne peux me résoudre à voter Pour car cela complexifie encore un peu plus le mode édition, ce qui peut être rebutant pour les nouveaux contributeurs. Difficile de savoir de quel côté doit pencher la balance. --Priper (d) 5 août 2011 à 18:24 (CEST)
12. Indifférent. Pour rappel, sur fr.wikipedia.org, ou bien ça t'amuse et tu le fais, ou bien c'est une corvée et tu ne le fais pas. Donc. Je ne m'embarrasserai pas plus demain à utiliser ces balises si elles sont disponibles que je m'embarrasse aujourd'hui avec le code. J'utilise pour l'essentiel les boutons de la bonne vieille barre d'outils de 2006. Tant que ces balises ne seront pas dans cette barre d'outils, je ne les insérerai à la mano que pour les sujets pour lesquels je voudrai délibérément améliorer le référencement, autrement dit, pour les entreprises sur lesquelles je prends plaisir à diffuser des connaissances sur le site fr.wikipedia.org. Pour les autres sujets, si le gras ne convient plus, je ne mettrai plus rien et je laisserai à ceux qui tiennent à la syntaxe le soin de se palucher l'insertion des balises. Cordialement. --Utilisateur:Brunodesacacias 6 août 2011 à 18:37 (CEST)

Question B. En cas d'adoption du balisage, quelle forme préféreriez-vous ?

Un seul vote est possible. La forme qui emportera le plus de suffrages sera celle utilisée (En cas d'égalité entre le modèle et le balisage, ils pourront être indifféremment utilisés).

Préférence pour la forme <dfn>...</dfn>

1. Udufruduhu (d) 20 juillet 2011 à 01:21 (CEST)

   Pour Totodu74 (devesar…) 20 juillet 2011 à 01:23 (CEST) étant donné le paramétrage et l'italisation possible grâce au modèle (merci Chandres ^^)

2. On utilise bien <ref>...</ref>, pourquoi pas <dfn>...</dfn> et plus court que {{Terme défini|...}}--'toff ^[discut.] 20 juillet 2011 à 05:13 (CEST)
3. --TaraO (d) 20 juillet 2011 à 07:34 (CEST)
4. Ascaron ¿! 20 juillet 2011 à 07:48 (CEST)

   Pour comme toff, de plus je trouve inutile de faire appel à des modèles lorsqu'il n'y a aucun paramétrage.--Chandres (✉) 20 juillet 2011 à 09:24 (CEST)

   Pour info, il existe un paramètre optionnel pour préciser la langue et utiliser de manière couplée et transparente {{lang}} dans le cas de termes définis dans une autre langue. Udufruduhu (d) 20 juillet 2011 à 10:04 (CEST)

   oups :-D cela veut donc dire que l'adoption de ce modèle simplifierait l'édition des milliers de pages de description d’espèce vivante en incluant en 1 seul modèle et la mise en forme et la langue.--Chandres (✉) 20 juillet 2011 à 10:31 (CEST)

   Actuellement non, mais ça peut et ça devra très simplement le faire (si le paramètre de langue est renseigné, le modèle peut automatiquement mettre en italique) Mais pourquoi on a pas percuté avant de lancer la PDD ? Pourquoi ? Hein ? Comme quoi, il ne faut pas tout figer dans la PDD et reporter les détails techniques dans le modèle et la page d'aide est avisé, ouf . Cordialement, --Lgd (d) 20 juillet 2011 à 10:57 (CEST)

5. Pour car cette forme fait partie de la famille des balises XML, avec balise ouvrante-contenu-balise fermante, format de balise mondialement accepté depuis plus de 10 ans et facile à analyser pour les parsers. Le format avec double accolade serait plus lourd; et le texte "terme défini" me semble enigmatique. mb2011 (d) 20 juillet 2011 à 10:14 (CEST)
6. Pour --Benj05 (d) 20 juillet 2011 à 10:39 (CEST)
7. Pour je penchais pour le modèle au départ, mais <dfn lang="...">...</dfn> étant correct, cette solution me semble la meilleure Peter17 (d) 20 juillet 2011 à 13:24 (CEST)
8. Je suis pour que les deux formes puissent être utilisées. Pwet-pwet · (discuter) 22 juillet 2011 à 11:53 (CEST)
9.  Neutre + 1 avec Pwet-pwet --Indeed ^{[knock-knock]} 22 juillet 2011 à 12:57 (CEST)
10. Pour Gérard (d) 22 juillet 2011 à 22:06 (CEST)
11. Pour : plus court, pas plus dur à comprendre, et je pense qu'un modèle alourdit beaucoup plus la lecture qu'une balise en en plus d'être plus complexe pour les nouveaux arrivants… Cordialement --Pic-Sou (d) 23 juillet 2011 à 16:26 (CEST)
12. Pour et toujours idem Pic-Sou. D'autant que "terme défini", ça ne veut rien dire... --Égoïté (d) 24 juillet 2011 à 15:20 (CEST)
13.  Neutre comme <references> et {{references}} -- Xfigpower (pssst) 25 juillet 2011 à 17:40 (CEST)
14. Pour facile à utiliser--Remy34 (d) 26 juillet 2011 à 09:19 (CEST)
15. Pour. Plus cour et pas plus dur. Il y a déjà <ref>, alors pourquoi pas <dfn> qui n’est pas plus abscons ? Tpt (d) 28 juillet 2011 à 11:23 (CEST)
16. Pour : beaucoup moins laid. Iorek (d) 29 juillet 2011 à 18:27 (CEST)
17. Pour Plus rapide à taper... ;) Rebmat (d) 4 août 2011 à 14:10 (CEST)
18. Pour Simple, rapide, plus facile à utiliser Tsunami330 ^[blabla] 6 août 2011 à 17:56 (CEST)
19. Pour Je préfère encore un tag simple qu’un modèle lourd. schlum ^{=^.^=} 7 août 2011 à 18:13 (CEST)
20. Pour. Plus c'est simple, plus c'est court, meilleur c'est ! ref -> référence, dfn -> définition (de terme). Pas compliqué ! --Warp3 (d) 8 août 2011 à 04:21 (CEST)
21. Pour Zakke (d) 12 août 2011 à 00:31 (CEST)

Préférence pour le modèle {{Terme défini|...}}

1. Il me semble préférable de limiter au maximum le code html pour favoriser les modèles et le code wiki. --Hercule ^Discuter 20 juillet 2011 à 01:38 (CEST)
2. même avis que Hercule (si création de redirections permettant de donner des alias plus courts comme {{def}} par exemple). – Bloody-libu (ö¿ô) 20 juillet 2011 à 01:50 (CEST)
3. En français, c'est mieux. --Nouill 20 juillet 2011 à 03:22 (CEST)
4. Avec des redirects possible comme {{def}} par exemple Mith avec une signature pourrie sans image pour ne pas faire mal aux yeux de certains (What ? You're talkin' to me ?) - Angers, le 20 juillet 2011 à 07:11 (CEST)
5. Sardur - allo ? 20 juillet 2011 à 07:23 (CEST)
6. Je ne vois que le potentiel. TIGHervé 20 juillet 2011 à 08:50 (CEST)
7. Moins de technique, plus de français. Rémi ✉ 20 juillet 2011 à 08:59 (CEST)
8. MicroCitron ^{un souci ?} 20 juillet 2011 à 09:01 (CEST)
9. Une page se rédie en code wiki, pas en HTML. Kelam (Qu'est-ce que c'est ?) 20 juillet 2011 à 10:15 (CEST)
10. Pour, bien qu'ayant une préférence pour un intitulé plus court ({{lien}} {{sujet}}, ou {{def}}...) --MGuf (d) 20 juillet 2011 à 10:28 (CEST) (edit MGuf22 juillet 2011 à 21:24 (CEST))
11. Dans cette hypothèse, l'approche « modèle » me semblerait préférable à l'approche Html. --Agamitsudo (d) 20 juillet 2011 à 10:29 (CEST)
12. Comme Hercule, en plus le modèle pourrait permettre de gérer la langue (et donc d'enlever {{lang}} et de garder la même "complexité" de code sur un paquet d'articles). Moyg hop 20 juillet 2011 à 11:04 (CEST)
13. Pour la possibilité qu'on se laisse de modifier le comportement, d'ajouter des options… Mais par pitié, choisir un nom ou un autre, n'importe lequel, mais n'en garder qu'un ! Avoir plusieurs façons de faire la même chose, ça :
    1. complexifie encore plus l'accès aux nouveaux qui doivent assimiler l'équivalence entre les différents noms possibles ;
    2. sera fatalement un motif de guerre d'éditions entre contributeurs qui n'ont rien de mieux à faire. — Arkanosis ^✉ 20 juillet 2011 à 11:30 (CEST)

       Oui, d'accord, mais en choisir un court ! (mais c'est trop tard, on est partis sur {{Terme défini|...}}). --MGuf (d) 20 juillet 2011 à 11:42 (CEST)

    Si il y a plusieurs modèles, ce seront des redirects, donc le modèle principal (donc pas en redirect) sera prioritaire, et donc les guerres d'éditions n'auront pas lieu d'être, ou seront stupides. Ce n'est pas le premier modèle avec des redirects. Mith avec une signature pourrie sans image pour ne pas faire mal aux yeux de certains (What ? You're talkin' to me ?) - Angers, le 20 juillet 2011 à 12:37 (CEST)

14. Pour tendance  Neutre Vigneron * ^discut. 20 juillet 2011 à 11:36 (CEST)
15. Pour Bibi Saint-Pol (sprechen) 20 juillet 2011 à 13:38 (CEST)
16. Pour le modèle est souple, il permet de gérer la langue, et si demain on veut un rendu autre que le gras, ce sera centralisé dans le modèle. Kertraon (d) 20 juillet 2011 à 16:15 (CEST)
17. Pour Le paramètre lang incorporé et possiblement l'italique me séduisent un peu, mais je serais pas contre un {{def}} ou un {{dfn}} :) Totodu74 (devesar…) 20 juillet 2011 à 16:19 (CEST)
18. Pour Préférence pour l'utilisation d'un modèle, je pense que la syntaxe sera moins surprenante. Par contre, le nom {{terme défini}} est trop long, il faut disposer d'un redirect comme par exemple {{sujet}} (plusieurs noms ont été proposés pour le redirect, mais cela n'est pas l'objet de cette pdd). od†n ↗^blah 20 juillet 2011 à 16:23 (CEST)
19. Pour, plus compréhensible je pense, et simple d'utilisation. Binabik (d) 20 juillet 2011 à 18:25 (CEST)
20. Relativement Pour. Pymouss |Parlons-en| 20 juillet 2011 à 20:38 (CEST)
21. Pour un modèle semble plus simple qu'une balise de code.--Bapti ✉ 20 juillet 2011 à 22:05 (CEST)
22. Pour Pourquoi faudrait-il du html alors qu'on peut avoir un modèle ? SM ** ようこそ ** 20 juillet 2011 à 23:05 (CEST)
23. Pour le modèle {{Sujet}} selon ƝEMOI – Je n’ai pas vu la proposition {{terme défini}} susciter un accord vraiment convainquant lors des discussions, à l’inverse de {{Sujet}}. A voté, ce 20 juillet 2011 à 23:13 (CEST).
24. Pour Je préfère nettement utiliser des modèles sur Wikipédia qu'utiliser du HTML qui est trop direct à mon goût. Mais  Neutre sur le nom du modèle : je trouve terme défini un peu long, mais je ne suis pas très pour utiliser des redirections, car avec un modèle type {{def}} ou {{dfn}}, on perd l'avantage du c'est du français. La proposition ci-dessus pour utiliser {{sujet}} me semble bonne... mais le nom est déjà utilisé ! Nadin123 [discuter] 21 juillet 2011 à 01:13 (CEST)

    On peut très facilement libérer le nom, l'actuel modèle {{sujet}} est en fait inutilisé. od†n ↗^blah 21 juillet 2011 à 16:16 (CEST)

25. Pour Je suis arrivé ici avec l'intention de voter pour la balise xml, mais les arguments présentés plus haut laissent voir le potentiel d'un modèle à la place.  Neutre sur le nom du modèle, mais je préfère un modèle court et sans espace, autant que possible. — Bouchecl (dring) 21 juillet 2011 à 06:16 (CEST)
26. Pour. Le modèle semble plus accessible. --LeJC ^{[Remixez-moi]} 21 juillet 2011 à 08:35 (CEST)
27. Pour Un modèle me semble bien préférable aussi souvent que possible à une syntaxe HTML qui étant moins claire peut rebuter plus facilement le néophyte (qui doit alors jongler entre des bouts de codes basés sur HTML et d’autres en code wiki, via des modèles). Je ne suis pas spécialement décidé concernant le nom du modèle, n’ayant pas suivi les débats préparatifs, mais {{Sujet}} est probablement un alias à considérer (alors que {{dfn}} / {{def}}, ce serait plus nébuleux / intimidant pour le néophyte). — MetalGearLiquid ^{[m’écrire]} 21 juillet 2011 à 20:59 (CEST)
28. Je suis pour que les deux formes puissent être utilisées. Pwet-pwet · (discuter) 22 juillet 2011 à 11:53 (CEST)
29. Plus verbeux, mais compréhensible à la première lecture. L'avantage n'est pas négligeable. Nous avons pleins de modèles au nom incompréhensible avant de lire toute sa doc, là nous pouvons tenter un minimum de clarté. Dodoïste ^{[ dring-dring ]} 22 juillet 2011 à 12:01 (CEST)
30. Oui mais, un grand Contre le titre du modèle proposé, {{sujet}}, ou même {{sujetitre}} serait à envisager. ~Hlm Z. [@] 22 juillet 2011 à 12:42 (CEST)
31. Paraît plus simple.--Morphypnos^[Dormir...]. 22 juillet 2011 à 22:19 (CEST)
32. Éventuellement, car je ne suis pas fan de la balise HTML. --Superjuju10 ^{Auboisement à votre écoute} 23 juillet 2011 à 11:28 (CEST)
33. A la rigueur... a au moins l'avantage d'être en mots français... Matpib (discuter) 23 juillet 2011 à 16:27 (CEST)
34. Pour Avec une préférence pour un code court, def me plaît bien. D'autant que "terme" est assez restrictif : on peut définir un acronyme, une expression... Est-ce évident que ce seraient aussi des "termes" ?--Cbyd (d) 23 juillet 2011 à 18:19 (CEST)
35. pour Mais pourquoi pas réserver la syntaxe wiki du gras au terme défini '''...''' et créer un modèle dans les cas particulier où c'est nécessaire dans le corps de l'article {{gras}} ?--pixeltoo (discuter) 23 juillet 2011 à 18:55 (CEST)

    Entre autres raisons : cette modification relèverait du développement de mediawiki, et casserait la compatibilité entre ses versions. Autant dire qu'elle n'est pas envisageable pour les développeurs. Cordialement, --Lgd (d) 23 juillet 2011 à 19:01 (CEST)

36. Pour par cohérence avec la syntaxe wiki et surtout parce que l'utilisation d'un modèle est bien plus flexible en termes d'aménagements ultérieurs (cf. par exemple les discussions un peu plus haut sur l'attribut de langue, etc.). Skippy le Grand Gourou (d) 26 juillet 2011 à 10:57 (CEST)
37. En espérant que ce changement ne sera pas adopté. En cas malheureux où cela le serait, cette syntaxe est de loin préférable.-- LPLT ^[discu] 26 juillet 2011 à 21:36 (CEST)
38. CQui (d) prefère de loin le modèle. Et n'aimerais pas que la version entre <> soit utilisée. --27 juillet 2011 à 10:06 (CEST)

    CQui (d) pour préciser, je ne pense pas que les <..></..> soient plus simple, si ce n'est pour les férus d'html, question vocabulaire, parce qu’à terme, le truc pourra être utilisé dans le corps d'un article, Terme Défini me semble plus correcte que Sujet par exemple. Étant personnellement paresseux, si on pouvait avoir des modèles qui se substent par défaut à la publication, je serais très très content, et pas seulement dans ce cas. --27 juillet 2011 à 10:36 (CEST) Precision de la precision, je souhaiterais pourvoir ecrire {{tf|titre}} et avoir a la place apres publication {{Terme défini|titre}}, voir mieux, ecrire {{tfen|title}} et avoir a la place apres publication {{Terme défini|title|lang= en}} en anglais. On en rediscute plus tard

    La seule solution en magasin est celle du bot qui effectue constamment le remplacement cosmétique, ce qui n'est pas une mobilisation de bot d'une utilité formidable puisque le jeu des redirects fait que le modèle fonctionne très bien avec son alias éventuel sans rien faire. Pour la seconde proposition l'intérêt de multiplier les alias {{tfen}}, {{tfde}}, {{tfzh-Hant}} etc. pour économiser la saisie d'un unique caractère semble un peu discutable à la marge. Cordialement, --Lgd (d) 27 juillet 2011 à 12:11 (CEST)

    « à terme, le truc pourra être utilisé dans le corps d'un article, Terme Défini me semble plus correcte que Sujet par exemple » : rien n'implique que l'on ne puisse pas utiliser deux modèles ({{Sujet}} réservé au paragraphe introductif et {{Terme défini}} en cas de définition dans le corps du texte) qui soient tous les deux traduits en HTML par une même balise <dfn> (le "truc"). Le wikitexte serait clairement balisé et donc compréhensible, même par un contributeur débutant ; le HTML serait également correctement balisé, bien qu'un peu moins précisément.--Juju2004 (d) 2 août 2011 à 16:54 (CEST)

39. Pour Martin // discuter 27 juillet 2011 à 11:15 (CEST)
40. Pour Très clair, très compréhensible, plus abordable que la balise. — Moipaulochon (@) 28 juillet 2011 à 01:13 (CEST)
41. Pour la forme d'un « modèle ». Syntaxe wiki, évolutif, inclusion de la mise en forme (gras, italique, langue). Je suis plutôt favorable à {{sujet}} que le [[:Modèle:{Terme défini|{{{Terme défini}}]] — Mirgolth 28 juillet 2011 à 12:10 (CEST)
42. Pour Trafalguar ^[✉] 28 juillet 2011 à 18:47 (CEST)
43. Plutôt pour. Le modèle est plus souple : il est facile d’ajouter une fonctionnalité pour un usage qu’on n’avait pas prévu. D’un autre côté, il est vrai qu’une syntaxe rigide permet d’éviter la tentation de transformer la chose en usine à gaz. — Pour la lisibilité du code, spécialement pour les débutants, je remercie les organisateurs d’avoir pensé à proposer un nom de modèle significatif plutôt que court, et sans alias. —C.P. 29 juillet 2011 à 10:34 (CEST)
44. Pour Juste pour le nom, ce sera déjà plus facile de s'en rappeler. --Newyork60 30 juillet 2011 à 11:02 (CEST)
45. Pour Plutôt pour un modèle {{sujet}} qui convient exactement, au niveau sémantique wiki, au premier paragraphe des articles. L'utilisateur n'a, de cette manière, pas à se soucier de la traduction HTML en <dfn>. De plus, cette traduction n'est pas figée dans le wikitexte, ce qui laisse une marge de manoeuvre (le modèle peut facilement être modifié selon les nouvelles spécifications HTML, ou par ex. pour revenir aux ''' si nécessaire). --Juju2004 (d) 1 août 2011 à 09:42 (CEST)
46. Plutôt pour Le moins pire car le plus explicite. Ο Κολυμβητής (You know my name) 1 août 2011 à 18:19 (CEST)
47. Kelson (d) 3 août 2011 à 22:46 (CEST)
48. Paraît plus compréhensible pour le non habitué éditant un article. sebjd 3 août 2011 à 22:52 (CEST)
49. Plus esthétique et plus rapide à écrire Pixel ^[Yoshi] 4 août 2011 à 23:56 (CEST)
50. --Gz260 (d) 6 août 2011 à 23:14 (CEST)
51. Olivierkeita | _{L'arbre à palabres} 10 août 2011 à 14:03 (CEST)
52. Pour Xavier Combelle (d) 10 août 2011 à 19:57 (CEST)
53. Sebleouf (d) 11 août 2011 à 22:53 (CEST)
54. Pour Plutôt favorable à {{sujet}} que le {{Terme défini}} (les titres ne comportent pas qu'un seul terme).--Rehtse (d) 12 août 2011 à 10:44 (CEST)

    A vérifier, mais il y a peu de temps, il me semble avoir compris que terme pouvait désigner un ensemble de mots. TIGHervé 15 août 2011 à 14:15 (CEST)

    Quand on utilise termes au pluriel, c'est sûr, sinon les dictionnaires que j'ai consultés n'évoquent "terme" comme ensemble de mots qu'en logique (si j'ai bien compris).Peu importe, l'initiative a peu de chance d'être poursuivie.--Rehtse (d) 15 août 2011 à 17:38 (CEST)

55. Pour. Plus simple et plus compréhensible. Les3corbiers (d) 14 août 2011 à 04:38 (CEST)
56. Pour Je préfère séparer les rôles. L'article doit être fourni dans le langage Wikipédien (avec sa propre structure, sa syntaxe, ses mots-clefs) puis transcodé pour élaborer son rendu, (X)HTM par exemple. Cette architecture améliore les possibilités de maintenance en cas de modification ultérieure, de changement de la balise à utiliser, voire permet le portage vers d'autres rendus ; Eric schreiner (d) (d) 16 août 2011 à 13:10 (CEST)