Wikipedia

Wikipedia:Technik/Baustellen/Warnung wenn Zusammenfassung fehlt

< Wikipedia:Technik | Baustellen

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

Problem

Bearbeiten

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

Bearbeiten

Stand der Dinge:

Serverseitig und clientseitig

Bearbeiten

Server

Bearbeiten

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

Bearbeiten
  • 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)

Bearbeiten

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

Vorteile

Bearbeiten
  • 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

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

Elemente auf dem Weg zur JS-Lösung

Bearbeiten

Null-Edit

Bearbeiten

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

Bearbeitungsfeld

Bearbeiten

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

Bearbeiten
  • 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

Bearbeiten

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

Bearbeiten

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.
  • 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

Bearbeiten

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

Opt-Out

Bearbeiten
  • 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

Bearbeiten

Polnische Lösung

Bearbeiten

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

Umherirrender, April 2012

Bearbeiten

Benutzer:Umherirrender/gadget/highlightemptysummary.js

TMg, Juni 2012

Bearbeiten

Benutzer Diskussion:TMg/forceEditSummary.js

Sinn der Zusammenfassung

Bearbeiten

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

Bearbeiten

Aus der Skin-Werkstatt:

Diese Dauerbaustelle

Bearbeiten
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Baustellen/Warnung_wenn_Zusammenfassung_fehlt&oldid=126922733“