Wikipedia:Umfragen/Technische Wünsche/Top 20/Wunsch 1

Problembeschreibung: <ref>…</ref> werden nicht angezeigt, wenn kein <references /> im Wikitext folgt. Das betrifft:

Wird versehentlich oder aus Unwissenheit ein Artikel mit <ref> jedoch ohne <references /> gespeichert, erscheint dauerhaft eine rote Fehlermeldung am Ende des Artikels. In der Vorschau kann man diese vorab sehen.
VisualEditor erlaubt aktuell das Einfügen von Einzelnachweisen, weist jedoch gar nicht auf das fehlende <references /> hin. Erst nach dem Speichern sieht man die Fehlermeldung (Bug 45132).
Beim Bearbeiten von Abschnitten fehlt jede Vorschau inklusive der Fehlermeldung (Wunsch 19). Das führt dazu, dass auch erfahrene Anwender versehentlich das <references /> vergessen.
Alle Lösungsansätze müssen den Sonderfall „<ref> nach dem letzten <references />“ beachten.

Grundsätzliche Lösungsmöglichkeiten:

Nachtrag durch nachfolgende Bearbeitung
Warnung
Ergänzungshilfe
Vollautomatische Ergänzung im Wikitext (Bug 30763)
Anzeige am Artikelende auch ohne <references />-Tag (Bug 30763)

Nachtrag durch nachfolgende Bearbeitung

Umsetzung nur manuell oder als Bot sinnvoll, nicht als Funktion der Software.

Pro:

Existiert bereits in Form von Wartungslisten, die äußerst zeitnah abgearbeitet werden, sowie Bots, u. a. Xqbot.
Anfänger werden – abgesehen von der abschreckenden Fehlermeldung – nicht belehrend unterbrochen.
Das Risiko, Anfänger abzuschrecken und nützliche Bearbeitungen zu verlieren, ist minimal.
Die nachfolgende (Bot-) Bearbeitung kann sogar als zusätzliches Erfolgserlebnis empfunden werden, da das Hinzufügen des Einzelnachweises dadurch gewissermaßen bestätigt wird. Bedingung: Die Zusammenfassungszeile sollte entsprechend einladend formuliert sein (beispielsweise „Ich habe deine Ergänzung – übrigens vielen Dank dafür – im Artikel sichtbar gemacht“).

Kontra:

Taucht als zusätzliche (kleine Bot-) Bearbeitung in Versionsgeschichte, Logbuch und Beobachtungslisten auf.
Aufwand für Botbetreiber.
Benennung und Positionierung des Abschnitts sind nicht eindeutig geregelt.

Aufwände:

Hilfestellung bei der Weiterentwicklung, ggf. Portierung bestehender Bots. Als eine Art „WMDE-Bot“ nicht sinnvoll.

Warnung

Umsetzung clientseitig per JavaScript und/oder serverseitig. Eine JavaScript-Lösung muss bei Abschnittsbearbeitungen zusätzlich den gesamten Artikel per API abfragen und analysieren.

Pro:

Als „Bearbeitungsfilter“ (AbuseFilter-Erweiterung) sofort umsetzbar.
Sowohl als Bearbeitungsfilter als auch als Helferlein (Gadget) durch die Community selbst umsetzbar.

Kontra:

Die Fehlermeldung der Cite-Erweiterung leistet im Grunde schon genau das, jedoch nur beim Bearbeiten ganzer Artikel.
Kann auf unerfahrene Benutzer abschreckend wirken. Schlimmstenfalls verwirft der Neuling seinen Bearbeitungsversuch dann, selbst wenn er wichtig für die Bequellung des Artikels gewesen wäre.
Kann zum Verlust von Bearbeitungen führen. Wie bei der Einstellung „Warnen, sofern beim Speichern die Zusammenfassung fehlt (oder es sich um die Standardzusammenfassung beim Zurücksetzen handelt)“ (zahlreich diskutiert, einst per Meinungsbild aktiviert jedoch sehr bald wieder deaktiviert) wirkt es beim Klick auf „Seite speichern“, als wäre der Speichervorgang erfolgreich angestoßen worden. Wechselt der Benutzer in diesem Moment den Browsertab und schließt den vermeintlich erledigten Tab später, geht die Bearbeitung verloren.
Wird nicht verstanden. Die Warnmeldung müsste sehr weit ausholend erklären, wovon sie spricht, warum das Fehlen des Syntaxelements ein Problem darstellt und wie der Benutzer das beheben kann.
Zusätzliche minimale Verzögerung bei jedem Speichern.

Aufwände:

Ggf. Hilfestellung bei Filtererstellung, sofern überhaupt nötig.
Offene Entwicklung eines Helferleins gemeinsam mit der Community (geschätzt 2 Sprints, 50 %). In einem zweiten Schritt kann diese Funktion anschließend in die Cite-Erweiterung übertragen werden.
Ggf. Zuarbeit zum VisualEditor, siehe Bug 45132.

Ergänzungshilfe

Umsetzung am ehesten per JavaScript denkbar, evtl. auch serverseitig. Eine serverseitige Umsetzung würde zu einer Anzeige ähnlich wie bei einem Bearbeitungskonflikt führen, so dass der Benutzer die vorgeschlagene Ergänzung begutachten und ggf. ändern kann.

Pro:

„Sanfte“ Benutzerführung im Dialog möglich.
… sonst wie unten.

Kontra:

Beim Bearbeiten von Abschnitten nicht direkt im selben Edit lösbar, würde statt dessen einen zweiten Edit des Benutzers auslösen.
Kann zum Verlust von Bearbeitungen führen, wenn der Klick auf „Seite speichern“ unterbrochen, das übersehen und das Browserfenster geschlossen wird.
Erhöht die Komplexität der Software und ihrer Bedienung.
… sonst wie unten.

Aufwände:

Umsetzung als Weiterentwicklung eines der obigen Warn-Lösungsansätze. Aufwände addieren sich entsprechend (geschätzt +2 Sprints, 100 %).

Vollautomatische Ergänzung im Wikitext

Umsetzung clientseitig per JavaScript, das in den Wikitext eingreift, oder serverseitig als zusätzlicher Vorverarbeitungsschritt.

Pro:

Umsetzung als Helferlein (Gadget) kann sehr gut für jede Sprache individuell konfiguriert werden.
Umsetzung als Helferlein bleibt vollständig in den Händen der Community.

Kontra:

Benennung und Positionierung des Abschnitts sind nicht eindeutig geregelt.
Muss für jede Sprache getrennt entwickelt werden. Nicht nur zur Übersetzung, sondern auch aufgrund des einzufügenden Quelltexts (Vorlage oder nicht und wenn ja, welche) und vor allem aufgrund der Stelle, an der einzufügen ist.
Fehleranfällig. Jede vom Benutzer bewusst oder versehentlich verursachte Abweichung kann dazu führen, dass an der falschen Stelle eingefügt wird.
Stupides Einfügen am Artikelende ist sinnlos, siehe Alternativvorschlag unten.
Momentan ist es abgesehen von wenigen Ausnahmen (Signaturen, substituierte Vorlagen, [[Link (Zusatz)|]] wird beim Speichern zu [[Link (Zusatz)|Link]]) unüblich und entspricht nicht der Benutzererwartung, den Quelltext automatisch zu manipulieren.

Aufwände:

Als Helferleins ist das als Weiterentwicklung der Warn-Lösung denkbar. Aufwände addieren sich entsprechend (geschätzt +2 Sprints, 100 %).
Auch als serverseitige Weiterentwicklung der schon bestehenden Funktion der Cite-Erweiterung oder als zusätzliche Erweiterung denkbar. Konkrete Aufwände insbesondere im Zusammenspiel mit dem VisualEditor sehr schwer abschätzbar.

Anzeige am Artikelende auch ohne <references />-Tag

Umsetzung als Funktion der Cite-Erweiterung.

Pro:

Am wenigsten in etablierte Prozesse eingreifende Lösung. Es wird lediglich eine weitere technische Möglichkeit hinzugefügt. Es obliegt der Community, ob und in welchem Umfang sie bewusst davon Gebrauch machen oder das Fehlen des <references />-Tags weiterhin als Fehler werten will.
Bestehende Werkzeuge werden nicht hinfällig sondern die Korrektur nach wie vor fehlerhafter Quelltexte nur weniger dringlich.
Einziger Ansatz, der automatisch auch die fehlende Einzelnachweis-Vorschau beim Bearbeiten von Abschnitten (Wunsch 19) lösen kann.
Wird automatisch auch Druckansichten etc. korrigieren.
Möglicherweise ein guter Startpunkt, um wieder ein aktives Entwicklungsteam um die eingeschlafen wirkende Entwicklung der Cite-Erweiterung zu scharen.

Kontra:

Kann zu als „falsch“ empfundenen Platzierungen der Einzelnachweise führen.
Kann zu bewusst weggelassenen Tags und zusätzlicher Nacharbeit führen. An der Pflicht, die Überschrift „Einzelnachweise“ (o. ä.) im Artikel zu verwenden und diese (und damit auch die <references />) nur an bestimmten Positionen zu verwenden, ändert sich jedoch nichts.
Muss entweder konfigurierbar sein oder die Zustimmung aller Communitys finden.

Aufwände:

Weiterentwicklung der schon bestehenden Funktion der Cite-Erweiterung, praktisch anstelle der Fehlermeldung (geschätzt 3 Sprints, 100 %).