Discussion utilisateur:Nemo Le Poisson/Sans Flow

Nemo Le Poisson

Page utilisateur

Discussion

Brouillons

Contributions

Si vous n'aimer pas Flow, vous pouvez me parler ici ! J'y répondrai également ! Sinon, c'est par là.

Ajouter un message

Mieux comprendre Wikipédia

Devenir rédacteur

Vos pages

Rejoindre la communauté

Bienvenue sur Wikipédia, Nemo Le Poisson !

Bonjour, je suis Erdrokan, et je vous accueille en tant que wikipédien bénévole.

Wikipédia est une formidable aventure collective, toujours en construction. La version francophone comporte aujourd'hui 2 653 494 articles, rédigés et maintenus par des bénévoles comme vous et moi. Vous allez y effectuer vos premiers pas : n’hésitez pas à me contacter si vous avez besoin de conseils ou d'aide pour cela, ou à laisser un message sur le forum des nouveaux. Une réponse vous sera apportée avec plaisir !

Wikipédia repose sur des principes fondateurs respectés par tous :

Encyclopédisme et vérifiabilité (s'appuyer sur des sources reconnues) ;
Neutralité de point de vue (pas de promotion) ;
Licence libre et respect des droits d'auteurs (pas de copie ou plagiat) ;
Savoir-vivre (politesse et consensus) ;
N'hésitez pas à modifier (l'historique conserve tout).

Vous êtes invité(s) à découvrir tout cela plus en détail en consultant les liens ci-contre →

Un livret d'aide à télécharger, reprenant l’essentiel à savoir, est également à votre disposition.

Je vous souhaite de prendre plaisir à lire ou à contribuer à Wikipédia.

À bientôt !

P.S. Vos nouveaux messages seront affichés en bas de cette page et signés par leur expéditeur. Pour lui répondre, cliquez sur sa signature (aide).
Erdrokan (discuter) 22 juin 2017 à 21:47 (CEST)[répondre]

Avertissement suppression « Transport en commun en Belgique »

Bonjour,

L’article « Transport en commun en Belgique » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). En tant que participant à l'article ou projet associé, vous êtes invité à donner votre avis à l’aune de l’existence de sources secondaires fiables et indépendantes et des critères généraux et spécifiques d'admissibilité.

N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

Accéder au débat

Chris a liege (discuter) 30 mars 2019 à 02:38 (CET)[répondre]

Ode sur la mélancolie

Merci beaucoup pour votre vote qui a contribué à la labellisation de cet article, désormais . En toute cordialité, --R F sub tegmine fagi (discuter) 17 avril 2019 à 14:42 (CEST)[répondre]

C'est avec plaisir

! -- Nemo ^Discuter 17 avril 2019 à 23:16 (CEST)[répondre]

Merci pour la Grotte de Vogelherd !

Hello Nemo,

Je te remercie infiniment pour ton vote grâce auquel l'article Grotte de Vogelherd a été promu AdQ .
Amicalement, — Ruyblas13 ^{[À votre écoute]} 28 avril 2019 à 08:08 (CEST)[répondre]

Bah de rien ! -- Nemo ^Discuter 28 avril 2019 à 18:10 (CEST)[répondre]

The Legend of Zelda: The Wind Waker

Bonjour.

Vous avez voté pour The Legend of Zelda: Majora's Mask et contribué à sa distinction, je vous en remercie. Une autre page peut éventuellement vous intéresser : The Legend of Zelda: The Wind Waker. J'ai beaucoup développé la page, elle a grandement évoluée et est maintenant au niveau Article de qualité. Il ne reste que quelques jours avant la fin de la procédure, alors je vous propose, si le sujet vous intéresse, n'hésitez-pas à relire et voter Discussion:The Legend of Zelda: The Wind Waker/Article de qualité !

Très cordialement. -- Archimëa [Toc 2 Mi] 14 mai 2019 à 08:42 (CEST)[répondre]

Article sur Nabila Ben Youssef

Bonjour ! J'ai trouvé des sources secondaires neutres et je les ai ajoutées à l'article. Peut-être seriez-vous d'accord d'aller y jeter un coup d’œil et éventuellement reconsidérer votre point de vue ? Braveheidi (discuter) 15 juin 2019 à 00:03 (CEST)[répondre]

. Merci pour ton travail. -- Nemo ^Discuter 15 juin 2019 à 11:03 (CEST)[répondre]

Renommage des Legolands

Bonjour, j'ai été surpris par ton renommage des différentes pages (Legoland Deutschland, Legoland Dubai, Legoland California, Legoland Florida, Legoland Japan et Legoland Malaysia). Cela part d'une bonne intention, mais ce sont pour moi des noms de marques déposées, ils sont en quelque sorte invariables, ils sont inscrits comme ça sur leur logo et ont en plus de ça des noms suffisamment transparents pour être compris par le plus grand nombre. On ne va pas renommer Movie Park Germany ou Disney's California Adventure par exemple. Qu'est ce que tu en penses ? Freddo (discuter) 5 juillet 2019 à 20:11 (CEST)[répondre]

Salut, Freddo cela me paraissait plus logique, il me semble que généralement, on traduit les nom anglais sur WP (à part pour les œuvres comme les films ou livre). La marque déposée ici, il me semble que c'est juste « Legoland », Deutcheland n'est que le lieu. Je trouve personnellement que Legoland Allmagne sonne mieux quand on désigne un parc (contrairement à une œuvre qui donnerait parfois une trad bizarre). Après, je ne pensais pas que ça poserait problème mais si tu veux remettre les mot anglais, cela m'est égal. -- Nemo ^Discuter 5 juillet 2019 à 21:29 (CEST)[répondre]

Merci pour ta réponse. Je vais essayer de me renseigner auprès d'autres contributeur pour ne pas faire d'erreurs. De mon point de vue, il faut conserver le nom original complet, mais je peux me tromper. Je te tiens au courant de mes recherches ! Bonne soirée. Freddo (discuter) 5 juillet 2019 à 22:51 (CEST)[répondre]

Bonjour Nemo Le Poisson, bonjour

Freddo. Je rejoins pour ma part totalement l'avis de Freddo, il met en mots ce que je pense dans le cas Legoland.

Mais pour aller encore plus loin concernant les œuvres, je trouve justement que celles-ci sont parfois traduites pour s'adapter au pays/à la culture où elles sont disponibles, et donc exportées. Tels Orgueil et Préjugés vs Pride and Prejudice dans la littérature ou Pirates des Caraïbes vs Pirates of the Caribbean pour le cinéma. Par contre pour les lieux ouverts au public dans un pays, et donc totalement implantés dans celui-ci, le nom en VO doit être maintenu. Tel Central Park — et tous ses homonymes — qui n'est pas traduit par Parc central, heureusement d'ailleurs. Donc je préconise la VO. Bon week-end à vous. Eliedion (discuter) 7 juillet 2019 à 12:16 (CEST)[répondre]

Merci

Eliedion pour ton avis sur la question. Je vais procéder au renommage de ces pages prochainement. Bon dimanche à tous ! Freddo (discuter) 7 juillet 2019 à 18:29 (CEST)[répondre]

Tête d'enfant de trois quarts à droite BA

Bonjour Nemo,

L'article sur Tête d'enfant de trois quarts à droite vient d'être promu Bon Article.
Merci d'avoir contribué à cette promotion par ton vote positif !

Crijam (Discussion) 7 juillet 2019 à 13:04 (CET)[répondre]

Problème avec ta signature

Salut,

Ta signature comporte une erreur d'imbrication de balises, il faudrait déplacer les ''' fermant la zone de gras pour les mettre après la fermeture des deux balises </small></sup>.

En effet, tu ouvre tes balises dans l'ordre suivant : gras → sup → small. Il faut donc les fermer dans l'ordre small → sup → gras.

Exemple de correction que j'ai effectué sur Wikipédia:Questions techniques/semaine 28 2019 : [1].

Merci.

Bonne journée.

--Tractopelle-jaune (discuter) 12 juillet 2019 à 13:24 (CEST)[répondre]

Merci de m'avoir informé, c'est corrigé. -- Nemo ^Discuter 12 juillet 2019 à 13:34 (CEST)[répondre]

Wikimag n°591 - Semaine 30

Une nouvelle édition du Wikimag est disponible à la lecture.

Commentaires sur l'édition · Écrire une suggestion · Voir toutes les éditions · Se désabonner

OrlodrimBot (d) 30 juillet 2019 à 08:28 (CEST)[répondre]

Avertissement suppression « Flashcode »

Bonjour,

L’article « Flashcode » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). En tant que participant à l'article ou projet associé, vous êtes invité à donner votre avis à l’aune de l’existence de sources secondaires fiables et indépendantes et des critères généraux et spécifiques d'admissibilité.

N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

Accéder au débat

Chris a liege (discuter) 8 août 2019 à 11:21 (CEST)[répondre]

Prévisualiser

Bonsoir. J'ai remarqué que vous avez fait 16 modifications sur cette page [2], mais vous pouvez utiliser le bouton "Prévisualiser". Vous prendrez moins de temps, et sa limitera votre nombre d'interventions nécessaires pour les prochaines modifications. Bonne soirée. Shadow-M-P (discuter) 12 août 2019 à 21:18 (CEST)[répondre]

Merci de votre conseil. C'est vrai que j'aurais pu regrouper certaines de mes modifications mais pas toutes car je fait une modif, puis trouve un autre truc à modifier... -- Nemo ^Discuter 12 août 2019 à 21:40 (CEST)[répondre]

Wikimag n°863 - Semaine 33

Une nouvelle édition du Wikimag est disponible à la lecture.

Commentaires sur l'édition · Écrire une suggestion · Voir toutes les éditions · Se désabonner

OrlodrimBot (d) 19 août 2019 à 08:29 (CEST)[répondre]

Avertissement suppression « Liste des agents XX »

Bonjour,

L’article « Liste des agents XX ^{(page supprimée)} » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). En tant que participant à l'article ou projet associé, vous êtes invité à donner votre avis à l’aune de l’existence de sources secondaires fiables et indépendantes et des critères généraux et spécifiques d'admissibilité.

N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

Accéder au débat

Lebrouillard ^{demander audience} 21 août 2019 à 11:41 (CEST)[répondre]

Merci

Merci de ce vote en faveur de la labellisation de l'article Harvey Comics !

Cordialement, --Olivier Tanguy (discuter) 1 septembre 2019 à 00:02 (CEST)[répondre]

Toy Story

Bonjour Nemo. Concernant l'article Toy Story, je te propose de faire un brouillon de ton coté avec ta vision des choses ("à ta sauce") afin que nous puissions échanger sur quelque chose de concret. --GdGourou - Talk to °o° 2 septembre 2019 à 11:13 (CEST)[répondre]

Salut, @Gdgourou C'est une très bonne idée, je m'y attellerai prochainement ! Étant étudiant, je reprend les cours mais j'essayerai de trouver du temps. Sache par ailleurs que le but de la contestation n'était pas du tout de critiquer le travail remarquable que tu avais fait avec @MicroCitron en 2010 (époque où je ne connaissais même pas WP) mais bien d'améliorer l'article pour le rendre plus fidèle à un AdQ de 2019. Dans mon brouillon, je compte étoffer le RI et le synopsis, ainsi que réorganiser la structure (en mettant la liste des sortie comme boite déroulante dans la section Sortie et accueil, les chansons également dans une boite déroulante dans une section Bande-Son) et inclure toute les voix dans une même section à la sauce de Scream (film)#Distribution. À part ça, je trouve l'article Toy Story impeccable, que ce soit sur la rédaction ou sur le contenu. L'article Toy Story est selon moi, une bonne illustration des problèmes de gabarit actuel du projet Cinéma, et cela permettra sans doute de mieux te faire comprendre mon idée de restructuration. -- Nemo ^Discuter 2 septembre 2019 à 11:52 (CEST)[répondre]

PS: Si j'ai proposé à la suppression le modèle DisneyType, c'est bien parce que je le trouvais doublon, je n'en voyais plus l'utilité à l'heure actuel, et que je pensais que c'était mieux de faire un gabarit pour tous les films confondu. J'admets que proposer le modèle à la suppression en même temps que rediscuter des structure de film n'était pas un bon timing.

Lua

Bonjour,

Ton ajout sur le modèle "Trop d'ouvrage" m'intrigue. Je suppose qu'il s'agit de Lua, mais par quoi et comment ce code peut être utilisé ? Salutations — Vega (discuter) 4 septembre 2019 à 18:52 (CEST)[répondre]

Bonsoir Vega

, TemplateData permet d'utiliser un modèle à l'aide de l'éditeurvisuel. Et ça appose automatiquement le mois et l'année au moment ou un utilisateur a mis le bandeau sur un article. C'est extrêmement utile pour ceux qui n'utilisent pas que le wikicode comme moi. Cordialement, -- Nemo ^Discuter 4 septembre 2019 à 19:00 (CEST)[répondre]

Bonsoir Nemo Le Poisson, comment n'y ai-je pas pensé (je modifie par code aussi). Merci pour l'explication.

NB : ta (nouvelle ?) signature a un effet étonnant sur ta (vieille) PDD, probablement à cause d'un "small" mal fermé =) — Vega (discuter) 5 septembre 2019 à 00:49 (CEST)[répondre]

Je disais l'inverse, comme moi qui n'utilise pas toujours le wikicode.

Pour ma signature, il semblerait que ce soit réglé. -- Nemo ^Discuter 5 septembre 2019 à 14:04 (CEST)[répondre]

Sections templatedata mal placées

Bonsoir et merci d’ajouter des sections templatedata aux modèles qui n’en ont pas !

Par contre, il faut mettre impérativement ces sections à l’intérieur de la documentation :

soit dans la sous-page de documentation lorsqu’elle existe
soit dans le paramètre contenu du modèle {{Documentation}}

Dans le cadre d’autres maintenances j’ai eu à corriger tes ajouts (exemple). Ta manière de procéder fait que la section se trouve en dehors de la documentation et que le modèle apparaît dans la liste Projet:Modèle/Maintenance/Listes# Modèles avec du contenu non standard en noinclude.

On y trouve d’ailleurs dans cette liste un autre problème te concernant .

Pourrais-tu effectuer ces corrections ?

Je reste à ta disposition si tu as des questions.

Merci.--FDo64 (discuter) 5 septembre 2019 à 22:23 (CEST)[répondre]

@FDo64 Ah, désolé, je vais corriger ça sur base de ceux qui sont dans la catégorie, merci de m'en avoir informé. Heureusement, ce n'est qu'une petite partie des modèle où j'ai ajouté Template

. Je vais essayer de tous les corriger ce matin vu que j'ai du temps. -- Nemo ^Discuter 6 septembre 2019 à 10:15 (CEST)[répondre]

FDo64 : J'ai tout corrigé je crois. Par contre, j'ai pas compris pourquoi il y a parfois des modèles inclus dans la liste mais qui n'ont que la documentation dans les balise noinclude (et le problème avec le modèle contradiction). Peux-tu me confirmer que tout est bon pour toi ? -- Nemo ^Discuter 6 septembre 2019 à 11:15 (CEST)[répondre]

Remerciement

Bonsoir,

Je tiens à vous remercier pour votre accueil.

Je vous recontacterai si besoin.

--Hammi2u (discuter) 24 septembre 2019 à 21:22 (CEST)[répondre]

Bienvenu Hammi2u ! Je vois que vous suivez les cours du Wikimoc mais vous pouvez aussi venir vers moi si vous avez besoin d'aide ! -- Nemo ^Discuter 1 octobre 2019 à 17:00 (CEST)[répondre]

Remerciements

Merci pour le commentaire et le vote ayant permis la labellisation de l'article Arsène Lupin.

Bien cordialement,--Kasskass (discuter) 16 décembre 2019 à 10:39 (CET)[répondre]

Derien, l'article pourra encore s'améliorer (cf remarque de Sammyday sur d'autres sources dispo apparemment) mais bravo pour ton travail qui mérite bien cette belle étoile dorée. -- Nemo ^Discuter 16 décembre 2019 à 17:24 (CET)[répondre]

Réflexions concernant les descriptions TemplateData

Salut Nemo Le Poisson,

Je vois que tu t'investis pas mal dans la mise en place de données TemplateData, je ne peux qu'approuver et te féliciter, m'étant toujours senti un peu seul dans ce domaine (bénéficiant quand même d'aide ponctuelle de certains contributeurs). Par la force des choses, il est vrai que je suis devenu assez expert du système TemplateData, de ses possibilités, et surtout de ses limites pénibles (voir phab:tag/templatedata pour toutes les fonctionalités demandées depuis longtemps). Je suis d'ailleurs aussi l'auteur comme tu le sais de la réécriture de 2018 de Aide:TemplateData.

J'avais déjà commencé en 2019 l'ajout au minimum du format d'indentation à de nombreuses infobox (afin de mettre un terme au massacre par l'éditeur visuel de l'indentation (alignement des paramètres et de leurs valeurs)). Exemple ici : [3].

Au fil du temps, sont venues diverses réflexions de ma part sur l'utilisabilité des modèles dans l'éditeur visuel (je m'intéresse surtout à lui, car les autres outils comme TemplateWizard sont plus destinés à des contributeurs maîtrisant un minimum le wikicode, et sachant assez facilement chercher par eux-mêmes ailleurs d'éventuelles informations sur le fonctionnement des modèles).

Je me suis rendu compte qu'en utilisant vraiment différents modèles depuis l'éditeur visuel, un certain nombres de petites choses pouvaient faciliter la compréhension et l'utilisation des modèles via les données TemplateData, et surtout leur cohérence.

Cela consiste bien entendu à minimiser le nombre de paramètres marqués "suggéré" à ceux utilisés le plus fréquemment (sachant qu'ils sont systématiquement insérés dans le wikicode, même vides, pour les infobox, c'est généralement pas problématique, voir carrément voulu, mais pour les autres modèles, c'est vite pénible).

Une autre chose, c'est que parfois il manque des explications additionnelles pour un paramètre sur comment faire telle ou telle chose. Exemple ([4] [5] pour les points manquants) : J'ai ajouté dans la description de deux paramètres comment faire pour modifier le texte affiché d'un lien. La description des deux paramètres concernés est donc passée de « Nom d'un article. » à « Nom d'un article. Pour modifier le texte affiché du lien, saisissez « {{!}} » après le nom de l'article, suivi du texte à afficher. »

C'est tout bête, il ne s'agit pas de surcharger les descriptions avec trop d'explications, mais là, c'était quelque chose qui manquait (cette méthode doit être utilisée chaque fois que l'on veut faire un lien vers une section, sans afficher l'ancre). Ces explications étaient naturellement présentes sur la page de documentation du modèle, mais l'information n'était pas disponible pour les utilisateurs de l'EV ignorant cette technique.

Lors de ces tests d'utilisabilité, je me suis aussi rendu compte de quelque chose de pas pratique du tout, c'est quand on veut insérer un modèle depuis l'EV, mais que l'on ne connaît pas son nom exact. Chose fréquente pour bon nombre d'utilisateur de l'EV.

Car lorsque l'on cherche à insérer un modèle depuis l'EV (que ce soit en tapant {{ ou via le menu « Insérer » → « Modèle »), et que l'on commence à taper les premières lettres, on devrait pouvoir s'aider du début de la description du modèle. Hors bien trop souvent, le début de la description visible est inutilisable pour clarifier les choses, à quoi sert le modèle, etc. Tout simplement car conçu comme une phrase littérale, du genre : « Ce modèle permet d'ajouter ceci pour les articles concernant cela ».

Exemple plus parlant :

Je souhaite ajouter un lien vers un article approfondissant un sujet traité dans une section, sous la forme d'un bandeau de section. Je sais qu'il y a un modèle pour ça, qui doit se nommer article quelquechose.
J'ouvre donc dans l'EV la fenêtre d'insertion de modèle, et je tape « Article ». Apparaît alors divers modèles, dont {{Article}} et {{Article détaillé}}. Voici les descriptions affichées visibles à l'époque pour ces deux modèles :
- Article
  Pour citer un article en tant que ...
- Article détaillé
  Ce modèle, en début de section,...

Voici les descriptions complètes :

{{Article}} : « Pour citer un article en tant que référence (menu "Citer") ou l'insérer dans un modèle (menu "Insérer"), remplir les champ suivants. Les astérisques (*) désignent les champs obligatoires pour que la référence ou le modèle s'affiche correctement. Un « article » peut être n'importe quelle contribution à une publication en série : périodique, journal, magazine, revue scientifique{{etc.}}" »
{{Article détaillé}} : « Ce modèle, en début de section, met en exergue un ou plusieurs autres articles approfondissant le sujet de la section. »

Commentaires : Description indigeste pour l'un, indiquant quand même plus ou moins à quoi ce modèle sert, mais rempli d'informations inutiles (comment insérer un modèle, ben je le sais, c'est ce que je suis en train de faire...) Pour les champs obligatoires, l'interface d'insertion de modèle gère déjà ça très bien. Et pour finir, voir affiché un « {{etc.}} » à la fin est un peu bizarre (le gentil contributeur a cru bien faire, mais les modèles ne sont pas transclus dans les descriptions...). Pour l'autre, les répétitions du genre « Ce modèle sert à ... » sont inutiles, puisque l'on sait déjà que l'on est en train d'insérer un modèle servant à quelque chose...

C'est à ce moment-là que j'ai pris conscience de l'importance de se mettre du côté de l'utilisateur de l'éditeur visuel, de préférence un utilisateur débutant. J'ai donc modifié ces descriptions en :

{{Article}} : « Modèle de source pour citer un article en tant que référence. Un « article » peut être n'importe quelle contribution à une publication en série : périodique, journal, magazine, revue scientifique, etc. » ([6])
{{Article détaillé}} : « Bandeau de section pour lien vers un ou plusieurs articles approfondissant le sujet. » ([7])

Ce qui permet, que par exemple sur l'ordinateur sur lequel je suis, je vois les descriptions suivantes :

Article
Modèle de source pour citer un art...
Article détaillé
Bandeau de section pour lien vers ...

Avouons que c’est quand même plus intelligible et clair qu'avant (sans être parfait pour autant). Le premier modèle s'appelle article, donc préciser que c'est un « modèle de source », et qu'il permet de « citer » un article (même si on voit pas le mot article) apporte plus d'informations qu'avant (à savoir modèle de source citer). Pour le second, on indique « bandeau de section » et « lien », sachant que le terme « Article détaillé » est fourni par le nom du modèle. Je ne sais pas si tu vois ou je veux en venir, mais je pense que oui.

Je suis donc arrivé à la conclusion qu'il faudrait essayer de limiter le texte redondant et inutile, et au moins essayer d'indiquer de quel type de modèle il s'agit, et si possible son but, le tout de manière semi-standardisée, pour faire plus propre. Essayer d'avoir une certaine systématique pour ajouter plus de clarté quand on cherche un modèle dans l'EV.

Ainsi, j'ai imaginé comme règle personnelle qu'un modèle affichant un bandeau de section devrait avoir une description commençant par « Bandeau de section », car ainsi on indique un élément important, il y aura peut-être deux-trois modèles commençant par la même chose, mais en passant la souris dessus, on verrait le reste. Si c'est un modèle pour des sources, j'ai imaginé « Modèle de source », pour une infobox : « Infobox pour un objet ».

Certains modèles resteront trop compliqués à expliquer, mais je pense que les trois quarts des modèles peuvent avoir une description plus pertinente.

Ce sont des règles personnelles, étant le seul à me préoccuper de ce thème, et en plus de manière récente, je n'ai encore rien rédigé sur Aide:TemplateData, pour plusieurs raisons : Manque de temps, seul à travailler sur ce genre de problématiques, et surtout absence totale de consensus possible, car personne ne s'occupait de TemplateData de manière générale à part moi... Puis j'ai arrêté de contribuer depuis août 2019 jusqu'en février 2020. C'est pour ces raisons que rien n'avait avancé sur ce point jusqu'à maintenant. Mais vu qu'il y a maintenant un autre contributeur préoccupé par les données TemplateData, ayant en plus davantage de temps que moi, je me dis que c'est peut-être le moment d'essayer de mettre au point quelques conseils (absolument non obligatoires), sous forme de bonnes pratiques, pour améliorer la cohérence, l'intelligibilité et l'utilisabilité des descriptions TemplateData des modèles depuis l'éditeur visuel.

Je vais prendre l'exemple du modèle {{Infobox Drapeau}}, tu as ajouté la description « Ce modèle permet de présenter les caractéristiques d'un article consacré à un drapeau. ». C'est une très belle phrase, c'est comme ça que j'écrivais les descriptions TemplateData de modèles pendant 2 ans.

Mais quand je veux insérer le modèle dans l'EV, voici ce qui s'affiche chez moi :

Infobox Drapeau
Ce modèle permet de présenter les...

Une description suivante serait mieux :

Infobox Drapeau
Infobox pour un drapeau

On peut toujours faire un « Infobox pour un drapeau. Permet de présenter les différentes caractéristiques d'un drapeau » pour ceux qui trouveraient trop court (même si je pense qu'il est possible de s'en passer dans certains cas). Mais quel que soit la longueur finale de la description, on comprend tout de suite plus facilement à quoi correspond cette infobox.

Voilà, j’attends ton avis sur ce sujet complexe, encore peu exploré, mais sur lequel il y aurait matière à travailler pour moi.

Dans tous les cas, un grand merci pour ton travail de documentation des modèles, tu reprends un peu une partie de mon travail que je n'ai plus le temps de faire.

Bonne soirée.

[édit.] En complément, j'oubliais, quelques conseils et tests divers concernant les descriptions, que j'ai rassemblé sur une de mes pages brouillons : Utilisateur:Tractopelle-jaune/BrouillonJ. N'hésite pas à compléter.

--Tractopelle-jaune (discuter) 27 mars 2020 à 22:09 (CET)[répondre]

Merci pour ces réflexions @Tractopelle-jaune, je suis tout à fait prêt à reprendre Aide:TemplateData avec toi et d'essayer de faire évoluer les pratiques autour de ce sujet.

Au sujet des fonctionnalités indpispensable qu'on a pas encore quand on est dans l'éditeur visuel j'en ai listé deux :

Permettre qu'un modèle soit substé soit par défaut soit en cochant une case lorsqu'on insère un modèle avec l'éditeur visuel. Actuellement c'est impossible ! sauf si on écrit par défaut subst:Nom du :modèle
Permettre de retourner dans l'onglet de recherche si en lisant la description détaillé et les paramètre d'un modèle, on se rend compte que c'est pas le bon !

Au sujet de l'outil de recherche en lui-même

Lorsqu'on cherche une redirection de modèle, mettre le titre du modèle avec un (redirigé depuis...)
Ne pas suggérer les modèles contenant dans leur doc un {{Modèle obsolète}}
Prendre en compte le autres mots d'un modèle dans la recherche pour avoir un vrai outil. Je te rejoins à 100% sur le problème actuel de « quand on veut insérer un modèle depuis l'EV, mais que l'on ne connaît pas son nom exact » c'est galère pour le moment !
Permettre de rechercher un type de modèle particulier : infobox, bandeau, modèle de réponse...

La première est déjà liste dans Phabricatoir, j'espère que ça verra le jour de même pour les autres !.

Au sujet de l'outil TemplateData :

Lorsqu'on fait une erreur, au lieu de nous empêcher de valider notre contrib, il pourrait nous dire où est l'erreur ! L'outil externe JSonlint le fait déjà !
Permettre de rendre ça plus rapide comme le font d'autres outils externe !
Changer plus facilement l'ordre des paramètre en les faisant directement glisser, pour le moment c'est très galère, soit on les ajoute un par un dans le bon ordre, soit on doit modifier le code du TemplateData à la main !
Permettre de rajouter des liens interne dans la description de TemplateData pour que ne pas devoir en plus écrire une autre description dans la documentation (cf bas).

Au sujet des description de modèle :

Je te rejoins au sujet de la complexité quand on est débutant de trouver le bon modèle, (et même après). La première solution serait de clarifier les noms de modèle. Par exemple : Tout les bandeaux de section commence par « Section à ... ». J'estime que le titre du modèle devrait directement nous apprendre de son utilité.

Au sujet des docs de modèle :

Où placer TemplateData ? C'est très confus ! Parfois ils sont dans une section à part parfois dans utilisation... Je me suis une fois fait reverté car on trouvait redondant que je rajoute la description alors qu'elle était mise haut... Il faudrait donc si ma proposition de liens interne (cf plus haut) est acceptée que les description dans la doc soient toujours mise avec TemplateData !

Voilà, pour toute ces réflexion, je pense qu'elles auraient leur place sur une partie/section du Projet:Modèle en plus de Aide:TemplateData qu'on devrait peut-être revoir avec une aide de base, une aide avancée et une page de recommandation ? Il serait certainement utiile d'en discuter avec la communauté car l'insertion des modèles dans l'éditeur visuel est qqchose de très important, surtout pour les nouveaux ! Si tu es très occupé IRL, pas de problème on avancera à ton rythme ! -- Nemo ^Discuter 30 mars 2020 à 18:31 (CEST) (mis à jour dû aux améliorations le 11 juillet 2022).[répondre]

Autre question en passant, quel est la différence entre Templatewizard qui s'utilise avec l'édition en wikicode si je ne m'abuse et l'outil en Éditeur visuel ? Ils utilisent tous les deux les données de TemplateData non ? -- Nemo ^Discuter 30 mars 2020 à 18:36 (CEST)[répondre]

Nemo Le Poisson : Merci pour ton retour.

Concernant les fonctionnalités demandées, on ne peut pas faire grand-chose d'autre qu'attendre, mais faut pas se faire de faux espoirs, TemplateData n'est pas du tout la priorité des devs à l'heure actuelle. Pour moi, c'est une extension sur laquelle je n'ai aucune attente de nouvelles fonctionnalités pour le moment, je fais avec ce que l'on a déjà.

Pour la recherche d'un modèle, étant donné que l'on ne peut pas agir sur le logiciel, il n'y a que deux volets sur lequel on peut agir pour la faciliter :

Le nom du modèle,
La description.

Mais pour le nom des modèles, c'est extrêmement délicat, et sauf dans de très rares cas, je déconseille fortement d'y toucher, car c'est un truc à partir dans des débats et controverses stériles avec les contributeurs des projets concernés. Sur ce point-là, j'applique aussi le principe du « faire avec », je n'y touche pas. La plupart des modèles existent depuis plus de 10 ans, et leurs noms et usages sont profondément ancrés. Bref, je « fais avec ».

Par contre, sur la description des modèles, il y a matière à agir, car là on peut faire la différence en cherchant un modèle. Et éviter une partie de ces pénibles aller-retours nécessitant de fermer la fenêtre d'insertion de modèle pour la ré-ouvrir quand le modèle n'est pas le bon (en l'absence de bouton retour). D'où les propositions et pratiques personnelles décrites plus haut.

Concernant le placement des données TemplateData, personnellement, sauf cas particuliers, je les place dans une section « TemplateData », à la fin, mais juste avant une éventuelle section « Voir aussi » ou « Modèles connexes ».

Exemple de schéma :

...

== Paramètres/Utilisation ==
...

== TemplateData ==
<templatedata>
...
</templatedata>

== Voir aussi ==
...

{{Projet|Modèle|...}}

...(catégories)...

Mettre les données TemplateData dans une section nommée « TemplateData » permet de bien délimiter et expliciter qu'il s'agit de données spécifiques.

Une des seules exceptions à ce principe, c'est que parfois, au lieu d'avoir une section « Paramètres » avec la description des paramètres (en wikicode), c'est le bloc TemplateData qui fait office de tableau ou liste des paramètres (j'ai déjà vu ça quelques fois pour des modèles assez simples). Mais ce n'est pas un objectif pour moi de remplacer des sections « Paramètres » rédigées en wikicode par les données TemplateData. On y perd souvent des informations, de la mise en forme, c'est très rigide, et on s'attire vite des ennuis (justifiés)...

Il est peu probable à mon avis, et ce même si tous les souhaits de développement étaient miraculeusement exaucés, que TemplateData remplace un jour les bonnes vielles descriptions et documentations de modèles rédigées à la main, sauf pour les modèles très simples. Avant tout pour une question de flexibilité, de mise en forme, d'usage, etc.

Moi j'applique la philosophie de « faire avec » ce que l'on a déjà. Sachant que les infobox correctement documentées au niveau TemplateData sont très minoritaires, que même pas encore toutes les infobox ont au moins un format d'indentation personnalisé pour éviter de casser l’alignement vertical des paramètres, que les descriptions sont souvent inutilisables, lacunaires ou encore remplies d'informations inutiles.

Avant de commencer à écrire de nouvelles recommandations hors-TemplateData, ne pas oublier comment a tourné le Projet:Modèle/Harmonisation (voir aussi Discussion Projet:Modèle/Harmonisation). Lancer des chantiers trop complexes et impactant de multiples projets est tout simplement irréaliste. D'autant plus que la plupart des modèles existent depuis longtemps déjà. On ne crée presque plus de nouveaux modèles « courants » de nos jours. Les modèles qui sont maintenant créés sont très spécifiques à des projets et cas précis, et généralement utilisés que sur quelques pages.

Pour toutes ces raisons, concernant notre sujet TemplateData, je suis d'avis de d'abord concentrer les efforts sur trois points importants, qui sont, à l'heure actuelle, non controversés :

Format d'indentation personnalisé pour les infobox (même si on ne complète pas la description et les paramètres), car cela réduit l'impact de l'éditeur visuel sur la mise en page des infobox. source de plainte et de mauvaise image de l'éditeur visuel.
- C'est ce que j'ai fait régulièrement pendant quelques mois. Et un format d'indentation pertinent ne correspond pas forcément au plus long paramètre. il faut tenir compte des paramètres les plus utilisés. S'aider de l'outil https://wstat.fr/template/ pour vérifier quels sont les paramètres les plus utilisés d'un modèle, et agir en conséquence. La longueur d'un paramètre utilisé moins de 5 à 10 % des cas ne devrait pas être prise en compte (sauf cas particuliers).
Documenter les différents paramètres (et le faire bien), et ça c'est bien plus difficile qu'on ne le pense. Car il faut parfois donner des consignes spécifiques, indiquer qu'il vaut mieux utiliser tel autre paramètre dans tel cas (en pensant à indiquer le nom affiché du paramètre, et non le nom technique en wikicode).
- Très important aussi pour la clarté, ne pas hésiter à adopter la convention suivante pour plus de clarté dans le nommage TemplateData des paramètres : Les nommer par groupe (pour la cohérence). Exemple pour une infobox :
  - image → Image
  - légende → Image - légende
  - taille image → Image - taille
- Avec cette convention de nommage, on « masque » pour l'utilisateur de l'éditeur visuel le nom « technique » (en wikicode) des paramètres, qui bien souvent n'a pas trop de logique, et varie entre les modèles. Par contre, il faut être très vigilant à ce que les mentions de ces noms de paramètres modifiés dans les descriptions d'autres paramètres (dans les données TemplateData) soient ajustées en conséquence. Afin que le tout reste cohérent. Exemple plus parlant : dans une description TemplateData d'un paramètre, parler de « Pour modifier la taille de l'image, utiliser le paramètre « Image - taille ». » et non « taille image ».
- Je t'invite à regarder les données TemplateData d'{{Infobox Cours d'eau}}, que j'ai entièrement complétées de manière très poussée il y 2 ans. J'utilise pas mal la convention Nom du paramètre - complément. Cela facilite grandement la recherche des paramètres optionnels. Au lieu de vouloir chercher à renommer en dur (wikicode) des paramètres aux noms incohérents, on peut tout simplement faire « disparaître » ce problème dans l'éditeur visuel avec le nom donné dans TemplateData.
Importance de la description du modèle, surtout les 4 à 6 premiers mots, qui sont souvent les seuls visibles dans l'éditeur visuel quand on recherche un modèle. Essayer d'avoir une certaine cohérence « Bandeau de section pour ... », « Modèle de source pour ... », « Infobox pour un ... », etc. Tout cela permettrait de gagner en cohérence, faciliter la recherche de modèles et leur utilisation, le tout sans s’attaquer à des points critiques ayant des implications notables sur les autres contributeurs.

Pour ta dernière question, oui l'outil TemplateWizard utilise les données TemplateData, mais dans les différents éditeurs de wikicode. Il dispose d'une interface assez différente de celle de l'éditeur visuel. Et surtout, il ne peut servir qu'à ajouter un modèle, mais pas à le modifier (pour le moment). Donc l’intérêt est plus réduit dans le cas des infobox et autres modèles que l'on modifie plus que d'en insérer de nouveaux. Et les utilisateurs du wikicode sont généralement plus à l'aise pour chercher dans les pages de documentation des modèles en cas de doute.

Bonne soirée.

--Tractopelle-jaune (discuter) 30 mars 2020 à 20:25 (CEST)[répondre]

Nemo Le Poisson : Bravo pour l'ajout des données TemplateData. Je n'arrête pas de voir passer dans ma LdS tes modifs (j'ai une grande partie des infobox et leurs documentations associées en LdS).

Juste quelques petites remarques :

Habituellement, sur les documentations de modèles, on a le plan suivant :

== Utilisation == : Consignes d'utilisation diverses, pas obligatoire, souvent inutile dans le cas des infobox, ce contenu (généralement seulement constitué d'une ou deux phrases) pouvant aisément être mis directement dans le RI de la doc du modèle (ce que je fais souvent). Là, ce n'est qu'une question de préférence personnelle (tant que l'ordre et le nom des sections sont respectés).
== Syntaxe == : Code vierge à copier dans les articles, en tout cas la version de base.
== Paramètres == : Détails des paramètres, généralement rédigé en wikicode, peut aussi être remplacé par le bloc TemplateData pour les modèles assez simples.
== Exemple == : Un ou plusieurs exemples de rendu.
== TemplateData == : Le bloc de données TemplateData, à moins qu'il ait été placé dans la section « Paramètres ».
== Voir aussi == ou similaire : Si modèles connexes.

Tout particulièrement, il est habituel de mettre d'abord la section « syntaxe » du modèle (le code à copier), et ensuite seulement la liste des paramètres (que celle-ci soit écrite en wikicode ou via le bloc TemplateData) ; ex : [8] :

Sur ce point encore, afin de garder une certaine cohérence dans les documentations (important notamment pour les utilisateurs de lecteur d'écran (malvoyants) afin qu'ils sachent où trouver l'information recherchée, sans devoir « rentrer » dans toutes les sections une à une). Pour cette raison, la section contenant l'explication des paramètres ne doit pas s'appeler « Utilisation », mais « Paramètres ». Il faut réserver le terme « Utilisation » pour les éventuelles explications introductives du modèle, et les éventuelles instructions d'utilisation spéciales. Et sauf cas particulier, la section « Syntaxe » va avant la section « Paramètres ».

D'autant plus que les sections nommées « Utilisation » ou « Utilisation et paramètres » seront fréquemment sautées par les utilisateurs de lecteurs d'écrans, car ces sections contiennent souvent pas mal de fatras inutile (et souvent peu accessibles, notamment à cause de tableaux) issus du code de documentation par défaut, avec les instructions sur comment insérer le modèle dans l'éditeur visuel (exemple de code que j'ai supprimé : [9]).

Autres petites remarques :

Les modèles {{Projet}} avec les projets concernés (infobox, sinon modèle) devraient idéalement êtres placés dans la partie en <includeonly></includeonly> car ils sont catégorisants, sans ça, on catégorise la page de doc tout comme le modèle.
Parfois certains paramètres ne devraient pas êtres marqués comme suggérés, surtout les paramètres extrêmement peu utilisés (et ce n'est pas parce qu'ils sont indiqués dans le code à copier que c'est forcément pertinent de les copier (exemple : [10], même si dans le cas présent, tu n'as fait que reprendre logiquement le code par défaut)
Attention à ne pas laisser de paramètres TemplateData "label" vides, c'est soit remplis, soit inexistants (afin que le nom du paramètre soit repris comme titre). Sinon cela provoque des bugs bizarres (ex. [11])

Ce sont justes quelques remarques en passant, j'espère que tu ne les prendras pas mal, mais vu que ce n'est que le début d'une phase massive d'ajouts de données TemplateData diverses, autant éviter de devoir trop repasser derrière, et de pouvoir garder une certaine cohérence entre documentations

Et une petite explication sur les lecteurs d'écrans (que le rendu soit fait par synthèse vocale ou plage braille) :

En simplifiant, il faut savoir que ces logiciels proposent généralement deux modes d'utilisation, et que l'on jongle continuellement d'un à l'autre :

Un mode navigation basé sur l'arborescence de la page, qui permet de sauter entre les éléments de même niveau, de rentrer ou sortir d'un élément, etc., afin d'aller là où l'on souhaite. Une fois cet élément atteint, on peut basculer en mode lecture.
Un mode lecture (par exemple pour lire un article, une section, un paragraphe, etc). Ce mode lit de manière généralement linéaire depuis la position où l'on se trouve, en rentrant dans tous les éléments pertinents).

Par exemple, imaginons que je viens chercher une info sur un paramètre dans la documentation d'un modèle, une fois arrivé sur la page, en mode navigation, je parcours les titres des différents éléments <h2> (ce sont les titres de section de 2e niveau, générés avec == Titre de section ==), mais sans rentrer dans ces éléments. Une fois trouvé la section s'appelant « Paramètres », je rentre dedans, je navigue pour comprendre sa structure (liste à puces, liste de définition, tableau standard, tableau TemplateData), puis je rentre dans cette liste ou tableau. Ensuite cela dépend de la structure de la liste, de l'outil utilisé, des habitudes du l'utilisateur (cela peut être navigation, recherche dans le bloc, lecture linéaire, etc.).

Je t'invite aussi à prendre connaissance de WP:AA/BP pour toutes les bonnes pratiques d'accessibilité (rassure-toi, tu ne peux jamais tout mettre en œuvre, mais cela permet de prendre conscience de l'importance de certains détails et pratiques problématiques.

Autrement, encore une fois bravo, et bonne après-midi à toi.

--Tractopelle-jaune (discuter) 6 avril 2020 à 14:46 (CEST)[répondre]

TemplateData, la suite !

Hello Tractopelle-jaune : ! Je suppose que tu as vu passé le changement d'interface pour l'insertion de modèle. Désormais c'est le même en wikicode comme en Éditeur Visuel, et les descriptions sont visible par défaut. J'aime beaucoup ! Il y a aussi les paramètres suggéré. Dommage par contre que le dévelopement du nouvel éditeur TempleData est arrêté pour le moment. (Qui rendait plus visible la possibilité d'afficher les paramètres dans un certain ordre, et qui documentait tout directement). Enfin, l'outil de recherche intègre maintenant les mots-clés, et j'ai même l’impression que les débuts de descriptions des modèles, affichent plus de caractères qu'avant.

Bref, il va falloir actualiser Aide:TemplateData. Je peux m'y atteler, mais comme tu as écrs 90% de la page actuelle, tu serais aussi d'une grande aide . -- Nemo ^Discuter 27 novembre 2021 à 21:00 (CET)[répondre]

Nemo Le Poisson : Merci pour la notif.

J'ai vu passer les changements, et c'est au programme pour le milieu de la semaine prochaine (normalement à partir de mercredi). J'ai pas mal de points sur ma todo-list concernant cette page d'aide.

Je vais essayer de faire un tir groupé, et d'écluser ainsi tout ce qui traîne sur ma todo-list (et dans ma tête) concernant cette page d'aide.

Il y a aussi les bonnes pratiques que je dois encore compléter, et quelques autres bricoles qui manquent de clarté, et qui traînent depuis un moment (voir aussi ma PdD), issues entre autres d'échanges avec Thomasbr33.

Et au passage, merci à Thomasbr33 et toi pour votre aide concernant TemplateData. Car — bien que vous ne soyez évidement pas les seuls à compléter ces données — vous êtes par contre parmi les rares à aller au-delà de la simple saisie des libellés et descriptions pour les quelques modèles qu'ils utilisent fréquemment. Donc merci.

--Tractopelle-jaune (discuter) 28 novembre 2021 à 11:43 (CET)[répondre]