Wikipedia

MediaWiki Diskussion:Spam-blacklist

(Weitergeleitet von MediaWiki Diskussion:Spam-whitelist)
Letzter Kommentar: vor 2 Monaten von Lustiger seth in Abschnitt Verbesserungsvorschlaege/Fragen zur SBL
Einleitung dieser Diskussionsseite anzeigen
Abkürzung: WP:SBL
Link-Blacklist

Die Einträge der Spam-Blacklist der deutschsprachigen Wikipedia und der Spam-Blacklist des Meta-Wikis verhindern, dass Wikipedia-Seiten gespeichert werden können, falls auf den Seiten (oder in der Zusammenfassung) versucht wird, eine unerwünschte Webseite (oder eine ganze Website) neu zu verlinken, die in der Blacklist aufgeführt ist. Bereits bestehende Weblinks werden seit Mai 2008 durch diese Liste nicht mehr tangiert.

Die Einträge der Spam-Whitelist verhindern, dass bestimmte Webseiten, die in der globalen oder lokalen Blacklist stehen, geblockt werden.

Wie funktioniert diese Seite?

Bearbeiten

Im Folgenden wird die Vorgehensweise für (Ent-)Sperr-Requests beschrieben. Die Kenntnis der Richtlinien für externe Links in der Wikipedia wird vorausgesetzt.

Vorgehen bei Entsperr-Requests

Bearbeiten
  • Zunächst schauen, von welcher Blacklist der Link gesperrt wird. Dies kann über ein Tool herausgefunden werden, das zudem diverse Logdateien durchsucht. Dort sollte auch ein Grund für eine etwaige Sperre und eine zugehörige Diskussion ausgespuckt werden.
  • Falls der Link von der lokalen (deutschsprachigen) Blacklist geblockt wird: Wenn in deinen Augen nach Lesen der Begründung/Diskussion immer noch eine Entsperrung sinnvoll ist, platziere am Ende dieser Seite deinen Request. Verlinke dabei ggf. bereits geführte Diskussionen darüber.
  • Falls dagegen der Link von der globalen Blacklist gesperrt wird: auf der talk page der Spam-Blacklist auf Meta Entsperr-Request stellen. Wird der Request dort abgelehnt, besteht die Möglichkeit, den Link in die lokale Whitelist aufzunehmen. In diesem Fall platziere deinen Request auf dieser hier Seite ganz unten.
  • Spezialfall Google-Links: Handelt es sich bei dem gesperrten Link um einen, der über google auf die eigentliche Seite weiterleitet, so lässt sich der wahre, kürzere URL durch ein Tool extrahieren. Dann sollte es in der Regel keine Probleme mehr durch die SBL geben.
  • Für Entsperrwünsche von Links aus dem medizinischen Bereich bitte direkt an die Redaktion Medizin wenden.

Vorgehen bei Sperr-Requests

Bearbeiten
  • zuerst prüfen, ob eine User-/Artikel-Sperre evtl. die bessere Alternative wäre. In diesem Fall Vandalismus melden.
  • hier auf dieser Diskussionsseite sowie deren Archiv nach Diskussionen darüber suchen.
  • wenn in deinen Augen dann immer noch eine Sperrung sinnvoll ist, platziere am Ende dieser Seite hier deinen Request. Dabei:
    • lass stets die Angabe des Protokolls http:// bzw. https:// des fraglichen URLs weg,
    • begründe, weshalb eine Sperre erforderlich ist,
    • verlinke -- soweit bekannt -- bereits geführte Diskussionen zum Thema,
    • gib Diffs an, die belegen, dass gespammt wurde.

Verbesserungsvorschlaege/Fragen zur SBL

Bearbeiten
Letzter Kommentar: vor 2 Monaten48 Kommentare9 Personen sind an der Diskussion beteiligt

Saubere Projektseite, mehr Ordnung

Bearbeiten

startbeitrag herverschoben von WD:EL. -- seth 10:19, 6. Jan. 2014 (CET)Beantworten

Die Rückmeldungen und Bedienungshinweise beim unbeabsichtigten Auslösen der SBL sind allerdings gewöhnungsbedürftig. Erinnert etwas an WP:DWL Mitte 2012: „Nicht hilfreich“. Es fehlt eine saubere Projektseite WP:Spam, auch als Unterseite dieser WP:EL realisierbar. Momentan ist WP:SBL eine WL auf MediaWiki Diskussion:Spam-blacklist und diese eine krude Mischung aus Diskussionsseite, Funktionserklärung und Antragsseite. Die Funktionserklärung gehört in den WPNR, und zu dieser dann eine eigene Diskussionsseite WD:, die sich mit der Verständlichkeit der Projektseite beschäftigt. --PerfektesChaos 18:11, 4. Jan. 2014 (CET)Beantworten

gudn tach!
einen besseren namen als "spam" sollte man vermutlich aussuchen, weil nicht alles, was auf der sbl landet, spam ist.
welche struktur schlaegst du vor? -- seth 10:21, 6. Jan. 2014 (CET)Beantworten
  1. Ich würde gern die Top-Ebene des WP-NR von inhaltlichen Seiten entlasten und verstärkt mit Unterseiten arbeiten:
  2. Innerhalb einer Seite WP:Weblinks/Blockade die folgende Gliederung:
    • Funktionsbeschreibung
      • Zweck
      • Wann genau wird die Blockade ausgelöst, wann nicht?
      • Wo und was sind die blacklist; lokal, global; gibt es eine whitelist? gibt es Ausnahmeregeln für Namensräume (Wirksamkeit nur im ANR)?
    • Hilfe, ich bekomme die Seite nicht gespeichert, was mach ich jetzt bloß?
      • Hierher verlinken aus der Systemnachricht, die bei der Auslösung gezeigt wird.
    • Ich möchte eine URL blockieren lassen
      • Bedingungen dafür, Art der Begründung; lokal, global?
      • Verweis auf Antragsseite
    • Ich finde, eine URL könnte entblockiert werden.
      • Bedingungen dafür, Art der Begründung; lokal, global?
      • Verweis auf Antragsseite
    • Aktuelle Blacklist
      • Wo zu finden; lokal, global?
      • Weitere Listen und Kandidaten; etwa Mirror.
      • Auffinden von Einzelfallbegründungen
      • Hinweise für bearbeitende Admins.
  3. Antragsseite
    • Würde ich wie alle anderen Anfragen und Anträge lieber im WPNR sehen; somit WP:Weblinks/Blockiert/Anfragen
      • Diese Seite hier und ihr Archiv kann dorthin verschoben werden.
  4. Hilfeseite (=HNR)
    • Würde ich nicht ausgliedern; zu wenig.
    • Wäre der Inhalt von „Funktionsbeschreibung“.
    • Besser auf einer Seite mit den dewiki-Spezifika zusammenhalten. Hilfeseiten beschreiben die Software-Funktion; das käme für die mw:Extension in Frage, aber ist zu mager und die Gesamt-Seite ist nicht so ewig lang.
    • Bekommt von Amts wegen eine WL auf die Funktionsbeschreibung.
schönen tach --PerfektesChaos 10:51, 6. Jan. 2014 (CET) 10:58, 6. Jan. 2014 (CET)Beantworten
gudn tach!
hast du den kasten oben rechts auf dieser seite (bzw. WP:Spam-blacklist/navigation) gesehen und die seiten, auf die dort verlinkt wird, bereits beruecksichtigt? -- seth 00:58, 7. Jan. 2014 (CET)Beantworten
Selbstverständlich.
Bevor ich konkreter antworte, würde ich gern wissen, wie deine Rückfrage hinsichtlich Berücksichtigung zu verstehen ist:
  1. Es gibt ja diesen Kasten, damit ist doch schon alles klar.
  2. In diesem Kasten sind Seiten wie WP:Spam-blacklist/manual verlinkt, deren Position noch nicht explizit in der oben grob skizzierten Seitengliederung benannt ist.
Schönen Tag --PerfektesChaos 10:42, 7. Jan. 2014 (CET)Beantworten
gudn tach!
oh, ich meinte 2., denn der kasten ist ganz sicher nicht optimal. -- seth 17:05, 7. Jan. 2014 (CET)Beantworten


Na, dann stelle ich mal etwas ausführlicher dar, wie ich mir sowas vorstelle.

(Seitennamen als Arbeitsvorschlag; mögen noch anders gewählt werden)
Die Zahl der Sternchen entspricht ggf. der Zahl der Gleichheitszeichen im Überschriftenlevel.
  • WP:Weblinks/Blockade oder /Blockiert = WP:SBL etc.
    • Zielgruppe:
      • Allgemein interessierte Wikipedianer, die sich mal informieren möchten
      • Benutzer mit aktuellem Problem mit einer Domain oder URL
      • Admin-Startseite
    • Funktionsbeschreibung
      • Zweck der ganzen Sache
      • Wann genau wird die Blockade ausgelöst, wann nicht?
      • Wo und was sind die blacklist; lokal, global?
        • Wozu gibt es eine lokale whitelist, wie wirken die zusammen?
        • Gibt es Ausnahmeregeln für Namensräume (Wirksamkeit nur im ANR)?
    • Hilfe, ich bekomme die Seite nicht gespeichert, was mach ich jetzt bloß?
      • Hierher verlinken aus der Systemnachricht, die bei der Auslösung gezeigt wird.
    • Allgemeine Politik der deWP
      • Welche Grundsätze gelten für das Sperren?
      • Wann käme Entsperrung oder lokale whitelist in Frage?
    • Benutzerwünsche
      • Ich möchte eine URL blockieren lassen
        • Bedingungen dafür, Art der Begründung; lokal, global?
        • Verweis auf Antragsseite; deutschsprachig ausdiskutieren
      • Ich finde, eine URL könnte entblockiert werden.
        • Bedingungen dafür, Art der Begründung; lokal, global?
        • Verweis auf Antragsseite; deutschsprachig ausdiskutieren
    • Aktuelle Blacklist
      • Wo zu finden; lokal, global?
      • Weitere Listen und Kandidaten
        • Mirror
        • Redaktion Medizin
        • Redaktion Chemie
        • Redaktion Naturwissenschaft und Technik
      • Auffinden von Einzelfallbegründungen
      • Hinweis auf /Vorgänge
    • Hilfsmittel
      • Tool1, Zweck1, Bedienung1
      • Tool2, Zweck2, Bedienung2
      • Tool3, Zweck3, Bedienung3
    • Hinweise für bearbeitende Admins.
    • Weitere Informationen
      • [[../]] = WP:EL
      • WP:BELEGE
      • Spam-Blacklist (meta)
      • Spam-Blacklist-Portal (en)
      • Extension:SpamBlacklist (mw)
  • WP:Weblinks/Blockade/Anfragen oder /Anträge
    • Zielgruppe:
      • Benutzer mit aktuellem Problem mit einer Domain oder URL
      • Abarbeitende Admins
    • Wünsche sowohl betreffend lokal wie auch global, Sperrung und Entsperrung
    • Ein Abschnitt je Angelegenheit
      • Nur offene Angelegenheiten
    • Globale Angelegenheiten werden deutschsprachig geklärt und administrativ entschieden; danach von Admins auf meta: umgesetzt oder angeregt. Auch die Entscheidung, ob lokal oder global geeigneter, wird hier administrativ getroffen.
    • Archivierung: Erledigt-Modus, nach etwa einer Woche
    • Für Admins ein Hinweis auf [[../Administration]] oder auch Abschnittseinbindung mit <section>
    • Für Benutzer ein Hinweis auf [[../#Benutzerwünsche]] oder auch Abschnittseinbindung mit <section>
  • WP:Weblinks/Blockade/Anfragen/Archiv
    • Zielgruppe:
      • Alle, die wissen wollen, aus welchen Hintergründen eine Domain oder URL blockiert wird.
    • Textsuche zu empfehlen. Überschriften sind nicht hinreichend.
    • Ursache könnte auch bei meta: stehen; dorthin geeignet verlinken.
  • WP:Weblinks/Blockade/Administration
    • Zielgruppe:
      • Abarbeitende Admins
      • Offene Politik, darf jeder sehen
    • Handlungsanweisungen und nur von Admins operativ umsetzbare Links und Aktivitäten
    • Projektspezifische deWP- und meta:-Politik
    • Arbeitsabläufe; darunter der Abschnitt „Vorgehen“ ein Stück weit hier drüber.
      • Falls l.s. mal eine Urlaubsvertretung oder Nachfolger braucht.
    • Verlinkung auf [[../Technik]] etc.
    • Verlinkung auf Systemnachrichten mit Konfiguration und Bedienungsanleitung
      • (wohl zwei Links aus der Navibox; entfallen dort)
    • Verlinkung auf IRC-Channels; vermutlich nur für Admins wichtig
      • (wohl zwei Links aus der Navibox; entfallen dort)
  • WP:Weblinks/Blockade/Format oder /Technik oder /Syntax oder so
    • Zielgruppe:
      • Abarbeitende Admins
      • Techies, beratende Software-Experten
      • Offene Politik, darf jeder sehen
      • Für Normalbenutzer wahrscheinlich unverständlich und uninteressant; ohne Admin-Rechte wenig damit anzufangen.
    • Vermutlich die verschobene Seite Wikipedia:Spam-blacklist/manual (so nach erster Durchsicht).
    • Neutrale, im Prinzip auf jedes Wiki anwendbare technische Doku.
    • Keine projektspezifische Politik und Richtlinien.
  • WP:Weblinks/Blockade/Vorgänge
  • Diese Seite hier:
    • Verschieben; verbleibt nur noch ein Hinweis auf die Startseite.
  • Navibox stark gekürzt (verwirrend) oder entbehrlich

VG --PerfektesChaos 00:16, 8. Jan. 2014 (CET)Beantworten

gudn tach!
hui, ganz schoen viel holz. ueber die benamung der konkreten seiten muesste man sich noch mal unterhalten; aber das ist zweitrangig. also antworte ich erst mal auf den vorschlag zur eigentlichen strukturaenderung:
  • eine separate uebersichtsseite, die einem alles erklaert (also die jetzigen abschnitte WP:SBL#Wie funktioniert diese Seite?, teile von Wikipedia:Spam-blacklist/manual#Richtlinien, das intro dieser seite hier, nur ausfuehrlicher), halte ich fuer sinnvoll.
  • somit waere die hiesige seite nur noch eine reine request-seite (das, was bei dir /Anfragen waere).
  • ein archiv der requests gibt's ebenfalls schon, allerdings wird das manuell (von mir) gepflegt, weil bots dafuer zu doof waeren bzw. erst noch gebastelt werden muessten.
  • /Technik waere der technische teil vom jetzigen Wikipedia:Spam-blacklist/manual. ich wuerde da aber auch teile von /Administration einordnen, und /Administration selbst somit als ueberfluessig erachten. bspw. das mit der urlaubsvertreteung ist eine nette idee, jedoch sind pragmatisch betrachtet WP:AAF oder AP:AN da die besseren anlaufstellen dafuer, weil /Administration zu wenige watcher haette.
  • Wikipedia:Spam-blacklist/watchlist koennte von mir aus komplett eingestampft werden; wird eh kaum benutzt.
  • den sinn von /Vorgänge habe ich noch nicht verstanden. ich finde es besser, wenn alles, was besprochen wird, zentral auf einer seite stattfindet, weil man somit auch die anzahl der leute, die die sachen auf ihrer watchlist haben, moeglichst gross haelt. und seit existenz der sbl haben diese talk page hier eigentlich zu wenige leute auf ihrer watchlist. durch eine aufteilung wuerden es vermutlich noch weniger.
  • navibox: braucht man bei aufteilung der seiten noch mehr als jetzt.
uebrig bliebe nach meinen streichungen/aenderungen (wie gesagt, die konkrete benennung der seiten ist ein zweites thema):
  • uebersicht/portal (manual fuer user und richtlinien fuer alle)
    • technik (technisches manual fuer admins und interessierte user)
    • requests (diese seite hier, ohne manual-zeugs)
      • archiv (wie gehabt)
  • funktionalseiten MediaWiki:Spam-blacklist (und whitelist) bleiben logischerweise unveraendert bestehen
  • WP:Spam-blacklist/log bleibt ebenfalls so bestehen, weil konsistent mit en und meta.
und, was meinst du? -- seth 16:37, 12. Jan. 2014 (CET)Beantworten
  • Ein Missverständnis:
    • /Administration verstehe ich als nicht-technische, projektorganisatorische Bedienungsanleitung für Administratoren, nichts sonst.
    • /Administration ist keine Anfragenseite und braucht auch keine watcher.
    • watcher gehören zur Antrags/Anfrageseite.
    • Die rein technischen Detailfragen, auch wenn sie mangels Schreibberechtigung nur für Administratoren relevant sind, würde ich auf einer separaten und projektneutralen Seite /Technik usw. belassen. Meiner Erfahrung mit dem Schreiben von Bedienungsanleitungen nach führt das zu einer wesentlich klareren Struktur der Seiten. Nebenbei gilt diese dann auch für jedes Wiki-Projekt.
  • Diesen Namensraum „MediaWiki Diskussion“ möchte ich komplett verlassen.
    • Anfragen gehören (wie die WP:AF zeigen) grundsätzlich in den Projekt-Namensraum.
    • Es sind immer auch Anfragen zu den Gegebenheiten und Rahmenbedingungen des Projekts.
    • Diese Seite hier kann mitsamt ihrem Archiv auch dorthin verschoben werden.
    • Warum angeblich die automatische Archivierung nicht funktioniert haben soll, erschließt sich mir nicht. Überall anders klappt das; aber vielleicht deshalb nicht, weil das hier alles etwas sehr eigen konstruiert ist.
    • Und dann auch wie von jeder anderen Seite gewohnt auf die Unter-Unterseite /Archiv archivieren.
  • /Vorgänge
    • Das ist der Auffangraum für die watchlist und ggf. die IRC-Kanäle, wobei sich mir weder der Sinn/Zweck der einen noch der anderen erschlossen hat; mangels hinreichender Zweckbeschreibungen.
    • Meint die misstrauische Beobachtung von Marketing-Kampagnen oder Artikel-Infiltration, ohne direkt zu einem Eintrag in der Blacklist zu führen. Könnte auch durch interessierte Normalbenutzer beschickt werden.
    • Wenn die watchlist aber ohnehin nicht mehr sinnvoll ist, wäre der Verbleib neu zu bewerten. Erstmal hatte ich alle Seiten unterzubringen.
    • Zu den „Vorgängen“ zählt auch das log.
  • WP:Spam-blacklist/log wäre eine Weiterleitung, wenn es der Konsistenz mit en und meta bedarf.
    • Wir gliedern aber ganz allgemein unsere Projektseiten nach unseren Bedürfnissen; und nicht danach, wie irgendwelche Seiten auf en oder meta heißen mögen.
    • Wobei die Seite WP:Spam-blacklist/log konfus ist, weil sie derzeit Unterseite einer nicht existierenden Seite WP:Spam-blacklist ist; auch das machen wir grundsätzlich nie, um die Seitenstruktur noch durchschaubar zu halten.
  • Sinn der Sache ist es, bei Spezial:Präfixindex einen zusammenhängenden strukturierten Teilbaum sämtlicher inhaltlicher Seiten zu bekommen (alles andere mögen Weiterleitungen sein), und nicht ein Verwirrspiel quer durch die Namensräume, mit dem einem Präfix für die eine Seite, und wieder einem anderen Präfix da, und die Anfragen dann wieder dort.
    • Die einzigen Ausnahmen hiervon sind die wirksame blacklist und whitelist, die zwangsläufig im Namensraum „MediaWiki“ stehen müssen – was auch für alle nachvollziehbar ist.
  • An den Anfang jeder meiner Seitenbeschreibungen hatte ich eine Zielgruppenorientierung und einen Seitenzweck gestellt – ist das soweit eingängig?
VG --PerfektesChaos 18:20, 12. Jan. 2014 (CET)Beantworten

Februar 2014

Bearbeiten
gudn tach user:PerfektesChaos!
zu /admin: ja, trennung von technik und orga ist sicherlich ein sinnvolles und loebliches unterfangen (auch wenn das meiner meinung nach auch auf einer seite getrennt behandelt werden koennte)
zur archivierung: ja, das ist hier eigen. dadurch ist das archiv hier ganz gut benutzbar. themen werden dort nach domain gruppiert und nur die gruppen werden chronologisch angeordnet. wenn man alle diskussionen zu einer domain sucht (was der regelfall ist), kann man die sehr leicht finden, weil sie gruppiert wurden. archiv-bots dagegen koennen nicht anders, als stumpf chronologisch alles in die archiv-tonne zu kloppen, in der man sich die jeweiligen zusammenhaenge selbst raussuchen muss. das waer fuer mich als admin, der das archiv haeufig konsultiert voellig unpraktikabel.
zu /vorgaenge und watchlist: die sbl-watchlist ist ein zwischending zwischen SBL und nicht-sperre. die seiten, die dort gelistet sind, stehen unter besonderer beobachtung, weil sie schon mal (negativ) aufgefallen sind. da sie eine normale und harmlose seite ist, kann und soll sie auch von nicht-admins genutzt werden (nicht zuletzt, um admins zu entlasten). die watchlist wurde aber kaum genutzt und kann evtl. einfach abgeschafft werden.
zu /vorgaenge und irc-channels: die irc-channels sind fuer leute (die derzeit praktisch nicht existieren), die sich gezielt auf spam-jagd - insb. mit COI hintergrund - machen wollen. ausserdem bieten die bots eine nuetzliche datenbank-abfrage-mechanismen a la "wann, wo und von wem wurde eine vorgegebene domain in der wikipedia verlinkt?".
zu /log: hab gerade gesehen, dass das ja schon gar nicht mehr konsistent mit meta und en ist. verschieben waer also ok, ich muesste das allerdings dann auch in ein paar scripts aendern.
dann koennen wir ja mal zur frage des praefixes kommen. ich faend ja so was wie WP:Weblinks/blacklist oder WP:Blacklist oder WP:Link-Blacklist sinnvoll. dass "blacklist" im namen weiterhin vorkommen, faend ich deswegen gut, weil es sich genau darum handelt, eine blacklist. gleichzeitig waere gut, wenn wir auf das wort "spam" verzichten koennten, weil es haeufig unpassend ist. -- seth 23:52, 20. Feb. 2014 (CET)Beantworten
  • Zur Trennung in einzelne Seiten:
    • Ausschlaggebend ist für mich die Zielgruppe; und die Verständlichkeit für Normalbenutzer.
    • Was man nicht wissen muss, soll einen nicht verwirren. Was nur mit Admin-Rechten möglich ist, sollte keine einführende Beschreibung stören; das haben wir noch auf etlichen und überladenen Seiten. Ich habe gerade vor ein paar Tagen H:VG und H:VV auseinandergezogen, die traditionell ineinander verheddert waren. Was nur für Vollprofis wichtig ist, wird aus dem allgemeinen Einführungskurs herausgezogen; es gibt Hilfe:Echo für Normalos und Wikipedia:Technik/MediaWiki/Echo für Insider.
  • Zur Namensraumfrage:
    • Ich möchte grundsätzlich alles dieses Zeugs nach und nach aus dem Mediawiki-Namensraum und dessen Diskussion herausnehmen; mit Ausnahme der Programmierung/Liste selbst.
    • Anfragen gehören auf eine Anfragenseite und diese grundsätzlich in den Projekt-NR = WPNR. Und dies für alle Angelegenheiten aller Themenbereiche; so dass man auch den WPNR nach einer Angelegenheit durchsuchen kann; und nicht im NR MediaWiki Diskussion, wo kein Normalbenutzer draufkommt.
    • Ob ein Bot verschiebt oder du das manuell machst, ist mir herzlich gleich.
  • Zur Seitenbenennung:
    • Ich möchte im völlig abgesoffenen WPNR nicht alles zwischen Tausenden von Seiten verschwinden lassen, sondern so nach und nach in den kommenden Jahren und Jahrzehnten Strukturen aufbauen.
    • Ziel ist, dass man sich als Benutzer nur eine Startseite merken muss; etwa WP:Weblinks. Von der aus bekomme ich eine Navigationshilfe: WP:Weblinks/Blockiert (oder Blacklist), WP:Weblinks/Defekt.
    • Trotz Querschuss durch matthiasb wurde ja kürzlich auch der MBF in BF umbenannt; auch eines deiner Kinder. Wobei ich anraten würde, der H:FILT ein move=sysop zu verpassen; noch so eine Odyssee muss nicht sein.
    • Insofern kann ich mir gut vorstellen, von dem traditionellen Insider-Namen „Blacklist“ zu einem intuitiv eher erfassbaren Begriff zu kommen. Und da finde ich irgendwas mit „Blockieren“ nachvollziehbarer, zumal es zu diesem Mechanismus auch eine whitelist gibt, die auf derselben Seite erklärt wird wie die blacklist, also was denn jetzt?
  • Allgemein sind im Meta-Bereich aufgrund der puren Vielzahl Umstrukturierungen erforderlich; immer weiter machen wie es immer schon so gewesen ist produziert den totalen Dschungel.
    • Wir hatten 2008 50–60 Hilfeseiten; heute geht es stramm auf die 300 zu, die ich schon auf dem Schirm habe.
    • Wir hatten 2005 mal gut 100 Projektseiten; inzwischen über 1300 ohne die Unterseiten.
    • Die Shortcuts sind die völlige Pleite. 2005 hatte man mal angefangen, jede erdenkliche Seite mit zwei, drei, vier, fünf Abkürzungen zu versehen. Damit hat man alle Buchstabenkombinationen aufgebraucht, die man heute dringend brauchen würde; es sind 1500 WP-Abkürzungen registriert und dazu kommen noch Kfz-Kennzeichen von Stammtischen. Niemand kann sich außer zwei, drei Abkürzungen wirklich wichtiger Seiten merken, was das alles bedeutet, und versteht noch einen Text, in dem jemand mit diesen Abkürzungen um sich schmeißt. Regelmäßig wird falsch verlinkt, weil das dann halt doch irgendwie anders heißt.
  • Wenn du also eine oder gar mehrere Seiten als nicht mehr erforderlich in das WP:Archiv verschiebst, soll es mir recht sein.

Soviel als allgemeiner Kommentar; gude nacht --PerfektesChaos 00:43, 21. Feb. 2014 (CET)Beantworten

gudn tach!
trennung in einzelne seiten: hab ich kein problem mit (solange man es noch schafft, dann den ueberblick ueber die vielen seiten zu behalten/bekommen)
namespace: da hatte ich mich, glaube ich, noch gar nicht zu geaeussert. hab jedoch auch hier keine einwaende gegen eine verschiebung. diese talk page hier sollte dann halt nur einen fetten bilingualen hinweis enthalten, wo (ent-)sperr-requests zu erfolgen haben.
seitenbenennung:
  1. mehr hierarchie im seiten-namen: ist von meiner seite ok (auch wenn das gegen die eigentlich ja eher flache wiki-struktur spricht; gerade bei handbuechern hilft hierarchie meist mehr, als sie schadet).
  2. blacklist vs. blockieren vs. noch zu finden: zugegeben, ich hab was gegen woerter, die sich zwangseingedeutscht anhoeren und die im deutschen ohnehin schon viele bedeutungen haben, deswegen gefaellt mir "blockieren" in diesem kontext nicht so. "blacklist" als ueberbegriff fuer black- und whitelist ist allerdings, da hast du recht, auch nicht unbedingt soo geil, auch wenn ich mich daran mittlerweile gewoehnt habe. ich ueberlege dazu noch mal, vielleicht faellt mir was besseres ein.
umstrukturierung grundsaetzlich erforderlich: wenn sich dadurch eine konsensuelle verbesserung ergibt, gerne. :-) -- seth 11:53, 21. Feb. 2014 (CET)Beantworten


  • WL-Hinweise
    • Natürlich gibt es WL und/oder Boxen, wo immer nötig.
  • Hierarchie:
    • Die flache (Null-)Hierarchie passt sehr gut in den enzyklopädischen Bereich.
      • Die anderthalb Millionen Artikel lassen sich nicht in einen zentralen Hierarchiebaum einsortieren; vielmehr gibt es sehr oft Mehrfachkategorisierung.
      • „Brandenburger Tor“ ist Bauwerk, Symbol der deutschen Geschichte, Kunstwerk/Architekturstil, geografisches Objekt.
    • Im enzyklopädischen Bereich sucht der Leser nach Informationen über einen Gegenstand der realen Welt, von dem man etwas gehört hatte.
    • Im Meta-Bereich (WPNR+HNR) sind die Objekte virtuell.
      • Die Objekte entstehen erst dadurch, dass wir eine Seite darüber anlegen.
      • Niemand kann ahnen, dass es bestimmte Seiten und Themen überhaupt im Projekt gibt oder dass man danach suchen könnte.
      • Deshalb braucht es noch viel viel viel mehr Navigation und systematische Erschließung des Meta-Bereichs; soweit im Rahmen der Übersichtlichkeit möglich etwa bereits von WP:Autorenportal, Hilfe:Übersicht oder WP:Technik geleistet.
    • Mein Wunschtraum ist es, 2020 mal einige dutzend Seiten auf der Hauptebene des WPNR zu haben, die entweder wirklich wichtige und häufige Einzelfragen betreffen (WP:WWNI, WP:RK, WP:LK, WP:K) oder aber Portale zu einem ganzen komplexen Themengebiet sind wie etwa WP:Anfragen, mit Unterseiten als WP:Technik oder WP:Lua.
      • Und diese paar dutzend Seitennamen könnte man sich so ungefähr merken; und es ließe sich damit auch eine vernünftige WP:Sitemap aufstellen. In den Suchergebnissen verrät einem der Pfad, worum es in etwa gehen wird, statt kryptische Namen und Abkürzungen zu liefern.
      • Bei 1300 Einzelseiten auf dem top level ist das illusorisch.
      • Deshalb mein Plädoyer für Wikipedia:Weblinks als Einstieg zu einer ganzen Wunderwelt, die mit externen Links zu tun hat.
    • Die Mehrfachkategorie ist auch im Meta-Bereich nicht völlig auszuschließen; aber deutlich seltener.
  • Benutzerfreundlichkeit
    • Ich meine mich erinnern zu können, dass Undurchschaubarkeit der Wikipedia, unübersehbare Regeln und mysteriöse Funktionalitäten und Prozesse eine häufig vorgebrachte Klage von Newcomern und Außenstehenden wäre.
    • Der momentane Zustand des WPNR ist vielleicht nicht Hauptursache, sicher aber Symptom.
    • Bezeichnend ist, dass kürzlich sogar die Beschreibungsseite gelöscht wurde, die darlegen soll, was und wozu und wie der WPNR ist.
    • Ein Pfad hin zur Benutzerfreundlichkeit und Verständlichkeit ist die Trennung von einführenden Infos für Normal-Autoren (bzw. Nur-Leser) und dem Detailwissen für Programmierer, Systemkonfigurierer, Administratoren und Fortgeschrittene. Andernfalls werden die Seiten völlig überladen mit Details, der Überblick geht verloren, und für Einsteiger Relevantes ersäuft in erstmal unwichtigen Spezialfragen.
      • Beschränkung auf das Wesentliche auf den Startseiten (Didaktische Reduktion); für das gemeine Volk.
      • Technischer Kleinkram in größerer Menge auf gesonderte Seite auslagern; für die Spezialisten.
Schönes Wochenende --PerfektesChaos 23:16, 21. Feb. 2014 (CET)Beantworten

name der unterseite

Bearbeiten

gudn tach!
dem, was du 2014-02-21 schriebst, kann ich eigentlich auch wieder nur zustimmen. teilweise meinte ich das ja auch schon, habe es nur nicht so sehr expliziert, weil ich davon ausging, dass du das eh aehnlich siehst oder sogar besser weisst. letzte woche hab ich ein kleines brainstorming zu moeglichen bezeichnungen veranstaltet fuer die moeglichen $X in Wikipedia:Weblinks/$X. herausgekommen ist die - nicht durchgaengig ernstgemeinte - liste:

blacklist, kontrolle, verwaltung, beschraenkung, aufsicht, regulierung, schutz, sonderbehandlung, ueberwachung, blockade, sieb, filter, zensur, abwehr, schirm, schild, raster, konflikte

aus PC- bzw. historischen gruenden werden sonderbehandlung und abwehr wohl nicht sinnvoll sein. ueberwachung ist ebenfalls zu negativ konnotiert. meine favoriten sind, nach einigem ueberlegen, blacklist und filter. denn die whitelist (um deinen obigen einwand aufzugreifen) ist letztlich ja nur eine einschraenkung der globalen blacklist, also nicht ein pendant zur blacklist, sondern lediglich ein teil davon. deshalb halte ich blacklist als ueberbegriff fuer sinnvoll.
an der bezeichnung filter koennte man zwar bemaengeln, dass es ja bereits die edit filters gibt und somit eine verwechslungsmoeglichkeit besteht, aaaaber diese verwechslung passiert eh schon manchmal, denn einem durch die technik behinderten user ist es eher egal, welcher filter-mechanismus ihn vom arbeiten abhaelt, und jemandem, der eine verlinkung verhindern lassen will, sollte die entscheidung, ob nun via blacklist oder edit filter, besser von einem admin abgenommen werden. bei den jetzigen SBL-diskussionen wird auch hin- und wieder mal ueberlegt, ob die SBL oder das edit filter sinnvoller ist. eine gemeinsame diskussion ueber das filtern von links ist also ohnehin sinnvoll und geht in die richtung der von dir propagierten wunderwelt, oder?
(dass beide begriffe im deutschen und im englischen hierfuer benutzt werden koennen, ist ein kleiner zusaetzlicher plus-punkt, da es bei SBL-angelegenheiten manchmal schnittpunkte zu diskussionen auf meta gibt und meta-admins es so vermutlich leichter haben, die richtige anlaufstelle zu finden.)

der aktuelle stand ist offenbar: deinen vorschlag, alles unter WP:EL/... bzw. Wikipedia:Weblinks/... halte ich fuer sinnvoll. ueber den namen der unterseiten reden wir noch. die grobe struktur haben wir auch schon besprochen. ich bin ungefaehr ab dem kommenden wochenende bis anfang april wahrscheinlich nahezu komplett offline, wuerde aber gerne, bevor eine konkrete verschiebung stattfindet, noch ein wenig mitreden, zumal ich ein paar scripts anpassen muss, die unter anderem lesend aufs archiv und das manuelle log zugreifen.
wie gehen wir weiter vor? wenn wir einen namen fuer die EL-unterseite haetten, koenntest du (wenn du zeit+lust hast) schon mal anfangen, die kuenftigen seiten anzulegen, vorerst noch mit einem fetten baustellen-hinweis versehen. somit waere die suche nach dem unterseitennamen das vorrangige ziel. was denkst du? -- seth 21:38, 5. Mär. 2014 (CET)Beantworten

„Filter“ ist völlig okay.
  • Verwechlungsgefahr besteht dann ja nicht, weil bei allen relevanten Seitennamen „Weblinks/Filter“ dransteht. Damit kann es nicht der Bearbeitungsfilter sein.
  • Damit ergeben sich auch Seitennamen, die von englischsprachigen Kollegen sofort nachvollzogen werden können.
  • „Filter“ ist auch neutral und unbelastet gegenüber Assoziationen wie „Zensur“ und dem bisherigen „Spam“ mit bias.
  • Eine gewisse Ähnlichkeit zum Bearbeitungsfilter besteht ja in den praktischen Auswirkungen für die Autoren.
Die Zeitschiene ist völlig okay; Richtung Sommer in Ruhe langt, keine Hektik.
Die Seitenverschiebungen würde ich gern komplett dir überlassen, weil du genauer weißt, wo welcher Absatz mit beisteht. Das Grundprinzip der Zielgruppenorientierung hatte ich deutlich gemacht, insbesondere dass Normalbenutzer nicht mit Informationen geflutet werden sollten, mit denen sie selbst erstmal nichts anfangen können. Wenn du selbst die Verschiebung in der Hand hast, kannst du auch synchron die Scripts anpassen; für die anderen Benutzer ändert sich sowieso durch die entstehenden Weiterleitungen nichts – notfalls laufen sie auf Infokästen mit auffallendem Hinweis, also in diesem Namensraum.
Schönen Abend --PerfektesChaos 22:14, 5. Mär. 2014 (CET)Beantworten
doh, ich hoffte, noch etwas arbeit abgeben zu koennen. ;-) aber vermutlich hast du recht, dann hab ich am schluss auch weniger moeglichkeit zu meckern.
noch ein paar offene punkte:
  • nehmen wir einfach "filter", oder sollte man das noch sonstwo zur diskussion stellen?
  • magst du vielleicht noch mal bei gelegenheit ein update bzw. eine mini-zusammenfassung der struktur hier posten? also einfach die seitennamen und stichwortartig, einzeilig deren inhalt?
-- seth 23:01, 5. Mär. 2014 (CET)Beantworten

Restrukturierung 2023

Bearbeiten

Gudn Tach!
Im Kontext des neuen Features, also der Domain-Blacklist (oder Domain-Blocklist, egal, Hautsache DBL), hab ich überlegt, ob es sinnvoll sein könnte, zumindest schon mal einen Teil zu restrukturieren. user:PerfektesChaos hat dazu auch bereits etwas geschrieben. Wir sollten die Diskussion aber besser hier fortsetzen.
Ideen:

  • Diskussionen um zu blockierende Websites werden künftig unter WD:Weblinks/block/example.org abgelegt.
  • Alte, archivierte Diskussionen werden entsprechend vom aktuellen Archiv in diese neue Form überführt. (Macht Arbeit, könnte ich aber erledigen; evtl. Bot-gestützt.)
  • Vorteil: Links zu Diskussionen sind persistenter. Keine unnötige bis verwirrende Jahreszahl-Abhängigkeit mehr. Die aktuelle manuelle Archivierung wird deutlich einfacher und kann evtl. sogar automatisiert werden.
  • Reverse-Domain-Variante von Perfektes Chaos: WP:Weblinks/block/org/example.

Ich denke, die Reverse-Domain-Variante (ich kenne die Vorteile) ist in diesem Fall hier weniger geeignet, denn:

  • Das ist unintuitiv für Leute, die nicht PerfektesChaos oder seth heißen.
  • Wir haben häufig Fälle, die sich nicht auf genau eine Domain beschränken, sondern eine Gruppe, z.B. #Ukrainischer_SEO-Spam. Da würde ich nicht unbedingt für jede Domain eine eigene Seite anlegen wollen.
  • Für n-Level-Domains (mit n>2) braucht's normalerweise keine separate Diskussionsseite (Beispiel: #(de.)knowledgr.com). Das würde ich stets bei der SLD bündeln.

Andere offene Punkte:

  • Welcher Namespace wäre sinnvoll: WP oder WD? Da es sich um Diskussionen handelt, fänd ich WD sinnvoller. WP würde ich vorerst unbenutzt lassen, jene Seiten könnten aber künftig irgendwann mal für automatisch generierte Infos genutzt werden.
  • Ab welchem Zeitpunkt sollten Diskussionen auf diesen Unterseiten platziert werden? Ich würde sagen, ab dem frühestmöglichen Zeitpunkt. Aber: Wenn man schon den Request auf einer Unterseite erstellen lässt, bekommt das niemand so leicht mit (Oder funzt die Subscribe-Funktion auch für Unterseiten? Ich glaube nicht.) Also braucht's vielleicht doch weiterhin eine Request-Seite wie diese hier. Aber wann verschiebt man dann die Diskussion? Gleich nach dem Request oder erst nach Erledigung? Und: per Bot, so wie auf WP:VM?
  • Grundsätzlich möchte ich versuchen, die Umstrukturierung nicht zu groß werden zu lassen, weil sie sonst wieder wie vor neun Jahren eben an der Größe scheitern könnte, wenn sich niemand findet, der das alles umsetzt.

-- seth (Diskussion) 14:52, 11. Nov. 2023 (CET)Beantworten

Zum letzten Punkt: Schau mal zwei Abschnitte weiter unten bei #Trennen. Ich bin mir fast sicher, dass Benutzer:Antonsusi noch Kapazitäten hat. -- Grüße, 32X 17:34, 11. Nov. 2023 (CET)Beantworten

Auf WP:MW/Ä wurde ich um Stellungnahme gebeten:

  • WP: oder WD: für die Erörterungen?
    • Es ist keinerlei sonstiger Verwendungszweck für WP:-Unterseiten in Sicht. Die wirksamen Umsetzungen stehen im MediaWiki-Namensraum.
    • Damit würden alle aktiv konsultierbaren WD: immer auf ein Rotlink verweisen. Abgesehen von Archiven erörtern wir auf WD: die Angelegenheiten der Vorderseite, also von WP:, die es aber nie gibt.
    • Hingegen ist es durchaus üblich, auf einer Vorderseite Einführungstext und Diskussion darüber zu verhandeln. Beispiele: WP:AP, WP:FZW, WP:LKH, WP:A/A, SGA, Wahlen, Werkstätten.
    • In solchem Kontext verwenden wir die Diskussionsseite überhaupt nicht oder allenfalls zur Meta-Organisation.
  • Forderung: Kenne ich eine beanstandete URL, muss ich unmittelbar zur Projektseite mit der Erörterung navigieren können.
    • Problem: Hat die Beanstandung den Host bad.cheating.example.co.jp, dann weiß ich nicht, ob ich im Alphabet nach „b“ wie bad oder „c“ wie cheating oder „e“ wie example nachsehen soll.
    • Triviale Benennung der Projektseite nach der zur Blockade herangezogenen Domain ist denjenigen unbekannt, die eine blockierte URL vorgefunden hatten und nach der wirksamen Begründung suchen.
  • Reverse URL
    • Das mag beim Erstbesuch für die meisten etwas irritieren, ist aber bei guter Erläuterung und Navigation erlernbar und fällt beim dritten Besuch schon nicht mehr auf.
    • Ist dafür zukunftsfähig und skalierbar.
    • Das Beispiel würde ggf. erörtert auf WP:Weblinks/Block/jp/co/example und kann dadurch immer von Software wie von Menschen eindeutig identifiziert werden.
    • Es entstehen mindestens bei den TLD, gelegentlich auch bei Subdomains verwaltungstechnischer Art wie etwa .co.jp Navigationsseiten im Sinne einer BKS, weil wir noch nicht am Blatt angekommen sind, sondern noch im Geäst navigieren.
    • Diese können mit einer automatisch generierten Liste von bis zu 200 Einträgen zur Auswahl versehen werden; hier mal auf einige wenige sichtbare eines anderen Astes gekürzt:
  • Erörterung auf einzelner Projektseite
    • Das ist schwer zu begrüßen, verglichen mit dem Kuddelmuddel und der riesigen und für Smartphones erst recht unübersichtlichen bisherigen Organisation in Abschnitten.
  • Jede Projektseite sollte eine Unterseite einbinden, etwa: WP:Weblinks/Block/!Intro
    • Diese erhält „Vorlagenparameter“, die einen Einführungsabschnitt generieren, und dazu weitere standardisierte Elemente:
    • Wer hatte diese Blockade eingerichtet? [optional]
    • Wie lautete die ursprüngliche Forderung (Diff; Versionsnummer)? [optional]
    • Wann wurde diese Blockade eingerichtet? [optional; ISO-Tag]
    • Wann wurde diese Blockade ggf. beendet? [optional; ISO-Tag]
    • Es ist eine Navigationsseite für tiefer liegende Domains und keine einzelne Angelegenheit. [optional; boolean; 0]
      • Generiert die o.a. Liste der Unterseiten.
    • Beliebiger Freitext vor Diskussions-Abschnitt. [optional]
    • Abschnitt == Diskussion == (wird generiert wenn nicht Navigationsseite).
    • WP:Weblinks/Block/!Linkbox mit Gesamt-Navigation innerhalb WP:Weblinks/Block.
  • Mehrere Subdomains zu einer Erörterung
    • Dieselben Schurken können ihren Müll auf den Kokosinseln, unter .com und .fr und sonstwo anbieten, auch mit wechselnden Haupt-Domains.
    • Es gibt nur eine einzige Erörterung zentral für alle.
    • Alle Aliasse, für die softwaretechnisch je eine unabhängige Blockade eingerichtet werden muss, verweisen über eine Weiterleitungsseite auf die zentrale Diskussion.
  • Verschiedene Subdomains einer Domain
    • Beispiel: Es mögen blockiert sein
      • gequatsche.blogspot.com
      • bullshit.blogspot.com
    • Dann ist blogspot.com grundsätzlich legitim. Über den enzyklopädischen Wert und die Eignung als Beleg mag im Einzelfall gestritten werden; es gibt hier aber autorisierte relevante Beiträge einer Lemmaperson oder aber renommierter Fachleute, welche dieses Medium für eine Online-Publikation und als Webspace gewählt hatten.
    • Unter WP:Weblinks/Block/com/blogspot findet sich dann eine Navigationsseite (siehe oben).
    • Die Erörterungen zu den voneinander unabhängigen „Kanälen“ erfolgen auf eigenständigen Projektseiten.
  • Reform der Seitenstruktur
    • Ich erwarte eine zukunftsfähige erweiterbare übersichtliche Seitenstruktur.
    • Das Gefrickel und Gebastel aus unserer Kindergartenzeit, als es ein Dutzend Domains gab, und 100–200 Metaseiten, und 250 Vorlagen, ist unserem Drei-Millionen-Artikel-Monster nicht mehr angemessen.
    • Innerhalb der Gesamtlösung müssen die Erörterungen zu einzelnen Domains und die allgemeinen Einführungen und Erklärungen und Prozeduren einen sinnvollen Platz erhalten und strukturell auch an WP:Weblinks angebunden sein und eine Gesamt-Navigation ermöglichen.
    • Eine Restrukturierung hat alle vorhersehbaren zukünftigen, erst recht alle heutigen Anforderungen vollständig zu erfüllen, damit das Volk nicht alle Nase lang eine neue Struktur erlernen und bookmarken muss.
  • Meine persönliche Beteiligung
    • Ich bin ziemlich angefressen, dass meine Bemühungen von 2014 komplett ignoriert wurden.
    • Für behelfsmäßiges Gebastel und Gepfusche stehe ich nicht zur Verfügung.
    • Ich habe Hunderte offener Aufgaben in der Warteschlange.
    • Diese Angelegenheit werde ich erst dann weiter programmtechnisch verfolgen, nachdem eine den zeitgenössischen Anforderungen entsprechende Grundstruktur realisiert wurde. Auch dann wären meine zeitlichen Ressourcen sehr begrenzt. Die bisherigen und jüngsten Anläufe, mit untauglichen Bastel-Lösungen irgendwie eine robuste und zukunftsfähige Umsetzung hinzubekommen, haben bereits ziemlich viel meiner Ressourcen konsumiert. Allein schon die Idee, es sollen pauschal sämtliche Bot-Betreiber bzw. deren Bots volle Admin-Rechte erhalten, nur damit in einer JSON-Seite nachträglich von einem externen privaten Bot ein Zeitstempel nachkorrigiert werden könne, lag außerhalb meiner Vorstellungswelt.

VG --PerfektesChaos 11:00, 27. Nov. 2023 (CET)Beantworten

Nachtrag: „Ab welchem Zeitpunkt sollten Diskussionen auf diesen Unterseiten platziert werden?“
  • Sofort nach Wunsch; ggf. auf einer Art Antragsseite.
  • Muss irgendwo getracked werden, welche Anfragen neu und noch nicht administrativ hü oder hott entschieden wurden.
  • WP:CUA bekommt das auch irgendwie hin.
  • Zu jeder Domain, zu der bereits einmal Bedenken geäußert wurden, ist eine eigenständige Unterseite anzulegen, und der „Antrag“ oder die Anregung ist dorthin zu kopieren.
  • Die Unterseiten zu Domains sind völlig unabhängig davon, ob eine Blockade eingerichtet wurde oder nicht, und ob die jetzt im Moment noch bestünde oder nicht.
  • Archiviert wird nicht. Die Unterseiten zu Domains verbleiben ewig.
  • Die Intro-Einbindung enthält Felder, zu welchem Datum (nominell, Altfälle per 1. Januar 1970 oder was) eine Blockade eingerichtet wurde; dann ist sie jetzt aktiv – und wann diese Blockade wieder aufgehoben wurde, dann halt nicht mehr.
  • Damit gibt es zu jeder zweifelhaften Domain eine ununterbrochene Geschichte, wie in welchen Jahren die Lage beurteilt wurde und ob die Domain sich später vielleicht gebessert oder verschlechtert habe und ob daraus Blockaden folgten.
VG --PerfektesChaos 11:15, 27. Nov. 2023 (CET)Beantworten
PPS: Frische, noch nicht endgültig entschiedene Anregungen zur Blockade können in der Intro-Einbindung einen Schalter erhalten; administrativ auf Blockade entschieden oder auch abgelehnt; die noch nicht entschiedenen können in einer Art Wartungskat aufschlagen und wer eine Überprüfung der Entscheidung begehrt darf das Häkchen bei diesem Schalter wieder rausnehmen und es wird wieder unter „Diskussionsbedarf“ kategorisiert. VG --PerfektesChaos 11:20, 27. Nov. 2023 (CET)Beantworten

Aus Sicht des gemeinen Pöbels gibt es zwei Fragestellungen:

  1. Meine Bearbeitung wurde gerade geblockt; warum?
  2. Ich bin im ANR auf URL x.y.z gestoßen und finde sie problematisch. Wurde darüber bereits diskutiert? Wo?

Die erste Frage ließe sich über searchsbl beantworten; mit einem Wiki-externen Tool.

  • Wenn nicht lokal, dann mag das ja auch eine globale Regel geben.

Weil es aber zur zweiten Frage keine aktive Blockade gibt, muss die Organisation unserer lokalen Diskussionen dazu sich aus der URL herleiten lassen.

  • Vielleicht wurde bereits über eine zweifelhafte Domain diskutiert und vorläufig auf Zulassung entschieden. In den folgenden Jahren können die Inhalte aber noch grottiger geworden sein.
  • Hier muss die Seitenstruktur eine Navigation ermöglichen.
  • Die bislang oft verwendeten textlichen Überschriften sind dafür absolut ungeeignet.
  • Eine Suchmaske wäre ohnehin ratsam, ist aber keine zulässige Problemdelegation. Meine Suchanfrage kann überbestimmt sein und deshalb kein Resultat liefern.

VG --PerfektesChaos 10:11, 1. Dez. 2023 (CET)Beantworten

Gudn Tach!
Oha, danke für die ausführliche Antwort.
  • Namespace WP oder WD: Soll mir recht sein, dann also WP.
  • Forderung bzgl. (Sub)+-Domains:
    • Klar, es ist theoretisch nicht so einfach, siehe auch https://www.publicsuffix.org/, aber in der Praxis würde es, denke ich, nicht zu vielen und wenn, dann lösbaren Problemen führen.
    • Bei bad.cheating.example.co.jp (oder auch hudelsprudel.blogspot.com) würde ich zwei Seiten WP:Weblinks/Block/example.co.jp und WP:Weblinks/Block/bad.cheating.example.co.jp erstellen (und notfalls dann auch noch die dritte dazwischen je nachdem). Welche von beiden Seiten auf die andere weiterleitet bzw. als Liste dient, hinge davon ab, ob die Diskussionen sich überlappen. Faustregel: Pro Website eine Seite. blogspot.com ist eine Website und hudelsprudel.blogspot.com ist eine andere Website. Aber de.wikipedia.org und en.wikipedia.org wäre eher eine Website, die unter WP:Weblinks/Block/wikipedia.org behandelt würde (und die Subdomains könnten dorthin weiterleiten).
    • Es gibt manche komplizierten Fälle, z.B.
      • "translate.google.[^\/]{2,5}/translate": Da fänd ich mehrere Möglichkeiten denkbar, z.B. WP:Weblinks/Block/translate.google.* oder WP:Weblinks/Block/translate.google.com oder ganz ohne URL-Schema WP:Weblinks/Block/Google_Translate.
    • Wichtig wäre, dass man die richtigen Seiten über die normale Suche (eingeschränkt auf "prefix=WP:Weblinks/Block") findet. Wird man wohl nicht in allen Fällen hinbekommen (z.B. translate.google.wtf), aber in den meisten.
  • Reverse URL:
    • Mir geht's weniger um die Regulars, die gewöhnen sich an fast alles (sogar an monobook), sondern mir geht's eher um Leute, die eben nicht so häufig hier sind. Diese Leute sind in der Mehrzahl, denke ich. Und für die taugt das Reverse-Zeugs nix.
    • IOW: Ich glaube, das werden wir der Community einfach nicht verkaufen können.
  • !Intro: wahrscheinlich sinnvoll, ja. Allerdings würden die optionalen Felder bei den Altfällen wohl leer bleiben, weil das niemand freiwillig für mehrere Hundert Fälle rückwirkend ausfüllen wird. 1970-01-01 passt von mir aus.
  • !Linkbox: ok.
  • 2014: Tut mir leid, dass du angefressen bist. Ich hab's nicht ignorieren wollen. Ich hab's ja auch absichtlich nicht archiviert. Außerdem war ich doch der letzte, der noch Fragen stellte, auf die du dann nicht mehr reagiertest. ;-p
  • Aufwand: Du kannst mir glauben, dass ich den auch gering halten möchte. Bisher kam ich mir ein bissl wie Asterix auf der Jagd nach dem Schein A38 vor. Eigentlich wollte ich doch nur ein einheitliches Format für das neue Tool etablieren und bin deswegen von einer Anlaufstelle zur nächsten empfohlenen gehopst.
  • Zum Nachtrag: passt. Dein letzter Punkte war ja auch damals meine Motivation für die aktuelle (zugegeben unbequeme) Archivierung, bei der die Diskussionen thematisch zusammengehalten und nicht nur von einem Bot rein chronologisch sortiert werden. Daher sollte ein Transfer zur neuen, gar nicht so unähnlichen Struktur auch halbwegs einfach sein.
  • Zum Schalter: Ließe sich sowas auch später noch nachrüsten? Ich würde gerne mit einem MVP starten.
Wenn es ok für dich wäre, wenn wir auf die reverse URLs verzichten, würde ich mal die anstehenden Todos skizzieren und dich um Kontrolle bitten, bevor es dann ans Eingemachte geht. -- seth (Diskussion) 20:50, 2. Dez. 2023 (CET)Beantworten
Verzicht auf reserve ist nicht okay.
  • Grund sind die beiden von mir dargestellten Anwendungsfälle: „gemeinen Pöbels gibt es zwei Fragestellungen“
  • Du hat einen Denkfehler drin, und du hast ihn immer noch nicht begriffen.
    • „Bei bad.cheating.example.co.jp (oder auch hudelsprudel.blogspot.com) würde ich zwei Seiten WP:Weblinks/Block/example.co.jp und WP:Weblinks/Block/bad.cheating.example.co.jp erstellen“
    • cheating.example.co.jp sei auf alles blockieren eingestellt.
    • Jemandem wurde seine URL blockiert, oder findet eine Webseite unerwünscht.
    • Deren Host wäre: malicous.cheating.example.co.jp
    • Deine von dir benannte Weiterleitung WP:Weblinks/Block/bad.cheating.example.co.jp greift aber dafür nicht; die fängt mit „ba“ an.
    • Deine eigentliche inhaltliche Seite cheating.example.co.jp greift aber auch nicht, denn ich suche nach etwas mit „malicous“.
  • Dein Denkfehler ist: Du findest die Information ex post; nachdem du bereits weißt, an welcher Stelle es steht und wonach du suchen musst.
    • Außenstehende haben dieses Vorwissen nicht, und sie haben eine unbekannte Menge zukünftig entstehender Subdomains.
    • Alle Subdomains über die wirksame Blockade hinaus sind beim reverse irrelevant, genauso über eine potenziell böse Website hinaus.
    • Die Subdomains willst du in deiner Darstellung vollständig mit lauter Weiterleitungen umleiten, aber du weißt überhaupt nicht wie heute oder gar zukünftig alle Subdomains heißen.
Einzelne Pfade unterhalb des Host werden beim Host diskutiert, auf derselben Projektseite.
Minimum Viable Product
  • Das ist buzz-biz-bullshit-bingo, was geistige Armut beim Entwickeln eines Gesamtkonzepts vertuschen soll.
  • Minimum Viable Product setzt Entwicklungszyklen von wenigen Tagen und realtime-Feedback voraus.
  • Wir lesen hier ein Zeitintervall zwischen zwei Iterationsschritten von offenbar einem Jahrzehnt, zwischen der ersten Iteration von 2007, meiner erfolglos gebliebenen Beschwerde von 2014 und einer anstehenden Umsetzung vielleicht 2024.
  • Heißt: Was immer du als angeblichen ersten Prototyp mit Abwarten auf Feedback bis zur nächsten Iteration mir aufzuschwatzen versuchst, hätte dann wieder 17 Jahre Zeitbedarf bis zum nächsten Iterationsschritt. Falls ich den noch erleben sollte.
  • Heißt: Die jetzt getroffene Entscheidung muss so weise und weitsichtig sein, dass sie auf viele Jahre alles abfangen kann.
  • Ein bis anderthalb Jahrzehnte ist auch die Zeitdauer, die es braucht, bis die Schädel in unserer Community die Veränderung einer einmal gelernten Information reinlassen. Wir haben User, die jammern heute noch dem prettytable hinterher, das es für ein Dreivierteljahr 2008 mal gab und danach von einheitlich wikitable abgelöst wurde, oder den hack mit SortKey, der 2009–2011 einmal erforderlich war und seitdem obsolet und schädlich ist, oder die Forderung, dass auf ewig rechts oben zwischen die Werkzeuge und Aktivitäten die Geokoordinaten zu einem Artikel reingeschrieben werden sollen. Heißt: Die Iterationszyklen der agilen Software-Entwicklung, die bei einer abgesonderten Testgruppe alle Woche einen veränderten Prototypen ins Feld schicken, kannst du in einer Wikipedia nicht ernsthaft beabsichtigen wollen.
  • Nerven- und arbeitssparende Aktivitäten haben ein Gesamtkonzept, das eine Realisierung aller heute bereits absehbaren Entwicklungen zulässt und Plätze freihält, unabhängig davon welche jetzt oder später geschmeidig und ohne Brüche eingefügt werden.
TL;DR: ohne reverse ohne mich.
VG --PerfektesChaos 22:25, 2. Dez. 2023 (CET)Beantworten
Gudn Tach!
Ich hatte dich weiter oben so verstanden, als würdest du im o.g. Beispiel die Seite WP:Weblinks/Block/jp/co/example erstellen ggf. mit Präfixsuche für Unterseiten, also Subdomains.
Wenn jetzt jemand wissen will, ob eine Seite mit host malicous.cheating.example.co.jp schon besprochen wurde, müsste die Person:
  • als erstes das Ablage-Schema verstehen,
  • dann auf WP:Weblinks/Block/jp oder WP:Weblinks/Block/jp/co starten und sich mit den Präfix-Listen durchhangeln, so weit es eben geht. Grundsätzlich kann man die inkrementelle Wiki-Suche dafür benutzen, aber das wird vielen zu kompliziert sein.
Abgesehen davon, dass ich das für relativ aufwendig halte, sehe ich hier noch nicht, wie jemand im o.g. Fall von translate.google.wtf vorgehen sollte, wenn vielleicht WP:Weblinks/Block/wtf/google/translate noch nicht existiert, aber eben WP:Weblinks/Block/com/google/translate, wo die zentrale Diskussion stattfindet, was die suchende Person ja nicht wissen kann.
Bei der konventionellen URL-Schreibweise müsste die Person bei malicous.cheating.example.co.jp:
  • als erstes das Ablage-Schema verstehen, wobei dies etwas intuitiver wäre, weil die Host-Schreibweise gewohnt ist.
  • dann auf WP:Weblinks/Block/example.co.jp starten und sich evtl. durchhangeln.
Und bei translate.google.wtf hätte die Person ein ähnliches Problem wie oben. (Allerdings käme man hier mit der inkrementellen Wiki-Suche weiter, aber das muss man halt wieder wissen.)
Weitere Unterschiede von reverse vs. not reverse:
  • Die Präfix-Listen lassen sich mit Bordmitteln erstellen, aber funzen nur bei Reverse-Schreibweise. Bei der konventionellen Schreibweise müssten die Links (auf etwaige Subdomain-Seiten) manuell oder per Bot erstellt werden. Oder man behilft sich mit sowas wie:
    Special:Search/linksto:Wikipedia:Weblinks/Block/example.co.jp prefix:Wikipedia:Weblinks/Block/
  • Bei einfachen Domains, was die allermeisten Fälle sind, kann man bei der Reverse-Schreibweise nicht einfach den konventionellen Hostname hinter Wikipedia:Weblinks/Block/ schreiben.
  • Die Suche in Seitentiteln nach konventionell geschriebenen Hostnames wird bei Reverse-Schreibweise nicht fündig.
Welche wesentlichen Vor-/Nachteile übersehe ich?
Natürlich ist auch wieder denkbar, ein externes Tool zu schreiben (bzw. searchsbl zu erweitern), sodass man einfach den kompletten URL dort pasten kann und dann die passende(n) Diskussionsseite(n) verlinkt bekommt. Dafür wäre die URL-Schreibweise in den Seitentiteln wurscht.
Zum MVP: Nein, da missverstehst du mich offenbar. Mir geht es darum, dass die Diskussion nicht wieder im Sande verläuft, weil eine Eier-legende Wollmilchsau kreiert werden soll, sondern ich möchte mit vertretbarem Aufwand eine (ausbaufähige) Lösung haben, deren baldiges Erreichen realistisch erscheint.
-- seth (Diskussion) --seth (Diskussion) 02:47, 3. Dez. 2023 (CET)Beantworten
Gudn Tach!
Ich bin zu wenig überzeugt, dass die Vorteile der reverse-Schreibweise überwiegen, sondern denke aktuell, dass sie mehr Nachteile haben wird. Du siehst es andersherum. Dead-lock.
Um aber in der Sache trotzdem voranzukommen, würde ich trotzdem gerne damit beginnen, die alten Diskussionen zu verteilen und würde, da ich 1. wohl am meisten damit arbeiten werde und 2. den Großteil der der Umzugsarbeit tragen werde, dann einfach die von mir präferierte Variante wählen.
Konkret:
Ich würde also für jeden host eine Seite a la WP:Weblinks/Block/example.org anlegen und die Inhalte der Unterseiten von MediaWiki_Diskussion:Spam-blacklist/Archiv dorthin verschieben.
Analog zu den Regeln des Edit-Filters sollte ich dann auch einen Bot dafür einrichten, Hinweise auf neuste Diskussionen auf einer zentralen Seite zu bündeln, vgl. WP:Bearbeitungsfilter/latest topics.
Wichtige Einwände? -- seth (Diskussion) 13:53, 24. Dez. 2023 (CET)Beantworten
Gudn Tach!
Ich hab mir vorgenommen, irgendwann im Sommer 2024 dieses Thema anzugehen. Genaues Datum kann ich noch nicht nennen. -- seth (Diskussion) 10:22, 20. Mai 2024 (CEST)Beantworten

Restrukturierung 2024

Bearbeiten

Ich fange jetzt mal mit ein paar Seiten an. -- seth (Diskussion; bitte bewerte meine Admin-Arbeit) 18:22, 24. Aug. 2024 (CEST)Beantworten

Hab mich oben rausgehalten, weil ich weder mit der aktuellen Struktur, noch mit den Vorschlägen hier etwas anfangen kann und ich wenig motiviert war, für so eine so unwichtige Frage so lange Beiträge zu lesen. Nun möchte ich aber doch meine Meinung zu Protokoll geben: Ich erkenne ehrlich gesagt keinerlei Mehrwert darin alle Anträge hier auf eigene Seiten zu verschieben, anstatt einfach (wie bei LD, VM und quasi jeder anderen Funktionsseite) ein normales Archiv zu führen (vielleicht monatsweise?), wo alle Abschnitte per Bot hinwandern, sobald sie erledigt sind. Wenn eine Domain diskutiert wird, die früher schonmal besprochen wurde, kann man ja trotzdem leicht alte Diskussionen finden und verlinken. So funktioniert es auf meta:Talk:SBL ebenfalls ohne Probleme.
Aber letztendlich ist es mir egal – solange du Lust hast, dich ums archivieren zu kümmern und diese Seite aufgeräumt wird, kannst du auch gern ein aufwendiges System nutzen. Sollte sich eines Tages niemand mehr dafür finden (PerfektesChaos denkt ja oben schon an die nächste Iteration in 17 Jahren), kann man ja immer noch auf normale Archivierung umstellen. --Johannnes89 (Diskussion) 18:42, 24. Aug. 2024 (CEST)Beantworten
Gudn Tach!
Das Problem, das ich bei der konventionellen Datum-getriebenen Archivierung sehe, ist, dass vergangene Diskussionen zur gleichen Angelegenheit häufig ignoriert werden, weil es den Leuten zu aufwendig ist, sie herauszusuchen. Gerade bei der Blacklist ist es jedoch wichtig, die vergangen Diskussionen zum Thema zu kennen.
Beim Edit-Filter haben wir (anders als bei VM oder LD) eine Seite pro Regel, was die Diskussionen zur gleichen Sache zusammenhält und einem auch einen besseren Eindruck zu false positives gibt. Hättest du da denn lieber eine VM-ähnliche Vorgehensweise mit einem Archiv nach Datum?
Auf meta sehe ich dasselbe Problem. Nur erfahrene User finden da vergangene Diskussionen und es ist teilweise aufwendig.
"Lust": Die aktuelle Archivierung finde ich relativ aufwendig. Von der neuen Struktur verspreche ich mir, dass es besser flutscht. Die konventionelle Archivierung halte ich dagegen für eine denkbar schlechte Krücke.
-- seth (Diskussion; bitte bewerte meine Admin-Arbeit) 18:56, 24. Aug. 2024 (CEST)Beantworten
Aktuell (wo wir die manuelle Übersicht aller Diskussionen im Archiv pflegen) suchen die Leute doch auch keine alten Diskussionen heraus? z.B. #eslam.de, #axishistory.com 2024, #austria-forum.org – da scheinen die Abschnittseröffner die alten Diskussionen nicht gefunden zu haben, obwohl du so viel Mühe in die Archivierung gesteckt hast.
Bei Edit-Filtern haben wir wesentlich weniger Seiten (aktuell max. 428, von denen die meisten irrelevant sind, da die Filter deaktiviert/gelöscht wurden) und müssen viel seltener mal was archivieren. Dass Leute diese Seiten finden, liegt daran, dass sie ihnen mit der Filterwarnung verlinkt werden, was bei der SBL / Domainblocklist nicht der Fall ist?
Nach Datum archivieren wäre übertrieben, weil dafür zu wenig los ist, aber einfach per Bot normale Monats- oder Jahresarchive (wie auf Meta), ohne manuell noch so ne Übersichtsliste o.Ä., hielt ich mit Blick auf den in meinen Augen geringen Mehrwert komplexerer Lösungen für das sinnvollste.
Aber wie gesagt ich will gar nicht meckern, sondern wollte nur fürs Protokoll meine Meinung anmerken. Ich hab nichts gegen nen aufwendigeren Prozess, solange ich mich daran nicht beteiligen muss, sondern jemand anderes (in dem Fall du) die Arbeit erledigen möchte :) --Johannnes89 (Diskussion) 19:33, 24. Aug. 2024 (CEST)Beantworten
Gudn Tach!
  • Zum ersten Absatz: Richtig. Aber zumindest finden wir Admins auf diese Weise sehr schnell die alten Diskussionen und konnten auch leicht darauf verweisen. Bei der neuen angedachten Struktur wird es vermutlich wieder so ähnlich sein, aber es sollte (zumindest bei einfachen Domains wie example.org) für nicht ganz so erfahrene Leute künftig etwas einfacher sein. Dadurch werden solche Requests dann vermutlich etwas seltener.
  • Edit-Filter: Dadurch dass wir 428 Unterseiten haben, braucht's normalerweise keine Archivierung. Das Modell a la VM wäre aber, nur eine einzige zentrale Seite (also Wikipedia:Bearbeitungsfilter/Anträge) zu haben und alles auf einen unübersichtlichen Stack zu archivieren. Bei den Link-Blacklists werden wir künftig auch (fast) keine Archivierung mehr brauchen, weil es für jede (Haupt-)Domain eine eigene Seite gibt.
  • Beim Block direkt zu den Seiten verlinken: Stimmt, das Feature haben wir leider nicht und werden wir vermutlich auch nicht so leicht bekommen.
  • Datum-getrieben: Damit meine ich nicht (unbedingt) tagesweise, sondern nur, dass der Zeitstempel das Ziel determiniert und nicht das Thema, was viel sinnvoller wäre. Das ist ja gerade das Hauptproblem an der konventionellen Archivierung: Ich weiß doch nicht mehr, ob ich 2009 oder 2014 irgendwas gemacht hab.
  • Der Prozess sollte (nach der zugegeben aufwendigen Umstellung) weniger aufwendig sein, als das aktuelle Prozedere und zugelich mehr Übersicht bieten. Die konventionelle Archivierung ist nichts anderes als eine Notlösung, die sich im Laufe der Zeit verselbständigt hat, aber auf dem Spektrum der Möglichkeiten nur geringfügig besser als das Versenken in der History.
  • Ich bin dir für deinen Input dankbar, auch wenn ich dagegen argumentiere. :-)
-- seth (Diskussion; bitte bewerte meine Admin-Arbeit) 19:53, 24. Aug. 2024 (CEST)Beantworten
Glaub wir gehen da einfach ganz anders heran, ich würde einfach das Suchfeld in der Vorlage Vorlage:Archivübersicht nutzen (oder halt searchsbl), deshalb ist mir die Seitenstruktur so egal…
In meinen Augen sollte Archivierung auf allen Funktionsseiten so gestaltet sein, dass ein Bot diese lästige Arbeit machen kann (was bei Datumsarchivierung ja auch Standard ist). Wenn man es anders machen will, hab ich nichts dagegen, solange ich es nicht machen muss :) --Johannnes89 (Diskussion) 20:23, 24. Aug. 2024 (CEST)Beantworten
Gudn Tach!
Ich hab nochmal darüber nachgedacht, ob es nicht doch eine Möglichkeit gäbe, direkt in den Blockademeldungen auf die richtigen Diskussionen zu verlinken. Mit externen Tools könnte es in den meisten Fällen möglich sein. Idee:
  • In der SBL- oder DBL-Fehlermeldung wird ein externes Tool, verlinkt, z.B. spam-discussion-forwarder.toolforge.org/?block_type=sbl&blocked_string=blockierteZeichenkette.
  • Das Tool sucht die passende Domain heraus. Im Falle der DBL ist das ein Klacks, im Falle der SBL kann es kompliziert werden, aber meistens ist es möglich.
  • Das Tool kann auch prüfen, ob die Blockade von Meta kommt.
  • In simplen Fällen kann das Tool einfach weiteleiten auf die deutsche Diskussionsseite, wenn eine existiert.
  • In anderen Fällen kann das Tool einem Fallback-Vorschläge machen, wo man sich nun hinwenden soll.
Muss ich nochmal in Ruhe überlegen.
-- seth (Diskussion; bitte bewerte meine Admin-Arbeit) 22:31, 25. Aug. 2024 (CEST)Beantworten
Oder noch einfacher und ohne externes Script:
https://de.wikipedia.org/wiki/Spezial:Suche?fulltext=Search+full+text&prefix=Wikipedia%3AWeblinks%2FBlock%2F&search=$1&ns0=1&ns9=1&ns11=1
-- seth (Diskussion; bitte bewerte meine Admin-Arbeit) 14:55, 1. Sep. 2024 (CEST)Beantworten
Todos für mich für die nächsten Tage/Wochen:
-- seth (Diskussion; bitte bewerte meine Admin-Arbeit) 02:31, 25. Aug. 2024 (CEST) 08:27, 8. Sep. 2024 (CEST), 02:10, 11. Nov. 2024 (CET), 00:20, 12. Nov. 2024 (CET), 18:25, 16. Nov. 2024 (CET)Beantworten

Freigabe von URLs für Seiten außerhalb des Artikelnamensraums

Bearbeiten

Einige Websites sind in der Liste enthalten, weil sie als Quelle ungeeignet sind, zum Beispiel anwalt.de. Leider werden dadurch auch Verwendungen der Website, die keine Quelle sind, blockiert. Solche Verwendungen kann ich mir im Artikelnamensraum nicht vorstellen, aber zum Beispiel in der Auskunft und auf Diskussionsseiten kann die Verwendung dieser Websites hilfreich sein. Ich halte es deshalb für wünschenswert, Eintragungen auf den Artikelnamensraum beschränken zu können. --BlackEyedLion (Diskussion) 19:37, 21. Jan. 2019 (CET)Beantworten

+1. Z.B. auf WP:AU rasselt man in diese Spamfilter rein, obwohl das dort eigentlich überhaupt kein Problem ist (z.B. youtu.be). --Filzstift (Diskussion) 08:45, 23. Sep. 2020 (CEST)Beantworten
gudn tach!
sorry fuer die spaete antwort (@user:BlackEyedLion). ich habe die frage offenbar uebersehen.
bei der SBL gibt es eine solche unterscheidungsmoeglichkeit nicht. das waere grundsaetzlich eher ein feature request an die software-entwickler. es kann aber sein, dass die das ablehnen und auf das edit-filter verweisen, mit dem solche einschraenkungen auf namensraeume ja moeglich waeren. problem beim edit-filter ist jedoch, dass es fuer die masse an links wesentlich unuebersichtlicher als die SBL waere.
fuer diskussionsseiten empfehle ich deshalb im falle von geblacklisteten links, das protokoll "https://" wegzulassen.
@Filzstift: ich vermute, dass man youtu.be eigentlich nicht blacklisten muesste. ich hak dazu mal auf meta nach. -- seth 23:13, 10. Okt. 2020 (CEST)Beantworten
gudn tach user:Filzstift!
die leute auf meta meinen, dass extrem viel spam in form dieser kuerzeren urls reinkaeme. wir koennten's in dewiki einfach mal ausprobieren. siehe dazu separaten thread weiter unten. -- seth 15:50, 11. Okt. 2020 (CEST)Beantworten

Trennen

Bearbeiten

Hallo. Diese Seite hier ist ziemlich unübersichtlich. Ich würde es sehr begrüßen, wenn zumindest zwischen Vorschlägen für Eintragungen und Vorschlägen für Streichungen unterschieden würde. Darüber hinaus wäre eine separate Seite dafür zweckmäßig, z. B. MediaWiki Diskussion:Spam-blacklist/Anträge. Sie könnte sogar im WP-NR stehen, wo sie besser zu finden wäre. Also z. B. Wikipedia:Spam-blacklist/Anträge. Auf dieser Seite gäbe es dann nach einem Intro nur die Abschnitte "Eintragungen" und "Streichungen". Es wäre auch hilfreich, wenn Änderungen nicht mit so unspezifischen ZFs wie "der neueste Akkaly-Müll …" abgespeichert würden sondern mit einem konkreten Text, also "+sites.google.com/site/liebeab12", denn die Versionsliste muss auch als Logdatei fungieren. (Ein kleines Programm (ähnlich dem AWB), welche die ZF automatisch erstellt, wäre da für die Admins nützlich. Gruß von ÅñŧóñŜûŝî (Ð) 11:28, 11. Okt. 2020 (CEST)Beantworten

gudn tach!
im abschnitt #Saubere Projektseite, mehr Ordnung hatten wir vor ein paar jahren mal ueber eine restrukturierung gesprochen. das ist irgendwann im sande verlaufen, vermutlich auch weil's zu viel arbeit gemacht haette.
eine trennung zwischen streichen und aufnehmen faend ich persoenlich nicht sinnvoll, weil es diskussionen, die eigentlich zusammengehoeren, auseinanderreissen wuerde.
separate seite fuer antraege: da haette ich nichts dagegen, allerdings sollte die vermutlich 1. besser ohne die bezeichnung "blacklist" auskommen (weil der begriff quasi selbst auf die blacklist geraten ist und somit wohl als nicht nachhaltig angesehen werden sollte), aber 2. sollte meiner ansicht nach kein zu eingedeutschter begriff verwendet werden, weil spam was internationales ist und auch hin und wieder kommunikation mit wikipedianern von anderen wikis stattfindet bzw. jene diese seite hier gut auffinden koennen sollen.
unspezifische ZF: es gibt ein separates log, in dem auf die jeweiligen diskussionen zu jedem (fast) eintrag verwiesen wird. oben rechts im kasten verlinkt. -- seth 15:37, 11. Okt. 2020 (CEST)Beantworten

Änderungen an der Spam-Blacklist

Bearbeiten

Es sind Änderungen an der Art und Weise, wie Links blockiert werden können, geplant: s. phab:T337431 zum Einstieg und durchklicken. Kurz: diese Seite hier wird entfallen, stattdessen wird es eine neue Spezialseite geben, um einfach Domains (ohne Anwendung von Regexp) auzuschließen. Regexp-Blockierungen gehen dann nur noch über den Missbrauchsfilter. -- hgzh 08:07, 6. Jun. 2023 (CEST)Beantworten

Gudn Tach!
Danke für den Hinweis. Oha, das wird sicher ein Spaß. Es steht aber noch nicht fest, wann das kommt, oder?
Die Regexp-Regeln nur noch über das Edit-Filter zu regeln, klingt für mich eher ungeil. Etwas kritisch sehe ich auch, dass an der Diskussion niemand von den üblichen mir bekannten SBL-Admins teilzunehmen scheint. User-centered design sieht für mich anders aus. Aber ok, schauen wir mal. Vielleicht wird ja alles super. -- seth (Diskussion) 08:21, 7. Jun. 2023 (CEST)Beantworten
Nein, wann das kommt, steht wohl noch nicht fest. Das Zerpflücken der bisherigen Liste sehe ich auch recht kritisch, im Task hatte jemand vorgeschlagen, den Ausdruck nur optional als Regexp interpretieren zu lassen. Das würde ich auch besser finden. -- hgzh 10:13, 9. Jun. 2023 (CEST)Beantworten

Bearbeitungsfilter um eine Funktion zum Sperren von Domains erweitert

Bearbeiten

Ich möchte gerne auf die heute freigeschaltete Funktion "Bearbeitungsfilter um eine Funktion zum Sperren von Domains erweitert" hinweisen, siehe WP:NEU# 19. Juni 2023. --Raymond Disk. 11:48, 19. Jun. 2023 (CEST)Beantworten

Vgl. auch WP:AN (perma) --Filzstift (Diskussion) 15:00, 19. Jun. 2023 (CEST)Beantworten


(Ent-)Sperrungen

Bearbeiten
Letzter Kommentar: vor 11 Monaten16 Kommentare4 Personen sind an der Diskussion beteiligt

Neue Requests bitte unten anfügen. Das Wissen über unsere Richtlinien zu externen Links wird hier vorausgesetzt.

mirrors

Bearbeiten

ueber Wikipedia:Redaktion_Chemie/Archiv/2016/Dezember#www.chemie.de.2Flexikon bin ich darauf aufmerksamgemacht worden, dass Wikipedia:Weiternutzung/Mängel viele kandidaten fuer die sbl enthalten duerfte. allerdings muesste da wohl jede domain einzeln geprueft werden. pruefen heisst in diesem fall: 1. bisherige diskussionen dazu lesen; 2. schauen, ob in der wikipedia links dorthin in den letzten monaten platziert wurden; 3. hier einen antrag stellen.
falls jemand zeit hat, kann er ja mal anfangen. -- seth 23:14, 11. Mär. 2017 (CET)Beantworten

Lebensmittelkonversationseffizienz

Bearbeiten

Hi, ich bin 15 Jahre bei der wikipedia. Der Artikel stammt von mir. Quellen sind fast ausschließlich Masterarbeiten etc. Klar. Die Bild nimmt das Wort ebenso wenig wie die FAZ in den Mund. Aber egal was ich nehme: spamfilter verhindert jegliche pdf verlinkung. Ich werde den Artikel wohl eigenständig der QS melden müssen. Sorry . kein Verständnis für eure Haltung. Jemand einie Idee was und wie man verlinken könnte ?--blonder1984 (Diskussion) 20:57, 13. Nov. 2022 (CET)Beantworten

Scheint inzwischen geklärt zu sein [1][2]. Das Problem ist nicht PDF, sondern dass du zunächst anstelle des Originallinks nen Google-Link genutzt hast [3], die standardmäßig geblockt werden. --Johannnes89 (Diskussion) 21:25, 13. Nov. 2022 (CET)Beantworten

Copy-Paste-Unfälle: Domainname mit "%"

Bearbeiten
Gemeldet in Phabricator
Task T350190

https?-Domains mit %-Zeichen sind systematisch ungültig. zB https://www.eib.org%2Fattachments%2Fdocuments%2Fcv_madis_uurike_en.pdf&usg=AOvVaw0R_FdHxJUk5ZvxFGrUmmGa in Klaus-Dieter Ehmke siehe auch Benutzer:ⵓ/worklist6 bzw. quarry:query/77612  Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 18:20, 29. Okt. 2023 (CET)Beantworten

Gudn Tach!
Oha, guter Fund. Ich vermute, dass wir das mittels SBL schon blockieren könnten, aber dann würden wir zu viel mitblocken, z.B. auch den validen Link https://de.wikipedia.%6frg/. Gleiches gilt für das Edit-Filter.
Besser wäre also vermutlich ein Hinweis auf die Diskussionsseite der Leute, die sowas reinbringen. Das könnte ein Bot übernehmen. Wer technisch fit ist, kann's dann selbst beheben, alle anderen könnte man an WP:FZW verweisen.
Andere Vorschläge?
-- seth (Diskussion) 19:55, 29. Okt. 2023 (CET)Beantworten
Ich habe die Abfrage nun um einige weitere unerlaubte Zeichen ergänzt. Es sind nun aber ein paar false positive drinnen, etwa mit Koreanischen Zeichen. (Das MariaDB Regex arbeitet etwas seltsam). Ein Editfilter würde ebensogut reichen. Da man aber seit Oktober datenbankseitig die Domain (in umgekehrter Reihenfolge) in der Datenbank hat, sollte sich eine Überprüfung der Domain entsprechend der rfc möglich sein. Man könnte das aber ebenso in einen Edit-Filter einbauen. Eventuell könnte man das dann in Spezial:LintErrors ausgeben. Dafür müsste man wohl ein Ticket erstellen.
Ein Bot könnte zumindest bei angemeldeten Benutzern helfen, bei einigen Themen häufen sich die Fehler. Bei IPs/temporären Benutzern wird das eher wenig helfen. Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 22:01, 29. Okt. 2023 (CET)Beantworten
ich konnte nun die false-positiven entfernt, hier auch ein die Abfrage für enwiki Quarry:query/77756 Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 18:52, 31. Okt. 2023 (CET)Beantworten
Ich habe nun ein Ticket angelegt: T350190  Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 20:55, 31. Okt. 2023 (CET)Beantworten

ungenügendes Regex im Fall von Domain/Pfad

Bearbeiten

Siehe Diff [4]

Es kam die SBL-Meldung, 5.19.35.234/download geblockt ist. Den Eintrag habe ich aber in der lokalen SBL nicht gefunden, kommt der von meta?

Bei dem Link handelt es sich aber um 125.19.... Die Umgehung war allerdings auch recht einfach. siehe Diff. Ich denke für solche Fälle sollte das Regex angepasst werden. Mehrere Slashes lösen sich gerne auf einen Slash auf. Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 22:21, 30. Nov. 2023 (CET)Beantworten

Gudn Tach!
Blockierende SBL-Einträge kannst du via https://searchsbl.toolforge.org/ finden. Im konkreten Fall ist es der Eintrag
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/(idn|[pj]oker|daftar|download|deposit|login|sbotop|sv388|agen-|90bola|bola|mcn-livescore|slot-online)
auf m:Spam_blacklist. Dass "12" nicht erfasst wurde, macht eigentlich nichts.
Das mit den Slashes kann ich dort einbauen. -- seth (Diskussion) 22:50, 30. Nov. 2023 (CET)Beantworten
Dieser Filter ist schon recht allgemein, schadet aber offensichtlich nicht. Aktuell sind mindestens noch 6 URLs mit /download einer mit /agen im ANR. Die werden ich gleich mal angehen.  Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 23:32, 30. Nov. 2023 (CET)Beantworten
Ich brauche nun eine Whitelist für
* 194.245.36.230/downloads/4009134517817.pdf im Artikel Eierstecher, statt des Dirty-Fix
die anderen 6 Links die in das Muster vielen sind nun auf eine andere Weise gefixt, da brauchte ich kein Webarchiv. Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 00:01, 1. Dez. 2023 (CET)Beantworten
Gudn Tach!
Ich glaube zwar nicht, dass das überhaupt einen Beleg braucht, weil man bei einer Internetsuche schnell sowas findet wie [5][6] und außerdem unklar ist, inwiedern man der IP-Quelle vertrauen kann, aber andererseits ist zumindest kein Spamming bei diesem URL zu erwarten. Ich geb das mal frei und verschiebe diesen Thread nach WP:SBL. -- seth (Diskussion) 00:11, 1. Dez. 2023 (CET)Beantworten

(Herverschoben von user talk:lustiger_seth -- seth (Diskussion) 00:13, 1. Dez. 2023 (CET))Beantworten

Ich habe das im Artikel Eierstecher nun durch einen Link auf eine Kolumne in der Süddeutschen ersetzt. Frohes Schaffen — ⵓ ⌨   [​ɪ​​u:] 00:27, 1. Dez. 2023 (CET)Beantworten
Gudn Tach!
Ok, sehr gut. Dann entferne ich den Whitelist-Eintrag auch wieder. -- seth (Diskussion) 00:49, 1. Dez. 2023 (CET)Beantworten
Abschnitt hinzufügen
Abgerufen von „https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Spam-blacklist&oldid=250407483“