Wikipedia:Bearbeitungsfilter/Anträge

Auf dieser Seite können Vorschläge für einzelne Regeln des Missbrauchsfilters (auch bekannt als AbuseFilter) eingereicht werden.

Archiv

Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 2 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

bechterev aka evakuierungstroll aka 84.167.* ...

• Regel #3
• Regel #4
• Regel #5
• Regel #17
• Regel #18
• Regel #29

gudn tach!
die regeln sind zwar schon aktiv, aber da ich ja auch selbst der meinung bin, dass alle regeln auch oeffentlich dokumentiert werden sollen, moechte ich hiermit die (angepasst umfomulierte) e-mail an die buerokraten wiedergeben:
um das bereits jahre dauernde treiben des sog. evakuierungstrolls (siehe dazu user talk:lustiger_seth/84.167.*) einzudaemmen, koennten zwei regeln aktiviert werden:

1. die unnuetzen aenderungen des users als ip sollten komplett geblockt (nicht nur mit einer warnung versehen) werden. ich habe seit >1a alle aenderungen seiner ip-range 84.167.128.0/17 mitverfolgt. ich bin mir deshalb (heuristisch) sicher, dass in ueber 99% (ich vermute sogar: in 100%) aller hiermit getriggerten faelle auch wirklich nur der besagte user mit diesem block konfrontiert wuerde, es sei denn, er aendert sein verhalten erheblich. es bietet sich evtl. ein eigener blockhinweis (z.b. "abusefilter-bechterev") an, den ich bei bedarf formulieren wuerde.
2. um zudem seine troll-socken besser zu finden, sollten zusaetzlich suspekte edits geloggt/getaggt werden, jedoch ohne warnhinweise oder aehnliches, um andere user nicht zu stoeren.

die regeln dafuer gab ich an und passte sie noch ein paar mal an verschiedene sachen an. die filter-ids sind #3 und #4. -- seth 01:16, 31. Mär. 2009 (CEST)

Das ist doch der Rechtschreibtroll, der es auch schon auf meine Artikel abgesehen hatte...? Die Filter haben eine recht grosse Trefferzahl, dafür dass es sich nur um einen einzigen Benutzer handeln soll. Sind da wirklich keine Falschmeldungen dabei? Ich kann die Ergebnisse (noch...) nicht ansehen. -- PaterMcFly Diskussion ^Beiträge 09:03, 31. Mär. 2009 (CEST)

gudn tach!

ob es derselbe ist, der es auf deine artikel absah, weiss ich nicht. bechterev macht so ca. 10 edits pro tag (ganz grobe schaetzung).

es sind ja zwei regeln #3 und #4: die erste, #3, die auch edits verbietet, hat bisher eine quote 100% afaics. die regel #4 dagegen macht nix ausser mitloggen, also gibt nicht mal ein warning aus, sodass niemand gestoert/behindert wird. da bechterevs edits mit dem AF nicht ganz so gut getriggert werden koennen, sind da die false positives zwar recht hoch, aber die regel #4 soll eh nur dazu dienen, socken (also neue accounts oder offene proxies) von bechterev zu finden. dass die trefferzahl der zweiten regel so hoch ist, liegt aber auch an zwei zusaetzlichen dingen: 1. das tagging des AF hat noch ne macke, die manche edits doppelt zaehlen laesst, 2. bechterevs standard-ip-range wird dort ebenfalls noch mal aufgefuehrt (hab ich aus performance-gruenden so gemacht).

dass unter den false positives der zweiten regel sich relativ viele vandalen oder aehnliches befanden, die nix mit bechterev zu tun hatten, ist noch mal eine andere sache. ;-) -- seth 11:48, 31. Mär. 2009 (CEST)

Ja, das habe ich gesehen, war auch keine Kritik, nur eine Frage. Gegen Filter, die nach potentiellen Vandalenaktionen "fischen" ohne Benutzer zu Behindern, gibt's von meiner Seite nichts einzuwenden (oder kommen da jetzt die Datenschützer? Systematische Überwachung und so?). Übrigens: Ist es Absicht, dass die Filter plötzlich öffentlich sind, waren sie doch vorher nicht, oder übersehe ich da was? -- PaterMcFly Diskussion ^Beiträge 21:50, 31. Mär. 2009 (CEST)

gudn tach!

hab deine fragen nicht negativ aufgefasst. :-) sorry, falls meine antwort dennoch so rueberkam.

dass die beiden filter jetzt komplett oeffentlich einsehbar sind, war absicht (wenn auch nicht von mir). siehe dazu Hilfe_Diskussion:Missbrauchsfilter#Filterbeschreibungen. -- seth 23:29, 31. Mär. 2009 (CEST)

als ergaenzung zur regel #3: ich habe heute die betreffende range erweitert von /17 auf /16, da bechterev offenbar sich in die andere 17-er-range eingeklinkt hat. evtl. kommt es daher, dass er jetzt den quellcode des filters lesen kann oder weil er hier mitliest. da ich ueber die api und ucuserprefix=84.167. sowieso immer alle edits von usern aus der 16-er-range angezeigt bekommen habe, kann ich noch abschaetzen, dass nach meiner erweiterung der range ebenfalls keine bis kaum false positives auftreten werden. falls tatsaechlich dennoch ein nicht-vandale dadurch geblockt werden sollte, werde ich selbstverstaendlich das filter wieder auf die 17-er-range einschraenken. in den letzten 12 monaten war die andere ip-range allerdings eher sehr wenig konstruktiv. -- seth 23:29, 31. Mär. 2009 (CEST)

Da Bechterev sich nun immer anmeldet, um seine nicht-erlaubten Edits doch noch durchzudruecken, werde ich Regel #3 erweitern: Bisher wird nur seine IP-Range geblockt. Ich werde es so aendern, dass auch andere nicht-autoconfirmed User geblockt werden, wenn sie solche Aenderungen durchfuehren, unter der zusaetzlichen Voraussetzung, dass Bechterev unter den letzten Editierern war. -- seth 22:09, 9. Apr. 2009 (CEST)

Dagegen, das geht mir zu weit. --Complex 22:10, 9. Apr. 2009 (CEST)

Hab's noch nicht umgesetzt. Es waeren aber eh nur wenige Edits, sodass es mir keine grossen Probleme bereitet, sie weiterhin einzeln durchzugehen. Ich vermute, dass weiterhin die Trefferquote von 100% gehalten werden kann.

Mir ist noch eine Verbesserung eingefallen: Statt Autoconfirmed-Status koennte man den Edit-Count des Users abfragen. Der User muesste dann z.B. mind. 20 Edits durchgefuehrt haben.

Die Alternative waere wieder die Semi-Sperre von mehreren Artikeln. Ich denke, da ist das AF die deutlich bessere Moeglichkeit. -- seth 00:07, 10. Apr. 2009 (CEST)

Auch mit der Modifikation geht mir das noch immer zu weit. Für so ein marginales Problem werden mir potenziell zu viele sinnvolle Änderungen und Good-Faith-Edits von Neubenutzern und IPs geblockt. --Complex 11:52, 10. Apr. 2009 (CEST)

Ich praezisiere mal mein Vorhaben, dann wird's vielleicht deutlicher.

Bisher: alte_bedigung = (user==84.167.* && (bestimmter_artikel || (diffsize==klein && typischer_edit)))

Geplant: neue_bedingung = (alte_bedigung || (user_edits<20 && diff_size==sehr_klein && aktueller_typischer_edit && 84.167.* in last_users ))

Dabei ist "aktueller_typischer_edit" nur eine Auswahl der Edits, die zurzeit in der alten Regel fuer die IP-Range verwendet werden; und zwar immer diejenigen Edits, die Bechterev gerade versucht durchzudruecken, die jedoch gemaess moderner Woerterbuecher unnuetz/falsch sind.

Ich habe so eine neue moegliche Regel mal gegen fast alle von #4 gematchten Edits laufen lassen und da gab's keine false positives. -- seth 17:53, 10. Apr. 2009 (CEST)

Ich halte es trotzdem für potenziell schädlicher als so breit zu autofiltern. Irgendwelche Reverts, die so was enthalten (typisch: Vandalismus, dann bechterev, zurück auf Version vor Vandalismus) sind dann nicht mehr möglich. Nein danke. --Complex 17:55, 10. Apr. 2009 (CEST)

Hmm, hab dein Beispiel wohl noch nicht verstanden. Also 1. Vandalismus, 2. Bechterev, 3. Revert auf Version vor Vandalismus. Wenn der dritte Edit durch die neue #3 geblockt wuerde, muesste dafuer der Vandalismus sowas wie ein Gegenspieler von Bechterev sein, der dazu auch noch doppelt so gut wie Bechterev ist. Koenntest du das Beispiel etwas naeher erlaeutern? Ach so, aber waehrend wir hier diskutieren, werde ich schon mal eine Testregel basteln, die nur mitloggt, also ohne action. -- seth 23:26, 10. Apr. 2009 (CEST)

Angesichts dessen, dass Du nicht mal selbst sicher zwischen Bechterev und Bechteverv-Gegenspieler unterscheiden kannst (kein Vorwurf), wäre das genannte Szenario schädlich, da es wohl zwangsläufig zu Fehlern kommen wird. Lieber ein revertierter Vandalismus mehr und ein vergraulter User weniger als x unnötige wandte/wendete Edits, die nicht wirklich schaden, sondern nur nerven. Da überzeugen mich auch x Wochen "0 Treffer" in irgendeiner Testregel nicht. Ach ja: e1 und e2 sind immer noch ungeeignete Filternamen. --Complex 23:35, 10. Apr. 2009 (CEST)

Die von dir genannten Links sind leicht misszuverstehen. Bechterev aendert gerne "-sendet", "-wendet" in "-sandt" bzw. "-wandt", obwohl beide formen meist (es gibt bestimmte Ausnahmen, die er jedoch afaics noch nicht getroffen hat) gleichwertig sind (vgl. Duden[1][2]). Votarier und Wofall waren Sockenpuppen Bechterevs. Die eine Aenderung Bechterevs (als 84.167.210.99) war ein Versehen (vergleiche es einfach mit den anderen Edits der IP-Range), das vermutlich dadurch zustande kam, dass Bechterev haeufig blind revertiert und es ihm hier vermutlich so vorkam, als sei er wieder dran.

Insofern ist dein "angesichts dessen" imho ebenso unpassend wie die die Behauptung, dass es "zwangslaeufig zu Fehlern kommen muesse". -- seth 01:44, 11. Apr. 2009 (CEST)

Danke für die Bestätigung, wie fragil die ganze Sache ist - nach einem erfolgreichen WP:MB und Zustimmung der Community zu dieser Änderung steht dem nichts entgegen, bis dahin sollte die ganze Sache möglichst konservativ gehalten werden. --Complex 01:55, 11. Apr. 2009 (CEST)

Was ist denn fragil an der Sache? Bei der versehentlichen Aenderung von Bechterev hat das AF doch ueberhaupt nichts falsches gemacht. -- seth 02:02, 11. Apr. 2009 (CEST)

Du kannst es nicht mal manuell auseinanderhalten, was von Bechterev kommt und was nicht - wie willst Du dann für alle Nutzer zuverlässig einen Filter programmieren können? Ich habe ja kein Problem, wenn das Ding als "Trollausbremsmaschine" kurzzeitig missbraucht wird, aber dafür, allen Benutzern generell irgdendwelche Arten von Edits, nur weil da mal ein Troll dazwischenfunkte, zu verbieten, sehe ich kein Community-Votum. --Complex 02:08, 11. Apr. 2009 (CEST)

Irgendwas scheine ich falsch erklaert/du missverstanden zu haben. Manuell kann ich es (entgegen deiner Behauptung) auseinanderhalten, was von ihm kommt und was nicht. Die Regeln koennen das offenbar auch recht gut, wenn auch staerker begrenzt. #3 hat beispielsweise bisher immer nur Bechterev geblockt. #4 ist bewusst etwas breitgefaechterter, weil damit ja auch nix geblockt, sondern nur detektiert wird. Die (neue) Testregel hat bisher noch nicht angeschlagen, weil Bechterev wohl derzeit lieber neue Artikel aendert.

Zur "kurzzeitigen Trollausbremsmaschine": OK, ich kann mal probieren, ob es was hilft, wenn ich so ne Regel wie die Testregel im Bedarfsfall fuer 1 oder 2 Tage auf "disallow" stelle. Evtl. genuegt das ja schon (haengt auch ein wenig davon ab, ob Bechterev hier mitliest).

"Allen Benutzern generell [...] Edits [zu verbieten], nur weil da mal ein Troll dazwischenfunkte" ist imho keine adaequate Beschreibung der Testregel (wenn sie auf "disallow" stuende), sondern eher einer Artikel-Semisperre. Die Edits, die getriggert werden, muessen ein ganz bestimmtes Schema erfuellen. Es werden ja nicht beliebige Edits geblockt, sondern nur solche, die verdammt aehnlich zu den schlechten von Bechterev sind. -- seth 19:53, 13. Apr. 2009 (CEST)

"Es werden ja nicht beliebige Edits geblockt, sondern nur solche, die verdammt aehnlich zu den schlechten von Bechterev sind." - und genau das halte ich für zuviel. Bitte lass so was erst durch ein MB absegnen. --Complex 19:56, 13. Apr. 2009 (CEST)

Hmm, nee, erst mal nicht, MBs verbraten immer extrem viel Zeit und die kann ich momentan nicht aufwenden. Ich werde die Testregel dann halt vorerst immer nur im Bedarfsfall kurzzeitig als "Trollausbremsmaschine" verwenden, wie du es oben bezeichnetest, also auf "disallow" setzen. Wenn dir das immer noch zu viel ist, werde ich halt die entsprechenden Artikel semisperren. -- seth 22:20, 13. Apr. 2009 (CEST)

Ersteres scheint okay (für "kurzzeitig" im kleineren einstelligen Stundenbereich), bitte ggf. auf false positives achten und beim ersten solchen abstellen. --Complex 22:22, 13. Apr. 2009 (CEST)

Das mit dem kurzzeitigen Ausbremsen war durchaus ernst gemeint. —Complex 13:31, 10. Okt. 2009 (CEST)

Ich finde es schade, dass du, obwohl du einiges missverstanden hast (z.B. koenne ich angeblich Bechterev nicht erkennen und Aehnliches, was einfach falsch ist), anscheinend darauf aufbauend nun die Anti-Bechterev-Regeln deaktiviert hast, anstatt sie einfach wieder auf die 17er-Range einzuschraenken. Abgesehen davon erklaerte ich weiter unten, dass ich die Regeln schon entschaerfte. Nun denn, Bechterev ist fast taeglich unterwegs, und nutzte zumindest im September zwischendurch auch mal die andere 17er-Range, die also nur per 16er-Range abgedeckt ist. False Positives gab es iirc nach meiner Abschwaechung der Regeln (nach Anfrage von Tinz, siehe unten) keine mehr. Ich wuesste auch nicht, wie ich ohne das AF den sinnlosen Edits von Bechterev Einhalt gebieten koennte, ausser durch Artikel-Sperren (die jedoch eine deutlich groessere Einschraenkung fuer die User bedeuten). Die Artikel-Sperren konnte ich via AF von ca. 50 auf ca. 10 herunterbrechen. Wenn du nun darauf bestehst, dass ich die zweite 17er-Range nicht mehr ueberwachen lassen soll, dann wird sich vermutlich die Anzahl der Artikel-Sperren wieder erhoehen.

Aber nun gut, dann reduziere ich die Regeln eben wieder auf die 17er-Range und freue mich schon jetzt riesig auf den naechsten Angriff von Bechterev, wenn er sich mal wieder in der anderen 17er-Haelfte befindet. -- seth 16:51, 10. Okt. 2009 (CEST)

Erm, jetzt mal von so Geplänkel wie Anti-Bechterev vs. Bechterev und wenig hilfreiches Abqualifiziere - wo habe ich den Konsens verpasst, dass die Filter beliebig lange offen bleiben? Den Verweis auf WP:MB habe ich schon gegeben. —Complex 16:53, 10. Okt. 2009 (CEST)

Zumindest bzgl. des MB hast du wohl recht, da das AF ja bisher offiziell nur als Test-Dings eingerichtet wurde. Das MB sollten wir in Angriff nehmen. Jetzt muss ich allerdings erst mal weg, aber morgen werde ich hoffentlich etwas Zeit haben, damit anzufangen. Wuerde mich freuen (ernsthaft!), wenn du dich bei der Erstellung desselbigen beteiligen wuerdet. Bitte deaktiviere die Regeln so lange nicht, da Bechterev wirklich Dauergast ist und die False-Positives wesentlich besser abschaetzbar sind als bspw. bei dem Diesel-Typ. -- seth 17:00, 10. Okt. 2009 (CEST)

Toller Wheelwar nebst Infragestellung meiner Kompetenz. Auf dieser Basis habe ich keine Lust auf Zusammenarbeit. —Complex 17:02, 10. Okt. 2009 (CEST)

fuer Klaerung einiger Missverstandnissen siehe user talk page

Das MB habe ich jetzt angefangen zu basteln; hab erst mal nur ein paar Stichworte zusammengeschrieben. -- seth 23:52, 12. Okt. 2009 (CEST)

zwischenueberschrift I

Ich habe Regel #3 nun erneut von der 17er- auf die 16er-Range erweitert, da Bechterev sie offenbar gezielt auswaehlen kann, vgl. z.B. [3].

Eie gehabt: Bisher keine false positives und ich gehe alle getriggerten Edits durch.

Die oben von mir vorgeschlagene Pauschalueberwachung habe ich dagegen bisher nicht eingesetzt und sehe derzeit auch keine Notwendigkeit dafuer. -- seth 21:03, 26. Mai 2009 (CEST)

Die Regel #3 hat hat "keine false positives?. [4], [5], [6], [7], das scheinen mir alles sinnvolle Änderungen zu sein, viel weiter habe ich nicht geschaut. Ich habe den Filter bis zur Klärung mal auf tag-only gesetzt. --Tinz 01:19, 28. Mai 2009 (CEST)

Nachtrag: offenbar hat es doch bechterev getroffen (siehe Spezial:Beiträge/84.167.201.156), der jedoch in den ersten beiden Links klar sinnvolle Änderungen machte. --Tinz 11:35, 28. Mai 2009 (CEST)

ja, bisher wurde ausnahmslos bechterev geblockt (das meinte ich mit "keine false positives", und warum sollte ich luegen? das koennte (sollte!) mich schliesslich meinen adminstatus kosten). dass dabei auch ein paar aenderungen von bechterev verloren gehen, die nicht voellig unnuetz sind, habe ich ihm erklaert, jedoch war ihm das egal. wenn er von seinen unsinnigen aenderungen ablassen wuerde, koennte man die regel aufweichen. da er das nicht tut, ist das AF die weniger stoerende massnahme. wie auch immer, die sinnvollen aenderungen, die er durchfuehrt, sind so marginal, dass es sich in den seltensten faellen lohnt, sie manuell umzusetzen/nachzutragen.

ich hab die regel wieder aktiviert, weil bechterev die luecke sehr schnell ausgenutzt hat :-( : [8] ich waere dir verbunden, wenn du die reverts und anderen unnuetzen der aenderungen selbst zuruecksetzen wuerdest. das ueberpruefen der aenderungen macht einen heidenspass... -- seth 21:10, 28. Mai 2009 (CEST)

aber warum blockt der Filter einer Änderung von "Td" zu "Tod" oder ein zugefügtes "und"? Er soll doch nur diejenigen Änderungen blocken, bei denen zwei korrekte Möglichkeiten existieren. Diese sind begrenzt und sollten daher durch eindeutigere Regeln zu erfassen sein, damit so etwas nicht passiert. Diejenige der Bedingungen, die das bewirkt, sollte durch eine bessere ersetzt werden. Und gehst Du oder sonst irgendwer die Edits nach falschen Positiven durch in dem Sinne, dass klar sinnvolle Edits, selbst wenn sie von bechterv stammen, trotzdem ausgeführt werden? --Tinz 01:42, 29. Mai 2009 (CEST)

gudn tach!

normalerweise achtet die regel u.a. darauf, dass z.b. keine vorkommnisse von "mithilfe" geloescht werden. (sie schlaegt allerdings erst wirklich zu, wenn mehrere kriterien erfuellt werden. das alleinige loeschen von "mithilfe" macht noch gar nichts.)

in einigen faellen bringt das jedoch nichts, z.b. aendert bechterev gerne unsinnigerweise saetze mit "evakuieren", wobei er das wort nicht immer ersetzt, sondern teilweise nur das drumherum umformuliert. deswegen werden ein paar aenderungen verboten, bei denen in den ersetzten zeilen bestimmte begriffe auftauchen, unabhaengig davon, ob die begriffe geloescht wurden.

u.a. war da auch das woertchen "trotz" dabei. da dieses wort haeufig auch in von aenderungen nicht direkt tangierten saetzteilen auftaucht, kommt es hin und wieder zu blockaden bechterevs, bei denen er eigentlich nichts schlimmes getan hat. ich habe jetzt mal "trotz" entfernt und pruefe nun stattdessen, ob "nichtsdestotrotz" geloescht wurde. damit sollte das von dir genannte problem nur noch selten auftreten.

deinen letzten satz (und gleichzeitig frage) habe ich nicht verstanden. ich gehe alle seine getriggerten edits durch, um zu schauen, dass es auch niemanden falsches erwischt hat und um die regeln ggf. zu modifizieren. seine aenderungen, die nicht unnuetz waren, pflege ich gelegentlich in die entsprechenden artikel ein, aber da es sich dabei eh meist nur um unwesentliche kleinigkeiten handelt, tue ich das nicht immer. vielleicht beantwortet das ja schon deine frage. -- seth 19:52, 29. Mai 2009 (CEST)

leider gab's jetzt zwei false positives [9] und [10]. beide weges des vorkommnisses von "evakuierung" in den geaenderten zeilen. ich werde deshalb

1. von den aenderungen der beiden ip-adressen auf den jeweiligen diskussionsseiten berichten und den autoren etwaiges einpflegen ueberlassen und

2. eine kopie der regel erstellen, und dafuer die jetzige etwas entschaerfen. die neue regel #5 (die bisher nur als test fungierte) wird dann so geschaltet, dass sie erst greift, wenn sie auf einen user mehr als einmal zutrifft. das sollte normale user vor falschen disallows schuetzen. -- seth 13:15, 21. Jun. 2009 (CEST)

da - vermutlich aufgrund eines bugs - die regeln anscheinend nur eine maximale laenge haben duerfen, habe ich #3 nun teilweise in #17 und #18 ausgelagert. sobald es moeglich ist, werde ich die regeln wieder fusionieren. -- seth 21:40, 8. Jul. 2009 (CEST), 21:39, 9. Jul. 2009 (CEST)

Hab jetzt angefangen, in #29 auszulagern. Der Bug ist leider noch nicht gefixt. -- seth 22:39, 11. Nov. 2009 (CET)

neue Faelle

• [11]
• talk:Cash-and-Carry-Arbitrage

Aufgrund dieser neuen Faelle und da der Bug bzgl. der Laenge der Regeln noch nicht gefixt wurde, werde ich eine weitere Regel bauen, um nicht die Artikel semi-sperren zu muessen. Alternative, bessere Vorschlaege, die Bechterev bremsen, sind sehr willkommen.
Eine seiner aktuellen Sockenpuppen ist uebrigens user:Kohlenklau und mit dieser hat er auch afaics noch nichts schlimmes gemacht. Wenn's dabei bliebe und er auch unangemeldet keinen Mist mehr verzapfen wuerde, koennten die Regeln ja allesamt deaktiviert werden. Aber leider war's in der Vergangen immer anders. Und wenn ich versuche, mit ihm zu reden, und ihn darauf hinweise, dass er die in der liste aufgefuehrten aenderungen unterlassen soll, blockt er komplett ab. Vielleicht hat ja jemand anders eine Idee. -- seth 20:40, 7. Nov. 2009 (CET)

Hier wieder 84.167. :

http://de.wikipedia.org/w/index.php?title=Spin&curid=11180&diff=66692202&oldid=66523896&rcid=66560298
Hatte das auch in der Disku-Seite eingetragen. Bitte dort löschen? Danke. Gruß -- Gerhardvalentin 17:16, 11. Nov. 2009 (CET)

Der Artikel Spin ist jetzt fuer die IP-Range gesperrt (Regel #3). -- seth 22:36, 11. Nov. 2009 (CET)

es gesellt sich Benutzer:Solarkippe hinzu: [hier]   Gruß -- Gerhardvalentin 12:47, 12. Nov. 2009 (CET)

gudn tach!

Hab die Sockenpuppe gesperrt. Falls er da noch mal was macht, muessen wir dann halt doch den Artikel mal semisperren. -- seth 22:55, 12. Nov. 2009 (CET)

Hallo, ich hoffe [das hier] ist mit [Benutzer-Disku] und [Artikeldisku] erledigt. Gruß --Gerhardvalentin 18:31, 17. Nov. 2009 (CET)

gudn tach!

ui, 84.167.* hat sich ja mal wieder zu einer diskussion herabgelassen. ich glaube, dass ueber dieses thema schon mehr leute versucht haben, mit ihm zu reden, bisher vergeblich. bin mal gespannt, ob deine erklaerung gefruchtet hat. vorsorglich habe ich trotzdem den artikel fuer die ip-range gesperrt. man sieht ja dann im log, ob fortfaehrt. in aller ausfuehrlichkeit wurde das thema uebrigens auf der talk page von WP:NK diskutiert. -- seth 08:42, 18. Nov. 2009 (CET)

wegen des danach folgenden edit-wars in Glaubwürdigkeit (Recht) habe ich der ip-range nun das entfernen von "'sch" (wenn noch weitere bedingungen erfuellt sind) verboten. -- seth 01:28, 21. Nov. 2009 (CET)

Am 26. 11. 2009 als IP 84.167.217.26 unterwegs, kleiner Edit-War, keine großen Schäden. --Gerhardvalentin 17:44, 26. Nov. 2009 (CET)

ja, der user ist seit etwa 2007 mehrmals pro woche aktiv. durch die bisher aktivierten regeln im abusefilter sind allerdings nur noch wenige edits wirklich schlecht, da die anderen im filter haengenbleiben. die meisten nicht blockierten sind ok, weil sie teilweise eine verbesserung darstellen. bei edit-wars oder mehrwertfreien aenderungen kannst du hier gerne bescheid sagen, dann kann ich versuchen, geeignete massnahmen zu ergreifen. im obigen, letzten fall sehe ich allredings bisher keinen handlungsbedarf. -- seth 23:14, 27. Nov. 2009 (CET)

War schon zu lange Ruhe eingekehrt? Heute wieder: [hier] Gruß --Gerhardvalentin 17:45, 16. Dez. 2009 (CET)

danke fuer den hinweis, hab den artikel halbgesperrt und die aenderungen groesstenteils revertiert. -- seth 00:38, 17. Dez. 2009 (CET)

Als angemeldeter Nutzer Knallaku?? seit 30.11. z.B. [hier] Gruß --Gerhardvalentin 10:58, 17. Dez. 2009 (CET)

ja, und ich hatte knallakku auch seit kurz nach seiner anmeldung unter beobachtung; ist jetzt gesperrt. -- seth 22:07, 17. Dez. 2009 (CET)

Hier ist Andere als Nomen hervorgehoben. --Gerhardvalentin 23:55, 17. Dez. 2009 (CET)

das war jetzt allerdings sehr wahrscheinlich nicht bechterev. und in jenen einzelfaellen sollte man auch moeglichst im edit summary kurz den revert begruenden. falls jene aenderung im artikel haeufig vorgenommen werden sollte, kann ein "sic" (wahlweise als html-kommentar) evtl. was helfen. -- seth 00:24, 18. Dez. 2009 (CET)

Derzeit: ["Schweizbezogener" Artikel] (Zürich - Zürcher, die "Zugewandten Orte", die "Helvetische Einheitsverfassung" ... bitte kannst Du helfen? --Gerhardvalentin 10:23, 17. Mai 2010 (CEST)

gudn tach! 84.167.* sollte jetzt diesbzgl. gehindert werden. falls er als sockenpuppe weitermachen sollte, melde dich wieder hier oder (falls es dringend ist) auf WP:VM. -- seth 23:45, 17. Mai 2010 (CEST)

Zusammenfassung und Quellen

• Regel #10.

Wie bereits in diesem Thread vorgeschlagen möchte ich anregen, einen Filter einzurichten, der später das Feature „Warnen, wenn beim Speichern die Zusammenfassung fehlt“ ablösen kann. Der Filter könnte z.B. so aussehen:

action == "edit" & article_namespace == 0 & user_groups == "*" & summary rlike "^\s*(?:/\*.*\*/)?\s*$"

Solange die Warnung noch über die Benutzereinstellung forceeditsummary aktiviert ist, sollte der Filter natürlich nur Mitloggen, damit über das Logbuch eine Analyse des Features möglich ist. Gruß --P.Copp 14:01, 18. Apr. 2009 (CEST)

..Meinungen, Kommentare, Einwände dazu? --P.Copp 14:55, 28. Apr. 2009 (CEST)

Sei mutig. Der Filter zum Mitloggen ist eine gute Idee. Er könnte ggfs. auch ein Ersatz für das jetzige Feature sein. — Raymond ^{Disk. Bew.} 15:15, 28. Apr. 2009 (CEST)

Ganz ohne administrative Hilfe werde ich hier allerdings nicht auskommen :D --P.Copp 15:20, 28. Apr. 2009 (CEST)

Ich habe es umgesetzt. forceeditsummary erzwingt aber auch bei angemeldeten Benutzern und generell allen Namensräumen eine ZuQ. Diese wäre jetzt ausgespart. Ich persönlich begrüßte dies, das Meinungsbild forderte aber leider etwas anderes. Möglich wäre also action == "edit" & summary rlike "^\s*(?:/\*.*\*/)?\s*$" Ich frage (und fragte) mich nur, ob die verworfenen Bearbeitungen überhaupt gefiltert würden. Grüße, —DerHexer (Disk., Bew.) 16:34, 28. Apr. 2009 (CEST)

Es werden, wie vermutet, nur die Änderungen gefilter, die auch gespeichert wurden. Auffallend häufig sind dabei Zusammenfassungen mit „/*…*/“ aufgelistet; soweit ich wusste, werden die durch forceeditsummary nicht verhindert; Raymond hatte mich diesbezüglich allerdings korrigiert. So können wir schwerlich erfahren, welche Änderungen allein aufgrund der erzwungenen ZuQ verfallen.
http://de.wikipedia.org/w/index.php?title=Spezial:Missbrauchsfilter-Logbuch&details=10586 spricht gegen meine Theorie. Grüße, —DerHexer (Disk., Bew.) 16:51, 28. Apr. 2009 (CEST)

Also auf den ersten Blick finde ich relativ viele geloggte Bearbeitungen, zu den es keinen entsprechenden Eintrag in der Beitragsliste des Benutzers gibt, daher denke ich schon, dass auch verworfene Bearbeitungsversuche geloggt werden. Allerdings ist die Detailansicht des Logbuchs nur für Admins zugänglich. Gruß --P.Copp 16:58, 28. Apr. 2009 (CEST)

Danke für die Umsetzung, auf den ersten Blick scheint es zu funktionieren, es sind schon einige Treffer im Logbuch verzeichnet. Wenn das ganze ein paar Tage gelaufen ist, kann man dann versuchen ein paar genauere Daten daraus zu gewinnen.

Zu den anderen Punkten: Der Wunsch, dass nur im Artikelnamensraum gewarnt wird, wurde ja bereits vielfach geäußert und wurde auch schon per bugzilla:18052 beantragt. Angemeldete Benutzer wiederum können sich ja auch jetzt schon die Warnung in den Einstellungen deaktivieren, daher lässt sich diese Einschränkung vielleicht verschmerzen? Gruß --P.Copp 16:55, 28. Apr. 2009 (CEST)

Auswertung

Aufgrund der hohen Anzahl der Treffer hier schonmal der erste Zwischenstand:

anonyme Edits im Artikelnamensraum

Tag	Bearbeitungsversuche						gespeicherte Edits
	gesamt	ohne Warnung	mit Warnung
			ges.	abgebrochen	nachträglich ausgefüllt	erneut ohne ZuQ gespeichert
29.04.	5 280	854	4 426	2 156	1 096	1 174	3 124
30.04.	4 429	800	3 629	1 659	863	1 107	2 770
01.05.	3 583	845	2 738	1 038	724	976	2 545
02.05.	3 444	799	2 645	1 104	695	846	2 340
03.05.	4 260	811	3 449	1 506	846	1 097	2 754
04.05.	5 862	960	4 902	2 478	1 148	1 276	3 384
05.05.	5 787	1 056	4 731	2 260	1 114	1 357	3 527
06.05.	5 306	824	4 482	2 121	1 133	1 228	3 185
07.05.	4 864	795	4 069	1 949	992	1 128	2 915
08.05.	4 741	1 001	3 740	1 657	985	1 098	3 084
09.05.	3 480	741	2 739	1 079	746	914	2 401

--P.Copp 12:43, 10. Mai 2009 (CEST)

Beispiele abgebrochener Bearbeitungen

29.04. 14 – 15 Uhr

[12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169] [170] [171] [172] [173] [174] [175] [176] [177] [178] [179] [180] [181] [182] [183] [184] [185] [186] [187] [188] [189] [190] [191] [192] [193] [194] [195] [196] [197] [198] [199] [200] [201] [202] [203] [204]

29.04. 18 – 19 Uhr

[205] [206] [207] [208] [209] [210] [211] [212] [213] [214] [215] [216] [217] [218] [219] [220] [221] [222] [223] [224] [225] [226] [227] [228] [229] [230] [231] [232] [233] [234] [235] [236] [237] [238] [239] [240] [241] [242] [243] [244] [245] [246] [247] [248] [249] [250] [251] [252] [253] [254] [255] [256] [257] [258] [259] [260] [261] [262] [263] [264] [265] [266] [267] [268] [269] [270] [271] [272] [273] [274] [275] [276] [277] [278] [279] [280] [281] [282] [283] [284] [285] [286] [287] [288] [289] [290] [291] [292] [293] [294] [295] [296] [297] [298] [299] [300] [301] [302] [303] [304] [305] [306] [307] [308] [309] [310] [311] [312] [313] [314] [315] [316] [317] [318] [319] [320] [321] [322] [323] [324] [325] [326] [327] [328] [329] [330] [331] [332] [333] [334] [335] [336] [337] [338] [339]

--P.Copp 15:02, 30. Apr. 2009 (CEST)

Hab mir mal bis [50] die Beispiele angeguckt. Die meisten sind ganz klar unnötig, fünf bis zehn sinnvolle(re) Bearbeitungen waren aber zu erkennen. Dass diese abgebrochen wurden, dient nicht gerade der Verbesserung unserer Enzyklopädie … Bezeichnend ist natürlich die Anzahl von über 2000 Bearbeitungen, die einfach weggeklickt wurden. Ich vermute des Weiteren, dass der Anteil von korrekten zu falschen Änderungen sich zu ersteren verschiebt, wenn man Beispielabbrüche zur Nichtschulzeit auflistet. Könntest du dies für, sagen wir, 18 bis 19 Uhr filtern? Danke für deine Bemühungen um die Auswertung! Grüße, —DerHexer (Disk., Bew.) 14:52, 30. Apr. 2009 (CEST)

Ja, die Abbrecherquote von fast 50% hat mich auch etwas erstaunt, das ist sogar deutlich höher als bei der Signaturwarnung.. 18-19 Uhr s.o. Gruß --P.Copp 15:02, 30. Apr. 2009 (CEST)

Man sollte das ganze wirklich mal genauer auswerten um zuverlässigerer Prozentzahlen an vernünftigen Edits zu bekommen, und die obigen Diffs in sinnvoll/nicht sinnvoll/irgendwo dazwischen einzuteilen (ich könnte das frühestens heute abend machen). Mich hatte erst irritiert, dass bei einigen Links gar kein Diff erscheint. Dies passiert dann, wenn man einfach Bearbeiten und dann Speichern klickt ohne etwas zu ändern. --Tinz 15:44, 30. Apr. 2009 (CEST)

Sobald auch nur eine einzige sinnvolle Bearbeitung durch die Zwangszusammenfassung verloren gegangen ist, hat diese ihre Funktion verloren: ausschließlich unsinnige Bearbeitungen zu verhindern. Personen, die willig sind, ihre Kenntnisse zu teilen, werden am Arbeiten in diesem Projekt ausgeschlossen – einen schlimmeren Fall von Aufhebung des Wikiprinzips habe ich noch nicht erlebt. Grüße, —DerHexer (Disk., Bew.) 12:52, 1. Mai 2009 (CEST)

sehe ich nicht so, man sollte das rationaler sehen. Glaubst Du wirklich, dass durch die Dauerhalbsperren von Sex und hunderten von anderen Artikeln noch nie ein guter Edit verhindert wurde? Oder durch Rangesperren? Das sind zwei Fälle die dem Wikiprinzip weit stärker widersprechen, weil "gute" IPs völlig schuldlos am Edit gehindert werden, hier jedoch bekommen sie nur eine nette Aufforderung, einen Kommentar anzugeben, die sie auch ignorieren können wenn sie das möchten. Es kommt m.E. immer auf das Verhältnis von Aufwand zu Nutzen an. --Tinz 13:05, 1. Mai 2009 (CEST)

Bei Halbsperren gibt es eindeutige Hinweise, auf der Diskussionsseite Verbesserungen anzumerken. Rational betrachtet, betrifft die Zwangs-ZuQ tausende Artikel mehr als Halbsperren; dadurch gehen verhältnismäßig mehr sinnvolle Bearbeitungen verloren. Und je mehr sinnvolle Bearbeitungen verloren gehen, umso mehr wird meines Erachtens das Wikiprinzip eingeschränkt. … Mal ganz abgesehen davon, dass der Button „Seite speichern“ heißt, die Seite aber gar nicht gespeichert wird (bei [Halb-]sperren gibt es den gar nicht; es wird nur der Quelltext angezeigt -> der Benutzer weiß, dass er das nicht abspeichern kann; so ist das bei der Zwangs-ZuQ ein Betrug am Bearbeiter). Bei der früheren Zwangsvorschau wurde wenigstens der Knopf deaktiviert. Ein Fortschritt bei der Zwangs-ZuQ wäre ja schon, wenn der Button so lange deaktiviert wird, bis etwas in der Zusammenfassung geändert wurde. Das erachtete ich als ziemlich sinnvoll … Grüße, —DerHexer (Disk., Bew.) 13:11, 1. Mai 2009 (CEST)

Ich finde das sehr gut in http://pl.wikipedia.org/ gelöst. Dort zeigt ein roter rahmen um die zusamenfassungszeile beim ersten speichern, dass die Zeile nicht ausgefüllt wurde. -- Joschi ^{Sprich mit mir} 12:06, 2. Mai 2009 (CEST)

Hi. Ich bin über den Hinweis von P.Copp bei WP:FzW hier gelandet. Würdet Ihr mal einer neugierigen IP, die nicht fließen java spricht (oder was immer die kryptischen Zeichen oben sein mögen) laientauglich erklären, was das Filter genau macht? Speziell interessiert mich, wie sich Benutzer:DerHexer die Bearbeitungen bis [50] ansehen kann, obwohl diese doch garnicht getätigt wurden (weil abgebrochen), da kommt man als einigermaßen Außenstehender echt nicht mehr mit. Werden hier auch Bearbeitungen mitgeloggt, die ich nur in der Vorschau ansehe, oder wie hab' ich das zu verstehen? Gruß, 217.86.23.251 13:17, 16. Mai 2009 (CEST)

Nein, mitgeloggt wird nur, wenn man auf „Speichern“ drückt und dann der Hinweis auf die fehlende Zusammenfassung erscheint. Einsehbar sind die abgebrochenen Bearbeitungen allerdings momentan nur für Admins. Grüße --P.Copp 13:26, 16. Mai 2009 (CEST)

Danke. Mochmal für mich als Zusammenfassung: Die "abgebrochenen" Edits sind technisch vorhanden, werden aber nicht angezeigt, die "Vorschau"-Edits sehe nur ich? Ich häng' gleich noch ne Frage dran: Was mir überhaupt nicht klar ist: Wie soll dieses Filter, das die Beiträge mitloggt, die wegen des "Zusammenfassungszwangs" abgebrochen wurden, ausgerechnet diesen "Zwang" ersetzen? Gruß, 217.86.23.251 13:38, 16. Mai 2009 (CEST)

Das ist eher eine technische Feinheit und würde zunächst am Softwareverhalten nicht viel ändern: Der Filter kann so eingestellt werden, dass er nicht nur mitloggt, sondern eine Warnung anzeigt. Wenn man diese Warnung genauso gestaltet, wie die jetzige durch den "Zusammenfassungszwang" und diesen dagegen dann abschaltet, hat man sozusagen das gleiche wie vorher. Der Vorteil wäre z.B. dass die hiesigen Admins dann leichteren Zugriff darauf haben. Gruß --P.Copp 13:45, 16. Mai 2009 (CEST)

Ach schad, ich dachte, dass man damit diesen Kram wieder abschaffen könnte. Naja, sei's drum. Dank' Dir, Neugierde befriedigt, System verstanden :-) Gruß, 217.86.23.251 13:52, 16. Mai 2009 (CEST)

Verhindern, dass Bots Interwikis zu bestimmten Vorlagen hinzufügen

• Regel #12.

Seit dieser Woche wurden mehrere Bugs im pywikipedia-Framework behoben, wodurch Bot nun auch massenhaft Interwikis bei Vorlagen hinzufügen können. Das Problem der großen Wikis (und auch dewiki) ist, dass Interwikis in Vorlagen meist von einer Unterseite eingebunden werden. Auf dewiki ist dies die Unterseite /Meta, falls in der Vorlage {{Dokumentation}} verwendet wird. Die py-Entwickler habe im Subversion-Bearbeitungskommentar geschrieben, dass man dies erstmal nur sehr vorsichtig testen soll und alle Edits erstmal noch nachkontrolliert werden müssen. Leider scheinen das aber die meisten Betreiber nicht gelesen zu haben. Ich habe deswegen seit Tagen immer wieder die Betreiber angeschrieben, aber es nimmt kein Ende. Der Resultierende Fehler ist, dass die Interwikis in Folge nun doppelt vorhanden sind und die Interwikiliste sehr lang wird (Beispiel).

Bei Vorlagen, die nicht die Dokumentations-Vorlage benutzen, werden die Interwikis weiterhin direkt zur Vorlage in den noinclude-Bereich hinzugefügt. Das mit dem noinclude-Bereich kann der py seit gestern (vorher waren die Interwikis deshalb auch im ANR sichtbar).

Bei der Regel sollte man aber auch globale Bots aussperren (auch wenn die eigentlich auf dewiki nicht erlaubt sind). Deshalb filtert man wahrscheinlich besser über die Zusammenfassungszeile statt Gruppenstatus (auch um nur Interwiki-Bearbeitungen zu vehrindern). Also mein Vorschlag in Worten formuliert, da ich die Variablen nicht genau kenne):

"Verhindere die Bearbeitung einer Vorlage, wenn der alte Quelltext {{Dokumentation}} enthält und der Bearbeitungskommentar mit 'Bot: Ergänze:' anfängt."

-- Merlissimo 18:00, 5. Mai 2009 (CEST)

Ich habe erst einmal die Benutzergruppe Bots hinzugefügt zur Vorsicht (zum Taggen ist es ja okay) und den Filter noch nicht scharf geschaltet - mal auswerten und ggf. vorher verbessern: Spezial:Missbrauchsfilter/12 --Complex 18:30, 5. Mai 2009 (CEST)

Funktioniert offenbar nicht. Sollte vielleicht funktionieren wenn amn das ganze in

(article_namespace == 10)
&
(old_wikitext rlike ".*Vorlage:((DokumentationVorlage:)).*")
&
(summary rlike "^Bot:.*Ergänze:.*")

ändert, da der Filter in der derzeitigen Form nur funktioniert, wenn in der Vorlage ausschließlich {{Dokumentation}} steht -- Joschi ^{Sprich mit mir} 17:33, 9. Mai 2009 (CEST)

Doch funktioniert wunderbar [340] (Complex hatte das an den Altbearbeitungen auch getestet). Ich habe nur in den Tagen vor meinem Antrag 11 Botbetreiber auf ihren Heimatdisk. angesprochen, das zu unterlassen und die pybot-Entwickler dazu bewegt eine Warnmail in dem Verteiler zu schicken. Seitdem war bisher nur noch der Bot von Obersache im Vorlagennamenraum aktiv, der aber keine Vorlagen mit "Dokumentation" bearbeitet hat. Aber im Botframework behoben ist der Punkt trotzdem noch nicht. -- Merlissimo 18:00, 9. Mai 2009 (CEST)

Ah ok, hatte halt nur die 0 bei der Trefferzahlt gesehen :) -- Joschi ^{Sprich mit mir} 11:46, 10. Mai 2009 (CEST)

Nur zur Info warum es derzeit so ruhig ist: enwp hat in ihrer Policy nun Bots verboten Interwikis im Vorlagennamenraum hinzuzufügen - außer es gibt einen expliziten Antrag inkl. Testphase. Die BAG sperrt andere Bots sofort ohne Vorwarnung, gerne auch global. Deswegen macht es kaum noch jemand und es gibt derzeit keine Treffer, aber der Filter ist zur Kontrolle nach wie vor sehr sinnvoll. Merlissimo 00:43, 22. Mai 2009 (CEST)

Zur Dokumentation: Das Teil ist "scharf" und verhindert jetzt den Edit, die entsprechenden Botbetreiber werden (in unregelmäßigen Abständen) bestimmt und angeschrieben. --Guandalug 14:58, 25. Aug. 2009 (CEST)

Vorlage:Dokumentation hat einen optionalen Parameter: Beispiel. Sollte noch abgefangen werden. Vielleicht so etwas wie /\{\{\s*(?:D|d)okumentation\s*(?:\|[^\}]*)?\}\}/, aber ich denke, da fällt jemandem etwas passendes ein. Vielen Dank Der Umherirrende 18:57, 24. Sep. 2009 (CEST)

Ups, da hattest du denselben Gedanken ein paar Minuten eher: Benutzer_Diskussion:Guandalug#IW-Bots_bei_Vorlagen Merlissimo 19:11, 24. Sep. 2009 (CEST)

gudn tach!

wenn es nicht wichtig ist, dass man nur komplette vorlagen matcht, sondern wenn ein indikator fuer die vorlage fuers triggern reichen soll, dann genuegen ressourcenschonendere varianten wie

old_wikitext rlike '\{\{[Dd]okumentation(?:\||\}\})'

oder

lcase(old_wikitext) contains '{{dokumentation'

-- seth 22:21, 24. Sep. 2009 (CEST)

Um die Performanz von RegEx habe ich mir nicht so viele Gedanken gemacht. Vielleicht kann man ja das ganze matchen und wenn die Zeiten für den Filter in die Höhe schießen, die andere Methode verwenden. Wenn man die ganze Vorlage matched, dann vermeidet man unschöne Nebeneffekte, die man jetzt noch nicht kennen muss. Es sollte auch nur ein Vorschlag von meiner Seite sein. Der Umherirrende 11:30, 26. Sep. 2009 (CEST)

gudn tach!

klein vieh macht zwar bekanntlich auch mist, aber der unterschied sollte hier wirklich vernachlaessigbar klein sein. und der grundsaetzliche einwand ist natuerlich auch berechtigt. hab deine aenderung also jetzt mal uebernommen. btw. in char classes muessen braces {} nicht maskiert werden. -- seth 11:42, 26. Sep. 2009 (CEST)

Wem die Milisekunde noch zu lang ist, kann es ja gerne mit [Dd] anstatt (?:D|d) ausprobieren. Wie sich das auswirkt, habe ich keine Ahnung von. Der Umherirrende 14:19, 10. Okt. 2009 (CEST)

thomas7

• Regel #19

gudn tach!
diese regel muss unbedingt noch verschaerft werden. die potenzielle false positives-rate liegt imho viel zu hoch. da ich nicht weiss, wie dringend die sache ist, habe ich der regel jetzt nicht das disallow-flag genommen. imho sollte das aber bis zu einer besseren loesung getan werden. -- seth 00:45, 17. Jul. 2009 (CEST)

Notiz: Kleine Anpassung, "like" triggerte so nicht. —mnh·∇· 15:59, 17. Jul. 2009 (CEST)

ach so ja, die funktionen wurden zwischendurch immer mal wieder veraendert, ohne abwaertskompatibel zu sein. kann sein, dass bei "like" "*foo*" und nicht "foo" angegeben werden muss. aber egal, hast die regel ja ueberarbeitet, sodass ich meine bitte von oben erst mal als erledigt ansehe.

bzgl. des testens und des schnellen loeschen durch oversights: was genau willst du testen? fuers testen genuegt es ja, wenn man sich irgendwelche edits heraussucht und die regel daran anpasst. man kann davon ausgehen, dass, wenn die regel bei "foo" funktioniert, sie das auch bei "bar" tut. ansonsten koennen wir uns auch gerne mal per chat (da details der regel nicht oeffentlich besprochen werden sollten) treffen und darueber unterhalten. -- seth 21:29, 17. Jul. 2009 (CEST)

Ach, wollte gar nix Besonderes testen, ich benutze halt vor dem Speichern immer gern „Regel testen“ mit ein paar echten Accounts, um doofe Logik-/Tippfehler ausschließen zu können. Klappt nicht, wenn die Oversights nur sowas übriglassen ;). Viele Grüße, —mnh·∇· 21:56, 17. Jul. 2009 (CEST)

schon klar. zumindest gegen logikfehler kann es helfen, wenn man eine modifizierte regel auf andere, z.b. harmlose edits loslaesst. -- seth 22:03, 17. Jul. 2009 (CEST)

Redirecttroll

Hallo,

in letzter Zeit ist der Redirecttroll wieder verstärkt unterwegs (aktive Admins und RCler sollten das von VM wissen). Teilweise werden seine Ranges täglich gesperrt. Daher rege ich an das Anlegen von Redirects und Falschschreibungsweiterleitung aus folgenden Bereichen auf einen pro Stunde zu drosseln (oder zu verhindern) und zu markieren.

• 88.76.224.0/19 (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren)
• 88.77.224.0/19 (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren)
• 88.78.0.0/20 (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren)
• 88.78.224.0/20 (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch • sperren)

Eine Diskussion dazu gab es schon mal mit Complex (finde ich nicht im Archiv), daher @seth: Bitte mit Groß- und Kleinschreibung. Gruß blunt. 19:29, 16. Aug. 2009 (CEST)

Ich glaub, ein Unsinnsredirect pro Stunde rutscht schneller durch, als fünf, die so besser erkannt werden und zu einer IP-(Range-)Sperre führen. —Complex 20:18, 16. Aug. 2009 (CEST)

Gudn Tach!

Wie waere es, wenn wir die Regel scharfstellen aber nur in akuten Faellen aktivieren (naemlich eben dann, wenn man eigentlich auf die Range-Sperre ausweichen wuerde)? So wuerde die Blockierung insg. etwas reduziert, es koennten also andere User aus der IP-Range normal arbeiten, bloss eben keine Redirects anlegen. Da die Regeln allerdings nicht zeitgesteuert automatisch deaktiviert werden koennen, muesste dies dann manuell geschehen, d.h., das birgt die Gefahr, dass es vergessen geht. Aber was haltet ihr ansonsten davon?

Danke fuer den Majuskel-Hinweis. Haette es sonst wieder vergessen. :-) -- seth 20:34, 16. Aug. 2009 (CEST)

Hilft nicht, dann trollt er halt auf Diskussionsseiten rum ([341]), eine Rangesperre wird so oder so nötig sein. —Complex 20:38, 16. Aug. 2009 (CEST)

faekalanmeldungen

• Regel #14

Diese Regel, ergreift zurzeit keine Massnahmen, sondern loggt bloss Account-Erstellungen einiger haeufigen Vandalen mit. -- seth 23:12, 18. Aug. 2009 (CEST)

verschiebeschutz

• Regel #15

Diese Regel, ergreift zurzeit keine Massnahmen, sondern loggt Lieblings-Verschiebungen einiger haeufiger Vandalen mit. -- seth 23:12, 18. Aug. 2009 (CEST)

Edgar von Webern

• Regel #21
• Regel #22

Zwei Regeln sollen unsinnige Bearbeitungen (vor allem kategorisierungen) bzw. Anmeldungen eines Users verhindern. -- seth 23:12, 18. Aug. 2009 (CEST)

Stalking durch ex-Rosa Liebknecht

• Regel #23

Regel gegen Reverts des stalkenden/poebelndnen Users RL. -- seth 23:12, 18. Aug. 2009 (CEST)

Diesel-Filter möglich?

• Regel #25.

Diesel legt bekanntermaßen Accounts mit Toilettenbezogenen namen an, daher wäre ein Filter auf Namen, die Wörter wie Scheisse, Scheizze, Kagge, Kack und Klo (Beispiele aus dem aktuellen Fall) beinhalten. --Liberaler Humanist 22:09, 30. Sep. 2009 (CEST)

Dafür ist eigentlich Mediawiki:Titleblacklist zuständig. Leider verwendet der Spinner schon so viele fremde Zeichen (kürzlich irgendwas kyrillisches), dass entsprechende Filter sehr schwer zu schreiben sind. --PaterMcFly Diskussion ^Beiträge 22:22, 30. Sep. 2009 (CEST)

die tbl wird derzeit fuer neuanmeldungen und so was verwendet und basiert auf konventionellen regexp (PCRE). das AF bietet darueber hinaus ein paar funktionen, die versuchen, solche umgehungsversuche (via kyrillischen oder anderen buchstaben) mitzuerfassen. allerdings ist meines ermessens dem klo-trottel damit nicht beizukommen, da er sich neue ja auch viele neue begriffe ausdenkt. ich glaube, die RC-ler sind das einzige mittel gegen ihn. -- seth 21:01, 1. Okt. 2009 (CEST)

Praktisch wäre dafür natürlich sowas wie "Neuangemeldete Benutzer müssen nach der Anmeldung 2 Minuten warten, bevor sie editieren dürfen". Dann bleibt genug Zeit für eine kurzfristige Sperre, und "seriöse" Neuanmeldungen wird es kaum betreffen, da man am Anfang eh seine Zeit braucht, die ersten Edits hinzubekommen. Bräuchte natürlich aber Mediawiki-Unterstützung. --PaterMcFly Diskussion ^Beiträge 00:03, 2. Okt. 2009 (CEST)

Clusterbildung von Dieselkonten erkennt man in der Regel schneller als einzelne - Sperrung dauert pro Konto rund eine Sekunde, da hat Diesel also mehr Mühe Captchas einzugeben als wir mit dem Sperren. So richtig sehe ich die Problemstellung nicht. Für halbwegs erfahrene IPs, die sich endlich anmelden, um einen Tippfehler zu korrigieren, sind zwei Minuten dagegen unnötig lang. —Complex 00:07, 2. Okt. 2009 (CEST)

Deine Mutter

Hallo, können wir nicht endlich mal einen Filter auf *deine mu(tter|dda)* für IPs machen. Die False-Positives dürften sich auf weniger als ein Prozent im Jahr belaufen. Grüße -- Berliner Schildkröte 23:16, 6. Okt. 2009 (CEST)

das thema hatten wir schon mal: Wikipedia:Missbrauchsfilter/Anträge/Archiv#Schimpfw.C3.B6rter_durch_IPs_auf_im_Artikelnamensraum

wie haeufig kommt das denn deiner schaetzung nach vor? -- seth 13:00, 10. Okt. 2009 (CEST)

Ich kann zwar die Situation hier nicht genauer bewerten, allerdings gibt es auf Commons solche Filter (allerdings nur für englische Schimpfwörter). Diese haben bisher in einem Monat (davor waren sie nur im Galerienamensraum der Commons aktiviert, wo selten vandaliert wird) keine False Positives gegeben. Ich denke, wenn man eine Seite einrichtet, wo man sowas melden kann, und sich auch immer wieder mal die Details anguckt, dann sollte das ein stabiler Missbrauchsfilter sein. Natürlich kann es sein, dass es mal false positives gibt, aber dank dem Log, das geführt wird, kann man auch einfach dann anstelle des Benutzers den Edit ausführen. Ich denke, dass so ein Filter der Wikipedia enorm gut tun würde, denn so einer geht gegen den Vandalismus vor, und nicht gegen jeden neuen Benutzer wie die gesichteten Versionen. --The Evil IP address 21:15, 4. Nov. 2009 (CET)

gudn tach!

In der englischen Wikipedia werden sehr viele potenzielle Beleidigungen gefiltert. Dort hat man halt auch mit wesentlich mehr Vandalismus zu kaempfen. Allerdings weiss ich nicht, inwiefern da wirklich eine Kontrolle der Logs erfolgt. Und hier sollten solche Regeln auch nur dann angelegt werden, wenn die regelmaessige Kontrolle der Logs sichergestellt ist. Denn wenn niemand Zeit und Musse dafuer hat, bringen auch die Logs nix.

Ausserdem sollten false positives - wenn ueberhaupt - dann nur hingenommen werden, wenn der Nutzen der Regel wirklich gross waere. Und ich vermute er waere es in diesem Fall nicht. Aber das koennen wir ja z.B. durch eine Test-Regel, die auf logging-only gestellt wird, herausfinden. Hat jemand Einwaende bzgl. einer solchen Test-Regel? -- seth 20:50, 7. Nov. 2009 (CET)

Filter 26

• Regel #26.

Begründung / Antrag fehlt. Aussdem: was ist an "LiL'Sparrow" als Benutzername ungeeignet  ? -- Arcudaki Blitzableiter 12:45, 9. Okt. 2009 (CEST)

gudn tach!

begruendung ist der diesel-trottel. sehr schlecht fand ich allerdings, dass die syntax voellig falsch benutzt wurde und damit natuerlich alles moegliche unbeabsichtige passieren kann. wer sich mit regexps nicht auskennt, sollte sie nicht benutzen, sondern einen antrag stellen. sonst passiert es irgendwann mal dass jemand versehentlich die wikipedia sperrt und als konsequenz das AF deaktiviert wird. das waere obermist. ich habe die groebsten schnitzer in der regel soeben beseitigt, aber einiges (was vermutlich nicht schadet) erst mal belassen, weil ich nicht wusste, was damit genau gematcht werden soll.

"LiL'Sparrow" war ein false positive. das problem ist mittlerweile behoben. wobei sich ein paar weitere admins noch mal genau die regelbestandteile anschauen sollten, um die wahrscheinlichkeit weiterer false positives zu minimieren. DerHexer, liest du mit? -- seth 13:19, 10. Okt. 2009 (CEST)

Zufälligerweise ja. Das, was jetzt erstmal drin steht, ist in Ordnung; nur die ersten beiden Sachen find ich mit drei Zeichen zu kurz und uneindeutig (HerrmannPD). Grüße, —DerHexer (Disk., Bew.) 17:10, 10. Okt. 2009 (CEST)

"NPD" wird ohnehin von der TBL geblockt, somit habe ich mal die ersten beiden sachen rausgenommen, zumal hier keine einwaende kamen. -- seth 00:08, 16. Okt. 2009 (CEST)

Geocities

• Regel #27.

Mein Bot meldet gerade alle Geocities-Weblinks, da der Dienst nächste Woche eingestellt wird. Da auf den Geocities-Benutzerseiten diese Abschaltung nicht erkennbar ist, wäre es vielleicht hilfreich eine kleine Info einzublenen, wenn Benutzer so einen Weblink noch hinzufügen wollen. Geocitoes-seiten gehören mit 5700 Weblinks zu den Meistverlinken - außer spezielle Datenbanken. Das betrifft die Domains geocities.com, *.geocities.com , www.geocities.* und geocities.yahoo.* (die letzen beiden mit diversen Länderdomains z.B. com.br oder .jp).

Hinweis: Geocities stellt seinen Dienst zum 26. Oktober ein. Bitte suche auf Archive.org nach einer geeigneten archivierten Version und verlinkte diese.

Oder so ähnlich mit speziellem Geocities-Archiv.org-Link im Hinweismodus. Der Archivlink (z.B. http://web.archive.org/web/20071015101822/http://www.geocities.com/classicallyaudrey/moonriver.htm) sollte natürlich ohne Hinweis eingefügt werden können. Merlissimo 17:35, 17. Okt. 2009 (CEST)

Ich habe jetzt beim Nachschauen schon zwei Fälle gesehen, wo jemand den Link korrekt durch einen Archivlink ersetzt hat und später revertet wurde mit der Begründung "Wieso? Link geht doch". Genau das würde ich gerne vermeiden. Merlissimo 05:11, 18. Okt. 2009 (CEST)

gudn tach!

Die Warnung habe ich in Anlehnung an MediaWiki:Abusefilter-warning auf MediaWiki:Abusefilter-warning-geocities erstellt, allerdings noch nicht in Verwendung. Die Regel ist #27, allerdings tut sie zurzeit noch nix ausser mitloggen.

Das AF hier statt der SBL einzusetzen, ist imho eine gute Idee, um die User eben ueber den Sachverhalt zu informieren und um die Verlinkung auf Diskussionsseiten zu ermoeglichen.

Gibt's Einwaende oder sollte der Hinweis scharfgeschaltet werden? -- seth 16:14, 18. Okt. 2009 (CEST)

so, die archive-links sind jetzt auch in der regel explizit ausgenommen. und anhand der log-eintraege bis jetzt (bei denen die archive-links noch mitgeloggt wurden) konnte ich das auch ganz gut testen. ich schalte die regel auch heute nacht scharf, wenn weiterhin niemand was einwendet. -- seth 21:02, 19. Okt. 2009 (CEST)

related: user talk:Don-kun#geocities-link. -- seth 20:29, 7. Nov. 2009 (CET)

herverschoben von Hilfe_Diskussion:Missbrauchsfilter -- seth 00:30, 24. Nov. 2009 (CET)
Kann man den Geocities-Filter anpassen, das er geocities.jp ignoriert? Es gibt für diese Domain keine Hinweise das sie ebenfalls von der Geocities-Abschaltung betroffen ist. --Mps 16:53, 23. Nov. 2009 (CET)

Ich bin gerade aufgrund der Logs auf http://www.geocities.ws/ gestoßen. Da hat jemand einen Web Archiv alter Geocities Seiten angelegt. Müsste also auch raus. Merlissimo 00:50, 24. Nov. 2009 (CET)

(bk) ich kann kein japanisch und muss dir deshalb einfach glauben. hab jp freigegeben. bleibt die frage, ob die regel ueberhaupt noch weiterhin sinn macht. gibt es jetzt noch seiten, die funktionieren, aber in kuerze dichtgemacht werden?

ps. 'ws' gebe ich auch noch frei. -- seth 00:53, 24. Nov. 2009 (CET)

@seth Interessant: Beim Speichern des Filters gibt es keinen BK. Ich war auch gerade am austesten. Ich nehme meine Änderung wieder zurück.

Mit .jp ist es wohl so (es gibt nur Gerüchte), dass jemand yahoo viel Geld geboten hat, um den Dienst zu übernehmen. Sollte das der Fall sind von Yahoo erst AGB-Änderungen, Exportmöglichkeit für Übernahme usw. nötig (also ein längerer Prozess). Zumindest wird es wohl mind. bis Frühjahr noch funktionieren, so heißt es. Danach ist ungewiss. Merlissimo 01:03, 24. Nov. 2009 (CET)

gudn tach!

ja, bk wird dort leider nicht angezeigt. war gut, dass du deine aenderung revertiertest, denn mit brackets werden zeichenklassen definiert. [jp] ist so aehnlich wie (j|p), also nicht das gewuenschte. -- seth 22:18, 25. Nov. 2009 (CET)

Zusätzlich zu geocities.jp bitte noch geocities.co.jp freigeben. --Mps 16:52, 25. Nov. 2009 (CET)

erledigt. -- seth 22:18, 25. Nov. 2009 (CET)

links auf gutefrage.net

• Regel #28

gudn tach!
Siehe WP:SBL#gutefrage.net. Mir scheint so, als muessten wir hier das AF einsetzen, weil die SBL nur pauschal Links verbieten kann. Ich werde eine Regel einrichten (erst mal auf logging-only), welche die Links im main namespace verhindert. -- seth 23:21, 24. Okt. 2009 (CEST)

Redirectflooding

Ist es eigentlich möglich das Massenhafte erstellen von Weiterleitungen durch einen Filter zu unterbinden. Wenn also jemand fünf Weiterleitungen in Folge erstellt ihn dann irgendwie auszubremsen. Meistens ist das nämlich wenig sinnvoll. --92.224.224.46 01:44, 14. Feb. 2010 (CET)

moeglich ist es. kommt denn haeufig solcher missbrauch vor? -- seth 12:02, 14. Feb. 2010 (CET)

mE recht selten, oft ist es aber so, dass jemand, der viele Weiterleitungen erstellt, damit der WP behilflich ist, z.B. ein Reihe von aufgelaufenen Ortsnamen vom Balkan abzuarbeiten. --Atlan ^Disk. 00:59, 21. Feb. 2010 (CET)

Ergänzung /37

• Regel #37

da würde noch entfernt fehlen. -- Atlan ^Disk. 00:10, 7. Mär. 2010 (CET)

Aber wenn man auf "entfernen" klickt steht nur "Änderung xxxxx von XX wurde rückgängig gemacht.". Meinst du das? --Euku:^⇄ 00:21, 7. Mär. 2010 (CET)

oh, stimmt, sorry, danke. --Atlan ^Disk. 00:37, 7. Mär. 2010 (CET)

Bezeichnung des Systems und Filter für Löschanträge

Ich habe zwei Anregungen. In der englischsprachigen Wikipedia heißt der Filter "Edit Filter" was wesentlich passender ist, da dort, wie hier im Grunde auch, die Erweiterung für Dinge genutzt wird, die keinen oder keinen eindeutigen Missbrauch darstellen, insofern ist die Wortwahl unpassend und unnötig agressiv. Zum anderen hätte ich gerne Markierungen für das Stellen (und wohl auch das Entfernen) von Löschanträgen. Das geht im Wesentlichen darauf zurück, dass die Beitragenden keine oder keine einheitlichen bzw. keine zuverlässig automatisch erfassbaren Bearbeitungskommentare erfassen, was zu Problemen führt, wenn man die letzten Änderungen verfolgt oder später etwaige Vorgänge nachvollziehen möchte, zum Beispiel für statistische Auswertungen.

Konkret gibt es zum Beispiel Benutzer, die neue Artikel vor der Schnelllöschung mit Einsprüchen und Überarbeitungen bewahren möchten, und das bisher eher wenig optimal über den IRC feed und anhand der Bearbeitungskommentare erledigen, ebenso gibt es Dienste die auswerten, wer und wann welche Löschanträge gestellt hat, und die Auswertung anhand der Löschkandidaten führt leicht zu Fehlern, zum Beispiel wenn Schnelllöschanträge zu regulären Löschanträgen umgewandelt werden. Das entfernen spielt zum Beispiel dann eine Rolle, wenn jemand mal einen Bot schreiben möchte, der automatisch die "War Löschkandidat"-Vorlage auf der Diskussionsseite einbindet (wozu man wissen muss, in welcher Benutzergruppe derjenige der ihn entfernt hat ist, um Admin-Entscheide von anderen zu trennen, wozu man die genaue Version kennen muss, in der der Antrag entfernt wurde, wozu man wiederum sämtliche Versionen durchgehen muss).

Die entsprechendne Filterregeln wären trivial, für Schnelllöschanträge wäre der passende Ausdruck { gefolgt von einem aus

• schnelllöschen
• löschen
• sLA
• sla
• db-user
• db-u1
• delete
• Schnelllöschen
• Löschen
• SLA
• Sla
• Db-user
• Db-u1
• Delete

gefolgt von einem aus (die Beschränkung ist notwendig, da die Schlüsselwörter auch Prefix anderer Vorlagen sind, die Zeichenauswahl ist einigen syntaktischen Feinheiten geschuldet, die man den bisher gestellten Schnelllöschanträgen entnehmen kann, aber im Detail auch nicht weiter wichtig sind)

• }
• |
• <
• {

Für reguläre Löschanträge wäre das einfach { gefolgt von Löschantragstext (da hier die übergeordnete Vorlage substituiert wird und "Löschantragstext" sonst nirgends vorkommt).

Angewandt würden die Muster auf added/removed_lines beziehungsweise old/new_wikitext (ich würde letzteres vorziehen, da Softwarebedingt die Differenzen nicht immer ganz richtig sind, insbesondere wenn die Vorlagen nicht ganz richtig eingebunden werden; hier müsste man dann die Mustererkennungen vergleichen, ala, ist jetzt da war vorher aber nicht). Die zugehörigen Tags wären "Löschantrag", "Schnelllöschantrag", "Löschantrag entfernt", und "Schnelllöschantrag entfernt". Prinzipiell wäre auch "SLA in LA umgewandelt" sinnvoll, dafür müsste man den Filter aber auf old/new_html anwenden, und ich bin mir nicht ganz sicher, dass man dafür einen guten Ausdruck hinbekommt (und eventuell lohnt der Aufwand nicht, je nachdem, ob die Variablen ohnehin zur Verfügung stehen, oder speziell für den Filter erst gefüllt werden müssten); das Problem hier ist, dass manchmal der Schnelllöschantrag nicht einfach entfernt wird, sondern mittels nowiki und ähnlich auskommentiert wird, was man über reguläre Ausdrücke anhand des unverarbeiteten Textes nicht gut abbilden kann; und es gibt Fälle wo Administratoren erst den Schnelllöschantrag entfernen und dann erst in der nächsten Revision den Löschantrag einbinden.

Falscherkennungen sollten sich auf Dokumentationsseiten (Hilfeseiten die Löschanträge erklären, Benutzerseiten wo Benutzer sich zum Kopieren und Einfügen entsprechende Beispiele vorhalten). Eventuell macht es Sinn, den Filter daher auf die Artikel und Kategorienamensräume zu beschränken. --94.223.185.168 22:23, 17. Mär. 2010 (CET)

Zumindest Änderung am Filter 36

• Regel #36

Bitte den Filter um folgende Bedingungen erweitern: Der Nutzer muss in den letzten 10 Bearbeitern der Seite mindestens 3 mal auftauchen, aber nicht der letzte Bearbeiter sein. Der Filter sollte die Bearbeitung natürlich auch mit dieser Erweiterung erst beim dritten Mal verbieten. --Arcudaki Blitzableiter 14:51, 13. Apr. 2010 (CEST)

Das funktioniert nicht, weil die Variable eine unique Liste der letzten zehn Benutzernamen enthält und man deshalb auch nicht den letzten Bearbeiter einer Liste bestimmen kann. Merlissimo 21:37, 13. Apr. 2010 (CEST)

Hinweis auf Vorschau

Ich fände es sinnvoll, wenn einem Benutzer bei der xten aufeinander folgenden Bearbeitung im selben Artikel ein Hinweis bezüglich Vorschau angezeigt würde. Die Meldung könnte eine Kurzversion von Vorlage:Vorschau sein. Für x würde ich einen Wert von 3–5 vorschlagen. --Leyo 21:32, 13. Apr. 2010 (CEST)

Sinnvoll, aber diese Aktionen sollten nicht geloggt werden, da es sonst nur eine Bloßstellung ist. Vielleicht kann man schauen, ob verschiedene Abschnitte bearbeitet wurden oder immer der gleiche bzw. der ganze Artikel. Der Umherirrende 22:03, 13. Apr. 2010 (CEST)

Ist es möglich, die Aktionen nicht zu loggen? --Leyo 19:59, 15. Apr. 2010 (CEST)

Es gibt die Option "Bearbeitung im Missbrauchsfilter-Logbuch markieren", ich weiß nur nicht, ob ich sie richtig verstanden habe, es gibt aber auch die Option "Bearbeitung für eine spätere Überprüfung markieren", da bin ich mir aber nicht sicher was sie macht (bei diesem Vorschlag unangebracht, wollte ich nur so vermerken). Der Umherirrende 20:20, 15. Apr. 2010 (CEST)

"Bearbeitung im Missbrauchsfilter-Logbuch markieren" erzeugt einen Logbuchantrag. Diese Option können Admins nicht abschalten. Die Option "Bearbeitung für eine spätere Überprüfung markieren" tagged/markiert die Aktion. Dies ist für diversen Spezialseiten, wie "Letzte Änderungen", wo es eine Tag/Markierungs-Filtermöglichkeit gibt. Merlissimo 20:49, 15. Apr. 2010 (CEST)

Schade, warum auch immer das so gedacht ist, aber danke für die Erklärung. Der Umherirrende 20:54, 15. Apr. 2010 (CEST)

Für mich ist das nicht abschaltbare Loggen kein Killer-Kriterium. --Leyo 14:46, 16. Apr. 2010 (CEST)

Tage gibt's, die gibt's gar nicht

Ich bin gerade dabei, Datumsangaben wie 31. Februar, 31. April, 31. Juni, 31. September und 31. November aufzuspüren und zu korrigieren. Die finden sich jeweils zu Hunderten, und während es natürlich Ausnahmefälle geben kann, wo das aus dem einen oder anderen Grund tatsächlich eine korrekte Angabe sein könnte, z.B. irgendein Eigenname (und ein ganz besonderer Spezialfall wäre der 30. Februar, den's hier und da tatsächlich gegeben haben könnte), ist es in 99,9 % der Fälle doch ein klarer, faktischer, aber über technische Filtermaßnahmen erkennbarer Fehler. Nicht unbedingt eine Schlamperei des Wikipedia-Autors, häufig findet sich der Fehler offenbar schon in der Quelle, aber dann sollte diese halt hinterfragt werden, und das Datum bleibt falsch. Über die üblichen Tippfehler geht das weit hinaus, denn beim Einfügen eines 31. April ist eben nicht ersichtlich, ob damit tatsächlich ein 30. April, ein 1. Mai, ein 31. März oder ein ganz anderer Tag gemeint - nur eines ist (ziemlich) sicher: Das eingefügte Datum ist faktisch falsch. Wäre es angebracht, hier einen (Warn-)Filter zu installieren? Das Nachräumen per Hand über unzählige solcher Angaben ist jedenfalls ziemlich mühselig. --YMS 19:43, 15. Apr. 2010 (CEST)

Spielwiese

Hallo, gibt es eine Möglichkeit einen Filter zu installieren, der verhindert, dass die Begrüßungskasten-Vorlage der Wikipedia:Spielwiese entfernt wird? Wenn die Vorlage entfernt wird, also nicht mehr im Text steht, sollte eine Fehlermeldung kommen, die einen passenden Vorschlag macht... - Würde das sehr sinnvoll finden, nachdem der Begrüßungskasten immer wieder mal entfernt wird. Grüße von Jón + 14:10, 16. Apr. 2010 (CEST)

Jede zwei Stunden schaut mein Bot auf allen drei Spielwiesen nach dem rechten und stellt sie wieder her, sofern in der letzten halben Stunde zuvor keine Bearbeitung stattfand. Auf der Hauptspielwiese sind andere aber meistens schneller mit dem zurücksetzen. Insofern fehlt mir etwas die Notwendigkeit. Was du eigentlich möchtest wäre wahrscheinlich eine Pagenotice. Merlissimo 00:20, 18. Apr. 2010 (CEST)

Riesenedits

Würde es nicht Sinn machen, Riesenedits wie den auf der Hauptseitendisk von heute 21:00 (+ 1.346.412 Bytes) abzufangen? Ab einer Größe von x (100.000? 50.000?) kann eigentlich nix sinnvolles mehr drin sein und die Datenbank wäre mit Sicherheit nicht traurig drüber. --Marcel1984 ^{(?! | ±)} 21:59, 20. Apr. 2010 (CEST)

http://de.wikipedia.org/w/index.php?title=Ilias&diff=50568523&oldid=50534309 … 200.000 Bytes; keine Ahnung, wie das mit mancher botgenerierter Seite hier ist; 500.000 würde ich aber als mindestes ansehen, gerne auch das doppelte. Grüße, —DerHexer (Disk., Bew.) 22:03, 20. Apr. 2010 (CEST)

Spezial:Längste Seiten meint, dass die 500.000 wohl reichen dürften. --Marcel1984 ^{(?! | ±)} 22:11, 20. Apr. 2010 (CEST)

Ja, im ANR ist das klar. Es gibt aber, wenn ich mich recht erinnere, zumindest auf meta Logs von Bots, die diese Größe überschreiten. Da weiß ich aber nicht genau, ob die dann mit einem Edit gemacht werden. Vlt. erstmal mit 500.000 antesten ohne Reaktion? Grüße, —DerHexer (Disk., Bew.) 22:29, 20. Apr. 2010 (CEST)

Mit ohne Reaktion meinst du einfach nur Anlage ohne Folge für den Auslöser? Dann ja, gern. --Marcel1984 ^{(?! | ±)} 22:37, 20. Apr. 2010 (CEST)

Dann würde man auch sehen, wie oft derartiger Vandalismus überhaupt vorkommt (vermutlich: nicht oft), wie schnell er auch ohne Filter revertiert wird (vermutlich: schnell), und wie häufig er kontraproduktiv wäre (Einstellen kompletter, langer Seiten verhindert; Reverts von Artikelleerungsvandalismus verhindert). --YMS 19:19, 21. Apr. 2010 (CEST)

A pro pos Artikelleerungsvandalismus - ließe sich das nicht auch über einen Filter abfangen? Kenne grad keinen sinnvollen Grund, warum eine Seite mit new size = 0 im ANR zugelassen werden sollte. --Marcel1984 ^{(?! | ±)} 21:43, 21. Apr. 2010 (CEST)

siehe z.b. Wikipedia:Missbrauchsfilter/Anträge/Archiv#Seitenleerungen. -- seth 22:04, 21. Apr. 2010 (CEST)

Neuen Vorschlag

Wie wäre es mit einem Filter zum Schutz gegen Seitenleerungen oder wenn im Artikel Wörter, wie fuck, scheiße usw. reingeschrieben werden. Könnte so ein Filter erstellt werden? --80.138.116.11 09:41, 5. Mai 2010 (CEST)

Seitenleerung ist eine gute Idee - bei den Wörtern bin ich auch schon auf Varianten gestossen, die nicht im Duden stehen. G! GG ^{nil nisi bene} 09:55, 5. Mai 2010 (CEST)

Zum Thema Seitenleerung siehe eins drüber --Guandalug 09:57, 5. Mai 2010 (CEST)

Seitenleerungen können auch sinnvoll sein, wenn etwa ein Artikel in einen Redirect umgewandelt wird oder eine URV entfernt wird. Das sind zudem die am leichtesten erkennbaren Vandalismen. Wortfilter wurden hier schon häufiger abgelehnt, da auch Schimpfworte in Einzelfällen in Artikeln sinnvoll sein können und diese sinnvollen Edits dann geblockt werden würden. --Orci Disk 10:58, 5. Mai 2010 (CEST)

In der engl. WP gibt's einen ähnlichen Filter (siehe en:Special:Tags). Zudem gibt's ClueBot, der vandalismusverdächtige Edits revertiert. --Leyo 12:01, 5. Mai 2010 (CEST)

nicht bearbeitete Zusammenfassung

• Regel #10

Kann man den Filter nicht wieder aktivieren, nachdem er sich selbst deaktiviert hat? --188.23.105.140 19:18, 8. Mai 2010 (CEST)

Er hat sich durch die hohen Treffer selber deaktiviert, aber richtig erwünscht war er nie, daher ist er vermutlich nicht wieder aktiviert worden. Wobei ihm das Schicksal beim Aktivieren wieder Treffen könnte. Siehe auch Wikipedia:Erzwungene Zusammenfassung. Der Umherirrende 19:59, 8. Mai 2010 (CEST)

Ungültige Weblinks

Auch für die Einfügung von http://http:// und http:http:// (ferner vielleicht htpp://, hppt://, etc.) wäre eine Warnung angebracht. Derartige Links sind immer falsch und bringen auch moderne Browser noch gehörig durcheinander (mein Opera z.B. führt mich derzeit mit jedem http://http://-Link auf ein x-beliebiges YouTube-Video, früher war's mal ein Browserspiel), und sind nachträglich auch nicht ganz leicht aufzuspüren (die Wikipedia-interne Suche sowie die Weblinksuche etwa kann man dafür vergessen, auch Google funktioniert nur mäßig). Andererseits sind deren dauerhaftes Bestehen ja ein guter Indikator dafür, wie selten hier jemand die angegebenen Quellen nachprüft. --YMS 22:54, 11. Mai 2010 (CEST)

wow, 909 http://http://-Links - davon 629 im ANR. Ich würde sagen wir korrigieren die erst einmal und schauen in zwei Wochen, wie viele dann wieder neu hinzukommen sind, ok? Merlissimo 23:05, 11. Mai 2010 (CEST)

Woher stammt diese Zahl? (Ich hatte vorhin schonmal schwache 20 derartige Links korrigiert, plus einige auf Commons.) --YMS 23:40, 11. Mai 2010 (CEST)

Ich betreibe einen globalen Weblink-Korrektur-Bot. Wenn der das nicht wüsste ....

Er benutzt dazu ein kleines Tool von mir [342]. Die Zahlen [343] sind die pageids, die den Link beinhalten. Die benutzt der Bot dann als Eingabe. Merlissimo 23:48, 11. Mai 2010 (CEST)

Absatz nach Wikipedia:Bots/Anfragen#Ungültige_Weblinks verschoben, da hier die falsche Seite für den Botlauf. Merlissimo 00:52, 12. Mai 2010 (CEST)

Bitte ersetze diesen Text durch Deine aussagekräftige Überschrift verhindern

Wäre es möglich einen Filter einzurichten, der oben stehende Überschriften auf WP:SH und WP:AU verhindert und die Benutzer mit einer Vorlage freundlich darauf hinweist, dass sie die Überschrift gegen Ihre eigene austauschen sollen? Ideal wäre es auch, wenn gleichzeitig Signaturen am Anfang der Frage verhindert werden, so wie hier. WikiDienst ^?! 19:23, 1. Jun. 2010 (CEST)

Scheint sich nach einer auffälligeren Gestaltung des Editintros weitgehendst erledigt zu haben. WikiDienst ^?! 01:09, 28. Jun. 2010 (CEST)

Info: neuer Stalking-Filter

• Regel #48

Aufgrund dieser Anfrage habe ich probeweise Spezial:Missbrauchsfilter/48 eingerichtet. Zunächst mal nur zur Protokollierung des Umfangs, ggf. spätere Restriktion. Gruß, --Wiggum 14:15, 2. Jun. 2010 (CEST)

Nicht gut. Der Filter steht ja wohl seit einiger Zeit auf "verbieten".

Ich bin nicht sehr geübt in der Interpretion der MBF-Logs, aber ich meine viele falsch Positive zu sehen, insbesondere wohl wegen added_lines like "*Mich*" -- es gibt einfach zu viele legitime Edits, die einen "Michael" in den Artikeltext einfügen wollen.

--Pjacobi 10:33, 17. Jun. 2010 (CEST)

Siehe hier--Wiggum 10:39, 17. Jun. 2010 (CEST)

Henner Reitmeier

Wie auf meiner Diskussionsseite zu sehen scheint ein Benutzer (allem Anschein nach Henner Reitmeier selbst) unter verschiedenen IPs die Bekanntmachung eigener Veröffentlichungen in der Literaturliste zu versuchen. Inzwischen habe ich vermutlich das meiste wieder gelöscht. Aber kann man eventuell einen Filter setzen, um weiteren Literaturspam zu verhindern? --Of 17:17, 16. Jun. 2010 (CEST)

gudn tach!

ja, prinzipiell moeglich, aber sollte nur eingesetzt werden, wenn die konventionellen mittel versagen. hab auf user talk:Datschist#Verschiebung einer Diskussion geantwortet. -- seth 23:54, 16. Jun. 2010 (CEST)

Die-Winterreise-Sperre

• Regel #47

Verstehe nicht wirklich wie der Filter funktioniert. Es sollten doch nur IPs aus bestimmten Range betroffen sein, aber das Logbuch sagt etwas anderes. Mag mich jemand aufklären? Danke und Gruß --Engie 20:45, 26. Jun. 2010 (CEST)

gudn tach!

es werden edits in bestimmten artikeln verhindert, die

• von bestimmten ip-adressen ausgehen (unabhaengig von der begriffswahl) oder
• bestimmte begriffe beinhalten (unabhaengig vom user).

-- seth 13:04, 27. Jun. 2010 (CEST)

bzgl. dieser meldung auf AAF eine frage an die admins, die diese regel einrichteten: soll jene ip-adresse 82.212.22.178 entsperrt werden, oder nicht? wenn sich niemand meldet, werde ich sie von #47 ausnehmen. -- seth 17:19, 27. Jun. 2010 (CEST)

Ich versteh nicht genau, was du dir vorstellst: Eine einzelne dynamische IP rausnehmen, ist keine Lösung auf Dauer; im konkreten Fall wird aus mehreren Ranges editiert, über die ich aber keinen vollständigen Überblick habe. Gruß --Hozro 19:29, 27. Jun. 2010 (CEST)

war es nicht so, dass diese kabel-ip-adressen zwar dynamisch sind, aber meist laenger als nur 24h halten, sondern mehrere wochen/monate halten? in diesem fall waere eine entsperrung dieser ip-adresse durchaus eine ueberlegung wert. -- seth 20:58, 27. Jun. 2010 (CEST)

kleine Ergänzung aufgrund eigener Erfahrung: lt. telefonischer Auskunft von Kabel BW wird einem Kunde eine IP-Adresse dauerhaft für mehrere Monate (idealerweise für die gesamte Vertragslaufzeit) zugeordnet. Faktisch wechseln die Adressen regelmäßig - teilweise schon nach Stunden (einmal hatte ich vier Wechsel an einem Tag), fast immer nach ein bis zwei Tagen, ganz selten auch mal erst nach einer Woche. Per Reset kann ich als Kunde den Wechsel der IP nicht beeinflussen. Gruß, --82.212.22.178 21:16, 27. Jun. 2010 (CEST) PS. ich melde mich hier nochmal, wenn die IP gewechselt hat *Meld* --78.42.72.223 00:49, 28. Jun. 2010 (CEST)

Die Kabel-IPs scheinen in jeder Region etwas anders zu funktionieren, ich beobachte das auch schon ne Weile :) Während die des obigen Kollegen praktisch täglich wechselt, bleibt meine wochenlang (Spitzenwert waren drei Monate iirc) konstant. --91.64.58.117 11:07, 28. Jun. 2010 (CEST)

@IP91.64.58.117: Kabel Deutschland ≠ Kabel BW ;-) --82.212.23.54 19:26, 28. Jun. 2010 (CEST)

Achso klar, Hessen, Bawü und NRW zählen natürlich nicht zu Deutschland. Aber wieso dann Bayern? hmmm, --91.64.58.117 00:07, 29. Jun. 2010 (CEST)

@IP91.64.58.117: wie kommst Du jetzt auf Bayern? --82.212.23.54 00:09, 29. Jun. 2010 (CEST)

Danke seth für die Auskunft, so weit so klar. Verstehe aber immer noch nicht ganz, wieso wurde beispielsweise dieser Beitrag verhindert? --Engie 21:10, 27. Jun. 2010 (CEST)

@Engie: Vermutlich weil in added_lines "lorenzondo" enthalten war. Ich versteh auch nicht, warum der Filtermechnismus den jeweiligen Vorgängerbeitrag unter entfernte Zeilen _und_ unter hinzugefügte Zeilen verbucht. Bei den letzten beiden Treffern von nr. 48 (und einigen davor) dasselbe. Gruß --Wiggum 13:45, 28. Jun. 2010 (CEST)

Hmmm, deine Erklärung macht Sinn. Dieser Bug sollte schnellstens behoben werden, sonst werden durch den Einsatz des Filters "Aktion, wenn bestimmtes Wort hinzugefügt wird" zuviele False Positives erzeugt, da noch weitere Beiträge auf der Seite berücksichtigt werden. Gibt es schon einen Bugreport, kenn mich damit leider nicht aus. --Engie 17:21, 28. Jun. 2010 (CEST)

TIFF-Warnung

Von meiner Disk kopiert:

Könntest Du noch eine Rubrik für eingebundene TIF/TIFF-Bilder hinzufügen? Derzeit werden dafür keine Thumbnails erzeugt. -- Rosentod 14:56, 23. Mai 2010 (CEST) Einziger Treffer: Datei:Hessen Kr Biedenkopf ed.tif in Kreis_Biedenkopf. Allerdings mit Dateinamensfilter. Die Query nach mime-type läuft zu lange. Merlissimo 16:42, 23. Mai 2010 (CEST) Habe ich gleich behoben. Eine regelmäßige Abfrage wäre aber trotzdem nicht schlecht. -- Rosentod 17:28, 23. Mai 2010 (CEST) Ich persönlich wäre eher für einen Missbrauchsfilter, der einen Warnhinweis einblendet, damit weiß jeder direkt, warum es nicht funktioniert. Hast du gerade die Bugbeschreibung? Dann kann ich nachsehen ob es nur tiff oder auch noch andere Bitmaps betrifft. (wobei ich den Bug bisher auch nur von tiff kenne - neben Animationen bei gif) Merlissimo 17:56, 23. Mai 2010 (CEST) [344] -- Rosentod 18:27, 23. Mai 2010 (CEST) Es scheint das Problem nur bei TIFF zu geben. -- Rosentod 18:35, 23. Mai 2010 (CEST) *push* Ich hatte gerade wieder ein paar TIFFs. Ich halte das Thema für recht wichtig, da TIFFs tendenziell sehr hochwertige Bildspenden sind. Zusatzfrage: Ließe sich nicht etwas machen, dass Dateiendungen nicht mehr case-sensitiv sind (wenn keine zwei Dateien existieren, die sich nur durch die Endung unterscheiden)? --Rosentod 20:14, 1. Jul. 2010 (CEST) Zur Dateiendung: Kurzfristig lässt sich da nichts machen. Die Idee ist aber älter, siehe Bug 4421: Image file extension should not be part of the name. Es hat schonmal jemand mit der Programmierung angefangen, ist aber wohl für den Moment eingeschlafen. — Raymond Disk. 20:25, 1. Jul. 2010 (CEST)

Die Extension:PagedTiffHandler befindet sich gerade im Review von Tim Starling (Bug 23258), somit könnte eine zeitnahe aktivierung nicht mehr so viel im Wege stehen und danach gibt es dann Thumbs von TIFF-Bildern. Ich fände den Hinweis bis dahin allerdings sinnvoll. Was ich nur nicht so gut finde, ist das es dann einen Eintrag im Log verursacht, und da man ja nichts falsch gemacht hat, ist es irgendwie komisch eine Spur zu hinterlassen, aber ich denke, damit sollte man leben, es gibt auch andere Filter die die Logs zumüllen. Der Umherirrende 21:01, 1. Jul. 2010 (CEST)

Gerade gelesen: "We should be able to deploy it in a matter of days." (comment 17) Vielleicht doch abwarten? Der Umherirrende 21:04, 1. Jul. 2010 (CEST)

real soon now™ --Rosentod 12:30, 2. Jul. 2010 (CEST)

Firefox 1.0-Benutzer-Warnung

Auf meinen Botwartungslisten benutzt mein Bot ein geschütztes Leerzeichen, deswegen fallen mir dort ständig Firefox-1 Benutzer auf. Die letzten Fälle waren [345], [346] und [347].

Der Grund dafür ist in Bug 218277 zu finden. Ich bin mir aber nicht ganz sicher, ob es auch firefox 1.5 betrifft. FF2 ist aber selbst in der Alpha-Version nicht mehr betroffen. Auf den Wartungslisten ist das egal, aber es hat ja auch Auswirkungen auf den Artikelnamensraum, vor allem da die IW-Bots das nbsp-Zeichen auch zwischen Einheiten setzen.

Ich habe in den letzten Monaten vielleicht ein halbes Dutzend Leute angesprochen und alle waren für den Hinweis dankbar und haben ihre Browserversion umgestellt. Die Frage ist, wie bekommen wir solche Bearbeitungen geloggt um die Benutzer anschließend ansprechen zu können. Ich habe versucht zu schauen ob in removed_lines ein nbsp enthalten war und im kompletten neuen Wikitext nicht mehr (weil wenn es FF war, wird es garantiert überall ersetzt). Aber ich habe es nicht hinbekommen. Merlissimo 18:29, 2. Jul. 2010 (CEST)

Regel 36

• Regel #36

Das Ding ist wohl zu restriktiv und deswegen heute auf der VM aufgeschlagen. Es verbietet mehr als 3 Änderungen an einem der gelisteten Artikel innert 30 Stunden. Punkt. Ohne Nebenbedingungen. Wenn also jemand 3 Edits braucht, um eine unbestrittene Verbesserung einzubringen kann er danach nichts mehr tun. Und das für alle Benutzer. Das ist schon sehr streng. Entweder man macht die Liste der Artikel sehr kurz (und entfernt auch Altlasten regelmässig) oder man reduziert die Sperrzeit massiv. --PaterMcFly Diskussion ^Beiträge 23:15, 3. Jul. 2010 (CEST)

Altlasten werden regelmäßig aussortiert. Ich schaue dort jede zwei Wochen nach, ob in den Artikel noch schwebende Konflikte bestehen.

Dir geht es aber um den Spielplan, einen anderen Kontext, als die anderen betroffenen Artikel. Nach der Vollsperre am ersten Tag und Ersetzung dieser durch den Filter musste die ganze WM über diese Seite nicht mehr voll gesperrt werden. Ich würde das als Erfolg bezeichnen würde. Das in diesem einen Fall auch viele sinnvolle Änderungen unterdrückt werden können habe ich absichtlich in Kauf genommen, da dies eine Abwägung gegenüber ständige temporäre Vollsperren war und aufgrund der hohen Beteiligung kein Aktualisierungsnachteil zu befürchten war. Merlissimo 23:28, 3. Jul. 2010 (CEST)

Ah, ok. Ich hatte zunächst gar nichts von einem Edit-War gesehen. Es sah für mich zunächst sogar nach einer Präventivsperre aus. Aber wenn es da tatsächlich Gekloppe gab, ist das natürlich eine akzeptable Möglichkeit. --PaterMcFly Diskussion ^Beiträge 13:31, 4. Jul. 2010 (CEST)

Um das nachvollziehen zu können musst du dir die Hauptseite ansehen. Nach der Vollsperre habe ich den Spielplan auf die Unterseite ausgelagert um nur diesen Datenteil entsprechend schützen zu können und den Hauptartikel weiter ohne Filter zu belassen. Inzwischen gibt es ja nicht mehr so viele Spiele insofern bin ich optimistisch, dass es nun auch ohne klappt. Merlissimo 15:50, 4. Jul. 2010 (CEST)

diskussionsseitenschutz

• Regel #50

da auf einer diskussionsseite auch nach mehrfachen hinweisen immer wieder unsachliche beitraege eingefuegt wurden, habe ich jetzt das abusefilter zuhilfe genommen. sollte in wenigen wochen unnoetig geworden sein. -- seth 22:41, 16. Jul. 2010 (CEST)

Hauptseite

Früher (in der guten alten Zeit) konnten alle Benutzer (sogar unangemeldet, wenn ich mich richtig erinnere) die einzelnen Vorlagen auf der Hauptseite bearbeiten. Der einzige mir bekannte Grund, warum dies nicht mehr so ist, war der Angriff, bei dem durch das Einbinden der letzten Änderungen die Server massiv überlastet wurden. Diesen und ähnliche Angriffe könnten doch mit dem Missbrauchsfilter verhindert werden, indem man das Einfügen von zwei geschweiften Klammern in Hauptseitenvorlagen verbietet. Natürlich muss sich der Admin, der einen solchen Filter einrichtet und danach die Kaskadensperrung aufhebt, seiner Sache absolut sicher sein, aber es sollte doch möglich sein, so einen Filter einzurichten, sodass man nicht für jeden Rechtschreibfehler auf der Hauptseite einen Admin braucht. --Schnark 10:31, 7. Aug. 2010 (CEST)

Dennoch sollte man es mit einem Filter verbieten, dass jeder ab autoconfimed die Vorlagen bearbeiten kann, sonst gäbe das zu viel Vandalismus. Sichter wären dafür sicher geeigneter. 188.23.2.40 07:07, 16. Aug. 2010 (CEST)

Nicht bearbeitete Zusammenfassung aktivieren

Könnte man den Filter wieder für IPs aktivieren? Angemeldete Benutzer können es ja sowieso einstellen, ob sie gewarnt werden, insofern wäre es sinnvoll, wenn der Filter nur für IPs gilt. 188.23.2.40 07:05, 16. Aug. 2010 (CEST)

Warschauer-Vertrag-Troll

Kann für IPs aus der Range 79.226.64.0/19 solche Bearbeitungen verhindern? Es mussten bereits mehrere Artikel und Diskussionsseiten halbgesperrt werden, aber es gibt genügend Ausweichziele für den Troll. Beispiele von IPs:

• 79.226.95.16 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)
• 79.226.79.88 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)
• 79.226.78.203 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)
• 79.226.76.46 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)
• 79.226.80.243 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)
• 79.226.83.77 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)
• 79.226.95.107 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)

Danke und Gruß --Engie 12:14, 31. Aug. 2010 (CEST)