Wikipedia:Misbruikfilter/Verzoekpagina filters

Uit Wikipedia, de vrije encyclopedie
Naar navigatie springen Naar zoeken springen


Nuvola apps kcmsystem.svg Verzoekpagina voor filters
Op deze pagina kunnen gebruikers voorstellen doen voor de aanmaak van nieuwe filters, het bewerken van bestaande filters of het verwijderen van bestaande filters. Ook kunnen fouten met betrekking tot bestaande filters op deze pagina worden aangegeven.
Overzicht beheerpagina's
Filters kunnen pas geëffectueerd worden wanneer deze eerst een week hebben proefgedraaid en er voldoende steun is vanuit de gemeenschap om het filter toe te passen. Dit telt ook voor reeds bestaande filters: wanneer deze significant worden aangepast, zullen deze aangepaste filters een week moeten proefdraaien. Proefdraaien houdt in dat er geen acties worden ondernomen, maar dat het filter alleen een logboek bijhoudt van wanneer het is geactiveerd.
Van alle bestaande filters wordt op Wikipedia:Misbruikfilter/Bestaande filters een overzicht bijgehouden.
Nieuwe verzoeken

Plaats nieuwe verzoeken onder het kopje "nieuwe verzoeken". Bij het doen van nieuwe verzoeken, vermeld je in elk geval het volgende:

  • Wat het filter moet doen (waarop het moet filteren, voor welke pagina's telt het filter, voor welke gebruikers telt het filter?);
  • Waarom dit filter geactiveerd zou moeten worden;
  • Moet het filter waarschuwen, moeten bewerkingen tegengehouden worden en/of moet de gebruiker de autoconfirmed status ontnomen worden?

Denk over deze zaken goed na, voordat je een verzoek indient

Afgehandelde verzoeken kunnen na een week worden gearchiveerd.
Archieven: 2009 - 2010 - 2011 - 2012 - 2013 - 2014 - 2015 - 2016 - 2017 - 2018 - 2019 - 2020 - 2021

Nieuwe verzoeken[bewerken | brontekst bewerken]

Verzoeken a.u.b. plaatsen in de volgende vorm:

===NAAM VOORSTEL===
{{/filter | id = | actief = }} <!-- niet invullen, tenzij het filter is aangemaakt //-->
* '''Taak:''' Waar moet een filter op letten, voor welke pagina's telt het filter, voor welke gebruikers telt het filter?
* '''Waarom:''' Waarom moet het filter geactiveerd worden?
* '''Gevolgen:''' Waarschuwen en/of Verhinderen en/of Autoconfirmed status afnemen?
* '''Waarschuwingstekst:''' Voorgestelde waarschuwingstekst, of link naar sjabloon.
Eventuele overige opmerkingen
~~~~
{{/einde}} <!-- Deze regel niet vergeten, anders loopt het kader door tot in het volgende verzoek! //-->



Aanpassingen filter 100 ahv foutieve meldingen[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Als ik zo vrij mag zijn hierbij aan te sluiten: is het gezien deze melding mogelijk om bewerkingssamenvattingen met "teruggedraaid" te negeren? En misschien meteen ook maar "revert", "rvv" en "rv"? Encycloon (overleg) 25 jun 2021 14:16 (CEST)


Waarom ging filter 66 niet af?[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Waarom ging het interwiki-filter bij deze en deze bewerkingen niet af? FifiNix (overleg) 24 mei 2021 10:37 (CEST)
    • Dit zijn geen interwiki's: vanwege de dubbelpunt achter de blokhaken worden ze als normale interne links behandeld. Het is wel te overwegen om ze mee te nemen, want ze worden in het algemeen als ongewenst beschouwd, behalve in voetnoten. Misschien het filter zo aanpassen: "Links naar anderstalige Wikipedia's zijn in de hoofdtekst ongewenst. Plaats deze in een voetnoot." Het filter zou dan moeten nakijken of het zich tussen ref-tags bevindt, zou dat mogelijk zijn? →bertux 24 mei 2021 11:07 (CEST)
      • Bedankt voor de duidelijke uitleg. Ja, als het filter op die manier kan worden uitgebreid, dat zou perfect zijn (imho). FifiNix (overleg) 24 mei 2021 11:58 (CEST)
      • Hoe moet het filter detecteren of iets 'hoofdtekst' is of niet? –bdijkstra (overleg) 24 mei 2021 15:31 (CEST)
        • Dat hoeft niet. Dat is enkel de mededeling voor de gebruiker, misschien wat lui geformuleerd; het filter hoeft alleen maar te kijken of er ref-tags om de linkjes staan; ja, dan mag de link, nee, dan niet →bertux 24 mei 2021 15:50 (CEST)


(hoofdbetekenis)[bewerken | brontekst bewerken]

Status:

Aanmaken filter · batchtesten
  • Taak: bewerkingen van dit type voorkomen. dus [[x (hoofdbetekenis)|x]] word [[x]].

de hoofdnaamruimte lijkt mij de meest logische naamruimte. en het filter kan volgens mij het beste voor iedereen tellen.

Rwzi (overleg) 21 jul 2021 10:49 (CEST)

Reacties[bewerken | brontekst bewerken]

Ik zie nogal wat leeuwen en beren:

  1. Wat met mensen die, bijvoorbeeld door kopiëren en plakken, per ongeluk zo'n link aanmaken? Ik zag pas de rode link Ieper (hoofdbetekenis) opduiken, hoe moet die hersteld worden? Kan het filter daartoe onderscheid maken tussen moderatoren en andere gebruikers? Kan het kijken of de hoofdbetekenis-pagina daadwerkelijk bestaat, blauw is?
  2. Wat moet er gebeuren als je een bewerking terugdraait waarin naast onzin een correcte link naar een hoofdbetekenis aangelegd wordt? Snapt het filter dat het zo'n terugdraaiing moet doorlaten?
  3. Kan het filter ermee omgaan als een tekst flink geredigeerd of totaal herschreven wordt, waarbij de hoofdbetekenis-link verdwijnt terwijl elders de gewone link opduikt?
  4. Als er ten onrechte een link naar bijvoorbeeld [[Amsterdam (hoofdbetekenis)]] is gelegd, kan het filter dan zo ingesteld worden dat je kunt herlinken naar [[Geschiedenis van Amsterdam]] of [[Amsterdam (Indische Oceaan)]]?
  5. Ik stel me voor dat zulke bewerkingen vaak te goeder trouw zijn. Als iemand een toevoeging van 300 woorden doet of een goede redactieslag maakt, is het dan de moeite waard om die tegen te houden voor één tekortkoming? Die vraag is des te meer relevant, omdat veel gebruikers nauwelijks zullen snappen waar het probleem zit, wat het inhoudt en hoe ze het op kunnen lossen. Het gevolg is dan dat de verbetering niet doorgaat en de goedwillende gebruiker gefrustreerd afhaakt. Daarom ook de volgende vraag:
  6. Hoe groot is het probleem, kun je dat kwantificeren?
  7. De toelichtingsteksten bij de filters zijn rampzalig en cryptisch, geschreven door iemand die geen idee heeft van hoe mensen zo'n melding lezen; op de helpdesk en bij de meldingspagina voor filterfouten zien we het topje van de ijsberg. Eigenlijk zou het hele filtersysteem stilgelegd moeten worden tot er iemand met met de stofkam doorheen is gegaan die de eisen van ergonomie redactie en opmaak aanvoelt. Tot dan moeten moeilijk te begrijpen problemen zoals deze niet via het filter afgehandeld worden.
  • Kan er eventueel ook een bot ingezet worden om de toevoeging 'hoofdbetekenis' terug te plaatsen, in plaats van een filter? Dat zou een hoop moeilijkheden schelen →bertux 21 jul 2021 12:20 (CEST)
1. het filter kan onderscheid maken op basis van gebruikersrechten van een gebruiker maar dan is het beter om het misbruikfilter te laten waarschuwen.
2. terugdraaiingen worden niet door het filter beoordeeld.
3. nee.
4. volgens dit voorstel wel.
5. nee, dan zou het beter zijn om het alleen te labelen.
6. enkele bewerkingen per dag.
7. dan is het beter om het filter alleen te laten labelen.
dat weet ik niet. Rwzi (overleg) 21 jul 2021 13:19 (CEST)


Verzoeken ter test in log-only[bewerken | brontekst bewerken]

Wanneer een nieuw verzoek in log-only is gezet, kan het verzoek naar hieronder worden verplaatst. Het filter zal vervolgens minstens één week in log-only draaien. In deze week kan de gemeenschap gegrond bezwaar uiten (zie ook de richtlijn).

OTRS-sjablonen[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen
  • Taak: Het filter wordt getriggerd als iemand anders dan een lid van Wikipedia:OTRS/Team het sjabloon {{PermissionOTRS-ID}}, {{OTRS-school}}, {{OTRS}} of het sjabloon {{OTRS-info}} gebruikt.
  • Waarom: Omdat dit door soort dingen alleen door een beperkte groep gebruikers in te zien is, en misbruik daarom misschien niet goed gesignaleerd wordt. De groep OTRS-agenten wordt steeds kleiner en misbruik ligt om de hoek. Het is een goede gewoonte van Commons om hierbij gebruik te maken van de misbruikfilters.
  • Gevolgen: Waarschuwen en/of Verhinderen lijkt me terecht.
  • Waarschuwingstekst: bv "Dit sjabloon kan uitsluitend door het OTRS-team gebruikt worden om aan te geven dat er een mailuitwisseling is geweest over de tekst of dit bestand. Plaatsing door andere gebruikers is niet gewenst. Neem bij twijfel contact op met iemand van het OTRS-team."

Eventuele overige opmerkingen Ciell 8 okt 2020 22:57 (CEST)

@Sumurai8, Bdijkstra: Als jullie tijd hebben, zouden jullie dan eens naar mijn verzoek hier willen kijken? Ciell 16 okt 2020 14:24 (CEST)
Ik ben geen misbruikfilterredacteur (en vooralsnog niet van plan het te worden). –bdijkstra (overleg) 16 okt 2020 19:04 (CEST)
@Ciell: Aangemaakt in testfase (log-only). Lymantria overleg 21 jan 2021 19:44 (CET)
Hey @Lymantria:, de eerste die mij opvalt is een ip die een doorverwijzing gebruikt en die dus niet gevangen wordt in het filter. (Gelukkig was Encycloon oplettend) Ciell need me? ping me! 18 feb 2021 17:40 (CET)
Hi @Ciell: Er zaten twee foutjes in. Als eerste werd geen rekening gehouden met de redirect links naar {{PermissionOTRS-ID}}, ten tweede stonden er ten onrechte meteen afsluitende } na de sjabloon-naam. Hersteld. Eens kijken of het filter nu wat vangt. Groet, Lymantria overleg 18 feb 2021 18:34 (CET)
Dit filter moet denk ik kijken of het sjabloon al niet in de voorgaande versie stond (vals-positieven mbt Hoyanova). We kunnen ook overwegen om een check in te bouwen of het sjabloon door een niet OTRS-persoon wordt verwijderd. Sum?urai8? 6 apr 2021 13:13 (CEST)
Ik heb een toevoeging gedaan om VTRS te detecteren ipv OTRS. Sum?urai8? 18 jun 2021 18:34 (CEST)


Sjabloon:Statistiek woonplaats Nederland inwoners[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen
  • Taak: Verhindert dat een in de artikelruimte ingevoegd Sjabloon:Statistiek woonplaats Nederland inwoners vervangen wordt door een handmatig ingevoerd inwonertal.
  • Waarom: Het sjabloon plaatst de inwonertallen per 1 januari, die in de loop van elk jaar door het CBS aangeleverd worden. Nieuwe bewerkers weten of begrijpen dit niet en/of kunnen er niet op wachten. Ze voeren dan handmatig inwonertallen van gemeenten en woonplaatsen in, waardoor de jaarlijkse update verstoord wordt.
  • Gevolgen: Verhinderen.
  • Waarschuwingstekst: Het actuele inwonertal op deze pagina wordt in de loop van het jaar automatisch vernieuwd. U kunt dit aantal niet handmatig aanpassen. Problemen met de aantallen kunt u melden op de Helpdesk.
  • Opmerkingen:
    • Het woord actuele geeft een hint dat (onder andere) historische inwonertallen wel aangepast kunnen worden.
    • Bij gebleken succes kan dit filter aangepast worden om ook verwijdering van andere inwoner-sjablonen te verhinderen en zelfs om de verstoring van andere automatische updates te voorkomen, zoals die van oppervlakten.

 →bertux 18 mrt 2021 17:32 (CET)

Encycloon en Sumurai8, jullie zijn hier nogal eens actief. Was dit nieuwe verzoek over het hoofd gezien? →bertux 20 mrt 2021 18:11 (CET)
Om voor mijzelf te spreken: ik ben hier niet actief als filterbewerker, alleen als verzoeker. Encycloon (overleg) 20 mrt 2021 18:16 (CET)
Ik zal eens kijken wat ik hiervoor kan maken. Sum?urai8? 22 mrt 2021 22:01 (CET)
Aangemaakt in log-only. Sum?urai8? 22 mrt 2021 22:30 (CET)
@Bertux: We hebben zo te zien de eerste hit al. En dit is een goedwillende gebruiker die onjuiste data omgezet heeft in juiste data, dus ik wil de wijziging niet terugdraaien. De oude versie was slechts gedeeltelijk automatisch gevuld, en er lijkt geen sjabloon te zijn om wijken en buurten automatisch te vullen. Sjabloon:Array Nederland woonplaatsen kerngebieden 2020 zet onbekende nummers om in buurtcodes die vervolgens bij elkaar opgeteld worden. Dit is sowieso fout hier, want het gaat hier om wat het CBS wijken noemt, niet om gemeenten. Grappig genoeg bevat Module:Array_Nederland_kerngebieden_inwonertallen_2020 de bijbehorende data wel, maar ik heb volgens mij geen sjabloon om dit op een nette manier daaruit te trekken.
Met zulke fouten in de encyclopedie (Voerendaal, aangeduid met whatever 1855 moet voorstellen, bevat bijvoorbeeld de inwoneraantallen van "wijk voerendaal (3180), wijk kunrade (3415), wijk ubachsberg (1550) en wijk verspreide huizen voerendaal (350)" voor een totaal van 8495) lijkt het mij niet wenselijk om zulke wijzigingen blindelings te blokkeren. Markeren zodat ze stuk voor stuk gefixt kunnen worden lijkt mij in dit geval een beter idee. Sum?urai8? 24 mrt 2021 20:09 (CET)
Na nog meer zoeken kwam ik ook {{Tabelrij CBS-buurt}} tegen, waar inwoners handmatig worden ingevoerd (en nooit meer worden geupdate), hoewel de exacte buurtcode ook gewoon in bovengenoemde data gevonden kan worden. {{Infobox plaats in Nederland}} vraagt om een CBS-code en een wooncode, maar heeft ook handmatig de inwoners en de datum inwoners als parameters. Deze worden genegeerd als cbs-code of woonplaatscode is ingevuld, maar de cbs-code wordt gevoerd aan {{Statistiek kerngebieden Nederland inwoners}} met data uit 2017 en de woonplaatscode komt lang niet altijd overeen met wat er beschreven wordt. Die kadasterbeschrijvingen moeten vervolgens alsnog handmatig gekoppeld worden aan CBS-codes, dus we schieten er achteraf helemaal niets mee op. We hebben {{Array Nederland gemeentes inwonertallen}} die wel CBS-codes pakt en recentelijk is geupdate, maar dan niet de data uit bovenstaande module haalt en alleen geschikt is voor gemeentes en niet voor buurten of wijken. Verward Volgens mij is het momenteel een grote rommel... Sum?urai8? 24 mrt 2021 21:50 (CET)
Ik raak altijd volledig de weg kwijt in onze omgang met inwonertallen, anders had ik wel meer huiswerk gedaan. Ik weet nu in elk geval dat het niet alleen aan mij ligt en hoop dat ik jou niet te veel werk bezorgd heb. Is het zinnig om het filter een paar maanden op de achtergrond aan te laten staan om te zien hoe de gebruikers omgaan met die rommel? (Idealiter langer, want het voorjaar is het update-seizoen.) Sowieso goed om het zootje komend najaar aan te kaarten (staat in mijn agenda) en héél misschien het verboden woord Wikidata laten vallen. Enne, ik mag toch hopen dat de vele standaardartikelen van het type Wijken en buurten in Arnhem wel enigszins systematisch en grotendeels automatisch gevuld en geüpdate worden? Uit de bewerkingsgeschiedenis kan ik dat niet opmaken, behalve dat ze voortkomen uit deze antieke botaanmaak. Ai, niet dus. We zitten tegen gegevens van 2008 aan te kijken, wat de lezer pas te weten komt als hij helemaal doorscrolt naar beneden. My god… →bertux 24 mrt 2021 22:26 (CET)


Nieuw gokspam stop filter[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen
  • Taak: Stoppen van Indonesische gokspambots
  • Gevolgen: verhinderen aanmaak pagina's
  • Waarschuwingstekst: Spam.

Eventuele overige opmerkingen zie hier onderaan voor de lijst met woorden en verdere uitleg. Hoyanova (overleg) 17 jul 2021 08:40 (CEST)


Verzoeken in testfase[bewerken | brontekst bewerken]

Minimale kwaliteit[bewerken | brontekst bewerken]

@Romaine: Deze verzoeken zijn aangemaakt als filter 104 in log-only. De eerste 17 hits kunnen genegeerd worden, maar hopelijk pikt het deze week een aantal nieuw aangemaakte artikelen op die aan deze voorwaarden voldoen. Als er artikelen niet worden opgepikt waarvan je wel zou verwachten dat ze zouden matchen zet de links hieronder. Dan kijk ik hier later naar. De logs staan onder het filterlogboek en worden gerapporteerd als filter 104 op het vandalismekanaal. Sum?urai8? 21 feb 2021 23:22 (CET)

Klopt het dat het filter momenteel ook aanslaat op pagina's in de gebruikersnaamruimte? Dat lijkt me niet nodig, het aanmaken van een lege gebruikerspagina of een zin in een kladblok is niet verboden. Encycloon (overleg) 22 feb 2021 09:13 (CET)
De aanmaakversie van het artikel K*** W****** liet het filter afgaan en is in mijn ogen een vals positief resultaat. Allereerst is het weliswaar onverzorgd, maar inhoudelijk geen bagger, aangenomen dat het gestelde klopt. Ook bevat het interpunctie, zegge en schrijve één punt.
Het deelfilter 'geen lopende zinnen' is scherper af te stellen door ook hoofdlettergebruik mee te nemen: geen enkelvoudige hoofdletters én geen interpunctie: bagger. (Meervoudige hoofdletters = meerdere achter elkaar. Die vormen uiteraard geen aanwijzing voor goede kwaliteit)  →bertux 22 feb 2021 14:48 (CET)
Aanvullingen:
  • Doorverwijspagina's en redirects (zie SO4-2) zouden niet meegenomen moeten worden. De kans dat die vandalistisch aangemaakt worden lijkt me klein, de kans op vals positieven juist groot.
  • Bewerkingen op bestaande pagina's geven ook te veel kans op vals positieven, bijvoorbeeld bij het aanvullen van sportresultaten en andere opsommingen, zie special:diff/58354874. Ook gaat het filter af als iemand de doelpuntenproductie van een voetballer actualiseert, van 32 naar 34 of zo.
  • Ik zie dat Lorive het filter heeft laten afgaan bij "autocreateaccount" op Speciaal:Aanmelden. Is dit gewoon het aanmaken van een gebruikersnaam? Het filter zou tot de artikelruimte beperkt moeten blijven, hooguit met een paar uitzonderingen die ik niet kan bedenken
 →bertux 22 feb 2021 15:05 (CET)
Ik heb het idee dat die laatste twee voorbeelden al door Sumurai8 verholpen zijn. Encycloon (overleg) 22 feb 2021 15:20 (CET)
Dank je voor de feedback.
  • Ik heb het filter nu afgesteld dat het alleen afgaat op de hoofdnaamruimte. Ik heb ook de Nederlandse naam "doorverwijzing" uitgesloten van een gedeelte van het filter. "redirect" was al uitgesloten.
  • Punt 2 is al opgelost. Het filter werkt alleen als de pagina nog niet bestond.
  • Punt 3 is al opgelost. Het filter werkt alleen als er een bewerking wordt gedaan.
Het artikel over K*** W***** voldeed aan de regel "Bij het aanmaken van pagina's door IP-gebruikers en niet-autobevestigde gebruikers het tegenhouden indien een tekst slechts één punt of geen enkele bevat", dus in dit geval deed het wat het design zei dat het moest doen. Het artikel is nu verwijderd omdat het privacy schendende informatie bevatte die niet te onderbouwen was met bronnen en de persoon geen enkele bekendheid lijkt te genieten. Afgezien van dat begrijp ik je punt. Het artikel was voor ons leesbaar en het filter kan geen uitspraak doen over WP:BLP en zou daar dus niet op moeten oordelen. Ik ben er echter nog niet over uit hoe ik het filter zou aanpassen om zo'n bewerking toe te laten, zelfs nu het artikel toch verwijderd moest worden. Sum?urai8? 22 feb 2021 22:46 (CET)
Opmerking Opmerking Filtermeldingen tot nu gecontroleerd. [1] Sum?urai8? 22 feb 2021 23:02 (CET)
Opmerking Opmerking Niks bijzonders tot nu [2]. Sum?urai8? 24 feb 2021 00:07 (CET)
Opmerking Opmerking deze wijziging (onderzoeken) triggerde op het aantal punten. Ik ben er nog niet uit waarom... Sum?urai8? 24 feb 2021 23:26 (CET)
Is er iets in het filter dat zoekt naar punten aan het eind van een regel? Het artikel telt drie punten en twee ervan staan niet aan het eind, doordat een volgspatie achter staat, zoals je in de onderzoekslink kunt zien in de rubriek Regels toegevoegd in bewerking (added_lines)  →bertux 25 feb 2021 00:51 (CET)
Het probleem lijkt te zijn dat all_links een link bevat van {{Link IMDb naam}}, waar ik de punten van tel, maar die niet binnen de tekst zelf staan. De tekst heeft 3 punten, de url 2, dus het netto aantal is 1. Maar eigenlijk is het 3. Ik heb een beetje aan het dubben of ik een check voor maximale tekstgrootte toevoeg, de check eruit haal voor urls (maar linkspam gaat dan meestal door het filter heen) of iets ingewikkelders doe waar ik manueel alle links in new_wikitext detecteer. Sum?urai8? 26 feb 2021 12:27 (CET)
Voor linkspam moeten er betere manieren zijn, dus het lijkt niet bijzonder logisch om die mee te tellen. Ik droom van een zelflerend neuraal netwerk dat aan de hand van termen als insta, http(s), Pinterest, Facebook, en inderdaad hoofdlettergebruik en interpunctie, een profiel van ongewenste artikelen opstelt. @Ciell heeft het wel eens over zoiets in De kroeg, het begint met een O… en meet de kwaliteit van bijdragen en/of artikelen. Maar of dat goed zou kunnen samenwerken met het filtersysteem?  →bertux 26 feb 2021 13:04 (CET)
Zie WP:ORES. Encycloon (overleg) 26 feb 2021 13:09 (CET)
Ik check niet meer op het aantal punten in urls. Dit betekent dat artikelen met alleen een url doorgelaten worden, maar dit zou niet echt een probleem moeten zijn. Sum?urai8? 1 mrt 2021 12:33 (CET)
Opmerking Opmerking Het filter is ingeschakeld met verhindering ingeschakeld en de voorgestelde tekst. Het gebruikt MediaWiki:Abusefilter-disallowed-kwaliteit. Sum?urai8? 1 mrt 2021 12:33 (CET)
@Sumurai8: er wordt meermaals aangegeven dat men de $1 niet begrijpt (die verschijnt zo te zien na Het automatische controlesysteem heeft uw bewerking tegengehouden om de volgende reden:). Is dat aan te passen? Encycloon (overleg) 20 mrt 2021 12:23 (CET)
Dit lijkt een bug te zijn met AbuseFilter, omdat we deze berichten bewerkbaar maken voor autoconfirmde gebruikers en de software niet om kan gaan met templates in die berichten blijkbaar. Ik heb deze bug aangemaakt. Als eruit komt dat dat niet aangepast kan worden zal ik die regel eruit halen. Sum?urai8? 20 mrt 2021 16:52 (CET)
Ze willen dat ik dat met parameters doorgeef aan onderliggende sjablonen. Dat heb ik gedaan en dat lijkt te werken. Sum?urai8? 20 mrt 2021 17:57 (CET)
Hier sloeg het filter niet aan doordat er een weblink in de inhoud voorkwam (xxx.jouwweb.be). Is daar iets tegen te doen? Encycloon (overleg) 21 mrt 2021 19:35 (CET)
Vanwege deze eerder genoemde wijziging (links die worden ingevoegd die niet in de wikitekst staan) denk ik niet. Er stond iets in het filter dat punten telde in `all_links`, maar dit heb ik eruit gehaald omdat het vals-positieven gaf. Ik heb liever dat er een aantal baggeredits niet worden geblokkeerd dan dat ik per abuis 1 blokkeer die een beginneling zou kunnen maken die wel een poging doet iets nuttigs te plaatsen. Ik kan iets proberen te doen met de nieuwe gerenderde html, maar dat vangt hoogstens een paar extra edits op, terwijl het lang niet alle tekst met links oppikt waar 0 of 1 punten in zit, maar wel een performance-impact heeft op iedere bewerking. Ik denk niet dat dat het waard is. Sum?urai8? 22 mrt 2021 21:45 (CET)
Oké. Ik kwam verder hier een willekeurige tekenreeks tegen waar ook twee punten in stonden. Encycloon (overleg) 29 mrt 2021 11:58 (CEST)
De oorspronkelijke versie (details) werd tegengehouden. De verwijderde versie voldoet aan geen van de regels van het filter. Ik vraag me af of ik misschien een check in moet bouwen of er ook minstens 2 spaties in een artikel zitten. Zijn er valide artikelen waar 0 of 1 spatie in zit? Sum?urai8? 31 mrt 2021 19:26 (CEST)
Niet dat ik weet. Encycloon (overleg) 31 mrt 2021 20:16 (CEST)
Enige dat ik me kan voorstellen zonder spaties is een redirect, maar ik neem aan dat die al uitgesloten worden. Etersheim - Etersheimer Braakmolen met zeilen.jpg Akoopal overleg. 3 apr 2021 15:43 (CEST)
Ik dacht zelf nog aan een bare-bones dp, maar zelfs daar zitten spaties over het algemeen in de links die je toevoegt. Ik heb het toegevoegd en ben benieuwd of er vals-positieven hierop terugkomen. Sum?urai8? 4 apr 2021 11:43 (CEST)
@Sumurai8: Waarom werd dit niet tegenhouden? Encycloon (overleg) 14 apr 2021 12:07 (CEST)
Het account bestaat sinds januari. Ik denk dat het account al autoconfirmed was, en daar slaat het filter niet op aan. Het filtersysteem laat me niet toe om wijzigingen te onderzoeken die al eens verwijderd zijn (zelfs niet na terugplaatsen), dus ik kan de details bij die wijziging niet meer ophalen helaas. Sum?urai8? 14 apr 2021 12:56 (CEST)
Daar zal het dan inderdaad aan liggen. Encycloon (overleg) 14 apr 2021 13:12 (CEST)

Aanmaak met hoofdletters[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen

Op Overleg Wikipedia:Vandalismebestrijding werd er door enkele gebruikers melding gemaakt van een grote hoeveelheid bagger-artikelen die iedere dag aangemaakt worden en per nuweg verwijderd dienen te worden. Om die grote toestroom een halt toe te roepen werd er voorgesteld om het aanmaken van nieuwe pagina's door IP-gebruikers en niet-autobevestigde gebruikers geheel af te sluiten. Na analyse van een redelijk grote groep nuweg-gevallen is gebleken dat er vier hoofdkenmerken zijn waaraan de meeste nuweg-gevallen voldoen en die door middel van het instellen van een filter tegengehouden kunnen worden. Om deze vier kenmerken met filters tegen te houden is er draagvlak, zie de overlegpagina. Dit is het eerste kenmerk van de vier:

  • Taak: Bij het aanmaken van pagina's door IP-gebruikers en niet-autobevestigde gebruikers het gebruik van alleen maar hoofdletters tegenhouden. Om situaties met 99 hoofdletters en 1 kleine letter (of 2, 3, etc) ook te filteren, graag de aanmaak tegenhouden indien meer dan de helft (50%) van de letters een hoofdletter is. (Ter voorkoming van mogelijk onjuiste filteracties bestandsnamen en redirects negeren.)
  • Waarom: Geen enkel artikel dat volledig in hoofdletters is geschreven, is geschikt voor Wikipedia.
  • Gevolgen: Verhinderen dat een pagina aangemaakt kan worden.
  • Waarschuwingstekst: De tekst is met opzet niet specifiek aangevend wat er mis is, omdat dit anders het omzeilen van het filter stimuleert. De tekst voor dit filter is dezelfde als de andere vier en luidt:

Uw artikel voldoet helaas niet aan de minimale conventies van Wikipedia. Kijk om een goed artikel te schrijven op Help:Tips voor het schrijven van een goed artikel.

Romaine (overleg) 14 feb 2021 10:21 (CET)

Eventueel de titel uitsluiten als die ook in kapitalen staat. Ik kan me voorstellen dat iemand een boektitel overneemt die geheel in kapitaal gezet is. Oude boeken met hun eindeloze ondertitels kunnen dan een vals positief geven. Het volgende tekstje is niet fantastisch, maar wel een legitiem beginnetje: REIZE NAAR SURINAMEN EN DOOR DE BINNENSTE GEDEELTEN VAN GUIANA is een vertaling van het boek NARRATIVE, OF A FIVE YEARS' EXPEDITION, AGAINST THE REVOLTED NEGROES OF SURINAM. Het is een reisverslag van John Gabriël Stedman. En er zijn véél langere titels  →bertux 14 feb 2021 17:50 (CET)


Aanmaak zonder zinnen[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen

Op Overleg Wikipedia:Vandalismebestrijding werd er door enkele gebruikers melding gemaakt van een grote hoeveelheid bagger-artikelen die iedere dag aangemaakt worden en per nuweg verwijderd dienen te worden. Om die grote toestroom een halt toe te roepen werd er voorgesteld om het aanmaken van nieuwe pagina's door IP-gebruikers en niet-autobevestigde gebruikers geheel af te sluiten. Na analyse van een redelijk grote groep nuweg-gevallen is gebleken dat er vier hoofdkenmerken zijn waaraan de meeste nuweg-gevallen voldoen en die door middel van het instellen van een filter tegengehouden kunnen worden. Om deze vier kenmerken met filters tegen te houden is er draagvlak, zie de overlegpagina. Dit is het tweede kenmerk van de vier:

  • Taak: Bij het aanmaken van pagina's door IP-gebruikers en niet-autobevestigde gebruikers het tegenhouden indien een tekst slechts één punt of geen enkele bevat (bestandsnamen en urls niet meegeteld). (Ter voorkoming van mogelijk onjuiste filteracties het aanmaken van redirects negeren.)
  • Waarom: Geen enkel artikel dat geen zinnen bevat, is geschikt voor Wikipedia.
  • Gevolgen: Verhinderen dat een pagina aangemaakt kan worden.
  • Waarschuwingstekst: De tekst is met opzet niet specifiek aangevend wat er mis is, omdat dit anders het omzeilen van het filter stimuleert. De tekst voor dit filter is dezelfde als de andere vier en luidt:

Uw artikel voldoet helaas niet aan de minimale conventies van Wikipedia. Kijk om een goed artikel te schrijven op Help:Tips voor het schrijven van een goed artikel.

Romaine (overleg) 14 feb 2021 10:21 (CET)


Aanmaak met drie uitroeptekens[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen

Op Overleg Wikipedia:Vandalismebestrijding werd er door enkele gebruikers melding gemaakt van een grote hoeveelheid bagger-artikelen die iedere dag aangemaakt worden en per nuweg verwijderd dienen te worden. Om die grote toestroom een halt toe te roepen werd er voorgesteld om het aanmaken van nieuwe pagina's door IP-gebruikers en niet-autobevestigde gebruikers geheel af te sluiten. Na analyse van een redelijk grote groep nuweg-gevallen is gebleken dat er vier hoofdkenmerken zijn waaraan de meeste nuweg-gevallen voldoen en die door middel van het instellen van een filter tegengehouden kunnen worden. Om deze vier kenmerken met filters tegen te houden is er draagvlak, zie de overlegpagina. Dit is het derde kenmerk van de vier:

  • Taak: Bij het aanmaken van pagina's door IP-gebruikers en niet-autobevestigde gebruikers het tegen houden als een pagina wordt aangemaakt waarbij er in de tekst drie uitroeptekens achter elkaar staan. Hierop dient wel een uitzondering gemaakt te worden als er gelinkt wordt naar het artikel over de band met de naam !!! of als er in de tekst woorden zoals "band" of "muziek" te vinden zijn.
  • Waarom: Het gebruik van drie uitroeptekens achter elkaar is een typisch kenmerk van taalgebruik dat niet past in Wikipedia en regelmatig terugkomt in teksten zoals "Bezoek nu onze site!!!" of "Ik vind Pieter een leuke jongen!!!"
  • Gevolgen: Verhinderen dat een pagina aangemaakt kan worden.
  • Waarschuwingstekst: De tekst is met opzet niet specifiek aangevend wat er mis is, omdat dit anders het omzeilen van het filter stimuleert. De tekst voor dit filter is dezelfde als de andere vier en luidt:

Uw artikel voldoet helaas niet aan de minimale conventies van Wikipedia. Kijk om een goed artikel te schrijven op Help:Tips voor het schrijven van een goed artikel.

Romaine (overleg) 14 feb 2021 10:21 (CET)

Je schrijft hierboven 'drie hoofdletters', bedoeld zal zijn 'drie uitroeptekens'. Verder: ik weet niet of drie vraagtekens en mengsels (?!!) van ook problematisch zijn; zo ja, dan mogen die ook mee →bertux 14 feb 2021 17:25 (CET)
Ja, foutje, aangepast. De combinatie met vraagteken(s) ben ik niet tegen gekomen in de steekproef, al kan ik me voorstellen dat ?!? of !?! ook populair kan zijn eens in de zoveel tijd. Van mij mogen die er gerust al in op zich, omdat ook dergelijke combinaties precies binnen het profiel van dit kenmerk passen. Romaine (overleg) 14 feb 2021 17:36 (CET)


Aanmaak met alleen een kopje[bewerken | brontekst bewerken]

Status: Op proef

bewerken · geschiedenis · logboeken · testen

Op Overleg Wikipedia:Vandalismebestrijding werd er door enkele gebruikers melding gemaakt van een grote hoeveelheid bagger-artikelen die iedere dag aangemaakt worden en per nuweg verwijderd dienen te worden. Om die grote toestroom een halt toe te roepen werd er voorgesteld om het aanmaken van nieuwe pagina's door IP-gebruikers en niet-autobevestigde gebruikers geheel af te sluiten. Na analyse van een redelijk grote groep nuweg-gevallen is gebleken dat er vier hoofdkenmerken zijn waaraan de meeste nuweg-gevallen voldoen en die door middel van het instellen van een filter tegengehouden kunnen worden. Om deze vier kenmerken met filters tegen te houden is er draagvlak, zie de overlegpagina. Dit is het vierde kenmerk van de vier:

  • Taak: Bij het aanmaken van pagina's door IP-gebruikers en niet-autobevestigde gebruikers het tegen houden als er uitsluitend een kopje ingevoegd wordt. (Ter voorkoming van mogelijk onjuiste filteracties het aanmaken van alleen een kopje en invoeging van bestandsnamen niet meetellen.)
  • Waarom: Geen enkele pagina dat uitsluitend een kopje bevat is geschikt voor Wikipedia.
  • Gevolgen: Verhinderen dat een pagina aangemaakt kan worden.
  • Waarschuwingstekst: De tekst is met opzet niet specifiek aangevend wat er mis is, omdat dit anders het omzeilen van het filter stimuleert. De tekst voor dit filter is dezelfde als de andere vier en luidt:

Uw artikel voldoet helaas niet aan de minimale conventies van Wikipedia. Kijk om een goed artikel te schrijven op Help:Tips voor het schrijven van een goed artikel.

Romaine (overleg) 14 feb 2021 10:21 (CET)


Afgehandelde verzoeken[bewerken | brontekst bewerken]

Updateverzoek Instaspam-filter[bewerken | brontekst bewerken]

Status:

bewerken · geschiedenis · logboeken · testen
  • Taak: Als ik deze logboekregel doorneem, zie ik een zinnetje langskomen (ook tijdens het lezen van een artikel met privacyschending) over hoe een account op Insta heet. Is het niet mogelijk om de filter daarop af te stellen? Verdere uitleg staat hieronder.
  • Waarom: Omdat het eigenlijk een soort oproep is om een account op Instagram te volgen.
  • Gevolgen: Graag hetzelfde houden.
  • Waarschuwingstekst: Dezelfde waarschuwingstekst.

Dit komt omdat dit soort spam in de toekomst vaker kan voorkomen en de filter daarop niet is ingesteld. Ook al kom ik deze manier van Instaspam niet tegen tegengekomen (behalve de dag dat ik dit verzoek indiende (22 augustus)), en ik denk dat hetzelfde geldt voor andere vandalismestrijders. Dus mijn vrees is - als we de filter niet op de juiste manier instellen - dat zowel de huidige als de toekomstige vandalismebestrijders dit echt tegen komen. Nieuwsgierige Gebruiker (overleg) 22 aug 2019 17:27 (CEST)

Dit filter blokkeert bewerkingen, dus we moeten 100% zeker zijn dat alle wijzigingen die dit filter matchen altijd geblokkeerd moeten worden. Een zin waarin mensen worden opgeroepen een instagramaccount te volgen is altijd verkeerd op Wikipedia. De zin zoals die in het gelinkte logboekbericht staat kan voorkomen in een legitiem artikel, zelfs als deze specifieke wijziging niet thuishoort op Wikipedia. Ik kan deze zinsconstructie dus niet toevoegen aan het filter. Sum?urai8? 29 aug 2019 23:12 (CEST)
Niet uitgevoerd Niet uitgevoerd Sum?urai8? 29 aug 2019 23:14 (CEST)


Tegenhouden van rare niet-bestaande sjablonen[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Taak: Dat er niet van die rare Russische sjablonen geplaatst worden.
  • Waarom: Naar aanleiding van deze en de verwante bewerkingen/ongedaan makingen.
  • Gevolgen: Waarschuwen, verhinderen en automatisch promoveren blokkeren lijken me handig.
  • Waarschuwingstekst: Is de waarschuwingstekst "Best editor, you are trying to place templates that are not created, you can't trying to place this templates, if you are 2 times trying it again, the abuse filter blocked you." een goed voorstel?

Jammer dat het te vaak moet gebeuren, daarom dien ik het verzoek in. Met vriendelijke groet: Nieuwsgierige Gebruiker (overleg) 22 jun 2019 14:00 (CEST)

Hallo? Moet ik deze verzoek weghalen? Want dit staat al meer dan 2 weken en er is niemand die reageert, ben ik de enige die op zijn eigen verzoek reageert? Nieuwsgierige Gebruiker (overleg) 6 jul 2019 16:17 (CEST)
Ik denk dat geen van de filterredacteurs hier heil in zien. Het maken van een filter kost vermoedelijk te veel tijd en moeite voor iets wat maar een paar keer per jaar gebeurt. –bdijkstra (overleg) 6 jul 2019 17:08 (CEST)
Paar keer per jaar? Nou, dit gebeurd (bijna) elke week met die rare Russische bewerkingen. Nieuwsgierige Gebruiker (overleg) 6 jul 2019 17:11 (CEST)
In dat geval zou het misschien helpen om een beeld te geven van de schaal van de overlast. –bdijkstra (overleg) 6 jul 2019 17:54 (CEST)
Nou, het gaat voornamelijk om de OP 's en soms ook GP 's (mogelijk is de schaal van bij wie het voorkwam incompleet) van Q-bit array, Jimbo Wales, NBS, OneLittleMouse, Ping08, Takewaki, Sigwald, Lanwi1, Jni, Geom en soms Favonian die het doelwit voor dit soort LSV zijn. Nieuwsgierige Gebruiker (overleg) 6 jul 2019 18:43 (CEST)
Elke week moet zijn elke maand denk ik, want de laatste golf dateert van 5 juni en daarvoor 5 april. Het aantal golven is dit jaar nog op één hand te tellen, is makkelijk herkenbaar en dus ook eenvoudig terug te draaien. De impact is dus heel laag en het risico (kans x impact) daarmee ook. De hoeveelheid werk om zo'n filter te bouwen werkt kennelijk niet op tegen de hoeveelheid werk om enkele malen per jaar een 10-tal gebruikerspagina's schoon te vegen. Groet, Brimz (overleg) 6 jul 2019 22:34 (CEST)

Maar ik hoop dat je snapt dat ik dit verzoek ooit indiende omdat ik Wikipedia hiertegen wil wapenen en dit regelmatig voorkomt. Met vriendelijke groet: Nieuwsgierige Gebruiker (overleg) 7 jul 2019 09:09 (CEST)

Gisteravond even in de mogelijkheden van misbruikfilter gekeken, ik zie geen opties om te controleren of een gebruikt sjabloon bestaat of niet. Dus ik vrees dat dit niet mogelijk is technisch. Etersheim - Etersheimer Braakmolen met zeilen.jpg Akoopal overleg 7 jul 2019 10:09 (CEST)
Maar het zijn telkens dezelfde sjablonen, en bovendien zijn alle letters van de naam Cyrillisch. –bdijkstra (overleg) 7 jul 2019 10:42 (CEST)
Dus daar kunnen we toch de misbruikfilter toch op aanpassen of niet soms? Nieuwsgierige Gebruiker (overleg) 7 jul 2019 14:20 (CEST)
Ik zie geen brood in het blokkeren van niet-bestaande sjablonen, omdat zoiets detecteren uitsluitend zou kunnen gebeuren met de gerenderde html, en zoiets betrouwbaar detecteren kost een hoop regexen, waarvan een aantal op een ENORME string, als het uberhaupt te detecteren is. Ik zie ook geen brood in het blokkeren van bepaalde schriften, omdat de kans op vals-positieven groot is. Het aantal bewerkingen dat hieraan voldoet lijkt ook niet enorm groot te zijn als ik de recente wijzigingen bekijk. Sum?urai8? 29 aug 2019 22:34 (CEST)
Het zijn inderdaad niet veel bewerkingen en het maakt mijzelf niet uit of er een filter hiervoor komt of niet, maar volgens mij kan het in 1 simpele, korte regex, iets als: class="new" title=""\>Sjabloon:[А-Яа-я:_ ]+\</a\>. Vals-positieven lijken me miniem want sjablonen met Cyrillische titels zijn zwaar ongewenst, zeker in overlegnaamruimten. –bdijkstra (overleg) 29 aug 2019 22:56 (CEST)
Je hebt gedeeltelijk gelijk. Ik had een veel ingewikkeldere structuur in m'n hoofd dan dat je eigenlijk nodig hebt. Je wil altijd voorkomen dat je een regex uitvoert op new_html met een lichtere query. Dat kan ik doen door te zoeken op {{cyrilische tekens}} in added_lines. Dingen die ik moet checken:
  • Links naar externe wikis moeten niet worden gefilterd
  • Wat wordt er gegenereerd met Template:, wat met de ruwp variant van Template/Sjabloon?
Ik kijk hier hopelijk in het weekend naar. Sum?urai8? 29 aug 2019 23:43 (CEST)
Aangemaakt in log-only. Sum?urai8? 1 sep 2019 19:14 (CEST)
Filter blokkeert nu wijzigingen na recente wijzigingen door deze gebruiker. Geeft momenteel geen waarschuwing, maar de kans dat iemand legitiem volledig cyrillische sjablonen toevoegt op een nederlands artikel is ~0. Sum?urai8? 19 sep 2019 22:14 (CEST)


Valse negatieven filter 35[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen

Zie deze wijziging en deze wijziging. Het filter ging niet af voor de eerste maar wel voor de tweede, terwijl het dezelfde rode link was. Graag het filter aanscherpen. –bdijkstra (overleg) 27 jan 2020 10:58 (CET)

Wat mij opvalt is dat in de eerste links spaties tussen de haken en het gelinkte woord staan, mogelijk gaat het daar mis. Etersheim - Etersheimer Braakmolen met zeilen.jpg Akoopal overleg. 29 jan 2020 23:09 (CET)
Die spaties zijn zeker weten het probleem hier. Het is niet heel eenvoudig aan te passen, maar ik denk dat het wel mogelijk moet zijn. Ik kijk er een keer minder slaperig naar. Sum?urai8? 5 feb 2020 00:10 (CET)
Ik heb een wijziging gedaan die get_matches gebruikt om een match te vinden en op basis daarvan de rode link zoekt. Het werkt met een uitgeklede versie op wijzigingen in mijn gebruikersnaamruimte, dus ik verwacht dat er geen problemen zijn met deze versie. Ik laat deze een week in de testfase staan en zal de logs doorlopen. Mocht iemand valspositieven/valsnegatieven tegenkomen dan hoor ik het ook graag. Sum?urai8? 5 feb 2020 22:38 (CET)
Uitgevoerd Uitgevoerd Geen klachten en geen rare filtermeldingen volgens mij. Sum?urai8? 15 feb 2020 18:24 (CET)


Emoji[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Taak: Filter dat voorkomt dat er emoji in teksten en bewerkingssamenvattingen worden gebruikt.
  • Waarom: Bewerkingen als deze [3] zijn vrij zelden van toegevoegde waarde.
  • Gevolgen: Omdat de RTRC op emoji vastloopt, zou ik ervoor kiezen om dergelijke bewerkingen te verhinderen.
  • Waarschuwingstekst: Iets in de geest van dat emoji niet zijn toegestaan in de teksten op Wikipedia

Brimz (overleg) 29 aug 2019 22:12 (CEST)

Er zijn momenteel 1719 utf8 emoji's lijkt het.bron Sommige hebben meerdere varianten/codes waarmee ze opgeroepen kunnen worden. Ik kan niet zo snel terugvinden of er een speciale range is vastgesteld waarin emoji's moeten zitten. Een paar duizend karakters in een regex stoppen lijkt mij niet heel snel/efficient, en ik wil niet een range opgeven die mogelijk karakters buiten deze al dan niet bestaande emoji range detecteert. Sum?urai8? 29 aug 2019 22:55 (CEST)
N.B. Dat RTRC crasht op bepaalde unicode karakters is een probleem dat Krinkle zelf moet oplossen. Het lijkt mij niet de bedoeling dat we tekenreeksen blokkeren omdat bepaalde tools er niet mee overweg kunnen. Sum?urai8? 29 aug 2019 22:57 (CEST)
Ik gok dat RTRC vastloopt op alle karakters boven U+FFFF. Meer oude JavaScript-code heeft hier moeite mee. –bdijkstra (overleg) 29 aug 2019 23:02 (CEST)
P.S. Zie Lijst van Unicode-subbereiken voor de emoji-range. En als je emoji's niet wil toestaan dan kan je categorie:Emoji wel opdoeken en ook kan je dan een aantal bronnen verwijderen waarin twitterberichten van beroemde personen geciteerd worden. –bdijkstra (overleg) 30 aug 2019 19:32 (CEST)
Daar heb je wel een punt. Dat laat onverlet dat emoji (is meervoud niet ook emoji?) in de bewerkingssamenvatting niet nodig zijn en dat het verhinderen daarvan geen nadelige gevolgen zal hebben om artikelen of categorieën over emoji aan te vullen. Brimz (overleg) 30 aug 2019 21:00 (CEST)
Meervoud zonder "'s" mag, maar ik heb de voorkeur voor met. Wat bedoel je trouwens met vastlopen? Als ik in RTRC bij tijdsbestek 20190829200100…20190829200359 invul zie ik geen rare dingen. –bdijkstra (overleg) 30 aug 2019 22:13 (CEST)
01 F600-01 F64F kwam ik eerder ook al tegen, maar als ik m'n hexadecimalen goed lees zijn dat 80 tekens. Er zijn een stuk meer emojis. Ik zie ook een emoji als 1F923 en 263A bijvoorbeeld. Gezien we emoji-artikelen hebben is het een stuk lastiger om een filter te maken die niet te restrictief is. Ik wacht op meer feedback van anderen hoe gewenst dit filter is. Sum?urai8? 31 aug 2019 10:51 (CEST)
Sorry ik haalde emoticons en emoji's door elkaar. Hier is een meer volledige lijst. –bdijkstra (overleg) 31 aug 2019 11:05 (CEST)
  • Blijkbaar doet filter 24 al het een en ander. Deze tagt de edit als kwebbelen. Ik denk niet dat blokkeren van de edit nodig is, maar ik zal kijken welke ranges nog niet in dit filter vallen. Sum?urai8? 7 sep 2019 22:18 (CEST)
    • Niet uitgevoerd Niet uitgevoerd Sum?urai8? 19 sep 2019 22:15 (CEST)

Ik weet niet of dit onderwerp nu al gesloten is, maar er werden afgelopen week twee onzinpagina's aangemaakt, een ervan met de titel "🙏" (nog terug te vinden voor gewone stervelingen) en nog een andere van dezelfde anonieme aanmaker 213.125.110.178 (die, omdat de bewerking is verborgen) alleen voor moderators is te achterhalen). Het lijkt me zinvol om tenminste [de aanmaak van] titels met éé of louter unicode-emoticon karakters te blokkeren/weren of te vlaggen? Mvg -- martix (overleg) 15 feb 2020 18:46 (CET)

Ik zal ze wel markeren, maar blokkeren gaat denk ik te ver. Ik ga hiervoor denk ik een testfilter aanmaken die ik een tijdje naast het bestaande filter laat lopen. Dan kunnen we kijken hoe goed het nieuwe filter werkt. Sum?urai8? 15 feb 2020 20:03 (CET)
Bv. 🍆 is geen onzinpagina. Een emoji als titel (inclusief van een redirect) is helemaal niks mis mee. –bdijkstra (overleg) 15 feb 2020 20:15 (CET)
Daar kan ik me inderdaad wel in vinden, dat voor sommige van die tekens een uitzondering geldt, maar ik schat in dat de meest relevante wel al bestaan, en/of anders -- wanneer minder relevant -- in het/een verzamel- of hoofdartikel over Unicode ingevoegd kan worden.
Terzijde/een beetje off-topic: persoonlijk zou ik er overigens voor gekozen hebben om de daadwerkelijke pagina-titel (die getoond word) een naam in het 'gewone latijnse schrift' te geven (dus "Aubergine (emoji|emotican|unicode)" en de van de pagina met het emoticon zelf als titel een #DOORVERWIJZING (redirect) te maken (omdat voor lang niet iedereen, afhankelijk van het device, platform, OS, browser en instellingen het icoon/emoticon/emoji niet getoond wordt, maar voor hen als titel slechts een (leeg) vierkantje te zien is, wanneer men geluk heeft, een vierkantje met daarin de 4 hexadecimale cijfers overeenkomend met het betreffende karakter. In het artikel erover staat een "gewone" afbeelding die toont hoe het emoji/emoticon er ongeveer uit kan of hoort te zien, hetgeen mensen dan kan helpen om hun instellingen aan te passen (zo zie ik, als iemand het 'Apple logo' in de tekst opneemt of verstuurt, dit karakter: "" (0xF8FF – dat er toevallig in de browser waarin ik nu werk, voor mij uitziet als een leeg vierkantje/rechthoekje, maar in de vrijwel alle andere applicaties als: "(t)" (een vetgedrukte onderkast van de t, omvat tussen twee cursieve haken, getoond op halve karakterhoogte t.o.v. de maximale verticale ruimte voor de huidige karakterset; wis en waarachtig te identificeren als "bijzonder" Unicode teken, maar met de beste wil van de wereld zie ik er geen appel noch eender welk ander stuk fruit dan ook in).
Verder, vanwege de Engelstalige invloeden zullen sommigen het misschien slechts kennen onder de term "eggplant", is het te overwegen om voor die term ook een redirect aan te maken, hoezeer ik ook onderschrijf dat dit een Nederlandstalige Wikipedia is, maar in de vaart der volkeren moet je soms wel toegeven en meegaan met de stroom, i.p.v. er tegenin.
Maar afsluitend, een vlag/flag/alert/label is inderdaad al zinvol genoeg. Mocht t.z.t. tijdens vandalismebestrijding gaan blijken dat de populariteit van onzinpagina's met emoji-titels hand over hand toeneemt, kunnen er altijd strengere (maar met voortschrijdend inzicht ook specifiekere) filter-expressies en -handelingen worden aangepast. Dank & mvg -- martix (overleg) 16 feb 2020 09:16 (CET)
Dit is off-topic, maar het Apple-logo is een geval apart: als beschermd handelsmerk is het niet opgenomen in Unicode. Verschillende Unicode-implementaties mogen verschillende dingen doen met de code 0xF8FF. –bdijkstra (overleg) 16 feb 2020 09:37 (CET)
Ah, maar dat brengt ons eigenlijk toch weer on-topic: behalve de Emoji-ranges lijkt het me net zo ongewenst om karakters uit de Private Use Ranges (Areas, Characters or Blocks (PUA) in te titel te hebben omdat het onvoorspelbaar is hoe het er op verschillende platforms uitziet. Daarnaast kan ik me zo 1-2-3 ook geen valide toepassing voorstellen voor het gebruik van horizontaal of verticaal gespiegelde karakters uit het standaard Latijnse schrift (alfabet) in de titels (uiteraard wel toelaatbaar in de artikeltekst). Op Unicode.org staat ook nog een FAQ over blocks en ranges, en hoewel aanvankelijk bedoeld voor een ander platform (Windows), staat hier op github een voorbeeld van het detecteren (filteren) van (o.a.) de Private Use Areas in Unicode tekst -- misshien dat het Sumurai8 nog wat kan helpen of een completer overzicht geeft van te mijden (of te vlaggen) ranges (al dan niet met al door anderen uitgevlooide (efficiënte) regexp's. Groeten -- martix (overleg) 16 feb 2020 12:12 (CET)
Ik weet niet of een misbruikfilter hiervoor de aangewezen manier is, aangezien Unicode telkens wordt uitgebreid. Regelmatig download ik de data dump en daarlangs haal ik dat soort dingen er al uit, zie gebruiker:bdijkstra/badchars. –bdijkstra (overleg) 16 feb 2020 12:39 (CET)
Ik denk dat bovenstaande check voldoende is. Het lijkt niet vaak genoeg voor te komen om dat soort wijzigingen eruit te halen, en nieuwe pagina's worden al allemaal gecontroleerd. Er is niet een makkelijke manier om ongewenste pagina's met emoji's te detecteren zonder dat hier vals-positieven tussenzitten. Ik zet dit verzoek voor nu weer in de ijskast. Sum?urai8? 2 mrt 2020 20:20 (CET)


Magische woorden met VT[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Taak: Graag loggen op het toevoegen van __([A-Z]|[A-Z]_[A-Z]){3,}__ in alle naamruimten waar de VT actief is (0, 2, 6, 12, 14 en binnenkort ook 4).
  • Waarom: Op Wikipedia:Visuele tekstverwerker/To do kwam naar voren dat het met de Visuele Tekstverwerker zeer gemakkelijk is om Magische woorden met dubbele underscores in te voegen. Bijvoorbeeld __DISAMBIG__, __GEENNIEUWKOPJEKOPPELING__, __INDEX__ enz. Het gebruik hiervan is doorgaans geen vandalisme, maar vaak wel misbruik. Sommige van deze magische woorden gebruiken een volgcategorie maar de anderen zijn zeer lastig te traceren, zeker op redirects. In het verleden heb ik de XML-dump gebruikt om misbruik op te sporen, zie bv. hier.
  • Gevolgen: Voorlopig geen.
  • Waarschuwingstekst: geen

Ik ben bezig met een tweede verzoek om in bepaalde naamruimten met bepaalde magische woorden (en ook met sommige paginatitels) te waarschuwen of te verhinderen. Dat kan een apart filter worden. –bdijkstra (overleg) 9 jan 2020 18:02 (CET)

Opmerking Opmerking Nu dat de VT standaard ingeschakeld is, is het m.i. gewenst om dit filter snel operationeel te hebben. –bdijkstra (overleg) 4 feb 2020 21:11 (CET)
@Bdijkstra: Dit is blijkbaar volledig langs me heen geschoten. Ik heb filter 93 in log-only modus aangezet voor een week. Je kunt de logs langslopen voor nu. Als het filter werkt naar behoren zal ik er ook een label aanhangen voor de recente wijzigingen. Sum?urai8? 5 feb 2020 00:00 (CET)
Dank, maar ik ben wel benieuwd waarom je niet de regex hebt gebruikt die ik voorstelde. Sommige magische woorden blijken weliswaar ook met kleine letters te werken, maar de VE gebruikt alleen hoofdletters. URLs van onder andere telegraaf.nl bevatten nogal eens dubbele underscores met kleine letters, dus met de huidige versie verwacht ik aardig wat valse positieven. Ook komt __[A-Z]{1,2}__ wel eens in URLs voor, maar niet in magische woorden, dus ook hierdoor verwacht ik valse positieven. –bdijkstra (overleg) 5 feb 2020 18:54 (CET)
De regex leek me onnodig complex, maar ik zie waar je op doelt. Ik heb nu de lijst van magische woorden en de Disambiguator-extensie ernaast gelegd en er een eindige lijst van gemaakt. Sum?urai8? 5 feb 2020 21:13 (CET)
Fijn, daarmee zijn valse positieven vrijwel uitgesloten. Op mw:Help:Magic words staat ook nog __EXPECTUNUSEDCATEGORY__, maar die kan je niet invoegen via de VT. –bdijkstra (overleg) 5 feb 2020 21:39 (CET)
Grappig, die staat niet tussen de Nederlandse vertalingen. Ik heb 'm voor de volledigheid toegevoegd. Sum?urai8? 5 feb 2020 21:59 (CET)
Ik heb ook besloten te tracken wanneer zulke magische woorden worden verwijderd. Voor wat je wil bereiken is dat net zo belangrijk. Sum?urai8? 8 feb 2020 23:11 (CET)
Geen vals positieven. Ik heb het label "Magisch woord" toegevoegd. Het filter markeert alleen wijzigingen en doet verder niets anders. Sum?urai8? 15 feb 2020 18:20 (CET)
Uitgevoerd Uitgevoerd Geen andere opmerkingen. Sum?urai8? 7 mrt 2020 13:08 (CET)


Magische woorden, fase 2[bewerken | brontekst bewerken]

Status: Actief

Aanmaken filter · batchtesten

Indexatie van al geïndexeerde pagina's: bewerken · geschiedenis · logboeken · testen
In of uitschakelen sectiebewerking: bewerken · geschiedenis · logboeken · testen
Uitschakelen van galerij: bewerken · geschiedenis · logboeken · testen
Uitschakelen van indexering: bewerken · geschiedenis · logboeken · testen
Instellen als statische redirect: bewerken · geschiedenis · logboeken · testen
Instellen als doorverwijspagina: bewerken · geschiedenis · logboeken · testen

  • Taak: Het blijkt wel degelijk regelmatig mis te gaan met magische woorden en de VT, vooral met nieuwe gebruikers.
  • Waarom: Het zou jammer zijn als deze gebruikers zichzelf verkeerde gewoontes aanleren.
  • Gevolgen: Waarschuwen of verhinderen bij verschillende magische woorden.
  • Waarschuwingstekst: Afhankelijk van de situatie.

Details:

  • Waarschuwen bij het toevoegen van __INDEX__ in 0 (artikelnaamruimte) en 14 (categorienaamruimte)
    Waarschuwingstekst: U heeft de optie ingeschakeld om zoekmachines deze pagina te laten indexeren, maar dit gebeurt al, dus het heeft geen effect.
  • Verhinderen van het toevoegen van __(NO|GEEN)?(NEW|NIEUWE)(SECTION|SECTIE|KOPJE)(LINK|KOPPELING|VERWIJZING)__ in 0 en 14
    Waarschuwingstekst: U heeft de optie [in/uit]geschakeld om een tabblad weer te geven om een nieuwe paragraaf toe te voegen op deze pagina, maar dit is niet gewenst in deze naamruimte.
  • Verhinderen van het toevoegen van __(NOGALLERY|GEEN_GALERIJ)__ in 14
    Waarschuwingstekst: U heeft de optie ingeschakeld om het genereren van een galerij uit te schakelen, maar dit is ongewenst.
  • Verhinderen van het toevoegen van __(NO|GEEN)INDEX__ in 0 en 14 behalve door moderatoren, behalve pagina's met {{Auteur}}, {{Nuweg}} of {{Reclame}} en behalve ^Categorie:(Gebruiker:|Wikipedia:Gebruikers/)
    Waarschuwingstekst: U heeft de optie uitgeschakeld om zoekmachines deze pagina te laten indexeren, maar dit is ongewenst.
  • Verhinderen van het toevoegen van __(STATIC|STATISCHE)(REDIRECT|DOORVERWIJZING)__ in 0 en 14
    Waarschuwingstekst: U heeft de optie ingeschakeld om te voorkomen dat deze doorverwijzing wordt bijgewerkt als de doelpagina wordt hernoemd, maar dit is niet van toepassing op deze wiki.
  • Verhinderen van het toevoegen van __DISAMBIG__ in 0 en 14
    Waarschuwingstekst[0]: U heeft de optie ingeschakeld om deze pagina te markeren als een doorverwijspagina. Dit doen we op deze wiki altijd met het Sjabloon:Dp.
    Waarschuwingstekst[14]: U heeft de optie ingeschakeld om deze pagina te markeren als een doorverwijspagina, maar dit is ongewenst op categoriepagina's.

Voor overwegingen en redenen, zie gebruiker:bdijkstra/Gedragschakelaars. –bdijkstra (overleg) 26 feb 2020 17:00 (CET)

Ik heb deze pagina op Overleg gewenst gezet, om meer input te krijgen over dit voorstel. Ik ben voornamelijk op zoek naar het volgende:
  • Zijn er bewerkingen die door de voorgestelde filters zouden worden geblokkeerd, die niet geblokkeerd zouden moeten worden?
  • Zijn er structurele bezwaren om de voorgestelde filters te gebruiken, en zoja, waarom en op welke wijze zou je het liever zien?
Bij voldoende support/uitblijven bezwaren zal ik deze filters in log-only mode aanmaken aankomend weekend. Er is dan nog zeker een week om eventuele bezwaren te uiten. Sum?urai8? 2 mrt 2020 20:16 (CET)
Filters aangemaakt in log-only:
Sum?urai8? 7 mrt 2020 23:56 (CET)
Berichten zoals ik die morgen wil gaan inschakelen:
Indexatie van al geïndexeerde pagina's (MediaWiki:Abusefilter-warning-indexatie, {{Misbruikfilter-waarschuwing-indexatie}})
Rode vlag U heeft de optie ingeschakeld om zoekmachines deze pagina te laten indexeren
Volgens een automatisch systeem heeft u de optie ingeschakeld om zoekmachines deze pagina te laten indexeren. In deze naamruimte gebeurt dit echter al automatisch. Expliciet aangeven dat deze pagina moet worden geïndexeerd heeft dus geen effect.

U kunt deze melding vermijden door onder Geavanceerde instellingen in de visuele editor de instelling voor zoekmachines op Standaard te zetten.

In of uitschakelen sectiebewerking (MediaWiki:Abusefilter-warning-sectiebewerking, {{Misbruikfilter-waarschuwing-sectiebewerking}}, gevolgd door de algemene MediaWiki:Abusefilter-disallowed, {{Misbruikfilter-verhinderen}})
Rode vlag U heeft het tabblad "Kopje toevoegen" in- of uitgeschakeld
Volgens een automatisch systeem heeft u het tabblad "Kopje toevoegen" in- of uitgeschakeld. Aanpassen van deze optie is alleen nuttig voor normale pagina's die voor overleg gebruikt worden, of overlegpagina's die expliciet niet voor overleg gebruikt worden.

In deze naamruimte (Wikipedia) is aanpassing van deze optie niet gewenst.

Dialog-error.svg U mag deze bewerking niet uitvoeren
Uw bewerking is door een automatisch systeem aangemerkt als schadelijk. Deze bewerking wordt daarom verhinderd.


Uitschakelen van galerij (MediaWiki:Abusefilter-warning-nogallery, {{Misbruikfilter-waarschuwing-nogallery}}, gevolgd door de algemene MediaWiki:Abusefilter-disallowed, {{Misbruikfilter-verhinderen}})
Rode vlag U heeft het automatisch genereren van een galerij uitgeschakeld
Volgens een automatisch systeem heeft u het automatisch genereren van een galerij uitgeschakeld.

In deze naamruimte (Wikipedia) is aanpassing van deze optie niet gewenst. U kunt dit ongedaan maken door onder Pagina-instellingen de optie Galerij uitschakelen aan te passen.

Dialog-error.svg U mag deze bewerking niet uitvoeren
Uw bewerking is door een automatisch systeem aangemerkt als schadelijk. Deze bewerking wordt daarom verhinderd.


Uitschakelen van indexering (MediaWiki:Abusefilter-warning-noindex, {{Misbruikfilter-waarschuwing-noindex}}, gevolgd door de algemene MediaWiki:Abusefilter-disallowed, {{Misbruikfilter-verhinderen}})
Rode vlag Indexatie van deze pagina is uitgeschakeld
Volgens een automatisch systeem is de optie uitgeschakeld om zoekmachines deze pagina te laten indexeren. Dit is ongewenst, tenzij het gaat om een van de volgende situaties:
  • De pagina voldoet aan een van de voorwaarden voor directe verwijdering. Op de pagina moet het sjabloon nuweg worden ingevoegd.
  • De pagina bevat waarschijnlijk auteursrechtenschendende tekst. Wanneer de pagina niet voor directe verwijdering wordt voorgedragen moet het sjabloon auteur worden ingevoegd.
  • De pagina bevat reclame. Wanneer de pagina niet voor directe verwijdering wordt voorgedragen moet het sjabloon reclame worden ingevoegd.

Indien geen van deze situaties van toepassing is kunt u onder Geavanceerde instellingen de optie Zoekmachines deze pagina laten indexeren op Standaard zetten.

Dialog-error.svg U mag deze bewerking niet uitvoeren
Uw bewerking is door een automatisch systeem aangemerkt als schadelijk. Deze bewerking wordt daarom verhinderd.


Instellen als statische redirect (MediaWiki:Abusefilter-warning-statische-redirect, {{Misbruikfilter-waarschuwing-statische-redirect}}, gevolgd door de algemene MediaWiki:Abusefilter-disallowed, {{Misbruikfilter-verhinderen}})
Rode vlag Pagina ingesteld als statische doorverwijzing
Volgens een automatisch systeem heeft u ingesteld dat deze pagina moet worden behandeld als een statische doorverwijzing. Hierdoor zou worden voorkomen dat deze pagina wordt bijgewerkt als de doelpagina wordt hernoemd. Deze functie is niet ingeschakeld op deze wiki, dus is dit ongewenst.

U kunt deze optie uitschakelen door onder Pagina-instellingen de optie Voorkomen dat deze doorverwijzing wordt bijgewerkt als de doelpagina wordt hernoemd aan te passen.

Dialog-error.svg U mag deze bewerking niet uitvoeren
Uw bewerking is door een automatisch systeem aangemerkt als schadelijk. Deze bewerking wordt daarom verhinderd.


Instellen als doorverwijspagina (MediaWiki:Abusefilter-warning-instellen-als-doorverwijspagina, {{Misbruikfilter-waarschuwing-instellen-als-doorverwijspagina}}, gevolgd door de algemene MediaWiki:Abusefilter-disallowed, {{Misbruikfilter-verhinderen}})
Rode vlag Pagina gemarkeerd als doorverwijspagina
Volgens een automatisch systeem heeft u deze pagina gemarkeerd als doorverwijspagina.

Dit is ongewenst in deze naamruimte (Wikipedia).

Schakel deze optie uit door onder Pagina-instellingen de optie Markeer deze pagina als een doorverwijspagina aan te passen.

Dialog-error.svg U mag deze bewerking niet uitvoeren
Uw bewerking is door een automatisch systeem aangemerkt als schadelijk. Deze bewerking wordt daarom verhinderd.


@Bdijkstra: Kun jij kijken naar de bewoording van de waarschuwingen? Ik ben van plan om de maatregelen in te schakelen met deze teksten morgen einde dag. Sum?urai8? 14 mrt 2020 21:38 (CET)
Ik zal er morgen naar kijken. –bdijkstra (overleg) 14 mrt 2020 21:54 (CET)
Ik heb wat aanpassingen gedaan, de waarschuwingen zijn wat mij betreft goed nu, op één ding na (maar dat kan achteraf ook). Is er een specifieke reden waarom je de genoemde sjablonen niet linkt? Daarnaast heeft filter 97 denk ik nog een kleine aanpassing nodig voordat ie uit log-only gaat: dit zou ook moeten checken op de redirects Speedydelete, Speedy, Delete, Db-author en Db-user. –bdijkstra (overleg) 15 mrt 2020 21:00 (CET)
Ik kan niet forceren dat een link opent in een apart tabblad, en het bericht wordt getoond op een bewerkpagina. Ik wil voorkomen dat onervaren bewerkers hun wijziging kwijtraken omdat ze doorklikken naar een sjabloon. Om dezelfde reden heb ik ook geen accolades gebruikt. In de meeste gevallen zullen zulke wijzigingen gedaan worden door iemand die heel goed weet wat magische woorden zijn (en die ook weer kunnen weghalen), of onervaren gebruikers die het via VT toevoegen. Daar zie je geen accolades.
Ik heb de genoemde sjablonen toegevoegd aan filter 97. Sum?urai8? 16 mrt 2020 18:51 (CET)
Oké, logisch. Voor onervaren gebruikers zal het inderdaad mogelijk zijn dat ze hun wijzigingen kwijtraken. –bdijkstra (overleg) 16 mrt 2020 19:11 (CET)
Filters nu ingeschakeld met waarschuwingen en blokkeringen. Sum?urai8? 16 mrt 2020 19:21 (CET)
Uitgevoerd Uitgevoerd Geen klachten tijdens testfase. Sum?urai8? 29 mrt 2020 11:28 (CEST)


Tijdsloze aanduidingen[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Taak: Het filteren op woorden als recent, binnenkort, vandaag, momenteel, inmiddels, tegenwoordig, en dan iedereen die dit wil invoegen waarschuwen
  • Waarom: Zie deze discussie: dergelijke woorden schaden de kwaliteit van Wikipedia en dienen in principe niet aan artikelen toegevoegd te worden (uitgezonderd citaten). Het probleem er in ligt dat we enerzijds in het dagelijks leven heel makkelijk woorden als "momenteel" gebruiken en anderzijds er toch nog best veel gebruikers zijn die hier niet of te weinig van op de hoogte zijn.
  • Gevolgen: Waarschuwen
  • Waarschuwingstekst: "In een encyclopedie kan geen relatieve tijdsaanduiding in de tekst staan, zoals vandaag, binnenkort, tegenwoordig, het afgelopen decennium, deze eeuw, etc. omdat later niet duidelijk is op welke tijdsperiode deze woorden betrekking hebben. Zie voor meer informatie: Wikipedia:Tijdsaanduiding.
    (op een 2e regel:) Een uitzondering hierop zijn citaten waarin deze woorden voorkomen. Uit de context van de omliggende tekst dient dan duidelijk te worden naar welke precieze tijdsaanduiding er verwezen wordt.


Romaine (overleg) 16 apr 2020 12:52 (CEST)

Opmerking Opmerking - Dan wel in de waarschuwingstekst opnemen dat er soms uitzonderingen mogelijk zijn (met name citaten); het voorstel suggereert dat deze woorden nooit zouden kunnen. Encycloon (overleg) 16 apr 2020 16:50 (CEST)
Dank voor de suggestie, die heb ik zojuist toegevoegd op Wikipedia:Tijdsaanduiding en hierboven met twee zinnen op een aparte regel. Romaine (overleg) 17 apr 2020 09:08 (CEST)
Uitgevoerd Uitgevoerd Aangemaakt in log-only. Sum?urai8? 19 apr 2020 12:53 (CEST)
Op basis van deze bewerking heb ik een conditie toegevoegd die de meeste tijdsaanduidingen in referenties negeert. Ik match nu ook op het woord "recente", wat eerder werd genegeerd. Sum?urai8? 20 apr 2020 20:00 (CEST)
Uitgevoerd Uitgevoerd Inschakeling met waarschuwingstekst. Sum?urai8? 25 apr 2020 14:42 (CEST)
@Sumurai8: Mooi! Het lijkt er op dat er af en toe gebruikers zijn die in plaats van de gefilterde woorden andere woorden gaan invoegen. Bv nu, kan die ook toegevoegd worden? Mogelijk zijn er nog meer andere woorden die ook nu gebruikt worden als alternatief die ook niet tijdgebonden zijn. Wellicht kan de tekst van het filter ook iets meer uitleg krijgen met voorbeelden. Bv in plaats van in deze eeuwin de 21e eeuw en in plaats van tegenwoordigsinds jaar X. Romaine (overleg) 28 apr 2020 14:42 (CEST)
Een paar opmerkingen.
  1. In een encyclopedie kan geen relatieve tijdsaanduiding in de tekst staan - ik zou dit minder dwingend maken (beeld je de irritatie in van iemand die net een enorme lap tekst opslaat met daarin 1x het woordje "tegenwoordig"). Vervang het door: Advies: wees in een encyclopedische tekst terughoudend met relatieve tijdsaanduidingen.
  2. Het was 10 mei, de oorlog was inmiddels voorbij kan prima. Ik zou het specifieker maken en het filter pas af laten gaan bij inmiddels is of is inmiddels.
  3. Nu zou ik niet zomaar toevoegen. Bijvoorbeeld in de uitleg van een algoritme kan het prima: nu berekend is dat.... Misschien ook hier specifieker: is nu. Maar dan nog: "het is nu eenmaal zo dat...". Een lastige dus.
Verder ben ik overigens wel voorstander van dit filter. Maar nog een paar keer goed overdenken kan geen kwaad. Josq (overleg) 28 apr 2020 15:20 (CEST)
Dank voor de feedback! Ik denk dat er zeker nog wat verbeteringen wenselijk zijn. Een zinsconstructie als "het is nu eenmaal zo dat..." is ook niet gewenst in verband met WP:WEASEL.
Echter, het mag denk ik zachter geformuleerd worden, maar "advies" is denk ik veel te vrijblijvend. Romaine (overleg) 28 apr 2020 15:37 (CEST)
Een onterechte melding speelde bv hier ook doordat "huidige" onderdeel is van een parameter van een infobox. Dat zal ook uitgezonderd moeten worden. Romaine (overleg) 28 apr 2020 15:43 (CEST)
Omdat er al een discussie gaande was op deze pagina, denk ik dat het handig is om daar te overleggen over de tekst van het filter. Romaine (overleg) 28 apr 2020 15:59 (CEST)
@Romaine: De gelinkte bewerking ging af op "Inmiddels". "Huidig(e)" staat niet op de lijst. Ik heb alles in de vorm van "woord + eventuele spaties + =" er desalnietemin uitgefilterd. Je kunt de melding die wordt weergegeven ook zelf aanpassen op {{Misbruikfilter-waarschuwing-tijdsaanduiding}}. Sum?urai8? 28 apr 2020 20:43 (CEST)
Lijkt correct te werken. Naar afgehandeld. Sum?urai8? 17 jun 2020 12:30 (CEST)


Categorieën homoseksualiteit in de geschiedenis[bewerken | brontekst bewerken]

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen
  • Taak: Tegenhouden van bewerkingen als deze en deze, effectief het toevoegen van de subcategorieën van categorie:Homoseksualiteit in de geschiedenis en de nog onbestaande categorie:Homoseksualiteit in het Oude Rome, In ieder geval voor IP-gebruikers.
  • Waarom: Ondanks kritiek en twijfels vanuit de gemeenschap (zie m.n. hier en hier, en talloze ongedaanmakingen van diverse gebruikers) worden deze categorieën vanaf verschillende IP-adressen aanhoudend gepusht zonder enige toelichting of wil tot overleg.
  • Gevolgen: Verhinderen
  • Waarschuwingstekst: Voor de toepassing van de categorieën met betrekking tot homoseksualiteit in de geschiedenis bestaat geen consensus. Gelieve op Wikipedia:De kroeg#Categorieën homoseksualiteit deel te nemen aan de gerelateerde discussie.
    (Voorgestelde tekst moet dan wel aangepast worden als de discussie gearchiveerd wordt.)
  • Opmerking: mocht de gebruiker de komende tijd niet weer doorgaan, kan dit verzoek vervallen.

Encycloon (overleg) 6 jun 2020 12:01 (CEST)

Dit verzoek is totaal van mijn radar gevallen. Ik heb filter 102 in log-only aangemaakt. Sum?urai8? 17 jun 2020 12:30 (CEST)
Er zijn sindsdien 2 hits, beide in juli 2020. @Encycloon:, mogen we voorzichtig concluderen dat de storm is gaan liggen en het filter uitschakelen? Lymantria overleg 21 jan 2021 19:50 (CET)
@Lymantria: je ping werkte niet (waarschijnlijk hierdoor). Maar die conclusie lijkt me inderdaad juist, dit kan weer uitgeschakeld worden. Mvg, Encycloon (overleg) 10 feb 2021 11:06 (CET)
Dank. Ik heb hem uitgeschakeld. Lymantria overleg 10 feb 2021 11:29 (CET)


Woorden Fat ass, Fat Ass, Phat Ass, Phat ass[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Taak: Veelgebruikte scheldwoorden in cyberpestedits
  • Waarom: Voorkomen dat men dat gescheld plaatst
  • Gevolgen: Verhinderen
  • Waarschuwingstekst:

Eventuele overige opmerkingen - graag toevoegen aan de scheldwoordenfilter als die er is Hoyanova (overleg) 29 jan 2021 12:08 (CET)

Verhinderen bij iedereen vind ik een beetje ver gaan, er is leglitiem gebruik van die termen. Kan het filter selectief verhinderen bij anoniemen en niet-autobevestigde gebruikers? –bdijkstra (overleg) 29 jan 2021 13:14 (CET)
Phat arse mag er ook bij. De meeste varianten komen ook aaneengeschreven voor. Al deze termen kunnen weliswaar denigrerend gebruikt worden, maar zijn geen scheldwoorden, althans niet in het Engels; ze betekenen min of meer lekker kontje →bertux 29 jan 2021 14:04 (CET)
Volgens mij komen ze in de Nederlandstalige Wikipedia enkel voor bij cyberpestende figuren die die woorden plaatsen. Hoyanova (overleg) 29 jan 2021 16:00 (CET)
Ja, als reactie op dit verzoek vond ik twee gevallen van plaatsartikelen waar aan het kopje Geboren een regel met naam, geboortejaar en "phat ass" waren toegevoegd. Zie ook Wikipedia:De kroeg#Eergisteren, gisteren en vandaag veel vandalisme in lemma's van inwonerslijsten en woonplaatsen. –bdijkstra (overleg) 29 jan 2021 16:20 (CET)
Ik heb dit aan filter 10 (schuttingtaal) toegevoegd. Sum?urai8? 21 feb 2021 23:47 (CET)


Vermelding overlijdens[bewerken | brontekst bewerken]

Status:

Aanmaken filter · batchtesten
  • Taak: Wijzigingen waarin zinsneden toegevoegd worden zoals sterft/stierf/gestorven, overlijd/overleed/overleden, vond de dood/dood gevonden, om het leven, pleegde zelfmoord, bee/ëindigde zijn/haar/het leven; waarbij een van deze zinsneden niet al eerder in de tekst stond; waarbij er geen <ref> (of andere bronvermelding: het woordje "bron", een URL) wordt toegevoegd; op pagina's die (indirect) onder de categorie:Persoon vallen. Indien mogelijk ook een check dat het niet om een historisch persoon gaat.
  • Waarom: Naar aanleiding van incidenten waarbij iemands overlijden (te) vroegtijdig werd gemeld zonder dat er goede bronnen beschikbaar waren. Zie deze Kroegdiscussie en in het bijzonder de suggestie van gebruiker:Matroos Vos.
  • Gevolgen: Een "waarschuwing" met zeer vriendelijke uitleg over de wenselijkheid van goede bronvermelding, er rekening mee houdend dat het ook nabestaanden kunnen zijn die dergelijke wijzigingen doen.
  • Waarschuwingstekst: Mogelijk probeert u iemands overlijden te vermelden. Als dat het geval is, dan is het van belang dat u betrouwbare bronnen opgeeft. Als een overlijden nog niet in betrouwbare (nieuws)bronnen gepubliceerd is, kunt u beter wachten met het te vermelden op Wikipedia. Voor vragen en hulp kunt u terecht op onze Helpdesk.

Josq (overleg) 10 feb 2021 11:07 (CET)

Er kan wellicht ook gekeken worden of een gebruiker infobox-velden als overlijddatum, sterfdatum en overlijden/overleden invult, en of in de eerste regel van een artikel (JAAR) of (PLAATS, JAAR) gewijzigd wordt naar (JAAR - ...) of (PLAATS, JAAR - ...). In de waarschuwingstekst nog linken naar WP:VER? Encycloon (overleg) 10 feb 2021 11:17 (CET)
Goede suggesties! Josq (overleg) 10 feb 2021 11:18 (CET)
Ik weet niet of dat met ditzelfde filter kan, en/of dat we er beter een editnotice voor kunnen aanmaken, maar bij de lijsten van overleden personen (vooral die van de huidige maand) is de facto bronvermelding ook verplicht. Encycloon (overleg) 10 feb 2021 15:34 (CET)
Kleine opmerking, het kan zijn dat de bron in de bewerkingssamenvatting genoemd word, dat zou ook gecontroleerd moeten worden lijkt me. – De voorgaande bijdrage werd geplaatst door Akoopal (overleg · bijdragen)
Dit is iets wat makkelijk te detecteren is voor mensen, maar lastig te vatten is in een filter denk ik. Teveel termen waar op gecheckt moet worden, teveel edge cases en teveel kans op vals-positieven. Sum?urai8? 21 feb 2021 23:34 (CET)
En als we het filter zouden beperken, bijvoorbeeld dus tot het specifieke infobox-veld? Encycloon (overleg) 21 feb 2021 23:42 (CET)
Dat zou makkelijker zijn. Dat is feitelijk een check of de tekst "overlijddatum=iets" voorkomt in de toegevoegde regels en of er extra links zijn toegevoegd aan de pagina. Ik vraag me sowieso af of het niet beter is om altijd bovenaan een pagina over een persoon te wijzen op WP:BLP en het belang van bronvermelding. Uiteindelijk moet alle informatie op die pagina onderbouwd zijn met bronnen, of anders direct teruggedraaid worden. Sum?urai8? 22 feb 2021 00:00 (CET)
En wellicht ook nog checken of de toevoeging het huidige jaartal bevat (of dat van het vorige jaar, denk aan een edit op 1 januari). Inderdaad zou een algemene notificatie ook goed zijn, maar of dat praktisch haalbaar is? Dan zou je eigenlijk zoiets als een verborgen Categorie:Levend persoon moeten hebben. Encycloon (overleg) 22 feb 2021 00:09 (CET)
@Sumurai8: kun je voorbeelden geven van mogeljke edge cases/vals positieven die niet/moeilijk te voorkomen zijn met wat creativiteit? Josq (overleg) 22 feb 2021 08:42 (CET)
Filters zijn slecht in het bepalen van context.
  • Ik kan niet bepalen dat een artikel een categorie heeft die een subcategorie van Categorie:Persoon is. Ik moet dit dus via een andere weg bepalen of iemand een persoon is.
  • Ik kan niet de infobox gebruiken, want er zijn tal van infoboxen die een persoon voorstellen
  • Er zijn tal van vormen waarop een overlijdensdatum toegevoegd kan worden.
  • In een parameter is relatief eenvoudig te detecteren
  • In de lopende tekst is een stuk is lastiger. Een filter dat kijkt naar steekwoorden zou bijvoorbeeld aanslaan op een zin als "Na het overlijden van zijn vrouw verhuisde Jansen naar de Verenigde Staten". Hier kan zelfs een datum in staan, dus hier valt niet op uit te sluiten.
  • Een overlijdensdatum kan worden toegevoegd in de eerste regel tussen haakjes. Dat heeft de vorm (dag maand jaar, plaats - dag maand jaar, plaats). Of de plaats komt eerst. Of men gebruikt een — ipv een normaal streepje. Of men zet niet een dag of een jaar. Of men voegt teksten als "ovrl." of † toe. Of door de zinsstructuur staat er een punt voor de datum (bv. Dr. Jansen (15 januari 1900 - 16 januari 1900), pseudoniem van Karel Karelsen, ...). Of er staan volledige sjablonen zoals {{ziedp}}, {{wiu}} of infoboxes of afbeeldingen voor de datum. Ik kan hier geen zinnige aannames maken, dus om dit te detecteren moet ik data ergens tussen haakjes detecteren.
Het detecteren van een bron is relatief simpel. Dat wil zeggen: Het filter slaat aan op het moment dat er geen nieuwe links worden toegevoegd aan de pagina en er geen links in de samenvatting staan. Ik zie niet zo snel een filter dat geen of weinig valspositieven heeft en nog steeds nuttig is, tenzij we uitsluitend de sjabloonparameters checken. De vraag is dan: Hoeveel anoniemen vullen een sjabloon eerder in dan de normale tekst. Sum?urai8? 22 feb 2021 22:07 (CET)
Vriendelijk bedankt voor deze mooie toelichting, dit geeft iets beter inzicht in wat wel en niet kan! Josq (overleg) 22 feb 2021 22:29 (CET)
Ik zie niet hoe ik hier een nuttig filter van kan maken, dus voor nu Niet uitgevoerd Niet uitgevoerd. Sum?urai8? 22 mrt 2021 22:30 (CET)


DTB4l[bewerken | brontekst bewerken]

Status: Actief

bewerken · geschiedenis · logboeken · testen
  • Toevoegen aan scheldwoordenlijst, gezien Urban Dictionary: DTB4l
    • Is er trouwens een speciale pagina om ongewenst taalgebruik te nomineren voor toevoeging aan de filterlijst? →bertux 9 apr 2021 19:06 (CEST)
      • Uitgevoerd Uitgevoerd Toegevoegd. Er is alleen deze pagina om bestaande filters aan te passen.