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

Livres et italiques

Question de LD transférée depuis la page de PDD.
Je soulève un problème : dans l'introduction, les titres des livres sont en italiques et entre guillemets (ex: « La Bibliothèque de Babel »), le resteraient-ils ? Avec les dfn, on aurait pour une chanson <dfn>...</dfn> et avec le modèle {{m|Terme défini|...}} ? Voir les recommandations. → LD ^{→ Réclamations ?} 3 avril 2011 à 12:24 (CEST)

Oui, c'est un point important et la proposition est à compléter là-dessus : le recours à dfn ou à son modèle n'empêchera pas de mettre en italique (ni de signaler un changement de langue pour répondre à une éventuelle question similaire) :

• <dfn>''lorem ipsum''</dfn> donne : lorem ipsum
• {{terme défini|''lorem ipsum''}} donne : lorem ipsum

Quant aux guillemets, il peuvent être renseignés à l'extérieur du balisage :

• « <dfn>lorem ipsum</dfn> » donne : « lorem ipsum »
• « {{terme défini|lorem ipsum}} » donne : « lorem ipsum »

Guillemets et italique peuvent être combinés :

• « <dfn>''lorem ipsum''</dfn> » donne : « lorem ipsum »
• « {{terme défini|''lorem ipsum''}} » donne : « lorem ipsum »

Cordialement, --Lgd (d) 3 avril 2011 à 12:42 (CEST)

Modèle avec intitulé court

Je suis favorable à l'introduction d'un modèle. Je sais que chacun pourra se faire un bouton — ou qu'un bouton sera fabriqué à l'usage de tous — pour introduire ce modèle facilement, mais je crois qu'il serait bien qu'on puisse le taper facilement "de tête", et qu'un intitulé simple est préférable, comme {{def|...}} (ou {{dfn|...}}. --MGuf (d) 3 avril 2011 à 12:43 (CEST)

+1. Il faudrait raccourcir l'intitulé du modèle en l'état. GLec (d) 3 avril 2011 à 14:01 (CEST)

+1--Rosier (d) 21 mai 2011 à 18:45 (CEST)

Plutôt favorable à rediriger {{def}} et {{dfn}} sur {{Terme défini}}. --Pic-Sou (d) 24 mai 2011 à 13:34 (CEST)

Modèle avec option "lang"

Je suis favorable à l'introduction dans le modèle d'un paramètre "lang", qui normalement est à utiliser de toutes façons en cas de titre en langue autre que le français, et qui sera plus simple à mettre que de le rajouter avec un autre modèle, comme {{def|TITRE|en}}. --MGuf (d) 3 avril 2011 à 12:43 (CEST)

ƝEMOI – Hautement favorable [à un modèle, sous un autre intitulé, et] à l’option de langue. Par contre, attention : ce doit être un raccourci simple pour {{lang}}, et ne doit pas gérer l’italique — celui-ci étant souvent à mettre lorsque le titre est en langue étrangère, mais pas systématiquement. Avis donné ce 3 avril 2011 à 13:21 (CEST).

+1 pour un modèle raccourci {{def|titre}} avec un paramètre optionnel pour la langue: {{def|titre|code}} (implicitement "fr"). Prévoir un message d'erreur sur un code langue incorrect. -- Speculos ^✉ 25 mai 2011 à 11:45 (CEST)

Remplacement automatique

Pourquoi pas en effet offrir la possibilité d'un tel balisage. Mais je soulève le problème du remplacement automatique des blabla par un <dfn>blabla</dfn>. Certains articles exposent le contenu d'un thème sans qu'il soit besoin d'en donner une définition dans le chapeau introductif comme Tourisme aux États-Unis, Culture des États-Unis, Mathématiques en Europe au XVIIe siècle, Cuisine indienne, Faune de l'Australie, et tous les Histoire de ....]. Pour ces articles, il ne me semble pas judicieux qu'un robot ajoute des balises dfn. Sera-t-on capable de produire un robot assez intelligent pour qu'il s'abstienne d'une balise dfn dans ces cas là? HB (d) 3 avril 2011 à 13:00 (CEST)

Malgré l'absence de réponse à ma question dans cette section, il semble à la lecture des autres sections que je ne sois pas la seule à relever que le terme en gras n'est pas toujours suivi d'une définition. Je souhaite que ce fait soit très clairement indiqué dans la prise de décision. Je souhaite que soit supprimé la remarque que les cas où le terme en gras ne correspond pas à une définition concerneraient des articles dont le résumé introductif serait à revoir (« ...en procédant ensuite à des corrections manuelles marginales (il s'agira surtout d'articles où le résumé introductif est par ailleurs à revoir). »).

Je signale en outre un changement unilatéral et non concerté sur la page résumé introductif. Alors que depuis septembre 2009 il était écrit

« 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, mais cela ne doit pas être systématique certains sujet n'ayant aucune définition consensuelle, et parfois aucune définition du tout »

cette mention disparait en décembre 2010 pour être remplacé par

« Une définition exhaustive n'est pas toujours possible, notamment pour les sujets complexes faisant eux-même l'objet de débats quant à ce qu'ils recouvrent (le temps, la vie, la science, la philosophie, etc.). En l'absence définition consensuelle, la première phrase pourra malgré tout proposer une formulation en termes simples permettant au lecteur de saisir le sujet de l'article »

sous couvert de modification de type typographique.

Vient maintenant cette prise de décision qui semble considérer que la première occurrence du titre est toujours une définition. Il me semble que si je vote oui pour cette prise de décision, je valide une interprétation du résumé introductif que je n'approuve pas.

Je ne souhaite pas bloquer une décision qui me semble apporter une réelle amélioration. Je souhaite donc que soit clairement écrit que le remplacement ne doit s'effectuer que dans les résumés introductifs où la première occurrence du titre correspond à une définition et qu'il est possible que la balise ne soit pas employée si le résumé introductif ne s'y prête pas. HB (d) 4 avril 2011 à 14:10 (CEST)

Il est temps qu'on se paye une prise de décision, on perd la main . Je veux dire qu'il n'y a pas de raison que cette prise de décision consolide ou au contraire menace des usages et consensus qui ont fait leurs preuves, ni qu'elle soit dramatisée et que soit perdu de vue qu'il n'y a à la base qu'un changement de codage de la page sans aucun effet immédiat pour le lecteur.
Sur la fin de ton message, si un résumé introductif ne comporte pas de définition, et qu'on employait quand même ce balisage, ce serait les robots utilisateurs qui auraient ultérieurement à gérer cette anomalie, pour tout le reste comme je viens de le rappeler, il n'y aurait aucun changement aucun effet négatif qu'un léger alourdissement du wikitexte (c'est aussi pourquoi si un modèle était utilisé pour ce balisage, il devrait rester léger pour ne pas apporter d'inconvénient par rapport à la simplicité des triple apostrophes.). Donc en résumé, il y aura des articles qui ne gagneront rien à ce changement, mais s'ils sont pourtant modifiés, ils n'en seront pas plus affectés que la masse des autres.
TIGHervé 4 avril 2011 à 21:45 (CEST)

Est ce vraiment utile ?

A la lecture de la PdD, je vois surtout que ce système va permettre d'aider des moteurs externes comme Google define. L'exemple fournit me parait louche, parce que si on met « accessibilité du web » entre balise, cela ne va pas plus donner la définition de la norme précise concernée par la redirection.

Je vois surtout que cette nouvelle manière de faire va compliquer encore un peu plus l'édition d'article pour des nouveaux contributeurs ou des contributeurs occasionnels. Le jeu en vaut il vraiment la chandelle ?

Puce Survitaminée (d) 3 avril 2011 à 13:14 (CEST)

Sur le premier point, tu touche un problème « politique », disons, évident. Mais le souci est autre et beaucoup plus simple : Google est actuellement l'outil le plus évident pour montrer aux contributeurs appelés à se prononcer sur cette PDD un exemple d'exploitation de ce balisage, et rien de plus . Il faut donc d'abord préciser très clairement qu'il ne s'agit pas ici de procéder à une sorte de prostitution honteuse de Wikipédia au service du grand capital incarné par Google, loin de là : on est réellement en train de parler de sémantique Web, à l'usage de tous les outils qui traitent le contenu de Wikipédia et pas seulement les moteurs de recherche.

Pour l'exemple fourni : si, ça va le faire. En mettant « accessibilité du web » entre balises et en le faisant de manière systématique dans tous les articles, on permet à un outil d'indexation d'utiliser un algorithme plus fin et plus pertinent que celui illustré par l'exemple actuel de Google define. Si les définitions sont indexées via dfn, les redirections pourront être traitées sans provoquer ce genre de confusion.

Pour le degré de complexité, c'est une question bien réelle. Le premier point important me semble ici ce qui est mentionné à quelques reprises dans le texte de la PDD : rien n'empêchera les contributeurs de ne pas se préoccuper de ce balisage, qui sera traitable par d'autres moyens (filtres, correction syntaxique). Le second point est celui de l'ajout d'une syntaxe supplémentaire, qu'il va falloir conserver aussi simple que possible, mais qui est le prix à payer pour un peu plus de... pertinence . --Lgd (d) 3 avril 2011 à 13:31 (CEST)

Loin de moi l'idée de dire que google c'est forcement le mal. Cela dit, je vois que nous parlons ici de « sémantique web », le problème, c'est que pour la grande majorité des contributeurs (dont moi ), cela ne veux rien dire…

Pour la complexité, je veux bien que quand on crée un article, on puisse continuer à faire comme avant, mais je penses plutôt aux contributeurs qui voudront retoucher une introduction déjà écrite (et contenant dfn). Ils doivent déjà affronter les 35 lignes de l'infobox, se faufiler entre les balises ref et jongler avec les modèles de dates. Doit on vraiment accentuer leur problème ? Tu dis que cela sera plus pertinent, si tu arrives à me l'expliquer, je suis d'accord qu'on peut faire un peu plus compliqué qu'avant. Puce Survitaminée (d) 3 avril 2011 à 13:41 (CEST)

Bien vu, « sémantique Web » peut passer pour un terme fourre-tout et mérite une explication ici.

Très concrètement, on parle de sémantique du format (ou du langage) dans lequel sont publiés les articles, c'est à dire de sémantique du format HTML. La sémantique, dans ce cas, c'est le fait qu'un contenu (une portion plus ou moins grande de l'article, éventuellement réduire à un mot) sera identifiée (balisée) de manière spécifique dans le code HTML, de sorte que cela se prêtera à une exploitation bien réelle par des outils logiciels.

Par exemple :

• baliser un bête lien, c'est faire de la sémantique : l'outil « navigateur Web » s'en sert pour qu'on puisse cliquer dessus et accéder à une autre page web ;
• baliser une abréviation, idem : cela permet au navigateur de restituer la signification de l'abréviation au survol de la souris, comme dans « et al. » par exemple ;
• baliser une liste à puces ou une liste numérotée via le code wiki « * » au lieu de faire des retours à la ligne, des <br> et des tirets : cela permet à une synthèse vocale d'annoncer le nombre d'items de la liste et de fournir une option pour passer à la lecture de la suite ;
• baliser un titre de section avec le code wiki approprié à base de « = », cela permet d'extraire une table des matière de la page, avec des utilisations plus nombreuses que la TOC statique que mediawiki génère par défaut (à partir du même balisage sémantique, d'ailleurs) ;
• baliser une citation via les modèles correspondants dans WP, cela permet d'extraire de WP un index des citations, avec leur sources

Dans le même ordre d'idée que ces quelques exemples rapidement mentionnés, baliser le terme défini permettra d'exploiter le fait qu'il y ait un terme défini et sa définition, de multiples manières. La particularité de cette proposition est qu'il s'agit en partie (mais en partie seulement) d'une amélioration sémantique dont les usages concrets sont loin d'être encore tous développés : faute d'usage de ce balisage, on ne l'a encore que peu exploité. L'idée est donc aussi pour une part de sortir du cercle vicieux « si dfn était utilisé par des sites majeurs, on ferait des outils pour en exploiter le potentiel évident. Mais s'il y avait des outils exploitant de manière évidente dfn, on déciderait de s'en servir dans des sites majeurs » . Cordialement, --Lgd (d) 3 avril 2011 à 14:27 (CEST)

En l’occurrence, l'ajout d'un modèle comme {{dfn}} ne va pas complexifier de manière significative l'édition. Les vrais problèmes sont, comme tu l'as dit Pucesurvitaminee l'infobox, la syntaxes des images et tableaux, les multiples modèles et les références. Un modèle de plus dans le lot ne fait pas une grande différence. Et pour tout dire, ce n'est pas un problème que nous pouvons traiter à notre niveau. La Wikimedia Foundation a ré-engagé Brion Vibber pour qu'il fasse un éditeur WYSIWYG, et la WMF va bientôt employer un expert en WYSIWYG (ou systèmes similaires) pour réaliser cela. C'est pas pour tout de suite, il faudra bien patienter un an ou deux vu l'ampleur du truc et le peu d'employés. Mais ça va venir, et il faut laisser cette responsabilité à la WMF. Par contre je tiens toujours aux choix du modèle plutôt que la syntaxe brute "<dfn>". Bien à vous, Dodoïste ^{[ dring-dring ]} 3 avril 2011 à 14:43 (CEST)

<span style="je l'avais bien dit Lgd">On pourrait croire que ça va servir à aider Google...</span>

Puce Survitaminée : Moi qui ne m'y connait guère, j'ai surtout cru comprendre que ça allait aussi palier certains problèmes de référencement d'articles Wikipédia par Google. Du genre certains titres en biologie écrits en noms scientifiques dont l'article ne ressort pas avec une recherche du nom vernaculaire, les œuvres titrées en VO... Et puis oui, il y a l'aspect réutilisation, qui me parle personnellement un peu moins. Totodu74 (devesar…) 3 avril 2011 à 22:59 (CEST)

J'ai lu attentivement la section expliquant à quoi ça servait et n'ai tout simplement pas compris le troisième item (celui relatif à l'accessibilité), les deux liens (un interne et un externe) contenu dans ce paragraphe n'étant pas éclairants. Quelle aide à l'accessibilité apporterait cette balise ? Touriste (d) 3 avril 2011 à 23:04 (CEST)

Elle permettrait à une aide technique (lecteur d'écran, configuration ou plugin du navigateur, etc.) de relever les termes explicités dans une page et d'y donner accès de manière spécifique, de la même manière que le balisage des citations permet d'extraire une liste de celles-ci par exemple. On donne ainsi aux outils d'assistance un moyen supplémentaire d'explorer et de consulter le contenu. Cordialement, --Lgd (d) 3 avril 2011 à 23:10 (CEST)

Je ne comprends pas davantage. Certes les outils auront plus de potentialités, mais en quoi ces potentialités sont-elles utiles à des humains ? Je comprends mal l'intérêt pour un handicapé qui peut déjà savoir que l'article Reims a pour titre "Reims" d'apprendre en outre que l'introduction de cet article contient la définition de "Reims". Ce n'est pas parce que son lecteur d'écran pourra en faire plus qu'avant que ça lui servira à quelque chose. Peux-tu m'éclairer davantage, sur l'interaction entre la page et le lecteur, pas sur l'interaction entre la page et les outils qui me semble assez secondaire, en tout amateurisme. Touriste (d) 3 avril 2011 à 23:16 (CEST)

L'utilisateur n'accède à la page qu'à travers ses outils, justement . C'est pourquoi l'essentiel du travail en accessibilité vise les outils d'assistance et non l'utilisateur lui-même. D'autre part, ce qui peut sembler immédiat et évident pour un internaute qui n'a pas besoin de ce type d'assistance ne l'est pas forcément pour un utilisateur handicapé. Par exemple, dans un lecteur d'écran, accéder rapidement via cette extraction d'information au fait que endive définit aussi « chicon ». Bien-sûr, le fait qu'on ne traitera (au moins dans un premier temps) que des informations données dès l'introduction limite l'impact apparent, mais il ne sera pas négligeable pour autant. Cordialement, --Lgd (d) 3 avril 2011 à 23:23 (CEST)

Modèle dont le titre parle à un non-informaticien

ƝEMOI – Je suis hautement favorable à un modèle, pour moi le wiki doit avoir une syntaxe unique et donc éviter tout balisage par chevron. Ceci précisé ; l’expression « défini », que ce soit par {{terme défini}} ou par {{def}}, ne me semble pas pertinent du point de vue des contributeurs non-informaticien. Je pense qu’un {{sujet de l’article}} ou en version courte {{sujet}} serait beaucoup plus clair. Je ne sais pas si cela doit être discuté ici ou par la suite. Avis donné ce 3 avril 2011 à 13:16 (CEST).

La question a été évoquée lors de discussions antérieures. L'argument en faveur d'un libellé générique du modèle (« terme défini » plutôt que « sujet de l'article ») est que cette syntaxe est susceptible d'être par la suite utilisée dans d'autres cas dans le reste du contenu des articles, où un libellé aussi spécifique que « sujet de l'article » ne conviendra pas. Cela dit, « sujet » est un moyen-terme intéressant à envisager, en effet. Cordialement, --Lgd (d) 3 avril 2011 à 13:21 (CEST)

Ne pas hésiter à refondre Modèle:Sujet pour cet usage, sachant que c'est un brouillon de modèle datant de 2006 et qui n'a jamais été utilisé. Je le dis car cela me semble être un compromis envisageable entre {{dfn}} qui serait trop court pour être explicite, et {{terme défini}} qui est trop long. Dodoïste ^{[ dring-dring ]} 3 avril 2011 à 14:48 (CEST)

Séparation de la question en deux ?

Au vu de mon opinion (à la louche, sans avoir vraiment réfléchi), il me semble qu'il y a deux questions assez distinctes :

1) Est-il opportun d'introduire et recommander une nouvelle syntaxe ?

2) Est-il opportun d'envoyer un bot à l'assaut des articles écrits dans le passé pour les remettre à jour ?

Toujours à la louche, je n'ai rien contre "1" malgré les problèmes de lisibilité du code source que ça pose - de toutes façons la lisibilité du code source est un combat perdu depuis longtemps. Je suis nettement plus dubitatif pour 2), notamment vis-à-vis des observations de HB. Ne pourrait-on séparer les deux questions ?

Je signale aussi qu'il y a, au moins en mathématiques, tout plein d'articles qui contiennent des définitions mises en valeur par du gras ailleurs que dans le résumé introductif, souvent atteintes par des redirections sur sections. Exemple parmi tout pleins : idéal irréductible qui renvoie à une section contenant du texte en gras. Quel avenir leur est programmé ? Touriste (d) 3 avril 2011 à 13:44 (CEST)

Tu poses à ton tour beaucoup de questions en un seul message . Je répondrai juste à la dernière dans l'immédiat : la démarche derrière cette PDD est de faire d'abord un premier pas en choisissant le cas de figure le plus évident (les introductions d'article). S'il y a d'autres pas à faire pour d'autres cas de figure, ce n'est pas du tout exclu, mais ce sont d'autres questions à aborder dans un autre cadre que cette PDD (et sans doute une fois qu'on aura plus de recul, d'expérience éditorial et d'indicateurs de résultat à partir du premier pas). Cordialement, --Lgd (d) 3 avril 2011 à 14:05 (CEST)

Touriste a un point : de ce que j'ai pu lire, des contributeurs questionnent la pertinence de <dfn>. La PdD devrait se concentrer sur ce sujet, il y a suffisamment de matière à débat. La substitution massive devrait faire l'objet d'une autre PdD. En effet, il y a plusieurs effets de bord qui méritent d'être analysés avant d'envoyer l'armée de bots à l'assaut de Wikipédia. Rapidement, il y a plus d'un million d'articles (plusieurs contributeurs qui ne consultent pas le Bistro se demanderont ce qui se passe), comment faire pour les articles dont le titre commence par « Histoire de » ou « Chronologie de », comment faire pour les articles qui contiennent plusieurs définitions (articles sur les maladies, par exemple) ? Cantons-de-l'Est 3 avril 2011 à 16:21 (CEST)

La mise en œuvre peut se faire en plusieurs temps.

Dans un premier temps, on pourrait par exemple traiter uniquement les pages qui contienne « '''Titre de la page''' ». Le risque de faux positif est alors quasiment nul et un gros morceau du travail serait ainsi effectué.

Ensuite, via un comptage de ce qui a été fait (contribs des bots à l'œuvre) ou de ce qui reste à faire (filtre ou erreur spécifique du Projet:Correction syntaxique), on doit pouvoir déterminer ce qui reste à faire et comment, par exemple en repassant en revue les pages non modifiées et filtrant selon que le texte en gras reprend un ou plusieurs mots du titre de la page sans être 100% identique.

Si ce qui reste est suffisamment réduit, alors on peut éventuellement envisager une action manuelle (via le Projet:Correction syntaxique et/ou avec peut-être un module AWB dédié).

Pour d'éventuelles erreurs de bots, il reste possible de corriger manuellement si ce qu'à fait le bot n'est pas correct.

Il est à mon avis illusoire de vouloir se passer à tout prix d'un recours aux bots. Comme l'a calculé Sisyph (d · c · b) ici, à 10 édits minutes (soit 2 à 3 fois plus vite que n'importe quel humain caféiné), un bot travaillant 24h/24 mettra pas moins de 75 jours à tout modifier. Alors si il faut tout faire à la main, on y est encore dans deux ans...

Et je crois que ce serait une erreur que de séparer la décision sur le principe et celle sur la mise en œuvre. Outre le fait qu'elles pourraient être contradictoires (et donc approuver le remplacement mais pas le recours aux bots, ce qui équivaut à son enterrement dans le meilleur des cas, où à une situation analogue à celle de {{Autres projets}} dans le pire), elles sont en fait intimement liées de par le but final. De plus, la mise en œuvre ne devrait pas dépendre d'une quelconque décision par des personnes qui n'y connaissent rien, mais de la possibilité technique de sa (bonne) réalisation, et donc d'une concertation entre les dresseurs de bots impliqués et les projets liés (Projet:Correction syntaxique notamment).

⇨ D^r Brains ^{∞ Consultation ∞} 3 avril 2011 à 18:19 (CEST)

Idem. Une innovation = une décision. Pour la mise en oeuvre, pareil on évite de couper les cheveux en quatre : il ne s'agit que de poser une balise et on ne risque rien du tout et pas de la perdre de vue, cette balise qui pourrait clocher je ne sais trop pourquoi. Accessoirement, on pourrait quand même faire fureter les robots avant (et non après) pour des investigations autour de la présence du titre dans la première phrase. TIGHervé 3 avril 2011 à 18:59 (CEST)

Le Projet:Correction syntaxique dispose déjà d'un listing des pages de ce type (Erreur N°001, avec un module AWB pour la corriger). A l'heure où j'écris ces lignes, aucune page de wikipédia ne présente cette erreur.

Il pourrait cependant être intéressant de lancer un bot sur un dump récent et de lister les changements à effectuer, pour voir le taux de remplacement simples (« '''Titre de la page''' »), un peu plus complexe (« '''Titre de la page un peu modifié''' » ou impossible à automatiser sans erreur probable (« '''Autre terme''' »). Un échantillonnage sur 5000 pages me semble pas mal pour se faire une bonne idée de ce qui attend les dresseurs.

J'ai remarqué aussi que les pages d'homonymie devraient faire l'objet d'une attention particulière, car il n'est pas rare qu'elles proposent différents termes définis (différents par la casse, par exemple les sigles), ou aucun. Elles devraient à mon avis être écartées de la mise en œuvre principale (à vérifier selon test sur dump décrit plus haut)

⇨ D^r Brains ^{∞ Consultation ∞} 3 avril 2011 à 19:22 (CEST)

Pour mémoire (l'application nécessitera une page de concertation où détailler les différents cas) : les pages d'homonymies sont à exclure, notamment pour des raisons de code HTML qui ne répond pas aux champ d'application de dfn (un paragraphe, et non un item de liste à puces). Cordialement, --Lgd (d) 3 avril 2011 à 22:16 (CEST)

Oui, mais je ne pensais pas aux listes à puces, mais aux trucs du genre :

Avant '''Sigle''' peut désigner : * [[Sigle (N°1)|]], définition sommaire; * [[Sigle (N°2)|]], définition sommaire; * [[Sigle (N°3)|]], définition sommaire; '''SIGLE''' peut désigner : * [[SIGLE (N°1)|]], définition sommaire; * [[SIGLE (N°2)|]], définition sommaire; * [[SIGLE (N°3)|]], définition sommaire;

Après {{Terme défini|Sigle}} peut désigner : * [[Sigle (N°1)|]], définition sommaire; * [[Sigle (N°2)|]], définition sommaire; * [[Sigle (N°3)|]], définition sommaire; {{Terme défini|SIGLE}} peut désigner : * [[SIGLE (N°1)|]], définition sommaire; * [[SIGLE (N°2)|]], définition sommaire; * [[SIGLE (N°3)|]], définition sommaire;

L'automatisation est pour le coup assez casse gueule. Il est effectivement opportun de ne pas traiter les homonymies automatiquement.

⇨ D^r Brains ^{∞ Consultation ∞} 3 avril 2011 à 23:08 (CEST)

Justement, ce sont des listes et le balisage dfn n'y est pas pertinent : il ne doit être employé, dans son acception HTML5 (qui est celle à retenir pour une utilisation robuste) que dans des éléments de paragraphe P quand le paragraphe contient non seulement le terme mais aussi sa définition. Ce n'est pas le cas dans les pages d'homonymies, qu'il faudra donc totalement exclure.

Si l'on voulait sémantiser ces pages d'homonymie, il faudrait recourir à des listes DL, mais c'est une toute autre question. Cordialement, --Lgd (d) 3 avril 2011 à 23:15 (CEST)

@Dr. Brains « quelconque décision par des personnes qui n'y connaissent rien » : les jugements sévères ont souvent des conséquences néfastes. Wikipédia est rédigée par des personnes qui ont des sentiments et des attentes. Ne pas en tenir compte prépare les difficultés. Des explications sans porter de jugement sur les personnes qui débattent facilitent souvent les décisions à venir. Deuxièmement, je n'ai jamais écrit qu'il fallait faire les modifications à la main. Voyons en premier si la balise est acceptée. Par la suite, il sera toujours temps de discuter technique. Cantons-de-l'Est 4 avril 2011 à 01:49 (CEST)

Dr. Brains voulait simplement dire qu'apporter massivement des modifications alors que le but de la manoeuvre est hors de vue des décideurs, est périlleux ; il n'a pas voulu dire que ne doivent ou ne devront s'en mêler que ceux qui auraient une science quelconque. Dans le même ordre, je viens de discuter plus bas avec Lgd et c'est un bon exemple de malentendu qui aurait en toute bonne foi eu des conséquences fâcheuses si j'avais eu à dresser un robot avant cet échange. Je crois donc que c'est par des aller-retour entre une innovation et les conditions de son déploiement effectif que les bonnes questions peuvent émergées et s'éclairer. A ce propos, toujours après le dit échange, les choses me paraissent bien plus simples, la question du titre étant en fait presque marginale. Enfin, faire accepter la balise passe aussi par la plus ou moins grande difficulté de la mise en oeuvre, qu'il faut donc étudier, comme elle passe par l'imagination d'autres décisions valorisant ces balises. TIGHervé 4 avril 2011 à 05:51 (CEST)

@Cantons-de-l'Est : Mon propos était ciblé dans l'optique où la mise en œuvre se ferait dans une autre PDD que celle de l'adoption du principe. Or, à partir du moment où le principe du <dfn> aura été accepté, il serait aberrant de soumettre les modalités de la mise en œuvre à un vote, s'agissant là d'un rôle 100% technique : Combien de bots doivent être impliqués ? Comment se répartir la tâche ? Quel langage utiliser ? A quelle vitesse doit-on limiter les modifs et combien de bots peuvent être lancés simultanément (pb de charge serveur) ? Comment limiter autant que possible les erreurs ?

Ce sont là autant de question auxquelles un contributeur lambda serait bien mal placé pour répondre. La discussion sur ces sujets aura lieu (elle a déjà un peu commencé, d'ailleurs) et chacun pourra éventuellement y donner son avis, identifier des difficultés potentielles, apporter une remarque ou poser une question, mais in fine ce seront les dresseurs de bots qui collégialement décideront de la marche à suivre pour mener la mission que le vote leur aura confié. Vouloir installer un vote communautaire dans ce processus de discussion technique n'est probablement pas une bonne idée.

C'est pourquoi je pense néfaste de séparer la question posée en deux (principe + technique), car finalement les seules questions posées concernent le principe de la balise <dfn> et le moyen d'insertion dans les articles (balise HTML ou modèle, et si modèle, quel nom). Le recours aux bots étant par ailleurs indispensable pour la mise en œuvre à l'échelle du million d'articles de wikipédia, la question technique est une question annexe : les bots ne feront qu'appliquer la décision prise. On peut faire confiance aux dresseurs pour mener cette tâche à bien avec le minimum d'erreurs (sachant qu'il sera inévitable qu'il y en ait tout de même, marginalement).

Mon propos n'est pas tant de dire « Votez oui pour le principe et faites aux dresseurs un chèque en blanc pour la mise en œuvre », mais plutôt « Votez oui pour le principe et laissez faire les dresseurs le boulot qu'ils ont l'habitude de faire (mais si vous avez des questions, n'hésitez pas) ». Les discussions sur la mise en œuvre ayant d'ailleurs commencé en parallèle à cette PDD, à la fois ici et sur WP:Bot/Requêtes. La discussion est ouverte à ceux que ça intéresse. Si ça peut faciliter leur vote dans un sens ou dans l'autre, tant mieux.

⇨ D^r Brains ^{∞ Consultation ∞} 4 avril 2011 à 11:05 (CEST)

Utilisateur:Dr Brains exprime mieux que je n'aurais su le faire la démarche que j'ai suivie pour le moment dans la préparation et la rédaction de cette PDD :

• La communauté est appelée à se prononcer sur la pertinence à ses yeux de l'adoption d'un surcroît de balisage
• Les intervenants de l'éventuelle mise en oeuvre (bots) ont déjà été alertés et sollicités pour donner leur avis côté faisabilité et moyen, ne serait-ce que pour s'assurer qu'on éviterait une PDD impossible à mettre en oeuvre, et pour détecter le plus tôt possible les questions qui peuvent l'être avec le point de vue des dresseurs de bots.

Je ne pense pas non plus que la communauté soit à même de se prononcer efficacement pour ou contre une mise en œuvre faisant appel aux bots : ce sont ces derniers qui sont les mieux placés, à partir de leur prudente expérience, pour répondre « non » ou « oui mais » à la suite de la question qui leur a déjà été posée (en cas de réponse négative, on ne serait pas allé plus loin que les discussions préliminaires au lancement de cette discussion). En revanche, les interventions des dresseurs dans ces discussions sont indispensables pour préparer le processus et donner aux contributeurs l'assurance qu'il sera géré collectivement et rigoureusement.

Enfin, côté préparation technique (même théorique si cela n'aboutit pas finalement), le moment me semble justement mûr pour travailler collectivement avec le projet de correction syntaxique et les dresseurs dans une page technique qui servira de référence. Une amorce est proposée dans Utilisateur:Lgd/Déploiement dfn.

Cordialement, --Lgd (d) 4 avril 2011 à 11:43 (CEST)

@Dr Brains, concernant ta phrase: "A l'heure où j'écris ces lignes, aucune page de wikipédia ne présente cette erreur" à propos de l'erreur n°001 du Projet:CS: ce n'est pas exact, il y a beaucoup de pages qui ne contiennent pas de texte en gras (regarde du côté de Projet:Maintenance/Analyse des créations sous IP pour t'en convaincre; il y en a aussi pas mal dans les anciens articles). Il se trouve simplement que la détection de l'erreur 001 est désactivée. (Je signale simplement ce fait pour qu'on n'en tire pas de conclusions hâtives). -- Speculos ^✉ 25 mai 2011 à 12:05 (CEST)

De la difficulté de définir un sujet

Bonjour.

La vocation de la première phrase d'un article est-elle de définir l'expression citée dans le titre ou bien de reformuler en forme longue le sujet que le titre expose en forme courte ?

Je ne sais comment formuler ma position parce que j'ai dû mal à l'identifier. Je vais donc probablement balbutier des suggestions que d'autres ont déjà évoquées ailleurs en termes clairs. Il serait alors judicieux que cette approche claire de mon problème soit exposée dans cet appel à voter, ce que je n'ai pas vu pour l'instant.

Si j'ai bien compris, les balises <dfn> .../... </dfn> appellent une définition. Il serait alors indispensable de faire suivre l'expression ainsi balisée par sa définition exacte. Posons ensuite le postulat « Aucune Wikipédia n'a vocation a être un dictionnaire de mots, ni même un manuel de langues. » Ensuite, admettons que certains sujets sont difficiles à définir et que l'objet des articles n'est pas de les définir mais de les raconter pour que le lecteur puisse en faire sa propre définition. Dans ce contexte, comment utiliser ces balises pour débuter des articles portant sur des sujets vastes ou controversés ?

Concrètement, ces balises simplifient-elles l'élaboration du résumé introductif des articles Gastronomie, Scientologie, France, Retraite par répartition ou Quiche lorraine ? Alors que l'historique et les discussions sur ces articles montrent bien que l'une des difficultés rencontrées pour élaborer ces articles est définir brièvement le sujet. Le gras, lui, n'appelle rien de spécifique. Il introduit en effet souvent une des définitions possibles mais il ne prétend pas donner aux internautes la définition. Cela d'autant mois si on considère vrai qu'une Wikipédia n'a pas vocation a définir des mots.

La conclusion de cette approche est donc très différente de celle qui me semble être à voter. Les balises <dfn> .../... </dfn> ne doivent pas se substituer au gras du premier mot de la première phrase du résumé introductif. Elles doivent être utilisées dans le corps de l'article, là où l'article donne une définition précise du sujet. Par exemple, La <dfn>scientologie</dfn> est une secte, puis, plus loin, « La <dfn>scientologie</dfn> est une Église ».

Comme je l'ai dit, tout cela est confus et cette confusion me donne la vague impression que l'outil est dangereux et qu'il n'est pas exclu qu'il soit contraire à l'intérêt général du projet élaboration de la Wikipédia francophone. Merci de votre attention. --Bruno des acacias 3 avril 2011 à 14:29 (CEST)

Même avis que Bruno, la question est mal posée; Ce que je souhaite avant tout est une ergonomie équilibrée: Wysiwig pour les contributeurs, lourde pour les délétionnistes. L'écriture facultative d'une définition dans le résumé introductif devrait être wysiwyg-Michelbailly (d) 3 avril 2011 à 19:43 (CEST)

Idem, tous les premiers termes en gras ne peuvent toujours être suivis de définitions. L'article qui m'est venu en tête en ce sens est Satellites naturels de Saturne... Cdlt, --Floflo (d) 4 avril 2011 à 12:56 (CEST)

Merci pour ce dernier message, qui pointe en effet un cas d'exception à retenir. En reliant la question aux discussions en cours côté bots, c'est un de ces cas où le remplacement ne devra pas se faire de manière automatique, et où il serait à traiter manuellement et éventuellement (on ne le fera pas pour cet article) : le titre de l'article (« Satellites naturels de Saturne ») n'est pas repris intégralement dans les phrases introductives (« Saturne possède 53 satellites naturels dont l'existence est suffisamment confirmée pour qu'ils soient nommés. Douze autres etc. » qui n'est pas de la forme « X est Y »), ce qui fournit un élément assez aisément repérable par les bots pour les détourner de l'article.

Le problème, sur le fond, n'est en effet pas de savoir si le paragraphe introductif d'un article est par défaut une définition admissible d'une ou plusieurs expressions : c'est le cas pour la majeure partie des articles. Le problème est d'aider à définir les cas particuliers en dehors de cette situation, où les bots ne devront pas intervenir. Cordialement, --Lgd (d) 4 avril 2011 à 13:26 (CEST)

Tout à fait. Je fais confiance aux dresseurs de bots dans cette délicate affaire de toute manière. Et au passage merci à TigH --Floflo (d) 4 avril 2011 à 13:57 (CEST)

Double titre

Est-il prévu/possible de mettre un balisage double ou multiple, lorsque le sujet d'un article est connu sous plusieurs noms (par facilité, le couple endive/chicon, mais il y en a bien d'autres) ? • Chaoborus 3 avril 2011 à 21:31 (CEST)

oui et la page de prise de décision vient d'être modifiée avec un exemple en ce sens.
Tel que je le comprends maintenant après la réponse erronée que je fais ensuite, le but est de
convertir toutes les occurrences de triple apostrophes en balises dans la première phrase.
C'est sur cette base que le dressage des robots modificateurs sera réglé, l'affaire du titre, voire à terme du sujet, n'étant que de l'ordre des moyens et non de la finalité. TIGHervé 4 avril 2011 à 05:37 (CEST)

Cette prise de décision concerne l'ajout d'une balise à la première occurrence du titre, actuellement en gras. Elle ne concerne pas la mise en caractères gras de version alternative du titre, ni toute autre modification du contenu des articles pour satisfaire des exigences ou contraintes dont il n'est question nulle part.
Si des contributeurs veulent profiter de cette proposition pour revoir les conventions et recommandations sur le résumé introductif qu'ils le fassent dans une page destinée à cela.TIGHervé 3 avril 2011 à 21:56 (CEST)

Heu, si, justement : ce balisage est également pertinent pour les termes alternatifs éventuellement présents dans le paragraphe d'introduction. J'ai complété le texte de la PDD pour préciser ce point. Cordialement, --Lgd (d) 3 avril 2011 à 22:13 (CEST)

Sauf que tu ne dis pas de quelle manière tu détermines que la mise en gras que tu rencontres est une instance définissante (alternative) et non un enrichissement secondaire. Tu parles uniquement de l'introduction. Ce n'est pas cette prise de décision qui va préciser comment l'introduction doit être lue du point de vue du Web sémantique (et donc rédigée). TIGHervé 3 avril 2011 à 22:33 (CEST)

Je ne comprends pas très bien ta question. Le rôle des mises en gras actuelles dans le premier paragraphe introductif est justement d'indiquer des instances définissantes. Pourrais-tu préciser peut-être à travers un exemple ? Cordialement, --Lgd (d) 3 avril 2011 à 22:39 (CEST)

Je reprends bêtement ton exemple : Alces alces comporte dans son introduction 4 termes en gras. Tu ne donnes pas ta clé de discrimination des termes à baliser, donc un, deux, trois, pourquoi pas les quatre ou plus dans une longue introduction. Il n'est pas question de remplacer trois apostrophes par une balise ! Je défends au contraire le point de vue du robot qui attend de préférence à avoir le titre de l'article balisé ou à défaut le premier terme en gras (ou balisé) de l'article. Donc, en résumé, la pertinence du titre est perdu de vue par la considération de complication langagière d'une part, et l'intérêt du balisage est dégradé par l'éventualité de balisages multiples. Toutes choses qui me font dire qu'on ne s'occupe que de retrouver le titre et de modifier la forme de son enrichissement, le reste étant de la cuisine wikipédienne habituellement peu sémantique. TIGHervé 3 avril 2011 à 22:51 (CEST)

Dans l'exemple donné, ce sont en effet tous les termes déjà retenus par ailleurs comme pertinents pour figurer dans cette phrase introductive, déjà mis en relief par le gras, qui sont concernés par l'emploi de dfn, sans qu'il y ait de question excessivement complexe à se poser. Et sur le fond, pour prendre un autre exemple, il serait assez absurde d'indexer « chicon » et non « endive » ou inversement . Il n'y a là aucune dégradation de l'intérêt de ce balisage, tout au contraire : le but est bien d'indexer toutes les occurrences, notamment par exemple pour enrichir un index actuellement limité au seul titre de l'article, comme celui de google define. Cordialement, --Lgd (d) 3 avril 2011 à 22:57 (CEST)

Il y a quatre termes en gras ; tu t'arrêtes au premier point final, le dernier est après ?
C'est pour ça que je dis que tu ne précises pas ce que tu considères comme un titre sur la seule base des apostrophes. TIGHervé 3 avril 2011 à 23:06 (CEST)

Bon je vois que j'étais parti sur une mauvaise piste : en fait le titre t'indiffère, ce que tu veux ce sont des définitions ou considérées comme telles, concernant le sujet de l'article et non son titre.
Il reste à corriger les questions posées en PDD pour refléter les exemples.TIGHervé 4 avril 2011 à 05:37 (CEST)

Tout à fait. La formulation actuelle des questions est une simple base de départ, à améliorer. Cordialement, --Lgd (d) 4 avril 2011 à 06:01 (CEST)

Au niveau mise en œuvre (la première phase, c'est à dire par un/des bot(s)), il y a plusieurs approches possibles pour ces cas-là :

1. on balise tous les termes en gras, puis par le truchement d'une liste des "Articles comportant plusieurs <dfn>" (créée pendant la traitement ou a posteriori), des humains devront vérifier que tous les termes balisés doivent effectivement l'être;
2. on ne balise que le premier terme en gras, puis par le truchement d'une liste des "Articles comportant du gras en intro en plus du <dfn>", des humains devront vérifier si d'autres balises sont à mettre.
3. on ne balise que la première occurrence en gras du titre de la page (et éventuellement du titre des redirection vers la page), des humains devront vérifier si d'autres balises sont à mettre.

Dans tous les cas, il y a des erreurs potentielles, et un humain sera nécessaire pour vérifier que le bot a bien fait son boulot.

L'avantage, dans ce cas précis, c'est que même en cas d'erreur du bot, l'aspect de l'introduction restera identique pour la plupart des gens (pas de modèle cassé ou de rendu incorrect (visuellement)). Seuls les outils se servant effectivement de la balise <dfn> seront éventuellement affectés.

⇨ D^r Brains ^{∞ Consultation ∞} 6 avril 2011 à 22:32 (CEST)

Je ne comprends pas le modèle

On parle de l'utilisation d'un modèle comme d'une évidence, quelque chose de pratique, d'habituel, ne présentant au pire que des difficultés de mémorisation, de surcharge, et autres considérations ordinaires.

Seulement, quand je me place non du point de vue contributeur, mais de celui qui - humain ou robot - utilisera à l'avenir de diverses façons ce balisage, j'ai un besoin d'éclaircissement tout aussi patent que le modèle est une alternative évidente. En effet, cet humain ou ce robot attend, si j'ai bien compris l'intention, à trouver un couple de balises dfn /dfn, et cela uniquement et non un modèle propre à Wikipédia comme {{Définition}}, {{Sujet}}, {{Titre}}. Si on intervient sur le contenu pour des lectures de ce contenu automatiques, je ne vois pas comment on peut y introduire de l'arbitraire par des choix humains et de langage.

Ou alors je suis passé à côté de quelque chose comme la conversion du modèle en balises à la sauvegarde, mais dans ce cas, encore faudrait-il en faire état avant tout. TIGHervé 4 avril 2011 à 12:00 (CEST)

Ce que "voit" un robot d'indexation, ce n'est pas le wikitexte, c'est le rendu HTML de ce wikitexte. Ainsi, peu lui importe que le HTML qu'il voit soit issu d'un modèle situé sur une autre page (modèle) ou si il est issu du wikitexte de la page qu'il "regarde" directement. Que la balise <dfn> soit insérée tel quelle dans la page ou via un modèle est donc totalement transparent du point de vue du lecteur (humain ou robot).

En revanche, l'utilisation d'un modèle présente des avantages pour les contributeurs de wikipédia par rapport à la simple balise HTML :

• facilité de suivi, via les pages liées du modèle;
• possibilité de se servir du modèle pour intégrer d'autres infos (par exemple la langue du terme défini, cf plus haut).

⇨ D^r Brains ^{∞ Consultation ∞} 4 avril 2011 à 12:15 (CEST)

 Oui bien sûr ! Hum il y a trop longtemps que je ne me soucie plus du HTML ... Et j'étais dans le principe d'une utilisation par "nos" robots maisons (wikitexte) sur le même mode que les robots extérieurs et inversement.

Merci de cet éclaircissement. TIGHervé 4 avril 2011 à 12:47 (CEST)

Pour compléter : en fait, on s'oriente doucement mais assez surement vers un modèle (Dieu sait si le proposant n'en voulait pas au départ, pourtant ) : il est transparent pour les outils externes qui tireront profit de ce balisage, il peut faciliter la maintenance interne, la chose plaît apparemment et spontanément aux contributeurs réticents devant un balisage assimilé à de la complexité d'édition en plus, il simplifie la gestion des changements de langue. Il va falloir succomber, je crois . Cordialement, --Lgd (d) 4 avril 2011 à 14:04 (CEST)

Je le sens comme ça aussi, avec aussitôt l'idée d'un compromis entre l'encombrement de la première phrase et la sophistication possible de ce modèle, ou encore l'idée de sa polyvalence et de son usage à terme ailleurs que dans la première phrase. Que tu succombes, passe encore +/-, mais la prise de décision ce serait dommage. TIGHervé 4 avril 2011 à 14:38 (CEST)

Comme cela n'a pas encore été évoqué, je me dois d'informer d'une limitation avec un éventuel modèle : la présence d'un caractère « = » dans le titre de l'article, devant être géré via nommage optionnel du paramètre ou utilisation de {{=}}.

Ce cas est heureusement rarissime, peut être géré manuellement et ne doit donc aucunement être une entrave à l'éventuelle adoption d'un modèle.

pour ma part, modèle ou balises, je n'arrive pas à trancher pour de bon...

Cordialement, od†n ↗^blah 4 avril 2011 à 16:24 (CEST)

Un petit ajout sur la question initiale de TigHerve et la réponse de Dr Brains. Le fait d'utiliser un modèle permet un balisage sémantique du code HTML (après rendu par le moteur Wiki) pour Google et autres, ainsi que pour les questions d'accessibilité et un balisage sémantique du WikiText pour les bots de Wikipedia. En effet, le modèle lui-même peut-être interprété comme une balise qu'un bot pourrait utiliser pour extraire des définitions du WikiText. Je n'y vois pas d'utilité immédiate, mais il me semble dommage de ne baliser que le HTML et pas le WikiText, et de perdre ainsi de l'information. En clair : si l'on doit mettre une balise HTML, alors oui au modèle !--Juju2004 (d) 6 avril 2011 à 15:54 (CEST)

Bah, la balise n'ayant en l'occurrence qu'une seule fonction, je pense que ça ne changera rien pour les bots. Je pense qu'un modèle ne pourrait servir qu'à deux choses : gratter quelques caractères (donc faut avoir un nom de modèle court) et pouvoir ajouter un paramètre pour la langue (du coup on passe de <dfn>{{lang|en|Toto}}</dfn> à {{dfn|Toto|en}}, ça pourrait effectivement être intéressant). od†n ↗^blah 6 avril 2011 à 18:00 (CEST)

<autre question>Si modèle il y a, peut-on imaginer un modèle qui introduise un rendu un peu différent de la phrase ? Je veux dire quelque chose qui indique à l'œil averti que les triple apostrophes ont été enlevées ou quelque chose qui valorise l'ensemble de la phrase telle qu'une taille augmentée d'un demi-point ?
Bien sûr, la question est d'ordre ergonomique et de l'ordre du consensus rédactionnel, pas technique (quoique pour valoriser toute la phrase, si !).
TIGHervé 6 avril 2011 à 19:36 (CEST)

Je pense que non, par contre il est possible à qui le souhaite, via son Monobook.css, d'afficher différemment les <dfn> genre avec une couleur. Mais cela est possible même sans modèle. od†n ↗^blah 6 avril 2011 à 20:09 (CEST)

Ce pourrait être possible en demandant à Lgd de modifier son gadget accessibilité à cet effet. Udufruduhu (d) 6 avril 2011 à 22:43 (CEST)

Le test est trivial à déployer, en effet. Le gadget peut également signaler automatiquement des emplois de dfn « hors champ d'application ». Cordialement, --Lgd (d) 6 avril 2011 à 22:57 (CEST)

Balisage systématique ?

Encore moi !
La prise de décision pose une question sur l'usage systématique des balises. A partir de là, deux interrogations :
1)s'il y a opposition, l'usage non systématique sera(i)-t-il autorisé ?
2) Est-ce qu'on peut ou est-ce qu'on pourrait l'utiliser dès maintenant ? Ne serait-ce que pour voir ou pour tester sur une petite échelle ou un échantillon ?

Bien entendu, vu que je pense comme et pour les robots, si vous me dites oui pour 2), il faudrait revoir tel ou tel robot qui s'appuie sur la présence des apostrophes (à moins de les laisser en plus des balise aïe !).
TIGHervé 4 avril 2011 à 20:26 (CEST)

1. « Systématique » est un terme peut-être maladroit de ma part dans ce brouillon de PDD : il signifie juste ici « selon un système », système exposé et à préciser dans la PDD et dans la page d'aide qu'elle mentionne. L'absence d'adjectif sera peut-être préférable dans la rédaction finale des questions, à moins que « usage raisonné » ne fasse l'affaire. En effet, et c'est aussi le but de cette discussion préliminaire, il y a un cadre d'usage qui est déjà grosso modo défini mais qui reste à préciser. En tous cas, il s'agit plus de guider cet usage que de s'enfermer dans un formalisme « juridico-réglementaire » comme WP en produit parfois.
   Après, j'avoue ne pas m'être posé la question en l'abordant sous l'angle conflictuel (qui me paraît un peu curieux, mais tu as en effet raison, on peut imaginer le pire avec raison sur Wikipédia) : que se passera-t-il en cas de conflit « éditorial », disons, sur l'usage d'un dfn dans un cas précis ? Par exemple, pour d'obscures raisons antagonistes autour d'un terme régionaliste (un exemple immédiat, pris au hasard) ? Ma foi, je supposerai simplement qu'il s'agit d'une question éditoriale, à régler par la discussion dans la page de discussion de l'article en question, non ? Un peu comme d'habitude, en fait . Ce que je trouve spontanément rassurant est qu'en fait, un éventuel conflit du type « faut-il mettre ou pas dfn autour du terme Y dans cet article ? » revient immédiatement à poser une question éditoriale déjà fréquente : « faut-il mentionner le terme Y dans l'introduction de cet article ou plus loin dans le corps de celui-ci, de manière plus contextualisée ? » Cela m'amène à penser qu'il n'y a guère de prise à conflits proprement liés à ce qu'introduit cette PDD, en fait.
2. Sinon, il y a déjà, je crois, quelques usages ponctuels ici ou là de ce balisage, à l'initiative d'un ou deux contributeurs (si j'en juge par quelques diffs ou discussions que j'ai vu passer). Je ne vois guère de souci à « tester », si tant est qu'il ait quelque-chose à tester à court terme en dehors des réactions des contributeurs. Tout au plus cela peut-il entrainer par la suite une ou deux scories selon qu'on va tester avec le balisage ala-HTML ou avec le modèle, mais rien de dommageable. On bougera, si cela aboutit, quelques centaines de milliers d'articles : tu parles de test sur quoi ? Une centaine au plus ? Ce n'est pas un souci.

Cordialement, --Lgd (d) 4 avril 2011 à 20:44 (CEST)

Ok sur toute la ligne même s'il y a beaucoup de pointillés...

Je pense qu'il faudra être précis dans les questions posées pour qu'on ne se retrouve pas peut-être avec des arguties du genre ça n'a pas été accepté donc c'est prohibé. Mais c'est faire compliqué pour un changement pas loin d'être cosmétique si ce n'était le tout début de l'article. Par ailleurs, il faudrait peut-être que tu écrives noir sur blanc qu'en l'état du Web il n'y a pas d'intérêt immédiat à utiliser dfn/dfn et qu'il n'y a qu'un potentiel. Autant jouer franc-jeu !

Un mot côté test : je marche souvent sur des œufs dans mes relectures d'article et sachant que la première phrase est l'objet de toute mon attention, tu peux imaginer l'inconvénient d'ajouter à une phrase entièrement remaniée ces signes cabalistiques, inconvénient vu du point de vue que je suppose sourcilleux de l'auteur qui n'en demande pas tant...

A suivre. TIGHervé 4 avril 2011 à 21:27 (CEST)

On pourrait peut-être en effet envisager de tester le remplacement sur les articles d'un projet donné (de l'ordre de quelques milliers d'occurrences) ce qui pourrait donner à voir d'une part les réactions des gens qui suivent la page et d'autres part pourrait servir de test aux dresseurs pour voir si il y a trop d'erreurs. Il faudrait juste trouver un projet représentatif des projets de wikipédia et avec le bon nombre d'articles (entre 1000 et 5000). Puce Survitaminée (d) 5 avril 2011 à 09:04 (CEST)

je ne veux pas m'aventurer, mais il me semble que le projet Biologie serait un bon terrain de test, et devrait voir la proposition d'un oeil assez ouvert. Cordialement, --Lgd (d) 9 avril 2011 à 22:13 (CEST)

Cadrage du test

Il a été fait quelques suggestions concernant la réalisation d'un test de modification de pages, comme ci-dessus de traiter tout un projet, on peut faire converger les idées ci-dessous, merci de répéter au besoin l'essentiel de vos investigations ou suggestions :
Il faut décider de la taille ou de la façon de sélectionner l'échantillon, du changement à appliquer, du ou des robots à lancer.
TIGHervé 7 avril 2011 à 14:07 (CEST)

Je rejoins l'idée qu'il ne faille pas séparer l'un de l'autre, et comme le dis Dr Brains plus haut après avoir fait un pré-test à vide sur les 2500 première page de Wikipédia. Le fait de prendre « les pages qui contienne « '''Titre de la page''' ». », j'ajoute sur les 350 premiers caractères uniquement. Ne m'a généré qu'un seul faux positif.

Une question, ne serait il pas judicieux de se regrouper entre dresseur sur un sous page quelconque et d'y rassembler nos script par langage afin que chacun puisse les peaufiner au mieux ?

Une autre, je penses qu'il serait pas mal, ne serait ce que pour rassurer la communauté. De parfaire ces fameux scripts, de faire des tests sur 5 / 10 / 15 000 ? pages à vide, et de publier quelque-part les logs des modifications qui auraient été entraînées.

La publications des logs de modif sur cette PDD ainsi que sur d'autres espaces meta (je penses au bistro) amènerait les gens à analyser et éviterait peut être une râlerie de modification non consensuelle alors que la PDD n'en est qu'à la phase de discussion que je crains.

Micthev ^(discuter) 7 avril 2011 à 14:16 (CEST)

Un point à prendre en compte avec la condition « 350 premiers caractères », c'est lorsque la page contient une infobox avant le résumé intro Aussi, je serais intéressé de connaître le faux positif que tu as rencontré. od†n ↗^blah 7 avril 2011 à 14:51 (CEST)

D'où le 350 et non pas 150 mais on peut voir à mettre plus d'octets. Rhaaa je n'ai pas les logs mais c'était justement à cause d'une infobox. C'est un truc du genre :

{{Infobox xy

|nom = '''Lorem ipsum'''

}}

'''Lorem ipsum''' dolor sit amet, consectetur adipiscing elit. Quisque aliquet, lacus eget vestibulum pulvinar

sur la page Lorem ipsum

donc forcément :

{{Infobox xy

|nom = <dfn>Lorem ipsum</dfn>

}}

<dfn>Lorem ipsum</dfn> dolor sit amet, consectetur adipiscing elit. Quisque aliquet, lacus eget vestibulum pulvinar

Enfin problème accessoire qui peut se résoudre en excluant les remplacements dans les modèles.

Micthev ^(discuter) 7 avril 2011 à 15:02 (CEST)

Est-ce que tu as prévu quelques routines de vérification après-coup, notamment si la page actuelle est un peu bugguée (par exemple, une balise <dfn> ajoutée mais non fermée, des balises suspectes qui contiennent trop de mots, des cas tordus d'imbrication du type « <dfn></dfn> », « <dfn><dfn>...</dfn></dfn> » ou « ''<dfn>...''</dfn> »...) ? Sinon en plus des modèles, il faut aussi faire attention aux images. Binabik (d) 7 avril 2011 à 17:16 (CEST)

Pour dire vrai pour l'instant je n'ai rien prévu je n'en suis qu'à l'embryon du commencement du début d'une ébauche ! Mais avant de continuer plus avant j'aimerais savoir si les autres dresseurs seraient d'accord pour que l'on rassemble et concentre nos efforts histoire de ne pas travailler tous dans son coin. Micthev ^(discuter) 7 avril 2011 à 17:25 (CEST)

Alors parfait ! Ce genre de chose permettra à mon avis de rassurer la communauté. Binabik (d) 7 avril 2011 à 17:28 (CEST)

Je crois que Lgd a créé une sous-page pour çà (voir plus haut).

Faire selon un nombre de caractères, c'est casse-gueule à cause des modèles ({{Voir homonymes}}, {{Ebauche}} et bien sûr infoboxes.

Il serait plus judicieux de faire soit la section 0 entière, soit éventuellement le premier paragraphe (mais en mode wikitexte c'est probablement compliqué à déterminer).

La partie édition de mon début de script fonctionne a priori dans la plupart des cas de figure.

Ca marche en cinq temps :

1. "élimination" de tous les modèles (dispatchage dans deux Array "modèle" et "hors modèle")
2. dans la partie "hors modèle", changement des ' (apostrophe droite) par des ’ (apostrophe courbe)
3. toujours dans la partie "hors modèle", remplacement dans les cibles de liens de l'apostrophe courbe par une normale (sinon, cassage des liens)
4. toujours dans la partie "hors modèle", ajout du modèle {{Terme défini|...}} autour des termes en gras
5. remise en ordre du texte dans et hors modèle

Les temps 2 et 3 sont là non seulement pour la typographie, mais aussi pour éviter d'avoir une apostrophe droite à l'intérieur d'un terme en gras (exemple : '''château d'York'''), sans quoi la RegExp ( "'''[^']+'''" ) plante et ne "voit" pas le terme.

C'est sans doute à peaufiner, et j'ignore si c'est transposable en python (la langage utilisé par la majorité des bots), mais ça donne je pense une idée de la marche à suivre.

PS : en l'état, on peut le tester sur n'importe quelle page (sauf homonymie) : il ajoute le dfn sur la page courante, autour de tous les termes en gras hors modèles. C'est sans frais car il ne sauvegarde pas automatiquement (libre à vous de cliquer sur publier...)

⇨ D^r Brains ^{∞ Consultation ∞} 7 avril 2011 à 21:57 (CEST)

Section 0 c'est faisable en wikitext en matchant les premiers == en fait en effet c'est plus judicieux.

Je ne parlais pas de ce genre de sous page mais une page genre WP:Bot/dfn

contenant une section JavaScript, une section Python, autre ?

avec à l’intérieur le code source d'un script auquel chaque dresseur apporterait ses améliorations.

Micthev ^(discuter) 8 avril 2011 à 00:12 (CEST)

Même pas besoin de s'embêter à matcher les == , il suffit d'appeler la page à modifier avec &section=0 comme je le fais dans mon code.

Ce que je disais difficile à matcher, c'est le premier paragraphe de l'intro. Il faudrait repérer le premier double saut de ligne, mais il y a un gros risque qu'il y en ait entre les modèles pré-introduction. A ce compte-là, il me semble plus simple de matcher carrément la seule première phrase (terminée par un point et suivie d'un espace puis d'une lettre en majuscule ou d'un double saut de ligne).

Pour la sous-page, je faisais référence à Utilisateur:Lgd/Déploiement dfn.

⇨ D^r Brains ^{∞ Consultation ∞} 8 avril 2011 à 01:04 (CEST)

J'ai en effet mis en place Utilisateur:Lgd/Déploiement dfn pour y recueillir petit à petit le résultat des tests et échanges entre les dresseurs (plutôt que pour y mettre le détail de ceux-ci). N'hésitez pas à la mettre à jour le cas échéant ou à modifier si cela ne vous semble pas le moyen le plus pratique. Cordialement, — Le message qui précède, non signé, a été déposé par Lgd (discuter), le 8 avril 2011 à 09:43 (CEST).

@ Dr Brains oui et non je penses aux noms du style H. F. Quelqu'un

@ Lgd, des que mon code ressemblera à quelque chose (ne soyez pas pressés) je le publierais sur cette page.

Micthev ^(discuter) 8 avril 2011 à 12:44 (CEST)

Pas de souci, nous avons tout notre temps (sans compter que je n'aimerais pas avoir à faire ce genre de travail avec comme source cette abominable syntaxe wiki au lieu du DOM ou du XML sur lequel je travaille habituellement : quand je vois la difficulté à matcher un paragraphe X, de mon point de vue, cela ressemble à un véritable cauchemar - chapeau aux dresseurs de bots !). Cordialement, --Lgd (d) 9 avril 2011 à 07:43 (CEST)

Ne m'en parles pas, je n'ai mis que trois ans à dresser correctement mon bot (et encore il lui arrive encore de faire des bourdes) Micthev ^(discuter) 9 avril 2011 à 07:46 (CEST)

Pub

Bonjour.

Pour information, ce présent appel à voter une décision ne me semble pas affiché sur Wikipédia:Accueil de la communauté. Cordialement. --Bruno des acacias 8 avril 2011 à 08:03 (CEST)

L'ouverture de la discussion y a été annoncé le 3 avril. --Lgd (d) 8 avril 2011 à 09:41 (CEST)

Je ne vois pas cette PDD dans la liste des PDD et sondages du tableau du contributeur, me semble-t-il. --Bruno des acacias 8 avril 2011 à 09:58 (CEST) PS. Personnellement, je ne consulte que très rarement la liste des annonces, encombrée des annonces sur les portails dont je n'ai strictement rien à faire.

Fait, par un autre que moi. --Bruno des acacias 29 avril 2011 à 17:54 (CEST)

Début et fin de la définition

Bonjour.

Où commence et se termine le texte qui définit l'expression balisée ?

Dans la page de vote, je n'ai vu que des informations sur le début de la définition et aucune sur la fin. Me suis-je trompé ? Si ces informations sont manquantes, voilà mes questions. Sinon, un lien vers les réponses déjà données suffira.

Prenons pour exemple l'article Quiche et de l'article Total (entreprise). <dfn>Quiche</dfn> affiche Quiche et <dfn>Total</dfn> affiche Total. Soit. On peut considérer que ce qui précède le mot gras n'est pas dans la définition. Soit. Mais quel est le mot qui, pour chaque exemple donné, clos la définition ? Est-ce :

1. Le dernier mot de la première phrase, ou
2. le dernier mot du résumé introductif, ou
3. Le dernier mot de l'article, ou
4. un mot choisi par les co-auteurs de l'article ?

Est-ce aux utilisateurs de la Wikipédia francophone de fixer ce mot de fin, est-ce défini dans les spécifications de Mediawiki ou est-ce choisi par ceux qui réutilisent le contenu du site fr.wikiepdia.org ?

Cordialement. --Bruno des acacias 8 avril 2011 à 08:21 (CEST)

Comment l'indique l'exemple donné dans la page de la PDD, il ne s'agit pas de baliser au mot près le début et la fin d'une ou plusieurs phrases qui constituent la définition d'un terme (c'est le rôle d'un autre balisage, celui des listes de définition utilisées par exemple dans Glossaire du cinéma). Il s'agit ici de sémantiser (baliser) le fait que le contenu du paragraphe où se trouve l'élément DFN contient une définition du terme. Le paragraphe en question n'est pas censé se limiter obligatoirement à cette définition.

Mediawiki génère le balisage qui identifie le début et la fin de ce paragraphe. Les contributeurs sont évidemment maître de l'information qui y figure. --Lgd (d) 8 avril 2011 à 09:33 (CEST)

Merci. Je regarde cela de plus près. --Bruno des acacias 8 avril 2011 à 10:02 (CEST) PS. J'ai pour l'heure compris que c'est « }} » qui clos la définition si on utilise un modèle.

Outil de validation de l'usage de dfn pour les contributeurs

Bonjour,
Comme demandé plus haut, un outil de détection des usages impropres de dfn a été mis en place pour les contributeurs intéressés. C'est un ajout au gadget accessibilité.

Il détecte (si tout va bien à ce stade de son débugage) les utilisations de dfn ou du modèle équivalent en dehors du premier paragraphe introductif de l'article. le cas échéant, il ajoute un message d'erreur dans la page et un lien vers Aide:dfn. Il fonctionne également lors de la prévisualisation d'un article.

Pour les utilisateurs du gadget accessibilité, pensez à actualiser le cache de votre navigateur.

Cordialement, --Lgd (d) 9 avril 2011 à 07:27 (CEST)

'a morche pô ! Totodu74 (devesar…) 10 avril 2011 à 15:57 (CEST)

Ah, je cherchais ce genre d'exemple, justement (présence d'un paragraphe vide provoqué par un modèle, ici le modèle d'icône de titre). On va corriger pour tenir compte de ce genre de cas. Merci ! Cordialement, --Lgd (d) 10 avril 2011 à 16:04 (CEST)

fait, cordialement, --Lgd (d) 10 avril 2011 à 19:03 (CEST)

Le lien ne me parle pas trop, mais ça marche (j'ai quand même pas de pot, le premier dfn que j'appose dans le Main cafouillait) Merci à toi, Totodu74 (devesar…) 10 avril 2011 à 20:14 (CEST)

Il faut que j'ajoute une mise en évidence des dfn bien utilisés (comme pour les changements de langue, les abréviations, etc.) Je vais mettre ça dans la grosse mise à jour du gadget prévue cette semaine (si tout va bien) avec l'amélioration de plusieurs détections (images, tableaux, listes) et peut-être une interface également améliorée. Cordialement, --Lgd (d) 12 avril 2011 à 10:59 (CEST)

Une illumination en passant

ƝEMOI – Faudrait-t-il, est-ce prévu, a-t-on déjà, etc., fait passer un robot pour retirer les occurences de « <dfn> » qui ont pu être disséminées sans être mises en <nowiki> lors de discussions quant à la possible introduction de cette balise ? ce 9 avril 2011 à 15:11 (CEST).

Si ces occurrences ne sont pas utilisées dans l'espace principal, quel est l'intérêt ? Udufruduhu (d) 9 avril 2011 à 15:27 (CEST)

Ce n'est pas prévu ni particulièrement nécessaire. Les pages de discussion, dont tout le code est à base de détournement bien plus lourd d'un autre élément sémantique, n'en sont pas à cela près. Et il y aura forcément d'autres emplois de cette balise dans des discussions ultérieures, mais l'impact sera pratiquement négligeable. --Lgd (d) 9 avril 2011 à 21:54 (CEST)

Expressions rationnelles ?

Bonjour,

J'ai un doute technique qui pourrait peut-être faire avancer un peu les choses au sujet de la programmation des Bots. Dr Brains a mentionné ci-dessus l'utilisation d'expressions rationnelles pour la modification (éventuelle) des pages afin d'introduire la balise ou le modèle. Or il ne me semble pas évident que le cas présent puisse être traité de cette manière. Je vois par exemple que dans la neutralisation des modèles, Dr Brains utilise déjà un genre de machine à états (voir la fonction dfnBot_getTemplate, Utilisateur:Dr_Brains/dfnBot.js, avec la variable Recursion comme variable d'état). J'ai bien l'impression que la machine à états est la bonne piste, en particulier pour les apostrophes de l'étape 2 de son programme (« dans la partie "hors modèle", changement des ' (apostrophe droite) par des ’ (apostrophe courbe) »), étape qui risque de poser pas mal de problèmes avec certains noms étrangers.

En clair : à mon avis, il serait plus simple de lire caractère par caractère, et déterminer si on est dans une partie italique ou non, dans une partie en gras ou non, etc., afin connaître exactement le statut de chaque apostrophe, plutôt que d'essayer de construire des expressions rationnelles complexes et pas forcément adaptées.--Juju2004 (d) 10 avril 2011 à 15:37 (CEST)

• Précision : le changement des apostrophe droite en apostrophes courbes ne concerne pas toutes les apostrophe mais les cas d'utilisation les plus courant d'apostrophe en francais (l', d', s', t', qu' ), en prenant garde à garder des apostrophe droite dans les cibles de liens pour ne pas les rougir accidentellement.
• Dans mon code, la variable Recursive sert lorsqu'un modèle est imbriqué dans un autre. Je viens de me rendre compte d'ailleurs que ce n'est pas correct si il y a deux modèles imbriqués dans le même modèle...
• Lire le code caractère par caractère risque de s'avérer extrêmement fastidieux, quand même, mais ça pourrait être une piste, en effet.

⇨ D^r Brains ^{∞ Consultation ∞} 12 avril 2011 à 13:56 (CEST)

Mmmmh je suis en accord avec le docteur, sur le fait que tout apostrophe n'a pas la même signification et ai d'avis que une vérification par caractère serait bien trop longue et fastidieuse. Micthev ^(discuter) 12 avril 2011 à 14:06 (CEST)

Digression d'un non-dresseur, typographe à ses heures : Dans un même article, l'homogénéité est à encourager, mélanger les apostrophes courbes et droites ne me semblent pas très heureux. Puce Survitaminée (d) 12 avril 2011 à 14:38 (CEST)

Je suis en accord avec toi, mais que proposes tu pour automatiser ce fait ? Tout en sachant que l'on dévie un peu là du sujet. Si tu le veux bien, je me propose de t'aider dans ta démarche, toutefois faisons le ici même si tu le veux bien, car ce script n'aura je penses, rien à voir avec dfn. Micthev ^(discuter) 12 avril 2011 à 14:45 (CEST)

@Mitchev : ce dont je parle est de programmer un petit parser assez simple, c'est-à-dire traiter effectivement caractère par caractère pour distinguer les textes en italiques, en gras et les modèles. La longueur de l'opération est à mon avis assez faible (voire négligeable) par rapport au temps de récupération d'une page et de modification de celle-ci, même en utilisant un langage interprété. L'algorithme peut évidemment être assez lourd, mais pour traiter un million d'articles, mieut vaut une solution robuste.

@Puce survitaminée : avec un parser, on évite l'étape de transformation de l'apostrophe droite en courbe. On dissocie donc les deux opérations (l'insertion d'une balise dfn et la transformation des apostrophes) et on conserve l'homogénéité des articles (quand elle existe).

Je vais réfléchir un peu à l'alogrithme qu'il faudrait mettre en place pour faire des propositions aux dresseurs (je ne suis pas moi-même dresseur de bot).--Juju2004 (d) 12 avril 2011 à 20:46 (CEST)

Je suis d'accord avec toi sur le principe et je veux bien ton algorithme, je vais tâcher de travailler en ce sens. Micthev ^(discuter) 12 avril 2011 à 21:26 (CEST)

Après réflexion, le plus simple et le plus sûr est d'aller chercher la solution à la source : dans le code de MediaWiki. Je vais regarder s'il n'y a pas un bout de code à extraire pour obtenir directement le résultat voulu.--Juju2004 (d) 13 avril 2011 à 13:34 (CEST)

Pour info, j'ai corrigé mon code : je n'utilise plus de RegExp ni pour la recherche du gras ni pour celle des modèles. Et je n'ai plus besoin de modifier les apostrophes droites en courbes.

⇨ D^r Brains ^{∞ Consultation ∞} 13 avril 2011 à 13:48 (CEST)

Je vais jeter un oeil. Le code MediaWiki pour les italiques est ici, dans la fonction doQuotes. Il faut que ton code implémente exactement l'algorithme, après avoir supprimé les modèles, pour éviter toute surprise. La fin de la fonction doit être adaptée pour tester la présence du titre de l'article, et mettre des dfn au bon endroit. (Toujours sous réserve que la décision soit prise en ce sens !)--Juju2004 (d) 13 avril 2011 à 19:11 (CEST)

J'ai mis un code en Python ici. Le programme ne gère que la partie remplacement du titre en gras par un titre avec balises dfn. Il n'a pas été soumis à une batterie de tests approfondie, mais il fonctionne sur les cas normaux testés. Il utilise exactement le même algorithme que MediaWiki pour les gras. La question des critères pour mettre du texte dans la balise dfn n'ayant pas été tranchée (texte en gras, oui, mais identique au titre de la page ? simplement similaire ? en première position dans les textes en gras ? etc.), l'algo va au plus simple : titre exact en gras hors modèle. Mais c'est adaptable--Juju2004 (d) 16 avril 2011 à 21:39 (CEST)

Je publie une nouvelle version de mon code Python pour gérer le remplacement du titre en gras dans la première section. Il gère :

• le non remplacement dans les modèles ;
• les gras et italiques comme MediaWiki ;
• certains modèles typo qui pouvaient poser problème (ex. {{e}}) ;
• les modèles dont il faut explorer les paramètres (ex. {{japonais}}) ;
• les tableaux (merci Dr Brains).

Ce code est un peu conçu comme une boîte à idées pour les dresseurs de bots qui vont participer à l'opération : servez-vous, testez, utilisez ou n'en faites rien, c'est comme vous voulez ! Si vous testez ou utilisez, pensez à m'en parler que je puisse avoir un retour.--Juju2004 (d) 18 avril 2011 à 12:15 (CEST)

Recensement des moyens de correction assisté

Bonjour,
La discussion avec le Projet:Correction syntaxique avance et permet de prévoir une prise en compte de cette syntaxe dans WPCleaner (ce qui va permettre de faire le joint avec une première phase de remplacement par bot, notamment).

Il serait intéressant d'indiquer ici les éventuels autres outils d'aide à la correction qui pourraient être concernés ?

Cordialement, --Lgd (d) 12 avril 2011 à 10:55 (CEST)

Pour ma part, une fois les principales corrections effectuées et cette PDD adoptée, je mettrais un script en routine sur la longue liste des scripts déjà en routine pour mon bot. Étant actuellement en vacances, je n'ai pas la main sur le serveur du bot, il est donc normal qu'il soit en arrêt . Micthev ^(discuter) 12 avril 2011 à 14:06 (CEST)

Précisions : ce script écrit en Python sera adaptable au framework pywikipedia. Micthev ^(discuter) 12 avril 2011 à 14:11 (CEST)

Ambiguïté sur ce qui est défini : le cas des oeuvres

Bonjour,

Suite à l'exploration des solutions techniques possibles avec Dr Brains (d · c · b) (qui a bien avancé sur la question du bot, soit dit en passant), un problème m'est apparu. Considérons cette ligne (la modification proposée étant effectuée) :

''<dfn>Paris-Dakar</dfn>'' est le quarante-et-unième album de la série de bande dessinée ''[[Michel Vaillant]]'', créée par [[Jean Graton]].

A mon sens, le paragraphe ne définit pas réellement ce qu'on entend par Paris-Dakar (la course, bien qu'elle ait changé de nom ajourd'hui). On pourrait trouver des cas similaires avec tous les films ou livres qui traitent d'une personnalité (Napoléon, etc.). Faut-il vraiment les faire passer à la moulinette dfn, quitte à avoir des "fausses définitions" ou plus précisément, des définitions de "produits dérivés" par rapport au terme qui est dans la balise ?--Juju2004 (d) 16 avril 2011 à 17:24 (CEST)

La définition d'un « produit dérivé » est une définition au sens de cette balise, en effet : elle indique le sens particulier de l'expression dans le contexte où il est employé ainsi. Cordialement, --Lgd (d) 16 avril 2011 à 19:12 (CEST)

Ok, je crois que je me pose trop de questions. Je dois être fatigué. Allez, une autre (comme ça, ça fera deux pour le prix d'une) : est-ce que tout terme (ou expression) est susceptible d'une définition ? Je pense en particulier au cas des noms propres...--Juju2004 (d) 16 avril 2011 à 21:28 (CEST)

Au sens de « définition » dans la sémantique de cette balise, oui. Pour donner un exemple concernant un nom propre (mais qui serait hors du cadre d'application de cette PDD et qui fait appel à un usage plus complet de dfn, peut-être pour plus tard) : dans un article où l'on parlerait successivement de différents personnages connus par le prénom « X », dfn permettrait de relier chacun de ces différents usages au paragraphe qui identifie exactement chacun des « X » en question, Cordialement, --Lgd (d) 17 avril 2011 à 07:14 (CEST)

Je pense que tu fais référence à l'attribut "title". C'est effectivement une autre question, mais elle se pose dès maintenant avec les textes dont le titre en gras ne reprend pas le titre de la page, mais fait procède à une mise en forme typographique (type {{e}}) : faut-il transformer le titre dans l'article en lui faisant perdre sa typographie, ou bien utiliser la balise "title" qui permet de spécifier un titre normalisé pour les robots et autres applications ?--Juju2004 (d) 17 avril 2011 à 08:44 (CEST)

Non, ce n'est pas l'attribut title (ni la balise title, il me semble y avoir confusion dans ton message ci-dessus ?). C'est la possibilité de renvoyer, lors de l'usage du terme, à son occurrence balisée par dfn et dotée d'un identifiant id. Mais bon, ce n'est pour l'immédiat.

Sinon, pour la question que tu évoques : il n'y a pas lieu de modifier la mise en forme. Par exemple, dans Ier siècle av. J.-C., on fera :

Le <dfn>{{-s-|I|er}}</dfn> commence le [[1er janvier]] [[-100]] et finit le [[31 décembre]] [[-1]].

A l'image de l'exemple actuel donné par le document de travail HTML, qui est : The <dfn><abbr title="Garage Door Opener">GDO</abbr></dfn> .

D'une manière générale, il faut inclure dans le balisage <dfn>...</dfn> tout ce qui relève en fait davantage de la sémantique et du contenu que de simples mises en forme : explicitation d'abréviations, signalement de la langue, italique à valeur sémantique en typographie, etc.

Sinon, par ailleurs, voilà un type d'article à traiter spécifiquement (pas via les bots) en raison du contenu inhabituel (et sans doute à corriger) qui précède le paragraphe introductif.

Cordialement, --Lgd (d) 17 avril 2011 à 09:12 (CEST)

Note: mon exemple avec Ier siècle av. J.-C. est un peu perturbé par tout ce qu'il y a par ailleurs à corriger dans les actuels modèles de siècles qui sont complètement crapoteux : {{-s-|I|er}} devrait produire comme HTML quelque-chose comme :

<abbr title="premier"><span class="romain">I</span><sup>er</sup></abbr> siècle <abbr title="avant Jésus-Christ" class="abbr">av. J.-C.</abbr>

Et non:

<span class="romain">I</span><sup>er</sup> siècle <abbr title="avant Jésus-Christ" class="abbr" style="white-space:nowrap">av. J.-C.</abbr>

Le point essentiel étant que l'on balise comme ayant été défini non seulement l'expression littérale « Ier siècle av. J.-C. » mais aussi et surtout « premier siècle avant Jésus-Christ ». Cordialement,--Lgd (d) 17 avril 2011 à 09:51 (CEST)

Je suis d'accord avec cette dernière phrase, c'est pourquoi je soulevais le problème des éléments de mise en forme (entre autres les balises "sup"). Et je parlais bien de l'attribut title de la balise dfn. Voir le document de travail : « Defining term: If the dfn element has a title attribute, then the exact value of that attribute is the term being defined. » et l'exemple sur cette page, avec la priorité de l'attribut title sur la balise abbr.

A mon sens, il convient de réaliser un traitement (une normalisation) sur les titres mis en forme et de mettre le résultat dans l'attribut "title". Mais bon, il faut encore voir si le document de travail évolue ou si on peut considérer cet attribut comme fiable...--Juju2004 (d) 17 avril 2011 à 10:32 (CEST)

Non. En effet :

1. la prise en compte de l'attribut title de l'élément dfn serait avant tout beaucoup trop compliquée pour les rédacteurs de Wikipédia (Ils commettent déjà régulièrement dans divers modèles des erreurs chroniques sur l'utilisation de l'attribut title sur des span et des div).
2. du point de vue de l'accessibilité, l'implémentation ou le moment de l'implémentation du title de dfn dans les aides techniques est une totale inconnue.
3. <dfn><abbr title="foo">bar</abbr></dfn> ne pose aucun problème de conformité, ni de robustesse, ni de sémantique.

Allons-y doucement, prudemment, pas à pas, de manière mesurée et améliorable par étapes : le mieux est l’ennemi du bien .

Cordialement, --Lgd (d) 17 avril 2011 à 10:45 (CEST)

Tes arguments me vont dans le principe, mais j'ai encore un doute. Je prends le paragraphe complet du document de travail : « Defining term: If the dfn element has a title attribute, then the exact value of that attribute is the term being defined. Otherwise, if it contains exactly one element child node and no child text nodes, and that child element is an abbr element with a title attribute, then the exact value of that attribute is the term being defined. Otherwise, it is the exact textContent of the dfn element that gives the term being defined. » et j'essaie de l'appliquer à la ligne ci-dessus (cas favorable), insérée dans une balise dfn :

<dfn><abbr title="premier"><span class="romain">I</span><sup>er</sup></abbr> siècle <abbr title="avant Jésus-Christ" class="abbr">av. J.-C.</abbr></dfn>

Pas d'attribut title dans dfn, ni d'unique enfant abbr. C'est donc the exact textContent of the dfn element that gives the term being defined. Si tout va bien, les abréviations sont résolues et on obtient "premier siècle avant Jésus-Christ", mais il faudrait faire un peu d'exégèse pour savoir si cela est garanti (nature exacte de textContent en particulier).

D'autre part, tous les modèles utilisés ne contiennent pas une balise abbr (par ex. {{e}}) qui permettrait de traduire la mise en forme en texte simple. Comment agira un robot dans ce cas ? Se contentera-t-il d'ignorer les balises sup ? Au mieux (si on ajoute la balise abbr), 7^e devriendra 7ème et pas septième, ce qui n'est pas homogène avec le cas du premier siècle avant J-C. Et il doit y avoir d'autres cas à prendre en compte...

NB. je ne soulève pas ces questions pour remettre en cause l'opération ni par malice, mais pour essayer de cerner exactement ce qu'il convient de faire et de faire faire aux bots.--Juju2004 (d) 17 avril 2011 à 14:17 (CEST)

Oui, le remplacement (par les bots, et même corrigé manuellement ensuite) ne produira pas un contenu sémantique idéal partout. Wikipédia se construit petit à petit dans un certain désordre, et il est très rare qu'on puisse obtenir un résultat correct de manière aussi directe qu'on le fait ailleurs. Mais c'est aussi un peu la définition () du wiki : améliorable et en amélioration permanente .

La voie la plus directe et profitable pour déployer ce balisage et en tirer profit est d'admettre que certains résultats ne seront pas optimaux quand on va chercher ce genre de question pointue de sémantique HTML (on va par contre éviter autant que possible ce qui ne serait « pas bien » du point de vue moins technique des contributeurs, c'est à dire l'éditorial).

Donc, oui, on va obtenir dans un premier temps des choses comme l'indexation potentielle de 7e (7e, donc) au lieu de « septième » si un modèle d'abbr était présent. Mais cela n'est pas la question à poser ici : la question que tu évoques est, tout à fait en dehors de cette question de dfn, qu'il reste beaucoup de travail à réaliser par ailleurs pour transformer les premières actions entreprises depuis septembre 2009 quand l'élément abbr a été enfin pris en compte par Mediawiki.

Disons qu'avec « un pas après l'autre », il y a aussi « une brique à côté de l'autre ». Cordialement, --Lgd (d) 17 avril 2011 à 14:32 (CEST)

Sinon, le fait que le draft HTML5 actuel semble sous-entendre qu'un seul élément enfant abbr (et seulement un élément de ce type, d'ailleurs, quid des title de liens pour prendre un exemple évident, ou des alt d'images, etc.) serait à prendre en compte : c'est une erreur qui a, si ma mémoire est bonne, déjà été remontée au groupe de travail du W3C. Cordialement, --Lgd (d) 17 avril 2011 à 14:43 (CEST)

Reformulation sur la question "est-ce uniquement la reprise du titre de l'article ?"

Bonjour,
J'ai reformulé le texte proposé en PDD, pour dissiper les confusions et répondre aux questions du type « est-ce seulement la reprise du titre de l'article ? » et « que fera-t-on en cas de plusieurs mises en gras ? »

N'hésitez pas à améliorer, critiquer, frapper pas la batte, quand même, svp. Cordialement, --Lgd (d) 17 avril 2011 à 10:03 (CEST)

Liste de…

ƝEMOI – J’ai cru comprendre que ce modèle (je grille les étapes, moi ? ) sert à définir le {{sujet}} (bis ) d’un paragraphe. Est-ce à dire qu’il faudra(it) optimalement l’appliquer 383 fois sur une telle page ? Sera-t-il préférable d’avoir pour ce cas un modèle spécial qui en profite pour éviter ces affreux <span> dans le code ? Bref, qu’en est-il des listes ? ce 17 avril 2011 à 14:48 (CEST).

Non. Son usage (dans un premier temps et dans le cadre de cette PDD) est rigoureusement limité au seul premier paragraphe introductif d'un article. Par ailleurs, Liste des Hommes de la Terre du Milieu est un de ces cas d'articles qui en sont un mais pas comme les autres qu'on va exclure du champ d'application, voir Utilisateur:Lgd/Déploiement_dfn#Pages_.C3.A0_exclure. --Lgd (d) 17 avril 2011 à 15:22 (CEST)

Sinon, pour un glossaire bien balisé, il faut refaire cela sur le modèle de Glossaire du cinéma (un bot avait prêté son concours pour ce dernier, voir ici). --Lgd (d) 17 avril 2011 à 15:48 (CEST)

<HS> ƝEMOI – Le code <dl><dd/><dt/></dl> généré est beaucoup plus propre, mais je me suis déjà senti gêné à y passer dès qu’il y a trop de lignes « courtes », car je trouve le résultat très moche et peu lisible. Comme ne sont concernées par cette remarque que très peu de pages desquelles je m’occupe / me suis occupé, et qu’elles auraient de toute façon besoin d’un gros travail, je n’ai pas pour le moment réfléchi à ce qu’il conviendrait de faire. Si tu as une solution lumineuse et directe, je suis preneur, sinon je continue à repousser. Ce 17 avril 2011 à 17:12 (CEST). </HS>

On dévie (si besoin, on poursuit plutôt sur ma page de discussion), mais rapidement : on peut a priori créer une classe CSS dans Mediawiki:Common.css qui rende l'usage de dl plus « discret », avec un rendu similaire à celui de Liste des Hommes de la Terre du Milieu actuellement, au prix d'un modèle assez léger éditorialement. Cela se justifierait peut-être, même si c'est destiné à un lot de pages limité (quoique potentiellement appelé à grossir pour diverses raisons, AMHA). --Lgd (d) 17 avril 2011 à 17:21 (CEST) Je n'ai rien dit, c'est un b... sans nom, faute d'une vieille propriété CSS hélas aujourd'hui abandonnée. --Lgd (d) 17 avril 2011 à 17:52 (CEST)

dfn et italiques

Hello, je me pose la question en voyant l'exemple donné dans la section le cas des œuvres, où je tiens à préciser que ''<dfn>Paris-Dakar</dfn>'' ne marche pas : il faut mettre les italiques dans le dfn :

• ''<dfn>Paris-Dakar</dfn>'' : Paris-Dakar (NB:Rendait Paris-Dakar avant manip' css)
• <dfn>''Paris-Dakar''</dfn> : Paris-Dakar

Et étant donné que ce cas va être omniprésent pour les taxons biologiques (d'ailleurs les noms scientifiques ne sont pas toujours graissés malheureusement quand un nom vernaculaire existe) il va soit falloir en tenir compte pour le robot (mais aussi à la création d'article, se rappeler que l'italique ne marche pas à l'extérieur) soit il existe peut-être une solution pour faire que ça marche ? (je ne sais pas du tout ce qui se cache derrière ces balises, donc à tout hasard...) Totodu74 (devesar…) 17 avril 2011 à 14:50 (CEST)

Heu... oui. C'est ce que je viens d'écrire dans Utilisateur:Lgd/Déploiement dfn aujourd'hui. Mais c'est où, la section le cas des œuvres Veuillez excuser ma mémoire défaillante parfois ? Cordialement, --Lgd (d) 17 avril 2011 à 14:59 (CEST)

Donc on ne peut pas faire en sorte que ça marche... ? (tu as eu du mal à trouver parce que j'ai mis la ligature ? ) Totodu74 (devesar…) 17 avril 2011 à 15:07 (CEST)

<deux baffes pour Edith /> Bon, juste pour l'italique et si cela simplifie la question pour les contributeurs, permettre le passage en italique avec la première syntaxe est juste une bricole à ajouter à Mediawiki:Common.css. D'ailleurs, en fait, je viens de l'ajouter de ce pas (inutile de perdre du temps avec ce niveau de détail). Donc désormais, ''<dfn>Paris-Dakar</dfn>'' donne Paris-Dakar, c'est à dire que ça marche si vous actualisez le cache de votre navigateur. Hop.

Totodu74 me fera 100 lignes pour avoir utilisé l'élément tt à la place de l'élément code, tsss..... Cordialement, --Lgd (d) 17 avril 2011 à 15:16 (CEST)

Aaaah, merci ! Économie de caractères, sinon c'est-y quoi la différence ? Totodu74 (devesar…) 17 avril 2011 à 15:21 (CEST)

code dit à la face du monde : « j'écris en police monospace parce que je balise du code », tandis que tt bredouille « j'écris en monospace mais je ne saurais pas vous dire pourquoi et auquel des multiples usages de ce genre de police cela peut correspondre dans ce cas ». Cordialement, --Lgd (d) 17 avril 2011 à 15:26 (CEST)

Encore un truc que je ne savais pas ! Copie rendue ! Totodu74 (devesar…) 17 avril 2011 à 16:43 (CEST)

TED 17 avril 2011 à 16:54 (CEST)

Il me cherche cuilà ? il me trouve --Lgd (d) 17 avril 2011 à 17:04 (CEST)

Exclusions de droit

Par exclusions de droit (ou sémantique), j'entends les exclusions d'article qui ne correspondent pas à l'objet de la balise. Les listes et les homonymies sont évidemment à exclure. Mais il reste des difficultés. Deux exemples :

• Les articles "Histoire de ...". Dans l'article Histoire de France, on constate que l'article n'a pas pour sujet le concept d'Histoire de France, mais l'Histoire de France elle-même. Autrement dit, il n'explique pas ce qu'est l'Histoire de France, il la raconte. Il est donc normal qu'il n'y ait pas de définition de l'Histoire de France en intro. Le sujet n'est pas défini (au sens : explicitation du concept), il est délimité. (Voir pour contre-exemple la très maladroite intro de Historique du parcours européen du Liverpool FC.)
• Les articles sur des personnes. Dans l'article Napoléon : « Napoléon Bonaparte, dit Napoléon I^er, né le 15 août 1769 à Ajaccio, en Corse et mort le 5 mai 1821 sur l'île Sainte-Hélène, au Royaume-Uni, fut général, premier consul, puis premier empereur des Français. Il fut un conquérant de l'Europe continentale. » Je ne suis pas sûr que cela soit une définition au sens sctrict de Napoléon. Je crois plutôt que c'est une présentation courte. Le problème de la définition des noms propres (que j'avais brièvement évoqué ci-dessus, mais la discussion avait pris une autre direction) est, si mes souvenirs sont bons, un serpent de mer de la linguistique. Un nom propre dénote, mais il n'a pas de signifié (ou un signifié dégradé, selon les théories). Personnellement, je serais pour interprêter la balise largement, pour y inclure les présentations courtes, mais j'ose à peine imaginer les guerres d'édition en perspective si la chose n'est pas précisée dès maintenant. Le problème dans ce cas est que le sens de la balise dfn est assez vague pour l'instant (et à mon avis, il dépendra grandement de ce qui va être fait de la balise par les utilisateurs de HTML). Toujours est-il qu'il faudrait y réfléchir dès maintenant.

Cordialement.--Juju2004 (d) 26 avril 2011 à 14:03 (CEST)

J'ai très peu de disponibilité sans doute jusqu'à samedi, cette proposition très bien vue appelle un avis détaillé que je donnerai sitôt que possible. A priori, je dirais oui pour le premier point, et du même avis que toi pour le second : il ne faut justement pas préjuger d'un usage étroit de « dfn ». Cordialement, --Lgd (d) 28 avril 2011 à 09:24 (CEST)

Pour moi, c'est simple, très simple. Il n'y a pas d'objet de la balise : en tant que producteurs de contenu, nous estimons seulement que cette balise correspond assez judicieusement au « développement du titre » que les conventions imposent comme première phrase, c'est tout. Que ce développement soit une définition est une question inconnue du projet et pour ma part toute allusion à une définition devrait être retirée de Wikipédia:Résumé introductif. Je passe mon temps à reprendre des efforts suants de définition pour en faire une introduction véritable du sujet et non un blabla évasif et circonvolutif qui n'ose pas appeler un chat un chat. Donc revenons à nos tout petits moutons : la balise encadre ce qui est enrichi en gras, sans état d'âme. Si ça ne convient pas à quelqu'un, ce quelqu'un ne peut être qu'un traqueur de définitions et que je sache nous ne travaillons pas pour eux particulièrement mais pour ceux qui sont intéressés par quelques mots pertinents sur un sujet (nommé par le titre). Si ça ne convient pas à quelqu'un, c'est à lui de filtrer ce qui n'est pas pertinent de son point de vue et il n'est pas question d'en faire davantage puisque comme je l'ai dit, ce n'est pas en tirant la première phrase dans le sens d'une définition qu'on sert l'encyclopédie qui je le rappelle ne traite pas du langage et de la manière dont on parle du monde, mais du monde lui-même.
Le balisage doit être fait à l'aveugle une fois éliminés les pseudo-articles comme les homonymies et les listes : au lieu de triples apostrophes, l'article aura une balise et pas l'ombre d'une contrainte ou exigence supplémentaire. TIGHervé 29 avril 2011 à 19:59 (CEST)

Promis, je fais un point plus complet demain dès que j'ai un oeil assez frais, là je suis juste bon à réagir à chaud. Totalement en vrac, et surtout pour ne pas oublier de le faire remarquer : je serai tout à fait d'accord avec cette idée de ne pas s'accrocher à la notion de « définition ». En fait, techniquement et sémantiquement, les spécifications renvoient plutôt à une notion plus large, qu'on peut peut-être bien exprimer avec « description » (@Juju2004 : regarde le vieux souci d'explication en français du rôle de DL: « liste de définition » - un abus - ou « liste de description » ?). Hervé voit très bien l'idée, en tous cas, avec son image du « balisage [qui] doit être fait à l'aveugle une fois éliminés les pseudo-articles » : Napoléon n'est pas un pseudo-article, en ce sens particulier de « pseudo-article». Son introduction donne une description qu'il est pertinent d'associer au terme Napoléon (et à d'autres à mentionner dans la phrase concernée) parce que les contributeurs l'ont déjà fait en l'écrivant. En revanche, Histoire de France entre clairement dans la série des exclusions (d'ailleurs, il n'y a rien de mis en gras à cette heure dans l'introduction de cet article Mais dans d'autres cas à exclure, c'est le côté formaliste de la règle « du gras en intro » qui a produit le résultat, plus qu'un choix réfléchi). Cordialement, --Lgd (d) 29 avril 2011 à 20:22 (CEST)

Je défends l'idée de non seulement ne pas faire intervenir la notion de définition (et description est bien le mot qui ne m'est pas venu à l'esprit), mais de ne rien faire intervenir du tout. En reprenant le terme "exclure" tu laisses totalement ouverte la porte à toutes interrogations qui n'existaient pas - en tout cas aussi explicitement - avant cette simple proposition de remplacer une syntaxe par une autre. Il faut de mon point de vue, s'affranchir non seulement d'une exigence de définition mais de tout autre scrupule intellectuel pour en rester au formatage du texte actuel, celui qui a déjà fait ses preuves comme tu le dis plus ou moins. Le remplacement se fait en confiance et a priori, les contributions ultérieures restant aptes comme pour tout le reste à améliorer les choses au cas par cas et selon chaque bonne volonté. Je ne vois pas où peut nous mener tout autre démarche comportant une part de discrimination et supposant « d'ouvrir les articles ». TIGHervé 29 avril 2011 à 21:09 (CEST)

Il y aura nécessairement d'une part des articles à ne pas traiter en première passe et d'autre part des exclusions nécessaires (les pages d'homonymies, la page Histoire de France citées ci-dessus, nous sommes en train de les déterminer). « [défendre] l'idée de non seulement ne pas faire intervenir la notion de définition [...] mais de ne rien faire intervenir du tout » est une sympathique vue de l'esprit, mais qui n'a aucun rapport avec le but du jeu dont on essaie de d'écrire les règles au plus exact : utiliser un balisage qui a un rôle sémantique donné, c'est à dire opérationnel.--Lgd (d) 29 avril 2011 à 21:26 (CEST)

Tu as précisé que Histoire de France n'avait pas de mise en gras, la question ne se pose donc pas pour le robot. Fournissons des articles et balisons, ne faisons pas l'inverse ou ne nous empêchons pas de baliser parce que tout n'est pas nickel. Moi des vues de l'esprit ? Il faut avant tout de vrais résumés introductifs notamment débarrassés de leurs embarras d'expression (désigne, correspond, forme, type, ensemble, espèce, etc.) : Je viens encore d'essayer ! sur un article récent. Ces cas sont innombrables par rapport aux articles qui semblent vous rester par avance en travers de la gorge, vous qui ne rêvez pas. Nous ne sommes pas dans une quelconque décharge d'octets, un fourre-tout sans queue ni tête, mais dans une encyclopédie et la préoccupation sémantique fait partie des murs : on a aucunement besoin d'en rajouter de ce point de vue, ni à l'occasion de cette proposition ni à tout autre. TIGHervé 29 avril 2011 à 21:38 (CEST)

Je synthétise mon point de vue (et essaie de vous répondre) :

• il est absurde de vouloir définir à tout prix en intro. Ce qu'il faut, dans une intro, c'est clairement délimiter le sujet (je crois qu'on est tous les trois d'accord sur ceci). Donc, pas question de produire de la définition pour la définition (je renvoie à nouveau à la maladroite tentative de l'article Historique du parcours européen du Liverpool FC comme exemple de ce qui n'est pas souhaitable) ;
• la balise <dfn> permet de marquer une expression dont la définition se trouve dans le paragraphe (en général) : « The dfn element represents the defining instance of a term. The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element. » Il paraît dès lors difficile de s'affranchir de la notion de définition comme le suggère Hervé. Cette balise ne formate pas (comme la mise en gras par ex.) : elle décrit un contenu ;
• il y a donc bien un hiatus entre l'usage préconisé de la balise et l'usage que nous voulons en faire, puisque le premier paragraphe peut contenir autre chose qu'une définition : une courte description par exemple. (J'ai par ailleurs déjà écrit que ça ne me posait pas de problème de mettre un <dfn> sur Napoléon ou autres cas de genre).
• je préfère soulever ces problèmes avant qu'après : pourquoi ne pas préciser dans la prise de de décision l'interprétation que l'on compte faire de la balise ? On veut adopter une balise : ce que l'on veut en faire n'est pas une question pertinente ? Je ne comprends pas l'idée d'adopter une balise sans préciser l'usage qu'on peut (veut, doit) en faire. Selon moi, on précise, on vote et c'est réglé (oui ou non). Si c'est oui, il sera plus difficile de lancer une guerre d'édition sous prétexte que ceci ou cela n'est pas réellement une définition ou ne correspond pas réellement à l'esprit de la balise. « Les contributions ultérieures restant aptes comme pour tout le reste à améliorer les choses au cas par cas et selon chaque bonne volonté » : perdre l'occasion d'encadrer précisément l'usage de <dfn> dès maintenant, c'est juste remettre le problème à plus tard ;
• enfin, l'idée d'une exclusion de droit de certains articles n'est pas complètement stupide, dans la mesure où certaines catégories d'articles n'ont pas pour sujet leur titre (c'est mal dit : je pense par ex. au cas "Histoire de France" qui, comme dit, n'a aucune raison de définir l'Histoire de France, puisque c'est de la France qu'il s'agit). Mais ce n'est pas le cas général, qui permettrait de dire que puisque rien n'est jamais défini (argument : "on parle du monde, non du langage"), on peut mettre du <dfn> partout (c'est ce que je comprends de ce qu'écrit Hervé, mais peut-être que je me trompe). On peut penser que les problèmes s'élimineront d'eux-mêmes, mais c'est faire confiance à la chance. Mieux vaut relever les cas où le <dfn> ne sera pas pertinent (ce qui suppose une réflexion préalable sur les articles et sur la balise).--Juju2004 (d) 29 avril 2011 à 23:38 (CEST)

Merci de m'avoir bien lu. Depuis hier j'en suis passé suite aux résistances à 150% minimum de ce que je pensais avant, c'est dire que je suis maintenant aux antipodes. Je me tais pour le moment, j'ouvrirais une autre section. Bonne continuation. TIGHervé 30 avril 2011 à 10:13 (CEST)

Quels dangers ?

Bonjour.

Quels dangers l'usage de cette « fonction Définition » pourrait faire courir à la Wikipédia francophone ?

Est-ce qu'elle altére le contenu ? Es-ce qu'elle détourne la Wikipédia francophone de sa vocation d'encyclopédie ? Est-ce qu'elle facilite la confusion entre la Wikipédia et le Wiktionaire ? Est-ce qu'elle complique l'édition des pages ? Est-ce qu'elle complique la lecture ? Est-ce qu'elle brouille la recherche de contenu ? Etc.

J'ai beau relire les informations fournies ici et avoir attendu que la discussion avance, je ne vois toujours pas les dommages que pourrait causer à la Wikipédia francophone l'usage de la fonction Définition proposée, si on part du postulat que « le résumé introductif a vocation à donner la définition du sujet de l'article exprimé par le titre » Si j'ai bien compris, avec ou sans cette fonction Définition, le contenu de la Wikipédia est le même. Seul change l'accès à ce contenu via certains outils tels que les moteurs de recherche. Sans cette fonction, le contenu n'est pas identifié et donc pas accessible par les outils qui utilisent cette fonction. Avec cette fonction, ce contenu est identifié et donc accessible par les outils qui utilisent cette fonction.

En conséquence, je ne vois pas ce qui, dans les principes fondateurs, interdirait l'usage de cette fonction Définition par ceux qui le souhaitent, ou, autrement dit, pourquoi celui qui utiliserait cette fonction se rendrait coupable de désorganiser le travail d'élaboration de la Wikipédia francophone. A l'inverse, je me demande pour quel motif un utilisateur aurait l'obligation d'être indulgent avec un utilisateur qui interdirait l'usage de cette fonction. J'irais même jusqu'à dire que je vois pas comment on peut voter « Contre » sans se rendre coupable de désorganiser le travail collaboratif.

Cordialement. --Bruno des acacias 29 avril 2011 à 18:33 (CEST)

Et bien, je suis globalement d'accord avec toi, à l'exception d'un point de détail, ce qui entraine mon total désaccord avec ta dernière phrase. Je suis intimement convaincu que l'insertion de ces balises (ou modèles) va compliquer l'édition. alors, comme nous le disions plus haut, c'est peut être seulement une goutte d'eau, mais pour moi, c'est celle qui pourrait faire déborder le vase. Et de mon point de vue (toujours strictement personnel et surement pas objectif), les avantages ne sont pas suffisant pour justifier qu'on complique encore un peu plus l'édition du résumé introductif. Mon (éventuel) vote contre sera donc un acte visant à permettre la collaboration du plus grand nombre à ce projet, et c'est pour ça que je plaiderai non coupable à tes accusations . Puce Survitaminée (d) 29 avril 2011 à 19:14 (CEST)

<Deux baffes à Edith />« Seul change l'accès à ce contenu via certains outils tels que les moteurs de recherche. Sans cette fonction, le contenu n'est pas identifié et donc pas accessible par les outils qui utilisent cette fonction. Avec cette fonction, ce contenu est identifié et donc accessible par les outils qui utilisent cette fonction. » : c'est un résumé très percutant du bénéfice attendu le plus évident et le plus certain (chapeau ).

Sinon : ce n'est pas vraiment une question de « dangers », bien qu'un contributeur puisse très bien amener une objection de fond imprévue (mais pour autant que je connaisse la question assez à fond, je cherche encore quel pourrait être cet éventuel souci majeur). L'idée générale du passage par une PDD est simplement que l'introduction d'un nouvel usage éditorial (surtout aussi « massif » comme celui-ci, et exigeant une grosse mobilisation des bots) nécessite une décision communautaire, ce qui passe par la possibilité de dire « non » si son explication n'est pas convaincante. Une PDD est en outre, dans un tel cas, à la fois un outil pédagogique et un moyen de mettre autant de monde que possible au courant.

Enfin, il y a tout de même la réelle question du (léger ?) surcroît de syntaxe wiki que cela entraine très directement (comme en témoigne Puce Survitaminée). A cet égard, une précision n'est peut-être pas inutile : ce genre de proposition va (pour moi, mais je ne pense pas être le seul) de pair avec une attention soutenue à tout ce qui peut, ailleurs, contribuer à simplifier la syntaxe, à rendre les modèles plus intuitifs, à éliminer le cas échéant certaines contraintes syntaxiques ou certaines surcharges de modèles à l’effet moins évident ou moins important. L'idée est que l'ont peut à la fois faire que WP tire profit de certaines avancées techniques et travailler sur le fond à simplifier autant que possible les choses pour les contributeurs. C'est typiquement ce que j'écrirais en gros en tête de pages comme celle du projet Modèle ou du projet Javascript... Cordialement, --Lgd (d) 29 avril 2011 à 19:21 (CEST)

De plus, si j'ai bien compris l'affaire, personne ne sera obligé d'utiliser la nouvelle syntaxe, ce sera juste conseillé (mais "interdit" quand même de reverter le passage du simple gras à "la balise dfn"). Il y aura bien toujours un Wikignome ou un bot pour le mettre... Donc pas de complication pour ceux qui n'en veulent pas (de complication). --MGuf (d) 29 avril 2011 à 20:12 (CEST)

« mais "interdit" quand même de reverter le passage du simple gras à "la balise dfn" » : pourquoi tout de suite les gros mots  ? ce ne sera pas plus « interdit » au sens où les gens seraient punis que de faire des listes avec des sauts de ligne excédentaires, de faire des copiés-collés avec des codes de contrôles, de mettre des &npsp; inutiles avant un signe de ponctuation double, etc. Ce serait juste une de ces multiples éditions inévitablement et techniquement à corriger, sans rien de coercitif . Cordialement, --Lgd (d) 29 avril 2011 à 20:26 (CEST)

Besoin de clarification sur l'objectif

Bonjour,

A mon avis (renforcé par les contributions d'Hervé ci-dessus), une chose devrait être clarifiée : quel est l'objectif ? Je vois deux approches possibles :

1. L'objectif est l'adoption par les contributeurs, dans leur pratique, d'une balise (ou d'un modèle) dfn utilisée en accord (relatif) avec les spécifications HTML.
2. L'objectif est de "dfniser" la masse des articles de WP. L'idée est que le <dfn> est un point d'entrée (pour les applications) vers une information, peu importe sa nature exacte.

Dans la première approche (qui a ma faveur), il faut définir clairement les conditions d'utilisations de la balise, afin de permettre à tout contributeur de décider quand il faut l'utiliser et quand il ne faut pas. Evidemment, pour ne pas laisser de côté un grand nombre d'articles, on va faire passer des bots sur pratiquement tous les articles. Ce traitement de masse devra se faire de manière à être au plus proche des consignes pour contributeurs humains. A noter qu'il manque alors une section entre la section "A quoi cela sert-il ?" et "Comment va-t-on s'y prendre ?" : quelque chose du type : "Quand et comment utiliser la balise (le modèle) ?" où il serait question de définition, présentation, etc.

Dans la seconde approche, on va moins se soucier de sémantique : on dfnise par bot tous les titres en gras dans les intros. Mieux vaut viser le plus large possible. L'apport des contributeurs par rapport aux bots sera dans ce cas minime (corrections à la marge). L'opération peut être renouvelée si nécessaire dans 6 ou 12 mois.

Alors : quel est l'objectif ? Cordialement--Juju2004 (d) 30 avril 2011 à 10:29 (CEST)

Bien vu. Pour la version 2, je ferais image en disant qu'il faut considérer qu'il y a eu simplement une amélioration du logiciel et que cette amélioration ne peut être complète qu'en suivant aveuglément sa logique et en modifiant les articles comme si les développeurs avaient pu le faire eux-mêmes sans état d'âme. La PDD n'est vue comme cela qu'une petite formalité comme une page de sondage pour créer un nouvel espace de noms. Il faut imaginer qu'on se réveille un matin avec tous les ''' convertis en dfn et qu'on ait rien à dire à cela. TIGHervé 30 avril 2011 à 10:48 (CEST)

L'objectif de quoi ? De la fonction, de la Wikipédia ou de l'appel à voter ? L'objectif de la fonction ne me semble poser aucun problème. La fonction a pour objectif de faire sur le site fr.wikipedia.org ce qu'elle est destiné à faire sur n'importe quel site Web. L'objectif de la Wikipédia est là beaucoup plus problématique. En effet, l'appel à voter part du postulat que le résumé introductif est un élément de dictionnaire encyclopédique et que donc, la Wikipédia francophone est un dictionnaire, ce que la page Wikipedia:Wikipedia est une encyclopédie réfute. L'usage de la fonction Définition enterrinerait donc que la Wikipédia francophone a vocation à définir les choses et donc à être un dictionnaire encyclopédique. Dans ce contexte, on comprend que l'objectif de l'appel à voter est en effet très vague : est-ce de décider de faire de la Wikipédia francophone un dictionnaire, est-ce d'obliger les contributeurs à accepter l'usage systématique de la fonction dans le résumé introductif de tous les articles ou est-ce de définir comment et quand utiliser cette fonction ?

Pour ma part, il est désormais établi que les articles portant sur une entreprise sont des articles de dictionnaire encyclopédique où la première phrase donne la définition du sujet. Cet appel à voter n'aurait donc comme seul objectif d'obliger les utilisateurs à accepter l'usage systématique de la fonction Définition dans la première phrase de tous les articles portant sur une entreprise. Mais est-ce que cela vaut pour tous les sujets ? Le vote devrait permettre de fixer le type d'articles où la fonction Definition est recommandée. Si elle est recommandée sur tous les articles, sur aucun article ou sur les articles de type A, B, C etc. --Bruno des acacias 30 avril 2011 à 12:06 (CEST)

@Bruno : C'est de l'objectif de l'insertion de la balise (et non fonction) <dfn> dans la WP francophone que je parle. Pourquoi (et comment) veut-on introduire cette balise ? Je renvoie aux deux approches évoquées ci-dessus. Aucune de ces approches ne modifie l'objectif de WP : je ne vois pas comment la pose d'une telle balise obligerait plus qu'une recommandation un contributeur à produire une définition. La question est : la pose de la balise est-elle automatique (ce qui l'éloigne un peu des prescriptions d'utilisation) ou limitée (ce qui implique de définir clairement les cas d'utilisation pour l'humain et les catégories d'articles pour le bot) ?

@Lgd (ci-dessous) : je suis d'accord pour partir des cas concrets, mais on ne pense pas de la même manière selon qu'on envisage la chose côté humain ou côté bot. Pour un humain, il faudrait définir des règles générales d'utilisation (je propose par ex. de rajouter un sens large à définition : courte présentation convient aussi (cf. cas Napoléon)) sans lesquelles on risque de voir arriver des guerres d'édition pour pas grand chose. Pour un bot, on cherche à définir des catégories d'articles à exclure (s'il y en a) : c'est différent, même si le but est que le bot donne un résultat proche de ce qu'aurait fait un contributeur humain.--Juju2004 (d) 30 avril 2011 à 14:14 (CEST)

Il me semble qu'il ne s'agit pas d'un choix entre les deux objectifs que tu indiques ci-dessus. Des règles d'utilisation sont évidemment nécessaires pour les contributeurs (il s'agit de complétez Aide:Dfn), mais ne diffèrent pas sur le fond des guidelines pour les bots (qui seront certainement plus restrictives en raison des cas non traitables par ce moyen). Les contributeurs devront eux-mêmes respecter certaines exclusions données aux bots (homonymies, voir ci-dessous), mais il seront en outre amenés à trancher sur des articles éventuellement exclus de l'intervention des bots (les cas borderline).

Pour l'ajout d'un sens plus large à « définition », tout à fait : n'hésitez pas à améliorer ceci. Cordialement, --Lgd (d) 30 avril 2011 à 15:38 (CEST)

Je ne pensais pas à deux objectifs distincts, mais à deux approches qui se lisent dans les interventions des uns et des autres. Il me semble qu'on ne pense pas pareil si on se place du point de vue du bot ou du point de vue de l'humain. J'aurais tendance à préférer préciser ce que l'humain doit faire et à donner comme une conséquence ce qu'il convient de faire faire aux bots. En résumé, à mon sens, l'élément principal à soumettre au vote est : quand et comment utiliser la balise ? Le reste (passage de bots) en est la conséquence pratique (qu'une discussion antérieure ("séparation de la question en deux ?") tendait à solidariser dans le vote).

La section "Quelles seront les règles d'usage ?" va dans ce sens, à cela près qu'elle est présentée comme le résumé d'une page d'aide dont le contenu ne sera évidemment pas contraignant. J'aurais tendance à renverser les choses dans une formulation (évidemment à discuter) plus contraignante du type : "Le nouveau balisage (quelle que soit la forme utilisée : modèle ou balise) doit être utilisé de la manière suivante :

• il est réservé aux termes dont une définition est fournie dans un paragraphe (il est donc notamment exclu des tableaux) ;
• il est réservé au seul premier paragraphe introductif des articles ;
• il est exclu des articles où le terme et sa définition ne figurent pas ensemble dans ce premier paragraphe (il est donc exclu notamment des pages d'homonymies) ;
• la notion de « définition » des points précédents est vue de manière élargie : elle correspond également aux différents mode de présentation ou description du sujet qui figurent dans le paragraphe introductif d'un article.

La page Aide:dfn fournit un complément d'information pour l'utilisation de cette balise."

C'est un peu plus large que ce qu'on envisage pour les bots, ce qui fait que l'opération des bots restera dans les clous. Ceci étant dit, les précisons que tu as apportées vont largement dans le sens que je souhaitais. Cordialement--Juju2004 (d) 2 mai 2011 à 12:24 (CEST)

Hum...

J'ai un petit double souci pour ma part avec une partie de cette proposition (mais je me trompe peut-être) :

1. d'un point de vue de méthode : je préfère éviter ce qui « grave dans le marbre » via le contenu d'une PDD quand il s'agit d'un domaine technique où des ajustements rapides peuvent être nécessaires à tous moment. C'est pourquoi je propose plutôt de ne mentionner dans la PDD que ce qui est le plus évidemment et certainement acquis, et de laisser à la gestion de la page d'aide le souci du détail des règles d'utilisations.
2. sur un point spécifique : la PDD cible précisément un premier usage de dfn immédiatement limité aux paragraphes introductifs : la mention « il est donc notamment exclu des tableaux » ne m'y semble pas nécessaire (en revanche, c'est à déporter en page d'aide, mais c'est un peu plus compliqué formellement, puisque ce serait dans l'absolu tout à fait admissible dans un P inclus via un tableau de mise en forme, par exemple). Moins il y en a à lire avant de voter, mieux c'est (voir la discussion du jour sur une autre PDD sur le Bistro).

Sinon, les deux derniers points sont d'excellentes formulations, bien mieux vues que celles que j'ai esquissées, mais peut-être plutôt à utiliser dans d'autres endroits de la PDD.

Qu'en dis-tu ? Cordialement, --Lgd (d) 2 mai 2011 à 12:41 (CEST)

Cordialement, --Lgd (d) 2 mai 2011 à 12:41 (CEST)

Sur le souci 1, je comprends la démarche qui permet de se garder pas mal de latitude. On peut partir comme ça et déporter le plus de choses possible dans la page d'aide. (Je vais me pencher sur cette page, histoire de ne pas te laisser bosser tout le temps tout seul.)

Sur le souci 2, le "notamment" permet simplement de préciser un cas qui est déjà compris dans la règle générale du paragraphe introductif. Pas nécessaire, mais peut-être utile... Par ailleurs, je ne suis pas sûr d'avoir bien compris ceci : « ce serait dans l'absolu tout à fait admissible dans un P inclus via un tableau de mise en forme, par exemple ». Théoriquement, la balise est admissible dans toute balise parente qui possède un contenu textuel (celui-là même qui définit le terme), donc de ce point de vue (si j'ai bien compris) ok. Mais là, j'essayais d'énoncer une règle d'utilisation WP, pas forcément une règle W3C. Et donc d'exclure ce cas un peu exotique (une pensée pour les bots aussi).

Enfin, je suis d'accord en principe pour déplacer les deux derniers points ailleurs, mais où précisément ?--Juju2004 (d) 3 mai 2011 à 13:36 (CEST)

Bonjour,
Pour être beaucoup plus concret et éviter les débats de principe, je vous propose plutôt d'indiquer ci-dessous quelles seraient les éventuelles exclusions auxquelles vous penseriez si vous estimez que l'usage de ce balisage doit être délimité de cette manière. Il me semble préférable de réfléchir à partir d'exemples précis pour déterminer si et comment le champ d'application de dfn doit être précisé au-delà de ce qui est indiqué pour le moment dans le texte de la PDD. Cordialement, --Lgd (d) 30 avril 2011 à 12:47 (CEST)

- Aucune exclusion :
toute page comportant le titre dans sa première phrase est traitée. Ceci comprend les homonymies et les listes qui pour moi répondent finalement aussi bien aux finalités de dfn que les autres. (c'est mes 150%, mais 100% me contentera). TIGHervé 30 avril 2011 à 13:48 (CEST)

• Pages d'homonymie s'il s'agit des pages d'homonymie proprement dites, du type PCF (homonymie) : le titre PCF repris en gras (à l'exception de la mention « (homonymie) » naturellement) n'est pas explicité dans le paragraphe où il se trouve, mais dans les items de la liste qui suit. Ce cas de figure ne répond pas aux règles HTML d'usage de dfn : c'est une exclusion inévitable. Il en sera de même des pages d'homonymie sans introduction, du type Train (homonymie) où les reprises du titre suivies de l'explicitation n'est pas dans un paragraphe, mais dans des items de listes. En revanche, dans les pages du type Train (armée française), l'usage de dfn est tout à pertinent : dfn sera donc utilisé dans les pages listées dans les pages d'homonymie, mais pas dans les pages d'homonymies elles-mêmes.

J'envisageais un balisage a priori de chaque item. TIGHervé 30 avril 2011 à 15:08 (CEST)

Nous sommes bien d'accord que c'est exclu puisque ce serait un usage de dfn non conforme à la spécification HTML ? Cordialement, --Lgd (d) 30 avril 2011 à 15:57 (CEST)

La spécification (ou ses rédacteurs) a-t-elle jamais entrevu le cas d'une page d'homonymie d'une encyclopédie ?
Il est alors exclu que l'on emploie plusieurs dfn dans un article en vertu de la même contrainte ? TIGHervé 30 avril 2011 à 16:15 (CEST)

Sur le premier point, la spécification HTML est tout aussi adaptée à WP qu'à d'autres sites, les contenus de WP n'ayant pas spécificités à cet égard. Il y a plutôt deux choses à prendre en compte:

1. Du côté technique : le format HTML dispose d'un type de liste spécifique pour les contenus qui sont à la fois du type « terme/définition ou description » et qui sont structurés en liste : les listes DL (syntaxe wiki ; et :), d'ailleurs utilisées sur WP dans les pages de glossaires (exemple: Glossaire du cinéma). Si on souhaite introduire la sémantique des définitions dans les pages d'homonymies, ce serait le moyen à adopter, mais ce n'est pas le propos ici.
2. Du côté pertinence : dans tous les cas, indexer les descriptions ou définitions très limitées contenues dans les pages d'homonymie n'est pas nécessaire puisque les définitions/descriptions équivalentes mais plus complètes le seront déjà dans les articles correspondants.

Pour la seconde question : comme expliqué dans le texte actuel de la PDD, celle-ci se limite à un premier usage (aussi simple que possible) de cette sémantique. Il est tout à fait possible en HTML de définir plusieurs termes différents dans des paragraphes différents d'une même page. Mais, ici, éviter les erreurs d'usages sera beaucoup plus délicat dès qu'on sortira du cas des premiers paragraphes introductifs des articles. Ce n'est pas à exclure pour plus tard, mais là encore, ce n'est pas le propos ici.

Cordialement, --Lgd (d) 30 avril 2011 à 16:44 (CEST)

• Pages de liste, je prends l'exemple de Liste des papes : est-il pertinent d'indexer l'expression « liste des papes » avec comme définition « Voici la liste des papes présentée volontairement de la façon la plus simple possible. Afin d'atteindre ce but, les détails et commentaires ont été reportés dans les articles connexes suivants : » ? Peut-on sinon considérer que c'est uniquement une question de rédaction de l'introduction et qu'une autre formulation amènerait un contenu pertinent de ce point de vue ? J'en doute.

Cordialement, --Lgd (d) 30 avril 2011 à 14:36 (CEST)

On balise. Ton exemple est excellent et excellent comme exemple de ce qu'on ne devrait pas rencontrer si facilement. Après je l'ai dit, que ceux qui utilisent cette balise regarde un peu autour pour juger de l'intérêt de l'exploiter. De plus le balisage contribuera(it) à rapprocher symboliquement les listes des articles. TIGHervé 30 avril 2011 à 15:08 (CEST)

Il me semblerait beaucoup plus sage d'éviter absolument la confusion entre ce qui nous occupe ici et le marronnier autour des « listes qui sont des articles ou pas ». Cordialement, --Lgd (d) 30 avril 2011 à 15:57 (CEST)

- J'ajoute une exclusion du même ordre d'idée que les pages de listes : les chronologies où l'on rencontre parfois un paragraphe introductif, du type 2007 en informatique avec « Cet article présente les principaux évènements de 2007 dans le domaine informatique ». Cordialement, --Lgd (d) 30 avril 2011 à 14:42 (CEST)

AdQ et BA comme proof of concept ?

hello,
Il y a une possibilité de déploiement et de test à laquelle nous n'avons pas encore pensé, et qui me semblerait intéressante à plusieurs titres : les AdQ et BA.

Ce pourrait être un champ bien délimité pour une première passe de bots/contributeurs, aussi bien en simulation qu'en déploiement effectif. Cela pourrait aussi rebondir sur le caractère « optimisé » et « exemplaire », donc non contraignant, de ces articles.

Je ne pense surtout pas à une question supplémentaire dans la PDD proposant de limiter dfn à ces articles, mais au contraire à un premier passage dans ceux-ci avant la PDD, à donner en exemple.

Cela exigerait évidemment une discussion préalable et conditionnelle avec les contributeurs qui s'investissent spécialement dans ce type d'article, mais c'est à creuser AMHA. Non ? Cela pourrait être une Preuve de concept utile pour les contributeurs.

Cordialement, --Lgd (d) 2 mai 2011 à 13:01 (CEST)

ol eh ! Si ça ne te dérange pas, il me semble au contraire y avoir pensé au départ. Je crois me souvenir aussi que je ne m'y suis pas arrêté en raison du caractère "optimisé" comme tu dis et de mon caractère ordinairement au contraire "rentre-dedans". Donc maintenant, si ça te paraît prouver quoi que ce soit, ce n'est pas moi qui vais dire que non. TIGHervé 2 mai 2011 à 15:07 (CEST)

Désolé si l'idée avait été évoquée et que cela m'avait échappé, mes plus plates excuses.Sinon, peux-tu expliciter en détail le souci que cela te semble poser, si je comprends bien la suite de ta réponse ? Ce n'est pas forcément une chose à faire, simplement une idée à examiner tranquillement. Cordialement, --Lgd (d) 2 mai 2011 à 15:14 (CEST)

Je pense que le problème évoqué par Hervé est celui-ci : les articles AdQ et BA ne sont pas représentatifs de l'ensemble des articles (ils sont "optimisés" au sens de : plus conformes à ce qu'on attend d'un article, de son paragraphe introductif, etc.). Il faudrait prendre un échantillon plus représentatif (avec des ébauches, etc.). Il me semble que tu avais évoqué un portail, ce qui paraît mieux convenir au niveau échantillonnage.--Juju2004 (d) 3 mai 2011 à 12:57 (CEST)

Pour un même terme plusieurs articles, comment réagir?

Bonjour à tous, ma question est peut-être hors de propos (si c'est le cas n'hésitez pas à me le signaler) mais j’essaie de comprendre le réel intérêt d'utiliser la balise HTML dfn, et surtout, comment l'utiliser à bon escient dans la rédaction (modification) des articles.

Pour cela, j'invente le cas de figure suivant: imaginons que je veuille obtenir la (ou les) définition de A20. J'ouvre mon encyclopédie préférée Wikipédia, je tapote sur mon clavier le mot clé « A20 » dans sont champ de recherche et je valide. J’atterris alors sur la page d'homonymie A20 m'indiquant que ce terme fait référence à une autoroute en France, Italie, Portugal, etc., mais aussi qu'il peut s'agir de l'Aero A.20 un avion biplan monoplace de chasse tchèque, ou encore d'un avion américain, le Douglas A-20 Havoc. Parfait! C'est exactement la réaction à laquelle je m'attends.

Maintenant, pour ce même cas de figure, j'utilise Google avec le mot clé « define: A20 ». Résultat: « Aucune definition de A20 n’a été trouvée en français. ». Comment faut-il réagir? S'empresser de modifier l'ensemble des articles, cités sur la page d'homonymie de Wikipédia, en ajoutant, par exemple, quelque part dans l'introduction de Autoroute française A20 <dfn title="Autoroute française A20" lg="fr">A20</dfn>? Mais dans ce cas, comment faire pour le Douglas A-20 Havoc dont l'écriture correcte est « A-20 » et non « A20 »?

Si je pose cette question, c'est tout simplement que ne comprends pas, actuellement, l'intérêt d'utiliser l'outil define de Google pour rechercher la définition de « Autoroute française A20 » (sachant déjà de quoi il s'agit d'après les mots clés), pour qu'au final il me donne la définition suivante: « L’autoroute française A20, appelée L’Occitane car elle traverse deux régions d'Occitanie, le Limousin et Midi-Pyrénées, est une autoroute française qui relie Vierzon (Cher) à Montauban (Tarn-et-Garonne) via Limoges. ... », tout ça pour me diriger vers l'article Wikpédia Autoroute française A20.

Si je dois utiliser l'outil define de Google (par exemple hein ), ne vaut mieux-t-il pas qu'il me propose les mêmes définitions que la page d'homonymie A20? Ne croyez pas que je suis contre l'utilisation de la balise dfn, loin de là. C'est juste que s'il faut utiliser cette balise encore faut-il qu'elle soit VRAIMENT utile. Au final, j'avoue que dans la PDD, lorsque je lis à la question: À quoi cela sert-il ?, la réponse « À vrai dire, le fait que Wikipédia s'en serve va aussi aider à le savoir:» ne me rassure pas beaucoup.

ps: j'ai utilisé pour cet exemple le mot clé « A20 » (il peut y en avoir beaucoup d'autres), un terme qui peut sembler imprécis, évasif, tout comme la PDD utilise le mot clé « WCAG » qui peut sembler pour certains tout aussi évasif et imprécis.

Merci pour votre attention --86.217.180.95 (d) 4 mai 2011 à 11:26 (CEST)

Bonjour - cette question est si bien posée et si intéressante que j'ai scrupule à y répondre, surtout en béotien.

Il me semble que rien ne porte spécifiquement le nom d'A20 et qu'en conséquence il est normal que rien ne soit définit sur ces trois lettres. Il n'y aurait de ce point de vue rien à faire, rien à modifier. (Cependant) Je serais personnellement partisan de baliser ainsi la page d'homonymie, mais on m'a répondu ci-dessus que ça ne respectait pas du tout les spécifications...

Donc je laisse la parole à plus compétent. TIGHervé 4 mai 2011 à 15:31 (CEST)

J'adore le sarcasme « surtout en béotien », ouah que répondre à ça? « Il me semble que rien ne porte spécifiquement le nom d'A20 », et bien essaie avec A4 qui lui correspond, selon mon dictionnaire le Petit Larousse édition 2008, à un «un format normalisé de papier de dimension 21 x 29,7 cm», mais étrangement Google define ne connaît pas. — Le message qui précède, non signé, a été déposé par l'IP 86.217.180.95 (discuter)

T'as un problème toi. TIGHervé 4 mai 2011 à 18:36 (CEST)

Pour faire vite : 1. je ne suis pas sûr qu'il s'agisse d'un sarcasme de la part d'Hervé, mais même si c'est le cas, inutile de prendre la mouche. 2. si Google Define ne fournit pas d'informations lorsqu'on écrit le mot-clé "A20" ou "A4", c'est d'abord le problème de Google. Comme ça a été évoqué, on ne va pas transformer Wikipédia en Wiktionnaire pour s'adapter à la balise ! 3. Utiliser la page d'homonymie comme source de définitions n'est pas absurde et on peut en discuter. Ce qui ne veut pas dire que ce sera intégré à l'opération qui implique les bots.--Juju2004 (d) 4 mai 2011 à 17:25 (CEST)

J'ai l'impression que la question ne se place pas dans le cadre Wikipédia mais dans celui des moteurs de recherche. En effet, il s'agit ici juste de baliser les termes liés à des définitions. C'est ensuite à l'algorithme utilisé par Google, pour ne choisir que lui, de décider selon toutes les pages qui correspondent à la requête lesquelles sélectionner. Tu peux remarquer que Google liste plusieurs définitions, et même plusieurs sur le même site si nécessaire. Voir par exemple la requête define:aide : http://www.google.fr/search?q=define:aide

Ensuite, est-ce « vraiment utile » ? La recherche de définition amène à mon avis pas mal de visiteurs et contributeurs. Ca ne peut être que bénéfique pour Wikipédia, car cette balise peut avoir un rôle interne (classification, outils de recherche…) et externe (moteurs de recherche en particulier).

Cdt, Cynddl ^{( ⌧ )} 4 mai 2011 à 18:28 (CEST)

La question ne relève en effet pas de Wikipédia. Cette PDD se limite (heureusement) à proposer l'application d'un standard technique, ce qui permet à des moteurs de recherche externe de s'appuyer sur un mécanisme connu et normalisé pour améliorer la pertinence de leur résultat. En revanche, il ne s'agit en aucun cas de dériver de cette simple application des standards Web vers une tentative d'optimisation en fonction de ce que ferait ou non tel ou tel moteur de recherche à sa manière. Le distinguo est un peu délicat, mais il est bien réel. On ne modifiera donc pas telle ou telle sorte de pages en fonction de ce que Google choisira d'en faire. Cordialement, --Lgd (d) 11 mai 2011 à 10:12 (CEST)

Aide au référencement est-il un danger ?

Bonjour,

L'aide au référencement est-elle la vocation de la Wikipédia ou bien un danger ?

Si l'usage de la balise dfn facilite l'accès au contenu du site fr.wikipedia.org via certains outils tels que les moteurs de recherche, alors il probable que plus de personnes auront plus d'intérêt à user de cette balise et à créer dans la Wikiépdia des pages usant de cette balise et portant sur des sujets qu'ils veulent faire bien référencer par les moteurs de recherche.

Prenons deux exemples : une école et un festival. Sans page dans Wikipédia, leur référencement est ce qu'il est. Avec une page dans la Wikipédia, leur référencement est meilleur. Avec une page et la balise, si leur référencement est encore meilleur, alors, il faut que cela soit clair dans la tête de tous les utilisateurs. Personnellement, je suis assez indifférent à cette situation, le Web étant ce qu'il est. Mais sauf erreur de ma part, certains utilisateurs sont réfractaires à l'idée d'user du site fr.wikipedia.org pour améliorer le référencement d'une chose, telle qu'une personne physique, une personne morale, un objet manufacturé ou un évènement, voire même un lieu, tel qu'un point de vente ou un site touristique.

Merci donc à ceux qui savent de nous dire si oui ou non, cette balise aide un directeur d'école à référencer son établissement sur le Web, un directeur de festival son festival, et plus généralement, aide des utilisateurs à référencer tout sujet qu'ils leur tient à coeur. Cordialement. --Bruno des acacias 11 mai 2011 à 09:53 (CEST)

Elle ne change rien à la situation actuelle :

1. un article présent dans Wikipédia sera référencé par les moteurs de recherche, qu'il soit balisé d'une manière ou d'une autre ;
2. le filtrage des articles pertinents ou non dans Wikipédia est un processus interne à WP qui ne se joue pas dans ces questions de balisage technique.

Cordialement, --Lgd (d) 11 mai 2011 à 10:06 (CEST)

Merci. C'est ce que j'avais compris mais, le point précédent de discussion me semblant ajouter une certaine confusion, j'ai pensé que cette clarification pouvait être utile. Cordialement. --Bruno des acacias 11 mai 2011 à 12:34 (CEST)

C'est évidemment la vocation de Wikipédia. Sinon autant fermer et revendre (très cher) le domaine wikipedia.org à un vendeur de V|AGR@. Marc Mongenet (d) 15 juin 2011 à 10:26 (CEST)

Question de vote non neutre

Je suis désolé, mais "Allez-vous trouver cela insupportable si des bots remplacent un ... par un ... ou par un ... dans le premier paragraphe des articles, sachant que c'est utile et que personne ne viendra vous ennuyer si vous continuez à mettre des ... ?" ne me paraît pas être une question rédigée de manière neutre. Une question rédigée de manière plus objective pourrait être : "Etes-vous favorable au changement du remplacement par des bots de ... par un ... ou par un ... dans le premier paragraphe des articles?". Thémistocle (d) 25 mai 2011 à 21:27 (CEST)

Pas d'objection -> intitulé changé.Thémistocle (d) 26 mai 2011 à 23:50 (CEST)

La formulation initiale était simplement un point de départ, il n'y a évidemment aucune objection à une formulation plus factuelle. En revanche, j'ai corrigé la reformulation qui ne correspondait pas à la question en jeu. --Lgd (d) 27 mai 2011 à 10:57 (CEST)

Votre reformulation me va très bien. Je pense que laisser une question de résumé en trois lignes peut être bien pour les personnes ne voulant pas tout lire.Thémistocle (d) 27 mai 2011 à 20:10 (CEST)