Wikipédia:Le Bistro/18 octobre 2021

Ajouter des liens
Une page de Wikipédia, l'encyclopédie libre.
Sous-pages
27 28 29 30
↑septembre / octobre↓
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
↑octobre / novembre↓
1 2 3 4 5 6 7
image manquante
Il y a 150 ans mourait un précurseur de ceci.
Bistro complet rafraîchi
Ajouter un message

Aujourd'hui, dans Wikipédia[modifier le code]

Le 18 octobre 2021 à 23:50 (CEST), Wikipédia comptait 2 367 663 entrées encyclopédiques, dont 1 988 articles ayant obtenu le label « Article de qualité » et 3 603 articles ayant obtenu celui de « Bon article ». Pour améliorer le contenu de Wikipédia, nous vous proposons de travailler les articles ci-dessous. N'hésitez pas à ajouter des liens internes, des images, des notions encyclopédiques ou simplement corriger les fautes d'orthographe. Demandez de l'aide en cas de doute ou visitez la page des premiers pas des contributeurs.

Articles remarquables et labels[modifier le code]

Bon articleArticle de qualité
Les labels sont un indicateur de qualité de certains articles de Wikipédia. Vous pouvez participer à ces démarches, en rédigeant des articles, en les relisant lors des procédures de labellisation BA ou AdQ, ou en contrôlant le niveau des anciens labellisés.
Bon article BA :
Article de qualité AdQ :
Contrôlez, relisez, améliorez et actualisez si besoin ces pages labellisées un 18 octobre :

Pommes à croquer[modifier le code]

Ces pages ont été ébauchées à l'instar du célèbre « Une pomme est un fruit » qui a marqué l'histoire de Wikipédia. Elles ont cependant évolué moins rapidement. Si leur sujet vous parait admissible, vous pouvez librement les développer. [Projet Pomme]

Articles à améliorer[modifier le code]

Voir aussi les articles ébauchés, à wikifier, à illustrer, à recycler, à vérifier, courts, non neutres, avec plusieurs fois la même image et en attente de relecture ainsi que les brouillons en attente de relecture et les articles avec un ou plusieurs liens à corriger.

Articles à créer[modifier le code]

Il existe aussi des pages regroupant les articles à créer en 2021, des articles demandés ou les plus attendus.

Suivi des débats d'admissibilité[modifier le code]

Anniversaires[modifier le code]

Joyeux anniversaire, Jahbomb (d · c), Remy34 (d · c) !

(Pour que l'on n'oublie pas le vôtre…)

Wikimag n°707 - Semaine 42[modifier le code]

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

OrlodrimBot (discuter) 18 octobre 2021 à 08:26 (CEST)[répondre]

Demande d'avis sur une modification du statut autoconfirmé[modifier le code]

Bonjour. Actuellement, le statut autoconfirmé (ou autoconfirmed pour les anglicistes), est un statut accordé 4 jours après la création d'un compte, et qui permet notamment :

  • le renommage d'une page ;
  • l'import de fichiers (par exemple des logos)
  • la possibilité d'intervenir sur des pages semi-protégées.

Or il arrive que des personnes créent des comptes dormants, sans aucune contribution permettant de vérifier qu'elle ont compris quelques règles de base, et attendent les 4 jours pour intervenir sur des pages en semi-protection. Un contributeur régulier s'en étonnait hier en RA.

L'idée serait donc de fixer un seuil minimal de contributions (à définir) avant d'accorder ce statut. Pour mémoire, ce seuil est de dix contributions sur la version en anglais de WP. Je suppose qu'une telle demande nécessite au moins un sondage, si ce n'est une prise de décision. Avant de lancer la machinerie lourde, je tâte la température pour avoir des avis argumentés permettant de préparer une éventuelle procédure officielle. Cordialement. --Pa2chant.bis (discuter) 18 octobre 2021 à 14:34 (CEST)[répondre]

Pour[modifier le code]

Contre[modifier le code]

  • Risque de rebuter les nouveaux contributeurs de bonne foi. Les vandales trouveront toujours comment faire dix modifications legit comme dit Jules en-dessous, les nouveaux contributeurs de bonne foi pas toujours. — Thibaut (discuter) 18 octobre 2021 à 15:37 (CEST)[répondre]
  • Contre le statut autoconfirmé c'est bien plus que les trois droits indiqués, voir la liste complète des 14 droits concernés sur Spécial:Liste des droits de groupe et augmenter la barrière à l’entrée pour un problème sur 1 droit sur 14 alors que la majorité (voir l'immense majorité) des nouveaux comptes ne posent pas de problème, cela me semble démesuré. Au pire, cela va créer un cercle vicieux et diminuer le nombre de nouvel arrivant et donc de personnes pour vérifier les potentiels vandalisme. Une anecdote personnelle : je me suis créé un nouveau compte pour ma résidence wikimédienne (VIGNERON en résidence (d · c · b)) et une des premières choses que j’ai voulu faire est d'ajouter une source, celle-ci contenait un lien internet or sans être autoconfirmé, il faut passer par un CAPTCHA. Du coup, je n’ai pas ajouté la source. Du coup, là on dit au va de facto interdire au nouveau d'ajouter facilement des sources pour commencer et parmi d'autres actions légitimes. Surtout que pour un compte dormant, faire 10 modifs cela ne changera quasiment rien, c'est vraiment les contributeurs de bonne foi qui seront le plus pénalisés. Au final, cela me semble vraiment contreproductif.
    Une meilleure solution serait de transférer le droit de modifier les pages semi-protégés à un autre groupe, par exemple le groupe autopatrolled (ou le groupe confirmé qui n’est pas utilisé sur la Wikisource francophone et qui lui pourrait avoir des règles plus strictes). Cdlt, Vigneron * discut. 18 octobre 2021 à 18:53 (CEST)[répondre]
    (D'accord avec l'essentiel de ton message.) Juste une remarque : transférer le droit de modifier les pages semi-protégés au groupe autopatrolled n'aurait aucun sens, il faudrait alors (mais j'y serais opposé Émoticône) transformer les SP en SPE. — Jules* Discuter 18 octobre 2021 à 19:14 (CEST)[répondre]
    @VIGNERON et @Jules* Bonsoir, dans un premier temps j'avais aussi pensé à basculer cela sur les autopatrolled avant de me raviser pour les mêmes raisons que Jules*. J'ai envisagé le groupe confirmed, mais de ce que j'ai compris, il n'est pas automatique et demanderait des actions d'attribution ? Mais si ce n'est pas le cas, c'est une possibilité intéressante pour avoir un seuil pour les semi-protégées sans toucher au reste des groupes. Tout de bon Triboulet sur une montagne (discuter) 18 octobre 2021 à 20:09 (CEST)[répondre]
    Le problème le plus gênant que je vois est l'impossibilité d'accéder aux pages de discussion structurées (flow) ce qui bloque l'accès au forum des nouveaux. Cela peut être un réel problème dans le cas de personnes qui auraient créé un article en quelques éditions, ou d'un vrai nouveau qui aurait une question à poser. Est-ce que techniquement, l'activation du statut confirmed est simple ? --Pa2chant.bis (discuter) 20 octobre 2021 à 20:01 (CEST).[répondre]
    D’après ce que j’ai compris, les non-autoconfirmed peuvent poster sur le forum des nouveaux mais pas modifier les messages des autres. — Thibaut (discuter) 20 octobre 2021 à 21:42 (CEST)[répondre]
    Effectivement, merci Thibaut. --Pa2chant.bis (discuter) 23 octobre 2021 à 12:56 (CEST)[répondre]
    @Pa2chant.bis, @Jules*, @Thibaut120094 et @Triboulet sur une montagne je n'y pense que maintenant mais est-ce que l’on ne pourrait pas simplement utiliser un filtre anti-abus ? C'est - en général - l'outil privilégié pour les besoins spécifiques tel que celui-ci. Cdlt, Vigneron * discut. 25 octobre 2021 à 21:15 (CEST)[répondre]
    @LD, puisque tu en parles aussi, te semble-t-il possible de mettre en place un filtre anti-abus sur le principe « moins de x contributions = modification d'une page en SP impossible/signalée » ? --Pa2chant.bis (discuter) 26 octobre 2021 à 05:12 (CEST)[répondre]
    J’ai pas compris, un filtre contre qui, contre quoi ? — Thibaut (discuter) 26 octobre 2021 à 05:16 (CEST)[répondre]
    @Pa2chant.bis, voici plusieurs remarques :
    Tout d'abord, pour mettre en place un filtre, il faut étudier la faisabilité technique, vérifier qu'il est utile (a priori et a posteriori) et consensuel, puis le tester avant de le mettre en place "définitivement". En principe, il doit être possible de faire quelque chose : nous pouvons mettre en place des filtres non bloquants pour établir un suivi, cela n'entrave pas nos prérogatives. Par exemple, d'après une demande récente, le filtre de test no 95 a été mis en place pour dresser un suivi sur une tranche d'utilisateur et une action particulière. En revanche, mettre en place "moins de x contributions = modification d'une page en SP impossible/signalée", c'est un autre débat. Bloquer des actions qui ne sont pas nécessairement des vandalismes (abus) ou des erreurs (règles définies par la communauté ou par Mediawiki) n'est pas possible sans une large consensus clair (prise de décision par ex.).
    S'il s'agit de journaliser des pages pour n'avoir qu'un suivi, sans bloquer et sans afficher un avertissement, cela me semble techniquement possible.
    Ensuite, vu la nature de la demande initiale, il s'agit de journaliser d'après des critères liés au compte et à ses actions.
    • Variables liées au compte :
      • Ancienneté : "user_age" = 345600 (en secondes, soit 4 jours) ou "user_groups" = "autoconfirmed"
      • Contributions : "user_editcount" = 0
    • Variables liées à l'action du compte :
      • Actions ("action") concernées :
        • "move" (déplacer une page)
        • "upload" (déplacer un fichier)
        • "edit" (édition quelle quelle soit)
          • il y a plusieurs variables commençant par "page_restrictions_" dédiées aux actions concernées (move, upload, edit), cf. extension ; mais je ne les ai jamais utilisées, je ne connais donc pas encore leurs fonctionnements. Elles pourraient peut-être être utiles pour restreindre la journalisation aux actions sur des pages protégées. Néanmoins, on peut contourner ce problème grâce à la présence automatisée de {{Semi-protection}} sur les pages protégées.
    En résumé : le filtre ci-haut journaliserait la première action des utilisateurs enregistrées depuis au moins 4 jours, sans activité antérieure à l'acquisition du statut ; première action qui est, elle-même définie, à savoir déplacer, éditer une page protégée ou télécharger un fichier.
    Nota : tous les comptes 'dormants' antérieurs à la création du filtre ne seront pas listés.
    En espérant avoir apporté quelques éléments, si tu souhaites soumettre la demande : Wikipédia:AbuseFilter/Requêtes Émoticône. BàT, LD (d) 26 octobre 2021 à 14:06 (CEST)[répondre]
    Il ne s'agissait pas de soumettre une demande, mais de savoir si techniquement un filtre pouvait répondre au besoin, pour le mentionner dans la prise de décision. La page extension n'est pas accessible, mais puisque la réponse possible ne correspond pas à ce besoin, laissons-tomber l'idée (sauf si d'autres modificateurs de filtres voient une autre piste). Merci en tous cas pour ces explications. Thibaut, on parle toujours du même sujet mentionné en titre. --Pa2chant.bis (discuter) 26 octobre 2021 à 21:28 (CEST).[répondre]
    Je dois être fatigué car je ne vois toujours pas le lien entre la proposition de modifier les conditions d’obtention du statut autoconfirmed et les filtres antiabus. — Thibaut (discuter) 26 octobre 2021 à 21:37 (CEST)[répondre]
    @Pa2chant.bis on pourrait au moins étudier la faisabilité voire y accéder (bien que ce soit plus simple de modifier les droits de ce groupe directement àmha), mais on ne peut pas le faire sans consensus communautaire.
    @Thibaut120094 le lien est simple : plutôt que de modifier les droits via une demande Phab, il serait techniquement possible d'interdire l'utilisation de certains droits de ce groupe d'utilisateurs via un filtre. Personnellement, je recommande plutôt simple suivi pour éviter les abus de FN. LD (d) 26 octobre 2021 à 22:19 (CEST=
    @ LD : les PDD sont déjà des usines à gaz, si en plus il faut ajouter des études de faisabilité technique, non merci. Autant envisager un recours direct sur le statut, si l'accord sur le principe se fait. --Pa2chant.bis (discuter) 26 octobre 2021 à 22:25 (CEST)[répondre]
    @LD : Ah merci ! Je vois que l’idée du filtre a été mise de côté, c’est en effet mieux de demander directement des modifications sur le statut (s’il y a consensus), ne serait-ce que pour ne pas gaspiller les « limites de conditions » des filtres. — Thibaut (discuter) 26 octobre 2021 à 22:45 (CEST)[répondre]
  • Contre Contre aussi. SarmentFurtif (discuter) 20 octobre 2021 à 08:34 (CEST)[répondre]
  • Contre fort, pour les raisons données par Thibaut et VIGNERON. Quelques vandales, que nous arrivons à gérer collectivement, ne doivent pas empêcher la contribution de nouvelles personnes venues de bonne foi. Trizek bla 22 octobre 2021 à 17:07 (CEST)[répondre]
  • -? Plutôt contre vu les arguments exposés, notamment de Jules* et Trizek (lui même reprenant Thibaut et VIGNERON) Émoticône. Un suivi des comptes dormants peut être réalisé par bot (voire par un filtre anti-abus) sans pour autant démotiver les nouveaux. — LD (d) 22 octobre 2021 à 20:51 (CEST)[répondre]

Autres[modifier le code]

  1. Pourquoi pas, mais je suis un peu dubitatif quant à l'utilité réelle de la mesure. Je m'explique.
    Le prérequis temporel (quatre jours) est essentiel, car il évite que des comptes soient créés sur le vif pour vandaliser via des opérations à accès restreint (surtout renommages, et modification de pages semi-protégées).
    À l'inverse, un minimum de dix modifications n'est pas vraiment une contrainte empêchant les vandalismes : il est extrêmement aisé de faire dix modifications legit juste après la création du compte et de le laisser dormant, ou bien encore de créer un compte dormant, de le réveiller lorsque l'on souhaite opérer les vandalismes voulus, et de faire dix modifications (pas besoin qu'elles soient legit, elles peuvent être des vandalismes) à la chaîne immédiatement avant.
    Sans être inutile, je crains qu'un critère de nombre de modifications (10 ou 20) n'aura qu'une utilité marginale faible. Le principal avantage serait que le compte, pendant ses n modifications préalables au statut autoconfirmed, apparaîtra comme « nouveau compte » dans LiveRC et les RC. L'inconvénient d'une telle mesure est de restreindre un peu plus la modification des articles semi-protégés et de complexifier l'accès au renommage des pages ; il est donc relativement faible. — Jules* Discuter 18 octobre 2021 à 15:00 (CEST)[répondre]
    Oui, tu as raison, cela ne pourra pas filtrer les personnes réellement mal intentionnées, et dans l'absolu, il faudrait que ce soit des contributions significatives, mais je ne pense pas que cela soit possible techniquement. Je suis consciente que l'effet est faible, on peut espérer au moins si les 10 premières contributions sont du vandalisme, qu'un admin compatissant interviendra avant l'obtention du statut. --Pa2chant.bis (discuter) 18 octobre 2021 à 15:12 (CEST)[répondre]
    @Pa2chant.bis : « on peut espérer au moins si les 10 premières contributions sont du vandalisme, qu'un admin compatissant interviendra avant l'obtention du statut » : certes, je me suis fait la même réflexion, mais dans ce cas, me suis-je répondu, en quoi est-ce un mieux d'avoir dix vandalismes sur des pages non semi-protégées qu'un (ou plusieurs) vandalismes sur un articles SP (ou via des renommages) Émoticône ?
    J'ajoute à mon commentaire initial qu'une valeur aussi élevée que celle proposée par @Jean-Christophe BENOIST, à savoir cinquante modifications, me ferait basculer en contre pour les raisons évoquées par Thibaut. L'équilibrage entre ouverture du projet et protection du contenu est une question très subjective, il n'y a pas de réponse correcte, mais mon point de vue est que nous devons être vigilants à ne pas refermer le projet sur lui-même, à ne pas limiter toujours plus — même à petits pas — les possibilités de contribution au motif du vandalisme (qui ne m'apparaît pas plus virulent ou nombreux aujourd'hui qu'il y a dix ans). — Jules* Discuter 18 octobre 2021 à 17:00 (CEST)[répondre]
    Il me semble que je n'ai pas fait mon premier renommage avant au moins 1 an, et les pages semi-protégées sont tout de même rares. Il y a tout de même largement de quoi se "faire la main" sans être bloqué ou gêné. Jean-Christophe BENOIST (discuter) 18 octobre 2021 à 17:58 (CEST)[répondre]
  2. Je suis Pour faire quelque chose mais je ne suis pas certain que ce soit la bonne approche. Parmi les 3 actions possibles des autoconfirmed, il n'y a que les contributions sur des pages semi-protégées qui me semblent problématiques (un nombre de contributions autour de 50, comme en PàS, ne me choquerait pas dans ce cas). En revanche, les imports (pas sûr) et les renommages peuvent être nécessaires pour des nouveaux qui créent une page (il faut renommer le brouillon il me semble). Leur mettre un seuil pourrait être problématique : ils ne connaissent déjà pas très bien les opérations s'il faut en plus intégrer des explications liées au nombre de contributions je ne trouve pas cela très pratique. Sinon, idem Jules* quant au fait que 10 ou 20 contributions correctes sont faciles à faire pour quelqu'un de malintentionné. Tout de bon Triboulet sur une montagne (discuter) 18 octobre 2021 à 16:29 (CEST)[répondre]
    Notification Triboulet sur une montagne : j'ai plusieurs fois constaté que les comptes de moins de 4 jours peuvent publier leur brouillon en article sans problème particulier : il y a une création par copier/coller et le brouillon est réinitialisé. Cela ne conserve pas strictement l'historique mais le droit d'auteur est respecté car le nouveau est généralement le seul à avoir contribué.
    C'est ensuite que les choses se compliquent parfois : si l'article est un bac à sable, la patrouille le supprime ; plus tard, le nouveau peut facilement restaurer son brouillon (cela fait découvrir la notion d'historique), puis le publier à nouveau et ça pourrait durer jusqu'au 4e jour. -- Habertix (discuter) 20 octobre 2021 à 01:48 (CEST).[répondre]
  3. Prendre le problème dans l'autre sens : être beaucoup plus exigeant sur l'usage des sources et leur proportion (quand on voit déjà ci-dessus que WP:PMS passe trop facilement, àmha, au second plan entre utilisateurs expérimentés). Cordialement, — Jolek [discuter] 18 octobre 2021 à 20:34 (CEST)[répondre]

Correction d'une image[modifier le code]

Sur Fichier:Les régions naturelles de France.jpg (de Notification Rayman78) je note une faute d'orthographe répétée dans l'adjectif "bourbonnais" (le R manque). L'auteur n'ayant plus contribué depuis novembre 2019 je me demande si quelqu'un d'autre serait en mesure de corriger la coquille. --Charlik (discuter) 18 octobre 2021 à 17:35 (CEST)[répondre]

@Charlik. J'ai réalisé une nouvelle version. Mais avant de la verser dans Commons, pourriez-vous me confirmer qu'il y a 3 noms à corriger : "BOCAGE BOUBONNAIS", "MONTAGNE BOUBONNAISE" et "LIMAGNE BOUBONNAISE" (noms avec les fautes). --Poudou! (discuter) 18 octobre 2021 à 19:27 (CEST)[répondre]
Désolé je vous ai devancé ... --Pline (discuter) 18 octobre 2021 à 19:42 (CEST)[répondre]
Pas grave. Le tout c'est de participer. --Poudou! (discuter) 18 octobre 2021 à 19:49 (CEST)[répondre]
Merci à tous ! --Charlik (discuter) 18 octobre 2021 à 19:53 (CEST)[répondre]

Section numérotées[modifier le code]

Bonjour à tous.

Certains d'entre vous doivent connaître un gadget, activable dans les préférences, qui permettait d'afficher les numéros des sections à côté du titre de ces dernières, ce qui permettait de plus facilement se repérer et d'avoir les sections numérotées, comme dans le sommaire. Ainsi, on voyait, par exemple « 4 Notes et références » dans le sommaire et le titre de section dans l'article était « 4 Notes et références », avec le numéro indiqué. Toutefois, ce gadget, que je trouve très pratique, semble avoir disparu récemment et il m'est impossible de le retrouver. Je précise que j'utilise (toujours) l'interface Monobook, même si je ne pense pas que ça change quelque chose.

Quelqu'un saurait-il comment activer cette fonctionnalité ? Éventuellement en personnalisant le Monobook.js.

AviaWiki ☎ 18 octobre 2021 à 22:20 (CEST)[répondre]

Notification AviaWiki :
Bonjour,
C'était une fonctionnalité intégrée directement à MediaWiki, mais elle a été supprimée.
Le bug renvoie vers un gadget de remplacement décrit dans mw:Snippets/Auto-number headings. Pour le charger, tu peux ajouter ceci à Spécial:Ma page/common.js :
mw.loader.load( 'https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-autonum.css&action=raw&ctype=text/css', 'text/css' );
mw.loader.load( 'https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-autonum.js&action=raw&ctype=text/javascript' );
Orlodrim (discuter) 18 octobre 2021 à 23:32 (CEST)[répondre]
Merci Notification Orlodrim. Je viens d'ajouter ces lignes à mon common.js et tout semble fonctionner correctement. AviaWiki ☎ 20 octobre 2021 à 23:47 (CEST)[répondre]

Palette[modifier le code]

Bonsoir, RositaTWD et moi ne sommes pas d'accord sur le contenu de la palette Modèle:Palette Personnel de la WWE et ce sur plusieurs points : je pense que comme il s'agit d'une palette de navigation les personnes qui n'ont pas d'article n'ont pas leur place sur cette palette. Le deuxième point est l'usage du gras qui selon moi ne devrait pas être présent. Enfin, la palette comprend largement plus de 100 articles (contrairement aux préconisations) ; une division entre Raw, Smackdown, NXT et NXT UK permettrait de résoudre le problème. J'aimerais donc des avis extérieurs pour résoudre ce désaccord. Qu'en pensez-vous ?

Je fais 3 parties pour plus de clarté. Merci. Amicalement,--Olivier Tanguy (discuter) 18 octobre 2021 à 22:47 (CEST)[répondre]

Présence de personnes sans articles[modifier le code]

Usage du gras[modifier le code]

Division de la palette[modifier le code]

  • Pas sûr que ce soit justifié, étant donné qu'il existe un article global sur le sujet qui rassemble le tout. A moins que cet article ne soit pas admissible (ce qui ne serait pas étonnant, puisqu'il s'agit plus d'une liste qu'autre chose...). SammyDay (discuter) 20 octobre 2021 à 16:10 (CEST)[répondre]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Wikipédia:Le_Bistro/18_octobre_2021&oldid=202697691 ».