Wikiup:Technische Wünsche/Topwünsche/Erweiterung der Einzelnachweise

 Info: Verwandtes Projekt: „Wiederverwendung von Einzelnachweisen“ (Themenschwerpunkt 2022-2024)

Erweiterung der Einzelnachweise, so dass bei verschiedenen Seiten desselben Werks nicht immer das gesamte Werk angegeben werden muss
Status	Entfällt
Ursprung	Technische Wünsche 2013 und 2015
Ergebnis in der Umfrage	10 Punkte (2013) & 17 Punkte (2015)
Phabricator	Workboard auf Phabricator
Bearbeitende	Team Technische Wünsche

Diese Seite dient der Dokumentation von Entwicklungsverlauf, Recherche und Diskussionen rund um den Wunsch „Erweiterung der Einzelnachweise, so dass bei verschiedenen Seiten desselben Werks nicht immer das gesamte Werk angegeben werden muss“. Anmerkungen und Fragen gerne auf der Diskussionsseite!

Beispielbild für die Erweiterung der Einzelnachweise

Problemstellung

Wenn man einen Artikel mit mehreren Seiten desselben Werks belegen möchte, so muss man die Quelle bislang für jeden Beleg einzeln vollständig angeben. Das verlängert sowohl den Wikitext als auch den Abschnitt Einzelnachweise. Das Problem betrifft vor allem Autorinnen und Autoren, die Wikitext nutzen, und Lesende, die leichter sehen wollen, ob alle Einzelnachweise aus derselben Quelle stammen.

Abgrenzung

Das Vorschauproblem (Belege, die nicht in der bearbeiteten Sektion definiert werden, werden nicht angezeigt. Beim genannten Lösungsvorschlag tritt das Problem immer auf) ist ein separates Problem, an dessen Lösung derzeit ein ehrenamtlicher Entwickler arbeitet.

Status

• Dezember 2019: Kann auf dem Beta Cluster getestet werden. (Beispielartikel)
• Juli 2021: Keine weitere Arbeit an dem Projekt durch das Team Technische Wünsche.

Warum dieser Wunsch nicht umgesetzt wird

An diesem Projekt haben wir bereits lange gearbeitet und hätten es auch gerne zu Ende gebracht. An wiederholten interessierten Nachfragen konnten wir erkennen, dass die Funktion zumindest von einigen sehnsüchtig erwartet wird. Nach Betrachtung aller Möglichkeiten und Risiken sind wir allerdings zu dem Schluss gekommen, dass mehr dafür spricht, das Projekt nicht weiterzuführen, denn insgesamt gibt es hier zu viele Ungewissheiten und keine guten Erfolgsaussichten:

1. Die Umsetzung für den VisualEditor wäre sehr umfangreich und vom Team Technische Wünsche außerhalb eines Themenschwerpunkts nicht zu leisten. Es ergibt aber keinen Sinn, eine zentrale Funktion auf absehbare Zeit VisualEditor-Nutzer*innen nicht zur Verfügung zu stellen, denn alle sollten sich gleichermaßen in den Wikis beteiligen können. Zudem hätte eine Bereitstellung nur für den Quelltext zur Folge, dass die Nutzungserfahrung von VisualEditor- und Wikitext-Nutzer*innen weiter auseinandergeht, was wiederum Konflikte unter Editierenden verstärken könnte.
2. Es ist außerdem schwer abzusehen, wie viel Aufwand es noch wäre, die Funktion für die Quelltext-Bearbeitung umzusetzen. Sie ist zwar schon weit vorangeschritten, aber in der Vergangenheit traten hier oft Probleme auf, die uns Monate zurückgeworfen haben, und damit müssen wir auch jetzt wieder rechnen. Wir möchten verhindern, dass weiterhin viel Zeit in diesen Wunsch fließt, die dann bei anderen Projekten fehlt. Es zeichnen sich beispielsweise bereits wieder Verzögerungen ab, etwa die Koordination mit dem Editing Team der WMF (weil Änderungen an der Quelltext-Bearbeitung immer auch einen Einfluss auf den VisualEditor haben).
3. Hinzu kommt, dass der Wunsch nur je 10 Punkte (in der Umfrage 2013) bzw. 17 Punkte (2015) erhalten hat. Obwohl damals die Beteiligung an den Umfragen insgesamt noch geringer war, sind das sehr wenige Stimmen im Vergleich zu den Themenschwerpunkten (Leichter mit Vorlagen arbeiten: 298; Bessere Unterstützung von Geoinformationen: 280). Statt viel Zeit in diesen Wunsch zu investieren, möchten wir uns lieber den Themen widmen, die bei vielen Nutzenden für Verbesserungen sorgen können.

Angesichts all dessen möchten wir einen klaren Schnitt machen, statt das Projekt noch weitere Monate oder Jahre in der Schwebe zu halten. Vorstellbar wäre aber auch hier, dass der Wunsch im Zuge einer der kommenden Umfragen wieder aufgenommen wird, sofern ein passender Themenschwerpunkt die Abstimmung gewinnt (beispielsweise „Arbeit mit Belegen“ oder „Wartung“) und sich dieses Projekt als das größte Problem darin herausstellt. Auch könnte der Wunsch in der Community Wishlist des Teams Community Tech (WMF) eingereicht werden. Ein verwandter Wunsch hat es dort im vergangenen Jahr auf Platz 54 geschafft.

Ein kleiner Trost ist vielleicht, dass die Arbeit des Technische-Wünsche-Teams trotzdem nicht vergebens war, denn im Zuge dieses Wunsches haben wir die Cite-Erweiterung (der Teil der Software, mit der Einzelnachweise erzeugt werden) von Grund auf überarbeitet und modernisiert. Das macht es in Zukunft deutlich leichter als zuvor, in diesem Bereich Verbesserungen zu erzeugen.

Mehr zur Historie

Historie

• Nach den Umfragen 2013 und 2015 wurde dieser Wunsch zurückgestellt, weil es keine Communityübereinkunft darüber gab, wie eine Referenz grundsätzlich formatiert sein sollte.
• Lösungsvorschlag September 2016: Dann wurde ein Vorschlag erarbeitet, der so viel Flexibilität bietet, dass Autorinnen und Autoren die Einzelnachweise weiterhin an ihre Bedürfnisse anpassen könnten.
• Diskussionen mit Vertretern der Wikimedia Foundation zeigten, dass diese Lösung aus technischer Sicht machbar wäre.
• Feedbackrunde auf dewiki (2016)
• Der Entwicklungsbeginn verschiebt sich etwas weiter nach hinten, da insbesondere die Umsetzung des Wunsches "Dateien nach Commons verschieben" sich als aufwendiger erwiesen hat als gedacht. Statt zu Beginn des 3. Quartals (Juli) ist geplant, möglichst noch Ende des 3. Quartals (September) mit der Umsetzung zu beginnen. Dies hängt davon ab, ob bei der Umsetzung aktueller Projekte weitere Schwierigkeiten auftauchen oder nicht. (Juli 2017)
• Von der WMF kam Anfang des Jahres noch ein anderer Umsetzungsvorschlag: <ref refines=”Buch” refinement-data=”Seite 14”/> (siehe T151301). Es musste gemeinsam geklärt werden, welcher Vorschlag die bessere Lösung ist. Beim Hackathon 2017 konnte sich darauf geeinigt werden, dass doch die oben vorgestellte Lösung gemacht wird.
• Feedbackrunde auf Meta (2018)
• Nach Abwägung der Pros und Kontras aus den Feedbackrunden kam das Projektteam zum Schluss, dass die Vorteile einer Implementierung des vorgestellten Vorschlags überwiegen. Der Vorschlag soll also umgesetzt werden.
  Ein großer Vorteil dieser Lösung ist, dass das Definieren eines name-Attributs den Bedarf, Informationen zu wiederholen, reduziert. Darüber hinaus erlaubt das Bündeln der Nachweise, auf einen Blick zu sehen, ob ein Artikel lediglich auf einer einzigen Quelle basiert. Sehr vorteilhaft ist weiterhin, dass der Vorschlag niemanden daran hindert, andere Zitationsstile zu verwenden: Durch die Erweiterung einer bestehenden MediaWiki-Funktion können auch Leute, die bislang keine Vorlagen für Belege benutzen wollen oder können, Zitationen derselben Quelle bündeln. Gleichwohl können die existierenden Vorlagen weiterhin genutzt werden und die Communitys können sie anpassen, um die neue Formatierung zu nützen, müssen dies aber nicht. Dass der Vorschlag die Reihenfolge ändert, in der Fußnoten angezeigt werden, wird nicht als sehr problematisch eingestuft, denn anders als bei akademischen Werken, die primär für Print gemacht sind, können die Lesenden der Wikipedia auf Fußnoten klicken, und sind daher nicht auf eine spezifische Reihenfolge angewiesen. Weil zzt. an anderen Projekten von der Wunschliste gearbeitet wird, gibt es noch keinen konkreten Zeitplan. Dies werden aber die nächsten Schritte sein:
  • eine Entscheidung treffen, wie der Name des neuen Attributs lauten soll,
  • eine Möglichkeit finden, wie ein Beleg und seine Verfeinerung im selben Zuge definiert werden können,
  • herausfinden, wie Belege mit vielen Verfeinerungen gut dargestellt werden können.
• Mit der Umsetzung innerhalb des Projekts Technische Wünsche wurde darauf gewartet, dass die Arbeit am Parser Unification Project der Wikimedia Foundation voranschreitet. Inzwischen ist deutlich geworden, dass schon vor dem Abschluss dieses Projekts mit einem ersten Meilenstein begonnen werden kann.
• Der technische Ansatz, der verfolgt werden soll, wird Anfang Oktober abschließend mit der technischen Community besprochen.

Recherche

Feedbackrunde auf dewiki (2016)

Bis zum 22. September haben Autorinnen und Autoren Einschätzungen zu einem ersten Lösungsvorschlag abgegeben. Vielen Dank für die zahlreichen Rückmeldungen!

Votum	Grundsätzliche Meinung zum Lösungsvorschlag	Die Visual-Editor-Frage
Pro	28 Personen	22 Personen
Kontra	8 Personen	2 Personen
Neutral	2 Personen	0 Personen

Positive Punkte	Kritikpunkte	Weitere Anmerkungen/Rechercheaufgaben
Flexibilität Optionalität (kann, muss nicht angewendet werden) Einfachheit	Komplexität: Schwer zu verstehen für Neuautoren Der Vorschlag unterstützt eher diejenigen, die Kurzreferenzen bevorzugen. Diejenigen, die Langreferenzen bevorzugen, geraten weiter in den Hintergrund Man muss die Quelle zwingend benennen Vorschauproblem: Referenzen, die nicht in der bearbeiteten Sektion definiert werden, werden nicht angezeigt. Beim genannten Lösungsvorschlag tritt das Problem immer auf.	Wenn man bei der vorgeschlagenen Lösung zur Referenz springt, sieht man erstmal nur die “refines”-Info. Die “Überquelle” ist potentiell sehr weit oben. Wie könnte das verbessert werden? Name: Gibt es nicht was besseres als “refines”? Aufzählungselemente: Ist es möglich, 1.a, 1.b etc zu nennen? Grundsätzlich gab es noch Diskussionen, wie man besser auf bestimmte Teile einer Quelle im Artikel verlinken kann - diese sind hier als “anderes Projekt” außen vor gelassen.

Das positive Feedback zum Vorschlag überwiegt klar. Das Team würde die Umsetzung des Vorschlags daher gerne angehen. Wir müssen dafür noch die Details mit der Wikimedia Foundation klären und haben deswegen einen anderen Wunsch vorgezogen, planen jedoch diesen Wunsch als einen der nächsten Wünsche um zusetzten.

Dabei wichtig ist:

• Die Umsetzung im Visual Editor sollte mit erfolgen, der Nutzen des Vorschlags wäre stark minimiert, sollte der VE außen vor gelassen werden. Dies würde es vermutlich auch für die Neuautoren wieder weniger komplex machen, die vermutlich eher den Visual Editor nutzen. Die Frage der Umsetzung muss mit dem VE-Team abgesprochen werden.
• Das "Vorschauproblem" (Referenzen, die nicht in der bearbeiteten Sektion definiert werden, werden nicht angezeigt) sollte gelöst werden, damit die Umsetzung des Lösungsvorschlags sinnvoll gemacht werden kann.
• Es soll recherchiert werden, inwieweit der Bevorzugung von Kurzreferenzen bei der vorgeschlagenen Lösung entgegengewirkt werden kann.
• Weitere Rechercheaufgaben: Siehe weitere Anmerkungen/Rechercheaufgaben oben.

Feedbackrunde auf Meta (2018)

Für eine Einschätzung der verschiedenen Sprachcommunitys wurde o. g. Lösungsvorschlag im Mai 2018 auch auf Meta vorgestellt, wo er um ein paar geringfügige Konkretisierungen ergänzt wurde.

39 Menschen aus 12 verschiedenen Wikis gaben in einer Feedbackrunde auf Meta ihre Einschätzung zu diesem Vorschlag, die meisten von ihnen (ca. 66%) sind primär in der englischen Wikipedia aktiv. Das Feedback zeigte ein gemischtes Bild: Gut die Hälfte der Teilnehmenden (~46%) stimmten für den Vorschlag, mehr als ein Viertel (~28%) dagegen. Ein weiteres Viertel (~25%) konnte nicht klar einem Pro oder Kontra zugewiesen werden.

Ein großer Teil des Feedbacks basierte auf Vorlieben: So bevorzugen einige Teilnehmende beispielsweise die Vorlage {{sfn}}, weil sie einfacher zu lesen und zu bearbeiten ist. Andere hingegen finden {{sfn}} schwer zu lesen und zu bearbeiten. Dasselbe kann auch für andere Lösungen gesagt werden, inklusive der hier vorgestellten.

Das Verhältnis von Seiten mit Zitationsvorlagen zu allen Inhaltsseiten von 10 verschiedenen Wikipedien (Status: September 2018).
Beispiel: Die englische Wikipedia hat insgesamt 5.717.161 Inhaltsseiten. 76.616 (1,34%) davon verwenden die Vorlage {{sfn}}, 30.641 (0,54%) verwenden {{rp}}.

Pro-Stimmen

Von Vorlieben abgesehen, gaben die Pro-Stimmen als Hauptgrund an, dass der Vorschlag eine integrierte Funktion darstellt, die nicht auf Vorlagen basiert. Diese Probleme mit Vorlagen wurden genannt:

• Vorlagen sind für neue Editierende schwer zu erlernen.
• Vorlagen erhöhen die Serverlast.
• Vorlagen sind nicht maschinenlesbar, was die Verarbeitung für Bots erschwert.
• Nicht alle Wikis nutzen Vorlagen. Eine integrierte Lösung würde in allen Wikis funktioneren, unabhängig davon, welche Vorlagen dort verwendet werden. Die Grafik zeigt die Verteilung verschiedener Zitationsvorlagen in den Wikis, in denen die Teilnehmenden der Feedbackrunde primär aktiv sind.

Weitere Gründe

• Mehrere Leute stimmten mit pro ab, ohne einen Grund zu nennen
• Der Vorschlag basiert auf einem bestehenden System.
• Für Lesende ist es transparenter, wie oft eine Quelle als Beleg verwendet wurde, sowohl im Abschnitt „Einzelnachweise“ als auch im Artikel selbst.

Kontra-Stimmen

• Ein weiteres Zitationssystem einzuführen, macht das ohnehin komplexe Thema Belege noch komplexer.
• Untergeordnete Fußnoten wie 1.1, 1.2 etc. sind in der akademischen Welt nicht üblich.
• Ein System mit eingerückten Fußnoten kann die Einzelnachweiseliste inkonsistent machen, denn es wird Quellen geben, die nur einmal und andere, die mehrfach zitiert werden.
• Der Vorschlag spricht von der Gruppierung von Belegen, aber tatsächlich gruppiert er Fußnoten. Fußnoten können neben Belegen auch erklärenden Text, Tabellen usw. enthalten. Diese Terminologie wird auch sonst häufig vermischt und kann auf ein konzeptionelles Problem hinweisen.

Benennung des neuen Attributs

Es haben sich nur wenige (12) Teilnehmende an der Frage nach der Benennung beteiligt. Es gab keine klare Mehrheit für die verschiedenen Namensvorschläge (refines, extends und neue Vorschläge).

Die geplante Lösung

So in etwa sähe ein Artikel aus.

Die folgende Lösung war geplant und die Umsetzung für die Nutzung im Quelltext-Modus schon vorangeschritten. Aus den hier beschriebenen Gründen wird dieser Wunsch aber nicht umgesetzt. (7. Juli 2021)

Wie Referenzen erzeugt werden

Der Vorschlag zwingt niemanden, anders zu arbeiten als bisher. Alle bestehenden Zitationsmethoden sind weiterhin ohne Einschränkung möglich.

mit Wikitext

Das Werk, auf das mehrfach referenziert wird, wird einmalig mit dem name-Attribute definiert, beispielsweise name="Pierson". Es wird dann jedes Mal, wenn ein Teil dieses Werkes referenziert wird, das neue extends-Attribut verwendet.

Beispiel: <ref extends="Pierson">S. 123–163 </ref> ergänzt im Abschnitt „Einzelnachweise“ unter der Referenz mit dem Namen „Pierson“ die Verfeinerung „S. 123–163“.

Im Screenshot wurde die Hauptreferenz innerhalb des Abschnitts „Einzelnachweise“ definiert. Es wird aber auch möglich sein, die Hauptreferenz innerhalb des Artikeltexts zu definieren, ohne eine ungenutzte Sprungmarke zu erzeugen. Eine Syntax dafür zu erzeugen ist auf der To-Do-Liste des Projektteams.

Vorteile

Weitere Hinweise

„extends“ macht keinerlei Einschränkungen, wie eine Referenz verfeinert wird. Sie kann für Seitenzahlen ebenso genutzt werden wie zum Beispiel für Bibelverse oder Kapitel. „extends“ zwingt niemanden dazu, die Arbeitsweise umzustellen. Alle bisherigen Methoden sind ohne Einschränkung weiterhin so möglich. „extends“ funktioniert unabhängig von Sprache, Schrift und Schreibrichtung.

Verstecken der Referenz auf das Werk selbst: Will man auf das Buch als Ganzes nicht im Text verweisen, sondern immer nur auf verschiedene Abschnitte, definiert man das Buch innerhalb der „<references> </references>“-Klammern im „Einzelnachweise“-Abschnitt, um keine ungewünschte Markierung im Text zu erzeugen. Unterstützung des VisualEditor: Zunächst würde das „extends“-Attribut nicht im VisualEditor auftauchen. Technisch wäre dies zwar möglich, für die Umsetzung wären jedoch weitere Absprachen nötig. Das betrifft zum einen das VisualEditor-Team, zum anderen müsste hier ggf. entschieden werden, wie die neue Version in das Userinterface des VisualEditors integriert werden soll. Beachtung der internationalen Relevanz: Wenn das „extends“-Attribut umgesetzt werden sollte, wäre es in allen Sprachcommunitys verfügbar. Aus diesem Grund ist es z. B. notwendig, die Verfeinerungen „1.1“ und nicht „1.a“ zu nennen, da dies deutlich besser in unterschiedliche Sprachen übertragbar ist.

mit Vorlagen

Ob sich für die diejenigen, die Vorlagen zum Belegen verwenden, etwas ändert, hängt von den Vorlagenbauern ab. Vorlagen setzen auf Wikitext-Syntax auf, und weil die Wikitext-Syntax für diesen Vorschlag optional ist, können Vorlagenbauer entscheiden, ob sie ihre Vorlagen anpassen wollen oder nicht.

So in etwa könnte der Vorschlag im Visual Editor aussehen.

mit dem Visual Editor

Wer den Visual Editor nutzt, wird das neue Modell ebenfalls verwenden können. Es könnte so aussehen, wie im Screenshot dargestellt.

Der Vorschlag zwingt niemanden, anders zu arbeiten als bisher. Alle bestehenden Zitationsmethoden sind weiterhin ohne Einschränkung möglich.

Bitte beachten

• Wenn man zum Erstellen von Einzelnachweisen eine Vorlage verwendet, die nicht das Attribut name benutzt, dann ist es nicht möglich, das Attribut extends zu nutzen.
• Alle Seiten, auf denen extends verwendet wird, kann man per Suchabfrage finden: https://en.wikipedia.beta.wmflabs.org/wiki/Special:PagesWithProp?propname=ref-extends&namespace=
• Da die erweiterten Fußnoten eingerückt werden, benötigen Wikis mit mehrspaltigem Fußnoten-Layout oder anderen visuellen Effekten ggf. Anpassungen ihrer Stile.

Allgemeine Verbesserungen an der MediaWiki-Erweiterung Cite

Während der Arbeit an diesem Feature hat das Team Technische Wünsche einige allgemeine Verbesserungen an der Mediawiki-Erweiterung, die für die generelle Erzeugung von Einzelnachweisen zuständig ist, vorgenommen. Dabei wurde u.a. nicht funktionierender Code entfernt und die gesamte Codebasis neu strukturiert, um die Leistung und Wartbarkeit zu verbessern.

Feedback

Auf der Diskussionsseite sind weitere Hinweise oder Ergänzungen zu diesem Wunsch wie immer willkommen.