Discussion utilisateur:Ideawipik

Mieux comprendre Wikipédia

Devenir rédacteur

Vos pages

Rejoindre la communauté

Bienvenue sur Wikipédia, Ideawipik !

Bonjour, je suis Bastenbas, 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 606 506 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 :

  1. Encyclopédisme et vérifiabilité (s'appuyer sur des sources reconnues) ;
  2. Neutralité de point de vue (pas de promotion) ;
  3. Licence libre et respect des droits d'auteurs (pas de copie ou plagiat) ;
  4. Savoir-vivre (politesse et consensus) ;
  5. 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).
Bastenbas (discuter) 27 juin 2018 à 22:24 (CEST)[répondre]

Lien interne sur les paramètre "site" du modèle" lien web"[modifier le code]

Bonsoir,

la doc de {{lien web}} est explicite : « site : indiquer le nom du site (avec un wikilien vers l'article Wikipédia, s'il existe) ou, si le nom du site n'est pas explicite, une description en quelques mots. Correspond au champ work sur la Wikipedia anglophone. » et la pratique répandue, alors je remets le lien interne retiré par cette diff : [1]. Sans reverter puisque l'erreur de syntaxe était belle et bien réelle, merci pour la correction.

Bonne soirée,

--Gaillac (discuter) 27 septembre 2018 à 21:47 (CEST)[répondre]

Pas de problème. Merci pour la remarque et allez le TFC!

Rép: Nationalités dans tableaux d'éffectif[modifier le code]

Bonjour. Je m'excuse, mais je pense que vous vous avez trompé.

  • Je ne suis pas complètement sûr si Gloire Amanda est actuellement admissible. Cependant, je suis sûr qu'il n'est jamais sélectionné par l'équipe principale du Canada. Il était seulement sélectionné par l'équipe des moins de 18 ans en 2015 pour un tournoi. C'est à dire que c'est encore possible qu'il sera sélectionné par l'équipe principale de la Tanzanie.
  • Mon référence a déjà spécifié que Domonick Zator possède la nationalité polonaise. Donné qu'il n'est jamais sélectionné par l'équipe du Canada, il reste admissible par l'équipe polonaise. À mon humble avis, ce n'est ni possible ni nécessaire de spéculer «pour quelle séléction aspire-t-il à jouer» (). Je personnellement connais une joueuse, qui a toujours vécu au Canada mais qui était sélectionné par l'équipe polonaise des moins de 17 ans pour le tournoi de la UEFA. CÉDRIC — A:CU 15 octobre 2018 à 19:46 (CEST)[répondre]

Module:Sports table/sub.colhead[modifier le code]

Lorsque tu ajoutes un paramètre à une fonction Lua, il est préférable

  • de l'ajouter à la fin des paramètres existants
  • de rendre ce paramètre facultatif

Cela évite d'avoir à modifier tout les appels à cette fonction pour lesquels ce paramètre n'est pas nécessaire.

Cette fonction colhead est par exemple aussi utilisée sur Module:Sports table/WL OT, ce qui génère une erreur dans la doc (visiblement les pages qui utilisent actuellement ce module ne passent pas par cette fonction, ouf). Si tu pouvais aussi mettre ce module à jour...

— Zebulon84 (discuter) 7 novembre 2018 à 17:01 (CET)[répondre]

Notification Zebulon84 : Bonjour, et merci pour ce rappel. Avant d'intervenir dans ces modèles/modules, j'avais bien regardé avec précaution où ils étaient utilisés.
Le paramètre style est un paramètre de la sous-fonction et non un paramètre du module. Il a été ajouté suite à cette discussion et à la remarque sur la forme du tableau (Matpib 26 septembre 2018 à 08:31). Je n'avais pas pris le temps, à tort de modifier le Module:Sports table/WL OT, le sachant inutilisé dans l'encyclopédie, et me demandant s'il ne faudrait pas le refondre. J'ai corrigé les modifs conformément à tes remarques. Est-ce correct?
Pour la suite, voici les questions suivantes. Pour info, les modèles qui utilisent le module Sports table sont 20 actuellement.
  • Faut-il franciser les paramètres pour respecter Projet:Modèle/Harmonisation#Nom_des_paramètres les conventions des modèles ? Ce qui n'a pas été fait par l'initiateur de ce module sur fr.wiki.
    Voire traduire le nom des modules ? En VND (ou GNP) pour "Victoire, Nul, Défaite" et "VD_départage" pour "Victoite, Défaite, éventuellement après dépatage" (par exemple aux tirs au buts ou overtime en hoockey).
  • Concernant la documentation, pour mes premiers pas sur WP, j'avais utilisé un tableau (cf Module:Sports_table/WL_OT), J'imagine que c'est mieux de le faire avec <templatedata>, non ? Si oui,
- <templatedata> est-il relié à la correrction syntaxique (argument de modèle invalide)?
- Par curiosité, est-il permis d'utliliser plusieurs fois <templatedata> dans un même modèle> pour espacer dans la rédaction de la documentation, les différentes options.
- comment y définir les paramètres dont le nom dépend du choix de l'utilisateur dans un autre paramètre (par exemple |team1=AAA |win_AAA=4 |loss_AAA=0),
  • Idée dont je doute de la pertinence et de la possibilié technique en terme de ressources, mais sait-on jamais, Quid d'un modèle ou les seuls paramètres d'entrée serait les résultats sportifs (scores des rencontres) et où le classement se ferait automatiquement (380 valeurs à passer pour un championnat et l'ajout d'une fonction de tri)?
Merci d'avance pour tes conseils. Cordialement(Aidewikip (discuter) 9 novembre 2018 à 00:00 (CET)).[répondre]

Protocole de Lisbonne[modifier le code]

Bonsoir et merci pour tes améliorations sur l'article Protocole de Lisbonne. Si tu as le temps et le courage de regarder les réf 1 et 7, je pense qu'il y a également matière à les grouper. Cordialement, --Cbyd (discuter) 18 novembre 2018 à 23:31 (CET)[répondre]

Fait. Cordialement. (Aidewikip (discuter) 19 novembre 2018 à 23:39 (CET)).[répondre]

Palais Massimo alle Terme[modifier le code]

Bonjour, j'ai terminé la traduction-adaptation. Il reste des erreurs dans les références. Merci, j'apprécie beaucoup ton travail. Ptyx (discuter) 2 décembre 2018 à 16:38 (CET)[répondre]

Alexandre le Grand[modifier le code]

Bonjour, merci pour tes corrections dans l'article Alexandre le Grand (quel vaste sujet !). Je ne trouve pas le lien Philippe à corriger, pourrais-tu stp m'indiquer dans quelle section il se trouve ? --Apollonidès (discuter) 13 décembre 2018 à 17:16 (CET)[répondre]

Bonjour Notification Apollonidès : Il s'agit du paragraphe commençant par « Les effectifs sont relativement faibles au départ de l'expédition » dans la section L’armée d’Alexandre qui fait référence à Philippe. Le lien conduit à la page des homonymes Philippe, sans le identifier/authentifier précisément (Philippe V de Macédoine, Philippe le satrape ou un autre). (Aidewikip (discuter) 13 décembre 2018 à 17:38 (CET))[répondre]
Merci, c'est corrigé ! N'hésite pas si tu vois d'autres erreurs ou oublis. --Apollonidès (discuter) 13 décembre 2018 à 18:03 (CET)[répondre]

Tableaux et modèle Listemédaillés[modifier le code]

Bonsoir,

tu es réactif !

Oui je comprends tes modifications. J'ai remis ma première forme dans le sens ou c'est beaucoup plus lisible et mieux structuré. Je note tes infos et je vais me pencher dessus dès que j'ai du temps libre pour corriger toutes ces erreurs.

Les sauteurs à ski en bleus dans les tableaux plus bas sont toujours en activité à ce jour. (je l'ai clarifié sur la page).

Cordialement. (NikoSerbe (discuter) 16 décembre 2018 à 22:09 (CET)).[répondre]

Au sujet de l'admissibilité de l'article Fédération internationale des véhicules anciens[modifier le code]

Bonsoir Aidewikip, pensez-vous que les sources sont à présent suffisantes? --Axepas11 31 décembre 2018 à 16:25 (CEST)[répondre]

Notification Axepas11 : Bonjour. Réponse en page de discussion de l'article concerné.

Roses[modifier le code]

Merci pour l'aide. Thomon 30 avril 2019 à 12:29 (CET)[répondre]

Question: Syntaxe des modèles[modifier le code]

Notification Supertoff : Bonjour, une simple question de curiosité, histoire de mieux comprendre le codage des modèles, à partir de l'exemple {{Infobox Personnalité du hockey sur glace}} où il n'y a aucune erreur dans le code (mis à part une petite balise de commentaire non fermée à l'origine d'une petite erreur de Lint : balise vide).

{{#if: {{{nationalité|}}}|{{Infobox V3/Tableau Ligne mixte|[[Nationalité]]|{{{{{nationalité|}}}|}}{{#if: {{{nationalité 2|}}}|<br />{{{{{nationalité 2}}}|}}}}}}}} ne pourrait-il pas être simplifié en
{{#if: {{{nationalité|}}}|{{Infobox V3/Tableau Ligne mixte|[[Nationalité]]|{{{nationalité}}}{{#if: {{{nationalité 2|}}}|<br />{{{nationalité 2}}}}}}}}}

  • En réalité ce sont les accolades (et barre verticale) mises en gras qui me posent question. Quelle est la raison de leur présence et leur influence sur le code HTML généré?
  • L'autre barre verticale qui suit "nationalité" à l'intérieur du if semble superflue car on a déjà passé le test et on sait que le paramètre est défini, non-nul, non-vide.

Merci d'avance pour votre réponse. (Aidewikip (discuter) 9 mai 2019 à 19:06 (CEST)).[répondre]

Salut. A priori tu as raison. Je vais me pencher là-dessus pour voir pourquoi j'ai fait ça. 'toff [discut.] 9 mai 2019 à 19:26 (CEST)[répondre]
Notification Supertoff : Bonjour. L'erreur mineure détectée par Linter dans les articles qui contiennent l'infobox mentionnée vient certainement du --> qui manque en début de ligne juste avant <!-- Repêchage de la LCHF --> Tu pourrais en profiter pour alléger le code comme ci-dessus si c'est bien équivalent. J'aurais bien tenté mais n'ai pas les droits. Merci.(Aidewikip (discuter) 13 mai 2019 à 11:12 (CEST)).[répondre]
Pour info, je viens de me pencher sur le code pour une autre raison et de retrouver pourquoi il semble y avoir des crochets en trop. Ils ont une bonne raison d'être. Je te laisse trouver la différence visuelle pour nationalité = USA (par exemple) avec ou sans {{ }} autour de USA Émoticône 'toff [discut.] 23 mai 2019 à 07:18 (CEST)[répondre]
PS : par contre je pense qu'il y a un pipe en trop à chaque fois... c'est peut-être pour ça que tu n'avais pas compris le truc. 'toff [discut.] 23 mai 2019 à 07:27 (CEST)[répondre]

Centre hospitalier de Digne-les-Bains[modifier le code]

Bonjour, ce diff [2] était il indispensable.... - Cela ressemble maintenant à du harcèlement de commenter mes contributions avec P:CS - Par deux fois vous avez gentiment critiqué ma façon de faire, merci de cesser immédiatement ce genre de diff - -- Lomita (discuter) 26 juin 2019 à 18:05 (CEST)[répondre]

Sagesses

« Ceux qui méritent le plus d’être loués supportent le mieux d’être critiqués. »

— Alexander Pope

« Qui s’enquiert de tout ce qui s’est dit sur son compte trouble lui-même son repos. »

— Sénèque

Bonjour Lomita. Si je suis tombé sur votre contribution, c'est juste qu'il est souvent plus facile de corriger une erreur quand on comprend son origine. En l'occurence, cette petite erreur (Titre de section ne finissant pas par « = ») classée comme de priorité élevée a été introduite par ce diff qui voulait corriger une erreur invisible de priorité basse (Titre : niveau de section manquant). Plutôt comique, non ? Rassurez-vous, je ne surveille pas vos interventions sur wikipédia. Mais compte tenu de vos nombreuses éditions, on peut aisément vous croiser involontairement. Trois petites remarques en un an, il me semble qu'on est loin du harcèlement. Et en vous "notifiant", je fais preuve de franchise. Sachez que j'apprécie aussi beaucoup certaines de vos contributions et vous en remercie. Il m'est déjà arrivé, après hésitation, de renoncer à appuyer sur le bouton "Remercier" par crainte de vous importuner. Salutations respectueuses. --Aidewikip (discuter) 26 juin 2019 à 22:11 (CEST)[répondre]

Modèle:Succession/Député québécois[modifier le code]

Bonjour,
Merci pour votre modification sur le {{Succession/Député québécois}}. Par contre, ça ne semble fonctionner. Voir : Louise Harel. — Riba (discuter) 8 août 2019 à 11:26 (CEST)[répondre]

Bonjour Riba. C'est normal! Pour l'instant, aucun article n'a été modifié et mes ajouts au modèle n'ont pas altéré leur forme antérieure. Je prépare un petit script pour traiter automatiquement ceux qui en ont besoin. Ce sera fait d'ici la fin de semaine. Je pourrais aussi lister les cas problématiques ou indécis. Cordialement. --Ideawipik (discuter) 8 août 2019 à 11:37 (CEST)[répondre]
Bonjour Riba
  1. C'est corrigé pour l'instant uniquement dans la quarantaine de pages liées au Portail:politique québécoise qui présentaient une balise HTML (pour le gras) syntaxiquement incorrecte. Correction effectuée en fonction de la valeur des paramètres député précédent (ou nomav) et député suivant (ou nomap). Puis une vingtaine d'autres en considérant aussi parti précédent, parti suivant et fin. Note : Dans les articles concernés, les modèles {{Insérer Député Qc}} ont été remplacés par {{Succession/Député québécois}}. Pour la deuxième fournée, ajout des remplacement {{Début dynastie}},{{Fin dynastie}} en {{Succession/Début}},{{Succession/Fin}}.
  2. Il reste des affichages de [[|]] générés par un paramétrage incomplet du modèle dans quelques articles. Accéder à la liste et aux explications sur cette autre page. Le bot peut la traiter entièrement désormais, sous réserve d'avoir quelques précisions donc un avis serait apprécié (choix esthétique).
  3. Mon bot a constitué un second tableau : liste articles des députés actuel dans le modèle Succession/Député québécois (112 dans la catégorie « Articles liés au portail politique québécoise »). Afin de faciliter la mise à jour ou la vérification, serait-il utile de le mettre dans une sous-page de maintenance du  Projet:Politique canadienne ou du  Projet:Québec ?
  4. Il y a un problème connexe à ce modèle, mais non lié à mes modifications. Il concerne les liens élection pour certaines années et provient soit de {{Succession/Député québécois}} soit de {{Lien élection québécoise}}. Voir par exemple les années 1923 (?) ou 1928 (élection exceptionnelle) sur l'article Camillien Houde. Il y a aussi quelque liens rouges comme 1955 sur John Richard Hyde. Si cela ne te dérange pas, je te laisse regarder cela, car tu connais bien ces modèles et la politique canadienne.
--Ideawipik (discuter) 11 août 2019 à 15:40 (CEST)[répondre]

correction Omaru (Nouvelle-Zélande)[modifier le code]

bonjour-

merci des multiples corrections mais que je ne comprends pas toujours et qui me promettent encore beaucoup de corrections dans les autres articles déjà traduits avant de les publier

je veux bien mettre un espace avant et après un titre ː pas de problème
pas de point avant le <ref> (et pourtant j' y fais attention)

mais je ne comprend pas le remplacement systématique de 'lien web' par 'lien briséǃ est ce de principe?/ le modèle lien web existe bien?

et surtout pour les datesː l'année est sans {{ }} alors que la date avec le mois est avec {{ }}
et les liens vers des articles non encore publié avec {{langue|en|nom de l'article}} au lieu de [[nom de l'article]] car après il faudra tous les reprendreǃǃ

en tout les cas merciː je vais essayer d'améliorer mais sans garantir qu'il n'y aura pas encore des erreurs
merci pour votre relecture. jgm18--Jgm18 (discuter) 1 septembre 2019 à 22:16 (CEST)[répondre]

Réponse détaillée faite en page de discussion utilisateur de Jgm18. --Ideawipik (discuter) 2 septembre 2019 à 08:10 (CEST)[répondre]
bonsoir
Excuse moi de te solliciter à nouveau mais sur l'article wiri (Nouvelle-Zélande) que je viens de publié , j'ai un message d'erreur que je n'arrive pas à résoudre concernant une erreur d'expression < opérateur inattendu  !!! de quoi s'agit il.?
par ailleurs format des coordonnées invalide (alors que j'ai copié exactement celles de la ville voisine?
merci de ton aide. bien amicalement. --Jgm18 (discuter) 3 septembre 2019 à 19:04 (CEST)[répondre]
Notification Jgm18 : Bonsoir. ✔️ Le problème vient des coordonnées géographiques insérées dans l'infobox et d'un conflit avec Wikidata. On peut s'en convaincre car il n'y a pas de problème si on copie le même code (avec les coordonnées renseignées, sur une autre page. Je ne pourrais pas t'expliquer réellement la raison mais la solution la plus simple, temporairement, est de laisser l'infobox charger les coordonnées depuis Wikidata. --Ideawipik (discuter) 3 septembre 2019 à 21:05 (CEST)[répondre]

Fichier ou Image[modifier le code]

Notification FDo64 et Pueblopassingby : Bonjour. Au regard de ces deux corrections contradictoires concernant "Image:" ou "Fichier:" : Diff #161847053 et Diff #161493082, que penser ? --Ideawipik (discuter) 2 septembre 2019 à 15:12 (CEST)[répondre]

Ideawipik et Notification Pueblopassingby : La réponse se trouve dans différents endroits : tout naturellement dans Aide:Insérer une image (wikicode, avancé) qui précise que la syntaxe est :
[[Fichier:Nom du fichier|vignette|alt=Texte alternatif pour l'image|Légende de l'image]],
et dans Help:Images qui indique « l'ancien préfixe d'espace de noms Image: est encore utilisable en tant que synonyme ».
C'est pourquoi je remplace systématiquement tous les « File » et « Image » par « Fichier » afin d'utiliser la syntaxe actuelle Faire l'inverse est inutile, voire incorrect. --FDo64 (discuter) 2 septembre 2019 à 21:34 (CEST)[répondre]
Notification FDo64 Merci pour cette réponse, que j'avais déjà en tête. Je souhaitais juste cibler ces modifs peu utiles et inviter Pueblopassingby à les éviter. Néanmoins certaines pages d'aide ne mentionnent que la syntaxe « Image » comme Aide:Syntaxe#Placer une image. --Ideawipik (discuter) 3 septembre 2019 à 23:52 (CEST)[répondre]
Bonsoir, en effet, une recherche avec "insource" permet de trouver une vingtaine de pages d'aide qui utilisent cette syntaxe. J'y passerai à l'occasion. --FDo64 (discuter) 4 septembre 2019 à 00:08 (CEST)[répondre]

Bonsoir Notification FDo64 et Ideawipik :. 1) "Image" a 5 lettres, "fichier" en a 7 (c'est plus rapide à écrire ; et d'aucuns se plaignent de la place prise par les bits superflus). 2) "Image" ne pose pas plus de problème technique que "fichier". 3) C'est plus joli (une excellente raison, surtout que pour "fichier" il ne manque qu'un 'a' après le 'f' pour dire phonétiquement tout ce que j'en ressens).
Pas question pour moi de jouer le jeu de ce technocratisme poussé et inutile : ce n’est pas à l'humain de se plier à la technologie mais bel et bien l'inverse. En accord avec votre décision, et m'abstiendrai dorénavant de traduire de l'anglais : copie directe depuis wikimédia, et basta. Ca répond tout à fait adéquatement au "peu utile" - qui de mon point de vue s'applique nettement mieux à la généralisation de ce type de langage. En fait je le vois comme négatif, c'est donc pire. Chacun sa vision. Bonne soirée à vous. Pueblopassingby (discuter) 3 novembre 2019 à 15:28 (CET)[répondre]

Bonjour Pueblopassingby. Personnellement je n'ai aucune préférence entre l'un et l'autre. Ce que je trouve juste imbécile c'est que, potentiellement, des contributeurs ou des robots se succèdent sur un même article pour corriger à tour de rôle ces détails. Avec un choix clair et uniformisé, peu importe le terme choisi, cela éviterait des modifications pas forcément volontaires (valeur par défaut de bots) qui compliquent les historiques et des sollicitations serveurs qui coûtent bien plus en terme d’énergie que la petite différence signalée. Pour un tel détail assez insignifiant, il ne devrait pas être difficile de trouver un consensus et de l'appliquer, histoire que les contributeurs ne rament pas dans des sens opposés. Ou bien il faudrait interdire et désactiver les traductions automatiques par gadgets ou bots (File ou Image) → Fichier et (File ou Fichier) → Image. Une "guerre" d'édition, même involontaire, sur ce point est assez futile. Mon bot a pris le parti, comme d'autres le font, de traduire « File » en « Fichier », mais de ne pas remplacer « Image » par « Fichier » comme tu peux le voir en bas de cette modification.
Question répartition : une recherche donne 134 000 articles contenant « Image: », 230 000 avec « Fichier: », et 92 000 avec « File: » (avec un gros doute sur ses chiffres)
Bonne soirée également. --Ideawipik (discuter) 3 novembre 2019 à 17:28 (CET)[répondre]
Coucou Ideawipik, je vois bien ton point de vue. Moi je n'ai pas de bot (et vraisemblablement n'en aurai jamais), donc je suis out dans le débat 'bot'. Tout ce que je visais jusqu'à aujourd'hui où j'ai pris la décision de ne plus franciser l'objet, était de 1) uniformiser les pages éditées car c'est plus pratique pour s'y repérer, 2) en gardant le côté humain puisque sur le plan technique/informatique j'imagine que 'fichier' et 'image' ça revient au même. Là où ça ne revient pas du tout au même c'est sur le plan humain. Je ne suis pas une machine donc je fonctionne avec des images, pas des fichiers. Ça c'est ferme et définitif, sinon on perd l'aspect 'établir des connexions hors sentiers battus', un trait essentiel à l'intelligence. Si je dois voir des fichiers, autant que je le laisse en anglais : au moins ça ne prend que 4 lettres et on n'en a pas plein la bouche quand on le prononce (donc on passe à autre chose plus vite). Et puis comme il y aura toujours qqn pour rajouter des images en gardant le mot "file", au moins ça gardera le côté bordélique sans lequel il n'y a pas de vie donc pas d'humain :) Bon, tout ça pour dire, si vous vous décidez pour 'image' je suis (du verbe suivre, et aussi du verbe être - avec vous) et ça vaut le coup de me le faire savoir pour que je me remette à franciser la chose. Si vous prenez le 'fichier', je reste (ailleurs) et ça restera en anglais pour ma part.
Bonne continuation :) Pueblopassingby (discuter) 3 novembre 2019 à 18:25 (CET)[répondre]

Suivisme[modifier le code]

Bonjour Ideawipik,

Je suis particulièrement étonné de ton intervention sur le BA, non pas que cela me chagrine mais j'aimerais juste savoir comment tu as découvert cela, tu n'es pas intervenu sur l'article Chepniers avant le problème, ni sur la page de Le Roy Wark ou celle de Arcyon alors comment ? Je pense que tu peux comprendre mon étonnement, tu ne ferais pas du suivisme par hasard.

Juste comme cela en passant, tu penses sincèrement qu'un contributeur qui annonce son vandalisme et qui le répète par deux fois cela soit juste une malencontreuse manœuvre de bonne foi.

Sans rancune. Cordialement -- Alaspada (d) 17 septembre 2019 à 17:03 (CEST)[répondre]

Notification Alaspada : Réponse toute simple : En suivant la discussion sur le forum de médiation à propos du portail des Hospitaliers sur les pages des communes et en lisant la dernière réponse, je suis allé voir ce que contenait la catégorie « Commune abritant une commanderie de l'ordre de Saint-Jean de Jérusalem » vers laquelle plusieurs liens pointent depuis la discussion. Je suis ensuite arrivé en un clic sur la page de suivi des articles liés à cette catégorie où l'article Chepniers était le dernier modifié, parmi les quatre retouchés ce 16 septembre. J'y ai regardé la nature des dernières modifications et apporté une correction mineure en même temps que Arcyon37. Plus tard, quand j'ai vu la raison pour laquelle l'utilisateur récent avait été bloqué indéfiniment, je me suis étonné. J'ai laissé passé la nuit avant de réagi. Ne cherche pas plus loin. Je ne suis pas en croisade contre toi, ni ne piste tes interventions.
Quant au problème que j'ai soulevé sur le BA et qui ne te concerne que partiellement puisque sa raison première est ma réaction à une action administrateur : le blocage d'un contributeur.
  • Tu exclus d'emblée la maladresse. Alors, comment expliquer pourquoi l'utilisateur a du s'y reprendre plusieurs fois pour insérer son contenu, a supprimé le modèle {{autres projets}}, s'est débattu avec les accolades ?
  • Tu dis que l'utilisateur impliqué est un « contributeur qui annonce son vandalisme et qui le répète par deux fois ». La seule menace que j'ai vue est « je ferai supprimer le lien de Wikipédia sur Chepnier » et est plutôt farfelue. Mais j'ai peut-être raté un épisode. Et quand bien même. Recevoir un premier revert sans autre explication qu'un commentaire de diff « pas d'article sur WPfr » qui n'est pas explicite du tout, surtout pour un contributeur qui n'a participé que trois jours à Wikipédia, on peut concevoir que cela puisse être perçu comme violent et engendrer un énervement. Mais ce n'est pas à nous de statuer sur ce cas. J'ai fais ce que je pensais être normal en effectuant ce signalement et apposant un message neutre sur la page de discussion du contributeur concerné.
Si tu me le permets, je t'invite tout de même à prendre davantage de précautions quand tu annules une modification et à davantage en expliquer la raison. En outre, l'argument qui consiste à dire que telle personne n'a pas d'article Wikipédia donc n'est pas notoire, est « bof bof » comme tu dirais. Un lien en page de discussion utilisateur vers une recommandation de Wikipédia serait plus clair et certainement mieux perçu par l'auteur des apports non encyclopédiques. Ainsi, le désaccord ne deviendra pas un conflit personnel. Chacun a sa part à accomplir pour créer le climat de non violence souhaité. Très cordialement. --Ideawipik (discuter) 17 septembre 2019 à 20:54 (CEST)[répondre]
J'accepte bien volontiers ton explication et te prie de bien vouloir m'excuser de t'avoir soupçonner de suivisme.
Par contre je ne te suis pas pour Le Roy Wark.
C'est à peu près les seules modifs que je fais encore sur les articles des communes de France, le suivi des Personnalités liées à la commune. Malheureusement le statut d'un contributeur n'est pas inscrit dans la signature et je t'avoue que depuis un peu plus d'un an, je ne fais plus de patrouille, donc je vais au plus rapide et en appliquant Projet:Communes_de_France/Conseils_pour_la_rédaction#Personnalités_liées_à_la_commune je donne en modification de diff soit « Personnalités liées à la commune : pas d'article dans WPfr » ou un peu plus complet « Personnalités liées à la commune : pas d'article dans WPfr, manque de notoriété », justement les deux explications de diff utilisés sur le cas qui nous intéresse. Généralement c'est suffisant pour tout le monde. Après un message de Le Roy Wark un peu aride sur ma PdD je reçois un message de Arcyon me renvoyant sur sa page où là le ton n'est pas des plus cool et où Le Roy Wark annonce sa « maladresse » et termine par « Ai-je été assez clair ? ». Donc à 22:21 je le revert de nouveau et à 23:04 Le Roy Wark me reverte pour la deuxième fois puis subitement à 23:07 et 23:08 sa « maladresse annoncée » révoquée dans le même temps par Lomita avec à 23:12 un avertissement qu'il n'a pas pu manquer de voir car il y a un affichage d'avertissement sur n'importe quelle page qu'il soit mais cela ne l’empêche pas à 23:13 d'un nouveau blanchiment de page pour aboutir à 23:14 au blocage et au rétablissement de l'article par Lomita. Et je trouve toujours que Lomita a fait et fait un bon travail, l'administratrice qui fait le plus de travail d'admin chez les admins et pas sur les RA. C'est trop facile de venir tout casser et n'annuler le blocage comme l'a fait Marc Mongenet. Il y a tous les jours des blocages comme ça et cela me laisse froid. Je suis par contre plus attentif aux blocages des anciens (et pour cause). Mais de rejouons pas les anciens contre les modernes nouveaux.
Je veux bien tout ce que tu veux mais je ne prendrai pas plus de pincettes avec des contributeurs qui ne cherchent pas à s'informer avant de contribuer quitte à déboucher sur des conflits personnels et je ne prends plus ma part pour créer un climat de non violence. Il y a un an peut être mais maintenant c'est terminé. Les seuls que je respecte sont les lecteurs, les seuls à qui l'on doive un peu d'attention et qui sont malheureusement souvent oubliés dans nos petits conflits internes.
Cordialement -- Alaspada (d) 17 septembre 2019 à 23:18 (CEST)[répondre]
Bonsoir Alaspada. Pas la peine de rappeler les faits ils sont bien exposés où il se doit.
Inutile également de mettre à dos deux administrateurs. Je comprends bien que dans la précipitation, ou un moment d'énervement, un admin puisse agir un peu vite et que deux administrateurs puissent avoir une vision légèrement différente.
Techniquement, le nouveau : je n'excuse pas son ton autoritaire ou capricieux et ne me suis pas opposé à une sanction temporaire, si nécessaire et ce n'est pas à nous de décider. Mais sur l'autre point « un avertissement qu'il n'a pas pu manquer de voir », je ne suis pas d'accord avec toi. Personnellement, je ne vois les alertes ou notifications que quand je charge une nouvelle page, pas quand je suis en train de rédiger un texte. Et c'est pourquoi je suis très dubitatif quant à ce fait, surtout quand une seule minute sépare les deux actions.
En ce qui concerne les blocages, je ne les regarde que rarement. Auparavant je n'en avais vu qu'un seul qui m'avait semblé légèrement abusif ou choquant. Mais pas au point de celui-ci, avec un motif de « Compte crée pour vandaliser » ne correspondant pas aux actions du compte. Donc cette fois, j'ai souhaité le signaler, indépendamment des intervenants impliqués. Il ne faut pas oublier que chaque contributeur a été un débutant et n'a pas pu cerner tous les tenants, aboutissants et usages sur l'encyclopédie en deux jours. Parce que dans le cas présent, il s'agit bien d'un usage/point éditorial : "comment remplir la section personnalités liée à une commune ?" Déjà que des contributeurs plus anciens ont parfois du mal à se mettre d'accord sur divers points, application des règles, critères, conventions alors pour un nouveau qui ne connaît pas forcement l'existence des conventions spécifiques à tel ou tel projet.
Sur le principe, arguer du fait que la présence sur internet n'est pas forcément une condition nécessaire ou suffisante de preuve de notoriété est acceptable.
Je partage ton souci pour le lecteur tout en pensant que sans contributeurs, il n'y aurait pas de lecteur et en gardant à l'esprit que l'encyclopédie (article, projet, ...) n'appartient à aucun contributeur.
N.B. Une suggestion pour tes résumés/commentaires des modifications : quand c'est "critique" inclus-y un lien vers la section d'aide ou de recommandation relative à la modification ou suppression que tu fais. Ce serait déjà un peu plus pédagogique. Cordialement. --Ideawipik (discuter) 18 septembre 2019 à 00:32 (CEST)[répondre]
C'est bien de garder l’enthousiasme des contributeurs récents pour les nouveaux, on en reparlera quand tu auras pratiquement 15 ans au compteur mais je ne serai plus là... -- Alaspada (d) 21 septembre 2019 à 16:11 (CEST) voir Discussion_utilisateur:Le_Roy_Wark#Suppression_de_mon_compte[répondre]

Utilisateur:Ideawipik/Football/Historique du classement sportif de l'Olympique lyonnais[modifier le code]

Bonjour, en faisant du ménage dans l’espace principal qui ne devrait pas contenir de lien vers l’espace Utilisateur (sauf quelques exceptions), j’ai trouvé un de tes modèles dans Bilan saison par saison de l'Olympique lyonnais.

Il faudrait songer à le transférer dans l’espace Modèle. Merci.

J'en profite pour te signaler que c'est toujours ton ancien nom qui est sur ta PU.

--FDo64 (discuter) 13 octobre 2019 à 17:45 (CEST)[répondre]

Merci FDo64 pour le signalement de ce vestige. J'ai supprimé cet élément, peu accessible, de l'espace principal. --Ideawipik (discuter) 14 octobre 2019 à 11:41 (CEST)[répondre]

Prise de décision - Amendement de la règle Wikipédia : Liens vers les portails[modifier le code]

Bonjour Ideawipik,

Pourriez-vous scinder votre intervention sur la PDD en deux parties pour permettre une réponse plus facile : une sur la rédaction des questions et l'autre sur la modalité de décision.

Je vous en remercie. Cordialement -- Alaspada (d) 30 novembre 2019 à 22:16 (CET)[répondre]

Merci. Auriez-vous une proposition pour présenter les deux dernières questions sous la forme d'une seule avec la méthode Condorcet. Cordialement -- Alaspada (d) 30 novembre 2019 à 23:23 (CET)[répondre]
Notification Alaspada : ✔️. J'avais hésité à créer deux sections lors de ma réponse. Je n'en aurais pas pris ombrage si vous l'aviez fait. C'est effectivement plus clair pour la suite des discussions. La première partie des remarques me semble bien avoir sa place dans la section « Objectif de la Prise de Décision » de cette page de discussion. À voir en fonction de l'évolution de la discussion.
Pour la méthode de Condorcet, il n'y aurait qu'une seule question : Classez par ordre de préférence les trois propositions suivantes :
A) statu quo,
B) proposition + de souplesse,
C) proposition avec ajout du critère général.
Salutations cordiales. édit ajout notification. --Ideawipik (discuter) 30 novembre 2019 à 23:36 (CET)[répondre]

Exemple dans la section « Présentation du problème à l'origine de cette PDD »[modifier le code]

Bonjour Ideawipik, J'ai lu ton message : [3].

Concernant la section « Présentation du problème à l'origine de cette PDD » [4], il va peut-être falloir en arriver à la solution que tu proposes, c'est à dire ne pas mettre d'exemple, mais je pense que cela amoindrirait le propos : il me semble que le lecteur de la PDD doit pouvoir comprendre très clairement d'où vient le conflit qui a conduit à nos discussions du mois de septembre et octobre. Non seulement Lucéram est l'article pris prioritairement en exemple sur le salon de médiation, mais en plus c'est vraiment un article où le thème de l'ordre religieux de Jérusalem est très peu présent. Pour le lecteur, il sera très long de lire toutes nos discussions sur le salon de médiation. Alors que si on met l'exemple dans la PDD, il comprend tout de suite pourquoi il y a eu conflit, pourquoi une demande de médiation a été ouverte, etc... Tu ne crois pas ? Cdlt --Baldurar (discuter) 5 décembre 2019 à 11:33 (CET)[répondre]

Notification Baldurar : Bonjour. Je le pense aussi. L'exemple donné ne me convainc pas comme je l'ai dit, à demi-mots, ici (neutralité et syntaxe) et en conclusion de ce message (pertinence pour illustrer la Prise de Décision). L'exemple de Lucéram (longuement discuté) me semble de prime abord plus parlant pour expliquer la raison d'être de la PDD.
La nécessité d'avoir un exemple introductif est valable surtout si certains énoncés de critère général sont trop flous et si, comme ceci a été relevé (Notification Jean-Christophe BENOIST), les exemples pour illustrer la règle "souple" incluent beaucoup d'exemple pour lesquels la règle "stricte" autoriserait également la présence du portail.
Si la rédaction des propositions évoluait et permettait de bien identifier les orientations souhaitées pour cette règle, alors l'exemple introductif pourrait être supprimé. Ce n'est pas le cas en l'état !
PS: pour comprendre d'où venait cet exemple précis : j'ai fait une recherche de « Civray (Vienne) » dans toute l'encyclopédie, hors articles. Les seules discussions qui en parlent sont celle-ci et celle-là toutes deux liées à des actions du même auteur pour qui « le portail va de pair avec la catégorisation ». C'est donc un cas parmi d'autres.
--Ideawipik (discuter) 5 décembre 2019 à 12:55 (CET)[répondre]
Ok.
Donc, en fait, l'exemple Civray n'a même pas été discuté, jamais, lors des discussions entre nous au mois de septembre et octobre... ! --Baldurar (discuter) 5 décembre 2019 à 13:06 (CET)[répondre]

Règle libérale[modifier le code]

Si on supprime les exemples introductifs de la règle libérale (j'avais pensé à mettre Audincourt comme exemple, voir PDD de Jean-Christophe [5] ) il faudra penser à mieux préciser cette règle libérale. Peut-être comme ceci : 

Il est possible de mettre dans un article un lien vers un portail dès qu'il existe un thème présent dans l'article qui soit commun avec ceux du portail, même si ce thème est évoqué dans l'article très brièvement.

Mais bon, on en est pas encore là. Il va d'abord falloir s'entendre avec Alaspada sur le fait que la règle libérale telle qu'elle est écrite actuellement est boiteuse. Cdlt --Baldurar (discuter) 5 décembre 2019 à 13:12 (CET)[répondre]

Notification Baldurar. Oui. Cela rejoint le troisième point de ce message. Un truc de ce genre. En plus court :
« Il est possible de mettre dans un article un lien vers un portail thématique dès qu'un thème commun avec ceux du portail est évoqué, même très brièvement, dans l'article. »
Comme Jean-Christophe, pour ne pas éparpiller les discussions, je préférerais qu'on aborde ces points sur la pdd de la PDD (Émoticône ou, pour traduire ce jargon, page de discussion de la prise de décision). --Ideawipik (discuter) 5 décembre 2019 à 14:01 (CET)[répondre]

R3R[modifier le code]

Bonjour Ideawipik,

vous ne manquez pas d'air, vous intervenez dans la discussion et vous osez mettre un bandeau R3R. Bravo il n'y a qu'un contributeur récent qui peut se permettre cela en parfait accord avec votre avis déclaré. J'en resterais là. J'attends la suite de pied ferme.

-- Alaspada (d) 5 décembre 2019 à 19:52 (CET)[répondre]

La pose d'un bandeau R3R était tout à fait justifiée. C'est bien vous qui avez imposé votre version pour la 3e fois alors qu'une discussion est en cours et que vous semblez la refuser (Diff #165142016). La suite de ma réponse se trouve sur la page de discussion associée. C'est quand même dommage d'en arriver là. --Ideawipik (discuter) 5 décembre 2019 à 21:49 (CET)[répondre]
Vous avez tout à fait raison « c'est quand même dommage d'en arriver là ». Relisez donc la règle, « un contributeur ne peut effectuer trois révocations ou davantage sur tout ou partie d'un article sur une durée de 24 heures consécutives » mais c'est évidemment moi qui vous ait reverté ? Moi qui m’intéresse à des questions que je ne défends pas ? Et bien non c'est vous, alors il serai bien que vous maitrisiez un petit peu mieux votre argumentation. -- Alaspada (d) 5 décembre 2019 à 23:33 (CET)[répondre]
Bonjour Alaspada. Il n'est nulle question d'argumentation. Regardons les faits.
Petite chronologie
État initial : A a introduit exemple dans la page.
- Le 2 décembre
B propose à la place un deuxième exemple (15:03)
A annule (15:21)
B annule (15:39)
A annule (15:48)
B pose un {{incompréhensible}} puis remet son exemple (17:01 et 17:40)
A propose alors un troisième exemple (19:52)
- Le 3 décembre
B propose un quatrième exemple (06:18)
A annule (20:22)
- Le 4 décembre
B annule (07:49)
A annule (12:00)
- Le 5 décembre
B annule (17:12)
A annule (17:21)
C, qui n'est jamais intervenu sur ce point de la page bien qu'il ait participé à la discussion à propos de cette page, supprime l'objet de la discorde i.e. l'exemple présent (en l’occurrence le troisième, notamment parce que ce paragraphe est difficilement compréhensible) et appose un R3R pour inviter les contributeurs à se mettre d'accord avant tout ajout d'exemple (19:33)
Qui est le plus fautif ? Si annuler indéfiniment des contributions est permis du moment que ce n'est pas fait plus de deux fois par jour, alors continuez ! Mais je ne partage pas votre conception de la guerre d'édition ni de la recherche de consensus par l'usure.
Pour info : J'ai également proposé des éclairages pour vous permettre d'organiser différemment la page et vous affranchir de ce point conflictuel (lire ce diff).
Cordialement. --Ideawipik (discuter) 6 décembre 2019 à 12:16 (CET)[répondre]

Prix Kandinsky[modifier le code]

Bonsoir Ideawipik,

J'avais en effet découvert ce deuxième Prix Kandinsky pour lequel je comptais rédiger l'article, ce qui est maintenant fait (ainsi que la page d'homonymie).

Bonne soirée, — Jacques (me laisser un message) 8 décembre 2019 à 21:37 (CET)[répondre]

Lien'[modifier le code]

Bonsoir, je travaille actuellement à vider les catégories Catégorie:Page avec trop d'appels dispendieux de fonctions parseurs et Catégorie:Page contenant trop d'inclusions de modèles. Une des méthodes (que j'applique) est de remplacer le modèle {{Lien}} par {{Lien'}}. Est-ce que ton bot se charge aussi de convertir ce deuxième modèle ? --FDo64 (discuter) 9 décembre 2019 à 21:03 (CET)[répondre]

Bonsoir FDo64. J'étais au courant de l'existence de ce modèle similaire à Lien mais je n'ai pas regardé en détail. Pour l'instant mon bot ne les traite pas. Mais je peux faire en sorte que oui. Par contre, pour limiter le travail du bot, je préfère travailler sur une catégorie ou liste limitée, comme Catégorie:Page utilisant Lien pour un article existant. Je sais bien qu'aucune catégorie n'est alimentée de la même façon car cela augmenterait encore le problème de nombre d'appel dispendieux de fonctions lourdes C'est d'ailleurs la raison d'être de ce modèle prime. Sais-tu s'il y en a beaucoup de cas concernées, a priori ? Pour éliminer les appels dispensables, ce que je proposerais est de faire tourner un programme spécial une ou deux fois par mois sur l'ensemble des articles contenant ce modèle en inclusion en dur (pas via des modèles). Si tu as un lien vers une recherche (Petscan, wstat ou autre) qui renverrait la liste brut des articles contenant le modèle « Lien' », je suis preneur.
PS : Remarque mineure, une recherche insource:/\{\{ *[lL]ien\'/ne renvoie pas grand chose, quatre articles seulement (et aucun modèle) actuellement.
PS2 : Pour être sûr, la conversion doit bien être réalisée exactement de la même façon que pour le modèle Lien ?
--Ideawipik (discuter) 9 décembre 2019 à 22:01 (CET)[répondre]
C'est vrai que les dernières stats n'indiquent que 10 pages, principalement des pages du bistro. J'en ai rajouté quelques-unes, surtout des listes. C'est par acquis de conscience que je suis venu t'en parler, mais c'est finalement pas très important si ce cas est ignoré…
Merci pour ta réponse. --FDo64 (discuter) 9 décembre 2019 à 22:10 (CET)[répondre]

2020[modifier le code]

Bonne et heureuse année ! Mike the song remains the same 1 janvier 2020 à 14:34 (CET)[répondre]

Tenure of Office Act[modifier le code]

Je vous remercie de votre vigilance et suis désolé de ma bévue. J'ai dépassé les trois quarts de siècle et m'aventure à regret vers les quatre cinquièmes ; pour tenir en respect Alzheimer je m'occupe de traduction mais je suis effrayé de n'avoir pas vu que je faisais deux fois la même chose (et c'est inquiétant). Soyez aimable et arrangez l'affaire comme vous le jugerez bon ; d'avance je me permets de vous remercier. Gustave G. (discuter) 17 janvier 2020 à 11:22 (CET)[répondre]

Dunlopillo[modifier le code]

Bonjour

J'ai demandé à un administrateur de casser le redirection pour me permettre de rédiger une nouvelle page...

... mais vous avez rétabli la redirection

Cordialement

--47dp (discuter) 14 février 2020 à 15:31 (CET)[répondre]

Bonjour 47dp. Il n'y avait rien à « casser », comme cela vous a été expliqué par Bédévore dont les conseils sont avisés. J'ajouterais seulement le suivant : avant de supprimer une page (article ou redirection), il est recommandé de s'assurer qu'il n'y a pas, dans l'encyclopédie, d'article (ou de modèle) contenant un lien interne vers cette page. La suppression entraîne des liens rouges dans les articles. Dans le présent exemple, voir Spécial:Pages_liées/Dunlopillo (au passage Notification Zivax). De même, la modification/transformation de redirections, sans vérification, peut parfois conduire le lecteur vers des pages non désirées (par exemple un homonyme). Des corrections de liens sont parfois nécessaires dans l'encyclopédie. Si ces dernières sont nombreuses, il est possible de solliciter l'aide d'un robot.
Maintenant, si vous souhaitez créer un article sur Dunlopillo, rien ne vous empêche de transformer une redirection en article. Il suffit d'éditer la page intitulée « Dunlopillo » (onglet « Modifier le code »), comme n'importe quelle page, en suivant la procédure donnée par Bédévore (ce qui a été fait par un autre contributeur) et en respectant les exigences encyclopédiques (pertinence, vérifiabilité des informations, sources secondaires de qualité).
En espérant avoir répondu à votre interrogation sur les redirections. Il n'y a pas besoin de recourir à un administrateur pour éditer de telles pages.
Cordialement. --Ideawipik (discuter) 14 février 2020 à 16:43 (CET)[répondre]
Un grand merci pour votre aide--47dp (discuter) 14 février 2020 à 16:51 (CET)[répondre]

Saisons club[modifier le code]

Bonsoir (plutôt bonne nuit),

Je reviens vers vous pour vous poser quelques questions. Depuis la dernière fois qu'on a échangé au café, j'ai quelque peu modifié la page de la saison actuelle de l'Espanyol en incorporant du texte.

Mes questions portent toutefois sur les feuilles de matchs. J'ai en effet, inspiré par l'article promu qu'est la saison 2011-12 de Caen, voulu ajouter les effectifs. Pour le moment, je le fais sur mon brouillon et voilà ce que ça donne. Sur l'article de Caen, les utilisateurs ont opté pour des feuilles colorées comme pour le Wikipedia anglais ou italien mais vous m'aviez dit que ça ne collait pas aux règles de neutralité (si je me souviens bien). De plus, est-il préférable de laisser des feuilles de matchs enroulées ou de tout englober dans un tableau comme pour la saison de Caen ? Ayant vu que d'autres articles promu comme le Football aux Jeux olympiques d'été de 1988 utilisent les effectifs, cela me motive à continuer de la sorte mais je ne veux pas non plus perdre le lecteur (c'est pour ça que j'espace mes effectifs pour bien délimiter les postes et mettre en avant le schéma tactique).

Bref, beaucoup de question somme toute assez peu importantes mais vu que ces pages ne sont pas réglementées, on assiste à un large éventail de feuilles de matchs. L'ironie, c'est que celles du Barça par exemple n'en ont pas et utilisent un tableau. Peut être devrait-je faire de même ?

Bien à vous. --Nebuno (discuter) 28 février 2020 à 03:36 (CET)[répondre]


Bonjour Ideawipik,
Je me permets de vous relancer une dernière fois concernant ce même sujet car vos conseils précédents m'ont aidé.
Pour faire court, voilà la feuille de match que je développe dans mon brouillon.
Même si l'ajout des effectifs est intéressant, je me demande si il est nécessaire ? Peut être devrais-je privilégier les tableaux ultra simples ou du moins la même feuille de match sans la compo, accessible dans le lien.
Bon aprem' --Nebuno (discuter) 4 mars 2020 à 16:10 (CET)[répondre]
Bonjour Nebuno. Désolé pour le délai, j'avais regardé le brouillon et commencé une réponse qui s'est perdue. Si cela vous convient, on peut se tutoyer. Voici quelques remarques concernant les pages de saisons de clubs.
  1. Feuilles de match
    • Effectifs nécessaire ? non, mais possibles oui. Comme déjà discuté, tout dépend de la page. Les feuilles de match dans l'article en l'état, ie sans les effectifs, pourraient suffire. En cas d'ajout des effectifs, je serais plutôt favorable à une simple liste classée en partant du gardien vers les attaquants mais sans chercher à reproduire un schéma d'effectif (rendu difficile par les lignes longues et très dépendant des supports/écrans). Le lecteur trouvera les éléments sur le lien externe Rapport. De plus un joueur est affecté régulièrement au même poste. Si d'aventure un entraîneur décidait de faire jouer un défenseur en attaque ou un attaquant de pointe en ailier, il serait plus intéressant d'avoir l'information dans un résumé textuel de la saison, dans la mesure où des sources externes pertinentes attestent que ce changement n'est pas purement anecdotique pour le jeu de l'équipe. Un doute aussi sur la pertinence des passeurs décisifs. Ma proposition se rapprocherait donc davantage de la feuille présentée plus bas. Voir aussi les deux propositions pour les remplacements, mais il y a sûrement d'autres pratiques existantes sur le projet foot. Note : il existe des paramètres cartons 1 et cartons 2. Documentation.
    • Pour les couleurs de fond des feuilles de match : privilégier une couleur par défaut ou neutre.
  2. Tableaux d'effectifs : Question des lignes de texte ou colorées entre les postes :
    • Les lignes entre les postes sont problématiques pour l'accessibilité (Bonnes pratiques) pour les personnes qui utilisent des outils de lecture automatique, synthétiseurs vocaux).
    • Il y a aussi un problème avec le classement des colonnes. Essayez de jouer avec les flèches de classement en haut du tableau. J'avais proposé une solution fonctionnelle pour ce deuxième point mais elle ne résout pas le premier point.
  3. Tableau des joueurs prêtés ou équipe réserve.
    Ces tableaux sont souvent constitués de deux voire souvent trois tableaux imbriqués alors qu'il suffirait concrètement pour des raisons de simplicité et d'accessibilité d'un seul tableau. Ce sont des corrections faisables.
Remarque. Si tu souhaites voir harmoniser les pratiques, rien ne t'empêche d'éditer et de faire des propositions sur les sous-pages du projet:Football, comme Projet:Football/Logistique ou pour les effectifs. Une mise à jour et un accès facilité à l'information seraient souhaitables pour aider les nouveaux contributeurs et les anciens.
--Ideawipik (discuter) 4 mars 2020 à 20:00 (CET)[répondre]


Bonjour Ideawipik,

Tout d'abord, merci pour cette réponse claire et précise.

J'ai apporté quelques modifications au niveau des effectifs tel que sur le tableau en bas.

Concernant les cartons, je sais qu'il y a une option carton que j'utilise d'ailleurs sur une page mais je trouve la version de 2011-2012 plus claire pour le lecteur, comme si on suivait le cours du jeu (c'est pour ça qu'un carton à la 39e est plus haut que celui à la 80e). J'ai aussi vu que certaines pages comme celles des JO 1988 ou saison 2019 de l'Impact de Montréal mettaient les cartons dans les effectifs. Est-ce une bonne idée ?

Pour les effectifs, après consultation de plusieurs pages et de sites comme L'Équipe, je trouve l'usage des tirets judicieux pour marquer les différents postes sans devoir bien aligner chaque joueurs. Quant aux changements avec les deux flèches, c'est beau et ergonomique mais en version mobile, je trouve que ça prend beaucoup de place (peut être utiliser seuleument la flèche verte comme sur ton exemple). C'est pour cela que je propose deux versions différentes sur les effectifs de cette feuille de matchs, afin que tu me dise celle qui semble la plus adéquate. Celle de gauche a des traits séparateurs fins et des signes de changements évidents tandis que celle de droite met plus en évidence la séparation avec des traits plus larges mais les changements sont en minutes (ça prend aussi moins de place).

Après, l'utilisation de ces effectifs pour une saison de club (l'Espanyol en l'occurence) assez peu importante est sûrement inutile... Toujours étonné de voir les saisons de deux clubs les plus consultés avoir les tableaux les plus simples tandis que des clubs plus petits ont droit à beau lifting.

En tout cas, merci pour ta patience et ton aide ! --Nebuno (discuter) 5 mars 2020 à 10:54 (CET)[répondre]


Edit : Il y a également, dans le cas où l'on est très rigoureux, la possibilité de mettre les effectifs détaillés comme pour la saison 2018-19 de Guigamp. La saison suivante utilise également cela mais ça prend du temps et est ce que cela sert vraiment à quelque chose ? Je me pose du moins la question pour les matchs de barrages dans les championnats comme la L1 ou la JLeague qui sont des matchs cruciaux et mériteraient une feuille de match détaillée. --Nebuno (discuter) 5 mars 2020 à 13:53 (CET)[répondre]


Voilà, je pense avoir trouvé le bon compromis pour les effectifs :

Je pense que ça demeure lisible pour un lecteur néophyte. J'hésite seulement entre les petits ou grands tirets. --Nebuno (discuter) 6 mars 2020 à 05:51 (CET)[répondre]

Bonjour Nebuno. +1 pour l'utilisation des tirets entre les "lignes", solution que j'ai déjà utilisée par le passé avec une préférence pour le tiret demi-cadratin –. Quant aux pictogrammes de remplacement de joueur, il est possible de les retirer même complètement. Libre à toi, tant qu'il y a une légère cohérence dans la page. Cela reste du détail.
Les effectifs détaillés généralisés sont à proscrire. Cela a d'ailleurs valu des problèmes d'affichage à la page mentionnée à propos de l'EAG 2018-2019 qui contenait beaucoup trop de modèles (limitation technique et temps de chargement). Mais ils peuvent bien sûr être mis en place pour une finale ou un match très important.
Je pense que ton compromis est correct. Il manque juste des buts à l'Espanyol Émoticône.--Ideawipik (discuter) 6 mars 2020 à 10:08 (CET)[répondre]
Je trouve aussi que mettre de tels détails pour la saison 2018-19 de l'EA Guingamp, c'est trop et ça n'a pas un grand intérêt.
Un grand merci pour ton écoute et tes conseils. Échanger avec toi est un vrai plaisir ! Bonne journée. --Nebuno (discuter) 6 mars 2020 à 10:18 (CET)[répondre]


Bonsoir Ideawipik,

Je reviens vers toi pour te montrer le compromis que j'ai obtenu concernant les effectifs détaillés. Je me suis rendu compte que le modèle Joueur feuille de match n'était pas nécessaire pour faire une feuille de match lisible et qui prend moins de place. Voici ma version, qui se trouve être l'effectif de l'Espanyol, contre celle "classique", de Séville.

Au final, la version que j'ai choisi prend un peu plus de place que les effectifs simples mais beaucoup moins que ceux du modèle.

Je tenais à te le dire puisque nous avons pas mal échangé sur le sujet.

Bonne soirée. --Nebuno (discuter) 20 juin 2020 à 20:29 (CEST)[répondre]

Méthode concernant l'harmonisation des catégories liées à une entité géographique[modifier le code]

Cf. Discussion utilisateur:Polmars#Méthode concernant l'harmonisation des catégories liées à une entité géographique. (Message dupliqué déposé par Polmars, le 8 juillet 2020 à 22:33 (CEST) ; remplacé par un lien interne).[répondre]

Aide création bot[modifier le code]

Hello, j'ai un peu de mal à réaliser l'auth de mon bot sur wikipedia, je pensais que je pouvais me passer d'un compte spécial bot et utiliser mon compte normal vu que ce n'est qu'une petite modif, mais j'ai des erreurs d'accès. J'ai essayé avec un bot password, mais je me tape des KeyError: 'messagecode' que je ne comprends pas trop. Pourrais-tu m'orienter rapidement ? Merci, Ywats0ns (discuter) 10 août 2020 à 19:40 (CEST)[répondre]

Bonjour Ywats0ns. Je viens de voir que depuis ce message d'hier tu as réussi à faire éditer ton compte principal en utilisant un programme automatique. Pour distinguer tes éditions manuelles et celles automatisées, sache qu'il est préférable que tu te crées un second compte par exemple nommé Ywats0nsBot, dans la page Utilisateur duquel tu inséreras le modèle {{Bot}}. Ensuite, demande le statut de bot pour ce compte, sur cette page, pour pouvoir utiliser le flag bot (et ne pas encombrer les listes de suivi des contributeurs). Compte tenu de tes premiers pas d'activité en mode bot, il ne devrait pas y avoir de souci. Il est aussi recommandé de mettre un lien interne vers la requête à laquelle répond le bot afin d'expliquer son action justifiée. Par curiosité, quel outil utilises-tu. — Ideawipik (discuter) 11 août 2020 à 11:57 (CEST)[répondre]
Hello,
j'avais cru voir qu'il était possible d'utiliser son compte principal en attendant d'obtenir le statut de bot, je me voyais mal demander un statut de bot alors que mon compte est jeune et que je n'avais jamais fait de bot. J'utilise pywikibot, je suis plus un fan de Python, et toi ? Ywats0ns (discuter) 11 août 2020 à 12:07 (CEST)[répondre]
Notification Ywats0ns. Même pour toi, je pense qu'il est préférable d'avoir un compte bot dédié. La création de ce compte est la première étape de la demande de statut donc autant le créer rapidement et l'utiliser pour montrer ce que tu peux apporter avec un robot. Idem, Pywikibot, légèrement personnalisé, mais j'utilise très peu, les scripts natifs, peut-être à tort. En revanche je me sers beaucoup d'un mwparserfromhell "amélioré localement" pour respecter les mises en formes. — Ideawipik (discuter) 11 août 2020 à 12:38 (CEST)[répondre]
Okay, j'ai créé le compte et j'ai fini les modifications avec, je passe la requête en "fait" Ywats0ns (discuter) 11 août 2020 à 14:30 (CEST)[répondre]
J'ai fait ma demande de statut, vois si tu peux passer donner ton avis ;-) Ywats0ns (discuter) 13 août 2020 à 12:51 (CEST)[répondre]

Demande une aide pour insérer des liens[modifier le code]

Bonjour!

Je vous remercie du fond du cœur pour vos explications précises, utiles et gentilles dans ma page. J’y ai répondu aussi :-).

Permettez-vous de demander encore une aide de votre part svp? Parce que j’ai un peu de difficultés pour insérer les liens, alors votre aide me fera un grand plaisir!

Sur la section Avalokitesvara en Corée(https://fr.m.wikipedia.org/wiki/Avalokite%C5%9Bvara), j’ai inséré les liens externes en français ou en anglais qu’on m’avait demandées. Mais on les a encore(!) supprimés! Pourriez-vous vérifier s’ils s’adaptent bien au wiki ou pas?

1. Temple Tongdosa

1) wiki en anglais

https://en.m.wikipedia.org/wiki/Tongdosa

2. Temple Naksansa

1) wiki en anglais

https://en.m.wikipedia.org/wiki/Naksansa

2) lien en anglais du site officiel de « Cultural Corps of Korean Buddhism » crée et dirigé par « Jogye Order Korea Buddhisme »

https://eng.templestay.com/temple_info.asp?t_id=naksansa

3) lien en français du site officiel de l’Office du Tourisme de Gangwon (Région coréenne)

https://www.gangwon.to/fr/gangwondo_trip/tourist_spot?control=AM0052_T&tourCode=TOSIGF00

3. un moine coréen Uisang

1) Site Wikifr, mais extérnes(?!) https://fr.qwe.wiki/wiki/Uisang

2) wiki en anglais

https://en.m.wikipedia.org/wiki/Uisang

3) Site de « New World Encyclopedia ». Selon le wiki, l’encyclopédie est plutôt suggérée, même en anglais ou en langue étrangère, en cas d’absence en français, c’est ce que j’ai remarqué.

https://www.newworldencyclopedia.org/entry/Uisang

J’aimerais bien préciser les liens que j’avais consultées pour écrire le texte, mais on continue à annuler. J’ai mis la question alors à la page de disscution(https://fr.m.wikipedia.org/wiki/Discussion:Avalokite%C5%9Bvara#Liens_externes_des_r%C3%A9f%C3%A9rences) mais cela ne semble pas résoudre.

Il me sera donc très reconnaissant d’avoir une aide de votre part.

Bien cordialement — Choyoung81 Choyoung81 (discuter) 22 août 2020 à 02:25 (CEST)[répondre]

Projet:Antipub/Homonymies avec Liens externes[modifier le code]

Bonjour,

Merci beaucoup pour avoir complété la page! Je me pose simplement une question : Comment faire une mise à jour régulière?

Je renouvelle mes remerciements pour cette page qui, j'en suis sur, aidera pour lutter contre la publicité dans wikipedia. RG067 (discuter) 22 septembre 2020 à 17:49 (CEST)[répondre]

Une chose qui m'étonne est le nombre de pages qui apparaissent dans cette liste. En effet, pendant la mois anti-pub @ContributorQ avait fait une liste du même genre (sauf erreur de ma part), qui ne contenait qu'une centaine de pages. Après, je ne connais pas grand chose à l'aspect technique et n'es aucune idée du pourquoi du comment. RG067 (discuter) 22 septembre 2020 à 18:06 (CEST)[répondre]
Bonjour RG067. Comme tu l'as vu, j'ai répondu sur la page de demande d'action des bots. Je suis persuadé qu'il existe des solutions plus efficace en termes de ressources rapidité et fréquence de mise à jour de la liste. Si l'idée finale est de travailler en conservant cette page, je pense qu'une mise à jour bi-mensuelle, comme fonctionnent certaines détections du projet Correction syntaxique serait suffisantes. Si cela facilite son utilisation, les contributeurs pourraient très bien éditer la page entre temps pour retirer ou barrer les éléments qui n'auraient plus de raison d'y figurer.
Quant au contenu de la liste (nombre de pages), je me rends compte qu'il y a de nombreux faux positifs, surtout dans la dernière partie de la liste, principalement en raison de certaines catégorisation de catégories qui apparaissent dans Catégorie:Homonymie comme Catégorie:Nom d'animal ambigu. Il s'agit aussi de pages catégorisés via un [[Catégorie:Homonymie]] sans être des pages d'homonymie. Le nom Catégorie:Homonymie et son introduction « Cette catégorie est automatiquement remplie par l’emploi du modèle {{Homonymie}} (et par tous les bandeaux pour page d'homonymie). » peuvent induire en erreur sur la destination de cette catégorie mais je conviens bien qu'elle n'est pas idéale pour l'objet de la demande. La méthode basée sur __DISAMBIG__ et les modèles d'homonymie est grandement préférable car elle correspond en réalité à ce qu'est réellement une page d'homonymie (j'avais hésité entre les deux méthodes et avais imaginé de comparer les deux). Sauf si une autre solution emerge, je remettrai la page à jour avec les vraies pages d'homonymie disponibles ici (mais limité aux 10000 premières). Pour les autres différences, s'il y en a, il faudra voir avec ContributorQ, la "définition" de page d'homonymie qu'il avait utilisée, mais on devrait concorder. Toutefois, selon moi, sur les quelques 6770 pages détectées (faux positifs inclus), il en restera au moins 4500 (seulement pour le modèle Homonymie) donc davantage avec les autres modèles qui apposent aussi un marqueur d'homonymie. Via Wikidata, on trouverait 5925 pages instance de page d'homonymie de Wikimedia.
Donc il serait bon de définir exactement ce que nous devons considérer comme page d'homonymie pour la détection, avant d'agir à nouveau. Cordialement. — Ideawipik (discuter) 22 septembre 2020 à 21:01 (CEST)[répondre]
Merci beacoup pour cette réponse détaillée! J'ai ouvert une section sur le projet anti-pub, nous allons voir les retours. Encore merci pour avoir répondu à la requête aux bots! RG067 (discuter) 22 septembre 2020 à 21:06 (CEST)[répondre]

Bonjour, la liste que je propose régulièrement au cours du mois anti-pub est une liste de pages d'homonymie contenant au moins un LE « nu » (voir explications détaillées).
La liste publiée par Ideawipik contient de nombreuses pages d'homonymie dont les LE ne sont pas nus ; ils sont inclus dans des références a priori légitimes, bien que les pages d'homonymie ne devraient pas présenter des réfs (ex. : page Elsa). --ContributorQ(✍) 23 septembre 2020 à 19:20 (CEST)[répondre]

Renommages lignes du métro de Los Angeles[modifier le code]

Bonjour,

Je réponds à votre message fait sur la page Discussion Projet:Transports en commun sur les nouveaux noms attribués récemment aux lignes du métro de Los Angeles.

1. Si je regarde les articles du projet, il me semble que le nom approprié serait plutôt sur le format « Ligne A du métro de Los Angeles ». Pouvez-vous me confirmer cela ?

Je ne crois pas qu'il y ait de réponse définitive, mais je pencherais vers le statu quo.

Les noms officiels et usités des lignes ne sont pas, par exemple: Los Angeles Metro Rail A Line ou lorsqu'un nom étranger est traduit: Ligne A du métro de Buenos Aires, mais uniquement A Line ou Ligne A. La précision entre parenthèses n'est utile que pour distinguer ces lignes des autres lignes qui ont le même nom. Les articles sur les lignes réseaux de Moscou ou de Taipei, par exemple, ne comportent pas l'ajout de du métro de Moscou ou de du métro de Taipei, parce que leur nom est fort probablement unique.

D'autres articles sur les réseaux de transport, comme ceux des autoroutes françaises ou canadiennes ne se nomment pas Autoroute A19 de la France, mais plutôt Autoroute A19 (France), vu qu'il s'agit du nom usité et probablement officiel de la voie.

Pour les réseaux de transport en commun, les articles adoptent les deux formes: Ligne X (métro de XYZ) ou Ligne X du métro de XYZ. Les réseaux de Montréal et de Barcelone utilisent par exemple la première forme. Beaucoup de réseaux urbains n'ont d'ailleurs aucun article créé pour leurs lignes de transport, particulièrement en Amérique.

2. Pour certains liens internes, il est possible de transformer le libellé du lien. Préférez vous que « ligne bleue » devienne « ligne A (bleue) » ou seulement « ligne A » ?

La dénomination bleue tendra à disparaître, cela commence même dans les communications officielles du LACMTA. Je privilégierais de garder que la lettre.

J'ai laissé le nom de couleur dans les textes à quelques endroits précis (comme dans les sections historiques), suivi du nouveau nom entre parenthèses, mais je l'ai complètement éliminée dans les articles plus spécifiques (ceux des stations). Les liens correspondants ont aussi été modifiés.

3. Bonjour Notification 67L31, si vous voyez d'autres modifications systématiques facilement automatisables, vous pouvez les faire connaître. Cela vous fera gagner du temps pour apporter du contenu aux articles.

J'ai pas mal renommé tous les noms de lignes dans les articles sur les lignes, sur les stations, sur le réseau en tant que tel et sur la ville de L.A. Il ne me reste que les articles sur les stations de la ligne L qui n'ont pas encore été modifiés, principalement, parce que la ligne changera de nom sous peu, lorsque des parties de son trajet seront intégrées à des lignes existantes. J'ai aussi déjà modifié le nom des palettes et modèles concernés.

4. 67L31 introduit aussi dans les articles des pictogrammes comme LACMTA Circle A Line.svg. Est-ce une pratique recommandé du projet. Si oui, vaut-il mieux introduire ces images directement dans le code des articles ou passer par un modèle intermédiaire comme cela est fait pour d'autres réseaux citadins.

Je ne suis pas familier avec le modèle intermédiaire, je ne pourrais vous dire pour ça... Ça m'apparaissait pourtant répandu.

Salutations, — Le message qui précède, non signé, a été déposé par 67L31 (discuter), le 23 septembre 2020 à 02:21 (CEST)[répondre]

remerciements[modifier le code]

Bonjour et merci pour vos remarques certainement toutes très pertinentes, et dont je vais tenir compte même si toutes ne me paraissent pas forcement évidentes.

Effectivement malgré la prise en compte de toutes les remarques et corrections faites par ceux, qui relisent les articles, je n'arrive pas vraiment à toutes les intégrer et les appliquer de façon constante.

Malgré les relectures, les corrections orthographiques sous word et les corrections syntaxiques sur le bac à sable avec prévisions, qui permettent de corriger un très grand nombre de fautes, les fautes persistent et sont trop nombreuses à votre avis pour permettre de continuer ce travail, ce que je comprend. Mon anglais est certainement trop approximatif et mon français aussi.

Je comprend que cela vous soit une charge de relecture importante et que la qualité prime sur la quantité.

Celle-ci est pourtant nécessaire pour la réalisation complète de travail, qui me semblait pourtant présenter un intérêt, du moins pour les lecteurs qui souhaitent trouver en français la richesse du wikipédia anglais.

La tache est énorme et peut être ne vaut elle pas la peine de mobiliser tant de corrections successives.

Il est de fait que les rivières m'ont amené à traduire les villes, et derrière, il y a tous les liens sur les routes, les lignes de chemin de fer, les montages et les lacs que j'ai exploré, et bien sur les personnalités.

De mois en mois, je m'y perd un peu et je perçois l'immensité des connaissances qu'il faudrait acquérir pour un si petit pays.

C'est vrai que je ne contrôle pas systématiquement les références et que beaucoup de liens renvoient, de fait, à des articles non encore publiés puisque toutes les références se croisent et que si j'ai traduit de très nombreux articles (j'ai en fait 6000 fichiers en attentes) , ils sont donc (par force) marqués comme des pages inexistantes, bien que potentiellement elles pourraient exister ultérieurement.

mais cela veut dire que le modèle lien est inutilisable tant avec l'item trad qu'avec frǃ car effectivement certains sont inexistant même en anglais et ce n'est pas moi qui pourrait les créer de toute pièce.

J'ai beau faire moi aussi la chasse aux guillements, erreurs d'ouverture ou de fermeture des modèles, aux blancs, aux accents sur les majuscules, aux majuscules anglaises qui n'existe pas en français et aux ponctuations et aux blancs avant/aprèsː tout est trop différent dans la typographie en anglais et en français, sans compter l'ordre dans les références des articles et des livres dans lesquelles je suis conscient d'introduire des erreurs en voulant corriger l'ordre des items pour répondre aux règles françaises, dont la logique m'échappe souvent, en particulier pour le ' qui apparaissent droit ou incliné et le " ou << avec la même touche selon le logiciel sous-jacent.

Quand à retourner lire les sources, je n'en ai vraiment pas le temps ni l'envie car s'il me paraissait intéressant de mettre à disposition de tous, la traduction de ces articles concernant toutes ces villes, je n'ai vraiment pas l'intension d'aller les explorer, même à travers la littérature anglaise.

Finalement je vois qu'il est plus sage d'arrêter complètement de publier, faute de pouvoir me faire relire par d'autres avant publication, car ces textes sont donc trop incertains et si je devais reprend à raison même d'une seule ville ou un lieu.. par jour, j'en aurai pour dix ans , ce qui de fait dépasse mon espérance de vie,et ce que de toute façon les corrections peuvent intervenir des années après, comme pour les rivières que j'avais publié il y a maintenant plus de deux ans, et pour lesquels les uns et les autres retrouvent et corrigent les imperfections.

Je vous remercie d'avoir pris le temps, tout comme Skoutarov et quelques autres de détailler les erreurs que je vais prendre le temps d'analyser et d'appliquer, sur les documents que je possède, même si au final cela ne servira peut être que pour moi même.

C'est peut être dommage pour les quelques uns qui m'ont remercier pour les publications précédentes, mais je ne vois pas comment faire une page de temps en temps car les fautes sont toujours les mêmes et bien trop nombreuses, malgré mes efforts.

Par contre ,comme je l'ai déjà proposé précédemment, je suis disposer à envoyer à quiconque, qui serait intéressé par le projet, de finaliser les villes de la Nouvelle-Zélande, une cl̠è-mémoire (400Mo) avec tous les textes à relire et mettre en forme adéquate pour les publier. C'est certainement un travail important mais que je confierai volontiers à toute personne intéressée par le sujet.

Ce serait peut être plus correcte mais encore faut il que quelqu'un soit intéressé par le sujet.

Il en est de même pour mes efforts pour promouvoir Wikipédia au niveau de Bourges car si les contributeurs sont éparpillés et n'ont pas l'occasion de se rencontrer,il n'y a vraiment pas de moyens de travailler en commun sauf à imposer aux autres les corrections à posteriori, ce que je regrette. Ceci me paraissait pourtant un principe moderne et efficace dans ce travail collaboratif, mais qui je le conçois n'est pas plaisant ni efficace puisque le même texte peut être relu par de multiples contributeurs qui parfois se contredisent avant d'aboutir à une forme stable.


J'espère au moins ne pas vous avoir choqué par les fautes que j'aurai fait malgré moi dans cette réponse, que je viens pourtant de relire de multiples fois. Mais je vous remercie donc très sincèrement, tout comme Skouratov et les autres contributeurs (Remy 34,Pautard,Remih, Franky007,Ga3lig,Jules,FD064 et bien sur Philippe rogez...et bien d'autres, y comprit les bots, qui sont très efficaces pour traquer les fautes et les blancs ) et je vous prie d'agréer mes meilleures salutations --Jgm18 (discuter) 8 octobre 2020 à 22:44 (CEST)[répondre]

Équipementiers Standard[modifier le code]

Bonjour, La syntaxe « '72 » signifie l'année de début. Les premières publicités commerciales sont autorisées en 1972, saison 72-73. Les informations viennent de la page 2 de "https://standardman11.skyrock.com/", un blog assez ancien et généralement bien documenté. Je n'ai pas référencé mes quelques ajouts, faute de savoir comme le faire. Avoir des petits chiffres dans le tableau lui-même ? me semblait peu esthétique. Merci pour l'aide technique. Amitiés --Shanon11 (discuter) 30 octobre 2020 à 13:28 (CET)[répondre]

Question PyWikiBot[modifier le code]

Hello Ideawipik Bonjour,
Je teste actuellement quelques fonctionnalités de PyWikiBot pour automatiser des extractions que je fais depuis longtemps à la main. Je me permet de te poser cette question car il me semble que tu l'utilises pour ton bot. Je comprendrai tout à fait si tu n'a pas le temps ou l'envie de te pencher sur mon problème, n'hésites pas à le dire.

Je bute sur un point pour extraire une section d'une page : celui-ci ne donne pas les résultats escomptés car au lieu d'extraire la section comme indiqué dans la doc de BasePage, il m'extrait la totalité de la page. J'ai écris le script de test minimal suivant, pour mette en lumière le problème. Je l'applique ici à une page de test car la page cible réelle est trop longue et spamme la console. 

import pywikibot  site = pywikibot.Site('fr', 'wikipedia')  def getSection(namespace, pageTitle, section):     completeTitle = pywikibot.site.Namespace.normalize_name(pageTitle + "#" + section)     pageWithSection = pywikibot.page.BasePage(site, completeTitle, namespace)     return pageWithSection  # Test 1 section1 = getSection(2, "Epok/Brouillon", "Section existante") print("Test #1") # Make sure section is correctly recognized print(section1.title()) # Should print "Utilisateur:Epok/Brouillon#Section existante" => OK print(section1.title(with_section=False)) # Should print "Utilisateur:Epok/Brouillon" => OK # Get content print(section1.exists()) # Should print True => OK print(section1.get()) # Should print only the section, but prints the whole page => NOK!  # Test 2 section2 = getSection(2, "Epok/Brouillon", "Section inexistante") print("Test #2") # Make sure section is correctly recognized print(section2.title()) # Should print "Utilisateur:Epok/Brouillon#Section inexistante" => OK print(section2.title(with_section=False)) # Should print "Utilisateur:Epok/Brouillon" => OK # Get content print(section2.exists()) # Should print False but prints True => NOK! print(section2.get()) # Should raise a pywikibot.exceptions.SectionError but prints the whole page => NOK!

Je ne sais pas si tu peux m'aider sur ce point ? Peut-être ai-je mal compris la fonctionnalité ?

Wikipédiennement, Epok__ (✉), le 31 octobre 2020 à 10:18 (CET)[répondre]

Salut Epok
Le choix du nom de variable pageWithSection est donc adapté puisque c'est la page entière Émoticône.
Je n'utilise pas toutes les fonctions de Pywikibot. Mais je peux t'orienter vers la fonction extract_sections de textlib qui dans le second élément renvoyé sections = textlib.extract_sections(textpage, site)[1] contient la liste des tuples (titre de la section avec les signes égal, texte de la section)
En itérant (indice i) sur le nombre de sections sections[i][0].strip(' =') devrait te donner le titre de la section courante que tu peux comparer au titre recherché. Le texte de la section est dans sections[i][1]. Mais attention ce qui est retourné est le contenu entre deux titres indépendamment de leur niveau et il faut donc traiter le résultat pour obtenir le contenu de la section réelle si elle contient des sous-sections.

Pour revenir sur ton code, les méthodes exists() et get() de pywikibot sont définies/appelées pour des objets de type "Page", donc il est normal qu'ils ne donnent pas le résultat que tu attends. On pourrait développer des méthodes pour cela, ce qui pourrait être fait de plusieurs façons. Je ne sais pas s'il existe déjà, dans la bibliothèque, un type d'objet "Section".
Voici juste un exemple de fonction toute simple qui fait en gros ce que tu cherchais à avoir, c'est à dire l'existence et le contenu entier de la section. Tu peux adapter à ta guise selon ce que tu souhaites. J'ai gardé, comme dans ton exemple une chaîne de caractère pour le paramètre pageTitle.
Attention néanmoins. Si tu comptes travailler sur beaucoup de sections dans une unique page, il est préférable d'écrire un programme adapté à cette tâche et de ne pas utiliser ces fonctions qui sollicitent le serveur en rechargeant la page à chaque appel.
J'ai peut-être fait des erreurs, mais voici ma contribution. — Ideawipik (discuter) 31 octobre 2020 à 15:06 (CET)[répondre]
import pywikibot from pywikibot import textlib  def getSection_exists(site, pageTitle, section):#fonction réduite si on veut juste tester l'existence de la section     page=pywikibot.Page(site, pageTitle)     textpage=page.get()     header, sections, footer = textlib.extract_sections(textpage, site)     for i, current_section in enumerate(sections):         if current_section[0].strip(' =')==section:#ici j'ai supposé qu'il faut respecter la casse du paramètre "section" de la fonction mais le test pourrait être adapté.             return True , current_section             break     else:#si on est ici c'est qu'on a pas satisfait le test (exeption à gérér à votre guise raise ?)         return False , 'Pas de section nommée « '+section+' »'  def getSection_exists_text(site, pageTitle, section):#fonction qui retourne le texte wikicode de la section en entier.     page=pywikibot.Page(site, pageTitle)     textpage=page.get()     header, sections, footer = textlib.extract_sections(textpage, site)     for i, current_section in enumerate(sections):         current_heading=current_section[0]         if current_heading.strip(' =')==section:#ici j'ai supposé qu'il faut respecter la casse du paramètre "section" de la fonction mais le test pourrait être adapté par exemple pour autoriser une initiale en majuscule ou un underscore pour les espaces.             current_section_long_text=[current_section[1]]#Le titre n'est pas dedans mais si on retire le [1], il sera dans le texte retourné.             bool_sous_section=True             j=i+1#integer to explore next sections/subsections till necessary             while bool_sous_section==True:                 try:                     next_heading = sections[j][0]                 except IndexError:                     next_heading = ''                 current_dep = (len(current_heading)                            - len(current_heading.lstrip('=')))                 next_dep = len(next_heading) - len(next_heading.lstrip('='))                 if current_dep < next_dep:                     current_section_long_text.extend(sections[j])                     j+=1                 else:                     bool_sous_section=False             return True , ''.join(current_section_long_text)             break     else:#si on est ici c'est qu'on a pas satisfait le test (exeption à gérér à votre guise raise ?)         return False , 'Pas de section nommée « '+section+' »'  site = pywikibot.getSite('fr') # Tests print("Test Section existante :\n"+str(getSection_exists_text(site,"Utilisateur:Epok/Brouillon", "Section existante"))) print("Test Section inexistante :\n"+str(getSection_exists_text(site,"Utilisateur:Epok/Brouillon", "Section inexistante"))) # Exemple avec des sous-sections print("Autre test :\n"+str(getSection_exist_text(site,"Olivia Colman", "Télévision")))
Wow, super ! Merci beaucoup pour ceci !
Je conclus donc que la doc n'est pas correcte en ce qui concerne les fonctions BasePage.exists() et BasePage.get(), car la première indique explicitement pouvoir faire ceci, et la seconde implicitement (via l'exception).
Je ne sais pas trop, s'il y a quelque chose pour les couples (page/nom de section). C'est possible mais quand je vois que .exists() considère seulement la propriété pageid qui est un attribut des pages Wikipédia, j'en doute.
Je note également que le numéro de l'espace de nom n'est pas nécessaire dans ta version car contrairement à BasePage qui note celui-ci "mandatory", ce ne semble pas être le cas pour Page (sauf si c'est nécessaire par héritage, mais il me semble que ça devrait alors être précisé). D'ailleurs à ce propos, même sans l'espace de nom ça fonctionnait quand même pour un objet BasePage, donc accumulé, ça me fait vraiment douter de la pertinence de la doc...
Dans PywikiBot, pourles pages, l'argument pour le paramètre namespace est passé indirectement (ou directement selon où on se place), dans le paramètre titre. Si je ne m'abuse c'est juste qu'il y a plusieurs manières de procéder, qui ne sont pas incompatibles. Ainsi, pywikibot.Page(site, "Epok/Brouillon", ns=2) est équivalent à pywikibot.Page(site, "Utilisateur:Epok/Brouillon") ou même à pywikibot.Page(site, "Utilisateur:Epok/Brouillon", ns=2). Il est fort probable qu'initialement il fallait obligatoirement spécifier le namespace d'un coté et le titre de la page (version courte sans le namespace). C'est plus souple aujourd'hui.
Au sujet du paramêtre nommé namespace de la fonction de mon exemple. J'ai retouché le code : il s'agissait d'un site. Tu auras compris que je n'ai pas vérifié le nom du paramètre, en recopiant ton code, ce paramètre n'était pas utilisé, même implicitement et comme j'avais défini le « site » du programme principal avant les fonctions et avec le même nom que le paramètre, la coquille passait inaperçue. Désolé si cela t'a induit en erreur. C'est mieux ainsi.
Mais avec ce code, pas de soucis, il fonctionne à merveille ! Et pas de soucis de surcharge de requêtes, c'est une fonction lancée une fois de temps en temps sur une page.
Ce que je voulais dire c'est que tu pourrais charger une seule fois le texte de la page de Maintenance, exécuter une seule fois la fonction extract_sections() et utiliser à volonté la liste locale obtenue, pour tous les titres de section qui t'intéressent potentiellement. Remarque : la page mentionnée ne contient que des titres du même niveau donc si tu es certain que cette structure ne changera pas, tu peux t'épargner la boucle while de la seconde fonction et économiser aussi en parcours de la liste des sections, en traitant la page de la sorte : 
for i, current_section in enumerate(sections):     current_section_title=current_section[0].strip(' =')     if current_section_title=="Redirections de modèle obsolètes et inutilisées":         …#Utiliser le texte contenu dans current_section[1]     elif…
C'est tout.
Après, l'étape suivante sera probablement de me libérer de PAWS pour faire certaines de mes extractions et pouvoir faire celles-ci sur un dump local pour éviter les requêtes à répétition : je fais aussi des parcours de catégories est c'est bien évidemment TRÈS long de tester toutes les pages sur plusieurs niveaux de hiérarchie. Mais je n'ai pas encore trouvé comment faire pour faire référence à un dump local plutôt que des requêtes, faudrait que je me penche dessus.
Quand tu parles de « tester toutes les pages sur plusieurs niveaux de hiérarchie », cela veut-il dire que tu retestes potentiellement les mêmes pages qui seraient multi-catégorisées ? Si c'est le cas, il est préférable d'établir en amont la liste complète des candidats (croisement/ combinaisons de catégories) par une méthode adaptée (par exemple un recherche Petscan) et de travailler ensuite sur les articles de cette liste.
Mon utilisation des dumps consiste à les parcourir en entier. En version simple : for page in xmlreader.XmlDump(chemin_complet_du_fichier_dump_local).parse(): Il y a alors accès aux page.ns, page.id, page.title ou page.text. J'en extraie, par exemple, des dictionnaires de redirections que je peux réutiliser ensuite. Ou j'analyse leurs contenu. Pour réduire les sollicitations serveur, voir aussi pagegenerators.py, notamment du coté de XMLDumpOldPageGenerator, en filtrant, selon le namespace et selon le contenu du texte de l'article avec une fonction dans text_predicate. Enfin, il y a la possibilité de travailler sur des dépôts partiels personnalisés qui peuvent être générés à partir des catégories dans Spécial:Exporter. J'imagine qu'il ne faut pas abuser de cet outil.
Encore merci !
Wikipédiennement, Epok__ (✉), le 31 octobre 2020 à 15:40 (CET)[répondre]
Notification Epok. Réponse ci-dessus entre les lignes et correction d'une petite coquille dans le code. Bonne soirée. — Ideawipik (discuter) 31 octobre 2020 à 19:49 (CET)[répondre]
Merci pour ces précisions.
Concernant les tests de pages dans des catégories, et des sous- et sous-sous-, etc. j'adopte en fait l'approche inverse : plutôt que de dresser une liste en amont, je crée au fur et à mesure une liste des pages déjà traitées, et j'ai une fonction d'itération (qui prend en paramètre ma fonction de traitement) qui vérifie d'abord que la page n'a pas déjà été traitée. Cela me permet également de définir des listes d'exceptions (pages/catégories à ne pas traiter). D'un côté ça impacte probablement les performances (nécessité pour chaque page de checker dans un set ou un dictionnaire), mais d'un autre ça m'épargne un travail en amont pour peu que je connaisse la catégorie racine. Pour rappel, il s'agit uniquement d'extraction d'information, pas de modification par le code (pas assez confiant pour ça pour l'instant).
Concernant les dumps, le problème que j'avais était d'appliquer mes scripts "live" sur un dump, en indiquant que le fichier (après parse par xmlreader.XmlDump) était la source de données et non le site. Mais je déduis de ce que tu dis que ce n'est pas l'utilisation "normale" du truc.
Grand merci pour tout ton temps,
Wikipédiennement, Epok__ (✉), le 31 octobre 2020 à 20:08 (CET)[répondre]

Modèle Joueur feuille de match[modifier le code]

Bonsoir Ideawipik, je n'ai pas compris ton dernier message sur le Café, c'est du charabia pour le novice que je suis en codage (je pense même pas que ce soit le terme adéquat). Concrètement, que dois-je faire si je veux simplifier ce modèle sur toutes les pages associées ? --Nebuno (discuter) 1 novembre 2020 à 20:15 (CET)[répondre]

Bonjour Nebuno. Pas de problème. Je tente quand même de t'expliquer ci-dessous, puisque tu t'es proposé pour agir Émoticône. Il s'agit bien de travailler sur cet article qui pose des problèmes d'affichage en raison des modèles (taille d’inclusion après expansion)
La proposition de remplacement faite consistait à ne plus passer par un modèle pour afficher le texte des joueurs, c'est à dire de remplacer les modèles par du simple texte. Cela ne pose pas de problème étant donné que le modèle en question ne fait pas une mise en forme de « ouf ». Il s'agit de convertir les suites de modèles en un texte formaté autrement. Par exemple
{{Joueur feuille de match | numéro = 1 | [[Karl-Johan Johnsson]] {{gardien}} }} {{Joueur feuille de match | numéro = 5 | [[Marcos Aoás Corrêa|Marquinhos]] }} {{Joueur feuille de match | numéro = 8 | Robert {{cap}} }}
en  [[Marcos Aoás Corrêa|Marquinhos]], [[Karl-Johan Johnsson]] {{gardien}}, Robert {{cap}},
Il convient donc de remplacer la première ligne par un espace suivi de [[Karl-Johan Johnsson]] {{gardien}} suivi d'une virgule et ainsi de suite.
En profitant du fait que presque tous les modèles de la page sont insérés en respectant une syntaxe identique syntaxe (même ordre des paramètres), la recherche (expression régulière ou regex) suivante permet de capturer le numéro et le nom du joueur pour les lignes sous les formes précédentes, y compris {{joueur feuille de match|numéro =5|[[Toto]] {{Gardien}} {{Cap}}}}.
La recherche stocke temporairement le numéro du joueur dans une variable temporaire numérotée "\1" ou "$1" et le contenu du second paramètre dans une variable numérotée "\2" ou "$2". Expression régulière pour la recherche :
\s*\{\{ *[Jj]oueur feuille de match *\| *numéro *\= *([0-9]*) *\| *((?:[^\[]+?|\[\[[^\]]+\]\])(?: *\{\{(?:[Gg]ardien|[Cc]ap)\}\})*) *\}\}\s*

Quand tu édites une page, en cliquant sur « Modifier le code » et choisissant « Avancé », tu accèdes à droite à un outil « Rechercher/Remplacer » qui accepte les expressions rationnelles (case à cocher), En recherchant l'expression régulière donnée ci-dessus et faisant remplacer par « espace à taper au clavier+$2+virgule au clavier », tu obtiendra le résultat souhaité. Le numéro du joueur n'est pas réutilisé mais pourrait l'être.

Ensuite, il faut faire de même avec les modèles qui ont un paramètre sortie comme {{Joueur feuille de match | numéro = 17 | [[Ole Kristian Selnæs]] | sortie = 64}}. L'expression suivante:
\s*\{\{ *[Jj]oueur feuille de match *\| *numéro *\= *([0-9]+) *\| *((?:[^\[]+?|\[\[[^\]]+\]\])(?: *\{\{(?:[Gg]ardien|[Cc]ap)\}\})*) *\| *sortie *= *([0-9\+]+) *\}\}\s*
permet de récupérer le numéro dans $1, son nom dans $2 et la minute de sortie dans $3. À remplacer par :
« espace à taper au clavier+$2 ({{suboff}}{{subon|$3}} XXXXX)+virgule au clavier ».
Tu obtiens donc, dans l'exemple donné, « Ole Kristian Selnæs (RemplacéEntré après 64 minutes 64e  XXXXX), ». Cela permet de suivre la syntaxe donnée dans Modèle:Feuille de match#Exemples d'utilisation (effectif simple). Les XXXXX seront à remplacer ultérieurement par les bonnes valeurs.

Ainsi, sur les près de 1 200 modèles de la page, tu en as traitées un environ de 950 en trois clics. Il ne te restes qu'à :
  • traiter manuellement que les modèles restants, c'est-à-dire remplacer les XXXXX par les noms des joueurs correspondant à ce changement, noms qui se trouvent dans les modèles restants de la même feuille de match ;
  • remplacer les paramètres « joueurs 1/2 » par « effectif 1/2 » et retirer les virgules superflus à la fin de ces paramètres ;
  • vérifier qu'il n'y a plus de « XXXXX » et supprimer les paramètres « remplaçants 1/2 » désormais inutiles;
  • en option, pour fignoler et gagner en lisibilité du code, retirer les commentaires vides qui étaient présents dans la page entre les modèles.
Et on ne doit plus être loin du résultat final, avec une page allégée en modèles. Si pour un match (une finale ?), tu souhaites garder la version un poil plus longue, rien n'empêche de reprendre la section dans l'historique de l'article, en ouvrant une autre page de navigateur.
Étapes finales : Prévisualiser pour repérer les problèmes éventuels. Sauver le contenu de la page dans un fichier, au cas où il y ait un problème lors du transfert sur Wikipédia. Et sauver la page. En cas de conflit d'édition (peu probable), il est préférable de reporter les modifications récentes de l'autre contributeur sur ta version, avant de retenter un enregistrement. — Ideawipik (discuter) 1 novembre 2020 à 22:52 (CET)[répondre]
Merci pour cette réponse détaillée, je vais prendre le temps de la comprendre avant de tenter des modifications. --Nebuno (discuter) 1 novembre 2020 à 23:08 (CET)[répondre]
Ideawipik (d · c · b) J'ai tenté de le faire mais je pense ne pas être au niveau. J'ai importé quelques feuilles de matchs détaillées sur mon brouillon pour le faire. Sur la recherche avancée, j'ai coché la case indiquée et tapé \s*\{\{ *[Jj]oueur feuille de match *\| *numéro *\= *([0-9]*) *\| *((?:[^\[]+?|\[\^\+\]\])(?: *\{\{(?:[Gg]ardien|[Cc]ap)\}\})*) *\}\}\s* puis espace $2 , mais ça ne marche pas. Je pense tout simplement n'avoir pas compris, même si c'est bien expliqué. Faut-il que je tape par exemple {{Joueur feuille de match|poste=DC|numéro=4|[[Ruben Gabrielsen]] {{cap}}}} suivi de tous les autres joueurs qui sont au moins mentionnés une fois ? Ces changement prennent-ils en compte les postes ? Je suis pas sorti de l'auberge. --Nebuno (discuter) 1 novembre 2020 à 23:32 (CET)[répondre]

J'avais mal compris, en fait le modèle est totalement remplacé par un effectif simplifié. Je trouve ça un peu dommage. Dommage qu'il n'y ait pas d'autres solution pour la page en question. Personnellement, j'aime beaucoup ce modèle qui est clair et plus agréable à la lecture. Je pensais qu'on simplifiait seulement le modèle afin qu'il prenne moins de place mais c'est pas possible. --Nebuno (discuter)
Notification Nebuno. Tu as bien suivi les consignes et compris la raison du problème. Ce qui précède ne marche que pour une syntaxe sans poste et que si on est dans le même ordre de paramètres que les premiers exemples, ce qui était le cas dans tous les modèles de la page à l'origine de cette discussion.
\s*\{\{ *[Jj]oueur feuille de match *\| *poste *\= *[^\|]*[^ ] *\| *numéro *\= *([0-9]*) *\| *((?:[^\[]+?|\[\[[^\]]+\]\])(?: *\{\{(?:[Gg]ardien|[Cc]ap)\}\})*) *\}\}\s* fonctionnera pour ton cas, en ne capturant toujours que numéro du joueur en $1 et nom du joueur+modèle cap/gardien en $2
Plus simple: il est possible d'avoir des paramètres nommés plutot que basés sur la position des groupes de capture comme dans
\s*\{\{ *[Jj]oueur feuille de match *\| *poste *\= *(?<poste>[^\|]*[^ ]) *\| *numéro *\= *(?<num>[0-9]*) *\| *(?<joueur>(?:[^\[]+?|\[\[[^\]]+\]\])(?: *\{\{(?:[Gg]ardien|[Cc]ap)\}\})*) *\}\}\s* où tu peux réutiliser $<poste>, $<joueur> et $<num>. Cette dernière recherche ne trouvera que les modèles où le poste et le nom sont non vides. Mais le numéro peut être vide.
Je t'invite à lire des aides sur les regex si cela t'intéresse. afin de définir exactement celle qui correspond à ton attente pour chaque cas.
Si l'ordre des paramètres est aléatoire ou disparate, l'utilisation des regex n'est plus vraiment possible et il faudra plutôt se tourner vers d'autres outils d'analyse.
Si la substitution ne convient pas, tu peux à la place remplacer par <br>$2 afin de conserver un joueur par ligne voire par <br>$1. $2 avec le numéro du joueur avant le nom. — Ideawipik (discuter) 2 novembre 2020 à 00:38 (CET)[répondre]
Merci de m'avoir aidé, c'était intéressant, Ideawipik (d · c · b). Je voulais alléger la page de la saison 2018-19 de Guingamp mais InfraRouge77 s'en occupe donc je n'ai pas besoin de cela pour la page dont je m'occupe car je trouve le modèle bien plus clair que les effectifs simplifiés. Si je pouvais simplifier ce modèle afin qu'il ne prenne pas tant de place ou du moins ne fasse pas trop d'appels (pour faire simple), je le ferais mais ça semble compromis. Bonne nuit. --Nebuno (discuter) 2 novembre 2020 à 00:45 (CET)[répondre]

┌─────────────────────────────────────────────────┘
 Bonsoir Ideawipik (d · c · b), juste par curiosité, je me demande comment tu as pu rendre le paramètre postes optionnel ? Est-ce que sa mise en option va alléger le modèle et aurait pu régler le problème de le saison 2018-19 de Guingamp ? Et quelle est la dysfonctionnalité présente depuis la création de ce modèle que tu as corrigé ? Merci pour ces corrections. La prochaine fois, je serai plus prudent dans mes interventions dans le domaine des modèles, je ne pensais pas à mal mais je ne gère pas la technique. --Nebuno (discuter) 3 novembre 2020 à 00:08 (CET)[répondre]

Je remarque que depuis ta modification, il y a petit problème. En mode mobile, ou même ordinateur, l'alignement de certains, voire de tous les joueurs n'est pas fait, ce qui rend la lecture peu agréable (exemple : Community Shield 2020). C'est pour cela que j'avais mis {{nobr|}} pour que l'alignement se fasse. --Nebuno (discuter) 3 novembre 2020 à 06:36 (CET)[répondre]
Bonjour Nebuno. Il est évident que tes maladresses étaient involontaires. Si tu veux intervenir efficacement dans les modèles, il faudra apprendre quelques rudiments techniques. Et ne pas oublier que les modèles doivent se mettre au service du consensus éditorial. Pour commencer ta formation, je te conseille déjà Aide:Créer un modèle, mw:Aide:Extension:Fonctions d'analyse et mw:Help:Parser functions in templates, et pour faire des essais Spécial:ExpansionDesModèles ou Modèle:Brouillon Modèle:Bac à sable ou une autre page de brouillon. Le retrait de ces insertions de cases vides aurait assurément réglé ou du moins grandement atténué le problème. Tu peux t'en convaincre en regardant la version labellisée de l'article (du 27 novembre 2019) qui ne devrait plus présenter les problèmes d'affichage qu'elle présentait avant la correction dans le modèle. Néanmoins léger reformatage actuel ne porte pas préjudice à l'article, comme le reconnaît son auteur. Enfin si tu veux vérifier si des pages posent un problème avec un modèle deux exemples de catégories : Catégorie:Page avec trop d'appels dispendieux de fonctions parseurs ou Catégorie:Page contenant trop d'inclusions de modèles.
Petit problème d'alignement. Techniquement, le décalage relevé sur l'exemple donné provient davantage du saut de ligne qui peut se placer entre le pictogramme sortie (ou entrée) et la minute correspondante (dans les modèles Suboff/on). Enfin cela dépend aussi de la taille de ton écran. Je crois que c'est aussi pour limiter ce risque de non alignement que certains contributeurs préfèrent mettre 92e plutôt que 90+2e. Les autres raisons de ce petit problème d'alignement sont les suivantes. Premièrement, certains noms dans le tableau sont long. C'est le cas de Pierre-Emerick Aubameyang, affublé du dossard/modèle de capitaine. Deuxièmement, en usant concomitamment de plusieurs options du modèle Feuille de match (image de la composition), et du modèle pour les joueurs, on demande d'afficher beaucoup, de chose sur la même ligne, dont une image de taillé fixée.
Possibilités:
  1. On accepte les sauts de ligne et la génération du tableau optimale au regard de la taille de l'écran et des contraintes imposées, même si la lisibilité et l'esthétique peuvent s'en trouver affectées.
  2. On force l'affichage sur une seule ligne de chaque joueur, comme tu le préférerais. En pratique, dans ce cas, il est peut-être préférable de ne placer un {{nobr}} que pour le joueur dont le nom est le plus long et directement dans l'article. Cela donnera le même rendu, sans alourdir le code du sous-modèle et sans augmenter les risques d'atteindre les limitations en nombre et taille d'expansion des modèles que pouvait poser ta proposition. Si vraiment, tu peux m'assurer que l'affichage sur une seule ligne pour toutes les cases de tous les tableaux d'effectifs, fonctionnement différent de ce qui s'est pratiqué jusqu'à ton intervention dans le modèle « Joueur… », est consensuel, une solution sans passer par un autre modèle serait possible directement dans modèle. Bon, admettons qu'on choisisse cet affichage plutôt que le précédent. C'est peut-être mieux mais… Inconvénient : on peut facilement arriver à une feuille de match faisant trois fois la largeur de base réservée au texte d'un article. Pas bon en termes d'accessibilité en obligeant le lecteur à déplacer latéralement le contenu pour le lire en entier !
Ce qui permet de réfléchir à deux points, au moins :
  • Est-ce que tout ce que je veux afficher est d'ordre encyclopédique ou mérite d'être répété sur chaque feuille de match ? Par exemple, les postes ? Cela fait un siècle que l'on arrive à peu près bien à distinguer des postes de joueurs. Les joueurs se spécialisent dans un rôle et en changent rarement. Est-il opportun de rappeler ces postes et des détails de nuance comme « milieu latéral » ou « piston », « défenseur central » ou « libéro ». Les caractéristiques de jeu des joueurs devraient plutôt être développées sur les pages des joueurs, les changements de postes ponctuels, un attaquant qui remplace un gardien, dans le corps de l'article. Est-il nécessaire d'insérer un drapeau de nationalité pour chaque joueur quand on peut accéder à cette information en cliquant sur le lien interne. Les numéros écrits sur les maillots m'apparaissent encore plus anecdotiques pour figurer ici. Omettre les informations secondaires, fait partie du travail encyclopédique.
  • Est-ce que l'affichage de certains détails pourrait être omis ou réalisé différemment, en fonction de la largeur de l'écran du lecteur ? Par exemple, sur les écrans étroits, se contenter du tableau des joueurs sans l'image de la composition. ou placer l'image en dessous plutôt qu'au milieu.
Note : Ce n'est pas très visible mais les tableaux des effectifs sont définis comme ayant 3 colonnes dans Feuille de match. Or, ta modification en spécifie 4 pour chaque ligne. Il serait plus propre pour le code html de paramétrer cela dans le code de feuille de match et peut-être d'ajouter un paramètre à Joueur pour établir la première ligne du tableau. Cela permettrait également de fixer une largeur pour la seconde colonne sans avoir à bricoler avec un espacement artificiel {{0}}.
Note 2 : Pour information, le rendu de la feuille de match, depuis sa conception mais surtout avec les ajouts d'options au cours du temps, n'est pas très accessible pour les non-voyants, étant constitué de tableaux imbriqués. — Ideawipik (discuter) 5 novembre 2020 à 18:26 (CET)[répondre]
Bonsoir, Ideawipik (d · c · b). Une nouvelle fois merci pour cette intervention. L'exemple donné du Community Shield 2020 est spécial car c'est l'affaire d'un seul match et c'est fréquent que les feuilles soient détaillées avec les nationalités dans ces articles ; je n'ai qu'ajouté les postes. Sur l'article de la saison 2020-2021 du Toulouse Football Club, j'applique simplement les postes sans les nationalités car ça serait de l'excès de détail, même pour moi.
Concernant les postes, il est vrai que c'est discutable mais dans le cas d'une saison de club, on peut avoir affaire à des changements tactiques fréquents (passer du 4-3-3 au 4-2-3-1 qui va faire changer de poste certains joueurs). Mon avis n'est probablement pas le plus objectif et encyclopédique mais je trouve intéressant de préciser les postes, surtout que l'option que j'ai installé ne nécessite que de mettre poste=AC par exemple. Sachant qu'ils sont spécifiés dans certaines pages comme celles de finales, je me chargerai de les compléter car les abréviations peuvent ne pas être comprises par tous, même si la majorité des visiteurs de ces pages sont plus ou moins de connaisseurs.
Le problème de l'affichage est surtout une envie personnelle que tout soit bien aligné mais ce n'est pas grave, tant que le lecteur n'est pas perdu.
J'ai du mal à comprendre la partie Note malgré mes relectures, est-ce que tu peux t'en charger, si tu as le temps et surtout l'envie ? Je souhaite pas te perdre faire du temps en longues explications. De plus, dans le commentaire laissé sur ta modification, tu écris : « S'il faut gérer width, padding ou spacing, il conviendrait de le faire proprement à l'échelle du tableau dans Modèle:Feuille de match ; ils seront à revoir. » Ici aussi, je ne comprends pas trop mais si tu maîtrises le sujet, je préfère que tu t'en charges également. J'espère ne pas être directif mais tu gères mieux la technique que moi.
J'ai une autre question qui concerne des tableaux. J'ai créé un tableau des meilleurs buteurs du championnat japonais 2020 mais je trouve qu'une de ses colonnes est trop large par rapport aux autres et surtout à son contenant.
Buteur Club Buts MJ1 Pen.2 Min.3
Médaille d'or Michael Olunga Kashiwa Reysol 23 24 1 2 111
Médaille d'argent Everaldo Kashima Antlers 14 27 1 2 158
Médaille de bronze Erik Yokohama F. Marinos 13 27 0 1 631
La colonne Pen. peut-elle être rétrécie ? Je me suis rendu sur les pages Aide:Tableau et j'ai découvert le paramètre width mais là encore, je l'utilise mal. J'ai tenté de l'appliquer sur les différentes colonnes ou en début de tableau mais rien n'y fait. Comme tu peux le constater, mon problème est là encore simplement esthétique mais si il est possible de rétrécir une colonne spécifique, je suis preneur. --Nebuno (discuter) 5 novembre 2020 à 23:18 (CET)[répondre]
Je suis gourmand avec mes questions. Je me permets d'en rajouter une mais ce sera la dernière. Ça concerne également un tableau.
Matchs internationaux
J'ai divisé la colonne Performances en deux. Est-ce possible de également diviser les deux sections Buts et Pas. ? --Nebuno (discuter) 6 novembre 2020 à 03:34 (CET)[répondre]

Infobox JV[modifier le code]

Salut @Ideawipik ! C'était pour savoir si ça avançait du côté du changement d'infobox JV ou si tu veux que je demande à quelqu'un d'autre. Bonne journée Goombiis (Discuter) 6 novembre 2020 à 14:42 (CET)[répondre]

Micromodifications[modifier le code]

Dommage qu’il vous réponde ainsi alors que vous avez été patient, poli et pédagogue. — Thibaut (discuter) 14 novembre 2020 à 23:34 (CET)[répondre]

Modèles[modifier le code]

Bonjour Ideawipik, je viens vers toi car j'ai besoin d'aide sur une petite modification que je souhaite apporter au modèle. J'ai créé le paramètre liench2 et il parvient à marcher si on déploie les paramètres mch, bch et pch ainsi que mcu, bcu et pcu. Ce paramètre permet de créer un lien vers la saison de championnat sur la colonne des matchs. Je souhaiterais que ce soit possible d'activer ce lien sans l'usage de ces paramètres et j'essaye de le faire sur le Bac à sable et la page de test mais la valeur s'affiche deux fois (sur le premier tableau, troisième ligne).

Dans un autre registre, sur la page du modèle Joueur feuille de match, j'aimerais rendre possible une séparation entre les postes grâce à l'usage de ---- comme sur la page d'Argentine - Angleterre (1986) mais je crois que le <!-- --> le rend impossible. Si ce n'est pas possible, ce n'est pas grave. Bonne après-midi. --Nebuno (discuter) 8 décembre 2020 à 15:56 (CET)[répondre]

Bonsoir Ideawipik, merci pour ces modifications. Concernant la ligne de séparation, ce n'est pas possible ? Bonne soirée. --Nebuno (discuter) 9 décembre 2020 à 19:24 (CET)[répondre]

Bonsoir Nebuno. Voici plusieurs réponses et réflexions.
A. Remarques de syntaxe (Fstats). Le code de ce modèle contient pas mal de code qui pourrait être simplifié par exemple {{#if: {{{mch|}}} | {{{mch}}} | {{{5}}} }} peut s'écrire {{{mch|{{{5}}}}}}précision utile. Je regarderai pour faire un ménage en ce sens.
B. Problème actuel de ta modification (Fstats). Pour l'affichage en double c'est logique… Enfin, cela correspond à ton code avec un affichage de mch (ou du paramètre 5) suivi d'un affichage du paramètre 5 avec le lien. Personnellement, je ne vois pas ce que l'ajout de ce lien apporte comme amélioration. Il alourdit juste le tableau, ce même lien interne étant déjà présent, dans la case précédente.
C. Ajout d'un trait entre les postes (Feuille de match). Vu que l'on est dans un tableau, le plus propre et plus respectueux de l'accessibilité (qui est déjà très dégradée par l'imbrication de tableaux) serait de spécifier un séparateur/bordure (ligne continue d'épaisseur particulière) sur (avant) le premier joueur listé à un poste donné. Dans la pratique et si on garde le fonctionnement actuel, il serait plus facile de le mettre sur (après) le dernier joueur à un poste donné.
Solution immédiatement applicable. Il suffirait, pour ce faire, d'ajouter :
1. dans {{Feuille de match}}, un border-collapse:collapse; ✔️ et non problématique par rapport au modèle actuel.
2. dans {{Joueur feuille de match}}, remplacer l'avant-dernière ligne {{!-}} par {{!-}} {{#if {{{trait|}}}| style="border-top: thin solid black;"}}
3. dans l'article concerné, ajouter le paramètre |trait=oui dans le sous-modèle pour le (dernier) gardien, dernier défenseur et dernier milieu de terrain.
Cependant, comme le modèle Feuille de match est bancal, surtout depuis l'ajout d'une quatrième colonne pour les postes, on pourrait améliorer cela. Il serait possible de définir le nombre de colonnes dans le modèle Feuille de match. On peut imaginer l'ajout d'une ligne d'en-tête (pas forcément affichée) pour définir les colonnes et largeurs.
On pourrait alors définir chaque ligne en entier dans le modèle Joueur feuille de match. Idéalement, il conviendrait de commencer chaque ligne introduite pas ce second modèle par un {{!-}} et on pourrait alors retirer dans les articles tous les commentaires (actuellement indispensables) et espaces entre deux modèles successifs, pour les remplacer par un simple saut de ligne. Cependant, il faudrait que toutes les insertions du modèles respectent la syntaxe préconisée pour ce paramètre (joueurs 1/2) avec l'utilisation du sous-modèle. Ce n'est pas le cas actuellement joueurs 1 et joueurs 2
Un code plus propre et plus logique permettrait de pouvoir afficher le trait au dessus du premier D, du premier M et du premier A. Il me semble que que cela serait mieux que la solution proposée plus haut.
Es-tu prêt à reprendre les articles repérés, pour conformer l’insertion du modèle à la syntaxe recommandée ? Si oui, attends mes instructions afin que nous soyons efficaces sans avoir à repasser ultérieurement dans les articles pour retirer les commentaires, lors du basculement de fonctionnement.
Cela dit, l'ajout d'une ligne de séparation est plutôt de l'ordre du gadget. Je ne suis pas du tout convaincu de sa pertinence, bénéfice/complexification des modèles, surtout pour les rédacteurs.
D. Pour reprendre le sujet plus haut, le problème des alignements (Feuille de match) relevé précédemment provient de deux choses. a) Il y avait une dissymétrie dans la largeur des colonnes imposée dans le modèle. b) La présence du {{nobr}} sur la colonne nom du joueur augmente le risque d'avoir des lignes plus large pour tous les membres, (joueurs et remplaçants) de l'équipe dont un nom de joueur est très long, parce qu'une autre colonne de ce même tableau sera imposée plus petite en comparaison avec celle l'autre équipe et obligera le contenu à s'afficher sur deux colonnes. Il me parait préférable d'avoir un décalage pour un seul joueur plutôt qu'un décalage qui s'additionne ligne par ligne, donc je serais plutôt favorable à retirer le nobr que tu as déjà ajouté à deux reprises (la plus récente ici), celui là même qui augmente le décalage dont tu te plains.
D'. Pour limiter les risques de mauvais alignement pour les petits écrans, j'ai proposé un affichage s'adaptant à la largeur de l'écran ou de la fenêtre. Est-ce que cela fonctionne pour toi ?
J'ai aussi modifié légèrement le code de Feuille de match qui requiert un paramètre poste=oui, dans les cas qui t'intéressent. Et on pourra retirer le {{0}} inélégant de « Joueur feuille de match », mais je te rappelle que le projet football n'est pas forcément favorable à ces précisions et que la solution dont je parle n'est pas forcément à conserver à long terme. Je vois trois possibilités fonctionnelles. J'essayerais demander l'avis d'un spécialiste avant de faire un choix.
E. Détail éditorial. Pour les postes, dans le modèle Joueur… , il me semble que regrouper GB et G, DF et D, ML et M, AT et A ne nuirait pas à une lecture plus aisée des différents postes. Une légende harmonisée pour des réalités identiques.
F. Conseil de méthodologie.
Sais-tu que tu peux tester tes modifications dans un modèle, sans les enregistrer (i.e. sans appuyer sur le bouton « Publier les modifications »). Cela évite d'allonger l'historique du modèle et de "faire profiter" aux autres utilisateurs de tes tâtonnements. Cela est évident pour les modèles qui affichent quelque chose dans la page du modèle, à la prévisualisation. C'est aussi possible pour pour les modèles en <includeonly>.
  • Méthode 1 qui marche dans toutes les pages :
    • ajouter en bas de ton code <noinclude>{{Titre de page|paramètres à tester du modèle}}</noinclude>. C'est entre ces balises que tu pourra faire tes tests ;
    • appuyer sur « Prévisualiser » ;
    • retoucher ton code et tes tests autant que nécessaire
    • quand tu es satisfait du code du modèle, retirer toute la partie de test, avec les balises noinclude puis publier les modifications.
  • Méthode 2 qui marche sur les pages de l'espace modèle et si on veut tester les conséquences des modifications du modèle sur une le contenant déjà.
    • entrer le nom de la page à tester dans la zone de saisie « Aperçu de la page avec ce modèle » puis cliquer sur « Afficher l'aperçu »
C'est tout. Bonne lecture ! J'ai conscience que tout n'est pas très clair. — Ideawipik (discuter) 9 décembre 2020 à 19:43 (CET)[répondre]
Bonsoir ! Je n'ai lu que tes points A et F et j'ai quelques remarques.
Le point A est totalement faux lorsqu'un paramètre est vide (voir Aide:Créer un modèle#Valeur par défaut d'un paramètre).
Nous sommes d'accord pour dire que sa méthodologie n'est pas bonne. J" lui ai déjà conseillé d'utiliser le bac à sable et sa page de test).
--FDo64 (discuter) 9 décembre 2020 à 21:18 (CET)[répondre]
Bonjour et merci FDo64 pour tes remarques judicieuses. Tu as raison d'être rigoureux. J'aurais mieux fait de dire « {{#if: {{{mch|}}} | {{{mch}}} | {{{5}}} }} peut être remplacé par {{{mch|{{{5}}}}}}, dans le cas précis dont il est question ici ». En effet, parmi les neuf combinaisons possibles pour les paramètres de mch et 5, les deux seules différences entre les deux propositions surviendraient si l'appel du modèle contenait une des syntaxes suivantes :
  • {{Fstats|mch=|5=valeur non vide}}, cas particulier dans lequel la première proposition donnerait « valeur non vide » et la seconde un vide/rien ;
  • {{Fstats|mch=}}, cas particulier dans lequel la première proposition donnerait « {{{5}}} » et la seconde un vide.
Or dans le modèle considéré, les deux paramètres sont des alias d'un unique paramètre à afficher (paramètre obligatoire, cela ne change pas grand chose) et surtout aucune insertion du modèle dans l'encyclopédie ne comporte de paramètre mch présent vide. Voilà pour la précison.
Quant à la méthodologie, a déjà été prodigué, il y un mois sur cette même page, le conseil suivant : « pour faire des essais Spécial:ExpansionDesModèles ou Modèle:Brouillon ou une autre page de brouillon. » Désolé pour le second lien qui n'est pas très utile, la page visée étant Modèle:Bac à sable. Plus généralement, Notification Nebuno, sur la forme essaye de regrouper tes modifications (et tes idées) sur les espaces de discussion également. Ce sera plus agréable pour tout le monde. Il n'y a pas le feu, patience.
Résumé des points C et D, quant à l'évolution des modèles {{Feuille de match}} et {{Joueur feuille de match}}. Il s'agit en fait d'un sous-tableau dans ce modèle. L'affichage et le code HTML semblent corrects mais en réalité, la technique adopté demande de fusionner (colspan) plus de colonnes que ce que ne contient effectivement le tableau. Est-ce une astuce, bien que correctement prise en compte, acceptable en HTML ?
Par défaut le tableau a normalement deux colonnes, parfois une seule quand on est dans un cas comme ceux-ci pour joueurs 1. Une troisième colonne, placée avant les deux autres a été rajoutée pour mettre un numéro, puis une quatrième pour un poste, juste après la précédente. La précision de la mise en forme spécifique de la colonne numéro était faite dans l'en-tête du tableau (en réalité, dans sa première case définie dans le modèle « Feuille de match »). Avec une colonne de plus il convient de changer la méthode. Particularité du fonctionnement actuel, chaque ligne (balises <tr> <td> ou pour être plus précis <tr> <td ) est créée dans le modèle qui la précède.
Si on exclut le fait de mettre numéro et poste dans la même case/colonne, je vois quatre possibilités pour prendre en compte le nombre de colonnes du tableau en fonction des choix du rédacteur et faire la mise en forme
  1. Utiliser dans le modèle principal des paramètres numéro(s) et poste et créer une ligne vide non affichée du tableau pour spécifier les largeurs. C'est ce qui a été mis en place sans satisfaction.
  2. Définir la largeur dans chaque case de chaque ligne du tableau dans le modèle Joueur… (éventuellement en définissant objet ou classe CSS si cela s'avérait avantageux). Avantages : on peut définir des alignements particuliers (à droite par exemple) et des "padding". Inconvénient (mais je me trompe peut-être) : augmentation de la taille après expansion du modèle.
  3. Créer un modèle « Gardien feuille de match » servant à définir les propriétés des colonnes, selon que son paramètre poste= soit renseigné ou pas. Avantage par rapport à la proposition n° 1. : pas d'ajout de ligne vide dans le tableau. Inconvénient : il y aurait besoin d'intervenir dans les articles.
  4. version 3 hybride. Tester dans le modèle Joueur si le poste vaut G, GB ou gardien. Petit inconvénient : coût du test dans tous les modèles.
Un avis de modéliste serait bienvenu. Merci. — Ideawipik (discuter) 10 décembre 2020 à 10:25 (CET)[répondre]
Bonjour Ideawipik, je n'ai pas reçu de notification de réponses, désolé pour le retard. Merci pour ces réponses détaillées. Oui, concernant ta première réponse et la relecture des colonnes, entre autre, je suis prêt à reprendre les articles repérés et attend tes instructions. Ta proposition me semble très bien. --Nebuno (discuter) 10 décembre 2020 à 15:48 (CET)[répondre]

Bonsoir Ideawipik,

en regardant l'article de la Finale de la Coupe UEFA 2000-2001#Feuille de match (RIP Gérard Houllier), j'ai dû ajouté deux {{nobr}}, sinon les noms des joueurs s'affichaient mal (voir cette capture d'écran).

Il me semble que c'est à cause de votre modification du 10 décembre sur le modèle {{Joueur feuille de match}}.

Chez moi, sur d'autres pages il y a ce genre de problèmes (exemples au pif) :

Si vous pouviez jeter un œil et voir d'où vient le problème.

Bonne soirée. Cordialement. — Jackrs (discuter) le 14 décembre 2020 à 19:39 (CET)[répondre]

Bonjour Jack Rabbit Slim's et merci pour le signalement.
La modification pointée consiste en un retour à un fonctionnement antérieur. L'introduction du modèle nobr entraînant sur plusieurs pages un dépassement de la taille maximum d’inclusion après expansion des modèles et de gros problèmes d'affichage. Pour info, du contenu qui est placé dans deux modèles imbriqués est comptabilisé deux fois dans ce décompte. Par exemple, s'il existe un modèle identité (dans le sens mathématique du terme {{Identité maths|{{Identité maths|texte}}}} donnerait une taille d'expansion deux fois plus importante que celle de {{Identité maths|texte}} pour un résultat HTML identique. On comprend donc que les nobr englobant chaque nom du tableau d'effectif augmentent drastiquement cette taille.
La solution adoptée, consistant à mettre, dans l'article, un nobr uniquement pour le nom de joueur le plus long dans le tableau est correcte et correspond à une possibilité que j'avais donnée en réponse à Nebuno, sur le même point lors d'une discussion précédente (5 novembre). La question d'alors portait également sur le fait de chercher à afficher trop de choses dans une largeur d'écran, problématique pour les écrans étroits, et est moins d'actualité depuis l'adaptation effectuée. Il serait possible de retirer le nobr dans l'article mais il n'est pas gênant.
Néanmoins, je reconnais que j'ai un peu trop anticipé le changement de comportement par défaut pour la largeur de la dernière colonne qui soulevait une autre question (affichage sur deux lignes si écran étroit). Cela se passe dans {{Feuille de match}} et la correction envisagée dans l'article aurait été d'ajouter un paramètre numéro=oui à ce modèle. On est pas encore certain du meilleur fonctionnement à adopter pour les colonnes optionnelles. L'affichage est rétabli.
Pour plus d’informations sur l'expansion des modèles en:Wikipedia:Post-expand include size et pages liées.
Pour répondre à une autre question de Nebuno, la donnée technique dont on parle est disponible d'au moins deux façons pour un article :
  • Sur un article en lecture, utiliser le navigateur afin d'afficher le code source de la page. Cela dépend du navigateur mais en général un clic droit sur la page propose cette fonctionnalité (ou au clavier un Ctrl+U). Chercher dans ce code « NewPP limit report » ou « Post‐expand include size » pour parvenir à la zone indiquant ces informations.
  • Lors d'une édition en mode modification du wikicode, cliquer sur Prévisualiser, aller en bas de la page, une ligne à dérouler intitulée « Données d’optimisation de l’analyseur » permet d'accès à plusieurs informations dont celle recherchée.
Cordialement — Ideawipik (discuter) 19 décembre 2020 à 14:55 (CET)[répondre]
Merci pour cette réponse, Ideawipik. Je me tiens prêt pour le moment où il faudra reprendre en main les articles concernés par les modifications de ces modèles. Bonne journée. --Nebuno (discuter) 19 décembre 2020 à 15:51 (CET)[répondre]