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?

Artikelneuanlagen mit wenigen Wörtern verhindern

• Regel #9.

Bisherige Diskussion.

Ich würde folgendes vorschlagen: Im Artikelnamensraum nur noch Artikelneuanlagen mit mehr als 10 Wörtern (alternativ mit mehr als 60 Buchstaben) zulassen, oder wenn die Seite die Wörter 'Weiterleitung', 'Redirect', 'Falschschreibung', 'Begriffsklärung' enthält. Es soll bei Verhinderung der Anlage ein Hinweis auf die Spielwiese kommen.

Grüße von Jón + 10:39, 7. Mär. 2009 (CET)

um die diskussion nicht parallel zu fuehren, schlage ich vor, deinen request erst mal nur als hinweis auf jene diskussion zu sehen und sie dort weiterzufuehren. wenn's um die konkrete umsetzung geht, koennen wir ja immer noch herswitchen. -- seth 14:08, 7. Mär. 2009 (CET)

die regel

old_size==0 & new_size<60 & article_recent_contributors==user_name & article_namespace==0 & action=="edit" & !(user_groups contains "editor" | added_lines rlike "/(?i:\{\{.*\}\}|redirect|weiterleitung)/")

scheint mir in der diskussion weitgehend akzeptiert worden zu sein.

ich schlage vor, sie schon mal zu aktivieren, aber vorerst auf tag-only zu setzen, um sicherheitshalber zu schauen, was man damit alles faengt. die diskussion ueber die regel kann ja auf der bisherigen seite weitergefuehrt werden. -- seth 00:45, 14. Mär. 2009 (CET)

da keine einwaende mehr kamen, habe ich jetzt die regel jetzt als [1] aktiviert, wobei derzeit bloss mitgeloggt wird. -- seth 21:36, 9. Apr. 2009 (CEST)

die regel laeuft jetzt seit ca. 2 monaten, aber hat nur 10 edits erfasst. wenn keine einwaende bestehen, wuerde ich die regel deshalb gerne komplett deaktivieren. -- seth 14:40, 7. Jun. 2009 (CEST)

bechterev aka evakuierungstroll aka 84.167.* ...

• Regel #3.
• Regel #4.
• Regel #5.

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[2][3]). 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)

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. [4].

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?. [5], [6], [7], [8], 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 :-( : [9] 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 [10] und [11]. 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)

einzelner soll einzelnen Artikel nicht bearbeiten

Der Artikel Hochstapler wurde geschützt, da zwei sich gegenseitig ihre Änderungen rückgängig gemacht haben. Zum einen ein anonymer Benutzer, zum anderen Knoerz. Siehe auch die Versionsgeschichte. Eine Halbsperre reicht nicht aus, daher wurde eine Vollsperre gesetzt. Wenn man nun nur Knoerz das Bearbeiten verbieten würde, würde eine Halbsperre ausreichen. --linveggie in Memorian Anita Roddick 20:05, 6. Apr. 2009 (CEST)

Hilfe:Missbrauchsfilter (v. a. „Der Missbrauchsfilter (Englisch: abuse filter) ist ein vielseitig einsetzbares Werkzeug zur Vandalismusbekämpfung.“ und Hilfe:Missbrauchsfilter#Beispiele) … —DerHexer (Disk., Bew.) 23:25, 6. Apr. 2009 (CEST)

naja, ein edit-war kann ja schon haeufig in richtung vandalismus gehen; tut es aber auch meiner meinung nach hier noch nicht. aber das AF wird nicht nur zur vandalismusbekaempfung genutzt. die signatur-regeln sind ja beispiele dafuer.

wie auch immer, ich denke, dass hier einfach eine kurze vollsperre genuegt. die diskussionsseite wird ja auch schon fleissig genutzt. in kuerze wird wohl die vollsperre aufgehoben, falls der edit-war weitergehen sollte, werden dann wohl eher user temp. gesperrt. insofern halte ich die anwendung der AF hier nicht fuer noetig. -- seth 23:36, 6. Apr. 2009 (CEST)

Dass damit nicht nur Vandalismus gefiltert wird, belegt mein Link auf die Beispiele … Ein Editwar ist aber nunmal ein inhaltlicher Disput und kein Vandalismus. Da eine Meinung zu unterdrücken, würde an Zensur grenzen. Grüße, —DerHexer (Disk., Bew.) 23:43, 6. Apr. 2009 (CEST)

So können den Artikel niemand außer Admins bearbeiten. Ansonsten alle angemeldeten außer Knoerz. Das Ergebnis ist, dass für alle anderen eine Änderung gegenüber der Halbsperre erfolgt und für Knoerz keine. --linveggie in Memorian Anita Roddick 00:07, 7. Apr. 2009 (CEST)

Ja, und dies kann man Diskriminierung, Zensur oder Unterdrückung von Meinungen nennen, aber nicht mehr Wiki im Sinne unserer Grundprinzipien. Grüße, —DerHexer (Disk., Bew.) 00:28, 7. Apr. 2009 (CEST)

Aber er kann doch die Seite auch bei einer Vollsperre nicht bearbeiten. Wenn das umgesetzt wird, können's alle seit 3 Tagen angemeldeten außer er nicht bearbeiten. --linveggie in Memorian Anita Roddick 01:47, 7. Apr. 2009 (CEST)

Ja, und damit würde er unterdrückt/zensiert. Was ist daran <nicht> zu verstehen? Inhaltliche Einschränkungen sollte es im Missbrauchsfilter nicht geben. Grüße, —DerHexer (Disk., Bew.) 15:35, 7. Apr. 2009 (CEST)

Warum eigentlich genau in dieser Allgemeinheit? Wenn sich X und Y in z Artikeln kloppen (ich erinnere mich an die Kategorie:Mörder oder Pseudowissenschaft) kann man mit dem AF gezielt solches Gemurkse verhindern statt z Artikel vollzusperren (oder Benutzer temporär, die danach eh weitermachen). --Complex 17:56, 7. Apr. 2009 (CEST)

Nur wozu braucht man da einen Filter? Wenn jemand die Autorität hätte, hätte er den Betreffenden schon immer mitteilen können, bearbeite den Artikel nicht oder lange Sperre. Das Problem ist dabei aber die Autorität. Sollen einzelne Admins so ein Artikelverbot aussprechen können? Das SG? Soll die Community über soetwas abstimmen wie bei Sperrverfahren? --Tinz 19:10, 7. Apr. 2009 (CEST)

Sperre macht Ärger und hinterlässt viel Geblubber auf allen möglichen Seiten, ein Filter könnte im Einzelfall etwas deeskalierender wirken. Dem SG vertraue ich da kein bisschen, das wäre aber wohl formal geeignet. Ebenso Community-Auflagen in einem Sperrverfahren.. --Complex 19:19, 7. Apr. 2009 (CEST)

Und ich vertraue keinem inhaltlich zensierenden Filter. Grüße, —DerHexer (Disk., Bew.) 17:18, 8. Apr. 2009 (CEST)

Es geht ja auch nicht um Zensur ("X darf dort nicht stehen") wie bei dieser Namensgeschichte im Amstetten-Fall, sondern um flexible Vermeidung von Editwars ohne gleich ganze Artikel zu sperren. --Complex 09:30, 9. Apr. 2009 (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)

Springer-Linkspam auf Autobild Artikel

• Regel #13.

Wegen dieser VM möchte ich bitten, einen Missbrauchsfilter einzurichten, der es IPs aus dem Springerrange 145.243.0.0/16 verbietet in Artikeln auf URLs der Domain www.autobild.de zu verlinken. Testweise für einen Monat, um die Häufigkeit zu prüfen. Gruß -- blunt. 13:23, 12. Mai 2009 (CEST)

Ich habe da mal was vorbereitet (Filter 13). In meinen Tests funktionierte es auch. -- blunt. 14:39, 12. Mai 2009 (CEST)

gemaess der VM sollte aber doch eigentlich das blockieren der kleineren range "145\.243\.190\.4[4-7]" genuegen, oder? weiterhin sollte imho nicht "gethrottlet" sondern gleich blockiert werden. die regel ist ansonsten imho ok. -- seth 22:30, 12. Mai 2009 (CEST)

Ich dachte, das drosseln drin zu lassen falls doch Artikelarbeit aus dem Range kommen sollte, bei dem die Links eventuell mal als refs verwendet werden. Den größeren Range wollte ich verwenden, um weitere IPs aufzudecken und zu protokollieren, denn es kann Zufall sein, dass nur die vier bekannten aus dem Range verwendet wurden. -- blunt. 23:03, 12. Mai 2009 (CEST)

drosseln: ok, macht vielleicht sinn. schaden tut's jedenfalls erst mal nicht. besser zu vorsichtig geblockt als zu restriktiv.

weitere ips aufdecken: dafuer braucht es keine AF-regel, sondern dafuer koennen wir einfach COIBot verwenden. und der sagt:

277 records; Top 10 editors who have added autobild.de: 145.243.190.46 (26), 145.243.190.47 (20), 145.243.190.45 (13), A3 RoDa (11), Thomas doerfer (7), 145.243.190.44 (5), Crazy1880 (4), Wahldresdner (4), 82.113.121.16 (4), 62.158.65.80 (3).

insofern braucht da imho keine groessere range genommen werden. -- seth 23:26, 12. Mai 2009 (CEST)

OK, dann den kleineren Range. Ich setze es ein. -- blunt. 23:40, 12. Mai 2009 (CEST)

AF statt Semi-Sperre

thread geteilt, neue ueberschrift, indent. -- seth 23:26, 12. Mai 2009 (CEST)

Etwas anderes: Ich würde gerne einen Versuch machen, statt über die Halbsperre einen bestimmten Artikel per Abusefilter zu schützen, um so zu sehen welche Änderungen dort durch die Sperre verloren gehen. Der Artikel wäre Bushido (Rapper), der sogar für viele angemeldete problematisch ist. Wäre ein solcher Test möglich und könnte jemand den Code dafür schreiben? Gruß -- blunt. 23:03, 12. Mai 2009 (CEST)

wie genau stellst du dir das in der ausfuehrung vor? wenn ein user einen artikel scheinbar bearbeiten kann, aber erst beim absenden ne olle fehlermeldung vorgesetzt bekommt, waere das ja nicht besonders nett. klar, man koennte den user in der meldung darauf hinweisen, dass die aenderungen erst gegengelesen werden. aber so ein system haben wir ja bereits: GV. vielleicht ist mir bloss noch zu unklar, wie genau du deinen vorschlag meinst. -- seth 23:26, 12. Mai 2009 (CEST)

Ehrlich gesagt geht es mir aktuell weniger um den Ersatz der Halbsperre durch den AF, als um eine Art statistischer Erhebung. Mich interessiert, wie oft und wie dieser spezielle Artikel durch unangemeldete bearbeitet wird. Warum dieser Artikel? Hier kann man ein gutes Sample nehmen, was in populären Rapper-Artikeln (hier 85.000 Hits) zu erwarten ist. Eine hohe Bearbeitungsfrequenz ist ebenfalls zu erwarten. Eine Freigabe für alle unter dem Schutz der GSV halte ich nicht für sinnvoll, da selbst von angemeldeten meist nur Unsinn kam.

Aus den Daten könnte man dann eine Liste mit Bearbeitungen konstruieren, die in solchen brisanten Artikeln nicht zu gelassen werden und die Artikel sonst freigeben. Wirkliche Artikelarbeit wollen wir ja auch grade von IPs haben. -- blunt. 23:39, 12. Mai 2009 (CEST)

hmm, sorry, aber ich verstehe immer noch nicht, wie du dir das praktisch vorstellst. wie soll die statistische erhebung ablaufen, ohne dass man leute, die was sinnvolles beitragen wollen, aergert? -- seth 22:19, 13. Mai 2009 (CEST)

na, jetzt können sie gar nichts beitragen. so viele werden es auch nicht sein, die etwas sinnvolles beitragen wollen. blunt. 22:22, 13. Mai 2009 (CEST)

Bei einer gewoehnlichen Semi-Protection koennen Verbesserungsvorschlaege auf der DS gemacht werden und keine unangemeldeter User kommt in die Versuchung Zeit fuer nicht-erlaubte Aenderungen zu verscwenden. Wenn der Artikel jedoch scheinbar unprotected ist, sieht es so aus, als koennte man ihn aendern, man bekommt aber beim Absenden ein "Aetsch!" vorgesetzt. Das ist erst mal weit schlimmer als von vornherein zu wissen, dass man einen Artikel nicht editieren kann.

Nun ja, man muesste also versuchen, die "Aetsch!"-Meldung so zu formulieren, dass unbedarfte Leute verstehen, dass ihre Aenderungen nicht futsch sind, sondern gegengelesen werden. Zudem koennte man ganz oben auf der Artikelseite einen Hinweis platzieren, der die Leute im vornherein auf den Umstand hinweist.

Allerdings wuerde das alles zusammen dann so ein bissl so aussehen wie die geprueften Versionen, die vielleicht mal irgendwann eingefuehrt werden, es aber noch nicht sind. Andererseits geht's ja nur um einen einzelnen Artikel, der sonst offenbar (hab ihn mir nicht angeschaut) semi-protected werden muesste. Hmm, warten wir mal weitere Meinungen ab; ich hab auch extra Grossbuchstaben eingesetzt, damit der Complex nicht zurueckschreckt, meine Antwort zu lesen und ggf. darauf zu antworten. -- seth 22:40, 13. Mai 2009 (CEST)

Ich vergaß zu erwähnen, dass die ganze Aktion auch zeitlich begrenzt sein soll. Etwa ein oder zwei Wochen. -- blunt. 22:44, 13. Mai 2009 (CEST)

Navigationstechnik/Klappboxen im Artikel

Für die Navigationsleisten stehen Klappboxen zur Verfügung. Diese werden auch mal gerne in Artikel eingesetzt, was sie aber nicht sollen, da sie unnötigerweise Informationen verbergen und diese auch nicht ausgedruckt werden können. Ich schlage vor, einen Hinweis zu setzen, wenn diese Technik im Artikelnamensraum eingefügt wird. Zusätzlich könnte man den gleichen Hinweis geben, wenn die Technik bereits eingesetzt ist. Dies würde ich aber auf autoconfirmed-Benutzer beschränken, da man damit nicht jede IP belästigen sollte, die einen Rechtschreibfehler ausbessert, sondern nur Personen, die dann auch damit etwas anfangen können. Meinungen sind willkommen. Der Umherirrende 21:04, 23. Mai 2009 (CEST)

gudn tach!

gab es bereits diskussionen ueber die ausklappbaren dinger bzw. steht in unseren regeln irgendwas darueber? wie haeufig (geschaetzt) kommt das fehlsetzen dieser teile vor?

warnings bei usern auszugeben, die nichts fuer die ursache des warnings koennen, halte ich meist fuer ne schlechte idee, so auch hier. denn solche hinweise werden vermutlich von vielen als nervend empfunden.

imho geht's also nur um die warnung bei der expliziten einfuegung solcher klappteile. falls sich niemand gegen deinen vorschlag ausspricht, sollte ein darauf zugeschnittener text erstellt werden, der als warning praesentiert wird. -- seth 23:55, 24. Mai 2009 (CEST)

Zur Häufigkeit kann ich nichts sagen, aber man sieht es halt in Artikeln, also ist es zumindestens nicht falsch. Wikipedia:Fragen zur Wikipedia/Archiv/2009/Woche 14#Einklappbare Tabellen, Wikipedia:Fragen zur Wikipedia/Archiv/2009/Woche 08#Liste in einklappbarem Feld und auf den anderen Archivseiten, dürften sich einige Diskussion finden, die sich dagegen aussprechen. Es soll nur ein Vorschlag sein, wenn sich keiner dafür ausspricht, dann kann es auch bleiben. Der Umherirrende 21:22, 25. Mai 2009 (CEST)