Wikipedia:Misbruikfilter/Verzoekpagina filters/Archief/2009

Dit is een archiefpagina, niet bewerken

Verwijderen verwijdersjablonen

Status: Actief

bewerken · geschiedenis · logboeken · testen

Via dit filter wordt het nu geregistreerd wanneer een nieuwe gebruiker een verwijdersjabloon verwijderd. Ik stel voor een duidelijke waarschuwing (of hier eigenlijk een bericht) te geven bij deze handeling. Kan er gecontroleerd worden of en welke verwijdersjablonen ik vergeten ben? - _LolSimon -?- 19 mei 2009 01:10 (CEST)

Zo te zien kunnen {nuweg}, {reclame} en {auteur} er nog bij. Pompidom 19 mei 2009 10:03 (CEST)

Grens verhoogt van 4 dagen (autoconfirmed) naar 15 dagen, vooral door de lengte van de verwijderprocedure en omdat de meeste gebruikers van <15 dagen ook weinig ervaring hebben. Het lijkt me gewenst dat er voor dit filter een apart sjabloon komt, met uitleg. Evt. zal ik dat wel binnekort doen. - _LolSimon -?- 19 mei 2009 20:40 (CEST)

Ter informatie: inmiddels heb ik bij dit filter een waarschuwing (of mededeling) aangemaakt. Om deze te bekijken, zie Sjabloon:Misbruikfilter-waarschuwing-verwijdersjabloon. Verbeteringen zijn van harte welkom. _LolSimon -?- 20 mei 2009 00:57 (CEST)

 Uitgevoerd waarschuwing ingeschakeld: dit filter heeft 1 week zonder grote veranderingen in log-only gedraaid. Er zijn geen bezwaren tegen het filter geuit. De (hierboven vermelde) waarschuwing (mededeling) is bij deze ingeschakeld. _LolSimon -?- 26 mei 2009 01:37 (CEST)

En dan toch deed deze edit het filter ten onrechte afgaan. Ik heb het filter aangepast zodat alleen op {{ne}} met ook twee sluitende accolades wordt gereageerd. Lymantria _overleg 27 mei 2009 16:08 (CEST)

Er zijn ook enige "weg"-sjablonen zoals {{WegESblauw}} en dergelijke. Geeft dat wellicht ook vals-positieven bij verwijdering of aanpassing? Zo ja, dan graag overal die accolades sluiten, want dan is niet te overzien wat er wellicht in de toekomst nog wordt toegevoegd en ten onrechte wordt afgevlagd. paul b 27 mei 2009 19:27 (CEST)

 Uitgevoerd via een regex. Lymantria _overleg 27 mei 2009 20:42 (CEST)

Voorbeeldtekst van bewerkknoppen

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleert of een gebruiker de voorbeeldteksten afkomstig van de edit toolbar heeft aangepast.

Voorbeelden van bewerkingen die het filter opmerkt: [1], [2], [3]

• Waarom: Komt voor met vandalisme, bij nieuwe gebruikers, en bij het per ongeluk klikken op een bewerkknop zonder dat je het doorhebt.
• Gevolgen: Waarschuwen of verhinderen
• Voorwaarden:

(article_namespace == 0) &
(contains_any(added_lines, 
"'''Vetgedrukte tekst'''", 
"''cursieve tekst''", 
"== Deelonderwerp ==", 
"[[Bestand:plaatje.png]]", 
"[[Media:Voorbeeld.ogg]]", 
"<nowiki>Voer hier de niet op te maken tekst in</nowiki>"
))

Larzzz 18 mei 2009 14:54 (CEST)

 Uitgevoerd. Aangemaakt als id2 in log only. Alleen heb ik in de laatste regel <nowiki> en </nowiki> weggelaten, voor het geval iemand een paar keer achter elkaar op die knop drukt. nl:Mark W (Mwpnl) ¦ talk 19 mei 2009 01:58 (CEST)

Zijn dat de enige onderdelen die verkeerd ingevoegd kunnen worden? Ik mis denk ik: [[Onderwerp]] + [http://nl.wikipedia.org WikipediaNL] + <math>a^2 + b^2 = c^2</math> - Romaine (overleg) 19 mei 2009 12:49 (CEST)

Dat kunnen gewenste toevoegingen zijn. Het artikel Onderwerp bestaat, en ieder mag er naar linken. Michiel1972 19 mei 2009 14:54 (CEST)

Daarom heb ik ze er inderdaad niet bijgezet. Mark, het maakt niet uit hoe vaak je op die knop drukt, het zal altijd de tekst <nowiki>Voer hier de niet op te maken tekst in</nowiki> bevatten. Larzzz 19 mei 2009 15:52 (CEST)

Je hebt gelijk. Stom. Ik vergeet steeds dat ik die knopjes ietwat getweaked heb. Aangepast. nl:Mark W (Mwpnl) ¦ talk 19 mei 2009 15:55 (CEST)

Bij gevolgen staat hier Waarschuwen of verhinderen. Lijkt me verstandig het hier nog over te hebben. Zelf denk ik dat dit een van de weinige is waar verhinderen wel kan. Akoopal _overleg 24 mei 2009 11:00 (CEST)

Het lijkt mij beter nog niet zo snel met verhinderen te beginnen, eerst testen in log-only en dan misschien nog wat langer met waarschuwen testen. - Bas 24 mei 2009 11:43 (CEST)

 Uitgevoerd Filter heeft een week zonder wijzigingen gedraaid, en voldoet. Waarschuwing ingeschakeld middels dit sjabloon. Lymantria _overleg 26 mei 2009 16:19 (CEST)

Verwijderen vandalismedossier

Status: Nooit aangemaakt

Aanmaken filter · batchtesten

• Taak: Controleer of een anonieme gebruiker zijn dossier wil verwijderen.
• Waarom: Dit gebeurt volgens mij regelmatig. Zo niet, dan ben ik zelf tegen dit filter.
• Aanmaken filter · batchtesten
• Gevolgen: Enkel waarschuwen
• Voorwaarden:

!("autoconfirmed" in user_groups) & article_namespace == 3 & 
action == "edit" & user_name in article_text & lcase(removed_lines) rlike "\{\{([Ww]s|[Ww]aarschuwing|[Ww]aarschuwing-anoniem|[Ww]aarschuwing-gebruiker|[Ww]s-organisatie|[Ww]s-hogeschool|[Ww]s-school|[Zz]b|[Zz]andbak|[Pp]br|[Pp]uber|[Bb]rp|[Bb]erisping)(\|.+?|)\}\}"

Eventueel kun je hier ook controleren of er veel tekst is verwijderd, maar dat lijkt me overbodig. --Erwin 16 mei 2009 19:58 (CEST)

De regex kan overigens nog beter gegroepeerd worden. Dat is simpelweg een kwestie van de benodigde tijd monitoren om te zien wat de snelste (en dus beste) variant is. (Al neem ik aan dat een variant als "\{\{([Ww]aarschuwing(|-(anoniem|gebruiker))|[Ww]s(|-(organisatie|hogeschool|school))|[Zz]b|[Zz]andbak|[Pp]br|[Pp]uber|[Bb]rp|[Bb]erisping)(\|.+?|)\}\}" sneller is.) --Erwin 16 mei 2009 20:17 (CEST)

Het is in dit geval overigens niet nodig om de hoofdletter-alternatieven in de regex op te nemen, omdat je vergelijkt met lcase(). MrBlueSky 17 mei 2009 00:00 (CEST)

Dankje, daar wees Mark me ook al op en het is inderdaad overbodig. --Erwin 17 mei 2009 11:56 (CEST)

Ik vraag me overigens af hoe wenselijk dit filter is. Het komt toch nog voor dat IP-gebruikers een waarschuwing gelezen hebben en deze vervolgens verwijderen. In hoeverre moeten we dat willen tegenhouden of voorkomen? Waarschuwing gelezen=waarschuwing gelezen. Die hoeft dan niet tot het einde ter tijden te blijven staan denk ik. nl:Mark W (Mwpnl) ¦ talk 19 mei 2009 23:41 (CEST)

Tot nu toe is toch de afspraak dat het dossier hoort te blijven staan, omdat het een vandalismebestrijder info geeft over de geschiedenis. Zolang dit min of meer de regel is, vind ik dit filter eigenlijk wel een goed idee, het gaat toch alleen om waarschuwen. Wat mij betreft testen om te kijken of het vaak gebeurd. Akoopal _overleg 20 mei 2009 00:07 (CEST)

Ook hier: Deze vandalismedossiers zijn ooit bedacht. Ze zijn niet verplicht en iedereen mag ze weghalen, als je daar anders over denkt moet je eerst maar een richtlijn invoeren die dat ondersteunt. tot die tijd dus ook geen automatische straf-acties tegen dingen die dus helemaal niet 'strafbaar' zijn. Fontes 21 mei 2009 00:52 (CEST)

Niet alle mores hoeven tot in elk detail vastgelegd in regels. Echter, als iemand één enkele waarschuwing krijgt, vervolgens nuttig bijdraagt, zal het niet als probleem ondervonden worden als deze na enkele maanden het sjabloon verwijderd. Er zijn dus situaties te bedenken waarin zo'n sjabloonverwijdering niet ongewenst is. Het filter moet dus of enkel waarschuwen, of bij onmogelijk maken wel duidelijk vermelden tot wie de persoon zich kan wenden om het sjabloon weg te laten halen. CaAl 21 mei 2009 10:23 (CEST)

Enkele maanden? Dus als een of ander opdondertje mij als 'anonieme' goedwillende gebruiker een waarschuwing geeft voor een onbedoelde fout ergens dan moet ik dat ding minstens twee maanden laten staan? Wat een totale bullshit. Dat soort Wikimores zijn achterlijke gebruiken van mensen die vrijwel niets nuttigs toevoegen en graag baasje spelen. Gebruikersoverleggen zijn niet voor 'controleurs' om makkelijk te zien wat iemand al op zijn kerfstok heeft maar om te overleggen. Lekker makkelijk ook om het op Wikigebruiken te gooien, onbeschofte gebruiken horen hier niet, hoe onverschillig men er ook over is gaan denken. Als die onzin er dan wel zo nodig moet staan dan hoor je dat per zaak te beoordelen (of de gebruiker nu echt goedwillend is) en er niet een bot op zetten die de gebruiker toch maar automatisch blijft 'straffen'. Zo vervreemd je nieuwelingen nog meer. Dit filtersysteem kan prachtige dingen doen maar met dit soort halfbakken op zelfbedachte gebruiken gebaseerde onderdelen boort men straks het hele project de grond in en wordt het een gedrocht. Fontes 21 mei 2009 14:18 (CEST)

Dit filter als waarschuwing prima; maar levert het echt iets op? Zal de anon de waarschuwing niet gewoon negeren? In dat geval is het filter enkel overbodige ballast... Fruggo 21 mei 2009 10:48 (CEST)

Bij alle filters die enkel een waarschuwing geven geldt dat de vandaal toch z'n gang kan gaan. Het verschil met geen filter is echter dat die vandaal al een automatische waarschuwing op zak heeft, en dus een bijdrage eerder geblokkeerd kan worden (als het zo ver moet komen). CaAl 21 mei 2009 16:29 (CEST)

Niet aangemaakt vanwege twijfels over wenselijkheid. --Erwin 26 mei 2009 22:50 (CEST)

Links naar ongewenste websites

Status: Nooit aangemaakt

Aanmaken filter · batchtesten

• Taak: Verwijderen van links naar ongewenste websites
• Waarom: We hebben geen behoefte aan links naar startpagina e.d.
• Gevolgen: Waarschuwen en Verhinderen

Het gaat om goedbedoelde, maar vrijwel altijd nutteloze links naar websites die onderdeel uitmaken van bijv. startpagina (er is een heel rijtje van deze sites op te noemen) en die vrijwel zonder uitzondering nauwelijks iets aan het artikel toevoegen. Binnen bronnensjablonen zouden ook links naar andere wiki's en andere sites die niet als bron gebruikt kunnen worden, gefilterd kunnen worden. Quistnix 21 mei 2009 11:36 (CEST)

Linken naar ongewenste externe websites tegengaan kan al langer via MediaWiki:Spam-blacklist. Ik heb geen idee of het beter is om dat via een misbruikfilter te doen of via de ingebouwde spam-blacklist; het lijkt me wel handig om dit allemaal via hetzelfde systeem te doen. CaAl 21 mei 2009 11:50 (CEST)

(na bwc) Links naar andere wiki's zijn momenteel een veelvoorkomend iets op lemma's, er zijn zelfs lang bijdragende gebruikers die bij hun bronnen een anderstalige wiki zetten, iets wat momenteel dus niet echt tegen gegaan wordt zou m.i. niet botmatig gestopt moeten worden. Verder denk ik dat het geheel blokkeren van startpagina links niet gewenst is, een waarschuwing en log zou daarvoor genoeg zijn, ik kan me namelijk voorstellen dat de link gebruikt kan worden op overlegpagina's om mensen naar meer informatie te verwijzen tijdens het opbouwproces, ook kan er bijv. in het artikel Startpagina een link naar startpagina.nl staan. Mvg, Bas 21 mei 2009 11:52 (CEST)

Daar heb je gelijk in. Sommige links (overduidelijke spam naar sexsites ofzo) wil je gewoon blokkeren; bij andere wil je meer uitleg geven. CaAl 21 mei 2009 11:56 (CEST)

Het filter zou alleen in de hoofdnaamruimte moeten werken, natuurlijk. En links naar anderstalige wiki's anders dan permalinks zijn wat mij betreft volslagen waardeloos als bronvermelding - Quistnix 21 mei 2009 12:01 (CEST)

Als MediaWiki:Spam-blacklist voldoet, dan lijkt een filter me overbodig. Twee systemen voor hetzelfde is alleen maar verwarrend. Overigens vind ik startpagina's juist een voorbeeld van sites die niet automatisch geblokkeerd hoeven te worden; deze kunnen - ook in de hoofdnaamruimte - wel degelijk nuttig zijn. Fruggo 21 mei 2009 12:10 (CEST)

Geef van dat laatste dan 1 voorbeeld - Quistnix 21 mei 2009 12:21 (CEST)

Weet je wat, ik geef je er zelfs twee: Startpagina.nl en Startpagina.be :) Fruggo 21 mei 2009 15:07 (CEST)

Da's mooi. De naam komt dus ook in de artikelnaam voor. Als je met niets anders komt, lijken mij hiermee de randvoorwaarden voor het opnemen van een link naar startpagina in een artikel compleet - Quistnix 21 mei 2009 15:12 (CEST)

Bijvoorbeeld: Linkpagina, Start.be, Kunsttaal, Massively multiplayer online role-playing game, en als bron (maar daar is het filter waarschijnlijk op in te stellen?) op Willem Pince van der Aa. Fruggo 22 mei 2009 19:03 (CEST)

Dit filter lijkt mij wel een goed idee omdat je er, in tegenstelling tot de blacklist, meer condities aan kunt verbinden. Zoals het voorbeeld van Quistnix hierboven: een link wel toestaan als de site overeenkomt met de artikelnaam. MrBlueSky 21 mei 2009 15:29 (CEST)

Een filter dat dient om slechts waarschuwingen bij bepaalde sites te geven i.p.v. direct tegenhouden kan zeker nuttig zijn, echter een filter dat het overal verbiedt behalve op 2 pagina's lijkt mij niet goed, ik denk dat er meerdere pagina's te bedenken zijn waar dit wel eventueel nuttig kan zijn. - Bas 21 mei 2009 17:42 (CEST)

Volgens mij is dit juist geen goed idee. Filters worden bij alle pagina's - ook buiten de hoofdnaamruimte - aangeroepen. Hoewel we via condities beperkingen kunnen opleggen, is het denk ik niet verstandig om filters te gaan maken die niet op bepaalde pagina's worden aangeroepen. Zeker niet als er al functies ( zoals de blacklist ) zijn, die deze functies al bieden. In theorie zouden we dmv. filters ook gebruikers kunnen verhinderen bepaalde pagina's te bewerken, maar om daarvoor een filter in te stellen dat op álle bewerkingen reageert... nee, bedankt. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 21:31 (CEST)

Niet aangemaakt, omdat we een m:Spam blacklist en MediaWiki:Spam-blacklist hebben. --Erwin 26 mei 2009 22:50 (CEST)

Geen bewerkingssamenvatting

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: Reageert op het oningevuld laten van de bewerkingssamenvatting.
• Waarom: Samenvatting is belangrijk voor het snel beoordelen van wat er in een edit is gebeurd, en wordt makkelijk vergeten. Niet serieuze bijdragers vergeten helemaal vaak de samenvatting in te vullen.
• Gevolgen: Vriendelijk "Waarschuwen" middels Sjabloon:Misbruikfilter-waarschuwing-geensamenvatting
• Voorwaarden:

(length(summary) == 0)

Lymantria _overleg 23 mei 2009 12:56 (CEST)

Als je de samenvatting leeg laat, krijg je toch al een waarschuwing? Krijg je er met dit filter dan twee, en zo ja, wat is de meerwaarde van twee waarschuwingen boven één waarschuwing? Fruggo 23 mei 2009 13:08 (CEST)

Blijkbaar dus niet. Het zou mij sterk verwonderen als dit afhangt van een modbitje. Annabel_(overleg) 23 mei 2009 14:22 (CEST)

Je kunt die waarschuwing uitzetten in je voorkeuren. Daarom lijkt dit filter mij niet zo'n goed idee, althans niet voor ingelogde gebruikers. Het filter klaagt ook over het grote aantal hits (12%!), en heeft zichzelf uitgeschakelt (hoewel er dan blijkbaar nog steeds gelogt wordt). MrBlueSky 23 mei 2009 14:35 (CEST)

Volgens mij kunnen gebruikers in hun voorkeuren aangeven dat zij gewaarschuwd willen worden als zij geen bewerkingssamenvatting geven, ik vraag me af of je dat dus verplicht moet stellen als dat ook een keuze is. Er is nergens een regel die aangeeft dat je bewerkingssamenvattingen moet geven, het is iets wat mag, je moet dus niet gewaarschuwd worden als je de keuze maakt om de samenvatting niet in te vullen. Ik ben dus tegen dit filter. - Bas 23 mei 2009 14:38 (CEST)

Ik ook. Er lijkt ook geen filter voor nodig te zijn, we hebben immers al Mediawiki:missingsummary. Bij kleine wijzigingen vul ik zelf overigens ook geen samenvatting in. Door dit soort dingen te gaan afdwingen krijg je dat mensen een "." of een spatie gaan gebruiken om het filter maar te kunnen omzeilen. nl:Mark W (Mwpnl) ¦ talk 23 mei 2009 15:07 (CEST)

Het lijkt me inderdaad niet gewenst nu ik dit allemaal zie, maar dat men per definitie bij kleine bewerkingen niets invult (en dan nog door moderatoren) is evenmin gewenst. Wat dat laatste betreft is bijvoorbeeld de afkorting "sp" van spelling, typo en fix, ook een goede samenvatting. Annabel_(overleg) 23 mei 2009 15:18 (CEST)

Niet uitgevoerd Was me er niet van bewust dat ik die waarschuwing in mijn instellingen had uitgezet. Misschien moet de default eens op "aan" gezet worden. Filter verwijderd. Lymantria _overleg 23 mei 2009 15:23 (CEST)

Een voorstel om de default om te draaien is een goed idee. - Bas 23 mei 2009 17:48 (CEST)

Mee eens. Ik vergeet vaak een bewerkingssamenvatting in te vullen, terwijl ik in principe wel altijd iets wil neerzetten. Pas als de pagina is opgeslagen, zie ik dan dat ik dat vergeten ben - Quistnix 23 mei 2009 17:53 (CEST)

Verplaatst naar afgehandelde verzoeken. Wat mij betreft mag de default inderdaad omgedraaid worden, maar daarvoor moet je ergens anders in overleg treden. --Erwin 26 mei 2009 22:50 (CEST)

Meer dan 8 medeklinkers aaneen

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleren of een gebruiker een rij van meer dan 8 medeklinkers aaneen toevoegt in de Hoofnaamruimte
• Waarom: Nederlandse woorden bevatten maximaal 8 medeklinkers aaneen - indicator van geoefen
• Gevolgen: Waarschuwen, bij gebleken geschiktheid mogelijk ook voorkomen
• Voorwaarden:

(article_namespace == 0) &
(added_lines rlike "[BbCcDdFfGgHhJjKkLlMmNnPpQqRrSsTtVvWwXxZz]{9}") &
!(all_links rlike "[BbCcDdFfGgHhJjKkLlMmNnPpQqRrSsTtVvWwXxZz]{9}") &
!contains_any(lcase(added_lines), "smiles", "inchi")

Nederlandse woorden bevatten maximaal 8 medeklinkers aaneen (bijv. angstschreeuw). Bij het willekeurig intypen op de middelste rij van het toetsenbord ontstaat makkelijk een langere rij medeklinkers. Dit geoefen kan worden gefilterd. Lymantria _overleg 21 mei 2009 13:59 (CEST)

En max. 7 klinkers? (ik denk dan aan "koeieuier", al is dat in de nieuwe spelling wel veranderd) - Quistnix 21 mei 2009 15:02 (CEST)

Hmm, oeioeioei in artikel De Zwarte Voeten... Lymantria _overleg 21 mei 2009 15:47 (CEST)

Er zijn gevallen (geen Nederlandse woorden) waarin het wel gebruikt kan worden. Brfxxccxxmnpcccclllmmnprxvclmnckssqlbb11116. Dus voorkomen liever niet, waarschuwen kan prima ondanks dit (enige?) geval. - Bas 21 mei 2009 17:34 (CEST)

Jip, de Latijnse nummers zijn zo'n voorbeeld. Annabel_(overleg) 21 mei 2009 17:42 (CEST)

Ook links naar bepaalde pagina's bevatten "code's" welke (bijna) willekeurig gegenereerd worden (zie voorbeeld). Ik vraag me af hoe vaak deze links voor komen, mocht dat vrij regelmatig zijn dan vraag ik me af of waarschuwen (van geregistreerde gebruikers) zelfs niet al te veel is. - Bas 21 mei 2009 17:48 (CEST)

Een ander geval waar vals positieven door kunnen ontstaan: Er wordt vaak bronnen van gebruikers gevraagd. Externe links, die leiden naar een bron, kunnen snel veel medeklinkers achter elkaar bevatten, bijvoorbeeld een externe link naar een boek op Google. Pompidom 21 mei 2009 19:18 (CEST)

Ik heb het filter aangescherpt in de zin dat het filter niet afgaat wanneer er links worden toegevoegd (zie voorwaarden). Lymantria _overleg 21 mei 2009 19:39 (CEST)

Goed punt inderdaad, ik zag dat die al een paar keer is afgegaan. Trouwens - ik heb geen idee - zou bijv. lcase(added_lines) rlike "[bcdfghjklmnpqrstvwxz]{9} sneller of trager zijn dan de bestaande code? nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 22:33 (CEST)

Hoi Mark, ik vermoed trager, omdat lcase een bewerking moet doen op alle tekens. Maar zeker ben ik er niet van. Groetjes, Lymantria _overleg 22 mei 2009 09:22 (CEST)

• Gaat het filter ook af wanneer een gebruiker niet 9 medeklinkers toevoegt maar deze al in het artikel staan? Ik kan namelijk niet vinden wat er hier en hier gebeurd is. - Bas 22 mei 2009 09:12 (CEST)
  • Hoi Bas, Het gaat hier om bewerkingen van alinea's waarin een link staat met een medeklinkerstapel. Kennelijk wordt de hele alinea dan als added_lines opgevat. Maar gek genoeg is de daarin vervatte link geen added_link. Daarom heb ik de uitzonderinsclausule van de link aangepast, zodat het filter nu niet afgaat als er een medeklinkerstapel in willekeurig een link staat in de uiteindelijke tekst. Hopelijk is dat wel afdoende. Lymantria _overleg 22 mei 2009 09:22 (CEST)
    • Hm, lastig. Ik ben in principe niet voor verhinderen, omdat het inderdaad voor kan komen dat een berg medeklinkers nodig is, vooral waar het bepaalde "codes" betreft. Een voorbeeld dat mij zo te binnen schiet is de zogeheten SMILES-notatie voor structuurformules, zie bijvoorbeeld nonaan (CCCCCCCCC) of stearinezuur. paul b 22 mei 2009 12:31 (CEST)

Aangepast zodanig dat SMILES- en InChI-notaties de filter niet triggeren. Ben benieuwd of dit de lengte van uitvoeren significant zal doen toenemen. Annabel_(overleg) 22 mei 2009 12:43 (CEST)

Weet niet was de oude looptijd is, maar met 16ms is hij IMHO wat lang. Mijn gevoel zegt het het kan verbeteren als je de tweede en derde regel omdraait, kan je dat eens proberen? Akoopal _overleg 24 mei 2009 11:08 (CEST)

Gedaan. Was nu 15 ms. Actuele filter hierboven ook ingevoegd. Ik kijk vanavond nog eens, en als het dan nog ongeveer even lang is, dan probeer ik ook of lcase helpt (suggestie Mark hierboven). Lymantria _overleg 24 mei 2009 12:50 (CEST)

9 ms is al best wel netjes, maar het is denk ik evengoed even een leuke test om hem een tijdje met lcase te laten draaien. Ik denk wel dat het sneller kan zijn, omdat het de reguliere expressie daarna halveert. Akoopal _overleg 27 mei 2009 20:34 (CEST)

Dat heb ik, zoals beloofd, al een tijdje gedaan. Meteen schoot de tijd weer naar 15/16 ms. Lymantria _overleg 28 mei 2009 07:25 (CEST)

Ik heb het volgende sjabloon als waarschuwing aangemaakt: Sjabloon:Misbruikfilter-waarschuwing-medeklinkers. Lymantria _overleg 28 mei 2009 18:49 (CEST)

 Uitgevoerd Het filter draait zonder grote wijzigingen nu een week. Ingeschakeld met waarschuwin zoals hierboven. Lymantria _overleg 29 mei 2009 09:24 (CEST)

Weghalen alle interwikilinks

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Waarschuwen bij verwijderen van alle interwikilinks door nieuwe en oningelogde gebruikers
• Waarom: Het is niet iedere nieuwe gebruiker duidelijk wat die codes in een tekst doen
• Gevolgen: Waarschuwen

Wanneer alle interwikilinks door een nieuwe gebruiker worden verwijderd, waarschuwen en uitleggen waarvoor die dienen. Quistnix 21 mei 2009 15:00 (CEST)

Deze filter lijkt me handig, maar waarom enkel nieuwe gebruikers? Ook reeds actieve gebruikers kunnen dit per vergissing doen... Een melding zou hen hierin bij kunnen staan. Annabel_(overleg) 21 mei 2009 15:29 (CEST)

 Voor Het gebeurt regelmatig dat nieuwe gebruikers een tekst aan het eind van een artikel toevoegen en daarbij (waarschijnlijk onbedoeld) alle interwikilinks en categorieen verwijderen. En wat Annabel zegt: waarom niet voor alle gebruikers. MrBlueSky 21 mei 2009 15:32 (CEST)

 Voor , maar niet voor gevestigde gebruikers. Ik verwijder regelmatig interwiki-links van pagina's omdat de interwiki's volstrekt onjuist zijn. Ik hoef dan niet zo nodig tegen een betuttelend filter aan te kijken eerlijk gezegd. Nieuwe en oningelogde gebruikers lijkt mee een logische keus. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 15:43 (CEST)

Je zou eventueel ook kunnen waarschuwen voor geregistreerde gebruikers en verhinderen voor niet-bevestigde gebruikers. Annabel_(overleg) 21 mei 2009 15:53 (CEST)

Kan, maar dan heb je twee filters die hetzelfde doen. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 17:10 (CEST)

 Voor ', maar ook voor gevestigde gebruikers. Niet gevestigde gebruikers verwijderen regelmatig interwiki-links van pagina's omdat de interwiki's volstrekt onjuist zijn. Zij hoeven dan niet zo nodig tegen een betuttelend filter aan te kijken eerlijk gezegd. Blijkbaar mogen we niet gevestigde gebruikers wel betuttelen maar is dat bij de kliek gevestigde gebruikers not done. Scheve maatstaven weer.. Fontes 21 mei 2009 16:32 (CEST)

Van niet-gevestigde gebruikers is de kans groter dat ze per ongeluk een fout maken, en vind ik het heel logisch om ze even te vragen of ze zeker weten dat ze alles willen verwijderen. Van gevestigde gebruikers mag je verwachten dat ze weten waar ze mee bezig zijn. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 17:10 (CEST)

Voorlopig heb ik het volgende:

(contains_any(lcase(old_wikitext), "\[\[[\s:]*[\w-]+:[^\]]+\]\]")) &
!(contains_any(lcase(new_wikitext), "\[\[[\s:]*[\w-]+:[^\]]+\]\]"))

Dit slaat echter ook aan bij het verwijderen van afbeeldingen (meer bepaald met dit slaat de filter alleen aan bij het verwijderen van alle afbeeldingen en interwikilinks). Hier moet nog verder naar gekeken worden, maar het is alvast een begin.

Annabel_(overleg) 21 mei 2009 15:53 (CEST)

Ah, Ik had Annabel's bericht niet gezien, en heb zelf net filter 9 aangemaakt. Die controleert niet op categorieën nog, maar wel op iw's. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 16:26 (CEST)

(rcount("(\[\[[a-z]{2,3}:.*\]\])",removed_lines)>2)

Dit werkt niet waarschijnlijk, omdat het altijd alle iw's als 1 telt. Waarschijnlijk moet je ".*?" gebruiken ipv ".*". MrBlueSky 21 mei 2009 16:32 (CEST)

Het werkt wel ;-) Ik ga geen filter activeren wat niet werkt ;-) maar netjes is anders, de .*? variant werkt - te zien aan erwin's edit aan het filter, snelheidsverhogend! nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 17:10 (CEST)

Deze filter werkt zowieso niet naar behoren. Zie bijvoorbeeld de Chinese interwikis en interwiki's naar eenvoudig Engels: [[zh-classical:角]], [[simple:Cathedral]] en [[be-x-old:Кут]]. Deze zijn eveneens valide. Annabel_(overleg) 21 mei 2009 17:17 (CEST)

Kwestie van {2,3} even aanpassen naar de langst toegestane lengte en [a-z] aanpassen naar bijv. [a-zA-Z-] om ook hoofdletters en de hyphen goed te keuren ^_^. Enig idee wat de langste lengte voor een iw is, kan ik het meteen aanpassen? nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 17:23 (CEST)

Je mag niet naar de lengte van de link kijken, maar naar wat de correcte opmaak is voor een iw-link. Overigens heb ik dit verzoek naar boven verplaatst omdat hier duidelijk nog werk aan is. Annabel_(overleg) 21 mei 2009 17:31 (CEST)

Het filter gaat dus ook af als er slechts een paar iw-links verwijderd worden. Dit gaat veel vals positieven opleveren. Ook staat het blijkbaar in tegenstelling tot de meningen zodanig ingesteld dat alleen nieuwe gebruikers het filter kunnen activeren. Annabel_(overleg) 21 mei 2009 17:32 (CEST)

Klopt het filter gaat nu af als er twee of meer links worden verwijderd, dit heb ik bewust ingesteld, zodat we de hits kunnen analyseren en naar boven kunnen bijstellen, ik vind het namelijk erg lastig om te beoordelen of we de grens bij 3, 5, 10 of 20 zouden moeten neerzetten.

Wat is volgens jou dan de correcte opmaak van een iw-link? een iw-link bestaat over het algemeen uit taalcode:paginanaam - in kleine letters, waarmee links naar bijvoorbeeld WP:MF worden uitgesloten. Waarbij de taalcode in bijna alle gevallen uit 2 of 3 tekens bestaat. De uitzonderingen kunnen we (a) toevoegen of (b) laten schieten omdat er bij de verwijdering van meerdere iw-links ook een grote hoeveelheid wél standaard iw-links verwijderd zal worden. Een klein aantal: en:List_of_Wikipedias#List is langer dan 3, maar de vraag is of opname daarvan de regex niet vertraagd en of dit het aantal hits inderdaad verhoogd (immers: de kans dat alleen lange talen worden verwijderd, en kleine afkortingen worden laten staan is niet zo groot).

De regex kijkt dus niet naar de lengte van de link, maar naar de lengte van de taalcode, daar kunnen we uitzonderingen aan toevoegen, maar de vraag is of dat relevant is. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 19:06 (CEST)

Ik heb mezelf ook nog die bedenking zitten maken. Alleszins heb ik een kleine aanpassing gedaan. Annabel_(overleg) 21 mei 2009 19:41 (CEST)

Je zou kunnen overwegen om [a-z]{2,3} te vervangen door ([a-z]{2,3}|zh-classical|simple) en eventueel de andere uitzonderingen. Tellen is een aardige optie, maar het voorstel was te waarschuwen als er geen interwiki's meer achterblijven. Ik begreep echter dat het filteren op new_text wat duur is? Akoopal _overleg 21 mei 2009 21:22 (CEST)

Rest ook nog dat er geen reden is om dit filter alleen toe te passen op nieuwe gebruikers. Bij autobevestigde gebruikers wil dit echt ook wel eens voorvallen, meestal als vergissing. Annabel_(overleg) 21 mei 2009 19:41 (CEST)

Hij kijkt nu naar gebruikers jonger dan 15 dagen, jij denkt dat dit te beperkend is en dat het filter op iedereen moet worden toegepast om te voorkomen dat ze misschien een fout maken? Een waarschuwing kan inderdaad genegeerd worden. nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 20:08 (CEST)

Ik vrees dat ik je niet begrijp. Bij nieuwe gebruikers kan je de bewerking weigeren. Als het gaat om waarschuwen, trek je dat best open naar de hele groep. Annabel_(overleg) 21 mei 2009 21:06 (CEST)

Wat ik bedoel te vragen is: Jij ziet liever de beperking voor een bepaalde groep gebruikers verdwijnen, en dat iedereen - anoniem of ingelogd - per definitie een waarschuwing krijgt? — Als ik jou nu goed begrijp zou jij het filter 2x willen toevoegen: 1x voor anonieme gebruikers(=verhinderen) en 1x voor ingelogde gebruikers (=waarschuwen). Dat lijkt me ongewenst, omdat je dan twee keer hetzelfde filter gaat uitvoeren, en dat neemt twee keer zoveel tijd in beslag bij alle bewerkingen, plus je beide filters dan weer moet aanpassen als er een beter algoritme is. Of bedoel jij iets heel anders? nl:Mark W (Mwpnl) ¦ talk 21 mei 2009 21:19 (CEST)

Waar het em dus over gaat is dat het huidige filter niets opbrengt. Ofwel trek je het open naar iedereen (je moet de goedwillende nieuwe gebruikers niet proberen te beteugelen, als je wil waarschuwen dan iedereen), ofwel verhinder je dit voor de niet-autobevestigde gebruikers (als specifieke vorm van vandalisme, zodat vandalismebestrijders ontlast worden). Annabel_(overleg) 23 mei 2009 14:25 (CEST)

Misschien moet het filter ook worden aangepast dat het niet aanslaat wanneer de pagina wordt veranderd in een redirect - of voorkomt een ander filter al dat dit nodig is? - Quistnix 22 mei 2009 07:32 (CEST)

Nee, dus dit heb ik toegevoegd. --Erwin 22 mei 2009 19:24 (CEST)

Na het doorlopen van alle hits twijfel ik over dit filter. Het gros van de terechte hits zullen ook meegepakt worden door het filter dat checkt op een pagina leeggooien. Ook een paar hits die denk ik gepakt worden door het filter om een paragraaf leeg te gooien. Vervolgens zie ik best wel een aantal terechte verwijderen van interwiki's door mensen die blijkbaar vanaf een andere wiki proberen de interwiki's weer te fixen, en die komen juist anoniem binnen als ze SUL niet gebruiken. En dan blijven er misschien een stuk of 4 hits (van de 32) waarvoor dit filter nuttig is. Akoopal _overleg 24 mei 2009 12:45 (CEST)

Het leeghalen van paragrafen is iets dat (nog) niet door andere filters wordt gedetecteerd. Het geheel leegmaken van de pagina wordt wel door een ander filter gedetecteerd en dit filter hoeft wat mij betreft daarop niet aan te spreken. Voor de rest zie ik nog te weinig hits om te kunnen oordelen over de bruikbaarheid van het filter - Quistnix 26 mei 2009 17:37 (CEST)

We kunnen het nog even afwachten, maar ik ben het op zich met Akoopal eens. Dit filter heeft te veel fout-positieven en weinig echte positieven. --Erwin 26 mei 2009 22:50 (CEST)

De fout-positieven zijn grotendeels vandalistisch van aard. Met uitzondering van het leeghalen van een pagina (waarop de controle het werk van een ander filter is en waarop dit filter niet hoeft te controleren) zie ik geen andere filters die daarop aanspreken. Ik heb nog steeds onvoldoende hits gezien om verdere conclusies te kunnen trekken - Quistnix 27 mei 2009 00:41 (CEST)

Dit misbruikfilter is bedoeld om vandalisme tegen te gaan. Hoewel theoretisch vertrouwde gebruikers kunnen gaan vandaliseren, denk ik dat vertrouwde gebruikers niet door het misbruikfilter gewaarschuwd moeten worden. Dit misbruikfilter is bedoeld om vandalisme te bestrijden, en niet om normale activiteiten van gebruikers te bemoeilijken. Dus met dit filter zouden we ons moeten richten op de doelgroep die een hoog risico vormen betreft deze ongewenste activiteit. Romaine (overleg) 27 mei 2009 01:07 (CEST)

Juist bij interwiki's worden er af en toe edits gedaan door anoniemen, die ervaren gebruikers zijn op een andere wiki, maar geen SUL gebruiken, en proberen een probleem met interwiki's te fixen. Ik had het idee dat een aantal hits van dit soort gevallen waren. Zodoende heb ik nog steeds mijn twijfels bij dit filter. Als we het al doen, dan hooguit waarschuwen. Akoopal _overleg 27 mei 2009 11:51 (CEST)

 Uitgevoerd Waarschuwingsmodus geactiveerd. De filter lijkt goed te werken. Indien er verder geen problemenoptreden, zoudeb later de gecontesteerde bewerkingen nog verhinderd kunnen worden. Annabel_(overleg) 31 mei 2009 22:18 (CEST)

Ongewenste woorden: seksuele schuttingtaal

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleert of een niet-autoconfirmed gebruiker bepaalde ongewenste woorden gebruikt - in dit geval "neuk(en)", "fuck", "kut" en "lul".
• Waarom: Voorkomen dit type vandalisme - het lijkt verstandig om dit type filters met een beperkt aantal woorden tegelijk te doen, ten behoeve van het bijhouden/testen van valspositieven.
• Gevolgen: Waarschuwen
• Aanmaken filter · batchtesten
• Voorwaarden:

!("autoconfirmed" in user_groups) & 
(contains_any(lcase(added_lines), 
"neuk", "fuck", "lul", "kut" ))

Lymantria _overleg 19 mei 2009 08:41 (CEST)

• • Volgens mij (maar dit weet ik niet zeker) kijkt contains_any enkel of parameters 2, 3, ... voorkomen als substring van parameter 1. Een (nuttige) bijdrage doen over Neukirchen is dus bijvoorbeeld niet mogelijk daar neuk in dat woord zit. Mocht mijn vermoeden kloppen, lijkt de volgende code me beter:

!("autoconfirmed" in user_groups)  & case(added_lines) rlike "\b(neuk|fuck|lul|kut)\b"

CaAl 19 mei 2009 12:34 (CEST)

Maar ik wil neuken wel uitsluiten. Dan zou kunnen

!("autoconfirmed" in user_groups) & (lcase(added_lines) rlike "\b(neuk(en)*|fuck|lul|kut)\b")

Lymantria _overleg 19 mei 2009 13:44 (CEST)

Ik ben erg tegen dit filter (of elk ander filter dat op woorden filtert). Als je woorden niet in een context leest (en reguliere expressies kunnen bijna per definitie niet de context begrijpen) kun je niet vaststellen of woorden als schuttingstaal gebruikt worden. Of mogen niet-ingelogde gebruikers straks geen bewerkingen meer doen op de pagina's: Neuk!, Neuken doe je zo, Fuck, Fuck Armageddon... This Is Hell!, Fuck The System, Fuck Wit Dre Day, Holy Fuck, Al Kut, LUL (band), De Dikke Lul Band, etc, etc, etc. Hoopje 20 mei 2009 00:13 (CEST)

Om de grenzen af te tasten, kan je er wel mee leven als het filter alleen waarschuwd? Dan kan de anoniem gewoon editten alleen moet hij zijn edits bevestigen. Akoopal _overleg 20 mei 2009 00:21 (CEST)

Aangezien alle scheldwoorden ook niet als scheldwoord gebruikt kunnen worden, lijkt me waarschuwen in ieder geval het maximum dat dit filter zou mogen doen. Ik vraag me wel twee dingen af:

• Hoeveel welwillende gebruikers worden door zo'n waarschuwing afgeschrikt?
• Hoeveel niet-welwillende gebruikers gaan na het lezen van die waarschuwing gewoon door met het toevoegen van scheldwoorden?

Hoopje 20 mei 2009 00:32 (CEST)

Ik ben ook tegen het gebruik van het filter voor dit soort zaken. Wae®th^tm©2009 | overleg 20 mei 2009 02:40 (CEST)

Ik snap de bezwaren (al kunnen de betreffende artikelen in het filter nog bewerkt worden, het gaat om de toegevoegde tekst). Zouden deze niet ondervangen worden als we ervoor zorgen 1. dat het filter niet te laten afgaan als het woord ook in de oude tekst of titel voorkwam [ !(lcase(old_wikitext) rlike "\b(neuk(en)*|fuck|lul|kut)\b") & !(article_text) rlike "\b(neuk(en)*|fuck|lul|kut)\b" ] 2. dat het filter niet werkt bij een nieuw artikel [ !(action == "create)" ]? Lymantria _overleg 20 mei 2009 09:03 (CEST)

Het lijkt me niet zonder meer een goed idee dit filter in te voeren, tenzij er slechts gewaarschuwd wordt (en ook dan is het wellicht over de rand). Het is namelijk mogelijk deze woorden op een bona fide manier te gebruiken. Met een automatische waarschuwing wordt het in ieder geval al makkelijker om vandalen lik op stuk te geven: ze zijn immers al gewaarschuwd bij het opslaan. paul b 20 mei 2009 10:02 (CEST)

De schade die Wikipedia ondervindt door vandalisme met schuttingtaal acht ik zeer aanzienlijk, de kans dat welwillende gebruikers door zo'n waarschuwing worden afgeschrikt acht ik zeer klein. Ik zie veel in Paul B's redenering dat een waarschuwing bij het opslaan een lik-op-stukbeleid vergemakkelijkt. Josq 20 mei 2009 10:30 (CEST)

De schade door vandalisme met schuttingstaal is nihil. Vandalistische bewerkingen met schuttingstaal worden in de regel binnen vijf minuten (met de hand) ongedaan gemaakt. En ik verwacht juist dat welwillende gebruikers (die blijkbaar interesse hebben in Wikipedia, anders zouden ze niet proberen informatie toe te voegen) meer door blokdreigingen worden afgeschrikt dan onwelwillende gebruikers. Al met al denk ik dat je heel voorzichtig moet zijn met zulke "inhoudelijke" filters. Gedane bewerkingen kunnen heel makkelijk ongedaan worden gemaakt, maar niet gedane bewerkingen zijn veel lastiger gedaan te maken. Hoopje 20 mei 2009 11:39 (CEST)

Paul slaat de spijker op z'n kop. Het filtermatig verbieden is ongewenst, omdat ook aardig wat niet-vandalistische edits niet meer kunnen. Ik denk niet dat goedwillende gebruikers massaal afgeschrikt worden als er een venstertje komt met "u zei piemel. dat woord wordt vaak gebruikt door kliederaars. als u er zeker van bent dat uw bijdrage nuttig is, klik ok". De vandalen kunnen nog steeds hun vandalisme plegen, maar er hoeft niet meer eerst een massaal waarschuwingslogboek gebouwd: de ws hebben ze al gehad, de kleuter kan gelijk geblokkeerd. CaAl 20 mei 2009 14:27 (CEST)

Eens met CaAl, denk niet dat een goedwillende gebruiker van die waarschuwing schrikt, en eerder denkt 'wat grappig, en goed dat ze erop checken', en er niet door afschrikt. Akoopal _overleg 20 mei 2009 16:34 (CEST)

(na bwc) Er lijkt toch iets minder bezwaar te zijn tegen waarschuwen. Dat hangt natuurlijk ook af van de tekst van de waarschuwing, die moet heel duidelijk zijn dat er geen bezwaar is tegen opslaan als het wel 'ok' is, maar duidelijk waarschuwen dat als het wel geklieder is er een waarschuwing en een block kan volgen. Ik denk dat dat de gemiddelde puber wel afschrikt. Het lijkt me voor de input nuttig dat deze geïmplementeerd word, en iemand de tijd neemt om te kijken wat hij over bijv. de afgelopen maand aan edits gedaan zou hebben. Omdat je alleen waarschuwt zou ik persoonlijk een maximaal 10% aan vals positieven aanvaardbaar vinden.

Kleine opmerking over de code, neuk(en)* kan je vervangen door neuk(en)? aangezien je niet hoeft te testen op het herhalen van de en. Akoopal _overleg 20 mei 2009 10:35 (CEST)

Het *-teken staat voor nul of meer keer. Een alternatief is "neuk[ten]*" die ook neukt/neukten/neukte/neuke e.d. afkeurt. Ik heb mijn voorstel aangepast tot alleen waarschuwen, niet tegenhouden. Lymantria _overleg 20 mei 2009 13:27 (CEST)

Ja, dat weet ik. Het vraagteken staat echter voor 0 of 1 keer, en dat is denk ik wat je wilt. Jouw alternatief is ook nog wel aardig. Akoopal _overleg 20 mei 2009 16:23 (CEST)

Zoiets als: De tekst die u gaat opslaan bevat vermoedelijk Schuttingtaal. Als u ervan overtuigd bent dat de tekst niet beledigend bedoeld is slaat u hem dan vooral op. Door op opslaan te drukken stelt u zichzelf verantwoordelijk voor de tekst. Blijkt deze alsnog beledigend bedoeld te zijn dan kan u de toegang tot het bewerken van deze site ontzegd worden Wae®th^tm©2009 | overleg 20 mei 2009 11:20 (CEST)

Lijkt mij een prima voorstel. Fontes 20 mei 2009 20:06 (CEST)

Ik vind ook dit voor een welwillende gebruiker wel heel erg streng ("kan u de toegang ontzegd worden"); als ik hier net kwam kijken zou ik er door afgeschrikt worden. En bij een waarschuwing klikt de vandaal toch wel door. Een filter als dit richt dus meer schade aan dan dat 'ie iets oplevert ben ik bang. Liever niet invoeren dus, ook niet als waarschuwing. Fruggo 21 mei 2009 10:45 (CEST)

Ik lees hierboven weinig de afweging tussen "een lezer leest op een pagina schuttingtaal, en wordt afgeschrikt om wikipedia serieus te gebruiken" en "een bijdrager wil een serieuze bijdrage doen waarin een woord zit dat als schuttingtaal kan worden opgevat, en laat zich afschrikken". Ook als schuttingtaal maar vrij kort op een pagina staat, kan dat toch tot een lezershit leiden. Bij de woorden hierboven schat ik deze schade aan wikipedia als ernstiger in dan het afschrikeffect van een (niet vaak voorkomende) waarschuwing bij een ten onrechte toegepast filter. Lymantria _overleg 21 mei 2009 13:32 (CEST)

Ohh, je mag geen shit zeggen van het filter. Hoe durf je... :-) Dit zijn gewoon niet zulke nuttige uitvindingen. Technische innovaties zijn alleen nuttig als ze iets verbeteren wat nu misgaat. Zie ook de kroegdiscussie. Mig de Jong 21 mei 2009 16:31 (CEST)

Een andere mogelijkheid is om filters zoals deze niets te laten doen: niet blokkeren, geen waarschuwing. Gebruikers merken dan niks, goedwillende gebruikers worden niet afgeschrikt, vandalisten worden niet aangemoedigd om inventiever te worden. Vervolgens kun je dan de log van het filter gebruiken als een soort "lijst van edits die aandacht nodig hebben". Je zou bijvoorbeeld een link naar de log toe kunnen voegen op Wikipedia:Controlelijst vandalismebestrijding. Vandalismebestrijders kunnen dan, voor ze een dagdeel aanpakken, eerst deze edits checken, vervolgens op de pagina noteren wanneer ze dit gedaan hebben. Dit zou ervoor kunnen zorgen dat dit soort edits, die in de praktijk toch vaak vandalisme zijn, meerdere keren per dag gecheckt worden zonder dat je daar gebruikers mee lastig valt. Met dit systeem hoef je niet bang te zijn voor valse positieven en kun je makkelijker woorden en zinsconstructies toevoegen. Dit zou er toe kunnen leiden dat een edit als deze niet anderhalve week blijft staan! Of dat die kans iig kleiner wordt. MrBlueSky 22 mei 2009 14:20 (CEST)

 Uitgevoerd Tijd om hem te testen in log only-modus. Het filter controleert ook of de woorden niet in de oude tekst staan. Lymantria _overleg 22 mei 2009 08:41 (CEST)

• Hee je kan niet zomaar iets invoeren als een grote groep tegen is! Wae®th^tm©2009 | overleg 22 mei 2009 18:32 (CEST)
  • Inderdaad; kan dit filter weer uitgezet worden aub? Fruggo 22 mei 2009 19:10 (CEST)
    • Zolang het filter in log-only staat gebeurd er effectief niet. Volgens de regels kan het tijdens de discussie aangezet worden, dan kan je ook goed zien wat het filter uiteindelijk doet, en hoe het zit met vals positieven enzo. Uiteraard kan het filter pas gaan waarschuwen of tegenhouden als er wel consensus over is. Akoopal _overleg 22 mei 2009 19:19 (CEST)
      • Ah dat scheelt, dank voor deze toelichting :) Fruggo 22 mei 2009 19:26 (CEST)
  • Bij het testen blijkt "fuck" teveel tot vals positieven te leiden. Deze heb ik verwijderd. Lymantria _overleg 26 mei 2009 12:33 (CEST)
    • Wat een gelul. Mig de Jong 26 mei 2009 12:45 (CEST)
      • Inderdaad, door een foutje was het er niet uitgehaald, alleen niet meer gecontroleerd of het in de oude tekst stond. Gezien het feit dat het toch vooral vandalismebijdragen filtert, en het voorzichtige waarschuwingssjabloon dat ik voorstel, heb ik het woord fuck toch weer helemaal teruggeplaatst in het filter. Lymantria _overleg 29 mei 2009 09:50 (CEST)

Het zou wel handig zijn als het logboek van het filter ook meteen een linkje zou bevatten met "bewerking ongedaan maken" of ten minste de optie om alleen die wijziging direct te bekijken. Kan zoiets gerealiseerd worden? Is wel zo handig bij vandalismebestrijding. Spraakverwarring 22 mei 2009 19:22 (CEST)

Het filter draait nu een tijdje en pikt er vandalistische bijdragen uit. Ik stel voor om over een paar dagen het filter in te schakelen op waarschuwen met Dit waarschuwingssjabloon. Omdat er discussie over was hieronder graag reacties of dat wel of niet gewenst is. Lymantria _overleg 29 mei 2009 09:40 (CEST)

 Voor Vanuit de scholierenvandalismeterugdraaipraktijk ben ik *heel* blij met dit filter - het scheelt zoveel handmatig terugdraaien en het lijkt me juist ingesteld met dat waarschuwen. MoiraMoira _overleg 29 mei 2009 09:43 (CEST)

 Voor zolang mensen alleen gewaarschuwd worden en de vals positieven dus niet toevoeging van goede informatie belemmeren is het pure winst en scheelt het enorm veel vandalismebestrijdingswerk. JZ85_overleg 29 mei 2009 09:56 (CEST)

In principe  Voor, denk dat waarschuwen best kan helpen, maar vind het voorgestelde sjabloon iets te streng met 'In heel bijzondere gevallen kan dit onderdeel zijn van een serieuze bijdrage'. Liever iets meer uitnodigend formuleren zoals 'Dit kan onderdeel zijn van een serieuze bijdrage waarvoor dit gebruikt moet worden'. Akoopal _overleg 31 mei 2009 23:15 (CEST)

Ik heb de waarschuwingstekst een beetje veranderd. Bijvoorbeeld het "heel" weggelaten voor "bijzondere". Lymantria _overleg 1 jun 2009 09:51 (CEST)

 Uitgevoerd Ingeschakeld in waarschuwingsmodus. Lymantria _overleg 1 jun 2009 09:51 (CEST)

Pagina's leeghalen

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Filter 3 van wp-en. Bewaakt het leeghalen van artikelen (meer specifiek: het vervangen van een artikel met meer dan 500 karakters door een text met minder dan 50 karakters). Geldt alleen voor anonieme en nieuwe gebruikers (zonder autoconfirmed). Een uitzondering wordt gemaakt voor het vervangen van een artikel door een redirect. Ook wordt een uitzondering gemaakt voor gebruikers die het artikel recentelijk bewerkt hebben.
  Typisch voorbeeld van een bewerking die het filter opmerkt: [4].
• Waarom: Het gebeurt regelmatig dat anonieme of nieuwe gebruikers een artikel leeghalen of vervangen door een kreet.
• Gevolgen: In ieder geval waarschuwen, liever nog verhinderen.

MrBlueSky 16 mei 2009 13:04 (CEST)

Het gaat dus om

!("autoconfirmed" in user_groups) & article_namespace == 0 & new_size < 50 & old_size > 500 & !(user_name in article_recent_contributors) & !("#redirect" in lcase(added_lines))

--Erwin 16 mei 2009 19:04 (CEST)

Ingeschakeld in log-only - Dit filter is nu ingeschakeld in log-only. Ik heb wel toegevoegd dat ook bij #doorverwijzing hetzelfde geldt als bij #redirect. Na een week kan er met voldoende steun een gevolg aan worden verbonden. - _LolSimon -?- 19 mei 2009 00:38 (CEST)

Zou ipv een uitzondering voor gebruikers die het artikel recentelijk hebben bewerkt, een uitzondering voor de auteur van het artikel kunnen worden gemaakt? Het gebeurd vaak dat gebruikers eerst een deel vd pagina leeghalen en dan pas de rest. Ook gebeurd het vaak dat auteurs hun eigen pagina direct weg willen. Taketa (overleg) 21 mei 2009 15:31 (CEST)

Eens met Taketa. En wat mij betreft mag het filter ook voor gewone gebruikers worden ingeschakeld: die behoren ook geen pagina's leeg te halen - Quistnix 26 mei 2009 17:44 (CEST)

Zouden we dan niet ook een uitzondering moeten maken voor wanneer mensen {{nuweg}} toevoegen? nl:Mark W (Mwpnl) ¦ talk 26 mei 2009 17:58 (CEST)

Bij een nuweg kan je de inhoud toch gewoon laten staan, er hoeft(/mag) dan niets leeggehaald worden. - Bas 26 mei 2009 18:14 (CEST)

Is soms wel verstandig, als het privacyschendig betreft, voorkom je dat het in de log komt. Akoopal _overleg 26 mei 2009 19:02 (CEST)

Zou je dan niet ipv een uitzondering voor een nuweg sjabloon beter een algemene uitzondering voor een recent artikel kunnen maken? Taketa (overleg) 27 mei 2009 19:25 (CEST)

Nee. Simpelweg omdat het leeghalen van een pagina niet de standaardverwijderprocedure is - Quistnix 27 mei 2009 20:49 (CEST)

Mag ik, gezien het logboek, wat (enkel) destructieve bewerkingen bevat, voorstellen om dit filter niet alleen te activeren, maar ook te activeren met "verhinderen" om te voorkomen dat gebruikers deze actie kunnen uitvoeren? Graag reacties! nl:Mark W (Mwpnl) ¦ talk 28 mei 2009 00:53 (CEST)

 Neutraal Allen destructieve edits gezien - maar liever eerst een fase met waarschuwen. Lymantria _overleg 28 mei 2009 07:24 (CEST)

 Voor Maar wel met een duidelijke uitleg wat de normale verwijderprocedure is voor de mensen met goede bedoelingen erbij - Quistnix 28 mei 2009 08:15 (CEST)

 Voor Maar alleen als er voor nuweg nog een uitzondering komt. Akoopal _overleg 28 mei 2009 09:41 (CEST)

lijkt me ook beter, graag wat langer testen en alle commentaar overwegen, Taketa (overleg) 28 mei 2009 20:06 (CEST)

 Tegen Tegen filters die verhinderen in het algemeen. Hoopje 28 mei 2009 23:21 (CEST)

 Neutraal - Zie Lymantria - MrBlueSky 29 mei 2009 01:22 (CEST)

 Tegen Tegen verhinderen na deze korte testperiode, mocht men verhinderen in willen stellen dan lijkt mij een langere testperiode (met waarschuwen) op zijn plaats. - Bas 29 mei 2009 08:25 (CEST)

 Uitgevoerd. Ik heb het filter conform bovenstaand overleg ingeschakeld voor waarschuwen en daarbij {{nuweg}}, {{speedy}} en {{delete}} bijgevoegd. Het waarschuwingssjabloon is {{Misbruikfilter-waarschuwing-leeghalen}}. Over een weekje kijken of ie effectief genoeg is om te activeren mét verhinderen? nl:Mark W (Mwpnl) ¦ talk 1 jun 2009 17:28 (CEST)

In de meldtekst misschien nog iets opnemen over verplaatsen van pagina's? Akoopal _overleg 1 jun 2009 19:42 (CEST)

Beveilig gebruikerspagina's tegen vandalisme

Status: Nooit aangemaakt

Aanmaken filter · batchtesten

• Taak: Gebruikerspagina's (GP's) kunnen niet meer door oningelogde en nieuwe gebruikers worden bewerkt, behalve als de nieuwe gebruiker de gebruiker zelf is.
• Waarom: In principe mogen alleen de gebruikers zelf hun GP bewerken. Vrijwel altijd zijn oningelogde/nieuwe accounts die dergelijke pagina's bewerken, vandalen die zojuist berispt zijn. Uitzondering moet gemaakt worden voor een nieuwe gebruiker die een GP wil aanmaken. Of, nog drastischer, alleen toestaan dat de gebruiker zelf zijn GP bewerkt. Maar dan kun je geen bloemetjes, sterren o.i.d. achterlaten.
• Gevolgen: Verhinderen

Ik weet nog niet genoeg van dit filter om de syntax voor de reguliere expressie samen te stellen. Robert (overleg) 19 mei 2009 13:13 (CEST)

Er dient normaal onderhoud plaats te kunnen vinden en ook moet een GP genomineerd kunnen worden voor verwijdering als er bv reclame op staat. (Daarnaast zou het de suggestie wekken dat gebruikerspagina's het bezit zijn van een gebruiker (zoals een website dat kan zijn), terwijl alle pagina's op dit project in het beheer zijn van de gemeenschap.) Dus die drastische variant is niet wenselijk. De vraag of dit filter überhaupt wenselijk voor nieuwe gebruikers is laat ik graag aan anderen over. Romaine (overleg) 19 mei 2009 13:36 (CEST)

De eerste variant lijkt me wel een nuttig filter, en onderhoud/sterrenplakkerij blijft mogelijk door geregistreerde gebruikers. Michiel1972 19 mei 2009 14:50 (CEST)

Betekent dit filter dat ik, als ik niet-ingelogd ben, mijn eigen GP niet zou kunnen bewerken? Fruggo 21 mei 2009 10:51 (CEST)

Ja. CaAl 21 mei 2009 11:16 (CEST)

Dit wordt in de regel ook teruggedraait, aangezien het niet zeker is dat het de gebruiker zelf is. Gefröbel op een GP waarbij anoniem de gebruikersinfo van iemand gewijzigd wordt, is mijns inziens ook onwenselijk. Annabel_(overleg) 21 mei 2009 14:54 (CEST)

M.i. overbodig filter. Voorkomt geen schade aan de encyclopedie. Ik vind het hele filteridee al niks, maar als we er ook nog eens dingen mee gaan regelen waarmee m.i. ongevaarlijk vandalisme (dwz niet direct op de inhoud van een lemma betrekkend) gaan dicht regelen... Niels^? 27 mei 2009 01:06 (CEST)

Ongevaarlijk vandalisme terugdraaien kost ook tijd en energie. Michiel1972 27 mei 2009 01:12 (CEST)

Momenteel worden verzoeken van gebruikers om hun gebruikerspaginas te semibeveiligen veelal afgewezen, tenzij er herhaald vandalisme was. Het is een grote verandering in beleid dit filter in te voeren, aangezien je alle GP automatisch semibeveiligt. Is hier genoeg steun voor? Zou dit niet via een peiling getoetst moeten worden ipv op deze pagina waar relatief minder gebruikers kijken? Taketa (overleg) 27 mei 2009 20:07 (CEST)

Hoewel ik het nut van deze inzie denk ik toch dat het verstandiger is deze als niet ingevoerd naar afgehandeld te verplaatsen omdat het toch omstreden is. Akoopal _overleg 28 mei 2009 19:31 (CEST)

Verplaatst naar afgehandeld, filter te omstreden. Akoopal _overleg 1 jun 2009 20:37 (CEST)

Overlegpagina.

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: IP gebruikers kunnen niet hun eigen overlegpagina leeghalen.
• Waarom: ivm verwijderen dossier.
• Gevolgen: Lijkt mijn best om te waarschuwen

!(user_groups contains "user") &
((article_namespace % 2) == 1 & (article_namespace != 3)) & 
action == "edit" & 
!(user_name in article_text) &
!(old_size < 100) &
new_size < 50

Huib talk^{Abigor @ meta} 20 mei 2009 21:47 (CEST)

Als het puur gaat om het verwijderen van het dossier, is het dan niet beter het voorstel hierboven van Erwin te nemen, dat specifiek test op het dossier? Akoopal _overleg 20 mei 2009 23:35 (CEST)

Dit lijkt mij sowieso een overbodige. Waarom zou iemand dossiers zo maar moeten slikken, die dingen worden hier uitgedeeld als snoepjes en helaas vaak nog onterecht en uit gemakzucht. Nergens is een regel die verbied dat een anoniem zijn eigen overleg kan leeghalen en dus is het ook doorgeschoten om dit automatisch te reverten of te waarschuwen. WEG met die dossiermentaliteit, die dingen werken alleen bij echte structurele vandalen. Fontes 21 mei 2009 00:48 (CEST)

Op dit moment is het filter slechts drie maal getriggerd. In alle gevallen was het de OP van een artikel, en geen gebruikers-OP. Klopt dat met de code van het filter? paul b 24 mei 2009 09:25 (CEST)

Even goed naar het filter gekeken, dit filter maakt dus juist een uitzondering voor het leegmaken van namespace 3, dat is overleg gebruiker. Dus volgens dit filter mag je wel overlegpagina's in de gebruikersruimte leeggooien, maar niet in de rest van de namespaces. Op deze manier lijkt het me vrij overbodig. Akoopal _overleg 24 mei 2009 11:12 (CEST)

Gezien het feit dat dit een fout filter is, en de taak omstreden stel ik voor deze uit te zetten en naar afgehandeld te verplaatsen. Het leeghalen van overlegpagina's in het algemeen kan een juiste handeling zijn. Akoopal _overleg 28 mei 2009 19:33 (CEST)

Filter uitgeschakeld om de redenen die Akoopal aangeeft. nl:Mark W (Mwpnl) ¦ talk 1 jun 2009 20:15 (CEST)

Verplaatst naar afgehandeld. Akoopal _overleg 1 jun 2009 20:37 (CEST)

Schreeuwen

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleert of een nieuwe gebruiker in de hoofdnaamruimte een behoorlijke toevoeging doet bestaande uit hoofdletters en interpunctie
• Waarom: Dit is SCHREEUWEN.
• Gevolgen: Waarschuwen
• Voorwaarden: Overgenomen van Overgenomen van en:Special:AbuseFilter/50

!("autoconfirmed" in user_groups) & (article_namespace = 0) 
& (length(added_lines) > 15) &  !("#(REDIRECT)|(DOORVERWIJZING)" in added_lines) 
& (added_lines rlike "^[A-Z0-9\s\pP]*?[A-Z]{5}[A-Z0-9\s\pP]*$") 
& !(added_lines rlike "__[A-Z]")

Lymantria _overleg 23 mei 2009 20:26 (CEST)

Kan je even toelichten wat het filter precies doet? Bij hoeveel hoofdletters achter elkaar reageert het, op wie, waar, etc. - Bas 23 mei 2009 20:50 (CEST)

Het filter reageert als er een regel wordt toegevoegd die bestaat uit alleen hoofdletters, spaties en interpunctie, en die in elk geval een cluster van 5 hoofdletters bevat. Redirect/doorverwijzing, noedit/newsection en notoc/forcetoc/toc zijn uitgezonderd. Lymantria _overleg 24 mei 2009 08:59 (CEST)

Valt dit eenvoudiger samen te vatten? Ik denk dan aan toekomstige softwarewijzigingen :) Bijvoorbeeld door het al uit te zonderen als er twee underscores achtereen in voorkomen? (schreeuwers doen dat vermoedelijk praktisch nooit anyway)? Zou helemaal ideaal zijn als er iets van een categorie "magicword" zou zijn die je gelijk in z'n geheel kunt uitzonderen. (misschien kunnen we ergens een lijst aanleggen en die lijst includen in diverse functies. Scheelt updaten) Effeietsanders 27 mei 2009 02:04 (CEST)

Triggert dit filter ook, ik noem maar wat, broncode in COBOL of BASIC? Dat lijkt me nl. niet zo gewenst. paul b 27 mei 2009 19:23 (CEST)

Een van de functies die al vergeten was uit te zonderen, was __NOINDEX__ btw. Effeietsanders 28 mei 2009 13:21 (CEST)

@paul b: ja dan gaat het filter af. Ik denk niet dat dat vaak voor zal komen, maar het is i.i.g. wel een reden om niet tot voorkomen over te gaan maar alleen tot waarschuwen. Bij de twee filters die met waarschuwen draaien blijkt dat overigens behoorlijk effectief.

@Effeietsanders: Noindex in de hoofdnaamruimte???? Lijkt me niet gewenst. Lymantria _overleg 28 mei 2009 18:21 (CEST)

In artikelen misschien niet, maar dat is lastig te voorspellen. Misschien dat er pseudo-naamruimtes zijn waar dit wel bruikbaar is. Mijn punt is vooral dat dit geen schreeuwen is, en dus niet hoort te triggeren. Dikke kans dat er in de toekomst meer van dit type magische woorden meer zullen voorkomen in de toekomst. Effeietsanders 29 mei 2009 01:16 (CEST)

Ik heb als "magicword" gekozen voor de regex __[A-Z], oftewel twee underscores gevolgd door een hoofdletter. Lymantria _overleg 29 mei 2009 07:39 (CEST)

Filter heeft ruim een week zonder grote wijzigingen en probleemloos gedraaid. Ingeschakeld in waarschuwingsmodus met Sjabloon:Misbruikfilter-waarschuwing-schreeuwen als waarschuwing. Lymantria _overleg 2 jun 2009 07:34 (CEST)

Schelden met 'homo'

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Filteren van schelden met het woord 'homo'
• Gevolgen: Waarschuwen.

_LolSimon -?- 19 mei 2009 14:22 (CEST)

Hoi Lolsimon, Overweeg ook te filteren op homo e.d. met een uitroepteken erachter. Lymantria _overleg 19 mei 2009 15:17 (CEST)

Ik zou dit filter graag combineren met #Verboden woorden: seksuele schuttingtaal. Het lijkt me niet noodzakelijk een apart filter voor het schelden met homo te hebben, dat komt het aantal filters niet ten goede en is niet direct nodig - althans, ik mag hopen dat we geen speciale "schande, je scheld met homo!"-waarschuwing gaan gebruiken? nl:Mark W (Mwpnl) ¦ talk 19 mei 2009 16:04 (CEST)

Prima idee, al is het voor het bekijken van de effectiviteit handig om het aantal "verboden woorden" in één filter niet al te groot te laten worden. Lymantria _overleg 19 mei 2009 16:32 (CEST)

Lymantria: dat maakt niet uit, want het uitroepteken staat achter de tekens die herkend worden door het filter. MarkW: op de Engelstalige wikipedia is dit ook gedaan, met de daar meest voor de hand liggende scheld-uitspraak: you suck. In tegenstelling tot bijv. 'kut' is homo een woord (of deel van een woord) dat wel regelmatig in de artikelen staat. Daarom is een specifiekere aanduiding in het filter nodig, en lijkt me een apart filter wel gewenst. Maar als de werking van het seksuele schuttingtaal-filter en de gevolgen ervan precies hetzelfde (of overlappend) zijn aan dat van dit filter, kan dit filter verwijderd worden. - _LolSimon -?- 19 mei 2009 16:35 (CEST)

Lolsimon: Ik bedoel eigenlijk dat je "Homo!" ook als schelden opvat, en niet als mogelijk eerste deel van de wetenschappelijke naam van een diersoort ;). Lymantria _overleg 19 mei 2009 16:39 (CEST)

Alleen "homo!" lijkt me (gezien het uitroepteken inderdaad ook zo'n duidelijk geval, dus toegevoegd. _LolSimon -?- 19 mei 2009 17:30 (CEST)

Combineren met het gewone scheldwoordfilter lijkt me lastig. In specifieke situaties (zoals het voorgestelde "* is een homo") zal het meestal om vandalisme gaan; maar er zijn talloze voorbeelden te bedenken waarin het woord homo in een niet-vandalistische context aan een lemma toegevoegd kan worden, terwijl bij een woord als "neuk" of "lul" dit niet zo is. CaAl 19 mei 2009 17:37 (CEST)

Dat is inderdaad precies de reden een apart filter aan te maken (het filter is al actief). Via de link kun je zien op wat het filter aanslaat. _LolSimon -?- 19 mei 2009 20:20 (CEST)

Mag ik bezwaar maken tegen dit voorstel, met inbegrip van bovenstaand voorstel over het onmogelijk maken van de woorden die men vat onder het kopje schuttingtaal? Ik mag die als vertrouwde bewerker nog wel gebruiken maar iemand anders mag ze niet meer gebruiken? Wat is dat voor een volstrekte kul?? Als dit de richting van dit projekt wordt dan hollen we hard richting de afgrond. Peter b 19 mei 2009 23:04 (CEST)

Wat een onzin dit. Ga je moeder vervelen. Mig de Jong 19 mei 2009 23:17 (CEST)

Voor voorstellen én eventuele bezwaren is deze pagina bedoeld, dus als er bezwaar is kan men dat hier kwijt. Groetjes - Romaine (overleg) 19 mei 2009 23:22 (CEST)

De tekst "is homo" komt regelmatig voor in bijvoorbeeld "is homoseksueel", "is homogeen" en "is homoniem". Op Coming out wordt gebruik gemaakt van "zijn homo’s" en op Bob van Schijndel en Jos Brink-prijs komt "is een homo" voor. Larzzz 20 mei 2009 00:01 (CEST)

Peter b en Larzzz: ik deel jullie zorgen, dit zijn inderdaad sterke argumenten. Dit filter zou voor teveel vals-positieven kunnen zorgen. Vandaar lijkt het me beter dat dit filter in deze vorm niet wordt ingevoerd. Wellicht is het een beter idee om het filter wat preciezer te laten werken, zoals alleen op nieuwe pagina's? (waarbij de verhouding vandalistisch/vals-positief vermoedelijk bijzonder hoog of 100% zal zijn). - _LolSimon -?- 20 mei 2009 00:24 (CEST)

Kunnen jullie niet eerst eens identificeren wat het probleem is dat jullie met deze "oplossing" willen oplossen? Volgens mij is dergelijk gescheld totaal geen probleem op wikipedia, en vandalistische edits met schuttingtaal zijn juist veel makkelijker te identificeren dan die zonder schuttingtaal. Door ze tegen te houden maak je het probleem alleen maar groter. Mig de Jong 20 mei 2009 08:56 (CEST)

Daarnaast is iemand homo noemen niet echt uitschelden. Ik heb verscheidene vrienden die homo zijn en vriendinnen die lesbisch zijn en ze duiden zichzelf ermee aan. Het woord homo in combanitie met andere uitingen kan weer wel uitschelden zijn. Maar moeten we werkelijk een robot hiervoor gebruiken? *zucht* Wae®th^tm©2009 | overleg 20 mei 2009 10:16 (CEST)

Ik ben vandaag een paar keer gebruikers tegengekomen die niet X is een homo gebruiken, maar die er nog een bijwoord tussengooiden, bijvoorbeeld X is een vieze homo of X is een kankerhomo. Door met een filter actief dingen te blokkeren / te waarschuwen, heb je kans op een wildgroei van dit soort dingen. Meningen? nl:Mark W (Mwpnl) ¦ talk 20 mei 2009 20:34 (CEST)

Kan er geen wildcard achtig iets tussen ter aanvulling van die bijwoorden? X is een "*" homo dan wel niet spaties. Ik vind het voorstel dat Waerth bij de andere schuttingtaal zet wel een hele mooi consensus. Waarschuw gebruikers dat er vermoed wordt dat ze schuttingtaal toevoegen. Schrikt sowieso al een deel af, het deel dat de interactieve opzet van Wikipedia onderschat bedoel ik dan. Voor de rest blijft dit deel van het filter gewoon heel moeilijk omdat soms de schuttingwoorden wel gewoon in context zijn (neuken doe je zo, homo sapiens et cetera). Hier is geen sluitende methode voor te bedenken dus een automatische revert op dit soort zaken zou niet moeten vind ik. Ik denk dat we ons vooral op de mogelijkheden van het filter moeten gaan focussen en alles wat randgevallen of onderdelen met mazen zijn moeten afstoten (qua automatische revert dan) en moeten vervangen door bijvoorbeeld de waarschuwingen die Waerth voorstelde dit met mogelijk een lijst ter controle. Fontes 20 mei 2009 20:53 (CEST)

Kroonprins Willem-Alexander is een lid van het koningshuis. Blah blah en zo voorts en zo. Verder schudde hij in Ergensanderstan de hand van president Ivan Ukland. In 2012 opende hij in het Nationaal Museum te Wereldseinde de tentoonstelling Homo Sapiens: van een aap tot een nog grotere aap. Hmm, nee ik weet het niet, met die wildcards... Hoopje 20 mei 2009 21:15 (CEST)

Leuk gevonden, je kan natuurlijk ook iets doen als is een [A-Za-z]* ?homo, dat zal het meeste wel pakken. Akoopal _overleg 20 mei 2009 21:25 (CEST)

O ja, nog een aanmelding, je kan de vals positieven beperken door expliciet te checken of er een aantal goede vormen, zoals homo sapiens niet in de toegevoegde tekst voorkomen. Zeker met dit soort toevoegingen gelden denk ik dezelfde overweging als bij sexuele schuttingtaal, zolang het waarschuwen is zal het allicht helpen. Akoopal _overleg 20 mei 2009 21:36 (CEST)

Zolang het waarschuwen is, heb ik er niet heel veel op tegen (hoewel ik nog steeds naar tegen neig). Maar ik probeer wel te bereiken, dat mensen de grenzen van dit soort automatische controleerders inzien. Het is filteren op alleen maar uiterlijke kenmerken, en dat kan nooit een mens (die op inhoud kan filteren) vervangen. Als tegenvoorbeeld op jouw een-na-laatste voorstel: Lucy is een typische homo erectus. Hoopje 20 mei 2009 21:51 (CEST)

Inmiddels is er behoorlijk wat verbeterd aan het filter, zodat de vals-positieven vrijwel nihil zullen zijn. - _LolSimon -?- 22 mei 2009 14:00 (CEST)

Een syntaxis waarbij homo in een toegevoegde regel voorkomt, tenzij aan een paar uitzonderingen wordt voldaan, lijkt mij principieel onjuist. Je kunt nooit vantevoren een uitputtende lijst van uitzonderingen bedenken. What about homogeneous (om maar te zwijgen van al die andere talen) bijvoorbeeld. En hoe zit het met homo sapiens, als ik daarbij niet zeg dat het latijn (of latin) is. Of mis ik iets?

Als je toch wilt waarschuwen bij homo als losstaand woord, gebruik dan tenminste een regular expression. - mvg RonaldB 22 mei 2009 18:14 (CEST)

De uitzonderingen zijn afgestemd op het meestvoorkomende gebruik. Verder zal een bewerking op bijv. het artikel homo sapiens, of homosexualiteit nooit voor een waarschuwing zorgen (zie de laatste regel van het filter). Vandaar verwacht ik vrijwel geen vals-positieven. Je hebt gelijk dat er vals-positieven kunnen zijn (bij vrijwel elk filter is dat theoretisch mogelijk), maar ik ben overtuigd dat de vals-positieven bij dit filter vrijwel nihil zullen zijn. Verder kan er gewoon worden opgeslagen na de waarschuwing, en het is duidelijk in de waarschuwing dat deze onterecht kan zijn. - _LolSimon -?- 22 mei 2009 19:08 (CEST)

Het toevoegen van zoiets als homo sapiens (of alle andere homo typen), kan op vele plaatsen, in heel serieuze artikelen en door heel serieuze gebruikers. Als dat geblokkeerd wordt ben je weg. Dat kan dus niet.

Als je daarvoor een waarschuwing krijgt, denk je ... (whatever). Als het een vandaal is, laat die zich door zo een waarschuwing niet tegenhouden. Een niet ingelogde vandaal heeft nu al de nodige hobbels te nemen alvorens de wijziging wordt opgeslagen (eerst "Toon bewerking", dan nog zo een grafische lettercombinatie).

Wat je wel zou willen voorkomen is "xx is een homo". Dan krijg je echter te maken met alle varianten daarop, zoals hierboven al aangegeven. Wat misschien in de buurt komt is dan een regexp die er ongeveer zo uit zou moeten zien:

\bis een\b(\w*\b)?homo\!*(\.|$)

in leesbare tekst:

• een word boundary (\b), gevolgd door
• "is een", gevolgd door
• een word boundary, gevolgd door het stukje tussen haakjes
  • een normaal karakter (\w), 0 of meerdere keren (*)
  • een word boundary
• en dat geheel 0 of 1 keer (?), gevolgd door
• "homo" als los woord, en tenslotte
• hetzij een punt (\.} of het eind van de regel ($). Geen word boundary, want dan blokkeer je b.v. weer 'xx is een homo sapiens".

Maar adh van dit voorbeeld zie je al dat je vrij snel heel complexe regexps en - nog belangrijker - logische overwegingen krijgt, die de zaak nooit volledig dichtgetimmerd krijgen. Dan kan je dus niet verdergaan dan waarschuwen, waarvoor in het geval van oningelogde vandalen al de nodige barrieres bestaan. - mvg RonaldB 23 mei 2009 03:12 (CEST)

 Uitgevoerd Het filter functioneert ruim een week en filtert prima veel gescheld eruit. Ingeschakeld met de schuttingtaal-waarschuwing. Lymantria _overleg 2 jun 2009 07:46 (CEST)

Verwijderen paragraaf

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Reageert op het verwijderen van een gehele paragraaf.
• Waarom: Soms wordt slechts een deel van een pagina verwijderd om te vandaliseren.
• Gevolgen: "Waarschuwen" door te vragen of dit wel degelijk de bedoeling is en eventueel markeren in geschiedenis en bijdragen.
• Voorwaarden: ?
• Waarschuwing: Sjabloon:Misbruikfilter-waarschuwing-paragraaf

(article_namespace == 0) &
!("autoconfirmed" in user_groups) &
(added_lines == "") &
(rmwhitespace(removed_lines) rlike "==\w+==") &
rmwhitespace(old_wikitext) contains rmwhitespace(removed_lines + "==") & 
!(rmwhitespace(new_wikitext) contains rmwhitespace(removed_lines + "=="))

--Erwin 22 mei 2009 20:01 (CEST)

Er zijn genoeg gebruikers die die code niet kunnen lezen, kun je ook voor hen aangeven welke voorwaarden er in het filter zijn toegevoegd, zoals voor wie het filter bedoeld is? Romaine (overleg) 23 mei 2009 15:36 (CEST)

Het reageert op niet-autobevestigde gebruikers die niets toevoegen, maar wel een hele paragraaf verwijderen. (Preciezer: de weggehaalde tekst bevat een kopje en de tekst daaronder tot aan het volgende kopje.) --Erwin 24 mei 2009 13:50 (CEST)

Lijkt me iets te makkelijk aan te slaan. Een nieuwe gebruiker die toch liever een andere opmaak ziet, bijvoorbeeld (dus alleen de kopjes weghaalt?), of die twee artikelen probeert te splitsen. Liever dit filter niet, en als toch, dan liever wat meer mitsen en maren (bijv een minimum aantal weggehaalde regels), wat ik wel erg interessant zou vinden is als dit twee keer achtereen gebeurt. Dat geldt wellicht uberhaupt voor het weghalen van teksten in een artikel. Effeietsanders 27 mei 2009 02:00 (CEST)

 Uitgevoerd Waarschuwingsmodus ingeschakeld. Ik heb een groot aantal filtermeldingen doorgekeken. In vrijwel alle gevallen gaat het om ruw schrappen van kop+tekst. Een enkele keer wordt alleen een eerste van twee kopjes weggehaald. Maar zonder meer een zinvol filter voor de waarschuwingsmodus, met uiteraard een genuanceerde waarschuwing (zie boven). Lymantria _overleg 5 jun 2009 21:31 (CEST)

Aanmaak (onzin)pagina bij bestand

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleert of een gebruiker een nieuwe pagina aanmaakt voor een bestand zonder info-sjabloon of categorie
• Waarom: Een geniepig soort vandalisme, dat lastig is te herkennen
• Gevolgen: Waarschuwen, bij gebleken geschiktheid voorkomen
• Waarschuwing: Sjabloon:Misbruikfilter-waarschuwing-afbeelding
• Voorwaarden:

  Article_namespace == 6 & action == "edit" & length(article_recent_contributors) == 0 & !(lcase(added_lines) rlike "info")
  

Het filter controleert of een nieuwe pagina in de bestand-naamruimte wordt aangemaakt zonder de teksten "info" of "categor" waardoor duidelijk is dat geen informatiesjabloon en geen categorie wordt aangeroepen. In log only modus gezet. (Vlak daarna een kleine correctie die alleen bij action == "edit" het filter doet afgaan) Lymantria _overleg 26 mei 2009 11:37 (CEST)

Wat maakt de naamruimte uit? Waarom is dit anders dan andere onzinpagina's? Ik zie het nut namelijk nog niet. --Erwin 26 mei 2009 22:50 (CEST)

Vandalisme op dit soort "pagina's" worden makkelijk over het hoofd gezien of niet herkend. Ik heb er vanmiddag toevallig nog twee gevonden van begin mei. Het plaatje functioneerde al via commons, functioneert nog steeds, en als je de pagina opent, dan valt ook voornamelijk het plaatje op. Je denkt: Een nieuw plaatje, dik in orde. Maar er is alleen een nieuwe tekst als beschrijving van een al bestaand plaatje gemaakt. En dan staat er in het midden ineens een vreemde zin.

In de bestandsnaamruimte is duidelijk dat er een beschrijving van een bestand of een categorie in moet staan om zinvol te zijn - meestal kunnen we het gewoon met de beschrijving op commons doen. En als je uploadt wordt je automatisch uitgenodigd om het information-sjabloon in te vullen. Die elementen zijn eenvoudig te checken. Dat is bij andere naamruimtes niet altijd zo eenvoudig. Lymantria _overleg 26 mei 2009 23:23 (CEST)

Regelmatig komt dit inderdaad voor, ik ken het. Ik denk dat het niet zinvol is om alleen een categorie op een pagina toe te voegen als het bestand op Commons staat (hetgeen ook wel gebeurt), misschien het "alleen categorie toevoegen" ook meenemen? Romaine (overleg) 27 mei 2009 00:53 (CEST)

Eens, dit komt regelmatig voor. En lokaal een categorie (en zelfs een sjabloon) toevoegen is ook niet gewenst m.i. Die info hoort tegenwoordig (laatste 2 jaar) op commons. Michiel1972 27 mei 2009 00:59 (CEST)

Dus dan samengevat: als een afbeelding ontbreekt of op commons staat is een pagina aanmaken onwenselijk. Is dat misschien mee te nemen of is dat te lastig? Romaine (overleg) 27 mei 2009 01:02 (CEST)

De laatste voorwaarde weghalen, elke edit op nieuwe bestandspagina zonder bijhorende lokaal geuploade afbeelding is m.i. ongewenst, dan blijft over: Article_namespace == 6 & action == "edit" & length(old_wikitext) == 0 Michiel1972 27 mei 2009 01:09 (CEST)

Dat moeten we niet doen, want dan gaat het filter ook af bij lokaal uploaden. Het filter voorziet helaas niet in het checken of er ook een lokaal bestand is waar de tekst bijhoort. Ik zal de categorie-uitzondering naar aanleiding van het bovenstaande echter verwijderen. Lymantria _overleg 27 mei 2009 07:34 (CEST)

Hmm, deze diff laat het filter afgaan. Daar snap ik geen donder van - het filter doet net of er nog geen tekst stond. Lymantria _overleg 27 mei 2009 13:29 (CEST)

Deze is echt vaag. Als ik bij 'onderzoeken' kijk, zegt hij dat de oude tekst 0 bytes is, dat is hij zeker niet. Lijkt me gewoon een bug die misschien gemeld moet worden? Moet eigenlijk wel het verwijderen van de afbeelding even uitgesteld worden, anders is het lastig onderzoeken. Akoopal _overleg 27 mei 2009 13:49 (CEST)

Bugmelding gedaan bij "bugzilla", NuCommons sjabloon even buiten werking gezet (op het bestand van die diff). Lymantria _overleg 27 mei 2009 14:53 (CEST)

Er komt niet veel reactie op deze bugmelding. Van Multichill begreep ik dat mogelijk het invoeren via de toolserver een rol speelt. Ik denk dat het opgelost is door toevoegen van NuCommons toe te staan. Lymantria _overleg 30 mei 2009 10:46 (CEST)

Dan toch weer een vals positieve met deze diff. Wel terecht dat die gefilterd zou worden, maar niet met dit filter. Ik heb alle vals positieven nog eens bestudeerd, en die toonden allemaal wel een oude lijst met recehte bijdragers. Door die te checken in plaats van de oude wikitext zou het moeten zijn opgelost. De check op NuCommons kon er dus weer uit. Lymantria _overleg 30 mei 2009 17:11 (CEST)

Er gebeuren geen vreemde dingen meer, zo lijkt het. Ik zou willen voorstellen om dit filter wél op voorkomen te zetten. Zinvolle bijdragen kom je bij dit filter niet tegen. Hoe kijken jullie daar tegenaan? – De voorgaande bijdrage werd geplaatst door Lymantria (overleg · bijdragen) 4 jun 2009 07:23

Zeker niet tegen, stukje monitoren is dan wel een pre. Misschien beter toch eerst een weekje waarschuwen nog. Wel ontbreekt hier de waarschuwingstekst nog. Daar moet in ieder geval een uitleg in dat de afbeelding op commons staat. Krijg je in het sjabloon nog de naam van het bestand mee zodat er een link naar commons bij kan komen? Akoopal _overleg 4 jun 2009 09:08 (CEST)

Inlinken van link naar het bestand op commons lukt denk ik niet - ik zou iig niet weten hoe. Voorstel waarschuwing hierboven aangevuld. Lymantria _overleg 4 jun 2009 12:05 (CEST)

 Uitgevoerd Ingeschakeld in vooralsnog de waarschuwingsmodus. Lymantria _overleg 6 jun 2009 17:29 (CEST)

Aanmaak minipagina

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleert of een gebruiker in de hoofdnaamruimte een pagina aanmaakt zonder redirect van minder dan 50 tekens
• Waarom: Dergelijk kleine pagina is te klein voor zinvolle inhoud
• Gevolgen: Waarschuwen, bij gebleken geschiktheid voorkomen.

article_namespace == 0
& length(article_recent_contributors) == 0
& length(added_lines) < 50
& !contains_any(lcase(added_lines),"#redirect","#doorverwijzing")

Reageert op een nieuw aangemaakte pagina van minder dan 50 tekens, zonder #redirect of #doorverwijzing. Ingeschakeld in log-only modus. Lymantria _overleg 2 jun 2009 11:43 (CEST)

Het komt regelmatig voor dat gebruikers effectief een doorverwijzing willen maken, maar niet weten hoe dat moet. Dan komt er als enige inhoud weleens iets te staan als "zie: [[bladiebla]]". Dat is uiteraard niet correct, maar het is geen vandalisme. Hoe gaan we daarmee om? paul b 2 jun 2009 11:51 (CEST)

Zoals ik hierboven ook schreef is de meldtekst ook zeer van belang. Dus ook hier het verzoek daar meteen een voorstel voor te maken. Daarin kan je de case die Paul aangeeft meenemen kwa uitleg, zodat de gebruiker het goed kan doen. Ik vind trouwens dat je veel gemaakte fouten die niet vandalisme zijn best uit mag filteren, want ze blijven ongewenst. Goede uitleg is dan wel een noodzaak. Akoopal _overleg 2 jun 2009 12:02 (CEST)

Voorstel: Sjabloon:Misbruikfilter-waarschuwing-minipagina. N.B. ook als gekozen wordt voor voorkomen, waar ik i.c. voor ben bij gebleken geschiktheid, dan kan er uitleg in het sjabloon komen. Lymantria _overleg 2 jun 2009 17:08 (CEST)

 Uitgevoerd ingeschakeld. Lymantria _overleg 9 jun 2009 16:52 (CEST)

Herhaling

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleert of een gebruiker een herhaling van hetzelfde woord/dezelfde woorden toevoegt
• Waarom: Indicatie van geen zinvolle inhoud, [5] is een voorbeeld van een opgevangen diff
• Gevolgen: Waarschuwen
• Waarschuwingstekst: Sjabloon:Misbruikfilter-waarschuwing-herhaling
• Voorwaarden:

article_namespace % 2 == 0
& (article_namespace != 2)
& !contains_any(article_prefixedtext, "Wikipedia:Zandbak", "Wikipedia:de Kroeg", "Wikipedia:Achterkamertje", "Help:Helpdesk")
& rmwhitespace(added_lines) rlike "([\w\.,\?!]{2,})\1{5}"

Het filter controleert of, onder weglating van spaties e.d., een combinatie van twee of meer letters/cijfers zesmaal direct achter elkaar herhaald wordt. De zandbak en gebruikersnaamruimte zijn uitgesloten. Lymantria _overleg 28 mei 2009 12:32 (CEST)

Triggert dit ook niet getallen op deze manier? (1111111111 bijv, hoewel niet heel waarschijnlijk :) ) Dit zou je voorkomen door te kiezen voor een combinatie van ofwel alleen letters/leestekens (sdsdsdsdsd), ofwel spaties ertussenIk zou sowieso eigenlijk hier kiezen voor alleen de artikelnaamruimte (in overleg kan ik me best voorstellen dat iemand aaaaaaaaaaaaaaaaaaah oid schrijft). Effeietsanders 28 mei 2009 13:27 (CEST)

Oh, en het alleen toepassen op nieuwe en anonieme gebruikers scheelt ook al :) (ik liet het natuurlijk net afgaan ;-) ) Effeietsanders 28 mei 2009 13:36 (CEST)

Alleen artikelruimte lijkt mij voldoende, en misschien alleen checken op herhalen van letters, niet van cijfers. Dit filter zou misschien wat vals positieven kunnen hebben in snelwegsjablonen enzo? Akoopal _overleg 28 mei 2009 19:46 (CEST)

Ik denk dat veel andere gebruiksnaamruimtes gefilterd moeten kunnen worden, ik ga straks de overleg ... gebruiksnaamruimtes wel uitsluiten. Ik zie niet in hoe die snelwegsjablonen dit filter triggeren? Lymantria _overleg 29 mei 2009 07:45 (CEST)

Ik ken de sjablonen niet goed en heb ook niet heel goed over de regexp nagedacht, maar kan me daar voorstellen dat je een aantal keer hetzelfde sjabloon invoert, iets van 'afslag rechts' en dat je daarmee een aantal keren een tekst herhaald. Akoopal _overleg 31 mei 2009 23:20 (CEST)

Hij slaat niet aan als er leestekens in het spel zijn. Lymantria _overleg 1 jun 2009 10:02 (CEST)

Om effectiviteit te vergroten wel . , ? ! als leestekens meegenomen. Lymantria _overleg 2 jun 2009 09:43 (CEST)

Ik wil iets uittesten m.b.t. de efficiëntie van dit filter. Daarvoor wil echter weten hoe veel tijd het filter nodig heeft voor bepaalde bewerkingen (in plaats van alleen een gemiddelde tijd). Weet iemand hoe ik dat kan uitvinden? Hoopje 1 jun 2009 01:12 (CEST)

Is me niet gelukt. Lymantria _overleg 2 jun 2009 09:43 (CEST)

Nogmaals qua naamruimte, het lijkt erop dat de gebruikersnaamruimte nu weer is toegevoegd? Ik zou willen voorstellen om het filter /alleen/ te laten werken op de artikelnaamruimte, aangezien voor de gebruikersoverlegnaamruimte, helpoverlegnaamruimte enz hetzelfde geldt als voor de normale overlegnaamruimte. Dus ipv "(article_namespace != 2)" dan "(article_namespace == 1)" Effeietsanders 4 jun 2009 10:07 (CEST)

Of ik begrijp je vraag verkeerd, of het komt doordat de source hierboven niet was geupdate. Ik ben het niet eens dat je herhaling wel in bijvoorbeeld de sjabloonnaamruimte zou mogen doen. Ik heb in de source (nu wel een update) uitgesloten alle "overleg"-naamruimtes, en tevens de naamruimte Gebruiker. Dat is toch goed zo? Lymantria _overleg 4 jun 2009 11:38 (CEST)

Als ik het goed begrijp, pakt ie nu alle naamruimtes waar overleg in het prefix zit. Dus dat omvat "Overleg:", "Overleg gebruiker:", "Overleg Wikipedia:" enz. Maar dus niet Help: , Wikipedia: enz. Daarnaast wordt tweemaal gecheckt op overleg: volgens mij. Ik denk dat dit vandalisme alleen relevant is in de hoofdnaamruimte, dus het is dan gemakkelijker om het alleen te activeren als article_namespace==1. Wmb zou het iig niet moeten aanslaan bij gebruikerspagina's (waar het volstrekt legitiem kan zijn) of bijvoorbeeld de kroeg of het achterkamertje. Effeietsanders 7 jun 2009 10:48 (CEST)

@effeietsanders: Je zit abuis met je telling van de namespace. article_namespace==1 geeft de overleg-ruimte. Dus, ten weede male, het nu draaiende filter kijkt niet naar wijzigingen in de gebruikersnaamruimte en alle overlegnaamruimtes. Op bijzonder veel andere pagina's (bijvoorbeeld ook op Help:Hulpmiddelen in de helpnaamruimte) is copypaste vandalisme of een opeenvolging van 12 dezelfde tekens ook heeeeel irritant. Daarom wil ik het filter in beginsel in de andere naamruimtes graag actief houden - overigens in waarschuwingsmodus. Achterkamertje, kroeg en helpdesk apart uitsluiten is w.m.b. prima. Is dat in jouw ogen voldoende? Lymantria _overleg 7 jun 2009 11:38 (CEST)

Achja, natuurlijk, begint op 0 ipv 1 :) should have known that.. Dat het irritant is, is voor mij niet echt voldoende reden eigenlijk, het is vooral niet schadelijk, omdat het niet om de artikelen zelf gaat, maar slechts om ondersteunende pagina's. Een andere categorie pagina's zou de verwijderlijst zijn (en alle subpagina's) enz. Dus de hele naamruimte uitsluiten is dan gemakkelijker. Effeietsanders 10 jun 2009 15:12 (CEST)

Okay, ik zal de naamruimtes Wikipedia en Help geheel uitsluiten. Lymantria _overleg 10 jun 2009 16:47 (CEST)

Even iets heel anders, checken of het geen overlegpagina's zijn kan ook door: '(article_namespace % 2) == 1'. Hiermee kijk je feitelijk of het namespacenummer oneven is, hetgeen altijd een overlegpagina is. Aangezien dit filter best wel een lange runtijd heeft, misschien is dit efficienter? Akoopal _overleg 8 jun 2009 17:46 (CEST)

Goede suggestie. Op iets andere wijze ingevoerd. Ook kroeg, achterkamertje en helpdesk uitgesloten. Soms lijkt er een foutje plaats te vinden, want deze filteractie is mij volstrekt onduidelijk. Lymantria _overleg 8 jun 2009 20:13 (CEST)

Actief, maar zelfs deze bewerking activeerde het filter, dus toch weer uitgeschakeld, zie ook het logboek. nl:Mark W (Mwpnl) ¦ talk 9 jun 2009 16:07 (CEST)

Haha, ja, dat snap ik. 🙂 Je verplaatste namelijk een tekst met herhaling erin, dus die stond weer in de added lines! Simpel opgelost door het filter niet actief te laten zijn als er in de removed lines herhaling zit - anders kan dit inderdaad vervelend en raadselachtig zijn. Verder toch ingeschakeld, omdat er geen wezenlijke verandering van het filter nodig was. Lymantria _overleg 9 jun 2009 17:01 (CEST)

Er is mij ook wel gebleken dat het filter alleen op nieuwe en anonieme gebruikers hoeft te werken. Ter optimalisatie dus autoconfirmed gebruikers uitgesloten. Lymantria _overleg 10 jun 2009 16:55 (CEST)

Handtekening in hoofdnaamruimte

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Controleren of een nieuwe of anonieme gebruiker een handtekening plaatst in de hoofdnaamruimte.
• Waarom: Omdat handtekeningen niet in de hoofdnaamruimte horen
• Gevolgen: Waarschuwen, daarin melden dat een handtekening niet in de hoofdnaamruimte hoeft/hoort te worden geplaatst, met de vraag om de handtekening uit het bericht te verwijderen voordat de bewerking wordt bevestigd.

Qua regex zou het beter kunnen denk ik, maar op deze manier zal het filter vermoedelijk ook prima functioneren. _LolSimon -?- 20 mei 2009 23:43 (CEST)

Probleem met handtekeningen is dat gebruikers er vrijheid in hebben, ik ken handtekeningen van gevorderde gebruikers die niet op dit filter zullen matchen. Daarentegen zullen het beginnende gebruikers dat nog niet veranderd hebben, dus al met al denk ik dat het wel een nuttig filter kan zijn. Akoopal _overleg 21 mei 2009 10:43 (CEST)

Misschien vang je inderdaad niet elke "overtreding", maar wel het grootste deel. Het aantal vals-positieven lijkt me zeer gering: zelfs als je als user name een woord hebt dat je ook in artikelcontext kan gebruiken ("ben" ofzo), zorgt de check op "(CE[S]T)" ervoor dat er toch iets vreemds gedaan moet worden om het filter te activeren. CaAl 21 mei 2009 11:18 (CEST)

Zoals CaAl al zei. Dit filter heb ik trouwens alleen ingeschakeld op niet-autoconfirmed gebruikers, niet op gebruikers die langer actief zijn zoals jij en ik. In het geval van gebruikers die een sjabloon als handtekening gebruiken, werkt het filter trouwens ook (in de sjabloonsnaam komt de gebruikersnaam voor), maar dit is op het moment niet aan de orde omdat het filter alleen op nieuwe/anonieme gebruikers werkt. - _LolSimon -?- 21 mei 2009 20:32 (CEST)

Hoe lang blijven nieuwe filters trouwens bij "nieuwe verzoeken" staan? Deze heb ik, na afwezigheid van 2,5 dag, nog nooit eerder gezien bijvoorbeeld. Overigens lijkt me dit een filter uit de categorie "onnodig, en daarom ongewenst". De meeste anonieme en nieuwe gebruikers die überhaupt een handtekening bij hun bijdragen plaatsen, schrijven iets van "Door: <echte naam>". En aangezien dit filter op "(CEST)" of (CET)" filtert, worden die niet herkend. Hoopje 23 mei 2009 20:15 (CEST)

Dit filter heeft tot nu toe inderdaad nog 0 resultaten, als dat over een aantal dagen nog zo is lijkt mij dit inderdaad een overbodig filter. - Bas 23 mei 2009 20:33 (CEST)

Dat er nul resultaten kwamen komt doordat het filter niet werkte. Deze diff werd niet gevangen. Ik heb het filter aangepast, zodat die wel zou zijn gevangen. Nu eens kijken of het wel werkt. Lymantria _overleg 26 mei 2009 13:07 (CEST)

Ik heb onlangs een schoonmaakronde gedaan betreft linken naar gebruikerspagina's en gebruikersoverlegpagina's en daarbij merkte ik slechts een enkele handtekening van een nieuwe gebruiker, en voor de rest was er geen enkele handtekening te vinden. De noodzaak van dit sjabloon lijkt me marginaal, maar dat dan alleen uberhaupt voor nieuwe/IP-gebruikers. Romaine (overleg) 27 mei 2009 00:58 (CEST)

Ik zie het filter nog steeds niet triggeren. Zit er nou nog een fout in, of komt het gewoon niet voor? Ik denk dat we het filter wel uit kunnen zetten onder het motto overbodig. Akoopal _overleg 2 jun 2009 11:52 (CEST)

De regex "(CE[S]T)" was in elk geval vreemd, en heb ik vervangen door "(CES?T)". Toch had dat nu, in de zomertijd, geen probleem op moeten leveren. Misschien komt het inderdaad nauwelijks voor. Lymantria _overleg 2 jun 2009 17:30 (CEST)

Weer zoiets vreemds, deze diff levert de eerste hit op, maar de handtekening is al in de vorige bewerking gezet. Ik heb de controle op vier tildes maar eens toegevoegd, wie weet zit daar de crux wel. Lymantria _overleg 3 jun 2009 23:07 (CEST)

Ho, nu wemelt het van de vals positieven, in de verkeerde naamruimte.... Met een paar haakjes gefixt, hopelijk. Lymantria _overleg 4 jun 2009 07:20 (CEST)

Kijk, nu komen er wel degelijk meldingen. Het lijkt erop dat de gefilterde edits eigenlijk zouden moeten vallen onder het hoofdstukje "voorbeeldtekst van bewerkknoppen" - er zit immers een handtekeningknop boven het invulvak. Daarom stel ik voor om die vier tildes van dit filter in te voegen in filter 2. Lymantria _overleg 5 jun 2009 11:02 (CEST)

Lijkt me geen goed idee. Hier zou namelijk een aparte waarschuwingstekst voor moeten komen die uitlegt dat de handtekening alleen voor overlegpagina's is, en niet voor de artikelen zelf. Akoopal _overleg 5 jun 2009 11:19 (CEST)

Het valt me op dat het filter nog nooit is afgegaan. Ik kwam net deze bewerking tegen. Ook daar ging het filter niet af. Mogelijk zit er ergens een fout in het filter. Hieronder de code zoals die nu is:

!("autoconfirmed" in user_groups) &
(article_namespace == 0) &
((added_lines rlike "~~~~") |
((user_name in added_lines) &
(added_lines rlike " \(CES?T\)")))

Wie fixt 't? Sum^?urai8^? 5 jun 2009 21:44 (CEST)

Er zit helemaal geen fout meer in, en het filter gaat inmiddels wel degelijk soms af. De door jou aangehaalde diff is van een "autoconfirmed" gebruiker. Die zijn in het filter expliciet uitgesloten. Wellicht moeten we die uitsluiting verwijderen... Lymantria _overleg 5 jun 2009 21:55 (CEST)

 Uitgevoerd Filter werkt inmiddels fijn. Ingeschakeld in waarschuwingsmodus met Sjabloon:Misbruikfilter-waarschuwing-handtekening als waarschuwing. Lymantria _overleg 11 jun 2009 07:42 (CEST)

Melding aangevuld met 'De handtekening is alleen bedoeld voor bijdragen op overleg-pagina's.'.– De voorgaande bijdrage werd geplaatst door Akoopal (overleg · bijdragen)

Prima! Lymantria _overleg 11 jun 2009 09:41 (CEST)

Kwebbelen in hoofdnaamruimte

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Gekwebbel in de hoofdnaamruimte eruithalen
• Waarom: Niet encyclopedische bijdragen
• Gevolgen: Waarschuwen

!("autoconfirmed" in user_groups) 
& (article_namespace == 0) 
& (lcase(added_lines) rlike "\b(h[oa]i|heej|ik ben|wij zijn|hallo|groet(jes)?(en)?|grtz|doe[ig]|i love|<3|ik hou van|is een schat(je)?)\b")
& !(lcase(removed_lines) rlike "\b(h[oa]i|heej|ik ben|wij zijn|hallo|groet(jes)?(en)?|grtz|doe[ig]|i love|<3|ik hou van|is een schat(je)?)\b")

Het filter reageert op diverse groeten, "ik ben" en "wij zijn" en op liefdesverklaringen in de hoofdnaamruimte. Ingeschakeld in log-only modus. Lymantria _overleg 2 jun 2009 10:06 (CEST)

Helaas reageert het filter ook op diverse verschrijvingen van woorden die niet onder de bovenstaande groeten vallen: [6], al in een van de eerste regels staat "groet op", moet zijn "groeit op". paul b 2 jun 2009 13:17 (CEST)

Dat kan natuurlijk gebeuren. Ik zie dat er ook een keer "ik ben" in een citaat bij zit. Dit is mijn voorstel voor het waarschuwingssjabloon: Sjabloon:Misbruikfilter-waarschuwing-kwebbelen. Lymantria _overleg 2 jun 2009 17:21 (CEST)

Technisch is er ook nog wel het een en ander dat fout gaat. Het is mij een raadsel waarom dit wordt afgevangen: [7]. paul b 4 jun 2009 15:52 (CEST)

Vanwege het streepje dat weggehaald werd bij "Ik hou van Holland" stond die regel ook bij de toegevoegde regels. Hoopje 4 jun 2009 16:03 (CEST)

In elk geval een reden om ook te checken of er niet dergelijke woorden ook worden weggehaald. (done). Lymantria _overleg 4 jun 2009 16:33 (CEST)

 Uitgevoerd Ingeschakeld in waarschuwingsmodus na een week succesvol proefdraaien. Lymantria _overleg 11 jun 2009 18:34 (CEST)

Toevoegen van spaties

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Ongewenste toevoegingen van een groot aantal spaties in een anonieme edit tegengaan.
• Waarom: Toevoeging van meerdere spaties is in principe overbodig, en duidt op ascii art of andersoortig vandalisme.
• [[Gebruiker:|]] ([[Overleg gebruiker:|overleg]] · bijdragen · filterlogboek)
• Gevolgen: Waarschuwing
• Condities: Zie https://en.wikipedia.org/wiki/Special:AbuseFilter/65 Dit filter staat in de top 5 van 'hits' op de Engelstalige lijst van filters.

!("autoconfirmed" in user_groups) &
!("sandbox" in lcase(article_text)) &
!("<source" in new_wikitext) &
(added_lines rlike "\s{8}") &
!(added_lines rlike " {7,}\n") &
!(added_lines rlike "\s{8}[#=\-]") & 
!(removed_lines rlike "\s{8}")

Michiel1972 19 mei 2009 14:46 (CEST)

• NB: 'sandbox' zou vervangen moeten worden door 'zandbak' bij gebruik op deze wiki. CaAl 19 mei 2009 14:51 (CEST)

Het filter zou in deze opzet (met zandbak) ook reageren op wijzigingen als deze, die niet per definitie fout zijn. Daar moeten we nog even goed aan sleutelen denk ik. nl:Mark W (Mwpnl) ¦ talk 19 mei 2009 16:06 (CEST)

Die wijziging die je geeft was toch ook niet gewenst? Prima om daar een waarschuwing/hint aan mee te geven dat de gemaakte wijziging niet klopt. Michiel1972 20 mei 2009 10:36 (CEST)

Waarom is die wijziging - technisch gezien dus - niet gewenst? Er worden twee regels toegevoegd aan een lijst. Als de inhoud van de toevoeging legitiem was geweest, zou deze wijziging ook zijn tegengehouden, en dat lijkt me niet de bedoeling? nl:Mark W (Mwpnl) ¦ talk 20 mei 2009 10:42 (CEST)

Indien zo'n geval zich zou voordoen, dan kan je de gebruiker waarschuwen dat er iets schort aan de opmaak. Indien de toevoeging legitiem is, weet je als gevolg van de melding dat je de opmaak kan verbeteren en kan je op zoek gaan naar meer info. In het geval er vandalisme is, dan kan je door middel van het logboek gemakkelijk nagaan wat er gecorrigeerd moet worden. Annabel_(overleg) 21 mei 2009 15:22 (CEST)

 Uitgevoerd Ingeschakeld in logmodus. Filter aangepast zodanig dat de filter niet aangaat in de gebruikers- en overlegruimte (voor het geval een gebruiker eens wil zandbakken zonder van de zandbak gebruik te maken). Annabel_(overleg) 21 mei 2009 15:22 (CEST)

Filter zou selectiever moeten. Dit [8] lijkt me geen ongewenste bewerking die zou moeten worden tegengehouden. Is het mogelijk enkel op aaneengesloten stukken witruimte te testen? paul b 27 mei 2009 19:19 (CEST) Tevens verzoek om nauwkeuriger te omschrijven wat het filter doet, de code zelf is nu juist niet leesbaar voor de gemeenschap, enkel voor de technocraten. paul b 27 mei 2009 19:21 (CEST)

Lijkt me wel een ongewenste bewerking (maar geen vandalisme), nog afgezien van een onopgemaakte tekstdump, worden er loze regels met spaties toegevoegd. Zover ik het logboek heb geanalyseerd wordt het filter 100% terecht getriggerd. Michiel1972 28 mei 2009 10:02 (CEST)

Het lijkt mij in ieder geval geen bewerking die een waarschuwing verdient. Het is misschien een bewerking door een beginnende gebruiker, maar inderdaad zeker geen vandalisme. Hoopje 28 mei 2009 23:25 (CEST)

Michiel1972: "terecht getriggerd"? Dit is wellicht een onhandige edit, maar we gaan toch iemand niet geautomatiseerd lastig vallen omdat we die witregels overbodig vinden? Automatische opmaakbewaking lijkt me niet het doel van deze filters. Verder tast ik nog steeds een beetje in het duister wat een gebruiker precies moet doen om dit filter te triggeren, dus ik zou nogmaals willen vragen dat nauwkeuriger aan te geven. paul b 28 mei 2009 23:42 (CEST)

Ik heb nu een stuk of twaalf triggers van het filter bekeken, en er zitten misschien drie bewerkingen tussen die m.i. afgevlagd kunnen worden en die niet hebben plaatsgevonden in een zandbakartikel dat sowieso wel wordt opgemerkt en verwijderd moet worden. Gelet op de royale hoeveelheid vals-positieven, lijkt mij dat we dit filter niet moeten invoeren in deze vorm. paul b 28 mei 2009 23:57 (CEST)

 Uitgevoerd filter actief in waarschuwingsmodus. Ik heb de logboeken bekeken en met de bekeken gelogde bewerkingen was altijd iets mis, invoegen van witruimte was er altijd bij. Annabel_(overleg) 31 mei 2009 22:13 (CEST)

Ja, dat dankt je de koekoek. Het probleem is dat een groot deel van deze edits op geen enkele wijze als vandalistisch kan worden aangemerkt. Daarmee wordt het "misbruikfilter" nu m.i. oneigenlijk gebruikt. Daarbij, hier [9] worden wel twee hele regels witruimte ingevoerd op volstrekt voor de hand liggende plaatsen. Wat moet een gebruiker op dat moment dan met die geautomatiseerde melding? paul b 2 jun 2009 09:35 (CEST)

De edit op [10] zou inderdaad niet moeten leiden tot een waarschuwing o.i.d., ik snap ook niet waarom dat heeft plaatsgevonden als ik het gebruikte filter bekijk:

!("autoconfirmed" in user_groups) &
!(article_namespace == 2 | article_namespace == 3) &
!("zandbak" in lcase(article_text)) &
!("<source" in new_wikitext) &
(added_lines rlike "\s{8}") &
!(added_lines rlike " {7,}\n") &
!(added_lines rlike "\s{8}[#=\-]") & 
!(removed_lines rlike "\s{8}")

Michiel1972 2 jun 2009 09:42 (CEST)

Ik ook niet, maar dat komt doordat ik de gebruikte code niet beheers. Ik zou toch graag wel eens willen weten waar het filter door getriggerd zou moeten worden. Overigens bevat de tweede "witregel" drie spaties, dat zou wellicht bijgedragen kunnen hebben. Maar dan ligt het voor de hand te vermoeden dat het invoeren van een stuk of vier, vijf alinea's met tussenkopjes en correcte opmaak leidt tot het triggeren van dit filter. Dat lijkt me niet gewenst. paul b 2 jun 2009 09:51 (CEST)

Ik beheers de code ook niet geheel. In het vakje (edit_diff) in de log van die [11] zie ik wel dat er spaties zijn gesignaleerd voor de kopjes en bij de start van de eerste regel onder het kopje. Normaal gesproken zal het toevoegen van een subkopje met witregels dit filter niet triggeren (probeer zelf maar eens). Michiel1972 2 jun 2009 09:56 (CEST)

Na een crash course regex lijkt me duidelijk te zijn wat er mis is gegaan. Gebruiker heeft ook nog eens een paar (i.c. vier) spaties toegevoegd achter de regel voorafgaande aan de witregel. Dit gecombineerd met (1) het feit dat regeleinden óók als whitespace gelden en (2) de drie spaties in de witregel, heeft het filter doen afgaan. Dit terwijl de "fouten" in de bewerking voor alle praktische doeleinden onzichtbaar zijn voor de lezer. Ik denk dat ofwel de waarschuwing een stuk specifieker moet en ook moet wijzen op spaties in lege regels of aan het einde van een niet-lege regel, ofwel we moeten heroverwegen of dit filter (in deze vorm) wenselijk is. Deze gebruiker heeft gelukkig zijn/haar bewerking toch doorgezet, maar het zou onwenselijk zijn als zinvolle bijdragen verloren gaan doordat gebruikers zich door een automatische waarschuwing laten afschrikken. paul b 2 jun 2009 12:06 (CEST)

Lijkt mij dat het filter weer terug naar log-only moet, en er eerst hier goed naar gekeken moet worden. Misschien dat \s vervangen door [\t ] al genoeg is, maar dat moet zeker eerst getest worden. In ieder geval is er over het huidige filter nog geen consensus lijkt me. Akoopal _overleg 2 jun 2009 12:24 (CEST)

Teruggezet in log-only modus. Het filter werkte niet naar behoren. Geprobeerd te fixen met (added_lines rlike "\s\1{7}") (zodat acht keer dezelfde soort witruimte wordt ingevoegd) wat lijkt te werken in de tests die ik deed op vals positieven. Lymantria _overleg 2 jun 2009 12:47 (CEST)

De filter werkt en werkte juist wel prima! Bij alle keren dat de filter afging, was iets mis. Hier wordt met een enorm vergrootglas gekeken op die ene bijdrage. Klopt dat dit je dit ook als één vals positieve zou kunnen klasseren, maar om hiervoor te zeggen dat de filter hierdoor niet werkt en dit klasseren als oneigenlijk gebruik is de zaken omdraaien. In het verleden hebben we vandalisme gehad, waardoor artikels werden opgeblazen door zogezegd onbestaande witruimte (tot wel 300kb!). Als er al iets gedaan moest worden, is het de tekst van de melding aanpassen, niet de fitler uitschakelen. Annabel_(overleg) 2 jun 2009 19:38 (CEST)

Het filter reageerde overdreven. Door nu te eisen dat er of acht keer spatie, of acht keer enter komt, denk ik dat het filter minder makkelijk onnodig afgaat. Een weekje langer uittesten moet toch niet het probleem zijn. Lymantria _overleg 2 jun 2009 22:59 (CEST)

Er waren meer dubieuze acties van dit filter, Annabel. Sowieso vind ik dat deze filters niet als automatische opmaakbewaking mogen dienen, maar enkel om vandalisme en ander misbruik te signaleren en eventueel te verhinderen. paul b 3 jun 2009 20:17 (CEST)

Foutje in de "verbetering" hersteld. Er kwamen nu helemaal geen hits meer. Lymantria _overleg 8 jun 2009 21:23 (CEST)

 Uitgevoerd Filter werkt nu naar behoren, terug in waarschuwingsmodus. Lymantria _overleg 15 jun 2009 17:18 (CEST)

plagiaat controle

Status: Nooit aangemaakt

Aanmaken filter · batchtesten

• Taak: Het filter moet kijken of de tekst erg op teksten ergens anders op internet lijkt.
• Waarom: Dit is handig tegen plagiaat.
• Gevolgen: Waarschuwen en/of Verhinderen.

Ik weet niet in hoeverre dit uitvoerbaar is maar als het uitvoerbaar is zou het heel handig zijn. KanmanVraagje? 20 jun 2009 17:47 (CEST)

Lijkt mij onuitvoerbaar. Als het technisch al mogelijk zou zijn, duurt het veel te lang om bij elke wijziging dit filter te laten lopen. paul b 20 jun 2009 18:07 (CEST)

'Verhinderen' lijkt me sowieso niet aan de orde; kopiëren van tekst is niet altijd auteursrechtenschending. Fruggo 20 jun 2009 20:51 (CEST)

Niet mogelijk. Technische beperkingen maken dat dit filter niet realiseerbaar is. nl:Mark W (Mwpnl) ¦ talk 20 jun 2009 21:31 (CEST)

Tekst na categorie of interwiki

Status: Actief

bewerken · geschiedenis · logboeken · testen

• Taak: Waarschuwt wanneer na een categorie of interwikilink iets wordt toegevoegd
• Waarom: Verkeerde plaats, vaak geklieder
• Gevolgen: Waarschuwen
• Waarschuwingstekst: Sjabloon:Misbruikfilter-waarschuwing-tekstnacatofiw

Het filter slaat aan als er na zo'n link minstens 5 letters/spaties staan. Lymantria _overleg 8 jun 2009 13:16 (CEST)

Lijkt me prima, maar ik geloof dat er ergens een bot/script in gebruik is die al jaren {beg} 's plakt na de categorieën. (Zie o.a. de edits van gebruiker:Brimz bv hier). Als het aan mij ligt is dat afgelopen hoor. Michiel1972 8 jun 2009 13:55 (CEST)

Op het overgrote deel van de artikelen staan de sjablonen boven de categorie, en slechts een enkeling heeft ze onder de interwiki's staan. Waar ik dat tegenkom pas ik dat aan. Het begginnetje-sjabloon hoort bij of op de plek van navigatiesjablonen te staan en niet onder de interwiki's of zelfs bovenaan de pagina. Wat ik me alleen afvraag, als iemand zijn bewerking wil opslaan en een eerdere bewerker heeft de categorie midden tussen de tekst gezet/laten staan (komt soms voor), krijgt diegene dan een melding of alleen als die iets onder de categorie wijzigt of...? Romaine (overleg) 8 jun 2009 14:06 (CEST)

Het filter reageert alleen als de situatie van iets tussen de categorieën en interwikilinks nieuw is. Als er al iets staat (bijvoorbeeld {beg}) dan gaat hij niet af. Lymantria _overleg 8 jun 2009 14:08 (CEST)

Dat begrijp ik, maar weten de beg-erbij-bot/script gebruikers dat ze hun script moeten aanpassen? Ik heb dat namelijk al een keer gevraagd (een jaar terug denk ik) maar men vond het blijkbaar geen probleem dat een {beg} wordt geplaatst na een categorie. Michiel1972 8 jun 2009 14:12 (CEST)

Ik besef me nu dat hij bij een beg-bot helemaal niet afgaat, omdat ik het filter alleen op 5 letters/spaties na een bestaande link laat reageren. Lymantria _overleg 8 jun 2009 14:18 (CEST)

Vrijwel altijd is het een {beg} met parameters zoals {beg|landen & volken} en/of datum. Maar goed, de scriptgebruikers komen er snel genoeg achter dat het niet maar kan na inschakeling van dit filter. Michiel1972 8 jun 2009 21:35 (CEST)

Het filter zal niet afgaan vanwege het gebruik van { binnen vijf letters/spaties na de categorie. Lymantria _overleg 8 jun 2009 22:35 (CEST)

Jammer, moeten we handmatig die 'beg' s blijven verplaatsen boven de cats :) Michiel1972 8 jun 2009 22:38 (CEST)

Als er behoefte is kan ik { aan de tekenset toevoegen :D Lymantria _overleg 8 jun 2009 22:49 (CEST)

Ik zag vandaag iemand die een afbeelding helemaal onderaan zette, dus dan moet [ er ook bij. Persoonlijk ben ik een voorstander van toevoegen van [ en { . Akoopal _overleg 8 jun 2009 23:03 (CEST)

Het toevoegen van [ zullen we maar niet doen, want interwikilinks en categorieën toevoegen moet wel mogelijk blijven. Lymantria _overleg 8 jun 2009 23:24 (CEST)

Ik zou even wachten met het implementeren van dit filter, zodat gebruiker:RonaldB de kans heeft om het script, welke verantwoordelijk is voor het plaatsen van de sjablonen na de categorieën, aan te passen. Doe je dit niet, dan verliest een groep medewerkers een stukje functionaliteit wegens onterecht vermeend misbruik en daar zijn de misbruikfilters niet voor bedoeld lijkt mij. Daarnaast heb ik niet een regel kunnen vinden, die zwart op wit stelt, wat de plaats is van een beginnetjessjabloon. Maar wellicht heeft iemand van jullie een link? M.vr.gr. brimz 9 jun 2009 08:27 (CEST)

Kun je dan wel een linkje geven waar de regel zwart op wit staat dat categorieën voor de interwiki's moeten, of dat categorieën niet gewoon leuk ergens midden in de tekst kunnen, of nog tientallen varianten? We hebben voor artikelen een bepaalde basisstructuur zoals die al jaren van toepassing is, zoals de volgorde van inhoud - navigatie- en beginnetjesjablonen - categorieën - interwiki's. Die standaard volgorde zorgt voor een hoop overzichtelijkheid en duidelijkheid voor nieuwe en bestaande gebruikers. Slechts met zeer goede reden zou daar van kunnen worden afgeweken. Het botmatig toevoegen van het Beginnetje-sjabloon is wat mij betreft geen voldoende reden om daarvan af te wijken. Groetjes - Romaine (overleg) 11 jun 2009 19:55 (CEST)

Hmm, zou ik niet erg voor zijn. Immers, ik kan me best voorstellen dat er een goede reden is om iets toe te voegen erna, zoals een opmerking tussen comment-tags of zelfs verwijzingen naar referenties op een gegeven moment (of sorteer-sjablonen?) Ik vraag me af of de voordelen echt opwegen tegen de potentiele nadelen en beperkingen die dit oplevert. Effeietsanders 10 jun 2009 14:15 (CEST)

Gezien de reacties until now, lijkt het me niet goed om { toe te voegen aan de te checken tekens. Opmerkingen tussen comment-tags konden zowiezo al. Het gaat nu alleen om een bijdrage die in de eerste vijf tekens alleen bestaat uit wit en letters. Zie de logboeken: dit pakt er heel wat onjuiste bewerkingen uit! Lymantria _overleg 10 jun 2009 16:59 (CEST)

Het filter ging in mijn ogen te snel af, en daarom heb ik een paar kleine aanpassingen gedaan. Zo moet er nu echt een letter worden toegevoegd (in plaats van 5x letter/spatie - dan reageert het filter al op een paar enters), en is het niet de bedoeling dat het filter reageert op iw of cat met : ervoor. Lymantria _overleg 14 jun 2009 15:31 (CEST)

 Uitgevoerd Ingeschakeld in waarschuwingsmodus Lymantria _overleg 21 jun 2009 19:43 (CEST)

Geen handtekening bij overleg

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: Attendeert op een vergeten handtekening bij toevoeging aan overlegpagina
• Waarom: Heel vervelend, soms vandalisme
• Gevolgen: Waarschuwen
• Waarschuwingstekst: Sjabloon:Misbruikfilter-waarschuwing-geenhandtekening

Meteen enkele vals positieven bij dossier-toevoegingen op ip-op's en een welkom. Dit heb ik proberen te ondervangen door toevoegen van {{ of # de waarschuwing te laten onderdrukken. Lymantria _overleg 11 jun 2009 12:42 (CEST)

Dit filter gaat vals positieven geven voor mensen die een foutje zien in hun bijdrage, en dat nog even aanpassen. De praktijk zal moeten uitwijzen hoe vaak dat is. Lijkt me over het algemeen verder wel nuttig. Akoopal _overleg 11 jun 2009 19:39 (CEST)

 Tegen dit filter. De mogelijkheid om filters aan te maken is bedoeld om misbruik tegen te gaan en niet om gebruikers te gaan betuttelen. Het komt vaak genoeg voor dat ik mijn eigen typfouten wil corrigeren (en die ga ik dus niet ondertekenen). Wat mij betreft schiet dit voorstel te ver door. Romaine (overleg) 11 jun 2009 19:48 (CEST)

Ik ben bang dat jullie het filter niet goed begrijpen. Gaat het om de alinea waar ook de handtekening al in staat, en daar doe je een wijziging in, dan gaat het filter niet af. Het kan zo zijn dat als je een lange bijdrage hebt, en je doet een aanvulling in een eerdere paragraaf, dat het filter dan vals positief afgaat. Daarom noemt het waarschuwingssjabloon dat ook. Verder zijn overlegbijdragen zonder handtekeningen behoorlijk vervelend. Als het filter inderdaad vaak ten onrechte afgaat, en dat valt niet onder controle te krijgen door slimmer te filteren (ik heb nu bijvoorbeeld ook het kopje uitgesloten), wil ik er best vanaf zien het in te voeren. Maar betuttelen vind ik het niet, als we proberen op vriendelijke toon voorkomen dat iemand het afz-sjabloon van stal moet halen. Lymantria _overleg 11 jun 2009 23:15 (CEST)

Voor de duidelijkheid, in principe voor dit filter. Ik vind zeker niet dat het misbruikfilter alleen vandalisme mag afvangen, dan zou het filter 'voorbeeldknoppen' ook al niet kunnen ... Vergeten handtekeningen zijn een ergenis, en kosten inderdaad tijd. Ik dacht alleen hardop na over de gevolgen. Afwachten wat het filter de komende dagen doet. Akoopal _overleg 11 jun 2009 23:53 (CEST)

 Tegen. Het filtersysteem is tegen duidelijk vandalisme - het doen van een kliederedit in de hoofdnaamruimte hoort daar wat mij betreft wél bij - maar een handtekening vergeten is geen vandalisme, hooguit een ongewenste gewoonte die af zou moeten worden geleerd - maar dát is een heel ander verhaal en vind ik om eerlijk te zijn een beetje betuttelend. Als er vervolgens ook nog eens bewerkingen als deze worden gemarkeerd, zijn we denk ik niet op de goede weg. Niet elke edit op een overlegpagina is een reactie immers. nl:Mark W (Mwpnl) ¦ talk 12 jun 2009 00:01 (CEST)

Zolang er dit soort vals positieven zijn in het filter, ben ik dat met je eens. Over de algemeen betuttelende teneur niet. Bijdragen aan overleg doe je met ondertekening. Voor ervaren gebruikers is dat iets als "stom, vergeten" en die zullen ondanks dat ze weten dat het niet klopt dat ze geen handtekening zetten, het filter irritant-betuttelend vinden. Veel niet ervaren gebruikers zullen niet weten hoe ze een handtekening moeten zetten, voor hen is zo'n waarschuwing juist prima. Dan is er de groep die eigenlijk helemaal niet wil overleggen, maar wil klieren. In een overleg zetten "allemaal onzin" ofzoiets. Juist die groep wil ik ook vangen natuurlijk. Door goed naar de logboeken te kijken probeer ik het filter te verbeteren. Zo heb ik de voorwaarde dat de gebruiker die de edit doet niet bij de recente gebruikers staat toegevoegd. Er is altijd nog de optie om het filter alleen op nieuwe en oningelogde gebruikers toe te passen. Lymantria _overleg 12 jun 2009 07:28 (CEST)

Sterk tegen invoeren. Dit is een misbruikfilter, geen "u bent iets vergeten"-filter (of een "u voegt acht spaties toe!"-filter, wat dat betreft). paul b 12 jun 2009 00:46 (CEST)

Het filter draait nu bijna een week. Als ik het logboek doorkijk, doet het filter zijn werk naar behoren. Hopelijk laten gebruikers met dit soort edits zich door de ondertekening afschrikken, en kan een boel {{afz|...}} voorkomen worden. Ik stel voor het filter wel in te schakelen in "waarschuwings"modus. Lymantria _overleg 20 jun 2009 09:32 (CEST)

Hopelijk laten mods voortaan het verwijderen van dergelijke bijdragen achterwege. De opmerking was niet super-relevant, maar had wel degelijk betrekking op het artikel! Als dit de gang van zaken wordt, en het filter voornamelijk overijverige vandalismebestrijders gaat aantrekken die van het onderwerp geen kaas gegeten hebben maar wel willekeurige niet-ondertekende bijdragen als vandalisme of "geen zinvolle inhoud" menen te herkennen, dan kunnen we dit filter missen als kiespijn! paul b 20 jun 2009 10:56 (CEST)

Nou nou, wat een frontale aanval zeg. Ik zag in het artikel noch Grinnus noch Rhenen. Ik zie nu dat ik daar te snel in geweest ben. Overigens heeft dat weinig met dit filter te maken. Ik had natuurlijk een beter voorbeeld moeten zoeken, zoals deze. Laten we het verder proberen zakelijk te houden, ajb. Lymantria _overleg 20 jun 2009 11:05 (CEST)

Als iemand met droge ogen beweert dat het toch wel fijn is dat dergelijke overlegbijdragen worden afgeschrikt, dan gaan mijn nekharen overeind staan. Niettemin viel ik harder uit dan nodig was, excuus daarvoor. In ieder geval hartelijk dank voor het terugplaatsen. paul b 20 jun 2009 11:15 (CEST)

Omdat dit filter toch wel wat impact hebt en weerstand kan oproepen, van deze even een melding op WP:OG maken? Akoopal _overleg 20 jun 2009 10:30 (CEST)

Prima. Lymantria _overleg 20 jun 2009 11:05 (CEST)

 Voor Iedereen die normaal gesproken handtekening zet maar vergeet is hiermee gebaat, en iedereen die nieuw is wordt er mee gecorrigeerd. Als je niet betutteld wilt worden, moet je niet dit soort fouten maken. --BDijkstra 21 jun 2009 13:13 (CEST)

 Voor - tekst filter is compleet en ondervangt volgens mij de kritiek. Eens met BDijkstra MoiraMoira _overleg 22 jun 2009 17:28 (CEST)

 Uitgevoerd - waarschuwingsmodus ingeschakeld gezien de reacties. Lymantria _overleg 25 jun 2009 22:42 (CEST)

Ik tel twee keer voor, en twee keer tegen het activeren van dit filter. Op basis waarvan vond je de argumenten tegen inschakeling niet opwegen tegen de argumenten voor inschakeling? nl:Mark W (Mwpnl) ¦ talk 26 jun 2009 00:49 (CEST)

Ik heb na de aanvankelijk geuite bezwaren het filter zeer flink aangepast, zodat het niet makkelijk zal afgaan als er niet daadwerkelijk een overlegbijdrage komt. Het filter gaat niet meer af bij een bot, bij een gebruiker die recent al aan het overleg heeft bijgedragen, bij een edit in op eigen overlegpagina's, bij het maken van onzichtbare opmerkingen, het plaatsen van dossier-meldingen met een # of het plaatsen van een sjabloon (bijv. hola). Nadat dat zo een week gedraaid heeft, heb ik voorgesteld om het in te schakelen, en tevens op WP:OG reactie gevraag. Daarop heb ik juist twee keer een reactie voor gehad, en alleen van Paulb een negatieve reactie. Verder is het vergeten van handtekeningen onder een overlegbijdrage wel degelijk een hinderlijke fout. Lymantria _overleg 26 jun 2009 07:29 (CEST)

Ik meen hierboven ook duidelijk commentaar te lezen van Romaine en van mijzelf, commentaar dat niet direct wordt opgelost met de argumenten die jij hier ter tafel voert. Dat telt eveneens voor de argumenten van Paul b. Ik meen niet dat het vragen om overleg reden is om oude argumenten plotseling te negeren. Misbruikfilters zijn in het leven geroepen om bij duidelijk vandalisme/misbruikt counteracties te doen. Het vergeten van een handtekening is geen misbruik. Bij gebrek aan een duidelijke consensus heb ik het filter daarom weer uitgeschakeld. nl:Mark W (Mwpnl) ¦ talk 26 jun 2009 14:30 (CEST)

Ik ben het voorledig met Mark eens, dit filter is niet nodig danwel geschikt voor actief gebruik. Huib talk^{Abigor @ meta} 26 jun 2009 20:03 (CEST)

Mij best, Mark. Dan starten we hier wel een peiling over. Maar in mijn ogen waren bezwaren als "Het komt vaak genoeg voor dat ik mijn eigen typfouten wil corrigeren (en die ga ik dus niet ondertekenen)" perfect ondervangen. Lymantria _overleg 26 jun 2009 20:14 (CEST)

Kom op zeg, we gaan toch niet peilen over een filter... Ik kan me verschillende redenen bedenken waarom je overleg niet ondertekend. Het niet ondertekenen is ook geen misbruik, waar we het wel over een misbruikfilter hebben. Als hier een peiling over begonnen word dan zakt mijn broek ervan af, hebben we geen betere dingen te doen dan Peilen? Huib talk^{Abigor @ meta} 26 jun 2009 20:21 (CEST)

Het willen aanpassen van typfouten is slechts een van de dingen die op overlegpagina's kunnen plaatsvinden, net als het toevoegen van tekst of een sjabloonfout eruit halen. En dan nog blijft het bezwaar dat het misbruikfilter bedoeld is voor misbruik en niet voor gebruikersbetutteling staan. Op de richtlijnpagina staat bij het 2e deel: "Nadat het filter een week zonder problemen en zonder significante wijzigingen heeft gedraaid in log-only mode, en er is voldoende steun, dan wel geen bezwaar op het filter wordt ontvangen, kan het filter geïmplementeerd worden door de juiste actie eraan te koppelen." -> 3 tegen, 2 voor is overduidelijk onvoldoende steun. groetjes - Romaine (overleg) 26 jun 2009 20:32 (CEST)

Als je Akoopal en mij perse niet mee wil tellen klopt dat. De peiling loopt hier. Lymantria _overleg 26 jun 2009 20:38 (CEST)

Zelfs al zouden er 3 voor en 3 tegen zijn, dat is nog steeds overduidelijk onvoldoende steun. Romaine (overleg) 26 jun 2009 20:55 (CEST)

Wat is er op tegen om een misbruikfilter te gebruiken voor iets dat geen misbruik is? --BDijkstra 27 jun 2009 15:47 (CEST)

N.a.v. Peiling uitgeschakeld. Lymantria _overleg 5 jul 2009 13:21 (CEST)

Gebruikersnaam aanmaken

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: Het filter moet letten op aanmaken van gebruikersaccounts die niet aan de richtlijnen voldoen. Een makkelijk te maken filter is bijvoorbeeld voor gebruikersnamen met meer dan 6 cijfers ([\d]{7,}) en voor gebruikersnamen met email-adressen (contains @), websites (contains www.) of ip-adressen (^([\d\.]*)$). Zie: sjab:og
• Waarom: Omdat een Wikipedia-gebruiker anders met dit sjabloon wordt gewezen dat zijn gebruikersaccount wordt geblokkeerd met een softblok; het kan hiermee korter en gebruiksvriendelijker.
• Gevolgen: Verhinderen en gebruiksvriendelijk bericht wat grofweg de criteria zijn.

Gebruikersnamen met websites, is misschien niet 'waterdicht' gedekt met "www." (dat hoeft ook niet). Daarnaast zou het misschien false positives kunnen opleveren (al weet ik niet zo snel wat). Kijk maar even wat jullie er mee doen. Ook misschien langere testperiode? Sum^?urai8^? 1 jun 2009 20:58 (CEST)

Sympathiek idee, maar dankzij de SUL denk ik niet dat we het moeten doen. Op andere wiki's gelden niet dezelfde eisen aan een accountnaam als hier, maar er kan wel geSULd worden. Als een gesulde gebruiker van bijv. en-wiki hier toevallig eens heen komt surfen met een account met 8 cijfers achter elkaar, zou die te zien krijgen dat zijn inschrijving op nl-wiki niet wordt geaccepteerd - wat misschien nog wel zwaarder is dan geblokkeerd worden (want dan kan hij hier nog wel lezen onder de accountnaam, in plaats van steeds zijn inschrijving verhinderd te zien). Zolang van een dergelijk "automatisch aangemaakt" account geen edits komen, is er ook geen probleem. Dus laten we dit filter maar niet doen. Lymantria _overleg 1 jun 2009 21:46 (CEST)

Eens met Lymantria, Door de ontwikkeling van SUL zou dit voor problemen kunnen zorgen. Huib talk^{Abigor @ meta} 1 jun 2009 21:51 (CEST)

Op en-wp is er ook een filter actief die controleert op ongewenste gebruikersnamen. Ik kan 'vanwege veiligheidsredenen' niet inzien. Zou er geen onderscheid gemaakt kunnen worden tussen action=createaccount op speciaal:aanmelden en 'onthefly' accounts aanmaken? Sum^?urai8^? 1 jun 2009 21:52 (CEST)

Edit: Met article_prefixedtext == "Speciaal:Aanmelden"? Sum^?urai8^? 1 jun 2009 21:55 (CEST)

Lymantria geeft een probleem aan wat niet bestaat. Het filter controleert niet op automatisch aangemaakte gebruikersnamen. Alleen gebruikersnamen die hier worden aangemaakt worden aan het filter onderworpen. Er kan dus nog steeds geSULd worden. Nogmaals: SUL-gebruikersnamen zijn niet aan deze test onderhevig. nl:Mark W (Mwpnl) ¦ talk 1 jun 2009 22:06 (CEST)

Voor degene die geïnteresseerd zijn: /([\d]{7,}|^([\d\.]*)$|@|www\.)/i does the job. Noot dat de laatste twee ook via contains_any gedaan kunnen worden. Aan jullie om uit te zoeken welk filter sneller is. Sum^?urai8^? 1 jun 2009 22:20 (CEST)

Wat is het voordeel van dit filter boven de MediaWiki:Titleblacklist, de oude Usernameblacklist? Ciell 1 jun 2009 22:27 (CEST)

@Ciell: Dit filter geeft een 'waarschuwing/bericht' die uitlegt wat er aan de hand is. De mediawiki-pagina's kennen die functionaliteit niet.

Zou het volgende filter voldoen? (Ik weet niet of de syntax goed is overigens en of accountname werkelijk de nieuw aangemaakte accountgegevens bevat...)

action = 'createaccount'
& accountname rlike /([\d]{7,}|^([\d\.]*)$|@|www\.)/i

Sum^?urai8^? 1 jun 2009 22:31 (CEST)

Opmerking van mijzelf: ^([\d\.]*)$ reageert ook bij 1. of zelfs een helemaal lege username. Misschien beter om een code als: ^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$ te gebruiken.... Sum^?urai8^? 1 jun 2009 22:35 (CEST)

Dus dan ga je niet beletten, maar waarschuwen, als ik je goed begrijp. Pseudo-ip adressen worden door de blacklist al geblokt, dus hoeven ook niet meer gewaarschuwd te worden? Ciell 1 jun 2009 22:39 (CEST)

 Uitgevoerd Aangemaakt in log-only nadat MarkW de twijfels heeft weggenomen. Lymantria _overleg 2 jun 2009 07:20 (CEST)

Kan je ook meteen een opzetje maken voor de meldtekst? Dat is bij dit soort filters net zo belangrijk als het filter zelf, en zou ook in de discussie meegenomen moeten worden. Kwa filter vind ik waarschuwen hier genoeg, niet verhinderen wat mij betreft. Akoopal _overleg 2 jun 2009 11:57 (CEST)

Is het filter niet nodeloos ingewikkeld als je het ip-gebeuren erin laat staan? Ciell 2 jun 2009 12:51 (CEST)

Qua opzet moet het een beetje overeenkomen met sjabloon:og. Ik stel na mijn examen wel iets op.

Ik bedenk me net, dat het misschien beter is om www\. te vervangen door (\.(nl|com|org|net))$. Komt denk ik vaker voor dat een gebruikersnaam eindigd op .nl, .com, .org, .net dan dat het begint met www. ... Je zou het ook als extra optie in de regex kunnen plaatsen... Sum^?urai8^? 2 jun 2009 13:04 (CEST)

Maar dan snap ik het nut helemaal niet meer, aangezien de blacklist het aanmaken van dergelijke accounts al voorkomt? Ciell 2 jun 2009 13:07 (CEST)

Ter verduidelijking: ook de blacklist waarschuwt: maak je nu een gebruiksnaam aan die niet voldoet, krijg je de volgende melding: Aanmeldfout U heeft een ongeldige gebruikersnaam opgegeven of de door u gekozen gebruikersnaam voldoet niet aan de eisen: bepaalde tekens (zoals @) en ip-adressen zijn niet toegestaan (zie ook de criteria voor een gebruikersnaam). Ciell 2 jun 2009 18:13 (CEST)

Het lijkt me inderdaad meer voor de hand te liggen om de check op meer dan 6 cijfers toe te voegen bij MediaWiki:Titleblacklist. Lymantria _overleg 3 jun 2009 07:59 (CEST)

Daar wordt dan MediaWiki:Noname ingeladen. Je moet vervolgens naar een andere pagina toe, wat weer een gedeelte is van een enorme pagina. Daarna moet de gebruiker weer de weg terugvinden. Waarom er niet een gebruikersvriendelijkere pagina is gebruikt, met de criteria gewoon ingeladen in het mediawiki-bericht, begrijp ik niet. Bovendien wordt dit bericht ook getoond, als een gebruikersnaam opnieuw wordt aangemaakt.

Waarom een filter gebruiken: De blacklist wordt geladen bij IEDERE pagina. 99% van die pagina's heeft niets aan die hele pagina, omdat er alleen maar gebruikersnamen op staan. Toch wordt iedere keer weer de hele pagina doorgespit op zoek naar regels waar de bewerking aan voldoet. Dit filter is sneller, omdat het filter wordt afgebroken als de actie /niet/ createaccount is.

Daarnaast is het nu mogelijk om te splitsen tussen opnieuw aangemaakte accounts (lees: Trollen die (mogelijk) (willen) doen alsof ze iemand anders zijn) en accounts die (mogelijk) niet voldoen aan de criteria (lees: Mensen die er vriendelijk op gewezen moeten worden hoe ze hun gebruikersnaam moeten aanpassen).

Het filter heeft dus wel degelijk zin. Om pseudo-ip-adressen te blokkeren ipv. te waarschuwen kan ik inkomen. De rest kan ook prima gedaan worden met een waarschuwing. Sum^?urai8^? 3 jun 2009 08:57 (CEST)

---

Ik heb zojuist even het filter getest. Gebruikersnaam user:MFTester1234567 werd wel door het filter gedetecteerd, maar user:Www.MFtester niet. Dat komt waarschijnlijk omdat de tekst case-sensitive is... Misschien www\. vervangen door [Ww]{3}[\. ] (Deze [\. ] omdat user:WWW Media ook ongewenst is...) Sum^?urai8^? 4 jun 2009 09:50 (CEST)

---

Ik zou eigenlijk liever eerst een algemene discussie zien over met welke gebruikersnamen we nu echt problemen hebben. Dat dit beter werkt dan een blacklist ben ik het in beginsel wel mee eens, maar tegelijk is het ook ontoegankelijker/onbegrijpelijker voor mensen van andere communities. Maar in any case, graag eerst een discussie binnen de gemeenschap, omdat ik dit toch wel een vrij ingrijpende wijziging vind, zeker bij zes cijfers enzo, wat altijd alleen maar een interpretatie is geweest die als waarschuwing is neergezet in the end. Effeietsanders 7 jun 2009 10:51 (CEST)

Aangezien dit filter al een hele tijd hangt, en er geen consensus lijkt te bestaan heb ik het filter uitgezet. Akoopal _overleg 30 jun 2009 19:38 (CEST)

Testfilter schuttingtaal

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: Uitfilteren van meer schuttingtaal - bij succesvolle test deze woorden invoegen bij filter 10
• Waarom: Veelal scholierengeklieder
• Gevolgen: Waarschuwen
• Waarschuwingstekst: Sjabloon:Misbruikfilter-waarschuwing-schuttingtaal

De te testen woorden voor nu zijn: poep, poepen (met vervoegingen), kaka, pies, piesen (met vervoegingen), pipi, je moeder (evt zonder spatie), kak, kakhoofd, schijt(en), klootzak(ken). Lymantria _overleg 3 jun 2009 11:15 (CEST)

Deze woorden zijn overgeheveld naar filter 10. Nieuwe woorden in het testfilter gestopt: gay, kont, stront, shit, hoer, tiet(en), tet(ten), kanker (met eventueel wat erachter) en u(w) moeder. Lymantria _overleg 10 jun 2009 11:25 (CEST)

"Kanker" graag eruit halen. Dat is de normale naam van een veel voorkomende ziekte en zal dus ook in veel goede bewerkingen voorkomen. Hoopje 10 jun 2009 11:57 (CEST)

Ik verwacht eigenlijk niet dat het woord kanker door anonieme gebruikers regelmatig zal worden toegevoegd in een positieve content. Sterker nog: het huidige logboek laat geen één keer een positieve toevoeging zien. Die ene anonieme uitzondering die wél iets zinvols toevoegt met het woordje kanker erin zal zich niet laten tegenhouden door een vriendelijke waarschuwingstekst. Wat mij betreft geen reden om eruit te halen dus. nl:Mark W (Mwpnl) ¦ talk 10 jun 2009 16:37 (CEST)

Per MarkW, bovendien slaat het filter alleen aan als het woord nieuw geïntroduceerd in het artikel. Lymantria _overleg 10 jun 2009 16:56 (CEST)

De vorige lijst is weer overgeheveld naar filter 10. Nieuwe filterwoorden: piemel, pik(kie), porno, stinkt e.d., homeau, pedo, sucks e.d., hoerenzoon en motherfucker met variaties. Lymantria _overleg 17 jun 2009 23:16 (CEST)

Van de lijst van vorige week heb ik porno niet overgeheveld naar filter 10, de rest wel. Porno blijkt veel aan te slaan met artikelen over porno-actrices. Nieuwe woorden: zuigt, lol (tbv kwebbelfilter), bitch, hamo en het voorvoegsel tering-. Lymantria _overleg 24 jun 2009 13:35 (CEST)

Op zuigt na overgeheveld naar de filters. Nu kan het filter voorlopig even dicht bij gebrek aan nieuwe "aanvoer". Lymantria _overleg 2 jul 2009 09:08 (CEST)

Er is nieuwe invoer: klote. Dat woord wordt in testmodus toegevoegd. Lymantria _overleg 17 jul 2009 07:15 (CEST)

Is na ruime, maar wat schuttingtaal betreft rustige, testperiode overgeheveld naar het schuttingtaalfilter. Testfilter is weer uit. Lymantria _overleg 2 aug 2009 11:42 (CEST)

Schuttingtaal:Kanker

Status: Actief

bewerken · geschiedenis · logboeken · testen

Graag een onderzoekje hoe vaak woorden die "kanker" bevatten nu eigenlijk terecht dan wel onterecht afgevlagd worden. Voor gebruikers is het nogal raadselachtig als dit filter afgaat op stukken tekst die geen enkel duidelijk scheldwoord bevatten. Wellicht is het mogelijk het als een apart filter af te splitsen om zo wat statistiek te krijgen (het filteren van filterlogs voor dat doeleinde lijkt nl. vrij lastig). Als er te veel vals-positieven opduiken, zouden we w.m.b. moeten overwegen het filter aan te passen. paul b 3 sep 2009 11:42 (CEST)

Hoi,

Ik denk dat het een goed idee is om kanker uit het bestaande filter te halen en even in een apart filter (log only) te zetten.

Ik kan me opzich heel goed voorstellen dat het woord regelmatig in een artikel zal worden gebruikt en daardoor veel valse positieven geeft.

Als ik geen bezwaren hoor ga ik ermee aan de slag.

groet,

Huib talk^{Abigor @ meta} 3 sep 2009 12:14 (CEST)

Ik heb een tijdelijk filter gemaakt (hier) zodat we kunnen checken hoevaak hij nu afgaat, Ik hoop dat dat is wat je bedoeld. Huib talk^{Abigor @ meta} 3 sep 2009 14:52 (CEST)

Dat lijkt het bijna te zijn, ik geloof dat in het oorspronkelijke filter iets staat met "lcase" (zodat het ongevoelig is voor wel of geen hoofdletters) en "kanker[a-z]*", vermoedelijk om ook op samengestelde woorden af te gaan. paul b 3 sep 2009 16:31 (CEST)

Ik heb het even gefixt. Het oorspronkelijke filter keek inderdaad naar woorden die met kanker beginnen. En keek ook of er niet al dergelijke woorden in de oude tekst stonden. Lymantria _overleg 3 sep 2009 23:11 (CEST)

Ik heb het waarschuwingssjabloon Sjabloon:Misbruikfilter-waarschuwing-schuttingtaal tekstueel wat meer op deze mogelijke vals positieven toegespitst. Ik heb een steekproef genomen uit de filtermeldingen until now. M.i. vrijwel allemaal terecht, maar niet geheel en al allemaal. Lymantria _overleg 16 sep 2009 14:49 (CEST)

Om een irc discussie even samen te vatten, het lijkt mij een goed idee om kanker uit het algemene filter te halen, en dit filter als specifiek filter te gaan gebruiken. Dan kan je een wat specifiekere waarschuwingstekst maken die duidelijker verteld dat de waarschuwing ook onterecht kan zijn, en wat beter nog wat uitzondering maken, zoals bijv de aanwezigheid van een medisch disclaimer. Akoopal _overleg 16 sep 2009 23:12 (CEST)

Agreed, en wat mij betreft dan ook checken op reeds aanwezige woorden als "carcinoom", "gezwel", "tumor" e.d. Het filter moet dan dus echt beter worden - en het waarschuwingssjabloon kan dan vriendelijker. Lymantria _overleg 16 sep 2009 23:15 (CEST)

Ik stel het volgende filter voor om te testen:

!("autoconfirmed" in user_groups) 
& (lcase(added_lines) rlike "\bkanker[a-z]*\b") 
& !contains_any(old_wikitext,"kanker","gezwel","ziekte", "carcinoom","medisch","uitzaaiing","leukemie")

Dit filter slaat aan bij bewerkingen door niet-autoconfirmed gebruikers, die het woord kanker invoeren met eventueel een achtervoegsel (geen voorvoegsel) in een tekst waarin nog niet het woord kanker, gezwel, ziekte, carcinoom, medisch (incl. de disclaimers), uitzaaiing of leukemie voorkomt.

Dit is mijn voorstel voor een waarschuwingssjabloon. Lymantria _overleg 22 sep 2009 22:15 (CEST)

Zowel de waarschuwingstext als het filter zelf kan ik prima mee leven. Nu even aanzien wat het doet. Akoopal _overleg 23 sep 2009 11:54 (CEST)

Op proef ingeschakeld. Lymantria _overleg 1 okt 2009 18:16 (CEST)

Werkt bijna perfect, ik ben 1 foutieve melding tegengekomen: hier. Ik pas het filter (in de testmode) nog een klein beetje aan om dit soort foutmeldingen (met nieuwe artikelen) te voorkomen. _LolSimon -?- 12 okt 2009 18:10 (CEST)

Inmiddels aangepast: als de toegevoegde tekst één of meerdere van de volgende woorden bevat zal het filter niet aanslaan (om foutieve meldingen te voorkomen): "gezwel", "kankerverwekkend", "carcinoom","medisch","uitzaaiing" en "leukemie". _LolSimon -?- 12 okt 2009 18:20 (CEST)

Gezien het feit dat dit filter inderdaad veel nauwkeuriger werkt dan het schuttingtaalfilter en ook een gepaster waarschuwingssjabloon heeft, heb ik de waarschuwingsmodus ingeschakeld en het woord kanker verwijderd uit het schuttingtaalfilter. Lymantria _overleg 15 okt 2009 11:42 (CEST)

Schuttingtaal testfilter

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: Testen op het gebruik van "wtf" ter eventuele toevoeging bij het schuttingtaalfilter.
• Waarom: Herhaald in vandalistische context waargenomen
• Gevolgen: N.v.t.
• Waarschuwingstekst: N.v.t.

Lymantria _overleg 8 okt 2009 10:55 (CEST)

Succesvolle test met beperkt aantal hits. Naar schuttingtaalfilter overgeheveld. Lymantria _overleg 15 okt 2009 11:42 (CEST)

Schuttingtaal testfilter: kk

Status: Uitgeschakeld

bewerken · geschiedenis · logboeken · testen

• Taak: Testen op het gebruik van "kk" ter eventuele toevoeging bij het schuttingtaalfilter.
• Waarom: Herhaald in vandalistische context waargenomen
• Gevolgen: N.v.t.
• Waarschuwingstekst: N.v.t.

Lymantria _overleg 14 dec 2009 11:47 (CET)

Test succesvol. Overgeheveld naar schuttingtaalfilter. Lymantria _overleg 23 dec 2009 10:43 (CET)