Wikipedia Diskussion:Technische Wünsche/Topwünsche/Erweiterung der Einzelnachweise

Bitte achtet auf einen freundlichen Umgangston. Das Projekt Technische Wünsche lebt vom Austausch. Alle Beiträge sind willkommen, solange sie konstruktiv sind. Das Projektteam bittet von persönlichen Angriffen oder beleidigenden Kommentaren abzusehen. Siehe dazu auch: Wikiquette, Wikiliebe, Keine persönlichen Angriffe

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit einem Tag mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Archiv

Zur Archivübersicht

Wie wird ein Archiv angelegt?

Einschätzungen zum Lösungsvorschlag (September 2016)

Antworten aus der Feedbackrunde

Das ist meine grundsätzliche Meinung zur vorgeschlagenen Lösung

• Das Einzelnachweissystem ist derzeit schon so unfassbar kompliziert geworden, ohne ein zweijähriges Studium ist das kaum zu bewältigen. Ich glaube nicht, daß die Einführung noch weiterer Möglichkeiten zielführend wären. Das macht es für Altautoren wie für Neuautoren immer komplizierter und unterstützt dann ohnehin nur den Einzelnachweiswahn. Schon jetzt glauben viel zu Viele, daß "Belege" = "Einzelnachweise" sind. Noch mehr Möglichkeiten würde wohl nur eine Zementierung dieses Unsinns sein. Marcus Cyron Reden 18:14, 12. Sep. 2016 (CEST)
• Ich finde den Vorschlag gut. Ich hätte so etwas bisher nur selten gebraucht, aber immerhin ein paar mal schon. Rjh (Diskussion) 18:59, 12. Sep. 2016 (CEST)
• Technisch halte ich die Lösung für einfach und direkt, abgesehen davon, den Volltext bei den Referenzen zu deklarieren, dass ist irgendwie verkomplizierend. Was spricht denn dagegen, in den Einzelnachweisen nur die Seiten und im Literatur-Abschnitt die Werke anzugeben? Klappt heute schon und ist übersichtlich. (Beispiel: Physik des Segelns) --PaterMcFly Diskussion ^Beiträge 19:02, 12. Sep. 2016 (CEST)
  • Die Form, wie Wikipedia bearbeitet wird spricht dagegen. Wikipedia ist nicht gedruckt, sondern im Fluß. Eine Änderung an der "falschen" Stelle und schon ist das ganze System zusammen gebrochen. Marcus Cyron Reden 20:17, 12. Sep. 2016 (CEST)

@PaterMcFly: Der Artikel Physik des Segelns ist leider ein böses Negativbeispiel. Gott bewahre, „Püschl“ (oder seine Cousine) wagt es, ein zweites Buch zu schreiben. Oder aber, irgend ein Depp kommt her und löscht das Buch aus der Literaturliste. Den Spaß, den man dann hat, kannst du in der Versionsgeschichte von Merseburger Zaubersprüche bestaunen. PS: Im ersten Augenblick habe ich nach einem Autor namens „Seemannschaft“ gesucht. Grrr.  _hugarheimur 18:23, 15. Sep. 2016 (CEST)

@Torana: Ok, das Risiko für so ein Chaos wäre wohl etwas reduziert, weil der Parser Fehler werfen würde, aber wenn der Bearbeiter da nicht drauf achtet, kann es genauso schief gehen. --PaterMcFly Diskussion ^Beiträge 21:30, 15. Sep. 2016 (CEST)

• Ich finde den Vorschlag grundsätzlich sehr gut. Das macht viele höchst komplizierte Artikel deutlich einfacher, Harvard-Style-References werden auf diese Weise sinnvoll umsetzbar.  Frohes Schaffen — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
• +1, gerade auch wegen der mit dem Vorschlag gebotenen Flexibilität. -- Karl432 (Diskussion) 19:27, 12. Sep. 2016 (CEST)
• Super-Lösung: Einfach, flexibel, und wer es nicht will, soll es halt nicht benutzen. -- Perrak (Disk) 19:29, 12. Sep. 2016 (CEST)
• Das einzige was mich stört ist, dass man sich neue Namen ausdenken muss, um dieselbe Seitennummer zu referenzieren. Auch finde ich diese Tags mit Parameterangabe lästig, da gefällt mir die Vorlage:CRef von Wikisource irgendwie besser. Sowas sollte es auch bei uns geben, etwa in der Form {{CRef|Pierson|131}} oder {{CRef|Pierson|123–163}}, so dass dann auch doppelte Seitenangaben automatisch erkannt werden.--Sinuhe20 (Diskussion) 19:36, 12. Sep. 2016 (CEST)

  Das ließe sich vielleicht auch hier als Vorlage umsetzen. --mfb (Diskussion) 22:32, 13. Sep. 2016 (CEST)

• Das ist ziemlich genau das, was wir auf dem Bonner Stammtisch mal besprochen hatten ... also ganz klar dafür! axp_de^Hallo! 19:51, 12. Sep. 2016 (CEST)
• Ja, passt!--Mabschaaf 20:31, 12. Sep. 2016 (CEST)
• Dafür! --Reinhard Müller (Diskussion) 20:34, 12. Sep. 2016 (CEST)
• Der Vorschlag ist auf jeden Fall besser als das was wir jetzt haben. Die Referenzierung ref refines=Pierson gefällt mir gut: Es werden die Einzelnachweise zu dem vorher erstellten Referenz eingruppiert. Was mir nicht gefällt ist die umständliche und feheranfällige händische Referenzierung auf die gleichen Seiten ref refines=Pierson name=Pierson131>S. 131. Warum muss der Autor das händisch machen? Kann die Maschine das nicht selber machen und die Einträge bei denen S. 131f. steht zusammenfassen. Also so wie Sinuhe20 es auch beschrieben hat?--Avron (Diskussion) 20:34, 12. Sep. 2016 (CEST)

Hallo Avron, mit der Frage, ob gleiche Seitenzahlen automatisch zusammen gefügt werden sollten, haben wir uns auch schon beschäftigt. Letztendlich haben wir aber beschlossen, das als eine gesonderte Funktionalität anzusehen - wenn eine "normale" Quelle doppelt referenziert wird, wird sie ja bisher auch nicht automatisch nur einmal angezeigt. Deswegen habe ich beim Beispiel zunächst die bisher gängige Methode verwendet. Trotzdem wäre es natürlich möglich, zusätzlich zur hier besprochenen refines-Funktionalität auch über die Umsetzung einer "Zusammenfassungsfunktionalität" nachzudenken. Viele Grüße, Lea Voget (WMDE) (Diskussion) 11:47, 13. Sep. 2016 (CEST)

• Bin ziemlich gespalten - in erster Linie geht es mir wie Markus und ich sehe hier eine weitere Form der Abschreckung durch komplexe und immer weniger sinnvoll bearbeitbare Quelltexte - zumal die meisten ihre Referenzen auch innerhalb des Fließtextes integrieren und damit der Quelltext bereits jetzt in stark referenzierten Texten kaum mehr les- und bearbeitbar ist. Hinzu kommt, dass ich in meinen Arbeitsbereichen und im größten Teil der Naturwissenschaften, in denen sehr selten an Monologien entlang und vielmehr mit Papern und knapperen Texten gearbeitet wird, keine Notwendigkeit für eine solche Auftrennung existiert und ich sie eher als störend empfinden würde. Anders sieht dies bei Biografien und vielen geistes- und kulturwissenschaftlichen Themen aus, bei denen die Nutzung viel-seitiger Monografien und Aufsätzen die Regel ist - hier könnte eine solche Form sinnvoll sein. Was ich mit ziemlicher Sicherheit erwarte und befürchte, ist ein weiterer Formalistenstreit zwischen Befürwortern und Ablehnern der neuen Form. All in all würde ich persönlich lieber bei der aktuellen Form bleiben oder gar zu einer noch weiter vereinfachten Form der Belegstruktur tendieren, stelle mich dieser Entwicklung jedoch auch nicht in den Weg, solang sie als Alternative betrachtet und entsprechend vorsichtig eingesetzt wird. -- Achim Raschka (Diskussion) 21:41, 12. Sep. 2016 (CEST)

  @Achim Raschka: Ich sehe nicht, wie das die Quelltextlesbarkeit verschlechtern würde. Im Gegenteil: Dadurch würden die "Referenzen auch innerhalb des Fließtextes" kürzer werden, weil nur noch die Angaben der Kapitel mitten im Absatz stehen, statt dass der Absatz mehrmals durch die komplette Angabe unterbrochen wird. Bei Auslagerung der Einzelnachweisdefinition in den Einzelnachweisabschnitt würde sich im Fließtextquelltext beim umseitigen Vorschlag nichts ändern; Und zwar ganz wörtlich nichts: Bei einer Umstellung von genauen Einzelnachweisen, die im EN-Abschnitt definiert sind, zu der umseitig vorgeschlagenen Syntax würde man nur den Quelltext des EN-Abschnitts ändern. Beim unten von @Mabschaaf gemachten Vorschlag wäre das anders, aber den gab's noch nicht, als du das geschrieben hast :-) --nenntmichruhigip (Diskussion) 18:10, 14. Sep. 2016 (CEST)

  @Nenntmichruhigip: Ob im Fließtext oder im EN-Abschnitt die vollständige Definition eines Verweises stattfindet, ist unerheblich. Beides ist möglich - wie auch schon jetzt. Mit einer Ausnahme: Soll das Werk selbst (ohne verfeinernden Zusatz) nicht zitiert werden (also nirgendwo im Text als ^[17] auftauchen), dann darf die Definition erst im <references>-Abschnitt erfolgen. Dahingehend unterschieden sich der Vorschlag vorne und meiner überhaupt nicht.--Mabschaaf 18:39, 14. Sep. 2016 (CEST)

  Der Unterschied ist, dass die Verwendung des im EN-Abschnitt definierten genauen EN beim umseitigen Vorschlag (wie bisher auch) z.B. <ref name="Buch-3"/> und bei deinem Vorschlag <ref name="Buch" detail="3"/> lauten würde. Wenn man also im Artikel Baugleis die "Forstmeyer"-Einzelnachweise zu deinem Vorschlag ändern würde, müsste man auch außerhalb des Abschnitts „Einzelnachweise“ etwas ändern. Das könnte mEn dazu führen, dass dein Vorschlag nicht so gut akzeptiert würde wie der umseitige. --nenntmichruhigip (Diskussion) 19:39, 14. Sep. 2016 (CEST)

• Endlich! Die Unmöglichkeit, Seitenzahlen im Nachweis einafch zu ändern ist der einzige Nachteil, den der VE noch gegenüber der Quelltextbearbeitung hat. Es ist nervig, entweder zwischendrin wechseln zu müssen oder den Nachweis noch mal ganz neu anzulegen. Das Problem zu lösen, wäre ein großer Schritt für die Wikipediaheit und ein noch größerer für den Visual Editor! -- southpark 22:24, 12. Sep. 2016 (CEST)
• Wie Marcus: Eine weitere unötige technische Verkomplizierung des Belegapparates. Das macht die Mitarbeit für Neu- und Altautoren noch schwieriger. Ich sehe überhaupt kein Problem darin, immer das gesamte Werk anzugeben. --Otberg (Diskussion) 22:32, 12. Sep. 2016 (CEST)
• Sehr gut. Auf so etwas warte ich schon lange. Ich habe in letzter Zeit immer notgedrungen diese hässliche Vorlage:Rp genutzt und kann es kaum erwarten, das auszutauschen. Ich finde es auch keineswegs kompliziert. --Rodomonte (Diskussion) 22:34, 12. Sep. 2016 (CEST)
• Super!--XanonymusX (Diskussion) 23:17, 12. Sep. 2016 (CEST)
• Ja unbedingt! Das Feature ist so essentiell, die "Verkomplizierung des Belegapparates" nehme ich dafür gerne in Kauf, zumal die bestehenden Alternativen (gruppierung der Einzelnachweise mit manuell angepassten Nummern, Vorlage:Rp, das Beispiel Physik des Segelns...) noch viel komplizierter sind.--Debenben (Diskussion) 23:55, 12. Sep. 2016 (CEST)
• Gefällt mir ausgezeichnet. Ist optional (also keine Schwelle für Neuautoren) und extrem flexibel anwendbar, ohne ein template aufzuzwingen. Genau so etwas hatte ich mir erhofft.--Meloe (Diskussion) 08:07, 13. Sep. 2016 (CEST)
• Eine kompliziertere Syntax (die eben nicht optional ist, wenn man bestehende Artikel bearbeitet, in denen sie verwendet wird) sollte nur zusammen mit Hilfsmitteln (in diesem Fall Funktionen im VE) implementiert werden, die die Arbeit damit wieder vereinfachen. --Schnark 09:54, 13. Sep. 2016 (CEST)
• Ich arbeite seit vielen Jahren mit der bisher bewährten Methode und würde überhaupt nichts ändern. Eine solche Veränderung ist in meinen Augen nur neues Wasser auf die Mühlen von Pseudo-Lektoren, die damit ihre Edit-Konto verbessern und noch mehr bewährte Autoren vergraulen, weil diese angeblich alles falsch machen. Wenn, dann müßte eine solche Änderung eine "Kann"-Änderung bleiben, die nicht wieder Geschwader von Besserwissern lostritt. Ansonsten votiere ich wie Marcus Cyron und Achim Raschka. Mediatus 11:19, 13. Sep. 2016 (CEST)
• Ist etwas anders als ich's mir vorgestellt habe, aber so scheint es mir besser zu sein :-) Die hier teilweise geäusserten Sorgen, dass der Quelltext damit zu kompliziert würde teile ich nicht. Momentan sehe ich oft beschwerden, dass die Einzelnachweise zu sehr vom übrigen Quelltext ablenkend seien, und dass das nach einer Auslagerung, wie sie mit der vorgeschlagenen Erweiterung noch einfacher möglich wäre, besser würde. Bei passend gewählten Bezeichnern (was wie auch bisher schon Aufgabe des Wiki-Autors ist) ist die Syntax auch ebenso selbsterklärend wie die bisherige. @Otberg: Es gibt Artikel, deren Quelltext mit dieser Erweiterung mehr als 32000 Zeichen kürzer wäre. Da ist es schon recht störend, wenn da immer die Langform steht. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)

  Aber viele Autoren möchten auch im Quelltext immer gleich sehen, welches Werk da als Beleg steht und nicht mehrmals klicken um es anderswo zu finden. --Otberg (Diskussion) 13:08, 13. Sep. 2016 (CEST)

  Die lassen sich auch jetzt schon einfach ärgern, indem man die Einzelnachweise im Einzelnachweisabschnitt definiert. Oder einfach einen benannten Einzelnachweis aus einem anderen Abschnitt nutzt. Ja, mich nervt das auch, wenn ich erst einen anderen Abschnitt aufrufen muss, um einen Einzelnachweis anzupassen :-)

  Aber das ist mEn bei der hier vorgeschlagenen Erweiterung nicht anders als bisher. Wer's unbedingt kurz haben will nutzt eben Hacks wie Vorlage:Rp oder gibt die Einzelnachweise nicht so genau an.

  Und mit dem Wunsch von auch-vielen Autoren nach kompaktem Quelltext ist der Wunsch danach, dass die EN möglichst überall im Haupttextquelltext voll ausgeschrieben stehen, nicht vereinbar. Einen der beiden oft genannten Nachteile der Existenz von Einzelnachweisen muss man also akzeptieren. Oder man nutzt ein Bearbeitungsprogramm, das auch anderswo definierte Einzelnachweise bearbeiten kann. Hab gehört, der VE könne das, aber der ist mir zu umständlich um es auszuprobieren. --nenntmichruhigip (Diskussion) 13:24, 13. Sep. 2016 (CEST)

Außerdem muss ich dann als Leser, ebenso wie als Autor, nicht mehr diese unsäglichen a.a.O. oder l.c.-Nachweise lesen, die die Schnitzeljagd erst so richtig lustig machen.--Meloe (Diskussion) 13:31, 13. Sep. 2016 (CEST)

• Klare und optionale Verbesserung. --Holmium (d) 08:13, 14. Sep. 2016 (CEST)
• Dito: löst das Problem, einfach zu bedienen, kann so kommen (gerne auch ohne den VisualEditor, benutze ich eh kaum, bin da altmodisch).--Mager (Diskussion) 09:33, 14. Sep. 2016 (CEST)
• Super. Machen! --Flominator 10:01, 14. Sep. 2016 (CEST)
• Gute Sache, bitte bereitstellen. --Toni am See (Diskussion) 12:25, 14. Sep. 2016 (CEST)
• Ich teile die Bedenken von Marcus Cyron und Achim Raschka.--Zweioeltanks (Diskussion) 16:01, 14. Sep. 2016 (CEST)
• Finde den Vorschlag gut, bitte schnellstmöglich in den Wikicode intergieren. Allerdings sollte der Einsatz dieser Syntax eine Kann-Bestimmung werden. Wer nicht mag, kann oder will, sollte imho nicht zu zur Verwendung gezwungen werden. -- Gruß  Sir Gawain Disk. 17:58, 14. Sep. 2016 (CEST)
• Wie Marcus Cyron und Otberg. @Achim Raschka: Die Erfahrung zeigt gerade bei der Gruppierung von Fußnoten, dass neue technische Features eben nicht behutsam eingesetzt werden, sondern im großen Stil (und dann zu Dingen wie zwei Fußnotenabschnitten oder fünf Arten von Fußnoten im selben Artikel führen, die außer dem Verursacher kaum jemand nachvollziehen kann). -- Carbidfischer Kaffee? 18:03, 14. Sep. 2016 (CEST)
• Ich sehe es als Verbesserung und bin dafür. Die Optionalität ist zwar eher theoretischer Natur (sobald man auf einen Artikel stößt, wo diese Syntax verwendet wird, muss man sich damit ja auseinandersetzen). Aber ich finde nicht, dass das System dadurch viel komplizierter wird.--Berita (Diskussion) 18:44, 14. Sep. 2016 (CEST)
• Klare Verbesserung und weniger Quelltext zerstörend als Vorlage:Cite web und Konsorten. --Mauerquadrant (Diskussion) 22:24, 16. Sep. 2016 (CEST)
• Ich find das super --Distelfinck (Diskussion) 15:17, 17. Sep. 2016 (CEST)
• sinnvolle Lösung, die auch vielfältige Möglichkeiten beim Export bietet.--Cirdan ± 16:01, 17. Sep. 2016 (CEST)
• Sehr praktikabel, ich finds gut Graf Umarov (Diskussion) 18:14, 17. Sep. 2016 (CEST)
• Deutlich besser als die {{Rp|xx}}-Lösung. Es löst keines der anderen hier angesprochenen Probleme. Das ist auch nicht verwunderlich, denn das sollte es von Anfang an nicht. Allerdings hätte ich nicht erwartet, eine Dummheit wie "Einzelnachweiswahn" (Marcus Cyron vom 12. September) in diesem Kontext zu lesen. Das hätte ich in einem Witz von Radio Eriwan erwartet (F: „Genosse Administrator, stimmt es, dass in Artikeln ohne Beleg auch die Wahrheit stehen kann?“ A:„Im Prinzip ja, aber google zur Sicherheit eine reputablere Quelle.“) Wann hast du die Idee der Wikipedia aufgegeben, Marcus? Yotwen (Diskussion) 07:39, 18. Sep. 2016 (CEST)
• Würde die Einführung dieses Features begrüßen. --Gretarsson (Diskussion) 00:37, 19. Sep. 2016 (CEST)
• eine Verkomplizierung und eher abzulehnen. Bereits die name-Syntax ist oft nicht mehr durchschaubar (siehe auch die Stellungnahme von Carbidfischer) --Hajo-Muc (Diskussion) 02:07, 19. Sep. 2016 (CEST)
• Wie Marcus Cyron, Otberg und Mediatus. Die Funktion muss zwar keiner nutzen, der sie nicht will - das klingt ja erstmal gut. Aber wie vielleicht bekannt ist, gehört ein Wikipedia-Artikel nicht seinem Hauptautor, auch wenn das manche gerne hätten. Auch der Artikel eines technisch unglaublich versierten Wikipedianers, der den Text mit allen Raffinessen der Wiki-Syntax ausstatten möchte, sollte danach noch so aussehen, dass ein Universitätsprofessor, der sich auf das Thema spezialisiert hat, aber von Computern kaum Ahnung hat, seine Ergänzungen einbringen kann, ohne vollends zu verzweifeln. Ich habe im Mentorenprogramm und Uniprojekten zu viel mit Neuautoren (die WMDE ja so dringend haben möchte) zu tun, um diese Funktion zu unterstützen. Die eine Hälfte der Neuautoren sieht sich bereits existierende Artikel an, um technische Anregungen für ihre eigene Neuanlage zu finden, und ist von den überall unterschiedlichen Vorgehensweisen und Techniken total verwirrt. Die andere Hälfte möchte einen bestehenden Beitrag überarbeiten und stößt dabei auf persönliche Vorlieben des Erstautors, die sich sonst in kaum einem Artikel finden und mit denen sie erst einmal klarkommen muss. Beides eine Katastrophe, jetzt schon, und mit der neuen Funktion noch viel mehr. Die Richtlinien besagen übrigens, dass jedes Werk bei jeder Nennung in einem Einzelnachweis komplett zitiert wird, und wer eine klare regelkonforme Vorgehensweise will, hält sich daran. --DerMaxdorfer (Diskussion \ Bewertung) 11:49, 20. Sep. 2016 (CEST)

  @DerMaxdorfer: Die Richtlinien die du da meinst sind so, weil diese Funktion bisher eben noch nicht existiert, und damit ein wie auch immer aussehender Bezug auf eine woanders stehende Langangabe versehentlich fehlerhaft werden kann. Mit der hier vorgeschlagenen Funktion würde sowas automatisch eine Fehlermeldung erzeugen, und es gäbe ein klar vorgegebenes Verfahren für diese Verkürzungen (gegenüber momentan vielen verschiedenen Varianten, die trotz der anderslautenden Regelung verwendet werden). Die von dir genannte Vorgabe würde nach Umsetzung dieses Vorschlags natürlich daran angepasst werden, weil der Grund dafür damit wedfallen würde. Der Artikelquelltext wurde ausserdem kürzer werden, was (weil die langen Einzelnachweistexte alles so unübersichtlich machen) oft gerade von weniger erfahrenen Autoren gewünscht wird. --nenntmichruhigip (Diskussion) 18:52, 20. Sep. 2016 (CEST)

  @Nenntmichruhigip: Mit den Richtlinien hast du natürlich recht, die sind kein Grund, etwas nicht zu ändern (Gleichwohl werden sie unübersichtlicher, wenn es mehr verschiedene Möglichkeiten der Artikelgestaltung gibt). Widersprechen möchte ich dir aber bei der Einschätzung der Folgen für weniger erfahrene Autoren (die man bei einer solchen Sache nur schwer praktikabel fragen kann): Ich habe den Eindruck, dass die Bytezahl des Quelltexts bzw. die Länge der Einzelnachweise kein Problem für Neuautoren ist, sondern eher die Vielfalt des Quellcodes und die zahlreichen Befehle, Vorlagen und Parameter. Das sieht man schon an folgendem Phänomen: Während sich langjährige Mitarbeiter meist an die Richtlinie halten, dass jeder Einzelnachweis nur ein Werk beinhalten soll, und dafür massenweise </ref> an <ref> hängen, neigen neue Autoren dazu, auch mehrere Angaben (teils mit ausführlichem Kommentar) in eine Fußnote zu packen. Noch einmal: Die Mitarbeit in der Wikipedia soll technisch so einfach und niedrigschwellig wie möglich sein. Was passiert, wenn sich eine Autoren-Community zwischen Richtlinien und technischem Schnickschnack einkapselt, hat man in den letzten Jahren am Mitarbeiterschwund gesehen. Liebe Grüße, DerMaxdorfer (Diskussion \ Bewertung) 19:11, 20. Sep. 2016 (CEST)

  Mit der Beschreibung dieses Effekts hat Kollege DerMaxdorfer recht: Die Zugangsschwelle für Neuautoren wird weiter erhöht. Allerdings betrachte ich das nicht als einen Grund, eine technische Verbesserung abzulehnen, denn sonst müsste ich mir ja auch Gedanken machen, welche früheren Neuerungen abgeschafft werden müssten, um Neuautoren das Leben leichter zu machen. Der REFA-Verband hat eine Maxime für solche Fälle:"Anpassung der Arbeit an den Menschen und des Menschen an die Arbeit." Die vorgeschlagene Möglichkeit erfüllt viele Kriterien des ersten. Und eine verbesserte Ausbildung von Neu- und Altautoren, beispielsweise durch Einzelnachweistutorials auf der Spielwiese könnten Wissens- und Verständnismängel der Autoren beheben helfen (und diese an die Arbeit anpassen). Nur hat sich dafür noch niemand begeistern können. Wir verlassen uns noch immer auf die Intelligenz des Einzelnen, statt die Fähigkeiten der Gruppe zu vervielfältigen. Yotwen (Diskussion) 03:29, 21. Sep. 2016 (CEST)

  Bin mir bei deiner Antwort nich so sicher, dass ob du mein Quelltextlänge-Argument richtig verstanden hast: Ich meinte sowas wie Ein Satz, egal wie lang.<ref>Zeilenlanger auf eine Seite verweisender Einzelnachweisquelltext</ref> Kurzer Satz.<ref>Zeilenlanger auf eine andere Seite verweisender Einzelnachweisquelltext</ref> Ups, wo ist der kurze Satz im Quelltext, der doch im Artikel steht? Der Absatz endet jedenfalls hier.. Klar, das kann man auch vermeiden, indem man die Einzelnachweise alle in den EN-Abschnitt auslagert. Da stört das wenigstens nur noch, wenn man was am EN ändern will, z.B. eine Archivversion zu einem Weblink ergänzen. Zum Rest stimme ich Yotwens Beitrag zu, auch dessen erstem Satz. --nenntmichruhigip (Diskussion) 16:26, 21. Sep. 2016 (CEST)

• Vieleicht ist es ja die Straße, die das Verkehrschaos löst. - Sie wird besser, bequemmer und wartugsärmer. Aber ist sie gut für die Stadt?. Im Grunde sehe ich das so wie Markus. Und um im Bilde zu bleiben: Wer Straßen baut wird Verkehr ernten. Die Fuhktion mag eine Verbesserung darstellen, doch stellt es die Weichen mM nach nur konsequenter in die falsche Richtung. --Aineias © 19:42, 20. Sep. 2016 (CEST)
• manche Artikel strotzen ja nur so von (mMn oft sinnfreien) ENs, besonders wenn andauernd aus demselben Buch zitiert wird. Da wäre weniger oft sinnvoll(er). Ansonsten großes +1 für den Vorschlag, macht es definitiv einfacher.

zur Übersicht im Bearbeitungsmodus wurde ein neuer einfacher Zeilenumbruch nach jedem </ref> schon mal helfen ;-). lG --Hannes 24 (Diskussion) 20:11, 21. Sep. 2016 (CEST)

• Sinnvolle Erweiterung. Wer sie nicht nutzen möchte, kann so arbeiten wie bisher. --Asdert (Diskussion) 09:35, 22. Sep. 2016 (CEST)

Das müsste bei der Umsetzung beachtet werden

• Wichtig ist, dass das Basis ref in die vollständige Referenz zur Quelle liegt gut erkennbar ist, und bei entfernen eine entsprechend deutliche Fehlermeldung hinterlässt. — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
• Wenn wie im Beispiel auf ein Subref der ein zweiter Name vergeben wird <ref refines="Pearson" name="Pearson131">Seite 131</ref> muss sichergestellt werden, dass sich dieser zweite name nicht an anderer Stelle schon für anderer Zwecke verwendet wird. Falls das der Fall ist sollte mindestens eine Warnung geworfen werden. Frohes Schaffen — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
  • Ich würde erwaten, dass diese beiden Punkte ebenso wie bei der bisherigen Mehrfachreferenzierung gelöst werden. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)
• Da in der Regel Bücher mit mehreren Referenzierungen genutzt werden, wäre es schon, wenn man z.B. über die ISBN dieses automatisch als Top-Referenz ausgeben könnte! axp_de^Hallo! 19:51, 12. Sep. 2016 (CEST)
  1. Ich möchte dringend anregen, dass ein <ref refines="...">...</ref> ohne gleichzeitige Angabe des zugehörigen name="..." zu einer Fehlermeldung führt, also nur vollständige Angaben mit beiden (wie nennt man das?) Qualifiern <ref name="..." refines="...">...</ref> gültig sind. Hintergrund: Ich kann mir sehr gut vorstellen, dass die refines="..."-Angaben häufig wie vorne ausschließlich für Seitenzahlen genutzt werden und vermutlich mit refines="Seite23" benannt; werden jedoch mehrere Werke auf Seitenzahlen aufgeteilt, ist im Quelltext nicht mehr spontan ersichtlich, auf welches ref name= sich das refines= bezieht.
  2. Die Verwendung „falscher“ oder gar keiner Anführungszeichen könnte in ähnlicher Weise zu Problemen führen wie bis kürzlich noch bei den <ref name=...>-Angaben. Hier also bitte sehr klar festlegen, was gültige Begrenzer für die beiden Namen sind: "„“'“”? Im Mockup wurde darauf gänzlich verzichtet - dann sollte die Verwendung von = außerhalb der korrekten Syntax nicht zulässig sein. --Mabschaaf 20:31, 12. Sep. 2016 (CEST)

  Hallo Mabschaaf, soweit ich verstehe, funktioniert refine anders: Du legst einmal das Buch mit ref name=GanzTollesWerk an, anschließend verweist du mit ref refine=GanzTollesWerk darauf. Es sollte also keine Missverständnisse geben, solange wie bisher name sinnvoll gewählt ist.--Cirdan ± 00:18, 13. Sep. 2016 (CEST)

  Hi Cirdan, ich habe es mir jetzt noch mal genau angeschaut, offenbar hatte ich das tatsächlich falsch verstanden, einfach weil ich es anders gelöst hätte. Für mich sollte das Werk (also die ausführliche Literaturangabe) wie gehabt mit <ref name="book1">Autor: Titel. Verlag, Ort, Jahr.</ref> angegeben werden. Wird darauf mit einem weiteren Verweis einschließlich Detailangabe verwiesen, wäre das <ref name="book1" detail="page13">Seite 13.</ref>.

  Weitere Zitate der gleichen Stellen wären dann <ref name="book1" /> (ohne exakte Angabe) oder <ref name="book1" detail="page13" /> mit exakter Seite. Damit sind die hier vielfach angesprochenen mehrfachen Verwendungen gleicher Detailangaben gelöst.

  Die Angabe von <ref detail="page13" /> wäre ungültig: kein detail= ohne Angabe von name=

  So bleibt die Möglichkeit offen, in einem anderen Werk ebenfalls Seite 13 zu zitieren mit <ref name="script2">Autor: Titel. Sammelband.</ref> und <ref name="script2" detail="page13">Seite 13.</ref>

  Das halte ich für syntaktisch deutlich einfacher als den Vorschlag vorne.--Mabschaaf 01:09, 13. Sep. 2016 (CEST)

• Bitte überprüfen ob die gleichen Seitenagaben auch automatisch zusammengefasst werden können.--Avron (Diskussion) 20:35, 12. Sep. 2016 (CEST)
• Die technische Darstellung von Einzelnachweisen befindet sich im Umbruch, siehe phab:T104927 und verwandte Tasks. Damit muss die Implementierung klarkommen. --Schnark 09:58, 13. Sep. 2016 (CEST)
• Es ist völlig unklar, wohin gesprungen werden soll, wenn man die Fußnote anklickt. Vermutlich kommt man direkt zum Untereintrag. Dann sieht man aber erst einmal nur die Seitenzahl, weil die eigentliche Literaturangabe sich oberhalb und damit außerhalb des Bildschirmfensters befindet. Man müsste also erst einmal hochscrollen um die vollständige Angabe lesen zu können. Da sollte eine benutzerfreundliche Lösung gefunden werden. --Schnark 11:23, 13. Sep. 2016 (CEST)
  • Andererseits wäre bei vielen verschiedenen verfeinerten Einzelnachweisen eines Obereinzelnachweises ein Springen auf den Obereinzelnachweis auch nicht so toll, weil dann ggf der verfeinerte EN nicht sichtbar ist. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)
• Es wäre zu beachten, wie sich die Erweiterung bei sowas wie <ref name="Buchtitel">Ich bin ein Buch</ref> <ref refines="Buchtitel" name="Buchtitel-42">Kapitel 42</ref> <ref refines="Buchtitel-42">Absatz 3</ref> (also Unterverfeinerung eines verfeinerten Einzelnachweises) verhalten würde. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)
• So, wie die Vorschau von Einzelnachweisen beim Bearbeiten von Abschnitten im Augenblick implementiert ist, rechne ich damit, dass verfeinerte Einzelnachweise dabei in den meisten Fällen nicht in der Vorschau dargestellt werden könnten. Das empfände ich als Rückschritt, sodass gleichzeitig an der Vorschau-Funktion nachgebessert werden sollte. --Schnark 09:07, 15. Sep. 2016 (CEST)
• Das Zusammenspiel mit den Popup-Anzeigen (Gadgets NavPopups und RefenreceTooltips) sollte funktionieren. Hierbei sollten die Einzelnachweise in Langform angezeigt werden. --nenntmichruhigip (Diskussion) 16:50, 22. Mär. 2017 (CET)
• ...

Sollte dieser Lösungsvorschlag auch umgesetzt werden, wenn noch nicht klar ist, ob dies auch in den VisualEditor integriert werden würde?

• ja, viele der komplizierteren Strukturen wird man wohl auf lange Zeit besser im Quellcode editieren.  Frohes Schaffen — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
• +1 -- Karl432 (Diskussion) 19:27, 12. Sep. 2016 (CEST)
• Klar. -- Perrak (Disk) 19:29, 12. Sep. 2016 (CEST)
• Aber sowas von! (Was ist ein Visual Editor?) axp_de^Hallo! 19:51, 12. Sep. 2016 (CEST)
• Ja, natürlich!--Mabschaaf 20:31, 12. Sep. 2016 (CEST)
• Von mir aus auf jeden Fall. --Reinhard Müller (Diskussion) 20:34, 12. Sep. 2016 (CEST)
• Ja. Ich vermute das diese kompliziertere Form sowieso nur von WP-Experten die länger schon dabei sind eingesetzt werden.Rjh (Diskussion) 22:05, 12. Sep. 2016 (CEST)
• Unbedingt --Rodomonte (Diskussion) 22:34, 12. Sep. 2016 (CEST)
• Keine Frage.--XanonymusX (Diskussion) 23:17, 12. Sep. 2016 (CEST)
• Ja.--Debenben (Diskussion) 23:58, 12. Sep. 2016 (CEST)
• Ja, unbedingt.--Meloe (Diskussion) 08:07, 13. Sep. 2016 (CEST)
• Nein, der VE ist der primäre Editor für neue und unangemeldete Benutzer. Es dort nicht zur Verfügung zu stellen, wäre in etwa so sinnvoll, als würde Microsoft eine neue Funktion für Windows programmieren und sie nur durch ein Kommandozeilentool zur Verfügung stellen. --Schnark 10:02, 13. Sep. 2016 (CEST) PS: Nach einem kurzen Blick auf den Code, vor allem ve.ui.MWReferenceDialog.js: So komplex ist der nun wirklich nicht, insbesondere da durch die Bearbeitbarkeit von Einzelnachweis-Gruppen und der Wiederverwenbarkeit von vorhandenen Einzelnachweisen eigentlich aller Code schon da ist und nur noch korrekt zusammengestellt werden müsste. Wenn man sich bei WMDE nicht zutraut, die Funktion im VE zu implementieren, dann traue ich den verantwortlichen Programmierern ehrlich gesagt nicht zu, die Funktion überhaupt implementieren zu können. --Schnark 09:12, 15. Sep. 2016 (CEST)

Schnark, Hintergrund der Frage ist nicht die "technische Schwierigkeit", sondern die noch ausstehende notwendige Koordinierungsarbeit mit dem Visual Editor Team. Solange noch nicht klar ist, ob der Vorschlag hier überhaupt in Frage kommt, macht es keinen Sinn, sich dazu bereits mit dem VE Team abzustimmen. --Birgit Müller (WMDE) (Diskussion) 13:58, 15. Sep. 2016 (CEST)

Die hier vorgeschlagene Änderung muss (auch) in Parsoid umgesetzt werden, und durch die Verzahnung von Parsoid und VE wird euch kaum etwas anderes übrig bleiben, als die Änderungen auch mit dem VE-Team abzustimmen, unabhängig davon, ob ihr die Funktionen zum Bearbeiten direkt mitimplementiert oder nicht. --Schnark 09:05, 16. Sep. 2016 (CEST)

Ist klar :). Trotzdem spielt eine Implementierung der Funktion in den VE nochmal in einer anderen Absprache-Liga. VG, --Birgit Müller (WMDE) (Diskussion) 10:34, 16. Sep. 2016 (CEST)

• Ja. Imo ist der VE nur ein Bearbeitungsprogramm von "vielen" möglichen. Da wäre es diskriminierend, darauf zu warten, dass das im VE komfortabler möglich ist, aber bei einem theoretischen anderen Bearbeitungsprogramm nicht. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)
• Ja. Der VE wird ohnehin nie das Editieren des Quelltextes vollständig ersetzen können. Das Feature zurückzuhalten weil der VE es nicht kann wäre in etwa so sinnvoll als würde Microsoft ein Feature für Windows 10 nicht freigeben weil die gleiche Funktion für Windows 7 noch nicht fertig ist. Mit dem Unterschied, dass jeder zum Quelltext wechseln kann. --mfb (Diskussion) 22:36, 13. Sep. 2016 (CEST)
• Ja, sicher. --Holmium (d) 08:12, 14. Sep. 2016 (CEST)
• Dito. --Flominator 10:01, 14. Sep. 2016 (CEST)
• Ja, auf jeden Fall. --Toni am See (Diskussion) 12:25, 14. Sep. 2016 (CEST)
• Ja, neue und unangemeldete Benutzer hantieren sehr selten mit Einzelnachweisen auf Werke mit mehreren Seiten--Avron (Diskussion) 17:34, 14. Sep. 2016 (CEST)
• Ja natürlich. Sehe keinen Grund, warum der Benutzergruppe, die den traditionellen Editor nutzt, diese Möglichkeit nicht gegeben werden sollte. Nur weil die andere Benutzergruppe es (noch) nicht kann, ist für mich zumindest keiner. -- Gruß  Sir Gawain Disk. 18:01, 14. Sep. 2016 (CEST)
• Ich nutze den VE nicht und es wäre schon schön, wenn man nicht auf die dortige Umsetzung warten würde. Aber warum darüber überhaupt diskutiert werden muss, dass das ganze mittelfristig auch im VE realisiert wird, verstehe ich nicht. Wie soll der VE je eine ernstzunehmende Alternative werden, wenn dort Grundfunktionalitäten wie das Belegen nicht oder nur teilweise umgesetzt sind?--Berita (Diskussion) 18:49, 14. Sep. 2016 (CEST)
• Bei allem Respekt, aber ein Feature für the chosen Few, die sich nicht umstellen mögen, ist nun echt Zeit- und Arbeitsverschwendung. Visual Editor ist nicht nur Standard sondern auch besser, Grundfunktionalitäten dort nicht vorzusehen, ist hochgradig retrograd. -- southpark 21:12, 15. Sep. 2016 (CEST)
• Eine Verbesserung zurückzuhalten weil der VE das noch nicht kann ist ein starkes Stück. Die Einführung kann ja von den VE-Programmierern als Ansporn verstanden werden die Funktionalität möglichst schnell bereit zu stellen. --Mauerquadrant (Diskussion) 22:30, 16. Sep. 2016 (CEST)
• Definitiv ja, weil er dann wohl schneller zur Verfügung steht und ich VE ohnehin nicht benutze. --Gretarsson (Diskussion) 00:40, 19. Sep. 2016 (CEST)
•  Ja, hier sieht man mal wieder die klaren Grenzen des VE und warum der QTE in jedem Fall der Haupteditor bleiben muss. --Morten Haan 🎲 Wikipedia ist für Leser da • Skin-Entwurf 18:03, 19. Sep. 2016 (CEST)
•  Ja --Hannes 24 (Diskussion) 20:13, 21. Sep. 2016 (CEST)
• Ja. --Asdert (Diskussion) 09:36, 22. Sep. 2016 (CEST)
• +1, ja. --Christian140 (Diskussion) 09:44, 24. Okt. 2016 (CEST)

Weitere Anmerkungen

• I18N: Schön wäre es wenn am die Verfeinerung pro Wiki im MediWiki-Namensraum festlegen könnte. Frohes Schaffen — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
  • Verstehe ich das richtig, dass du je nach Sprache einen anderen Begriff für "refines" haben möchtest? Bitte nicht, ich finde es jetzt schon schrecklich, dass die deutschsprachigen Literaturvorlagen mit den anderen Sprachversionen inkompatibel sind. Jetzt soll ich auch noch für jede Sprachversion eine andere Wiki-syntax lernen müssen?--Debenben (Diskussion) 00:04, 13. Sep. 2016 (CEST)
    • Ebenso. "ref" und beispielsweise "gallery" können auch nicht übersetzt werden. Wenn, dann sollte das für solche Syntaxelemente auch kommen, und das wäre mEn eine grössere Umstellung, die (wenn überhaupt, imo lieber nicht) unabhängig von der EN-Erweiterung erfolgen sollte. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)
      • Ich meinte eigentlich die Aufzählungselemente, sodass 1.a 1.b usw möglich wird. Frohes Schaffen — Boshomi ⌨   00:04, 14. Sep. 2016 (CEST)
• Im Mockup erscheint mit das Vorhandensein des ↑ vor der Langversion des Einzelnachweises fehlerhaft: Es gibt hierfür kein Sprungziel.--Mabschaaf 20:31, 12. Sep. 2016 (CEST)
• Mir gefällt refines als Wort nicht. Das ist zu dicht an ref und references dran und für nicht englischsprachige Nutzer schwer zu unterscheiden und zu lernen. Ich würde detail= oder exact= (die beide einigermaßen international sein dürften) vorziehen.--Mabschaaf 21:09, 12. Sep. 2016 (CEST)
• Ich stimme Mabschaaf zu. Ist das im Deutschen gebräuchliche ebenda nicht umsetzbar? Rjh (Diskussion) 22:07, 12. Sep. 2016 (CEST)

  Diese Tags sollen ja international sein und sind üblicherweise in Englisch und nicht in Deutsch, das wäre bei "ebenda" dann englisch "Ibid." Das versteht kaum noch jemand. Dann müsste man eher das Original nehmen, das wäre lateinisch ibidem, was aber auch unverständlicher ist und nicht zur englischsprachigen Programmierung passt. "detail=" wäre besser, das ist ein nicht flektiertes Substantiv, "refines" ist offenbar ein flektiertes Verb ("(es) verfeinert") und damit auch fehleranfällig, wenn man das "s" weglässt oder mit "ref" usw. verwechselt. Also besser "detail", das ist verständlicher und weniger fehleranfällig, "exact" wäre auch wieder kein Substantiv wie "name" und "references" und passt damit weniger gut. --Bjarlin 22:26, 12. Sep. 2016 (CEST)

  "detail" und "exact" klingt imo beides eher danach, als würde damit bezeichnet, wo es eine genauere Angabe gibt, statt wo die ungenauere Angabe steht. Die Bedenken zu "refines" teile ich jedoch ebenfalls. Und zu anderssprachigen habe ich ja oben schon geschrieben, dass ich Bjarlin zustimme. --nenntmichruhigip (Diskussion) 12:26, 13. Sep. 2016 (CEST)

  @Bjarlin: Ohne Doku kommt eh niemand auf die Idee das zu nutzen (oder findet raus das so was existiert). Deswegen wäre ich trotzdem dafür den Begriff Ibid. zu nehmen. Dann finden es wenigstens Lektoren und ähnliche Leute die sich damit auskennen. Rjh (Diskussion) 17:06, 13. Sep. 2016 (CEST)

  "Diese Tags sollen ja international sein und sind üblicherweise in Englisch" -> Ja, das ist einer der Gründe warum nicht englischsprachige Einsteiger so darüber fluchen. Allerdings kenne ich auch keine bessere Lösung (wie jeder der Excel VBA-Script mal Deutsch ausprobieren durfte weiß ;)) ). Rjh (Diskussion) 17:08, 13. Sep. 2016 (CEST)

  @Nenntmichruhigip: Das war genau das Missverständnis. Die korrekte Hierarchie wäre in meinen Augen <ref group="..."> für die groben Gruppen wie "Anmerkungen", "Einzelnachweise"; <ref name="..."> für einzelne Werke ("Buch 1", "Aufsatz X", ...); <ref detail="..."> für Detailangaben ("Seite 12", "Abschnitt Dorfgeschichte", ...).

  Die neue Ebene würde also unten angefügt werden. Aktuell ist der Vorschlag aber, eine Zwischenebene einzuziehen zwischen "group" und "name". Das halte ich - gerade für die Autoren, die schon lange dabei sind und das bisherige System gut kennen - für deutlich schwerer nachvollziehbar als eine "noch feinere" Ebene unten anzufügen. --Mabschaaf 17:25, 13. Sep. 2016 (CEST)

  Wenn ich dich richtig verstanden habe sähe das mit deinem Vorschlag beispielsweise so aus: Erster ungenauer Satz.<ref name="Buch">Buchtitel</ref> Zweiter ungenauer Satz.<ref name="Buch"/> Erster genauer Satz.<ref name="Buch" detail="Kapitel3">Kapitel 3</ref> Zweiter genauer Satz.<ref name="Buch" detail="Kapitel3"/> Das würde mEn die Bedeutung des name-Attributs ändern, auch wenn das – sofern ich nichts vergessen habe – "nur" in der Dokumentation Auswirkungen hätte. Könnte sein, dass ich das besser finden würde, bin da noch unschlüssig. Einerseits wäre es zumindest teilweise einfacher verständlich, insbesondere wenn Unterverfeinerungen eh verhindert werden sollen. Andererseits würde damit bei Mehrfachnutzung verfeinerter EN der Quelltext länger werden, und es müsste zwingend ein Bezeichner für die Vergenauerung angegeben werden. --nenntmichruhigip (Diskussion) 17:51, 13. Sep. 2016 (CEST)

  Ja, exakt so war es gemeint, so ist es korrekt und schon im Quelltext leicht erkennbar, zu welchem Werk eine detaillierte Quellenangabe gehört. Letztlich wird sich das ja in Artikeln bunt mischen, z.B.

  Erster genauer Satz.<ref name="Buch" detail="Kapitel3">Kapitel 3</ref> Zweiter genauer Satz<ref name="AkteX" detail="Kapitel5" />, der jedoch bezweifelt wird<ref name="Buch" detail="Kapitel5">Kapitel 5</ref> und in der Diskussion steht.<ref name="Buch" detail="Kapitel3" />

  dennoch sind hier die Zuordnungen klar. Stelle Dir einfach mal vor, hier würde überall nur die Kapitel-Angabe stehen...--Mabschaaf 21:38, 13. Sep. 2016 (CEST)

  Kann man auch gleich mit detail anfangen ? Also wenn ich die erste Aussage auf Seite 5 finde, dann die nächste Aussage auf Seite 12, danach auf Seite 25 usw. Rjh (Diskussion) 22:00, 13. Sep. 2016 (CEST)

  Sowohl beim umseitigen refines-Vorschlag, wie auch bei Mabschaafs detail-Vorschlag: Ja, aber die grobe Angabe muss dann im Einzelnachweisabschnitt definiert werden. Falls ich dich jetzt nicht falsch verstanden habe :-) --nenntmichruhigip (Diskussion) 22:38, 13. Sep. 2016 (CEST)

  Ich stelle mal vor: Erster genauer Satz.<ref name="Buch-3" refines="Buch">Kapitel 3</ref> Zweiter genauer Satz<ref name="AkteX-5" />, der jedoch bezweifelt wird<ref refines="Buch">Kapitel 5</ref> und in der Diskussion steht.<ref name="Buch-3" />. Dabei würde man die name-Attribute für die Mehrfachverwendung genauso benennen, wie man es bisher bei den vollständig ausgeschriebenen Einzelnachweisen machen würde. P.S.: Versuch bitte nicht auf die Idee zu kommen, mich überzeugen zu wollen: Ich verstehe schon, was bei der von dir vorgeschlagenen Variante die Vorteile sind. Ich will mich nur noch nicht festlegen welche Variante ich besser fände, und die Vorteile beider Varianten zum Vergleich sichtbar haben :-) --nenntmichruhigip (Diskussion) 22:38, 13. Sep. 2016 (CEST)

  Du gestehst mir zu, dass ich Deine Variante unübersichtlicher finde ;-)? Dich muss ich auch nicht überzeugen, letztlich ist entscheidend, was das Entwicklerteam umsetzt. Dazu müssen wir unsere Ideen und Vorstellungen zumindest mal verständlich machen können...--Mabschaaf 22:56, 13. Sep. 2016 (CEST)

  Klar. Ich finde momentan je nach Stimmung mal das eine und mal das andere unübersichtlicher… :-D Für deinen letzten Satz schreibe ich das hier ja auch, wollte nur verhindern, dass wir uns deshalb unnötig streiten :-)--nenntmichruhigip (Diskussion) 13:30, 14. Sep. 2016 (CEST)

  Also um es mal ganz klar zu machen, was ich schon häufiger gebräucht hätte: Mal angenommen ich schreibe einen Artikel über Vögel und habe Brems Tierleben als Buch. Dann möchte ich den Satz "Vögel haben Federn" belegen mit "Brems Tierleben, Kapitel Vögel, Unterkapitel Einführung". Der Satz "Sie entwickelten sich aus den Sauriern" mit "Brems Tierleben, Kapitel Vögel, Unterkapitel Entwicklungsgeschichte" und den Satz "Basstölpel sind Meeresvögel und ausgezeichnete Schwimmer" mit "Brems Tierleben, Kapitel Vögel, Unterkapitel Arten, Unterunterkapitel Tölpel". Dieses ungenaue "irgendwo im Buch" hab ich noch nie gebraucht und ich hab dabei ein ganz schlechtes Gefühl (ich würde das nie direkt benutzen). Rjh (Diskussion) 08:54, 14. Sep. 2016 (CEST)

  Ich denke, hier sind zu viele Perfektionisten am Werk. Was spricht gegen <ref refines="Brehms Tierleben"> Kapitel 3.8.1, auf Seite 321. </ref>. Dabei muss ich den Kapitel-Teil mehrfach schreiben, auch wenn ich dasselbe Kap. mehr als einmal verwende. Aber um das durch Einschachteln weg zu kriegen, müsste die Syntax so kompliziert sein, dass es schwer umzusetzten, und noch schwerer, für spätere Bearbeiter, nachzuvollziehen wäre. Durch die vorgeschlagene Struktur wird mir der Titel (samt ISBN, DOI, PMID und allem anderen) abgenommen. Das ist doch erstmal Erleichterung genug.--Meloe (Diskussion) 09:37, 14. Sep. 2016 (CEST)

  Das mit dem "überall nur die Kapitel-Angabe stehen" von Mabschaaf hätte ich anders verstanden, nämlich dass er annahm, dass man die genauen EN für Mehrfachverwendung anders bezeichnen würde als bisher, beispielsweise Erster genauer Satz.<ref refines="Buch" name="Kapitel3">Kapitel 3</ref> Zweiter genauer Satz<ref refines="AkteX" name="Kapitel5" />, der jedoch bezweifelt wird<ref refines="Buch">Kapitel 5</ref> und in der Diskussion steht.<ref name="Kapitel3" />. Mit seinem Vorschlag wäre eine Verschachtelung ja gar nicht möglich. Die Syntax des umseitigen Vorschlags (die ich auch nicht "so kompliziert" finde) hingegen würde das theoretisch ermöglichen. @Rjh: Re "irgendwo im Buch": Geht mir ebenso, steht aber leider teilweise in Artikeln, weil jemand nicht jede Seite einzeln in Langform angeben wollte. In meinem obigen Beispiel würde die ungenaue Angabe natürlich besser im EN-Abschnitt definiert werden und der ungenaue Satz genauer belegt :-) --nenntmichruhigip (Diskussion) 13:30, 14. Sep. 2016 (CEST)

  Je nach Aufbau des Buches würde ich bei auch bei sowas diese eine Unterstufung für ausreichend halten. Dabei kann man ja – je nach Gestaltung des Buches und seiner sonstigen Nutzung im Artikel – als "Buch" gleich das Hauptkapitel (also bei deinem Beispiel "Vögel") angeben. Mag vielleicht manchmal schöner wirken, die Unterkapitel auch zusammenfassen zu können, aber das stelle ich mir sowohl beim Schreiben wie auch beim Quelltextlesen umständlicher vor.

  Mit Mabschaafs Vorschlag wäre direkt aus der Syntax heraus klar, dass eine solche Verschachtelung nicht möglich ist; Beim umseitigen Vorschlag wurde schon angeregt, dass sowas nicht möglich sein soll, obwohl die Syntax suggeriert, dass es möglich wäre. --nenntmichruhigip (Diskussion) 13:30, 14. Sep. 2016 (CEST)

• Es wäre gut, wenn man irgendwie Weblinks an unterschiedliche Seitenangaben anpassen könnte. Also beispielsweise bei PDF-Dokumenten Sprungmarkenn wie #page=42 oder bei Links auf Google Books den GET-Parameter pg (vgl auch Vorlage:Google Buch). --nenntmichruhigip (Diskussion) 18:29, 14. Sep. 2016 (CEST)
• Ich hatte vor einiger Zeit die Idee der „Referenzen-Parameter“: als Definition <ref name="Ref">[http://abc.xyz/{{{Seite_URL}}} Buch], S. {{{Seite}}}</ref> und dann im Aufruf = <ref name="Ref" param-Seite_URL="S01" param-Seite="1" />, wobei dann die Ausdrücke in den geschweiften Klammern der Ausgangsdefinition ersetzt werden – wollte ich nur mal loswerden. -- hgzh 18:19, 16. Sep. 2016 (CEST)
• Wieso eigentlich nur für Bücher? Was ist mit URLs wie https://heise.de/-3301400 wenn ich danach noch auf https://heise.de/-3248574 verlinken möchte wäre es doch schön das mit der Funktion zu machen wenn hinter her wieder anklickbare Links entstehen. --Mauerquadrant (Diskussion) 22:45, 16. Sep. 2016 (CEST)

Unterschiede/Beziehung zu group

Wenn das richtig verstehe ist das angestrebte doch bereits möglich mithilfe von "group". Insofern wüsste ich gerne was die Intention dieser Erneuerung ist. Lediglich eine Vereinfachung der Syntax? Oder welche Beziehungen und Unterschiede bestehen zur "group"-Variante?--Kmhkmh (Diskussion) 19:54, 12. Sep. 2016 (CEST)

Naja, bei der Gruppierung wird ja der Name der Gruppe im hochgestellten Text angegeben. Beim Vorschlag wird automatisch durchnummeriert (klar, könnte man mit Gruppen 1, 2, 3 usw. auch erreichen; hier wird aber wohl automatisch nummeriert, oder?). Grüße, —DerHexer (Disk., Bew.) 20:18, 12. Sep. 2016 (CEST)

Zudem wird durch refines eine eindeutige Beziehung hergestellt, während group für diverse Fälle Anwendung findet.--Cirdan ± 20:29, 12. Sep. 2016 (CEST)

Ich sehe es ähnlich wie Cirdan. Optisch kann mit group was ähnliches erreichen, aber mit dem Vorschlag ist es von der Struktur her sauberer und die Software weiss welche Einzelnachweise zu welchem Werk gehören. Damit könnte man sich noch einiges überlegen... Bei group klatscht man die Gruppe einfach unter eine Überschrift. Groups sehe ich eher für die Unterscheidung Einzelnachweise/Anmerkungen/... .--Avron (Diskussion) 20:36, 12. Sep. 2016 (CEST)

Zusätzlich zu allem bisher Gesagten würde ich noch ergänzen, dass Groups neu mit der Aufzählung beginnen, während refines es Autoren ermöglicht, Referenzen innerhalb von Einzelnachweisen oder anderen Gruppen zu spezifizieren. Tatsächlich würde der refines-Parameter wahrscheinlich so funktionieren, dass er sich immer nur auf eine bestimmte Gruppe bezieht. Wenn also eine Quelle innerhalb eine Gruppe spezifiziert werden soll, die nicht die Standard-Einzelnachweise ist, müsste nicht nur der Quellenname bei 'refines' angegeben werden, sondern gleichzeitig auch die Gruppe mithilfe des group-Parameters explizit spezifiziert werden. --Lea Voget (WMDE) (Diskussion) 11:54, 13. Sep. 2016 (CEST)

Verständnisfrage: Im Endeffekt stünde, nicht wie hier G 1, G 2 etc im Text sondern 1.1, 1.2? Mmh, das ist ja eine Verschlechterung - so merke ich mir, ah das G ist das Buch vom Gustav, aber mit ner Ziffer stattdessen - wie wenig intuitiv. Die in dem Bsp. angegebene Kurzform sehe ich kritisch - wenn die Liste von Einzelbelegen zu einem Werk zu lang wird, darf man dann bei jedem Klick im Text zuerst wieder nach oben scrollen um zu wissen welches Werk nun gemeint ist. Und wehe dem, der einen Satz nebst Beleg oder einen ganzen Absatz irgendwo anders weiterverwenden will, der darf dann den Beleg aus den anderen Textstellen heraus wieder zusammenbasteln. Naja, wurde ja schon vor 8, 9 Jahren so zu group diskutiert. Aber wer liest schon so alten Kram...--D.W. 21:40, 13. Sep. 2016 (CEST)

Und wofür stehen dort "(G)", "(T)" und "(B)"? Benatrevqre ^…?! 15:51, 14. Sep. 2016 (CEST)

Ich kann die Verschlechterung nicht nachvollziehen. Die Buchstaben sind ohnehin kryptisch; wenn ich wissen will was sich hinter einem Beleg verbirgt, dann fahre ich mit der Maus darüber und bekomme dazu den Text angezeigt. --Avron (Diskussion) 17:31, 14. Sep. 2016 (CEST)

Im Gegensatz zu group könnte man refine nach Bedarf/Vorliebe des jeweiligen Benutzers anpassen und beispielsweise automatisch Autorenabkürzungen usw. generieren (wie z.B. bei LaTeX üblich).--Cirdan ± 18:31, 14. Sep. 2016 (CEST)

kombination mit <references responsive />

bei gebrauch von „refines“ sollte der block bestehend aus der definition vom werk und „refines“ nicht umgebrochen werden, damit man bei vielen einzelnachweisen nicht erst scrollen muss und der einzelnachweis „zerrissen“ wird. gruss --Wetterwolke (Diskussion) 11:03, 31. Mai 2017 (CEST)

Update zum 1. Oktober 2018

Nach dem heutigen Totalumbau der Vorderseite (Danke für das Update!) sind die älteren Diskussionsbeiträge auf dieser Seite teilweise nicht mehr zutreffend oder inzwischen ohne Bezug. Evtl. sollte das klar gekennzeichnet oder auch per Archivierung aufgeräumt werden.--Mabschaaf 23:17, 1. Okt. 2018 (CEST)

@Mabschaaf: Danke für den Hinweis. Ich schau mir das gerne an, schaffe es allerdings vermutlich erst kommende Woche nach der WikiCon. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 17:03, 2. Okt. 2018 (CEST)

@Mabschaaf: Hier bin ich nochmal. Ich hab es noch nicht geschafft und bin jetzt bis Mitte November im Urlaub. Das Aufräumen der Diskussionsseite steht aber auf meiner Aufgabenliste, wird also nicht vergessen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:21, 23. Okt. 2018 (CEST)

Gibt es einen aktuellen Stand zu dem Technischen Wunsch? Grüße und Dank, Conny 14:30, 28. Mär. 2019 (CET).

@Conny: Wir haben weiterhin vor ihn umzusetzen, wann das passiert ist jedoch leider noch nicht sicher. Im Moment werden die Mediawiki-Parser von der WMF generalüberholt, somit können derzeit keine neuen Features die eine Erweiterung der Wikisyntax benötigen umgesetzt werden. Diese Arbeiten gehen vermutlich bis Mitte des Jahres, wenn wir mit der Entwicklung der anderen Wünsche gut vorankommen könnten wir dann in der zweiten Jahreshälfte damit beginnen. Das kann sich aber auch noch völlig ändern, denn Softwareentwicklung im Wikiversum bringt häufig unerwartete Überraschungen – gerade dieser Wunsch hatte bereits viele davon auf Lager und es gibt auch andere Wünsche die wir gerne möglichst bald angehen möchten. -- Michael Schönitzer (WMDE) (Diskussion) 15:38, 3. Apr. 2019 (CEST)

@Michael Schönitzer (WMDE): Danke für die Rückmeldung :) . Grüße, Conny 20:10, 3. Apr. 2019 (CEST).

Da inzwischen „Anfang Oktober“ war: Muss der umseitig vorletzte Satz zum aktuellen Stand aktualisiert werden, oder ist damit ein anderes Jahr gemeint? :-D --nenntmichruhigip (Diskussion) 23:13, 20. Okt. 2019 (CEST)

@Nenntmichruhigip: :) Der Status ist aktualisiert und der Wunsch befindet sich seit Ende Oktober (dieses Jahres :)) in der Umsetzung. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 09:25, 6. Nov. 2019 (CET)

Beta-Version

Hallo Team, vielen Dank schon mal für die Umsetzung! Eine Anmerkung: Ihr weist vorne darauf hin, dass ggf. Styles angepasst werden müssen, um die Einrückungen korrekt darzustellen. Vielleicht könnt ihr in dem Zusammenhang mal einen kurzen Blick auf diesen Wunsch werfen, ob der nicht direkt mitgelöst werden könnte...--Mabschaaf 17:03, 3. Dez. 2019 (CET)

@Mabschaaf: Danke für dein Feedback. Ich werde deine Anmerkung mit unseren Entwicklern besprechen und dir dann in den kommenden Tagen (hoffentlich) antworten können. -- Für das Technische Wünsche Team: Max Klemm (WMDE) (Diskussion) 08:54, 5. Dez. 2019 (CET)

Ich kann nicht beurteilen, welche technische Leistung dahinter steht. Darum geht es mir nicht. Aber ich will diese Funktion nicht, ich kann damit nichts anfangen, sie nervt nur. Ich will in einem Artikel alle Fußnoten einfach mit einer eigenen Fußnotenzahl sehen. In richtiger Reichenfolge. Ohne Buchstaben. Stets mit der gesamten Angabe in jeder Fußnote. Wenn eine Fußnote gelöscht wird (it's a wiki), hat das keinen Einfluss auf die übrigen. Ich will keinen neuen Code lernen. Wenn ihr meinen Work flow unterstützen wollt, dann macht es möglich, dass ich Literaturangeben irgendwo speichern und dann einfach abrufen kann. Nicht nur für einen, sondern für mehrere Artikel. Ziko (Diskussion) 21:00, 5. Dez. 2019 (CET)

@Ziko, es ist Dein Recht, dass Du die Funktion nicht willst, aber vermutlich ist das eine Minderheitenmeinung. Ich beispielsweise begrüße diese Funktion ausdrücklich und warte sehnsüchtig auf die allgemeine Verfügbarkeit, da ich -zig mal den bis auf die Seitennummer gleichen Fußnotentext nicht schön finde. Bereits jetzt benutze ich häufig <ref name="..." /> und erzeuge so mengenweise Referenzen mit Buchstaben. (Das Speichern von Literaturangaben ist eine andere Baustelle und könnte durchaus nützlich sein.) -- Karl432 (Diskussion) 21:22, 5. Dez. 2019 (CET)

(Quetsch) Welches Problem wird denn durch so eine technische Zusammenfassung gelöst? Ziko (Diskussion) 23:12, 5. Dez. 2019 (CET)

Beispielsweise, dass man in Ammerseebahn alle auf „Rasch: Nebenbahnen zwischen Ammersee, Lech und Wertach“ beruhenden Referenzen übersichtlich zusammengefasst sieht, statt diesen Buchtitel gefühlte 100‪× wiederholt über alle Referenzen verteilt zu sehen. -- Karl432 (Diskussion) 11:46, 6. Dez. 2019 (CET)

Na und - wo ist das Problem, lieber Kollege? Ziko (Diskussion) 20:58, 6. Dez. 2019 (CET)

Für mich ist die jetzige Unübersichtlichkeit der Referenzen ein Problem (mag sein, dass Du das anders siehst, das sei Dir unbenommen). Im Unterschied zu einer wissenschaftlichen Veröffentlichung, die einmal gründlich redigiert wird und dann statisch für alle Zeiten so da steht, ist ein Wikipedia-Artikel ein Angebot an alle, den Artikel weiterzuentwickeln. Dazu kann auch eine Übersichtlichkeit in der Liste der Referenzen hilfreich sein, und diese lässt sich schon bisher mit <ref name="..." /> und mit dem hier diskutierten Feature noch mehr (in meinen Augen) verbessern. Ich freue mich jedenfalls schon darauf, nach Freigabe des Features die Referenzliste beispielsweise in den Eisenbahn-Streckenartikeln meiner Heimatregion damit (in meinen Augen) verbessern zu können. -- Karl432 (Diskussion) 23:40, 6. Dez. 2019 (CET)

Was da als Beispiel vorgeführt wird, demonstriert Unkenntnis korrekten bibliographischen Zitierens. Bei Beiträgen in Sammelwerken oder Zeitschriften gehören die Angaben der kompletten Seitenzahlen zur Basisinformation. Falls sich das hier unter 1.1. verbirgt, würde das nur zur unkontrollierbaren Vermehrung schlampiger Belegangaben führen. Freiwillig werde ich das nicht benutzen, das Problem ist aber, daß derjenige, der einen Fehler entdeckt und ihn korrigieren möchte, sich mit diesem ganzen Kram auseinandersetzen muß. Und daher sehe ich auch die Gefahr, daß diese sogenannten Verbesserungen dazu dienen sollen, diejenigen hinauszudrängen, die nicht bei jeder Veränderung in Jubel ausbrechen. --Enzian44 (Diskussion) 22:56, 5. Dez. 2019 (CET)

ih finde die Syntax der Extension recht gemütlich; wenn uns etwas den Quelltext vesaut und verhunzt so sind das die Vorlagen "Internetquelle", "Literatur" oder wie sie sonst noch heißen, wenn die in den von mir angelegten Artikeln auftauchen, so fliegen sie umgehend im großen Bogen raus. -jkb- 21:02, 6. Dez. 2019 (CET)

auch wenn hier OT: was stört Dich an der Vorlage „Internetquelle“? Ich finde sie sowohl übersichtlich als auch sehr nützlich und habe schon zahlreiche refs mit ihr aktualisiert, bisher ohne Revert. -- Karl432 (Diskussion) 23:40, 6. Dez. 2019 (CET)

@Ziko: Danke für dein Feedback. Es ist schade, dass du die Funktion nicht hilfreich findest und wir dich damit nicht in deinem workflow unterstützen können. Wie @Karl432: schon gesagt hat kommen die Wünsche, an denen wir arbeiten, von einer Mehrheit der Wikipedianern selber. Ich will nochmals hervorheben, dass die Funktion rein optional ist und deinen bestehenden workflows nicht beeinflussen wird. Und Buchstaben kommen in der neuen Funktion gar nicht vor. -- Für das Technische Wünsche Team: Max Klemm (WMDE) (Diskussion) 08:46, 6. Dez. 2019 (CET)

Hallo Max, danke für deine Mühen. Nein, die Funktion ist nicht obligatorisch, aber ich finde es nicht schön, wenn ich erst viel Arbeit in einen Artikel stecke und dann uns jemand mit "ref name" oder sonstwas zwangsbeglückt. Ziko (Diskussion) 20:57, 6. Dez. 2019 (CET)

In solchen Fällen kannst Du doch mit Verweis auf WP:Korrektoren revertieren. Das mache ich auch, wenn jemand in die von mir erstellten Artikel bestimmte Vorlagen (z. B. Internetquelle oder Literatur) einbaut oder sie mit WSTM umformatiert. Irgendwann merken diese Leute dann, dass jeder Autor seine eigene Arbeitsweise und seine eigenen Vorlieben hat – und auch das Recht dazu. Für eine Diskussion über den Sinn dieser Erweiterung (die ich selbst sehr nützlich finde) ist es aber eigentlich zu spät. Die ist schon vor Jahren gelaufen und fiel zu Gunsten der Erweiterung aus.--Rodomonte (Diskussion) 21:25, 6. Dez. 2019 (CET)

Die Benutzung von Vorlagen bleibt jedem überlassen. Formatfehler in Einzelnachweisen lassen sich u.a. mit Hilfe von Vorlagen deutlich einfacher korrigieren. Ich persönlich halte es auch für sinnvoller, mehrfach verwendete EN mit <ref name=...> oder wie hier geplant zusammenzufassen, anstatt ein Dutzend Mal die gleiche Literatur einzufügen. LETZTERES macht den Artikel unübersichtlicher und mit größerer Wahrscheinlichkeit fehlerbehaftet. Der Leser sieht z.B. dann sofort, dass es nicht 30, sondern in Wirklichkeit nur 5 unterschiedliche EN sind.

Das Recht eines Autors auf eine bestimmte Formatierung seiner Artikel gibt es nicht. Wenn ein Autor einen neuen Einzelnachweis mittels einer Vorlage einfügt, hat diese Formatierung ebenso Bestandsrecht, denn WP:Korrektoren gilt für alle. Ansonsten kann natürlich jeder formatieren wie er will, ABER sollte auch die Vorlieben der anderen Autoren respektieren. Gruß --Bert (Diskussion) 23:28, 6. Dez. 2019 (CET)

Ich verstehe das einfach nicht: wieso Unübersichtlichkeit? Wo ist das Problem? Was kannst du nicht machen wegen der "Unübersichtlichkeit"? Und gerade weil die WP-Artikel sich weiterentwickeln können, darum ist es doch gerade sinnvoll, dass jede Fußnote für sich steht. Indem sie die gesamte Angabe in sich hat und völlig unabhängig von Änderungen an anderen Fußnoten ist. Ziko (Diskussion) 23:53, 6. Dez. 2019 (CET)

“Beauty is in the eye of the beholder”, das gilt wohl auch für Übersichtlichkeit. Wir sind hier offensichtlich einfach unterschiedlich. -- Karl432 (Diskussion) 00:02, 7. Dez. 2019 (CET)

@Mabschaaf: Unsere Entwickler haben sich das angesehen und wir denken nicht, dass man den von dir angeführten Wunsch mit lösen kann. Jedoch vielen Dank für den Hinweis! -- Für das Technische Wünsche Team: Max Klemm (WMDE) (Diskussion) 08:54, 19. Dez. 2019 (CET)

Endlich! Für die meisten Autoren die mit Büchern und Einzelnachweisen arbeiten eine Erleichterung, übrigens auch für Leser, welche sich Einzelnachweise anschauen. Nicht auf "Dagegen"-Lautsprecher hören.--Avron (Diskussion) 12:10, 7. Dez. 2019 (CET)

Der Leser sieht, wenn er einen solchen Einzelnachweis anklickt (und die Liste der Einzelnachweise etwas länger ist), erst einmal nur die Seitenzahl, während die eigentliche Literaturangabe oberhalb (oder bei einem Spaltenumbruch unterhalb) des sichtbaren Bereichs ist. Für den Leser ist das also ganz im Gegenteil keine Erleichterung, der muss dann nämlich erst einmal scrollen, wenn er sich wirklich für die Literaturangabe interessiert. Tatsächlich gibt es eine Benutzergruppe, die damit noch mehr Probleme haben wird, als der Durchschnittsleser, dafür lege ich mal einen neuen Abschnitt an. –Schnark 10:31, 10. Dez. 2019 (CET)

Man kann alles schlecht reden. Wenn ich aktuell ellenlange und mehrspaltige Einzelnachweislisten lese, davon aber vielfach redundant Buch und Autor ausgeschrieben, da verliere ich den Überblick.--Avron (Diskussion) 16:56, 10. Dez. 2019 (CET)

Das hat man hier aber doch schon diskutiert im Zusammenhang mit den Lesemaschinen für Blinde. Ist sicher einfach zu lösen - die <ref extends="XY"> gibt nicht nur die Seite aus, sondern auch "Müller, aao (oder s.o.), Seite ...". Wäre zu verkraften. -jkb- 17:07, 10. Dez. 2019 (CET)

@Schnark: Danke für dein Feedback. Wir haben das gleiche Feedback schon von den englischsprachigen Wikipedianer/innen bekommen. Daraufhin haben wir auf Phabricator ein Ticket erstellt, welches dieses Verhalten der Funktion thematisiert.

Gemeldet in Phabricator
Task T239785

-- Für das Technische Wünsche Team: Max Klemm (WMDE) (Diskussion) 08:56, 11. Dez. 2019 (CET)

Es geht mir nicht um das Popup, sondern um die ganz normale Ansicht, die sich bei einem Klick auf die Fußnote zeigt. Selbst wenn die Probleme mit dem Popup behoben werden, Benutzern, die das nicht nutzen (insbesondere diejenigen, die JavaScript deaktiviert haben), hilft das überhaupt nichts. –Schnark 11:54, 11. Dez. 2019 (CET)

Wann steht diese neue Funktion endlich in Wikipedia zur Verfügung? Ich warte sehnlichst darauf! ich habe hier diverse Einwände gelesen, ich kann aber nicht sehen, dass diese die Vorteile überwiegen; zumal die Nutzung ja optional ist. Für mich gibt es im wesentlichen 3 Vorteile: einmal gehe ich davon aus, dass diese Möglichkeit dazu führen wird, mehr Aussagen mit deutlich präzisere Angaben des Ortes für einen Beleg zu machen (bei Fachbüchern – z.B. in der Physik – kann das ungemein hilfreich sein), weiter stehen die Belege aus dem gleichen Werk zusammen an einer Stelle und drittens wird die Liste der Einzelnachweise deutlich kürzer, da viel viel unötige Redundanz vermieden wird (der Leser kann viel schneller erkennen wieviel verschiedene Quellen denn nun wirklich benutzt werden). – Ich wünsche mir dringend diese neue Funktion. Wann ist es soweit? Max Klemm (WMDE) kannst Du ein konkretes Datum nennen? ArchibaldWagner (Diskussion) 10:32, 23. Jan. 2020 (CET)

+1 (her damit, würde ich sagen) BG, --Leserättin (Diskussion) 18:14, 2. Feb. 2020 (CET)

Blinde Benutzer

Hat schon jemand getestet, wie blinde Benutzer, die einen Screenreader verwenden, mit dem neuen Format klarkommen? Der Link zielt auf den Listenpunkt, der nur die Seitenangabe enthält, während die eigentliche Literaturangabe irgendwo oberhalb steht. Wie kommt der Benutzer dort hin? Gibt es da eine Abkürzung, dass er „nur“ einem zusätzlichen Link folgen muss (und nochmal einen weiteren Zusatzschritt braucht, um wieder zurück in den Text zu kommen)? Oder muss er sich womöglich durch alle dazwischen stehenden Seitenangaben bis nach oben zur Literaturangabe durcharbeiten? Kurz: Wie wird sichergestellt, dass Einzelnachweise zukünftig weiterhin für alle Benutzer zugänglich bleiben? –Schnark 10:31, 10. Dez. 2019 (CET)

s. einen Abschnitt höher, meinen Beitrag von 17:07, 10. Dez. 2019 (CET), -jkb- 17:08, 10. Dez. 2019 (CET)

Aktuell haben wir in Artikeln reichlich Formatierungen wo Buch und Enzelnachweis über mehrere Abschnitte voneinander getrennt sind und das völlig ohne Verlinkung. Da sieht man Buch und EN nicht mal zusammen auf dem Bildschirm. Demgegenüber ist alles das hier eine wirklich große Verbesserung. Zumal sich bei diesem Ansatz, wie von -jkb- geschrieben, das Problem leicht softwaremäßig lösen lässt - was in den antiken Artikeln überhaupt nicht der Fall ist. Ich sehe hier auch kein Problem und freue mich schon auf die Umsetzung in bestehenden und zukünftigen Artikel. Gruß --Bert (Diskussion) 17:43, 10. Dez. 2019 (CET)

@Schnark: Auch hier bedanke ich mich nochmals für dein Feedback. Ich kann dir momentan nicht sagen, wie sich die Funktion für Benutzer/innen mit Screenreader verhält. Ich werde die Anmerkung an unsere Entwickler weiter geben und dich hier auf dem Laufenden halten, sobald ich mehr weiß.
Darüber hinaus ist hier der Link zu unseren Kriterien für die Umsetzung von technischen Wünschen, wo wir uns u. a. vornehmen, dass "[...] unsere Funktionen den Nutzenden von Screenreadern das Leben nicht schwerer machen" soll. -- Für das Technische Wünsche Team: Max Klemm (WMDE) (Diskussion) 09:16, 11. Dez. 2019 (CET)

Solche Fälle wie Arminius stellen kein großes Problem dar, eben weil der Einzelnachweis selbst ja nicht nur die Seitenangabe, sondern auch – wenngleich verkürzt – das Werk enthält. Das muss man – sowohl als sehender als auch als blinder Benutzer – beim ersten Mal vielleicht nachschauen, welches Werk gemeint ist, bei jedem weiteren Vorkommen weiß man das dann. Und da Standardwerke häufig mit ihrem Autor oder Herausgeber abgekürzt werden (vom Bronstein bis zum Pschyrembel), weiß man vielleicht sogar schon beim ersten Mal, welches Werk gemeint ist.

Tatsächlich würde das Problem dadurch gelöst, wenn ein extends-Einzelnachweis nicht nur seinen eigenen Inhalt wiedergeben würde, sondern auch in irgendeiner Form den übergeordneten Einzelnachweis. Nur: Ein menschlicher Autor kann so eine abkürzende Bezeichnung leicht aus dem vollen Einzelnachweis ableiten, eine Maschine kann das nicht. Das heißt, es müsste entweder bei jeder Verwendung die volle Literaturangabe wiederholt werden, oder die Kurzbezeichnung müsste vom Autor zusätzlich jeweils angegeben werden. –Schnark 12:10, 11. Dez. 2019 (CET)

Dass die Kurzbezeichnung immer angegeben werden müsste würde ich nicht für realistisch durchsetzbar halten: Dann kommen Leute, die meinen dass man das nicht bräuchte, weil das ja eh direkt darüber steht. Wäre es evtl möglich, nur beim Anspringen eines Einzelnachweises bei diesem die volle Angabe vordran zu setzen? Würde aber mindestens CSS und vmtl auch JS erfordern ... --nenntmichruhigip (Diskussion) 16:49, 11. Dez. 2019 (CET)

Der von Schnark zuerst angeführte Kritikpunkt war "... Der Link zielt auf den Listenpunkt, der nur die Seitenangabe enthält, während die eigentliche Literaturangabe irgendwo oberhalb steht. ..." "Wie kommt der Benutzer dort hin?" "... muss er sich womöglich durch alle dazwischen stehenden .... angaben bis nach oben zur Literaturangabe durcharbeiten?" Genau das ist bei solchen Artikel wie Arminius der Fall: unter Arminius#Anmerkungen findet man die Seitenangabe zusammen mit einer Bezeichnung, wie "Tacitus, Annalen". Aber, um rauszufinden, was gemeint ist, muss der Leser mehrere Abschnitte/Seiten hochscrollen auf Arminius#Quellen.

Für die (Minderheit der) Leute, die sich mit dem Thema auskennen, mag die Angabe "Tacitus, Annalen" genügend sein, um zu wissen, was gemeint ist, für die meisten Leser ist es das eben nicht (Anm: Als Chemiker schreibe ich ja auch nicht einfach nur Holleman in den Einzelnachweis und erwarte, dass jeder Leser versteht was gemeint ist). Insofern ist diese Erweiterung für blinde Leser nicht besser oder schlechter als die bisher gelebte Praxis bei historischen Texten. q.e.d. --Bert (Diskussion) 18:39, 17. Jan. 2020 (CET)

Es gibt durchaus zwei gewichtige Unterschiede zwischen dem Artikel Arminius und der derzeitigen Implementierung der neuen Software-Funktion: „Tacitus: Annalen 123.“ mag für viele Leser nicht ausreichend sein (da die genaue Stelle jeweils mit einer Online-Ausgabe verlinkt ist, ist sie aber eigentlich schon ausreichend), aber wie ich schon schrieb – wenn er die exakte Literaturangabe beim ersten Mal (und bei einem schlechten Kurzzeitgedächtnis vielleicht noch ein zweites Mal) nachgeschaut hat, dann kann er weitere Zitate sofort verstehen. Demgegenüber muss man bei einem Einzelnachweis, der wirklich nur aus einer Seitenangabe besteht, wirklich jedes Mal erneut herausfinden, auf welches Werk sie sich bezieht.

Zum anderen handelt es sich beim Artikel Arminius um eine Entscheidung eines einzelnen Autors, die Einzelnachweise auf diese Art zu gestalten. Wenn man darin ein Problem sieht (was ich im konkreten Fall wie gesagt nicht tue), kann man das gegebenenfalls nach Diskussion ändern und ganz konventionell in allen Einzelnachweisen die vollständige Literaturangabe hinschreiben. Das wäre mit der neuen Software-Funktion so nicht möglich, denn es wäre wohl kaum vermittelbar zu sagen: „Es gibt zwar die extends-Funktion, aber aus Gründen der Barrierefreiheit darf die nicht in Artikeln eingesetzt werden.“ Zudem würde die Anzahl der Verwendungen natürlich stark zunehmen, im Augenblick sind das wenige Einzelfälle, mit der neuen Funktion würde das dagegen viel häufiger eingesetzt.

Die Erweiterung in der gegenwärtigen Form würde also durchaus mehr Probleme für blinde Leser bedeuten als die gegenwärtige Praxis. –Schnark 11:07, 20. Jan. 2020 (CET)

mM schreit das geradezu nach einer technischen Lösung: Ein Häkchen in den Benutzereinstellungen könnte bewirken, dass alle für Sehende verkürzten Angaben für Blinde komplett ausgeschrieben werden. Weitergedacht könnten solche aktivierten "Lesehilfen für sehbehinderte Benutzer" auch noch für andere erleichterte Darstellungen genutzt werden, also letztlich für eine ganz eigene Skin-Gestaltung. --Mabschaaf 18:42, 20. Jan. 2020 (CET)

+1, das würde das Problem bei den erweiterten Einzelnachweisen nicht nur lösen, sondern diese sogar noch wesentlich verbessern, da der blinde "Leser" dann jedes Mal den kompletten EN bekommt und nicht nur einen Verweis auf eine Literaturstelle. Perfekt. --Bert (Diskussion) 00:36, 23. Jan. 2020 (CET)

wann?

wann wird die neue extend-extension verfügbar? Schläft sie im moment? LG -jkb- 22:23, 27. Apr. 2020 (CEST)

Hi @-jkb-:, wir haben die extend-extension auf dem Schirm. Jedoch arbeiten wir aufgrund anderer Projekte und der aktuellen Corona Situation nicht aktiv an dem Projekt. Sobald wir mehr wissen werden wir über die üblichen Kanäle (Projektseiten/ Newsletter) informieren. --Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 13:41, 28. Apr. 2020 (CEST)

Danke. Schade nur, dass es verspätet kommt - LG -jkb- 17:46, 28. Apr. 2020 (CEST)

Hi @Max Klemm (WMDE):, mittlerweile sind weitere fünf Monate verflossen und die schon lange als beta-Version getestete Erweiterung ist in de.wikipedia noch immer nicht verfügbar. Welche Erklärungen gibt es für diese Verzögerung oder Blockierung? Es fällt mir schwer zu glauben, dass hier noch ein Menge Arbeit für die Bereitstellung nötig ist. ArchibaldWagner (Diskussion) 09:30, 22. Sep. 2020 (CEST)

Ich kann mich da nur anschließen. Es ist schade, dass diese mMn sehr wichtige und hilfreiche Erweiterung noch immer nicht genutzt werden kann. -- H005 (Diskussion) 15:16, 22. Sep. 2020 (CEST)

+1 noch einmal, -jkb- 15:39, 22. Sep. 2020 (CEST)

Corona dient als Entschuldigung für alles... Und das bei einem Projekt, bei dem schon von Anfang an fast ausschliesslich digital gearbeitet wird.--Avron (Diskussion) 11:06, 23. Sep. 2020 (CEST)

Hi @ArchibaldWagner, H005, -jkb-, Avron:, folgende Situation gibt es momentan mit der Erweiterung der Einzelnachweise: im Wikitext funktioniert die Funktion. Das Problem ist, dass erweiterte Einzelnachweise im Visual Editor noch nicht richtig funktionieren, bzw. dort unter anderem die Gefahr besteht, dass Hauptquellen gelöscht werden können und dann die Erweiterung dieser alleine dasteht, was zu Datenverlust und Verwirrung führen könnte.

Um diese Probleme zu beheben, müssen wir uns nochmals mit dem Projekt beschäftigen. Bevor wir das tun können, haben wir aber auch noch andere Projekte abzuschließen, und zwar: Vorschau von Einzelnachweisen im Artikeltext und abschnittsbasierten Bearbeitungskonflikt Oberfläche. Da wir parallel auch noch an den neuen Themenschwerpunkten “Leichter mit Vorlagen arbeiten” und “Bessere Unterstützung von Geoinformationen” arbeiten, verzögert sich die Arbeit leider. -- Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 17:06, 6. Okt. 2020 (CEST)

Vielleicht könnt ihr das Projekt stärker priorisieren. Die Erweiterung ist wirklich extrem hilfreich. Schon bei einem durchschnittlich großen Artikel werden die Einzelnachweise sehr unübersichtlich, sobald ein größeres Werk mehrfach gemäß Hilfe:Einzelnachweise#Mehrfache Referenzierung desselben Werks mit verschiedenen Seitenangaben zitiert wird. Gruß Matthias 19:27, 22. Nov. 2020 (CET)

Ich schließe mich dem Wunsch meines Vorredners an. Nach meinen Erfahrungen ist es fast immer effizienter, fast fertige Arbeiten abzuschließen, bevor man sich in ganz neue Arbeiten vertieft. Es erzeugt garantiert weniger Stress, ja es erzeugt allseits Freude, wenn man diese Arbeiten endlich abhaken kann. ArchibaldWagner (Diskussion) 20:43, 22. Nov. 2020 (CET)

"momentan mit der Erweiterung der Einzelnachweise: im Wikitext funktioniert die Funktion." Bei mir hat es nicht geklappt. Ich habe hin- und herverglichen und komme nicht drauf, was ich falsch gemacht haben könnte. Würde das jemand, dem das schon gelungen ist, mal bitte im Artikel Quba (Rayon) für die doppelte Lit.angabe machen? Dann kann ich anhand des Richtigen meinen Fehler hoffentlich erkennen. --Tozina (Diskussion) 21:48, 14. Dez. 2020 (CET)

Wie hast du denn festgestellt, dass es nicht funktioniert? Ich kann auf die Schnelle keine Edit-Versuche von dir finden. -- H005 (Diskussion) 10:07, 16. Dez. 2020 (CET)

Na, die das Nichtfunktionieren anzeigende Vorschau habe ich nicht abgespeichert. So kannst du es nicht sehen. --Tozina (Diskussion) 08:48, 24. Dez. 2020 (CET)

Hallo Tozina, mein Kollege Max hat sich da nicht ganz klar ausgedrückt. Die Funktion ist zwar fertig entwickelt, aber wegen des Problems im Visual Editor noch deaktiviert. Wir sind im Kontakt mit den Kollegen von der WMF, aber wissen leider nach wie vor nicht wann das umgesetzt wird. Unser Team hat leider im Moment nicht die notwendigen Ressourcen um das selbst umzusetzen. -- Michael Schönitzer (WMDE) (Diskussion) 22:54, 18. Dez. 2020 (CET)

Vielen Dank für diese Nachricht. So weiß ich nun wenigstens, dass es nicht an mir liegt. Ich hatte mich über diese Funktion sehr gefreut und hoffe, dass sie bald in den regulären Betrieb geht. - Wenn du noch etwas Zeit findest: Warum kann die Funktion nicht vorerst in der Nurtext-Variante bestehen? --Tozina (Diskussion) 08:48, 24. Dez. 2020 (CET)

So, jetzt sind noch mal zwei Monate ins Land gegangen. Gibt es ein Update? Kann man vielleicht den Visual Editor zumindest so verändern, dass dieser entsprechende Einzelnachweise nicht anfasst? Ich habe nämlich das Gefühl, dass es bei dieser Geschwindigkeit noch ein Jahzehnt dauert. Verständniss habe ich dafür schon lange nicht mehr.--Avron (Diskussion) 10:34, 12. Feb. 2021 (CET)

Hallo Avron, Tozina und alle die hier mitlesen. Leider habe immer noch keine erfreulichen Nachrichten. Auch wenn wir dieses Feature selbst gerne abschließen und freischalten würden, werden wir in den kommenden Monaten daran leider nicht weiter arbeiten können. Für die zweite Jahreshälfte besteht zumindest noch eine kleine Chance es doch noch unterzubringen, auch wenn dafür gemäß Jahresplan keine Ressourcen dafür vorhanden sind. Darüber hinaus können wir leider noch nichts sagen – uns ist bewusst, dass dieses Feature sehnsüchtig erwartet wird. -- Michael Schönitzer (WMDE) (Diskussion) 15:06, 23. Feb. 2021 (CET)

Wer macht solche Pläne?--Avron (Diskussion) 15:14, 23. Feb. 2021 (CET)

Eigentlich war geplant dieses Projekt im Jahr 2020 umzusetzen und zu aktivieren. Leider haben sich unsere Pläne letztes Jahr nicht erfüllen lassen – das hatte verschiedene Gründe: Zum einen ist unser Team recht klein, fällt eine Person also aus, so macht sich das stark bemerkbar. Gerade auch durch Corona sind einige Teammitglieder mehr oder weniger stark ausgefallen, da sie kleine Kinder zu Hause haben. Der andere große Punkt, der uns einen Strich durch die Rechnung gemacht hat, war, dass durch Feedback der Community klar wurde, dass die Abschnittsbasierte Bearbeitungskonflikt Oberfläche noch deutlich Nacharbeit brauchte und dieses Projekt somit wesentlich mehr Ressourcen belegte als eigentlich eingeplant. Aus diesen Gründen haben wir im Jahr 2020 die Erweiterung der Einzelnachweise nicht umsetzen können und sind auch bei anderen Projekten weniger weit gekommen als erhofft.

Wir würden zwar selbst gerne dieses Projekt – unser bisher am längsten andauerndes – endlich abschließen, aber wir wollten auch die Themen “Leichter mit Vorlagen arbeiten” und “Bessere Unterstützung von Geoinformationen” nicht auf 2022 verschieben. Dazu kommt, dass wir bisher noch keine Erfahrungen mit dem Visual Editor haben, sodass wir nur schlecht abschätzen können wie aufwändig die Anpassungen sein werden.

Daher musste das Projekt aus dem Jahresplan 2021 leider gestrichen werden. Für Mitte des Jahres ist eingeplant, den aktuellen Arbeitsmodus zu überprüfen und neu zu entscheiden wie wir mit den verbleibenden Projekten der vorherigen Wunschliste umgehen. Ich hoffe, ich konnte ein wenig erklären, wie es zu dieser unerquicklichen Situation kam. -- Michael Schönitzer (WMDE) (Diskussion) 13:06, 4. Mär. 2021 (CET)

@Michael Schönitzer (WMDE): Vielen Dank fürs Bescheidgeben und die Erläuterungen. Es ist wirklich sehr schade!!! Nicht klar ist mir, warum das nicht für die Arbeit im Quelltext freigegeben werden kann, wenn es dort funktioniert. Dem Arbeiten im VE wird doch nichts weggenommen, dort würde nur Status quo bleiben. Wenn nichts Technisches dagegenspricht natürlich. Also Mitte des Jahres bei eurer Neueinschätzung? Und VE eben 2222. --Tozina (Diskussion) 23:16, 5. Mär. 2021 (CET)

@Tozina: Es schon aktivieren, bevor wir an der Unterstützung für VE arbeiten ist leider nicht möglich, da das leider nicht nur hieße das man im VE dieses Feature nicht nutzen kann – der VE "stolpert" über die neue Syntax. Wenn jemand im Quelltext diese Funktion in einem Artikel nutzen würde und später jemand im VE den Artikel bearbeitet, könnte der VE Einzelnachweise kaput machen. Zumindest das muss also korrigiert werden, befor die Funktion hierzuwiki aktiviert werden kann. :/ -- Michael Schönitzer (WMDE) (Diskussion) 14:32, 9. Mär. 2021 (CET)

Wenn WMDE wollte, könnte man ganz einfach eine Abfrage im VE machen, ob der Artikel die erweiterten Einzelnachweise enthält und in dem Fall eine Bearbeitung durch VE ablehnen. Damit würde man die Erweiterung im Quelltext nutzen können und die Super-Duper Lösung irgend wann später im VE nachziehen. Eber das möchte WMDE nicht. Und im nächsten Jahr kommt wieder etwas dazwischen...--Avron (Diskussion) 09:19, 15. Mär. 2021 (CET)

Auf den Leser kommt es an

Wir schreiben für die Leser, nicht für uns. Auch wenn das Schreiben unangenehm mühsam ist, trifft das nur wenige Menschen; wenn aber das Lesen unübersichtlich und mühsam ist, trifft das alle Leser, und das sind bei guten Artikeln einige Größenordnungen mehr als Verfasser. Trotzdem soll natürlich die Schnittstelle für den Verfasser so gestaltet sein, dass das Schreiben gut lesbarer Artikel nicht unnötig erschwert wird. Bei den Einzelnachweisen sehe ich die folgenden beiden Probleme:

Beispielbild für die Erweiterung der Einzelnachweise

Die Ausgabe ist unübersichtlich für den Leser. Die Einzelnachweise erscheinen in der Reihenfolge, in der sie zitiert wurden, selbst wenn sie sich nur in der Seitenzahl unterscheiden und manchmal auch wenn nicht. Jedes Mal mit allen bibliografischen Angaben. Dazwischen beliebig viele andere Nachweise, und die dann mit denselben Wiederholungen. Auch wenn der Leser von gedrucktem Material sich an manches gewöhnt hat (z.B. „a.a.O.“ oder auch kryptische Abkürzungen wie „Nudlhuber 1983“ – wo war doch gleich wieder ein solches Buch zitiert?): hier kann man Besseres erwarten, z.B. wie im Bildchen rechts.

Der Verfasser kann kaum etwas dagegen tun. Das einzige, was er tun kann, ist diejenigen Einzelnachweise zu einem zusammenfassen, die absolut identisch sind. Zitieren sie verschiedene Stellen im selben Werk, treten alle genannten Hässlichkeiten gnadenlos auf. Ein Work-around ist allenfalls, eine benannte Referenz mit allen Seitenzahlen zu fertigen („Johann Nudlhuber, …, S. 17, 31–35, 78–83“). Das ist zwar etwas übersichtlicher für den Leser, ist aber nicht im Sinne des Erfinders der Seitenzahl. Erscheint ein Werk unter Literatur und außerdem Einzelnachweise in dasselbe Werk, muss man es auf jeden Fall mindestens zweimal aufführen. Da der Verfasser des Artikels durch diese Macken an seiner Schnittstelle gezwungen wird, dasselbe Werk mehrfach mit allen bibliografischen Angaben zu erfassen – und erst recht wenn im selben Artikel mehrere Verfasser dasselbe Werk zitieren – können auch beim selben Werk Details voneinander abweichen, wodurch sie nicht mehr zusammengeführt werden können, selbst wenn sie inhaltlich könnten.

Ich kann nicht für einen Diskussionsbeitrag eine bessere Lösung aus dem Ärmel ziehen, möchte aber doch ein paar Anmerkungen loswerden, wohin es meiner Ansicht nach gehen sollte:

Jede Lösung muss abwärtskompatibel sein. Wir haben Hunderttausende Artikel, hoffentlich alle mit Einzelnachweisen. Die arbeitet keiner um. Also muss die bisherige Schnittstelle weiter funktionieren wie bisher, und eine Umstellung darf nur gefordert werden, wo damit neue Funktionalität oder neue Bequemlichkeit gewonnen wird.

Die Zusammenführung von Verweisen auf dasselbe Werk soll nicht der Verfasser machen, sondern die Wiki-Software. Das geschieht bei der Abarbeitung des Tags <refernces/>. Dann und erst dann wird festgestellt, wie oft und wo ein Werk zitiert wurde. Also neu: Wenn zwei Referenzen inhaltlich übereinstimmen, werden sie gemeinsam aufgelistet, egal ob der Verfasser sie schon über einen gemeinsamen Namen zusammengeführt hat oder ob er sie zweimal unabhängig angeführt hat. Sonst kann keine Kompatibilität mit der bisherigen Schnittstelle erreicht werden, die wiederholte Referenzen oft erzwungen hat. Außerdem wird dadurch die Benutzung der Schnittstellen nicht nur für den Verfasser selbst weniger fehleranfällig, sondern auch für Software wie den VisualEditor, der so nicht gezwungen ist, ähnliche oder gleiche Referenzen speziell zu behandeln. Diese zentrale Erfassung und Abarbeitung aller Referenzen kann auch die Qualität von Fehlermeldungen verbessern, die falsche Referenzen monieren.

Nicht Einzelnachweise <ref…> sondern Literaturangaben {{Literatur|…}} müssen wiederverwendbar sein. Und zwar aus zwei Gründen:

• Inhaltich: Mehrere Vorkommen des gleichen Werks, nicht aber notwendig der gleichen Stelle darin, sollen zusammengeführt werden.
• Syntaktisch: Der Inhalt eines <ref>-Tags ist eine beliebige Zeichenkette, deren Teile beliebige Form haben; die Parameter der Literatur-Vorlage sind dagegen einzeln auswertbar und vergleichbar.

Wenn ein <ref>-Tag nur einen Aufruf der Literatur-Vorlage enthält, wäre eine Umstellung auf eine erweitere Literatur-Vorlage auch automatisiert denkbar; anders formatierten <ref>-Tags kann man kaum mehr anbieten als das bisherige Verhalten.

Ich habe auch Vorstellungen darüber, wie eine solchermaßen ergänzte Schnittstelle aussehen könnte, aber das wird erst interessant, wenn Interesse an einer solchen Weiterentwicklung besteht. --Lantani (Diskussion) 11:47, 4. Feb. 2022 (CET), korr. 19:11, 11. Feb. 2022 (CET)

Super zusammengefasst!--Avron (Diskussion) 10:25, 11. Feb. 2022 (CET)

Da stimme ich zu. Dass allgemein starkes Interesse an Verbesserungen besteht, ist ja durch diese Umfrage deutlich geworden. Allerdings macht dieses Ergebnis nun auch kurzfristige Parallellösungen weniger sinnvoll, da diese den Entscheidungsspielraum für die "richtige" Lösung einschränken könnten (Stichwort Aufwärtskompabilität). -- H005 (Diskussion) 10:59, 11. Feb. 2022 (CET)

müsste es eigentlich nicht "abwärtskompatibel" heißen?--Avron (Diskussion) 11:55, 11. Feb. 2022 (CET)

Ja, müsste es. Ich korrigiere es in den Text hinein. --Lantani (Diskussion) 19:10, 11. Feb. 2022 (CET)

@H005: die richtige Lösung was ist das? Das was hier phab:T100645 schon existierte und mit dem Quelltext-Editor gut funktionierte wäre schon eine Riesenfortschritt gegenüber der aktuellen Situation. Mir wäre es lieber dieses wird erst einmal realisiert, als die super Superlösung, die dann erst in drei Jahren oder nie kommt. Meine Erfahrung mit Programmentwicklung ist eher, dass wunderbare großspurige Konzepte nie richtig zum Laufen gekommen sind. Kleine in der Praxis immer wieder geprüfte Schritte sind oft Ziel führender. ArchibaldWagner (Diskussion) 21:39, 11. Feb. 2022 (CET)

Die "richtige Lösung" würde nach meinem Wunsch auch die artikel- und projektübergreifende Wiederverwendbarkeit erleichtern. Also zum Beispiel die Abfrage von Literaturdatenbanken, in denen man dann das entsprechende Werk nachschlagen und die Werte halbautomatisch übernehmen kann. Diese werden dann in einem Wikidata-Eintrag gespeichert, auf den ich auch aus anderen Artikeln und Wiki-Projekten zugreifen kann. Vielleicht Träumerei, aber wenn die Behandlung des Top-Wunsches des Jahres sich darauf beschränkt, eine bereits vorhandene Funktion nur im VE verfügbar zu machen, fände ich das schon ein wenig dünn. -- H005 (Diskussion) 22:13, 14. Feb. 2022 (CET)

Soweit ich das Verstehe, gibt es bereits eine funktionierende Umsetzung des Themas, das Problem ist nur der Visual-Editor, da dieser damit auch klar kommen muss (siehe #Warum_dieser_Wunsch_nicht_umgesetzt_wird). Wie das aussehen sollte, kann man auch schon unter #Die_geplante_Lösung nachlesen. Trotzdem ein paar Anmerkungen zu den Ideen von Lantani, die davon ja abweichen:

• Dass nicht Einzelnachweise sondern Literaturangaben wiederverwendet werden sollten, is unnötig umständlich. Viel naheliegender und auch in der Anwendung intuitiver (und so schon in der Vorderseite vorgestellt) wäre es die jetzt bereits bestehend Möglichkeit der Mehrfachreferenzierung zu "erweitern". Also sowas wie <ref extends="Pierson">S. 123–163 </ref> Die Zusammenfassung erfolgt dann wie bei der Mehrfachreferenzierung natürlich automatisch.
• Die Idee die Zusammenfassung vollständig durch die Software durchführen zu lassen ist etwas praxisfern: In vielen Fällen sind bei Einzelnachweisen mit verschiedenen Seitenzahlen die Angaben nicht identisch, selbst wenn Vorlagen wie Literatur verwendet werden (sei es etwa dass mal der Vorname des Autors abkürzt ist oder ein Buchstabe klein/groß ist,...). Es muss also (wie auch bei der einfachen Mehrfachreferenzierung) eine Verknüpfung bereits von den Autoren/Editor erfolgen.--Naronnas (Diskussion) 10:40, 14. Feb. 2022 (CET)

<ref extends="Pierson">S. 123–163 </ref>

Ich sehe eine gewisse Diskrepanz zwischen den folgenden beiden Aussagen in Warum dieser Wunsch nicht umgesetzt wird:

• „extends“ zwingt niemanden dazu, die Arbeitsweise umzustellen. Alle bisherigen Methoden sind ohne Einschränkung weiterhin so möglich.
• 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.

Wer also bisher die Vorlage Literatur verwendet, kann das nicht benutzen; damit ist die Kompatibilität dahin. Und wenn es doch gehen soll, muss eben diese Vorlage wiederverwendbar sein, wie ich geschrieben habe, d. h. sie muss ein Attribut name benutzen – genau das habe ich gefordert, ohne jetzt die spezielle „name“-Syntax mit vorzuschlagen. So weit auseinander sind wir also gar nicht.

Mein Vorschlag ist natürlich davon geprägt, dass ich die Vorlage Literatur verwende und nach und nach frei formatierte Referenzen darauf umstelle. Damit habe ich aufs falsche Pferd gesetzt, wo doch der wahre Wiki-Guru, der ich trotz über 10 Jahren Artikel schreiben und mit Einzelnachweisen versehen eben noch nicht bin, stattdessen die MediaWiki-Erweiterung Cite verwendet, von deren Existenz ich hiermit Kenntnis nehme. Ist die irgendwo beschrieben, wo man sie als schlichter Verfasser von Inhalt findet? Vielleicht ist die besser zu internationalisieren, so dass Literatur nur als Oberfläche dafür dienen sollte, was das Problem schwieriger Übernahmen von Literaturangaben aus anderssprachigen WPs entschärft.

Ich vergleiche jetzt: Mein Punkt Kompatibilität ist mit dieser Lösung nur erfüllt, wenn man die Vorlage Literatur aufmotzt, was wohl machbar ist und den Punkt Literaturangaben wiederverwertbar dann erfüllt, wenn man deren Attribut name auch in weiteren Literatur-Aufrufen verwenden kann, z. B. um eine Buchreferenz im Abschnitt Literatur zu einem Einzelnachweis zu machen, der zusätzlich eine Stellenangabe enthält. Da wäre ein extends aber eine Änderung der Attributliste der Vorlage Literatur (oder Cite, wenn das passender ist) und nicht der unstrukturierten, mit <ref> definierten Zeichenkette. Und da bleibe ich bis jetzt der Meinung, dass extends nicht auf Zeichenketten operieren sollte, sondern auf Attributen.

Bleibt der Punkt zentrale Zusammenführung: Natürlich hängt das davon ab, dass Literaturangaben und Einzelnachweise wiederverwendbar sind und wiederverwendet werden. Ich fände aber diese Zentralisierung die technisch richtige Lösung, aber wenn alles andere ohne geht, kann man auch darauf verzichten. Vorteile wären:

• An einer Stelle wird für den ganzen Artikel festgestellt, welche Referenzen es gibt. Das geschieht auch bei einer Änderung an nur einem Abschnitt, so dass die dortigen Referenzen noch vor dem Abspeichern darauf überprüft werden können, ob sie irgendwo im Artikel definiert sind und wie – das Ergebnis kann also mit angezeigt werden.
• Wer Literaturangaben bündeln will, also alle Literaturverweise an einer Stelle stehen haben und dann nur noch die Namen verwenden, kann das tun – vorgeschrieben darf es aber wegen der Kompatibilität nicht werden.
• Ich habe keine Ahnung, was die Probleme beim VE waren, den ich nicht verwende: möglicherweise hängen sie mit dem Fehlen einer Instanz zusammen, die den Überbick über alle Referenzen hat.

--Lantani (Diskussion) 12:15, 14. Feb. 2022 (CET)

Probleme, wenn man nachträglich Seitenzahlen einträgt oder eine zweite Quelle

Angenommen, man hat diese Wiederverwendung durch das neue Extends-Feature:

<ref name="Atlantis">Sebastian Schulze: ''Regierungsformen in Atlantis.'' Wien 1902</ref>

...

<ref extends="Atlantis">S. 234</ref>

Und nun passiert eines von zwei Dingen (oder beides)

• In die ursprüngliche Referenz möchte jemand auch eine Seitenzahl einpflegen, z.B. S. 23
• In die ursprüngliche Referenz möchte jemand eine weitere Quelle einpflegen

Das Ergebnis sieht dann so aus

<ref name="Atlantis">Max Müller: ''Atlantis.'' Berlin 1901, S. 123; Sebastian Schulze: ''Regierungsformen in Atlantis.'' Wien 1902, S. 23.</ref>

...

<ref extends="Atlantis">S. 234</ref>

Was dann angezeigt wird, dürfte den Leser verwirren:

• Er weiß nicht genau, auf welches Werk sich die Seite 234 bezieht
• Dass in der hierarchischen Darstellung ein Haupteintrag nun aus zwei Büchern besteht (eines davon sogar mit Seitenzahl), ist komisch.

Natürlich kann man das in wenigen Minuten umbauen, so dass es gut aussieht.

Meiner Meinung widerspricht das aber der Aussage "Der Vorschlag zwingt niemanden, anders zu arbeiten als bisher. Alle bestehenden Zitationsmethoden sind weiterhin ohne Einschränkung möglich." Jemand, der gar nicht selber mit Extends arbeiten wollte, und der nur eine zweite Quelle oder eine präzisierende Seitenzahl eintragen wollte, wird gezwungen, sich mit dem neuen Feature auseinanderzusetzen. --T. Wirbitzki (Diskussion) 12:51, 8. Mai 2022 (CEST)

Ich sehe da keinen Unterschied zu der bisherigen Mehrfachverwendung von Einzelnachweisen. --nenntmichruhigip (Diskussion) 01:26, 9. Mai 2022 (CEST)

Genau, es handelt sich beide Male um Fälle, wo man meint, eine einfache, lokale Änderung zu machen, und wo sich das dann unerwartet auf andere Stellen im Text auswirkt. Ich hatte mir das Beispiel mit dem Eintrag 'Jablanica' (Datei:Mock_for_book_referencing_with_Visual_Editor.png) auf der Projektseite angeschaut. Wenn ich 'extends' benutzen würde, dann auf keinen Fall wie in diesem Beispiel, ich würde die Hauptreferenz "[1]" immer in den references "verstecken". --T. Wirbitzki (Diskussion) 07:29, 9. Mai 2022 (CEST)

Hilfe:Einzelnachweise#Zusammenfassung_mehrerer_Einzelnachweise_in_einer_Belegangabe scheint mir nicht sinnvoll. --Enhancing999 (Diskussion) 14:41, 11. Aug. 2023 (CEST)

Ein Anwendungsbeispiel für Sammelfußnoten ist Bahnstrecke Mering–Weilheim, wo Fundstellen mehrerer Quellen kontrastiert werden, in den Fußnoten 16, 41–42, 48–50, 52–55, 60 und 63. Sinn ergeben Sammelfußnoten, wenn sie genau eine Aussage im Fließtext belegen und es bemerkenswert ist, dass und wie die Quellen zu einem ähnlichen Ergebnis kommen. Ein Extremfall wären Quellen in einer Fußnote, die sich widersprechen und dadurch belegen, dass eine klare Aussage zurzeit nicht möglich ist. Weitere Diskussion dazu gibt es auch hier. Bei Sammelfußnoten kann "ref ... extends" nicht gut angewendet werden, darauf sollte in der Hilfe hingewiesen werden, sofern „ref ... extends“ eingeführt wird. --T. Wirbitzki (Diskussion) 07:58, 12. Aug. 2023 (CEST)

Hallo T. Wirbitzki, hab die Diskussion leider erst jetzt gesehen. Wenn ich das richtig interpretiere und die neue Form der Referenzangaben eingeführt wurde, lassen sich Deine Probleme wie folgt lösen. Schau Dir mal unter diesem Abschnitt die zweite Zeile der Tabelle an. Wenn Du das Werk im Abschnitt "Einzelnachweise" speicherst, kannst Du im Fließtext mit "ref extends" die gewünschte Quelle von der ersten Aussage an, die Du belegen möchtest, mit einer Seitenzahl besetzen.

Dein zweites Problem enthält den Fehler, dass Du versuchst, zwei verschiedene Quellen in einem Beleg unter "ref name="Atlantis" unterzubringen. Es darf aber in einer Referenzangabe nur eine Quelle eingebettet sein. Also wie folgt:

<ref name="Müller">Max Müller: ''Atlantis.'' Berlin 1901, S. 123</ref><ref name="Schulze">Sebastian Schulze: ''Regierungsformen in Atlantis.'' Wien 1902, S. 23.</ref>

Viele Grüße -- Ra'ike _Disk. ^P:MIN 11:38, 17. Jan. 2024 (CET)

Hallo @Ra'ike, vielen Dank für die Antwort.

Zu dem ersten von Dir behandelten Problem bin ich der gleichen Ansicht wie Du und habe das im letzten Satz meines Kommentars vom 9. Mai 22 auch so geschrieben. Ich habe mir damals vielmehr vorgestellt, wie Menschen vorgehen, die so arbeiten wollen wie bisher, und die würden die Ergänzung der Seitenzahl einfach in die vormalige Referenz ohne Seitenzahl eintragen. Man wird also gezwungen, anders zu arbeiten als bisher. Mein Punkt war also nicht, dass die neue Methodik keine Lösung hat, sondern dass es mit einem unzutreffenden und damit intransparenten Argument umworben wird, denn man muss zu allen Regeln, die man beim Wikifizieren befolgen muss, wieder neue dazu lernen. Das hat so einen Touch von „Vielen wird es besser gehen, niemandem wird es schlechter gehen“.

Bei der Beschreibung des zweiten Problems versuche ich aus der Sicht eines Korrektors zu verdeutlichen, was passieren kann, wenn Autoren in alter Manier Seitenzahlen einpflegen wollen und dann auch mal zwei Quellen in einer Fußnote etablieren. Artikel wie Bahnstrecke Mering–Weilheim enthalten z. B. zahlreiche „Sammelfußnoten“, die leserlich zusammengestellt wurden. Das oft diskutierte Zusammenbringen zweier Quellen in einer Fußnote ist Praxis und wird hier beschrieben. --T. Wirbitzki (Diskussion) 13:11, 17. Jan. 2024 (CET)

Hallo T. Wirbitzki, ich muss zugeben, dass mir die Praxis, mehrere Einzelnachweise in einer Belegangabe zu packen, bisher nicht bewusst war und bin leicht entsetzt (und hoffentlich auch andere) über diese Empfehlung auf der Hilfeseite. Das kann auch nur gutgehen, wenn diese mehreren Belege in einem Nachweis nur einmal an dieser Textstelle gebraucht wird. Die Verwendung der zukünftigen Erweiterung mit flexiblen Seitenzahlen verbietet sich in solchen Fällen dann auch.

Gerade ist mir aber auch aufgefallen, dass auf „der Rückseite“ dazu schon diskutiert wird. Das geh ich mir mal anschauen... Viele Grüße -- Ra'ike _Disk. ^P:MIN 14:56, 17. Jan. 2024 (CET)

Dass es Problem gibt, wenn man nachträglich etwas einträgt ohne alle Verwendungen zu berücksichtigen ist, findet man schon bei "name=". --Enhancing999 (Diskussion) 15:34, 17. Jan. 2024 (CET)

Ja, das Problem gibt's schon, die anderen kommen neu dazu, sobald man die Erweiterung einbaut. Eine falsche Verwendung des Attributs „name“ wird allerdings dadurch entschärft, dass der Nutzer zeitnah vor dem Speichern ein Feedback der Art „Referenzfehler: Ungültiges <ref>-Tag ...“ erhält. Die Erweiterung ist jedoch in dem Sinne konstruiert, dass alles zwischen öffnendem und schließenden ref-Tag stehen darf, also „weiß“ die Software sehr wenig, um Text zur Beschreibung des Werks von Text über die Fundstelle innerhalb des Werks zu unterscheiden, sodass automatisierte Hilfestellungen für Anfänger schwierig werden. --T. Wirbitzki (Diskussion) 17:09, 17. Jan. 2024 (CET)

Ich denke nicht, man sieht eine Fehlermeldung, wenn man

<ref name="blabla">Bibel, Buch ..</ref>

in

<ref name="blabla">Bibel, Buch .., 1-3 </ref>

ändert, auch wenn

<ref name="blabla" />

anderswo verwendet wird. --Enhancing999 (Diskussion) 17:17, 17. Jan. 2024 (CET)

Ja, das stimmt. Ich hatte gedacht, es geht Dir um die Änderung des Namensattributs. Vor einiger Zeit habe ich noch geglaubt, man könnte durch Tags, Attribute oder gar Vorlagen diese Beliebigkeit der Texte innerhalb von ref-Tags in den Griff bekommen, doch jetzt würde ich auch lieber die Umsetzung der Erweiterung sehen, weil der „Stau“ in der Erneuerung schwer erträglich ist. Man sollte allerdings auf Anfängerfragen zu den neuen Features sensibel reagieren. --T. Wirbitzki (Diskussion) 17:28, 17. Jan. 2024 (CET)

Persönlich tendiere ich dazu die ganze Referenz mit einem Namen im Abschnitt "Einzelnachweise" zu hinterlegen und nur <ref name="blabla" /> im Text zu verwenden. Die "extends" Funktion würde das noch bequemer machen. --Enhancing999 (Diskussion) 17:38, 17. Jan. 2024 (CET)

2023 Dezember 20: Stand der Entwicklung der neuen Funktion

Was steht dies jetzt? Wird es noch umgesetzt? Wenn ja, wann (auf dieser Wikipedia)?

Ich fand dazu https://phabricator.wikimedia.org/tag/cite-extends/ und https://phabricator.wikimedia.org/project/profile/4256/ --Enhancing999 (Diskussion) 12:09, 20. Dez. 2023 (CET)

Hallo Enhancing999, ich bitte um Verzeihung für die späte Antwort. Unser Team nimmt die Arbeit an diesem Projekt gerade wieder auf und wir rechnen damit, im Laufe dieses Jahres fertig zu werden. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 17:40, 11. Jan. 2024 (CET)

Test der bisherigen Umsetzung im Wikitext

Eine Anleitung zum Testen dessen, was bisher für den Wikitextmodus umgesetzt wurde, folgt in Kürze. Parallel zum Technische-Wünsche-Treff kann dann auch hier getestet und kommentiert werden. -- Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 14:13, 15. Jan. 2024 (CET)

Danke für die Updates. Ref mit "extends" gibt z.Z.: <ref extends="Pierson">S. 131 </ref> :d.h. Referenzfehler: Ungültiger Parameter in <ref>. :bzw. Cite error: Invalid parameter in <nowiki><ref> tag

Wird es aktiv, könnte man damit https://de.wikipedia.org/w/index.php?oldid=241186092#Literatur umformattieren. --Enhancing999 (Diskussion) 14:59, 15. Jan. 2024 (CET)

Vorlage:rp

In der Schilderung der Problemstellung heißt es: Alternativ kann ich Vorlagen nutzen, die aber nicht jeden Fall gut abbilden. Ich fasse das als Kommentar zur Vorlage:rp auf, die es seit dem Jahr 2007 gibt. In en.Wikipedia ist die Vorlage mit um die 60.000 Einbindungen recht verbreitet, während sie in de.Wikipedia deutlich weniger verwendet wird (3655 Einbindungen). Warum eigentlich? Ist die Vorlage zu unbekannt, oder wird die Darstellung mit Seitenzahlen hinter der Referenz-Nummer abgelehnt? --Kallichore (Diskussion) 18:11, 31. Jan. 2024 (CET)

Letzeres ist der Fall.

In diesem Wiki hier wird breit abgelehnt, weil für unser Publikum maximal unverständlich:

• Aussage^{[14]:26[23]:114–118[7]:4}

Deshalb wird diese Vorlage nur fluchend geduldet, bis es eine bessere Lösung gibt.

Sobald es nach vielen vielen Jahren endlich endlich endlich die umseitige Lösung gibt, wird die genannte Vorlage flächendeckend aus dem ANR herausgebaut werden; ein LA ist wahrscheinlich schon irgendwo getippt worden.

VG --PerfektesChaos 19:37, 31. Jan. 2024 (CET)

Wiederverwendung eines Einzelnachweises aus der Literatur

Hier habe ich eine Literaturangabe auf eine Referenz verweisen lassen, um die Wiederholung von Verlag, Ort und Jahr zu sparen. Das Beispiel zeigt, dass alles zwischen zwei ref-Tags stehen kann, nicht nur Fundstellen. Wenn eines Tages der seltene Fall eintritt, dass die Literaturempfehlung vom Einzelnachweis abweicht, müsste dieser Verweis wieder abgebaut werden.

Eigentlich möchte ich hier kein „ref extends“, sondern ein „ref expands“ bzw. „ref invoke“, also ein Herkopieren einer wiederverwendbaren Quelle, denn der Fußnotenverweis ist unnötig, weil ich mich ja nicht mehr im Fließtext befinde. Wahrscheinlich würde ich in der Praxis auf solch eine Wiederverwendung aus der Literatur heraus verzichten, weil das zu umständlich ist. --T. Wirbitzki (Diskussion) 05:42, 6. Feb. 2024 (CET)

So wie es in der en-wikipedia schon seit ein paar Jahren üblich ist. Da steht dann Nachname des Autors das Jahr und die Seitenzahl. Geht man dann darauf landet man bei dein Einzelnachweisen und der entsprechende Literatureintrag leuchtet auf... --Mr.Lovecraft (Diskussion) 18:05, 20. Feb. 2024 (CET)

Das entspricht der Harvard-Notation, für die ich mich hier regelmäßig stark mache. Im enWiki wird diese Notation aber bereits durch die Literaturvorlage unterstützt, die dazu aber eine Trennung von Vor- und Nachnamen der Autoren vorsieht. Das funktioniert aber bei mehreren Autoren eines Titels nicht mehr. Daher sollte die Kurznotation aus Autor und Jahr ein frei wählbarer Text sein. Wikipedianer können dann flexibel auf unterschiedlichste Sonderfälle (z. B. zwei Veröffentlichungen eines Autors im selben Jahr) reagieren. --Vollbracht (Diskussion) 23:06, 1. Mai 2024 (CEST)

greatquestion

Hallo Thereza, danke für den Hinweis Spezial:Diff/243033575/243457642 zum technischen Wunsch „Wiederverwendung von Einzelnachweisen vereinfachen“. Darin bittet ihr darum, sich auf greatquestion.co einzutragen. Beim Lesen von deren Privacy Statements gruselt es mich aber. Könntet ihr für solche Umfragen nicht Plattformen nehmen, die Daten nicht an Dritte - unter anderem zu Werbezwecken - weitergeben und nicht in Staaten außerhalb der Gültigkeit der DSGVO verarbeiten, vorzugsweise eine Wikimedia-Plattform? Die Plattform greatquestion.com möchte ich unter den Bedingungen nicht nutzen. --man (Diskussion) 20:24, 2. Apr. 2024 (CEST)

Hallo @DeWikiMan, danke für deinen Hinweis. Ich habe deine Bedenken weitergegeben und diesbezüglich bei meiner Kollegin nachgefragt. Derzeit warte ich noch auf eine Rückmeldung und bitte dich um etwas Geduld. Ich bin nun erstmal im Urlaub, daher wird sich vermutlich Johanna Strodt (WMDE) dazu bei dir melden. Nur, dass du dich nicht wunderst. Beste Grüße --Thereza Mengs (WMDE) (Diskussion) 14:38, 3. Apr. 2024 (CEST)

Ich unterstütze die Anfrage. Der Eingriff in die Privatsphäre ist schon ein wenig krass für einen Softwaretest. Ihr könntet die Funktion auch einfach in einem Testwiki freischalten und dann das Feedback der Tester abwarten. Am Ende wollt Ihr wissen mit welchen Tools die Autoren arbeiten wollen, und nicht welche Tools Ihr oder Eure Entwickler für sinnvoll haltet nach Auswertung irgendwelcher Videos nach einem 20-minütigen Test. Im Zweifel fragt Ihr hier das Falsche ab und die Entwicklung rennt, mal wieder, in die falsche Richtung. Derartig komplexe inhaltliche Strukturen (wie die mehrfache Einzelnachweisverwendung ist) bearbeiten eher erfahrene Benutzer. Die Frage wie schnell sich ein Benutzer damit zurechtfindet ist daher im Zweifel von nachrangiger Bedeutung. Grüße --Millbart talk 09:30, 6. Apr. 2024 (CEST)

Hallo @DeWikiMan und @Millbart, wie angekündigt melde ich mich während Therezas Abwesenheit, wenn auch erstmal mit einem Zwischenstand: Den Anbieter haben wir gefragt, was genau da mit Dritten geteilt wird, und es kann sein, dass es dazu schon eine Antwort gab, aber aufgrund von Krankheit im Team hat sie mich zumindest noch nicht erreicht. Ich melde mich hier nochmal, wenn es Neues gibt. Wir probieren diese Art des Testens zum ersten Mal aus, und das Feedback von euch und anderen hilft uns dabei, herauszufinden, ob wir diese Methode in Zukunft wieder anwenden wollen. Darum auch von mir nochmal danke.

Natürlich verstehen und respektieren wir, dass sich nicht alle wohl dabei fühlen, sich selbst aufzuzeichnen. Man kann die Funktion übrigens (schon seit einer ganzen Weile) auch ohne Aufzeichnung ausprobieren und im Wiki Feedback dazu hinterlassen. Der jetzige Test auf GreatQuestion soll das Feedback im Wiki auch nicht ersetzen, sondern erweitern, weil schriftliches Feedback in der Regel deutlich weniger Aufschluss darüber gibt, wie Leute konkret mit einer Funktion umgehen, wo sie stolpern usw. Sowas zeigt sich besser, indem man Menschen dabei über die Schulter schaut. Dass jene, die schon lange in den Wikis aktiv sind, sich eh stärker in die neue Funktion einfuchsen werden, mag stimmen. Unser Anspruch ist aber, die Funktion auch für sie bestmöglich nutzbar zu machen, und wir sehen solche Tests als hilfreichen methodischen Baustein, um das zu erreichen.

Wäre es okay für euch, wenn ich die Unterhaltung nach Wikipedia Diskussion:Technische Wünsche/Topwünsche/Erweiterung der Einzelnachweise verschiebe? — Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 18:10, 9. Apr. 2024 (CEST)

Ich bin mit der Verschiebung einverstanden. Schönen Gruß, --man (Diskussion) 22:23, 9. Apr. 2024 (CEST)

Kannst Du gerne verschieben. --Millbart talk 11:55, 11. Apr. 2024 (CEST)

@DeWikiMan: GreatQuestion hat sich zurückgemeldet: Sie haben ihr Privacy Statement überarbeitet, weil tatsächlich keine Informationen mit Dritten zu Werbezwecken geteilt werden. Danke nochmal für deine Nachfrage, und ein schönes Wochenende. -- Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 16:54, 12. Apr. 2024 (CEST)

Einzelnachweisvorschau

Die Erweiterung funktioniert und passt perfekt zu meiner Arbeitsweise. Nur die Vorschau beim Hovern über der Fußnote könnte noch verbessert werden. Momentan steht im Tooltip nur die Seitenangabe, aber nicht der eigentliche Einzelnachweis, auf den sie sich bezieht. --Rodomonte (Diskussion) 22:32, 12. Apr. 2024 (CEST)

Verkomplizierung

Mein Eindruck nach etwas Herumspielen im Beta-Wiki: Der Quelltext des Artikels wird mit zusätzlichem kryptischen Informatiker-Sprech belastet, sodass das Bearbeiten schwieriger wird. Und als Leser muss man, wenn man auf einen der Einzelnachweise mit der neuen Technik klickt, erst einmal wieder hochscrollen, um den Beleg zu finden, weil der Browser nur auf die Seitenzahl springt. Also wird auch das Lesen der Artikel schwieriger. Ich befürchte wirklich, dass diese Funktion, nachdem sie jetzt extra entwickelt wurde und so prominent beworben wird, tatsächlich von Leuten genutzt wird. Als wäre Wikipedia nicht schon kompliziert genug. Es tut mir ja leid um die Arbeit, die da hineingeflossen ist, aber mir fällt es wirklich schwer, da eine Verbesserung zu sehen. Mag mir jemand auf die Sprünge helfen? --DerMaxdorfer (Diskussion) 22:24, 14. Apr. 2024 (CEST)

Hallo @DerMaxdorfer:, ich suche jetzt schon die ganze Zeit nach dem konstruktiven Element deines Beitrags. Der Bedarf nach einer Abbildung von Seitenzahlen ohne endlose Dupplikation scheint mir (endlich) gesetzt zu sein. Hier geht es nicht um das ob, sondern allein um das wie. Die Verbesserung besteht darin, dass mit dem Vorschlag endlich eine praktikable Lösung zur Verfügung stünde. Gruß --Albrecht62 (Diskussion) 17:15, 16. Apr. 2024 (CEST)

Okay, also es geht lediglich darum, Buchstaben zu sparen? --DerMaxdorfer (Diskussion) 17:35, 16. Apr. 2024 (CEST)

Ach so, zum Thema konstruktives Element: Umseitig wurde explizit dazu aufgerufen, hier Rückmeldung zu geben über die Versuche mit der neuen Technik. Ich habe die neu entwickelten Möglichkeiten in Ruhe ausprobiert und meine Rückmeldung lautet, dass die befürchteten Nachteile tatsächlich eingetreten sind und dass ich nur wenig Vorteile finde. (Wenig = eigentlich nur die Einsparung von Zeichen.) --DerMaxdorfer (Diskussion) 17:38, 16. Apr. 2024 (CEST)

Nur, um Buchstaben zu sparen? Ist das jetzt Unlust, wenigstens einmal kurz über mögliche Vorteile nachzudenken, oder gewollte Provokation?

Natürlich geht es nicht darum, Buchstaben zu sparen, sondern darum, zum einen die Pflege zu erleichtern, indem Quellen nicht x-mal aufgeführt und bei jeder Änderung x-fach angepasst werden müssen, viel wichtiger aber noch, dem Leser einen besseren Überblick zu verschaffen. Er sieht dann auf den ersten Blick, dass auf dasselbe Werk von verschiedenen Stellen aus verwiesen wird, anstatt jedes mal erst die Fußnote anklicken zu müssen, um dann zu sehen, dass er die Quelle bereits kennt. Zudem führt es zu einer konsistenteren Liste an Belegquellen, denn redundante Datenpflege führt erfahrungsgemäß auf die Dauer immer zu Inkonsistenzen. --H005 (Diskussion) 17:19, 2. Mai 2024 (CEST)

Reihenfolge

Aktuell entspricht die Reihenfolge der Einzelnachweise der Reihenfolge der Ersterwähnung im Artikel. Soweit ich das Beispiel im Beta-Wiki verstehe, ist das hier auch so gedacht (was ich schade finde, aber dazu später mehr). Also ich bringe mal ein Beispiel: „Dieser Satz ist belegt.[Buch 2, S. 3] Aber auch dieser Satz ist belegt.[Buch 1, S. 99] Ein dritter Satz ist auch belegt.[Buch 2, S. 1]“ Die Reihenfolge in den Belegen wäre jetzt: Buch 2, S. 3 und S. 1 und Buch 1, S. 99. Wenn aber die Literatur bspw. chronologisch oder nach Nachnamen sortiert sein soll, ist eine andere Reihenfolge sinnvoll (hier: Buch 1 VOR Buch 2). Außerdem ist es doch viel besser, wenn ich das Buch in der Hand habe, die Seiten numerisch und eben nicht in der Reihenfolge des Artikels aufzulisten. Fragt sich wie man das umsetzt? Mein Vorschlag wäre der name-Tag, bspw: <ref name="buch_2-3">. Natürlich sollte das nicht die zwingende Lösung sein, sondern nur eine Option. Aber das wäre schon richtig gut. Beste Grüße --Fan-vom-Wiki (Diskussion) 00:01, 17. Apr. 2024 (CEST)

Wird der VisualEditor unterstützt?

Hi, ich habe gerade einen Test im Beta-Wiki versucht (weil ich die Funktion im gerade frisch angelegten Artikel Magdalenen-Terrasse schmerzlich vermisst habe) und bin sofort und komplett gescheitert. Kann das vielleicht daran liegen, dass der von mir verwendete visuelle Editor nicht unterstützt wird und ich für einen Test zwingend den Quelltext-Editor nutzen müsste? Falls dem so ist, sollte man das vielleicht auf der Vorderseite im Abschnitt "Teste die neue Funktion" deutlich machen?

Außerdem: Die Wahl des Begriffs "extends" erschließt sich mir nicht. Wie seid ihr auf ihn gekommen?

Vielen Dank und Gruß, --Gnom (Diskussion) Wikipedia grün machen! 12:44, 17. Apr. 2024 (CEST)

Kleiner Einwurf: Siehe auf der Vorderseite den Abschnitt Wikipedia:Technische Wünsche/Topwünsche/Erweiterung der Einzelnachweise#Im VisualEditor. --DerMaxdorfer (Diskussion) 17:16, 25. Apr. 2024 (CEST)

@Gnom: Danke für die Rückmeldung. Auf der Vorderseite stand es in der Tat recht versteckt, ist jetzt geändert. "Extends" war vor ein paar Jahres das Ergebnis einer längeren Feedbackschleife. Die Idee ist, dass man mit diesem Attribut einen bestehenden Einzelnachweis erweitern – also „extenden“ – kann. Von den Tests auf dem Beta-Wiki erhoffen wir uns aber auch Feedback zur Bezeichnung, insofern schon mal danke. Hast du vielleicht Ideen, was besser wäre?

Danke auch an @DerMaxdorfer für die Antwort. -- Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 17:48, 25. Apr. 2024 (CEST)

Danke @Johanna Strodt (WMDE) und @DerMaxdorfer. Ich konnte es jetzt testen und habe es auch verstanden. Der fehlende Support für den VisualEditor schmerzt aber wirklich sehr. Und den Begriff "extends" verstehe ich auch mit der Erläuterung nicht. Warum das "s" und nicht "extend"? Wenn wir nur in der DEWP wären, hätte ich einfach "Fundstelle" vorgeschlagen. Ich weiß aber nicht, ob der Begriff eine englische Entsprechung hat. --Gnom (Diskussion) Wikipedia grün machen! 11:44, 28. Apr. 2024 (CEST)

@Gnom: Die Wortwahl „extends“ geht darauf zurück, dass mal die „Funktionalität 2018“ erweitert werden sollte auf „Funktionalität mehr als früher“.

Das war ein Denkfehler seit Urzeiten im Wiki-Software-Entwicklungs-Prozess, wozu ich mich eins drunter bereits geäußert hatte.

Wenn das Feature im VisualEditor nicht angefasst werden kann, darf und kann diese Funktion nicht eingeführt werden, weil VE-Nutzer sonst keine <ref> mit Plus mehr editieren könnten.

VG --PerfektesChaos 12:14, 28. Apr. 2024 (CEST)

@Gnom: Guten Morgen. Ich hoffe, ich kann deine Schmerzen ein wenig lindern, wenn ich sage, dass diese neue Funktionalität ohne Unterstützung im visuellen Editor nicht ausgerollt werden soll. Bislang gibt es diese Unterstützung nur noch nicht – darum wird aktuell erstmal nur der Wikitext getestet, aber VE kommt noch.

Zum Namen des Attributs: Die Idee war, dass der Wikitext sich mit dem Attribut quasi als Satz lesen lässt: <ref extends="Pierson"> soll soviel bedeuten wie „Dieser Einzelnachweis erweitert den bereits angelegten Einzelnachweis namens Pierson.“

Die englische Entsprechung von Fundstelle kenne ich auch nicht. Falls es da eine Entsprechung gibt, müsste sie auch für Menschen, die kein oder kaum Englisch sprechen, gut verständlich sein. Wenn jemand ein solches Wort kennt, gerne melden. -- Viele Grüße und einen guten Start in die Woche, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 09:17, 29. Apr. 2024 (CEST)

Super, danke dir. --Gnom (Diskussion) Wikipedia grün machen! 13:38, 29. Apr. 2024 (CEST)

Namensgebung für das neue Attribut

@Johanna Strodt (WMDE): Mit Interesse habe ich jetzt hier gelesen, dass die Namensgebung für das neue Attribut noch nicht endgültig festgeschrieben ist.

• Dann ließe sich last minute vielleicht noch was machen.
• Die Kritik bzw. Verwunderung kann ich nachvollziehen.

Was ginge, was geht nicht?

• sub – in praktisch allen lateinisch verschrifteten Sprachen verständlich als irgendeine untergeordnete Einheit.
  • Substruktur, Subkultur, Substandard, Subspezies.
  • Adressiert wird jeweils eine bestimmte Untereinheit des Hauptwerks name.
• part – noch so ähnlich, aber nicht ganz so universell in den Sprachen.
• extends – so semi, ziemlich nerdig.
  • Nachvollziehbar, wenn die Vorgeschichte der letzten anderthalb Jahrzehnte bekannt ist.
  • Nicht zukunftsfähig, weil es auf einen Zustand „vorher“ und „danach“, also erweitert abhebt.
  • Es sollte durch das Datenmodell der Attribute jedoch zeitlos elegant die abgebildete Realität wiedergegeben werden.
  • Es war mal ein Anfängerfehler in den frühen 2010er Jahren, als MediaWiki jedes neu eingeführte Feature als „new“, „extended“, „enhanced“ bezeichnet hatte. Immer ein Jahr später wurden diese Optionen völlig unverständlich, weil niemandem mehr bewusst war, welche Funktionalität es vor dem new gewesen war und was da jetzt hinzugekommen sei und durch genau welche konkreten Möglichkeiten es dann irgendwie „erweitert“ wurde.
  • Nachdem ich mich da Mitte der 2010er mal energisch gegen derartiges Vokabular ausgesprochen hatte, hießen die Dingse dann Quelltext-Editor „2017“ und Vector „2022“ – immerhin ein konkret zu verortender Meilenstein in der Entwicklung, statt „new“, „newer“, „newest“.
• page – völlig ungeeignet.
  • Es gibt nicht nur Seitenzahlen, sondern auch Spaltenzahlen, Abschnitte, Unterabschnitte, Paragrafen, Kapitel, Versnummern und vielerlei Untergliederungen des Gesamtwerks, auf die Bezug genommen werden könnte.

VG --PerfektesChaos 22:48, 25. Apr. 2024 (CEST)

@PerfektesChaos: Danke, ich hab das mit aufgenommen. -- Beste Grüße und ein schönes Wochenende, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 10:12, 26. Apr. 2024 (CEST)

Mir ist der Name im Grunde egal. Aber eigentlich geht es doch nicht um eine Erweiterung, sondern um eine Konkretisierung. Vielleicht könnte das irgendwie in den Namen einfließen. --Rodomonte (Diskussion) 11:02, 26. Apr. 2024 (CEST)

Es geht eher um einen Teil von einem Ganzen als um eine Erweiterung, daher passen sub und part besser als „extends“. Konkretisieren (z. B. specify) kann man hier auch als das Lokalisieren einer Stelle im Werk sehen, dann bekommen wir einen locator, siehe auch hier. Knapp wenn auch vage wären detail oder hint. Man sollte den Namen halt in 5 Jahren auch noch mögen :-) --T. Wirbitzki (Diskussion) 08:30, 27. Apr. 2024 (CEST)

+1 für sub. Kurz, bündig, einprägsam, leicht zu merken und wiederzuerkennen. -- Karl432 (Diskussion) 09:34, 27. Apr. 2024 (CEST)

Wenn man ref sub="Pierson" schreibt, kann man das so verstehen, dass "Pierson" das untergeordnete Element ist, es ist jedoch das übergeordnete, besser wäre also subOf. Es war doch vermutlich nicht gemeint, dass das Tag sub heißen soll, es geht doch um das neue Attribut? --T. Wirbitzki (Diskussion) 10:20, 27. Apr. 2024 (CEST)

Es gilt <ref name="Pierson" sub="S. 123">, falls ich dein „Pierson“ richtig verstanden habe.

Oder aber <ref name="BiogrLex" sub="Pierson"> wenn „Pierson“ der einzelne Eintrag im Sammelwerk Biografisches Lexikon sein soll.

Es muss ein allgemeines Sammelwerk <ref name="BiogrLex"> konventionell definiert sein, das für alle Einzel-Fundstellen die gemeinschaftlichen bibliografischen Angaben spezifiziert.

VG --PerfektesChaos 12:21, 28. Apr. 2024 (CEST)

Danke für die Klärung, das hatte ich übersehen, dann passt das gut mit dem sub. --T. Wirbitzki (Diskussion) 13:05, 28. Apr. 2024 (CEST)

Ich kannte eine Version, wo die Seitenzahl zwischen öffnendes und schließendes ref-Tag geschrieben wird. --T. Wirbitzki (Diskussion) 13:47, 28. Apr. 2024 (CEST)

@T. Wirbitzki, @PerfektesChaos: Die Syntax, an der gearbeitet wird, lautet in der Tat <ref extends="Pierson"> S. 135 </ref>: Die Seitenzahlen werden also zwischen dem öffnenden und schließenden Ref-Tag definiert, nicht im öffnenden Ref-Tag. Die technische Umsetzung wurde damals lange mit Teams der Wikimedia Foundation diskutiert, teils kann man das hier und hier auf Phabricator nachlesen. -- Beste Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 09:44, 29. Apr. 2024 (CEST)

Ich war für einige Jahre raus.

• Ich weiß nicht mehr, seit wann das Projekt als Top-Wunsch-Feature von WMDE eingestuft wurde.
• Erörtert wird sowas seit einem Jahrzehnt.
• Wann das zuerst in WMDE-Technische-Wünsche vorgeschlagen wurde, weiß ich auch nicht mehr.
• Aber es gab wohl 1000 Bildschirmseiten auf mehreren Wiki-Seiten; mag das Gigabyte Text angestrebt haben.
• Von der Textmenge waren wohl >90 % nicht unmittelbar zweck- und lösungsinterpretiert.
  • Gefühlt 50 % erörterten allgemeine Wiki-Befindlichkeit, Publikationsdaten, Bibliografien, Wikidata, Zitationsregeln und liefen komplett an einer zu entwickelnden Software vorbei.
  • Ich hatte das Thema deshalb über Jahre komplett von der Beo genommen und das nicht mehr verfolgt.

Mein letzter Stand war gewesen, dass der Attributwert dem ref-Kontext nach Art eines Vorlagenparameters zur Verfügung gestellt würde; siehe ein Abschnitt drunter.

VG --PerfektesChaos 13:33, 29. Apr. 2024 (CEST)

Danke für die Klärung. Dann bleibe ich dabei, dass ref sub="Quelle X" eine Verschlechterung des Verständnisses für den Neuling darstellt, der das Gleichheitszeichen (=) ja als eine Gleichsetzung verstehen darf, und das würde den Sinn verkehren. Analog zu extends sollte vielmehr ein Verb gewählt werden, das die Beziehung zur Hauptquelle ausdrückt, z.B. „details“, „adds“, „specifies“ oder vielleicht „locates“. Oder man kehrt vom bisherigen Stil ab und nimmt eine Eigenschaft, dann müsste es aber eher „super“ (das aber wieder die Bedeutung von extends hat), „summary“, „parent“ oder „root“ heißen. Mein Favorit wäre „main“. --T. Wirbitzki (Diskussion) 08:45, 30. Apr. 2024 (CEST)

Mir würde nach einigem Nachdenken folgende Lösung am besten gefallen: <ref name="Pierson" add="S. 123" />

Begründung: <ref name="Pierson" /> ist heute bereits die verbreitete Methode, um einen vorhandenen Beleg wiederzuverwenden. Man will nun ja lediglich den vorhandenen Verweis an dieser Stelle durch "irgendwas" (also eine Seitenzahl, ein Kapitel, eine Randnummer, ein Kommentar ....) ergänzen. Dazu muss man hier lediglich ein add="irgendwas" hinzufügen, was ja genau das ist, was man will. "Add" dürfte sowohl für Deutschsprechende als auch Fremdsprachler recht leicht zu verstehen sein. Ich halte das für die intuitivste und am einfachsten zu merkende Lösung. -- H005 (Diskussion) 17:38, 2. Mai 2024 (CEST)

Hier werden Vorschläge für eine Formulierung gemacht, mit der Code die Darstellung von viel Text vereinfachen soll. Ich halte das für wenig leserfreundlich. In langen Verzeichnissen von Einzelnachweisen bin ich als Leser immer dankbar, wenn ich optisch schnell erfassen kann, welche Literatur immer wieder referenziert wird. Dazu dient die Kurznotation von Einträgen. Von einer solchen Kurznotation sollte aber stets auf die vollständige Notation verlinkt werden.

Die Formulierung <ref name="Pierson" /> dient dazu, einen irgendwie gearteten EN unverändert wieder zu verwenden. Dieser eine Eintrag wird dann automatisch mit zwei Positionen im Haupttext verlinkt. Mit ... add="S. 123" müsste automatisch ein weiterer Eintrag erzeugt werden. Wenn die originale ref "Pierson" eine Kurzreferenz wäre, könnten wir uns das getrost sparen und direkt eine neue Kurzreferenz "Pierson123" formulieren. Wäre es hingegen eine vollständige Referenz, würde uns als Lesern wieder die Übersichtlichkeit flöten gehen. Abgesehen davon, dass die Codierung, wenn überhaupt, nur wie von Johanna Strodt beschrieben gestaltet werden dürfte, halte ich das für konzeptionell falsch.

Aber auch hier gilt, dass wir erst überlegen sollten, welches Ziel wir mit unserer Vereinfachung anstreben. Eine Diskussion darüber läuft gerade im genau nächsten Thread: #Ist ein einzelnes Attribut eigentlich hinreichend?

Unabhängig davon, dass ich eine zweistufige Struktur (s. u.) präferiere, könnte eine künftige Codierung so aussehen:

 <ref><lit name="Pierson 1998">Paul Pierson: ''Über das Liebesleben der Pflastersteine.'' Infrastrukturverlag, Entenhausen 1998.</lit> S. 123</ref>

Die Kurzversion wäre dann:

<ref><lit name="Pierson 1998" /> S. 234</ref>

In jedem Fall würde ein Link zu der Stelle, wo die Langversion steht, mit dem Linktext "Pierson 1998" in den Kurzreferenzen stehen und könnte mit tooltip (wo verfügbar) direkt über das Buch informieren.

Ich selbst halte mehrfach referenzierte Literatur für wert, im Literaturverzeichnis eines Artikels aufzuführen. Ich schlage daher vor, standardmäßig vor dem references-Block, vorzugsweise an einer mit <literature /> bezeichneten Stelle alle lit-Elemente in der Form

• "Pierson 1998" - Paul Pierson: Über das Liebesleben der Pflastersteine. Infrastrukturverlag, Entenhausen 1998.

auszugliedern. Dann hätten wir eine klare, leicht zu vermittelnde zweistufige Struktur. Wir können aber auch darüber nachdenken, dem lit-Tag optional einen Parameter ... type="inline" mitzugeben, der dafür sorgen würde, dass das Element nicht ausgegliedert, sondern (ohne Schaden für mögliche Verlinkungen aus Kurzreferenzen heraus) im EN stehen bliebe. --Vollbracht (Diskussion) 14:47, 3. Mai 2024 (CEST)

Ich finde zweistufige Referenzierungen ausgesprochen hässlich und unpraktisch und verzweifle in der englischen Wikipedia regelmäßig daran, wenn das dort alles nicht mehr zusammenpasst und man hin und her scrollen muss, um die Zusammenhänge herauszufinden. Natürlich kannst du das trotzdem machen, aber darum geht es an dieser Stelle doch überhaupt nicht. Hier geht es um die bereits weit gediehene Implementierung der schon vor längerer Zeit in größerem Kreis abgesprochenen Erweiterung und um syntaktische Details, die noch optimiert werden können. --Rodomonte (Diskussion) 14:55, 3. Mai 2024 (CEST)

Deine Argumentation zieht nicht! Wenn wir im Tool Tip bereits sehen können, welche Literatur im Detail gemeint ist, muss man nicht hin und her scrollen um Zusammenhänge herauszufinden und es passt selbstverständlich stets alles zusammen.

Geschmäcker können verschieden sein. Aber Übersichtlichkeit kann man messen, nämlich daran, wie viel Text wir optisch erfassen müssen und wie gut dieser Text strukturiert ist.

Als Leser benötige ich im Zusammenhang jedes Textabschnittes die Info, mit der ich die Literatur eines EN identifizieren kann. Einmalig benötige ich zusätzlich zur Identifizierung auch die Info, wie ich dran komme. Wenn in jedem EN beide Infos stehen, leidet die Übersichtlichkeit enorm. --Vollbracht (Diskussion) 15:20, 3. Mai 2024 (CEST)

Wir sollten von Deinem Beitrag übrig behalten, dass Du eine Lösung präferieren würdest, in der <... type="inline" der Standard (default) und eine Ausgliederung mit <... type="hive" optional wäre, richtig? Solche Fragen (ob ausgliedern, oder nicht) sollten aber unten diskutiert werden. --Vollbracht (Diskussion) 15:31, 3. Mai 2024 (CEST)

Re: "Hier werden Vorschläge für eine Formulierung gemacht, mit der Code die Darstellung von viel Text vereinfachen soll. Ich halte das für wenig leserfreundlich." Ich kann dir nicht ganz folgen. Hier geht es um die Syntax des Wiki-Codes. Diese sollte für Autoren möglichst leicht zu verstehen und zu merken sein. Mit der Darstellung für den Leser hat das doch gar nichts zu tun.

Zur Darstellung: Hast du den Darstellungsvorschlag im Betatest gesehen? Ich fand den ziemlich gut und bin der Meinung, dass er deinen Wunsch "wenn ich optisch schnell erfassen kann, welche Literatur immer wieder referenziert wird" viel besser erfüllt als die Wiederholung mit Kurznotation. -- H005 (Diskussion) 18:09, 3. Mai 2024 (CEST)

Nein, habe ich nicht. Gib mir mal bitte einen Link! --Vollbracht (Diskussion) 18:31, 3. Mai 2024 (CEST)

Tja, wenn ich den hätte ... ich wurde während des Tests dorthin geleitet, aber habe ihn nicht gespeichert. Aber im Prinzip sah das so aus, dass in der Liste der Einzelnachweise erst die Literaturquelle in Langform kam (mit einer Ziffer) und darunter mit Einrückung eine Liste der jeweiligen Referenzierungen mit Zusatzangaben (jeweils mit der Ziffer der Hauptreferenz plus punkt plus Unterziffer).

Also ungefähr so:

7. Paul Pierson: Über das Liebesleben der Pflastersteine. Infrastrukturverlag, Entenhausen 1998.

7.1 Seite 324

7.2 Seite 43

Das ganze etwas schöner formatiert und mit den bekannten Pfeilen versehen, um zur Stelle im Text springen zu können. Und im Text wurden dann die Fußnoten mit ^[7.1] etc. angegeben. --H005 (Diskussion) 18:44, 3. Mai 2024 (CEST)

Ich habe mal ein Beispiel erzeugt. Das zeigt noch ein inakzeptables verhalten:

Hier muss Text mir relevanter Literatur belegt werden!<ref name="Bond 2007">James Bond: ''Waffentechnik für Dummies.'' In: C.I.5 (Hrsg.): ''Handreichungen für Doppelnullen.'' Geheimverlag, London 2007.</ref> Insbesondere muss da eine Textstelle berücksichtigt werden.<ref extends="Bond 2007">S. 123</ref>

liefert in etwa:

Hier muss Text mir relevanter Literatur belegt werden! Insbesondere muss da eine Textstelle berücksichtigt werden.

1. James Bond: Waffentechnik für Dummies. In: C.I.5 (Hrsg.): Handreichungen für Doppelnullen. Geheimverlag, London 2007.
   1. 1. S. 123

Wenn ich in das Verzeichnis der Einzelnachweise hinein gehe, dann sieht das aufgeräumt und übersichtlich aus. Auch darauf lege ich gerne Wert. Aber viel wichtiger ist doch, dass ich als üblicher Leser im Tool Tip bereits sehe, um welches Buch es überhaupt geht.

Spinnen wir das mal weiter! Nehmen wir mal an, wir wollten einige Titel aus einer Reihe referenzieren:

1. C.I.5 (Hrsg.): Handreichungen für Doppelnullen. Geheimverlag, London ab 2002.
   1. James Bond: Waffentechnik für Dummies. London 2007.
      1. S. 123.
      2. S. 234.
   2. Q: Phantom-Entwicklung für Dummies. London 2015.
      1. S. 345.

Unser Leser sieht im Haupttext nur, dass auf S. 123 verlinkt wird. Jetzt können wir nur hoffen, dass in den anderen Büchern der Reihe die S. 123 nirgendwo referenziert wurde. Dieses Problem besteht nicht, wenn die Aggregierung nicht über eine solche Struktur, sondern über sprechende Links geschieht:

==Literatur==

• C.I.5 (Hrsg.): Handreichungen für Doppelnullen. Geheimverlag, London ab 2002.
  • Bond 2007 - James Bond: Waffentechnik für Dummies. London 2007.
  • Q 2015 - Q (nicht genannter Autor): Phantom-Entwicklung für Dummies. London 2015.

==Einzelnachweise==

...

7. Bond 2007, S. 123.

8. Wurst

9. Bond 2007, S. 234.

10. Brötchen

11. Q 2015, S. 345.

...

Auch im Tool Tip wird dann die vollständige Kurzreferenz angezeigt. Die Kurznamen sollten wiederum Links auf die Einträge im Literaturverzeichnis sein, die den Text des Verzeichniseintrags im Tool Tip anzeigen. Den übergeordneten Eintrag (C.I.5, Handreichungen) ebenfalls anzuzeigen würde erheblichen Entwicklungsaufwand mit sich bringen. Darüber sollten wir noch mal diskutieren. Aber der Rest funktioniert und eine Vereinfachung der Codierung, wie oben beschrieben, wäre wünschenswert. --Vollbracht (Diskussion) 20:33, 3. Mai 2024 (CEST)

Was im Tool Tip angezeigt wird, ist doch noch einmal ein separates Thema. Ich weiß nicht, wie das im Moment umgesetzt ist, aber grundsätzlich könnte man da ja auch das Werk anzeigen.

Tool Tips sind übrigens auf Geräten mit Touchbedienung nicht verfügbar. Das ist nur eine nette Zusatzfunktion, aber nichts, was man voraussetzen kann.

Wenn ich im Tool Tip nur "Bond 2007, S. 123" sehe, ist das zwar besser als nur "S. 123", aber besonders sprechend ist das nicht, denn ich muss dann ja erst einmal auf der Seite herumsuchen, was genau mit "Bond 2007" überhaupt gemeint ist.

Die Form, die du in deinem Beispiel verwendest, entspricht nicht den Wikipedia-Richtlinien. Der Abschnitt "Literatur" ist nur für Literaturempfehlungen zum Thema gedacht, nicht für Einzelnachweise.

Einzelnachweise und Literatur müssen daher immer getrennt voneinander betrachtet werden.

In deinem Beispiel darf das Werk Handreichungen für Doppelnullen daher nur dann unter "Literatur" geführt werden, wenn es sich insgesamt besonders gut als vertiefende Lektüre zum Thema des Artikels eignet, nicht allein deswegen, weil es in Einzelnachweisen verwendet wird. Und wenn es in Einzelnachweisen verwendet wird, müssen dort auch mindestens Name des Autors/Herausgebers, Titel, Erscheinungsjahr und Seiten zusätzlich aufgeführt werden.

Siehe hierzu auch die Hinweise von @PerfektesChaos: unten im Abschnitt #Warum nicht die Anker-Vorlage vereinfachen und fertig? --H005 (Diskussion) 22:01, 4. Mai 2024 (CEST)

Wenn ich ein Werk in einem Artikel mehrfach zitiere, eignet es sich in jedem Fall als vertiefende Lektüre zum Thema. Und wenn es in der empfohlenen Literatur bereits vollständig beschrieben wird, kannst Du mir schwerlich begründen, dass dieselbe vollständige Beschreibung auch in den EN noch mal wiederholt werden sollte, nur weil die EN angeblich von der empfohlenen Literatur unabhängig sein müssten. Aber wenn in den EN nur eine Kurzreferenz steht, erwarte auch ich, ohne lange suchen zu müssen, alle relevanten Informationen, die ich brauche, zumindest direkt verlinkt. Bislang habe ich zu oft Artikel gelesen, in denen ein Werk im ersten EN vollständig aufgeführt wurde, danach aber nur noch mit rudimentären Angaben, aber ohne Verweis auf die vollständige Form. Was ich oben skizziert habe, will ich deshalb noch mal genauer ausführen. Hier also noch mal, was ich mir auch künftig wünsche (mit allen relevanten Tool Tips):

In den Einzelnachweisen die EN1 und EN2

Im Literaturverzeichnis:

• Bond 2007 – James Bond: Waffentechnik für Dummies. Geheimverlag, London 2007.

Im EN-Verzeichnis:

... aber am besten künftig alles generiert durch den Code:

In den Einzelnachweisen die EN1<ref><lit name="Bond 2007">James Bond: ''Waffentechnik für Dummies.'' Geheimverlag, London 2007.</lit>, S. 123.</ref> und EN2<ref><lit name="Bond 2007" />, S. 234.</ref>

Im Literaturverzeichnis:
<literature />

Im EN-Verzeichnis:
<references />

Wer die Tool Tips nicht nutzen kann, sollte mit einem Fingertip auf dem Link alle Informationen haben und ist mit 1-2 Rücksprüngen wieder im Haupttext. --Vollbracht (Diskussion) 23:25, 4. Mai 2024 (CEST)

Und hier noch eine meiner Meinung nach weitere wünschenswerte Form:

In den Einzelnachweisen die EN1<ref><lit name="Bond 2007" type="inline">James Bond: ''Waffentechnik für Dummies.'' Geheimverlag, London 2007.</lit>, S. 123.</ref> und EN2<ref><lit name="Bond 2007" />, S. 234.</ref>

Im EN-Verzeichnis:
<references />

... sollte nach meinem Dafürhalten dargestellt werden als:

In den Einzelnachweisen die EN1 und EN2

Im EN-Verzeichnis:

--Vollbracht (Diskussion) 04:17, 5. Mai 2024 (CEST)

@Vollbracht:

1. Zu Wenn ich ein Werk in einem Artikel mehrfach zitiere, eignet es sich in jedem Fall als vertiefende Lektüre zum Thema.: Auf gar keinen Fall! Es gibt hier Artikel mit weit über hundert Einzelnachweisen. Wenn darin ein Werk zwei mal vorkommt, ist das bei weitem kein Garant für eine generelle Eignung als Literatur. Sehr häufig behandelt ein Werk nur einen ganz bestimmten Einzelaspekt, auf den an zwei oder drei Stellen Bezug genommen wird.
2. Zu Und wenn es in der empfohlenen Literatur bereits vollständig beschrieben wird, kannst Du mir schwerlich begründen, dass dieselbe vollständige Beschreibung auch in den EN noch mal wiederholt werden sollte, nur weil die EN angeblich von der empfohlenen Literatur unabhängig sein müssten.: Das ist aber so erwünscht, siehe zum Beispiel unter Wikipedia:Zitierregeln#Abgleich_mit_den_Einzelnachweisen, unter Wikipedia:Literatur#Abgleich_mit_den_Einzelnachweisen und unter Hilfe:Einzelnachweise#Literaturbelege. Ich finde das auch richtig so. Es ärgert mich, wenn ich in der Fußnote nur ein "Bond, 2007, S. 123" finde, weil ich dann erst einmal herumsuchen muss, was das überhaupt genau für eine Quelle ist. Und wenn einer die Literaturliste ändert, also einen Eintrag löscht oder auf eine neuere Ausgabe aktualisiert, stimmen diese Verweise auch nicht mehr.

Du musst den Abschnitt in seiner Funktion so verstehen wie "Weblinks", nur dass es sich eben um Literatur handelt und nicht um Webseiten. Mit den Einzelnachweisen hat beides nichts zu tun. -- H005 (Diskussion) 20:41, 6. Mai 2024 (CEST)

Im ersten Punkt stimme ich Dir zu. Deshalb hatte ich auch die weitere wünschenswerte Form angegeben. Im zweiten Punkt belegen die Hinweise, auf die Du verlinkt hast,

• dass meine Empfehlung gelebter Praxis entspricht und
• ein Probleme, das dabei besteht und von meinem Vorschlag direkt adressiert wird.

Meinem Vorschlag folgend steht im Literaturverzeichnis eine relevante, in EN verwendete Literatur. Wer eine aktuellere Auflage derselben Literatur in das Literaturverzeichnis eintragen möchte, tut das einfach. Eventuell stehen dann zunächst zwei Auflagen dort. Das kann in seltenen Fällen sogar sinnvoll sein. Meist wird aber im EN dann einfach durch Hinzufügen eines einzelnen Attributs aus der ersten Form die zweite gemacht. In jedem Fall bleibt der Inhalt korrekt. --Vollbracht (Diskussion) 13:15, 7. Mai 2024 (CEST)

@H005: Die Lösung sieht auf den ersten Blick gut aus, doch sie entspricht nicht der Beta-Version, mit der (siehe Diskussion hier) Folgendes möglich sein soll:

<ref extends="book">[http://book.com/page5.html#headline Headline, page 5]</ref> (im Original hieß es noch "refines").

Solch formatierten Markdown schreibt man nicht in einen Attributwert.

Zudem sehe ich ein Problem, wenn es eine weitere Variante gibt, die mit „ref name=...“ beginnt. Dann gibt es ja noch mehr Tags mit dem gleichen Namen, das verwirrt. Ich muss immer bis zu dem Zeichen „/“ lesen, um zu erkennen, dass es sich um einen Verweis auf ein anderes ref handelt. Neulinge könnten auf die Idee kommen, auf ein additives ref ebenfalls verweisen zu wollen, doch eine solche rekursive Verkettung ist unerwünscht.

Vielleicht wäre so eine Notation möglich:

<ref addTo="book">[http://book.com/page5.html#headline Headline, page 5]</ref> --T. Wirbitzki (Diskussion) 06:31, 5. Mai 2024 (CEST)

An ref hatte ich ja auch überhaupt nichts verändert. Das sollte ja genau bleiben, wie es ist. --Vollbracht (Diskussion) 08:48, 5. Mai 2024 (CEST)

Ich habe einen Post von Benutzer H005 vom 2. Mai beantwortet, das Diskussions-Tool stellt das leider etwas unzusammenhängend dar. --T. Wirbitzki (Diskussion) 18:05, 5. Mai 2024 (CEST)

Alles Gut! Ich meinerseits bin ein wenig apodiktisch gewesen. Aber einerseits überzeugt mich die Lösung mit "extends", "refines", oder "addTo" nicht so, wie mein eigener Vorschlag. (Ich halte es also für richtig, die ref-Logik unangetastet zu lassen.) Andererseits sollte bei egal welcher Verkettung natürlich etwas sinnvolles bei heraus kommen, wenn wir sie möglich machen und ein Anwender sie entwirft. Das kann ich mir bei meinem Vorschlag sogar gut vorstellen. So könnte fiktiv im Artikel "Geheimdienst" die gesamte Reihe "C.I.5 (Hrsg.): Handreichungen für Doppelnullen. Geheimverlag, London ab 2002." als vertiefende Lektüre empfohlen werden. In den EN würde dann jeweils im vollständigen Nachweis für Bond 2007 auf den Eintrag im Literaturverzeichnis verlinkt, in den Kurzreferenzen aber wiederum nur auf den vollständigen Nachweis. Damit bleiben wir sparsam. Der Leser sieht zunächst die notwendigen Informationen zur Identifizierung, ist stets nur einen Klick von den nächstgenaueren Details entfernt und braucht im Extremfall drei Rücksprünge, um im Haupttext weiter zu lesen. --Vollbracht (Diskussion) 03:19, 6. Mai 2024 (CEST)

@T. Wirbitzki: Da hast du in der Tat ein valides Argument. --H005 (Diskussion) 20:22, 6. Mai 2024 (CEST)

Ist ein einzelnes Attribut eigentlich hinreichend?

Ich kann mich an die Erörterung der Entwicklung vor umpfff Jahren nicht mehr so richtig erinnern, meine aber dass sie zu kurz griff.

Die Hypothese ist, dass ein einziges Attribut hinzugefügt werden solle.

• Eigentlich war mal der Plan, dass etwa in Vorlage:Literatur der Wert des Attributs eingefügt werden könne, an geeigneter Stelle, etwa bei Seiten= oder so.
• Danach solle die Vorlage:Literatur mit dieser Variablen eingebunden werden, sofern angegeben.

Nun sehe ich aber aus heutiger Sicht Situationen vor mir, wo die geänderte Fundstelle im Sammelwerk mehrere lokale Veränderungen zur Folge hätte. Nehmen wir folgende heutige Vorlageneinbindungen; auch ohne Vorlage würde sich das identische Problem stellen:

• {{Literatur |Titel=Meier, Petra |Sammelwerk=Biografisches Lexikon |Band=11 |Datum=1995 |Seiten=123–125 |Online=http://biografisches-lexikon.example.org/articles?id=63076}}
• {{Literatur |Titel=Schulze, Paul |Sammelwerk=Biografisches Lexikon |Band=17 |Datum=1995 |Seiten=94–95 |Online=http://biografisches-lexikon.example.org/articles?id=87654}}

VG --PerfektesChaos 12:33, 28. Apr. 2024 (CEST)

Ich war für einige Jahre raus.

Erstaunt erfahre ich jetzt, dass nicht mehr der Attributwert, sondern der eine einzige Element-Inhalt zu verwenden wäre.

Auch geht anscheinend verloren, dass der Wert im Sinne eines Vorlagenparameters in Vorlagen verwendet werden kann.

Für das eröffnend zitierte und anspruchsvolle Anwendungsbeispiel stelle ich nachstehend mal eine fiktive Wikisyntax vor:

* [[Petra Meier]]<ref name="BiogrLex" 1="Meier, Petra" 2="11" 3="123–125" 4="63076" sub />
* [[Paul Schulze]]<ref name="BiogrLex" 1="Schulze, Paul" 2="17" 3="94–95" 4="87654" sub />

== Einzelnachweise ==
<references>
<ref name="BiogrLex">
{{Literatur |Titel={{{1|Eintrag}}} |Sammelwerk=Biografisches Lexikon |Band={{{2|}}} |Datum=1995 |Seiten={{{3|}}} |Online={{#if: {{{4|}}} | http://biografisches-lexikon.example.org/articles?id={{{4}}}}}}}
</ref>
</references>

Dabei mag <ref name="BiogrLex" sub="S. 123–125" /> eine Kurznotation sein für: <ref name="BiogrLex" 1="S. 123–125" sub />

Bis zu neun Parameter ließen sich verteilen.

Für den VE ist die Programmierung eher nix, sehr wohl jedoch das Einzelzitat.

Wie die momentane WMDE-Entwicklungsplanung dies umsetzen möchte, ist mir nicht so ganz klar.

VG --PerfektesChaos 13:49, 29. Apr. 2024 (CEST)

Es ist eine gute Idee, sich über solche Einzelnachweise Gedanken zu machen, wo sich zwischen ref und /ref genau ein Exemplar der Literaturvorlage befindet. Allerdings wurden Bemühungen um das Thema nicht mit Erfolg gekrönt, sodass es nun für eine Veröffentlichung in der Beta-Phase dieses Topwunsches zu spät kommt. Es ist jedoch bei vielseitigem Zuspruch eine spätere Fortführung denkbar, die sich mit Wiederverwendung in formatierten Literaturverweisen beschäftigt. Auch die formatierten Internetquellen ließen sich behandeln.

Cool gelöst finde ich in obigem Pseudocode das Zusammenspiel von ref-Tag und Vorlage in der Hauptquelle (zwischen references und /references). Das ref ist der Container, die Vorlage der Content. Nicht so schön ist, dass das sub dieses Zusammenspiel nicht mehr hat und dadurch dort eine Vermischung der Belange stattfindet. Nummern anstatt von bekannten Namen finde ich auch stark gewöhnungsbedürftig. Besser existierten für die Hauptquelle und die detaillierte Fundstelle zwei unterschiedliche Vorlagen, wobei ich hier in abgewandelter Form einem Vorschlag von Benutzer @Vollbracht nachgehe:

::* [[Petra Meier]]<ref main="BiogrLex" />{{LiteraturSub |Titel=Meier, Petra |Band=11 |Seiten=123–125 |OnlineDetail=63076}}</ref>
::* [[Paul Schulze]]<ref main="BiogrLex" />{{LiteraturSub |Titel=Schulze, Paul |Band=17 |Seiten=94–95 |OnlineDetail=87654}}</ref>
::== Einzelnachweise ==
::<references>
::<ref name="BiogrLex">
::{{LiteraturHauptquelle |Sammelwerk=Biografisches Lexikon |Datum=1995 |Online={{#if: {{{OnlineDetail|}}} | https://biografisches-lexikon.example.org/articles?id={{{OnlineDetail}}}}}}}
::</ref>
::</references>
::

Damit das funktioniert, braucht es ein zusätzliches Plugin für die Verarbeitung von ref, weil ja nur eine WP die Literatur-Vorlagen kennt. Dieses Plugin muss prüfen, dass die beiden verknüpften Literatur-refs zusammenpassen, und kann sie dann zusammenbringen. Wie man das OnlineDetail aus einer Vorlage in eine andere reinzaubert, wüsste ich allerdings nicht, eventuell ist dieses Feature auch verzichtbar. Vielleicht kann man auch ein LiteraturSub auf eine herkömmliche Literaturvorlage ansetzen, doch das wäre definitiv keine Konkretisierung einer Fundstelle mehr, sondern schon eine Art Patch, der vom Nutzer erstmal verstanden werden will. --T. Wirbitzki (Diskussion) 13:01, 1. Mai 2024 (CEST)

Die unbenannten Parameter habe ich gewählt, weil:

1. Ein tag nur explizit bestimmte Attributnamen verwenden kann; die Syntax eines Elements kann nur eine definierte Aufzählung von Bezeichnern (ggf. plus Lokalisierungen) zulassen.
2. Die ganze Geschichte auch global vermittelbar sein muss.
3. Außerdem muss der VE auch in der Lage sein, ein Formular anzubieten. Das kann er für offene Felder 1 bis 9, und es ist dann tückisch genug in der Dokumentation, für diesen Artikel zu vermitteln, was da wo neu eingetragen werden soll. Schon Quelltextler hätten zu schlucken.

Das obige Beispiel funktioniert nur für den Spezialfall eines gedruckten Werks; es sind aber Tausende von Vorlagen und Anwendungen bei Datenbanken, Weblinks, URL, Lexika und sonstwas vorstellbar, auf die solch eine Spezialisierung dann jeweils nicht passt. Man nennt sowas hard coded oder festverdrahtet; und alle Fachleute wissen, dass das nix taugt und nicht breit verwendbar ist.

• Solche Zuordnungen, dass Vorlage:LiteraturSub irgendwie verwurstelt ist mit Vorlage:LiteraturHauptquelle funktioniert nicht für ein Weblink, oder die Nutzung irgendeiner fertigen Vorlage:ADB oder welches Standardwerk auch immer; einschließlich der sogenannten Datenbanklinks.
• Obendrein hat die obige Darstellung einen Denkfehler: Die Information BiogrLex erscheint nicht in der Auswertung von Vorlage:LiteraturHauptquelle – damit ist in diesem Artikel nur eine einzige Paarung für nur ein einziges Sammelwerk LiteraturHauptquelle möglich. Es müssten aber beliebig viele sein. Und es muss auch etwas anderes als eine auf Papier gedruckte Publikation möglich sein. Und die jederzeit im Wiki veränderbare Programmierung von Vorlage:LiteraturHauptquelle muss für beliebige nicht bekannte Artikel und Sammelwerke möglich sein.

Ein spezielles PlugIn nur für dewiki und nur in PHP und nur für den Spezialfall eines gedruckten Werks wird kaum jemand mitgehen; die letzte vergleichbare Aktion lief bei Citoid und mappt öfter schlecht als recht auf JSON-Ebene. Wikisyntax muss ohnehin global sein; unsere ziemlich dewiki-spezifische Sichtungsmethodik war ein über ein Jahrzehnt dahinsiechender kaum wartbarer Krampf.

• Alle Vorschläge müssen global umsetzbar und anwendungsoffen sein. Meiner ist es; er ist auch mit etwas (überschaubarer) Mühe zu parsen, weil einfache Standard-Methodik.

Das momentan im Raum stehende Angebot, da einfach nur ein Textfitzelchen anzubieten (und diese ggf. numerisch vor lexikalisch in der Darstellung durchzusortieren) greift völlig zu kurz und ist zur Lösung der flächendeckenden Problematik absolut ungeeignet.

VG --PerfektesChaos 14:40, 1. Mai 2024 (CEST)

Ein Plugin für Literaturquellen und andere Spezialitäten von WMDE im internationalen Teil der Verarbeitung ist also nicht machbar, schade.

Wenn mit Textfitzelchen das gemeint ist, was zwischen beginnendem und schließendem ref-Tag steht, dann kann man damit schon eine Menge von Fällen abdecken, nur dürfen die Ansprüche an die Wiederverwendung einer Hauptquelle nicht zu umfangreich werden. Gehen die Ansprüche wie im obigen Beispiel so weit, mehrere Eigenschaften der Hauptquelle präzise (um-)formen zu können, kann ich mir jetzt nicht mehr vorstellen, dass der Quelltexteditor dafür das geeignete Werkzeug wäre, die unbenannten Parameter machen das Ganze doch schwer beherrschbar – das können aber andere anders sehen. --T. Wirbitzki (Diskussion) 21:43, 1. Mai 2024 (CEST)

Ich frage mich, ob bei all diesen Gedanken nicht die Struktur- und Inhaltsebene zu stark miteinander verwischen. Unser bisheriges Konzept sieht vor, dass allein Referenzen zu einer Ausgliederung von Inhalten aus der weitgehend linearen Darstellung des Artikelcodes herausgelöst und in einen eigenständigen "references"-Block ausgegliedert werden. Bevor wir uns über eine veränderte Codierung Gedanken machen, lasst uns erst überlegen, was wir darstellen wollen!

Die Evolution stellt sich mir, wie folgt, dar:

1. ref wurde eingeführt: einfache Link-Beziehung zwischen Haupttext und Eintrag im References-Block
2. Einträge im References-Block enthalten Links (WP und extern)
3. Einträge im References-Block stützen sich auf Einträge im Literaturverzeichnis. (-> Gekürzte Notation von Einzelnachweisen, wie in Fachliteratur üblich) 2-stufige Link-Beziehung zwischen Haupttext, Eintrag im references-Block und Eintrag im Literaturverzeichnis
4. Einheitliche Verkettungsregel für 2- oder mehrstufige Linkbeziehungen bei Referenzen, z. B. für gekürzte Notationen, die sich auf andere Einträge im References-Block stützen

Und jetzt die Frage: was wollen wir? Bei (3.) sind wir bereits. Das könnte noch weiter verbessert werden, ist mir aber bereits jetzt schon in meiner Artikelarbeit wichtig. @PerfektesChaos: Wenn ich Dich richtig verstehe, würdest Du eher dafür plädieren, (4.) anzustreben. Ist das richtig? Ich selbst tendiere eher zu der Ansicht, unsere Artikel sollten klar 2-stufig gegliedert werden (3.). Dieses Konzept halte ich auch für leichter zu vermitteln. Für, aber vielleicht auch gegen (4.) spricht, dass wir Autoren maximale Flexibilität haben, unsere Artikel auch komplex zu strukturieren. Also: was meint Ihr? --Vollbracht (Diskussion) 22:24, 1. Mai 2024 (CEST)

Für (4.) (speziell auch für das "extends"/"sub"-Konzept) spricht, dass sich alle Querbezüge in den <ref>-Zusmmenhängen abspielen und unabhängig davon sind, was in der Literaturliste angegeben ist. Sie können somit nicht zerstört werden, wenn jemand die Literaturliste ändert (beispielweise einen Eintrag durch eine Neuauflage mit anderen Seitenzahlen oder durch ein neueres umfangreicheres Werk desselben Autors zum selben Thema ersetzt, oder auch dort einen Eintrag als irrelevant löscht). -- Karl432 (Diskussion) 22:35, 1. Mai 2024 (CEST)

Dann wäre es möglicherweise wünschenswert, nicht nur Einträge im references-Block automatisch aus Abschnitten im Artikel-Code zu generieren, sondern auch solche im Literaturverzeichnis. Andererseits sollte jedem Editor im Literaturverzeichnis klar sein, dass Einträge, die extra mit einem Link-Anker (ID) versehen sind, auch Link-Ziele darstellen und nicht einfach so gelöscht werden sollten. Mir ist kein Fall bekannt, wo ein Link ins Literaturverzeichnis hinein verwaist zurück gelassen worden wäre. --Vollbracht (Diskussion) 22:46, 1. Mai 2024 (CEST)

Ich habe im direkt vorhergehenden Thread mal einen Vorschlag gemacht, wie so etwas codiert werden könnte. --Vollbracht (Diskussion) 14:50, 3. Mai 2024 (CEST)

Wenn ich das richtig sehe, würdest Du aber eine Darstellung bevorzugen, wie sie unter #Auf den Leser kommt es an beschrieben wird. Hier müssen wir uns aber fragen, was der Leser im Haupttext am Tool Tip gezeigt bekommt. Wird das der Haupteintrag mit Erweiterung sein? Als Leser wünsche ich mir, dass ich die Literatur des EN inklusive konkreter Stelle schnell identifizieren kann und nur bei Bedarf bequemen Zugriff auf die vollständigen Informationen bekomme. Das wäre mit Kurzreferenzen mit Link auf einen Literaturverzeichniseintrag gegeben. Mit der Extends-Kodierung wäre ein solcher Tool Tip nur schwer zu realisieren. Daher würde ich die oben von mir vorgeschlagene Variante bevorzugen.

Davon unbenommen bleibt, dass die Software natürlich alle Links auf die Extends-Einträge mit demselben Linktext versehen könnte, der auch für den Haupteintrag gilt. Die Regeln, die hierfür gelten sollten, sollten an dieser Stelle diskutiert werden. In jedem Fall müsste hierzu einiges neu entwickelt werden. Vom Entwicklungsaufwand her wäre die von mir vorgeschlagene Lösung extrem viel einfacher zu realisieren. Es braucht ja nur auf die für ref und references entwickelte Logik zurück gegriffen werden. --Vollbracht (Diskussion) 17:54, 3. Mai 2024 (CEST)

Warum nicht die Anker-Vorlage vereinfachen und fertig?

Die "Anker-Vorlage" macht doch eigentlich schon seit langem das was hier gewollt ist (Verlinkung Autor+Seitenzahl auf ein Langzitat). Ich fand diese Vorlage nur ziemlich umständlich in der Anwendung und hatte mir daher gewünscht, dass es eine Art Helferlein-Button für die Ankervorlage gibt, um dieses Tool im Visual Editor nutzen zu können. In Html sieht der Code aus wie angehängt. Ich habe das vor langer Zeit in einigen Artikeln ausprobiert, zum Bsp. hier (die ersten beiden Kurzzitate Johnson, verlinkt auf Langzitat).

Verlinkung des Kurzzitats im Fließtext auf den Anker im Literaturverzeichnis:

<ref name="XY_2012">[[#XY_2012|XY (2012)]], S. 98 f.</ref>

Anker im Literaturverzeichnis:

{{Anker|#XY_2012}}XY: ''Archaeological Theory.'' Verlag R. Mustermann, Berlin 2012

IMO wäre der einfachste Weg, das Kurzzitat (Autor+Jahreszahl) mit einem Anker-Button zu markieren. Der Button ersetzt dann nur den Code der Ankervorlage. Es gab sowas doch schon bei den Helferlein-Buttons zur Wiederholungsreferenz, das Schema wäre also fast dasselbe. Falls ich hier Teile der Diskussion nicht mitbekommen habe, bitte ich um Nachsicht. Ich habe das Voranstehende nicht alles gelesen. LS (Diskussion) 12:10, 29. Apr. 2024 (CEST)

Das ist äußerst unerwünscht.

Unser „Literatur“-Abschnitt ist keine „Bibliografie“ oder soeben genannt „Literaturverzeichnis“, wie man sie aus akademischen Werken kennt, die zu einem Zeitpunkt einmalig fertiggestellt werden und sämtliche bibliografischen Details zu allen zitierten Werken auflösen.

• Unser „Literatur“-Abschnitt enthält ggf. weiterführende Lese-Empfehlungen, die ggf. überhaupt nicht explizit im Artikel vorkommen müssen.
• Die Zahl der dort empfohlenen Werke ist auf ggf. fünf zu beschränken. Sie sollen das gesamte Spektrum des Artikels oder wesentliche Teilbereiche umfassend abdecken; ein „Einzelnachweis“ beschäftigt sich hingegen gerade mit einem Detail, wie der Name ja sagt.
• Auf keinen Fall kann der „Literatur“-Abschnitt komplett alle zitierten Werke aufzählen.

Hinzu kommt, dass unsere Artikel nicht am Tag X von einem oder wenigen Menschen in einer Endfassung abgeliefert werden, sondern sich über Jahrzehnte weiterentwickeln und von Hunderten bearbeitet werden, die kaum voneinander wissen.

• Der „Literatur“-Abschnitt enthält nur die neueste Ausgabe eines Werkes. Ein Einzelnachweis kann aber problemlos aus einer älteren Ausgabe mit damaliger Seitenzahl zitieren.
• Es gibt keine softwareseitige Sicherheit, dass alle Anker-Sprungziele auch mit gesetzten Ankern korrespondieren. Das stellt nur das <ref>-System zwingend sicher.

VG --PerfektesChaos 13:28, 29. Apr. 2024 (CEST)

Ich hatte dies vor längerer Zeit mal versuchweise im Artikel Syrischer Antentempel gemacht, sehe aber genau die von PerfektesChaos genannten Nachteile und habe es seitdem gelassen (und hoffe seitdem auf die Umsetzung des „extends“-Konzepts mit welchem Parameternamen auch immer). -- Karl432 (Diskussion) 23:02, 29. Apr. 2024 (CEST)

Ok, dann steige ich aus der Diskussion hier wieder aus. In der englischen WP gibt es die Vorlage "Sfn" (en.Template:Sfn), die ziemlich genau das macht: Kurzzitat auf Langzitat verlinken. Dazu werden noch verschiedene Zitatstile angeboten. Eigentlich alles schon da... --LS (Diskussion) 21:45, 29. Apr. 2024 (CEST)

Wenn ich z. B. im englischen Artikel Chinese Room die Vorlage sfn so verwende: {{sfn|Roberts|2016}}, und dann jemand kommt und sich vertippt, so dass {{sfn|Roberta|2017}} entsteht, dann wird in der Vorschau keinerlei Warnhinweis gebracht, der schädliche Commit geht einfach so durch – wer räumt das wieder auf, in abertausenden Fällen über die Jahre?

Stattdessen gibt es eine erschöpfende Gebrauchsanleitung für sfn mit dem schönen Satz „If an article is using this template, and nothing happens when you click on the highlighted wikilink from a Harvard style citation to a full citation at the bottom of the page, there are several possible solutions.“

Und dann kommen über 30 Zeilen Erklärung, wie man das reparieren könnte, wenn „nothing happens“.

Referenzen innerhalb eines Textes zu prüfen und automatisiert Referenzverletzungen zu vermeiden, ist state of the art. Das ref-Tag prüft Tippfehler bei Referenzen, Vorlagen-basierte Konstrukte wie sfn können das nicht. --T. Wirbitzki (Diskussion) 07:07, 30. Apr. 2024 (CEST)

@PerfektesChaos: Wieso willst Du das nicht? Wieso hältst Du das sogar für allgemein "äußerst unerwünscht"? Was soll denn das Literaturverzeichnis sonst sein? Es verzeichnet Literatur, die im Zusammenhang besonders relevant erscheint. Das betrifft die Literatur, die in den EN mehrfach verwendet wird, doch in besonderem Maße.

@T. Wirbitzki Das Problem mit einem "schädlichen Commit" haben wir immer, wenn wir irgendwo einen Deep Link einbauen. Schön, wenn wir es eindämmen können. Aber das verbietet nicht die Verwendung von Deep Links - auch nicht in EN.

@LS Deine Lösung ist gut, aber sie geht noch besser. Ich habe mir angewöhnt, eine tool tip-Unterstützung zu codieren, bei der ich natürlich merke, wenn mein Link ins leere zeigt. Oben habe ich einen Vorschlag gemacht, wie so etwas künftig automatisiert erstellt werden könnte. --Vollbracht (Diskussion) 15:05, 3. Mai 2024 (CEST)

Ebenso wie die Seitenangabe zwischen den ref-Tags in <ref extends="BiogrLex">S. 123–125</ref> kann ein Deep Link kaum automatisiert geprüft werden. Ein Deep Link ist ein externer Anker. Bei der Wiederverwendung von Einzelnachweisen geht's ausschließlich um Lemma-interne Verweise, die die Software in Millisekunden prüfen kann und sollte, um Flüchtigkeitsfehler zu vermeiden.

Natürlich gibt es bereits manuell ausführbare Hilfsskripte für den Editor (z. B. hier), um vorlagenbasierte Verweise zu prüfen. Wieso so was in abgewandelter Form nicht in eine regelmäßige Prüfung vor dem Speichern eingebaut wird, weiß ich nicht, vielleicht weil die MediaWiki-Software länderspezifische Vorlagen ungern unterstützt. --T. Wirbitzki (Diskussion) 17:56, 5. Mai 2024 (CEST)

Integration von Literaturverzeichnis und Einzelnachweisen

Gelebter Praxis folgend werden in vielen Artikeln in Einzelnachweisen gekürzte Literaturangaben gemacht, deren vollständige Beschreibung bereits im Literaturverzeichnis zu finden ist. Wenn das nicht richtig gemacht wird, führt das zu Problemen. Deshalb wurden Regeln aufgestellt, denen Autoren folgen sollten, um diese Probleme zu vermeiden. H005 hatte oben dazu bereits auf Wikipedia:Zitierregeln#Abgleich_mit_den_Einzelnachweisen, Wikipedia:Literatur#Abgleich_mit_den_Einzelnachweisen und Hilfe:Einzelnachweise#Literaturbelege hingewiesen. Ein weiteres Problem besteht bislang immer dort, wo gekürzte Literaturangaben in EN auftauchen, in denen nicht auf die vollständigen Literaturangaben verlinkt wird - unabhängig davon, ob letztere im Literaturverzeichnis oder an anderer Stelle in den EN stehen. Dann muss der Leser suchen oder raten, welche Literatur genau gemeint ist. Wenn es hingegen richtig gemacht wird, bestehen diese Probleme in keiner Weise.

Ein generelles Konzept besteht darin, dass Kurznamen, die z. B. im Literaturverzeichnis definiert werden, darauf hinweisen, dass aus Einzelnachweisen heraus auf die so bezeichnete Literatur verwiesen wird. Schon jetzt besitzen wir mit der <ref...-Logik ein mächtiges Werkzeug, um tote interne Links zu verhindern. Alle anderen internen Links sind ja dem Grunde nach Deep Links. T. Wirbitzki hatte hier bereits darauf hingewiesen, dass die kaum automatisiert geprüft werden können.

In diesem Zusammenhang habe ich oben einen Vorschlag gemacht, der darauf hinaus läuft, diese mächtige Logik auf ein neues Par von Elementen mit den Namen "lit" und "literature" zu adaptieren. Damit werden eine ganze Reihe an Forderungen und Wünschen erfüllt:

1. Einzelnachweise können stringent wiederverwendet werden.
2. Best Practices in der Erstellung wissenschaftlicher Literatur gelten weiterhin in der Wikipedia.
3. EN werden zielgerichtet daraufhin optimiert, verwendete Literatur schnellstmöglich zu identifizieren und trotzdem, gleichzeitig schnellen und direkten Zugriff auf genaueste Informationen zur Literatur zu ermöglichen.
4. Inkonsistenzen und tote Links können besser und bequemer als bisher vermieden werden.

In Konsequenz könnte, wie bisher schon bei den Einzelnachweisen die Definition einer Literaturbeschreibung entweder im Haupttext, oder im Verzeichnis kodiert werden. Beide Möglichkeiten bringen spezifische Vor- und Nachteile mit sich. So ist im Literaturverzeichnis häufig eine strukturierte Ordnung gewünscht, die nur dadurch erreicht wird, dass alle Einträge auch vor Ort kodiert werden. Wird hingegen die Definition einer Literaturbeschreibung direkt im EN kodiert, braucht es weniger Aufwand, auch die Darstellung dieser Literaturbeschreibung in das EN-Verzeichnis zu verschieben.

Im Wesentlichen wird sich die Adaption darauf beschränken, dass sich die Links und Backlinks zwischen den <ref- und <lit-Elementen in ihrer Formatierung und ihrem Linktext unterscheiden. Dazu kommt dann noch, dass das "name"-Attribut bei <ref optional und bei <lit verpflichtend ist und beim <lit-Element zusätzlich die Möglichkeit geschaffen werden sollte, mit einem type="inline"-Attribut eine Auslagerung in das Literaturverzeichnis zu unterdrücken. Dieses Attribut werden wir sicher nicht auch dem <ref-Element geben, da sonst womöglich im Haupttext Backlinks zu den Stellen auftauchen würden, an denen derselbe EN ebenfalls verwendet wird. Wir sollten uns in dem Zusammenhang auch Gedanken darüber machen, ob wir uns auch Backlinks aus dem Literaturverzeichnis in das EN-Verzeichnis hinein wünschen sollten. Was fällt Euch sonst noch ein, was beachtet werden sollte? --Vollbracht (Diskussion) 15:03, 7. Mai 2024 (CEST)