Wikipedia:Technik/Baustellen/Warnung wenn Zusammenfassung fehlt

Auf dieser Seite werden Lösungsansätze zum Umgang mit fehlendem Bearbeitungskommentar und angemessene Erinnerung der Benutzer zusammengestellt.

Problem

Wenn Seiten abgespeichert werden, ist grundsätzlich ein kurzer Hinweis in der Zusammenfassung zu wünschen. Oft wird dies schlicht vergessen.

• Eine angemessene Benutzerführung wurde bisher noch nicht gefunden.
• Es wird nach Lösungen gesucht, die dazu geeignet sind, langfristig als Standard auch für unangemeldete aber auch langjährig angemeldete Benutzer vorgegeben zu werden.

Vorgeschichte

• Wikipedia:Meinungsbilder/Hinweis auf Notwendigkeit der Angabe von Zusammenfassung und Quellen (2009)
• Wikipedia:Erzwungene Zusammenfassung
• Missbrauchsfilter 10 aktivieren: Zusammenfassung forcieren
  Spezial:Missbrauchsfilter/10
• Wikipedia:Projektdiskussion/Hinweise und Einschränkungen für Edits von IPs

Stand der Dinge:

• Angemeldete Benutzer können per Opt-In die MediaWiki-interne Funktion forceeditsummary in den Einstellungen aktivieren (MediaWiki:Missingsummary).

Serverseitig und clientseitig

Server

Die beiden Lösungen

• forceeditsummary
• Missbrauchsfilter

sind server-basiert: Die Gesamt-Bearbeitung wird an den Server geschickt; dieser wertet die Aktion aus und reagiert mit einer neuen Seite. Das ist dann entweder:

1. Geänderte Seite im Normalzustand
2. Weiterhin Bearbeitungsseite, mit Mitteilungsbox

Nachteil

• Die Zeit bis zum Aufbau der neuen Seite kann leicht ein Dutzend Sekunden bis etwa eine halbe oder ganze Minute betragen, abhängig von Netzwerkgeschwindigkeit, Seitengröße, PC-Hardware, Browser, Serverlast.
• Benutzer schließen oft Tab/Fenster des Browsers unmittelbar nach dem scheinbaren „Abspeichern“, um an anderen Themen weiterzuarbeiten. Die Bearbeitung ginge dann verloren.
  • Nebenbei ist das kein ratsamer Arbeitsstil; es könnte auch zum Bearbeitungskonflikt gekommen sein oder der Server mag down sein. Man kann zwar sofort nach Auslösen der Speicherung die Tabs/Fenster verlassen oder ggf. minimieren, sollte jedoch eine Weile später zurückkommen und die Tabs/Fenster erst bei Erfolg schließen.
• Neue und erst recht noch nie angemeldete Benutzer (IP) rechnen nicht unbedingt mit diesem Verhalten.

Serverseitige Lösungen konnten sich deshalb nicht als Standard durchsetzen.

Client (→JavaScript)

Lösungen mit JavaScript arbeiten unmittelbar im Browser (Client).

Vorteile

• Die Reaktion ist spätestens Sekundenbruchteile nach dem Auslösen des Abspeicherns sichtbar; grundsätzlich kann ein optischer Hinweis auch schon vorher erfolgen, falls noch keine Zusammenfassung vorliegt bzw. diese noch nicht wirksam geändert wurde.
• JavaScript-Lösungen sind für die deWP detailliert konfigurierbar und könnten auf Wünsche jedes einzelnen Benutzers eingestellt werden.
• Namensräume und andere Umstände könnten berücksichtigt werden.

Nachteil

• Benutzer ohne aktiviertes JavaScript würden nicht erfasst werden.

Elemente auf dem Weg zur JS-Lösung

Null-Edit

Ein sogenannter „Null-Edit“, also das Abspeichern ohne Textveränderung etwa zur Cache-Aktualisierung, muss immer ohne Notwendigkeit einer Zusammenfassung möglich sein.

Bearbeitungsfeld

Bei Textänderung in der wpTextbox1 wird nicht nach Eingabe des ersten Zeichens, sondern erst mit dem Verlassen des Bearbeitungsfeldes das Ereignis textarea.change() ausgelöst.

• Dies kann zum Auslösen einer Hervorhebung genutzt werden.
• Es bleibt kontinuierlich nachvollziehbar, ob der Inhalt des Textarea gegenüber der Ursprungs-Zeichenkette verändert wurde, ggf. auch zurückgesetzt worden ist.

Umfang der Eingabe

• Ein sichtbares Zeichen wie t oder k kann bereits eine gültigeZusammenfassung sein.
• Leerzeichen oder Tabulator-Zeichen wären allein keine valide Eingabe.

Automatische Vorgaben

Das Zusammenfassungsfeld kann automatisch bereits Inhalte enthalten:

1. Vorhandener Abschnitt, eingeschlossen in /* ... */
2. Letze Änderung zurückgesetzt von … auf Version von …
3. Neuer Abschnitt: …

Im ersten Fall würde dies nicht als gültige Zusammenfassung gelten. Die anderen beiden automatischen Einträge sind gültige Einträge; für die RCler beim Vandalismus-Edit hinreichend, bei Nutzung von „Abschnitt hinzufügen“ ohnehin nicht zu beeinflussen.

Speichern-Button

Der mögliche Eingriff in die Event-Zuordnung des Abspeichern-Buttons ist sehr riskant.

• Bei älteren und weniger standardkonformen Browsern kann dies dazu führen, dass dem Benutzer das Abspeichern überhaupt nicht mehr möglich ist.
  • In pl:MediaWiki:Gadget-edit-summary-warning.js wird event.preventDefault() ausgelöst; das kann auch schiefgehen.
• Statt in den Original-Button einzugreifen, ist es wesentlich sicherer, den Original-Button unsichtbar zu schalten und einen neuen Button und mit eigener Funktion und ggf. anderer Beschriftung einzufügen.
  • Zum Umschalten kann der Zweit-Button unsichtbar gemacht werden und das Original wieder erscheinen.
• Die Zuordnung des Tastaturkürzels ist zu organisieren. Es soll nicht möglich sein, mittels Tastaturkürzel eine andere Wirkung als durch Mausklick zu erreichen.

URL-Parameter

Kein Warnhinweis auf eine angeblich fehlende Zusammenfassung mehr, wenn diese bereits mit dem URL-Parameter &summary= übergeben wurde (Bugzilla:17416, rev:111091).

Opt-Out

• Auch wenn eine Warnung Vorgabe für alle Benutzer wäre, müssen angemeldete Totalverweigerer die Möglichkeit erhalten, durch einfachen Häkchen-Klick in den Benutzereinstellungen die Warnfunktion außer Funktion zu setzen.
• Nicht angemeldeten Benutzern (IP) kann man dagegen durchaus einen Bearbeitungskommentar abverlangen. Gesichtet werden muss ohnehin.

JS-Lösungen

Polnische Lösung

pl:MediaWiki:Gadget-edit-summary-warning.js

TMg, Juni 2012

Benutzer Diskussion:TMg/forceEditSummary.js

Sinn der Zusammenfassung

Auch bei kleineren Bearbeitungen ist eine konkrete Zusammenfassung wichtig für die beobachtenden anderen Nutzer wie auch zum Nachvollziehen der Versionsgeschichte.

• Für die Beobachter der Seite ist beim kommentarlosen Edit nicht klar, worum es ging. – Die maulige Stellungnahme „es kann doch jeder eine Diffpage machen, dann ist ja selbsterklärend, was ich geändert habe“ genügt nicht.
  • Das zwingt den beobachtenden Kollegen auf, für ggf. Hunderte von Seiten auf der Beo zu jedem einzelnen eine Diffpage zu bilden. Der Edit mag ja tatsächlich geringfügig sein, aber ein t oder lf in Verbindung mit einem halbwegs bekannten Benutzernamen guter Reputation erspart dies.
  • Die vertrauten Pelz–PD oder Aka–Tippfehler bedürfen meist keiner Nachkontrolle.
  • Auch bei den kleinen Edits der bots wird aus gutem Grund ein präziser Kommentar der Änderung aufgeschrieben.
• In der Versionsgeschichte ist nach zwei Dutzend kommentarloser Änderungen kein Überblick zu gewinnen, was sich zugetragen haben mag. Jeder einzelne Edit muss durchgesehen werden, statt einen ganzen Block als für die Fragestellung irrelevant erkennen zu können.
  • Es wird argumentiert, dass beim Einfügen eines Nachweises kein Kommentar erforderlich wäre, weil ja dieser Beleg sich selbst nachweisen würde. – Schon, aber darum geht es nicht. Vielmehr wird ein schlichtes +ref oder ausführlicher Beleg eingefügt von den Beobachtern sowie zum späteren Rückverfolgen der Versionsgeschichte als Anhaltspunkt benötigt.
• Es gibt die Option „Alle meine Edits als klein markieren“ (minordefault). Damit ist für die Kollegen wiederum nicht klar: Ist dieses K-Häkchen automatisiert pauschal vergeben worden, oder wurde es ganz bewusst für diesen einzelnen Edit gesetzt? Oder war es eigentlich eine größere Bearbeitung, bei der das automatische K gesetzt war und vergessen wurde, es in diesem einzelnen Fall herauszunehmen?
  • Der Wert des K wird deshalb regelmäßig angezweifelt; siehe Hilfe:Kleine Änderungen und irgendwo verstreut allerlei Projekt-Disku dazu, u. a. wohl bei den RClern sowie zu Sichtung und VJagd, umfassend: Hilfe Diskussion:Zusammenfassung und Quellen/Archiv/1.
  • Das K ist mehr eine Option zum schnellen Filtern für RCler; für die Analyse der Versionsgeschichte durch Mit-Autoren weniger hilfreich. Einzelne RCler können damit massenhaft alle Arten von link-sort-kat-ND-PDfixen sowie typografischen, orthografischen, grammatikalischen und Wikisyntax-Fehlern unterschiedlichster Bearbeitungskommentare ausfiltern und ihren Arbeitsschwerpunkt auf den Rest fokussieren.

Diskussion ab 2011

Aus der Skin-Werkstatt:

• Wikipedia:Technik/Archiv/2011 #Leere Zusammenfassungszeile farblich hervorheben
• Wikipedia:Technik/Archiv/2012 #Farbige Hervorhebung, wenn die Zusammenfassung fehlt