Wikipedia Diskussion:Technische Wünsche/Topwünsche/Subreferenzierung

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?

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)

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)

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)

@DerMaxdorfer Danke fürs Testen und für deine Hinweise. Es tut mir leid, dass ich so spät antworte. Eine Rückfrage habe ich, zu „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“: Bei mir springt der Browser so, dass sowohl die Hauptreferenz als auch die Subreferenz (z.B. Seitenzahl) sichtbar sind. Könntest du bei Gelegenheit nochmal testen, ob das bei dir jetzt auch so ist? -- Vielen Dank und beste Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 16:18, 20. Aug. 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)

@Gnom: Du hast es bestimmt schon mitbekommen: Mittlerweile gibt es im Betawiki auch eine Lösung für den Visual Editor. Sie ist noch in Arbeit und Dinge werden sich noch ändern (siehe hier), aber Feedback zum aktuellen Stand der Dinge wäre sehr hilfreich. Hier findest du Infos zum Testen. -- Besten Dank, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 16:37, 20. Aug. 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)

Dieses Konzept gefällt mir. Wie wäre es mit inherits mit Alias beerbt? -- Heribert3 (Diskussion/Talk) 16:22, 26. Aug. 2024 (CEST) (unvollständig signierter Beitrag von Heribert3 (Diskussion | Beiträge) )

Hallo Heribert3, ich habe deine Anregung mal ans Abschnittsende verschoben, damit sie nicht mitten im Beitrag eines anderen Benutzers ist. Danke für deine Idee! Folgendes Problem gibt es dabei: Während wir es sonst gewohnt sind, dass Wikisyntax lokalisierbar ist (z.B. können wir anstelle von #REDIRECT in dewiki auch #WEITERLEITUNG nutzen oder in itwiki #RINVIA), ist das bei Einzelnachweisen nicht möglich. Sowohl die <ref>-Tags, als auch alle Attribute (name, group...) heißen in allen Wikipedia-Sprachversionen genau gleich, selbst in Projekten, die ein ganz anderes Schriftsystem haben (was ein eigenes Problem ist...). Solange das so ist, müssen wir bei der Wahl des Attributs für Subreferenzen auch beachten, dass der Name idealerweise in vielen Sprachen funktioniert, wir können leider nicht einfach beschließen, in dewiki ein Alias zu verwenden. --Johannes Richter (WMDE) (Diskussion) 16:51, 26. Aug. 2024 (CEST)

Hallo Johannes, Danke soweit! Hab mir auch 2* überlegt, wo ich in einer jahrelangen und mehrere Scroll-Seitenlangen Disk das bestmöglichst auffindbar einsortieren soll. Deine Syntaxfehler hast du ja schon behoben. Wieso meckert mich der Bot an? Die sig verwende ich schon seit Jahren, ähnlich in en:WP.

Ich würde das extends-Konzept (unter welchem Name auch immer) beliebig tief verschachtelbar sehen, soweit sinnvoll, aufgrund Anzahl der EN und Struktur des zitierten Werkes, etwa so (aber nur in ref und nicht lit):

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

1. 1. Kapitel 1: Grundlagen

1. 1. 1. S. 123.

1. 1. Kapitel 2: Praktische Anwendungen

1. 1. 1. S. 234.

1. 1. Q: Phantom-Entwicklung für Dummies. London 2015.
      1. S. 345.

Der Formatierungsentwurf sieht sch... aus, hoffe ihr kriegt die Idee, und ich habs auch (noch) nicht getestet :-)

Weiter hab ich schon anderswo einige Anker gesetzt und darauf verlinkt. Ob jetzt die Erweiterung auch Deutsch oder nur Englisch wird, ist egal, wenn nicht so gut Englischsprechende WIKIaner*innen dann VE benutzen können. Als IT-ler mach ich eh alles im Quelltext! -- Heribert3 (Diskussion/Talk) 19:15, 26. Aug. 2024 (CEST) (unvollständig signierter Beitrag von Heribert3 (Diskussion | Beiträge) )

Hallo @Heribert3, vorweg zum Bot: Du scheinst in dewiki eine individuelle Signatur zu verwenden, die als nicht korrekt erkannt wird [1], weil sie wie ein Interwikilink formatiert ist. Wenn du in Spezial:Einstellungen#mw-prefsection-personal-signature jeweils das :de: entfernst, sollte der Bot nicht mehr meckern (in enwiki hast du sowas laut Tool auch nicht in der Signatur [2]).

Wir haben uns überlegt, ob wir Sub-Subreferenzen usw. zulassen, uns aber auch auf Feedback der Communitys dagegen entschieden. Das würde die Komplexität im Wikitext wieder erhöhen und auch die Einzelnachweisliste deutlich verlängern, weil Infos, die ursprünglich in einer Zeile als EN vorlagen, nun auf 3-4 Zeilen aufgeteilt sind. Insgesamt schienen die Vorteile so detaillierter Verschachtelungen nicht erheblich genug, die potentiellen Nachteile bei Benutzbarkeit und Lesbarkeit (gerade bei langen EN-Listen) auszugleichen.

Noch zum Thema Deutsch/Englisch: Wir haben bisher in dewiki Glück gehabt, dass sowohl "ref" als auch "name" auch im Deutschen funktionieren, jemand aus jawiki kann mit beidem vermutlich weniger anfangen... Aber in der Tat zeigen unsere Usertests, dass der Attributname für Wikitextnutzer gar nicht so entscheidend ist und im VisualEditor können wir die Beschriftung aller Buttons usw. problemlos in allen Sprachen ändern, sodass es dort auch keine Probleme gibt. --Johannes Richter (WMDE) (Diskussion) 07:19, 27. Aug. 2024 (CEST)

Ich habe einen weiteren Namensvorschlag: parent

Anderes möchte ich verlagern auf diese disk -- Heribert3 (Diskussion/Talk) 22:16, 27. Aug. 2024 (CEST)

Danke, darüber haben wir auch schonmal nachgedacht, das hat natürlich ne Informatiktendenz. --Johannes Richter (WMDE) (Diskussion) 07:07, 28. Aug. 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)

Hallo @Vollbracht, danke für deinen Kommentar und bitte entschuldige die späte Antwort. Du beschreibst ein System, wie es das z. B. in der englischen Wikipedia so ähnlich in Form von shortened Footnotes gibt – richtig? Diese Shortened Footnotes haben ja in der Tat den Nachteil, den du beschreibst, dass die Einzelnachweise nicht unbedingt mit dem übereinstimmen, was im Literaturverzeichnis steht – wenn manche Autor*innen in dewiki ähnliche Kurzreferenzen aktuell sogar ohne Vorlage nutzen, ist das natürlich noch fehleranfälliger.

Dieses Problem könnten Subreferenzen insofern abschwächen, als man die Hauptreferenz in der Einzelnachweisliste definiert und dann als “shortened footnotes” die Subreferenzen zugeordnet sind – wenn jemand die Hauptreferenz löscht, wird ein Fehler angezeigt. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 13:53, 21. Aug. 2024 (CEST)

Genau! Auf der anderen Seite sind ja die Vorteile unbestreitbar, die mit dem hier jetzt vorgesehenen System der Subreferenzierung nicht gegeben sind. Mein Vorschlag in diesem Thread ist also eine Lösung für die Gesamt-Wikipedia, die technisch sehr leicht umgesetzt werden kann, da die Logik in der Wikisoftware bereits codiert ist (für ref und references). Die Angelsachsen haben ihr System der Aufspaltung zwischen Vor- und Nachnamen der Autoren in ihren Vorlagen. Das kann man mögen, aber es ist nicht so flexibel, wie die von mir vorgeschlagene Lösung, die diesen Nachteil ja aufhebt. Eine Anpassung der enWiki-Vorlagen an die neue lit-Syntax würde sofort dazu führen, dass verwaiste sfn-Links im enWiki auffallen, ohne dass sich die Briten irgendwie umstellen müssten. Allein der Vorlagen-Code würde durch diese optionale Anpassung vermutlich erheblich kürzer. Alle Wikipedia-Autoren weltweit wären aber umgehend in der Lage, auch ohne Vorlagen in dieser in der Wissenschaft vielerorts üblichen Weise zu zitieren und alle unter shortened Footnotes beschriebenen Vorteile zu nutzen, ohne auf Probleme zu stoßen, wenn im selben Jahr zwei namensgleiche Autoren zum selben Thema veröffentlicht haben, oder einer zwei Artikel veröffentlicht hat. --Vollbracht (Diskussion) 15:30, 21. Aug. 2024 (CEST)

Danke, @Vollbracht. Dem „technisch sehr leicht“ umsetzbar muss ich aus Projektsicht leider widersprechen. Wir hatten in unserem Team (vor Langem) mal diskutiert, ob man nicht einen gänzlich neuen Tag einführen sollte, das wurde dann aber verworfen. Unter anderem weil es deutlich komplexer wäre, einen neuen Tag zu integrieren, als in einem bestehenden System ein Attribut zu ergänzen (und das ist bereits sehr komplex). Abgesehen vom Technischen wäre diese Lösung auch nur auf Literaturquellen beschränkt, oder? Und es wäre davon auszugehen, dass der Literaturabschnitt dadurch deutlich voller würde als bisher üblich. Das macht es beides eher unwahrscheinlich, dass dieser Vorschlag auf breite Zustimmung treffen würde, denken wir. Sag gerne, wenn ich etwas falsch verstanden habe. – Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 17:27, 23. Aug. 2024 (CEST)

Diese Antwort erstaunt mich wohl nur deshalb, weil ich die Randbedingungen für die Einführung neuer Tags und / oder Attribute in diesem Umfeld nicht kenne. Als ich selbst zuletzt solche Programmierungen vorgenommen hatte, machte das von der Komplexität fast keinen Unterschied.

Da ich zusätzlich zum Tag (<lit>) auch einen optionalen Parameter (type="inline") vorgeschlagen hatte, wäre die Lösung nicht allein auf Literaturquellen beschränkt, sondern wäre auch für die Einzelnachweise hilfreich. Wenn ein Tag existiert, kann natürlich nie ausgeschlossen werden, dass es für andere Zwecke missbraucht wird, wie das z. B. bei <ref> für Anmerkungen der Fall ist. (Eigentlich ja nur für Literaturreferenzen gedacht...) Erwarten würde ich das beim <lit>-Tag aber eher nicht so schnell.

Das der Literatur-Abschnitt wesentlich voller würde, sehe ich nicht. Vor allem würden Literaturempfehlungen, die keinen Einfluss auf den Artikeltext hatten, eher mal auffallen. Es wäre, denke ich, nicht das Schlechteste, wenn es künftig den einen oder anderen Artikel gäbe, in dem alle Literaturempfehlungen automatisch aus Stellen zusammen gesammelt würden, an denen aus der entsprechenden Literatur auch zitiert oder referenziert wurde. --Vollbracht (Diskussion) 07:31, 24. Aug. 2024 (CEST)

Liebe Johanna Strodt (WMDE), darf ich Dich noch mal bitten, ein Wenig von der Komplexität aufzuzeigen?

Könnte eine Spezialbehandlung für >> group="lit" <<, die dann im <ref>-Element auch ein >> name="Bond 2007" << verpflichtend macht, eine bessere Lösung darstellen? Die Spezialbehandlung wäre dann, dass der Link nicht mit "¹", sondern mit "Bond 2007" als Linktext erzeugt würde. Also:

   Der MI6-Agent James Bond empfiehlt in der Regel mit einer Walter PPK zu schießen.<ref><ref group="lit" name="Bond 2007">James Bond: ''Waffenkunde für Dummies.'' Geheimdienstverlag, London 2007.</ref> S. 123.</ref>
====Literatur====
<references group="lit" />
====Einzelnachweise====
<references />

würde zu ...

Der MI6-Agent James Bond empfiehlt in der Regel mit einer Walter PPK zu schießen.

Literatur

Bond 2007^[1] - James Bond: Waffenkunde für Dummies. Geheimdienstverlag, London 2007.

Einzelnachweise

Bond 2007 S. 123.

Wie hier zu sehen ist, scheint durch das verschachtelte <ref> ein Problem mit der Nummerierung der EN zu entstehen. Bitte korrigiere mich, wenn ich da falsch liege. Aber die Einführung eines neuen Tags erscheint mir vor allem mit copy und paste zu lösen zu sein und damit weniger komplex und fehleranfällig. --Vollbracht (Diskussion) 19:40, 8. Sep. 2024 (CEST)

Hallo @Vollbracht, unsere Lösung setzt darauf, möglichst nahe an der bestehenden Nutzung von Einzelnachweisen anzuknüpfen, damit Nutzende möglichst wenig neue Syntax lernen müssen. Dein Vorschlag erinnert an das, was {{sfn}} in enwiki macht – bloß ohne Vorlagen, die Einzelnachweise erzeugen. In der Form beinhaltet der Vorschlag aber zunächst das technische Problem, dass <ref> innerhalb von Einzelnachweisen nicht funktionieren und eine Lösung dafür deutlich aufwändiger wäre, als nur das neue Attribut für Subreferenzen, das wir einführen. Dazu kommt, dass die Veränderung dann sowohl Einzelnachweise als auch den Literaturabschnitt betreffen würde – in unseren Augen ein deutlich komplexerer Wikitext. Zudem könnte das Literaturabschnitte deutlich aufblähen, aktuell enthalten diese ja keine vollständige Liste aller in Einzelnachweisen genutzten Literaturangaben. Dazu kommt noch, dass Subreferenzen bewusst für alle Arten von Einzelnachweisen gedacht sind, nicht nur für Literaturbelege. Wenn man das bei deinem Konzept ebenfalls so handhaben möchte, müsste man also auch die Syntax im Abschnitt Weblinks ändern, wodurch es nochmal komplexer würde.

Grundsätzlich: Unsere Lösung ist als Teil eines jahrelangen Communityprozesses entstanden und hat sowohl in den Feedbackrunden als auch den Nutzungstests über die Jahre insgesamt Zustimmung erhalten oder wurde als Kompromiss zwischen verschiedenen alternativen Lösungsideen akzeptiert. Wir sind jetzt an einem Punkt, wo wir die gefundene Wikitextlösung nicht mehr grundlegend überarbeiten werden (was ja auch erneute Feedbackprozesse mit den Communitys erfordern würde), sondern den Themenschwerpunkt Wiederverwendung von Einzelnachweisen bald abschließen wollen. Aktuell arbeiten wir primär an den Workflows im Visual Editor und schauen natürlich für den Wikitext, ob/wie sich manches Feedback noch mit kleineren Änderungen umsetzen lässt, aber ohne das Grundkonzept noch wesentlich zu ändern. Entsprechend werden wir derartig unterschiedliche Alternativkonzepte in diesem Themenschwerpunkt nicht mehr berücksichtigen können. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 14:12, 9. Sep. 2024 (CEST)

Bitte beachten: Hier gab es eine neue Diskussion zu diesem Thema, die aber von anderen Voraussetzungen ausging. Ich habe sie deswegen komplett, ohne Änderungen vorzunehmen, in einen eigenen Abschnitt Literaturverzeichnis und Einzelnachweise verschoben. So geraten die Argumente für und gegen die beiden Vorschläge nicht durcheinander. --Lantani (Diskussion) 16:23, 8. Sep. 2024 (CEST)

Kurzer Test im ß-dewiki

@Johanna Strodt (WMDE), @Johannes Richter (WMDE) Ihr hattet um Feedback gebeten. Anhand eines einfachen Beispiels habe ich mit den Editoren ein paar Subreferenzen angelegt, und das hat gut geklappt. Für jemand, der sich länger mit dem Thema beschäftigt hat, wirkt die Funktion "Belegen - Extends" im VE einfach zu bedienen: Hauptquelle selektieren, Seitenangabe ausfüllen, fertig.

Als ich auf „references responsive“ umstellte, fiel mir auf, dass die Hauptreferenz mitsamt Subreferenzen in die zweite Spalte wanderte und dadurch freien Raum in der ersten Spalte ließ. Da geht ein wenig Raum verloren, was aber nicht so ins Gewicht fällt, wenn man bedenkt, wieviel unnötiger Text durch das Verfahren eingespart wird. Es würde die Sache nicht viel besser machen, die Subreferenzen auf beide Spalten umzubrechen und den Text der Hauptreferenz pro Spalte zu wiederholen. --T. Wirbitzki (Diskussion) 23:48, 26. Jul. 2024 (CEST)

Danke fürs Ausprobieren und für dein Feedback @T. Wirbitzki! Ich geb deine Rückmeldung bgzl. references responsive ans Team weiter :) --Johannes Richter (WMDE) (Diskussion) 15:29, 29. Jul. 2024 (CEST)

Überarbeiten vorhandener Artikel durch Anfänger

Ich sehe schwarz für die Bearbeitung von Artikeln, in denen diese Art von Belegtechnologie eingesetzt wurde, durch Anfänger. Das wird natürlich niemand merken, weil die meisten wohl gleich das Handtuch werfen, ohne dass dies registriert wird. Ich erinnere mich gut an die knallroten Fehlermeldungen, als ich nur versucht habe, einen inzwischen veralteten Beleg durch einen aus der aktuelleren Forschung zu ersetzen. Ich halte daher diesen ganzen Aufwand mit irritierenden Formatierungen obendrein für verlorene Liebesmüh und einen Weg in eine völlig falsche Richtung. Schade um die viele Arbeit, die andere am Arbeiten auch noch hindern wird. --Hans-Jürgen Hübner (Diskussion) 14:43, 19. Aug. 2024 (CEST)

Moin @Hans-Jürgen Hübner, danke für deine Rückmeldung. In unseren Usertests achten wir darauf, verschiedene Erfahrungslevel zu berücksichtigen. Bisher haben unsere Test mit Anfänger*innen keine erhöhten Probleme ergeben. Die meisten Neulinge nutzen ja den Visual Editor und kamen dort mit Subreferenzierung gut zurecht. Das wird aber natürlich auch in den kommenden Monaten noch ein Punkt sein, auf den geachtet wird. Wir schauen dabei auch darauf, wie eventuelle Fehlermeldungen so gestaltet werden können, dass möglichst niemand irritiert das Handtuch wirft.

Im Übrigen ist es natürlich problemlos möglich, Einzelnachweise einfach wie bisher zu nutzen. Da die neue Lösung aber seit Jahren wiederkehrend in den Technische-Wünsche-Umfragen gewünscht wird und auch bisher schon im stetigen Austausch mit der Community entwickelt wurde, gehen wir davon aus, dass der Großteil der Community die Funktion (zumindest in Artikeln mit sehr vielen fast identischen Einzelnachweisen) gerne nutzen möchte. --Johannes Richter (WMDE) (Diskussion) 15:19, 19. Aug. 2024 (CEST)

Hallo, ich habe mich einmal am bestehenden Artikel IBSV auf dieser meiner Unterseite probiert. Im Abschnitt "Einheiten" sind unterschiedliche Seitenangaben zu Einzelnachweisen zu finden. Ich habe es nicht geschafft so zu formatieren, dass ich keine, wie oben schon erwähnt, knallroten Fehlermeldungen bekomme. Gruß --Asio (Diskussion) 22:34, 19. Aug. 2024 (CEST)

Hallo @Asio otus, danke fürs ausprobieren! Subreferenzen sind aktuell noch in keiner normalen Wikipedia-Sprachversion aktiviert, sondern nur im Betawiki. Ich hab mir mal erlaubt, deine BNR-Seite nach drüben zu kopieren [3].

Wie du in der ersten Version siehst [4], werden da jetzt schon Subreferenzen angezeigt, allerdings immer noch mit nem Fehler. Woran lag der? Die mit "ref name" definierten Hauptreferenzen lagen sowohl im Artikeltext als auch im Abschnitt Einzelnachweise. Wenn sie doppelt vorhanden sind, gibt's ne Fehlermeldung. Im Artikeltext entfernt, sowie eine kleine Anpassung im Abschnitt Einzelnachweise [5] und schon sieht alles aus wie gewünscht.

Übrigens: Im Quelltext kann das alles ein wenig kompliziert aussehen, ich lade dazu ein, Subreferenzierung auch im Visual Editor auszuprobieren, wo das Erstellen von Subreferenzen im besten Fall genauso einfach klappen sollte wie normale Wiederverwendung von Einzelnachweisen. --Johannes Richter (WMDE) (Diskussion) 09:39, 20. Aug. 2024 (CEST)

Darstellungsproblem mit singulärer Anweisung <references />

Mit der singulären Anweisung <references />, wie sie in vielen aktuellen Artikeln benutzt wird, funktioniert die Anzeige der REFs mit der neuen Funktionalität nicht korrekt.
Erst mit einem öffnenden <references> und einem schließenden </references> ist die Darstellung korrekt (für das Öffnen kann auch <references responsive> verwendet werden). Beispiel (Difflink)
Ein entsprechender Hinweis sollte auf jeden Fall in die Anleitung.
Ansonsten ist das neue Feature sehr begrüßenswert!
--Archie02 (Diskussion) 23:24, 19. Aug. 2024 (CEST)

@Archie02: Danke für deinen Hinweis. Ich habe hier auf der Vorderseite ergänzt, was zu beachten ist. Findest du es so klarer? Danke auch, dass du getestet hast! -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 12:20, 21. Aug. 2024 (CEST)

@Johanna Strodt (WMDE) Ich würde den ersten Teil der Anleitung für die Syntax sogar noch ein bisschen länger ausführen mit (oder so ähnlich):

<references>

Hier drinnen steht dann die Hauptreferenz

Ggfs. weitere Hauptreferenzen ...

</references>.

Sonst fangen User eventuell an, die <references> .. </references>-Anweisung mehrfach in Artikeln einzubauen, was zu einem Fehler führt:

Referenzfehler: Das in <references> definierte <ref>-Tag mit dem Namen „BG“ wird im vorausgehenden Text nicht verwendet. Difflink für forciertes Beispiel --Archie02 (Diskussion) 17:04, 21. Aug. 2024 (CEST)

Passend hierzu möchte ich anmerken, dass es ziemlich unüblich, weil wegen übermäßigem Scrollen unpraktisch, ist, etwas anderes als <references/> zu verwenden. Einzelnachweise stehen in 99 % der Artikel direkt dort, wo sie auch im Artikel erscheinen. Ich sehe das Problem, dass der übergeordnete Einzelnachweis ohne Seitenzahl normalerweise nicht direkt als Einzelnachweis verwendet wird. Es wäre aber trotzdem iwie praktisch, wenn man eine Lösung hätte, die iwie so aussieht:

Dies ist ein Beispielsatz, der einen Beleg braucht.<ref name="beleg" extended>Max Mustermann: ''Gutes Belegebuch.''</ref><ref extends="beleg">S. 42.</ref> Dieser braucht auch einen.<ref extends="beleg">S. 95.</ref>

== Einzelnachweise ==
<references/>

Also ein Attribut, das markiert, dass der übergeordnete Beleg im Text nicht angezeigt werden soll. Wäre das eine technische Möglichkeit? --Kenneth Wehr (Diskussion) 08:23, 20. Aug. 2024 (CEST)

Hallo, ich habe nicht verstanden, wie es zu übermäßigem Scrollen kommt, wenn die Hauptquellen in der Sektion references stehen. Mit der Tastatursequenz Strg + Ende z.B. bin ich im Nu am Ende der Datei. Im Visual Editor ist alles vorwärts und rückwärts „verankert“. Im Artikel erscheinen Einzelnachweise nicht mitten im Text, sondern da ist nur ein numerierter Anker zur Fußnote unten im „Apparat“. Daher finde ich es natürlich, wenn Einzelnacheise auch da stehen, wo ich sie als Leser sehe, nämlich unten. Der Preis eines Einzelnachweises im Apparat ist natürlich, dass man einen Namen vergeben muss, wenn man die automatisch generierten Namen doof findet, die Zeit spendiere ich gerne. Bei Hauptquellen, die Subreferenzen haben, sind Namen sowieso obligatorisch. --T. Wirbitzki (Diskussion) 08:39, 20. Aug. 2024 (CEST)

Damit gehörst du aber offenbar einer Minderheitenmeinung an, denn wie gesagt finde ich die Einzelnachweise in nahezu allen Artikeln im Text und nicht am Ende. --Kenneth Wehr (Diskussion) 08:54, 20. Aug. 2024 (CEST)

Das spielt doch keine Rolle, sondern hängt von der persönlichen Arbeitsweise ab. Ich setze die Nachweise auch hinten hin, weil ich die Artikel im externen Editor bearbeite, die Quellen im ersten Schritt sammle und die Referenzen beim späteren Bearbeiten weniger stören als die Langformen. Mit dem Scrollen hatte ich nie Probleme.--Rodomonte (Diskussion) 09:10, 20. Aug. 2024 (CEST)

Gewiss, im Editor des Quelltexts gilt das Prinzip WYSIWYM, niemand soll seinen Editier-Stil für die bisherigen Fußnoten ändern, das wollte ich nicht sagen. Doch der neue Einzelnachweis ohne Seitenzahl ist meiner Meinung nach ganz gut im Referenzen-Bereich verortet. Es wäre doch etwas willkürlich, ihn einer seiner Fundstellen zuzuordnen, er ist für sie alle da. Man kann ihn direkt über der allerersten Seitenzahl zur Quelle platzieren; doch wenn später die Hauptquelle noch weiter oben zitiert wird, muss man umstrukturieren, das ist umständlich. Also werde ich den Einzelnachweis ohne Seitenzahl lieber gleich in den Referenzen-Bereich tun, weil er da stabil liegt und nicht unabsichtlich selbst als Einzelnachweis verwendet werden kann. --T. Wirbitzki (Diskussion) 09:55, 21. Aug. 2024 (CEST)

Hallo @Kenneth Wehr und auch dir danke fürs Ausprobieren und Kommentieren. Die Hauptreferenz im Artikel zu definieren und dann auszublenden haben wir vor einer Weile schon diskutiert, uns aber dagegen entschieden, denn das wäre ein starker Bruch zum bisher bekannten Verhalten der Software: Wenn man im Wikitext einen ref Tag setzt, erwartet man, dass an der Stelle auch eine Fußnote erzeugt wird. Das zu ändern, würde es für Nutzer*innen und auch in technischer Hinsicht komplexer machen. Insofern bleibt für Subreferenzen – die man ja aber nicht nutzen muss – in aller Regel* nur das Definieren in der Einzelnachweisliste. Wir nehmen an, dass es für viele gerade bei Artikeln mit sehr vielen Einzelnachweisen schon übersichtlicher wird, wenn sie in der <references>-Liste definiert sind.

(* Ausnahme: wenn man im Artikel an einer Stelle tatsächlich auch das ganze Werk angeben will.) -- Beste Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 12:49, 21. Aug. 2024 (CEST)

Ich habe es vorhin ausprobiert, im Artikel Trailer trash mit der Quelle Katie M. Founds. Es hat leider nicht funktioniert. LG - Thylacin (Diskussion) 18:19, 20. Aug. 2024 (CEST)

Hast Du das in der aktuellen DE:WP ausprobiert, oder aber, wie in der Anleitung stehend, in der Betatest Umgebung ? --Archie02 (Diskussion) 22:03, 20. Aug. 2024 (CEST)

In der de-WP, da soll es doch schliesslich funktionieren,oder ? - Thylacin (Diskussion) 22:30, 20. Aug. 2024 (CEST)

Da es sich hier um eine in der Entwicklung befindliche neue Funktion handelt steht das Ganze in der DE:WP noch nicht zur Verfügung, sondern nur in der Testumgebung. siehe auch Wikipedia:Technische_Wünsche/Topwünsche/Subreferenzierung#_Teste_den_Prototypen --Archie02 (Diskussion) 23:15, 20. Aug. 2024 (CEST)

@Thylacin: Danke für deine Meldung. Wie @Archie02 schon sagte (danke!), ist die Funktion noch nicht fertig. Die Einleitung auf der Vorderseite sagt das jetzt noch klarer (hoffe ich). Was du schon testen kannst, ist die vorläufige Fassung auf dem Beta-Wiki. Ich würde mich freuen, wenn du das machst und dann hier noch mal berichtest, wie du es findest. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 13:01, 21. Aug. 2024 (CEST)

Ein weiter Test auf beta-de-Wiki

Gemeldet in Phabricator
Task T367749

ich habe den Artikel Explosion des Oppauer Stickstoffwerkes, den ich 2021 zur Lesenwert Auszeichnung gebracht habe, auf beta-de-Wiki übertragen und die Literaturstellen mit Subreferenzierung zusammengefasst. Durch die Zusammenfassung reduziert sich die Anzahl der Einzelnachweise von 103 auf 56, der Quelltext reduziert sich von 108 auf 89 kB (= 82 %). Die Veränderung des Quelltextes war einfach und problemlos.

Insgesamt finde ich die Umsetzung bereits recht gelungen. Ergänzend sollte es noch möglich sein, wie die Hauptreferenz, auch die Subreferenzen vom Typ <ref extends="Haller2013" name="Haller2013_351">Seiten 351-352</ref> in den Abschnitt <references> - z. B. unter der Hauptreferenz - zu platzieren. Das führt im Augenblick zu einer Fehlermeldung.

Die Subreferenzierung macht die EN nach meiner Meinung übersichtlicher und die Implementierung wäre aus meiner Sicht, sowohl für viele Autoren als auch für die Leser ein echter Mehrwert. Das wird aus meiner Erfahrung aber solche Autoren, bei denen die Formatierung von Einzelnachweise nicht Ansichtssache, sondern eine Glaubensfrage ist, nicht überzeugen. Trotzdem weiterhin viel Erfolg bei der Umsetzung. Gruß --Bert (Diskussion) 01:59, 22. Aug. 2024 (CEST)

Hallo Bert, vielen Dank fürs Testen und deine Rückmeldung dazu. Was den Fehler angeht: Ist das vielleicht derselbe wie hier beschrieben – phab:T367749? Falls nicht, würde ich einen neuen Fehlerbericht anlegen, dafür wäre es dann hilfreich, den Wortlaut der Fehlermeldung zu haben. -- Besten Dank und schönes Wochenende, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 16:08, 23. Aug. 2024 (CEST)

Ja im Prinzip ist es das beschriebene Problem. Die Referenz wird verwendet, bevor sie definiert wird:

::...Nach der Inbetriebnahme größerer Reaktoren stieg die Tagesproduktion im Jahr 1911 zunächst auf 30&nbsp;kg und dann 1912 auf 1000&nbsp;kg Ammoniak.<ref name="FFI2016_16" />
::...
::<references>
::<ref name="FFI2016">
::...
::</ref>
::<ref extends="FFI2016" name="FFI2016_16">Seite 16-17</ref>
::...
::</references>

Das sollte ja eigentlich kein Problem sein, denn das funktioniert ja auch bei der normalen Verwendung von <ref name=" ...">, wenn diese erst am Ende im Bereich <references> definiert werden. Stattdessen werden im angezeigten Text im Abschnitt Einzelnachweise 2 Fehlermeldungen angezeigt:

Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens FFI2016_16 wurde kein Text angegeben.

Referenzfehler: Ungültiges <ref>-Tag. Der Name „FFI2016_16“ wurde mehrere Male mit einem unterschiedlichen Inhalt definiert.

Ich habe den Fehler hier eingebaut, sodass du ihn nachvollziehen kannst. Gruß --Bert (Diskussion) 17:34, 23. Aug. 2024 (CEST)

Danke, Bert! Ich hab den Link auch im Ticket ergänzt. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 17:41, 23. Aug. 2024 (CEST)

@Bert.Kilanowski: Ich möchte noch ergänzen, dass man den Fehler im Wikitext aktuell umgehen kann, indem man beim wiederverwendeten Einzelnachweis name und extends setzt, also z. B. <ref extends="FFI2016" name="FFI2016_16" />

Das ist aber wirklich nur als Behelfslösung gedacht. Der Fehler soll schon richtig gelöst werden. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 09:43, 28. Aug. 2024 (CEST)

Update nach weiterem Finetuning wurde die Anzahl der EN von 103 auf 51 und der Text um knapp 19 % reduziert.

Ich möchte hier nochmal sagen, dass auch ich - im Gegensatz zu einigen anderen Kommentatoren - die Zusammenfassung der Einzelnachweise (Haupt- und in Zukunft auch Subreferenz) im Abschnitt <references>...</references> für sehr vorteilhaft halte und daher auch bereits seit vielen Jahren aktiv nutze. Denn einerseits erleichtert das die Lesbarkeit des gesamten Quelltextes, wenn im eigentlichen Text nur kurze EN vom Typ <ref name="Sanner" /><ref name=FFI2016 /> anstatt solche, die über mehrere Zeilen gehen <ref>{{Literatur |Autor=Lisa Sanner |Hrsg=Stadtverwaltung Ludwigshafen am Rhein |Titel=„Als wäre das Ende der Welt da“. Die Explosionskatastrophen in der BASF 1921 und 1948 |Reihe=Veröffentlichungen des Stadtarchivs Ludwigshafen am Rhein |BandRihe=42 |Ort=Ludwigshafen |Datum=2015 |ISBN=978-3-924667-47-4 |Seiten= |Kommentar=Dissertation LMU München unter dem Titel: ''Die Oppauer Explosion [21. September 1921] und die Ludwigshafener Kesselwagenexplosion [28. Juli 1948] in der BASF – eine Vergleichsstudie industrieller Katastrophen in Nachkriegszeiten''}}</ref><ref>{{Internetquelle |autor=Tor E. Kristensen |url=https://ffi-publikasjoner.archive.knowledgearc.net/bitstream/handle/20.500.12242/1259/16-01508.pdf?sequence=1&isAllowed=y |titel=A factual clarification and chemical-technical reassessment of the 1921 Oppau explosion disaster the unforeseen explosivity of porous ammonium sulfate nitrate fertilizer |werk=FFI-RAPPORT 16/01508 |hrsg=Norwegian Defence Research Establishment / Forsvarets forskningsinstitutt |seiten=1-69 |datum=2016-10-04 |format=PDF; 1,6 MB |sprache=en |abruf=2020-01-01}}</ref> verwendet werden. Zusätzlich erspart es insbesondere bei Mehrfachnennung das ständige Suchen nach bestimmten EN im gesamten Quelltext, weil ja alle EN kompakt und übersichtlich in einem Abschnitt zu finden sind. Im Beispielartikel kann man das sehr gut nachvollziehen. Wer es unvoreingenommen betrachtet, wird dem sehr wahrscheinlich zustimmen können. Aber es gibt halt auch Autoren, die ihre Arbeitsweise seit 20 Jahren keinesfalls ändern wollen und selbst die Verwendung von Literatur-Vorlagen, wie Vorlage:Literatur oder Vorlage:Internetquelle ablehnen. Gruß --Bert (Diskussion) 10:46, 24. Aug. 2024 (CEST)

hierzuwiki

Einleitung / 3. Absatz / 1. Satz lautet:

Die Funktion ist hierzuwiki noch nicht verfügbar.

Ist dieses "hierzuwiki" ein sinnvolles Wort? Was bedeutet es?

Oder ein Fehler?

Ping willkommen, Steue (Diskussion) 01:54, 23. Aug. 2024 (CEST)

Vergleichbar mit hierzulande, aber eben limitiert auf dieses Wiki-Projekt, in diesem Fall de.wikipedia.org. LG, --VECTR¹⁹³ONATOR (DISK) 09:36, 23. Aug. 2024 (CEST)

Hallo Steue, danke für deinen Hinweis, und danke auch an @VECTRONATOR. Der Begriff ist mir hier immer mal wieder untergekommen. Und weil er kürzer ist als „auf der deutschsprachigen Wikipedia“, nutze ich ihn auch ab und zu. -- Beste Grüße und ein schönes Wochenende, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 15:42, 23. Aug. 2024 (CEST)

Danke Johanna

Ich liebe neue Wortbildungen. Da dieses Wort, wie du gesagt hast, öfter vorkommt, sollte es auch über die allgemeine Suche in unserer WP findbar sein.

Mir würde es aber schwerfallen, das umzusetzen.

In oben genanntem Vorkommen habe ich es zum Link erst mal hier her gemacht.

Ping willkommen, Steue (Diskussion) 20:51, 29. Aug. 2024 (CEST)

Hallo Steue, wenn ich im Namensraum „Wikipedia“ nach „hierzuwiki“ suche, bekomme ich 645 Treffer. Meintest du es so? -- Beste Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 15:21, 5. Sep. 2024 (CEST)

Aaahh - Danke Johanna
Dass dieses "hierzuwiki" fast nur in den *Diskussionen* vorkommen würde, hatte ich ja schon vermutet, aber dass man auch *gezielt* in den *Diskussionen* oder im NamensRaum *WP* suchen lassen kann, hatte ich bisher übersehen.
Herzlichen Dank!

Mit diesen "654" (bei einer *meiner* Suchen sogar "684") wäre auch die im Raume gestandene Frage danach, wie oft es denn hierzuwiki vorkommt, beantwortet.

Nachdem ich ein biss-chen mit den Auswahl-Möglichkeiten der Suche herumgespielt hatte, bin ich bei der Suche *nur* in "Hilfe" auch auf Hilfe:Glossar gestoßen, wo "hierzuwiki" tatsächlich bereits erklärt wird ( was ich schon vorschlagen wollte ).
Herzlichen Dank für Deine Mühe, mir diesen SuchLink zu basteln.

Dieser erste Link in den 3 Ergebnissen dieser Suche führte aber - leider - nur zum *Anfang* des Artikels Hilfe:Glossar.
Besser wäre es gewesen, wenn er *unmittelbar* zu der Erklärung von "hierzuwiki" geführt hätte und führen würde.
Aber dazu müsste man wohl:

• 1)
  • alle diese StichWörter zu Überschriften machen oder
  • für alle diese StichWörter in Hilfe:Glossar Anker anlegen

und

• 2) dann auch noch für jedes StichWort eine WeiterLeitung anlegen;
  

oder welche Möglichkeit siehst Du?

Und, erst/nur, wenn für jedes StichWort ( bzw. wenigstens für "hierzuwiki" ) ein Ziel ( ÜberSchrift oder Anker ) vorhanden ist, könnte ja jemand, der "hierzukwiki" verwendet, es unmittelbar zu dieser Erklärung verlinken.

Liebe Grüße Steue (Diskussion) 21:52, 7. Sep. 2024 (CEST)

Warum würdest du denn für jedes Stichwort eine Weiterleitung anlegen wollen? Du brauchst lediglich in Hilfe:Glossar einen Anker anzulegen, auf den du dann in den betroffenen Artikeln das Wort verlinkst [[Hilfe:Glossar#hierzuwiki]]. Diskussionen sollten aber nicht nachträglich verändert werden und im Artikelnamensraum wird dieser Begriff wohl kaum verwendet werden. Ich finde es vollkommen legitim, dass der Begriff einfach bei Nachfrage erklärt wird. LG, --VECTR¹⁹³ONATOR (DISK) 19:59, 8. Sep. 2024 (CEST)

@Steue: Ich stimme @VECTRONATOR zu, dass ein Anker ausreichen sollte. Das ist aber nur meine Meinung, und die muss hier nicht viel zählen, denn Hilfeseiten werden von Ehrenamtlichen gepflegt und es gibt zahlreiche Menschen hierzuwiki ;), die da besser bescheid wissen als ich. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 14:20, 9. Sep. 2024 (CEST)

An VECTR¹⁹³ONATOR und Johanna Strodt (WMDE)

Ja, Ihr habt recht: wenn *ich* "hierzuwiki" verwenden will, würde *mir* ein Anker genügen.

Es gibt aber noch über 600 weitere Stellen, an welchen "hierzuwiki" ohne Link-Eigenschaft vorkommt. Und es werden sicherlich noch viel mehr werden.

Wenn:

• es ( nur ) in Hilfe:Glossar/* hierzuwiki einen Anker gäbe und
• dann jemand im WP-NamensRaum einfach nur nach "hierzuwiki" suchte, bekäme dieser Sucher trotz dieses Ankers den Anfang von Hilfe:Glossar zu sehen, oder?

Bei meinem Vorschlag dachte ich:

1) an jene Leser, die auf dieses Wort stoßen, an Stellen, wo es *kein* Link ist und

ich dachte 2) daran, eine Weiterleitung im "WP"-NamensRaum anzulegen

( in der Annahme/Hoffnung, dass dies möglich seie ) auf den Anker in Hilfe:Glossar/* hierzuwiki.

Ich wusste z.B. nicht, dass es Hilfe:Glossar gibt.

Falls es noch mehr so wie mich gibt, diese sich aber wenigstens so gut auskennen, dass sie gezielt im WP-NamensRaum nach "hierzuwiki" suchen ( lassen ) können, bekämen diese dann, wenn:

• eine Weiterleitung im WP-NamensRaum und
• der Anker bei "hierzuwiki"

vorhanden wären, **unmittelbar** die Erklärung von "hierzuwiki" zu sehen.

Steue (Diskussion) 18:18, 10. Sep. 2024 (CEST)

Dialog bei Beleg erstellen

Ich habe hier heute etwas geschnuppert. Insgesamt sieht das nach einer guten Arbeit aus und ein sehr nützliches, lang herbei gesehntes feature.

Die Belegerstellung mit dem Visual-Editor ist für mich neu, hierzu einige Fragen: Meine Erfahrungen:

• Die Funktion "Automatisch" führte bei mir sowohl mit ISBN als auch mit einer URL zu der Meldung "Nicht möglich"; bei welchen Eingaben geht dieses "feature"? (Wäre toll, wenn das funktionieren würde)
• Bei neuen Belegen mit dem Visual-Editor wird der <ref>-Tag offenbar immer an die zu belegende Stelle im Text eingefügt, könnte man auch eine Option einführen, dass die <ref>-Tag-Definition innerhalb des <references>-Bereiches postioniert wird? (Mit dem Quelltext-Editor lässt sich das ja nachträglich dorthin verschieben) – siehe hierzu auch #Ein weiter Test auf beta-de-Wiki
• Bei neuen Belegen wird das name-Attribut des <ref>-Tags offenbar vom Visual-Editor automatisch gesetzt. Wie wäre es mit einer Option, die es einem Autor erlaubt, einen sprechenderen Namen zumindest vorzuschlagen?
• Der Unterschied zwischen Wiederverwenden und extends im Dialog war mir anfangs nicht klar.

--ArchibaldWagner (Diskussion) 18:31, 23. Aug. 2024 (CEST)

Zustimmung zu allen Punkten. LG, --VECTR¹⁹³ONATOR (DISK) 10:12, 25. Aug. 2024 (CEST)

Hallo @ArchibaldWagner, danke fürs Testen und für die ausführliche Rückmeldung!

• Die automatische Funktion zum Erzeugen neuer Belege scheint in der Tat aktuell im Betawiki nicht zu funktionieren. In den contentwikis (also auch in dewiki) funktioniert es aber, z.B. hat das [6] gerade geklappt, aber auf beta konnte ich mit der ISBN / URL gerade auch keine Einzelnachweise erzeugen. Wenn du magst, kannst du es gern auf meiner verlinkten Testseite ausprobieren.

Mehr zur automatischen Belegfunktion siehe Hilfe:Einzelnachweise/VisualEditor – kann man übrigens auch im 2017 Quelltextmodus verwenden, was ich in meiner Volunteer-Rolle regelmäßig mache.

• Wir arbeiten aktuell noch an vielen Workflows im VisualEditor, in irgendeiner Form wird in der Hinsicht auf jeden Fall eine Anpassung erfolgen – z.B. dass ein Einzelnachweis automatisch nach unten verschoben wird, sobald man sie mit einer Subreferenz wiederverwenden und somit zur Hauptreferenz machen möchte, oder halt wie von dir vorgeschlagen, dass man auch im VisualEditor direkt Hauptreferenzen im Abschnitt Einzelnachweise definieren kann, bevor man im Artikeltext Subreferenzen hinterlässt.
• Diese automatische Benennung im VisualEditor ist in der Tat (schon jetzt auch bei normaler Wiederverwendung, ohne unser Feature) ärgerlich. Auf H:Einzelnachweise/VisualEditor#Vorhandenen Beleg erneut verwenden steht dazu "Sinnvoll ist es dort für die Namensattribute einen sprechenden Namen zu verwenden, um den Beleg beispielsweise zu einer Quelle aus dem Abschnitt Literatur oder Weblinks leichter zuzuordnen, falls du zur Quelltextbearbeitung wechselst. Leider ist die Anpassung der Namensattribute mit dem VisualEditor nicht möglich (Stand Februar 2017)." Wir prüfen, ob wir im Zuge unseres neuen Features auch dazu eine Verbesserung ermöglichen können.
• Wie gesagt arbeiten wir ja aktuell an verschiedenen VE-Workflows, es könnte z.B. sein, dass wir die Funktion unseres aktuell getrennten "Extends"-Tabs in den bereits existierenden Wiederverwenden-Tab integrieren und dann dort die Option anbieten, ob man einen Einzelnachweis identisch oder mit unterschiedlichen Details wiederverwenden möchte.

Viele Grüße --Johannes Richter (WMDE) (Diskussion) 13:15, 26. Aug. 2024 (CEST)

Frage zum Anlegen der Hauptreferenz

Ich hab auch geschnuppert und im Artikel zur Sendung mit der Maus einen Beleg + Subreferenzen angelegt. Habe diese Disk hier vorher nicht vollständig durchgelesen, d.h. vielleicht ist meine Frage dort schon beantwortet. Die Frage lautet:

• Wie lege ich die Hauptreferenz (z.B. Buchtitel ohne Angabe von Seitenzahlen) am elegantesten an? Diese Hauptreferenz würde ja im Artikel so nicht eingesetzt – dort würde ich ja mit den „Tochterelementen“, d.h. extends mit Seitenzahlen arbeiten. Ist es so gedacht, dass man die Hauptreferenz „zu Fuß“ im Quelltexteditor in den references-tag packt?.
• Davon abgesehen wäre die Funktion für mich eine deutliche Verbesserung des Ist-Zustands. An einer Alternative zur rätselhaften Bezeichnung „extends“ arbeitet ihr ja :-) --Kaethe17 (Diskussion) 12:26, 24. Aug. 2024 (CEST)

Ja, die Hauptreferenz soll in das <references> Tag rein, vorzugsweise damit sie besser gefunden und bearbeitet werden kann. LG, --VECTR¹⁹³ONATOR (DISK) 10:11, 25. Aug. 2024 (CEST)

Hi @Kaethe17, danke fürs Ausprobieren und für deine Rückmeldung!

Wie VECTRONATOR bereits schreibt, sollte die Hauptreferenz in der Tat im Einzelnachweis-Abschnitt definiert werden. Im Quelltext ist das natürlich kein Problem, für den VisualEditor arbeiten wir noch an einem flüssigen Workflow – z.B. dass ein Einzelnachweis im Hintergrund automatisch in eine Hauptreferenz umgewandelt und nach unten verschoben wird, sobald man ihn im VisualEditor mit Subreferenzen wiederverwenden möchte. Wir melden uns, sobald wir den Prototypen im Betawiki dafür geupdated haben. --Johannes Richter (WMDE) (Diskussion) 12:50, 26. Aug. 2024 (CEST)

Danke für die Info und frohes Schaffen weiterhin. --Kaethe17 (Diskussion) 13:59, 26. Aug. 2024 (CEST)

Kontraproduktiv

Abend.

Wer auch immer meinte das man das <references /> entfernen muss, hat den workflow rein auf die en.wiki aufgebaut und das feature ist für andere wiki's schlicht kontraproduktiv. --Alexandra von Dæmonicum _(Disk) 23:53, 25. Aug. 2024 (CEST)

Hallo @AlexandraTheDevil, danke für dein Feedback. Subreferenzierung entsteht auf starken Wunsch der dewiki-Community, die auch über die vielen Jahre, die unser Team daran arbeitet, stets primäre Quelle für Fragen und Feedback war. Wir haben natürlich auch enwiki und viele andere Sprachversionen konsultiert, aber ich kann dir versichern, dass in unserer Arbeit ganz viel dewiki-Input steckt, auch was die von dir kritisierte Lösung im Abschnitt Einzelnachweise betrifft. H:EN#Inhalt der Einzelnachweise am Ende des Artikels gibt es übrigens auch in dewiki. Letztendlich ist unsere Lösung ein Kompromiss in der technischen Umsetzung, damit die Hauptreferenz (ohne Details) nicht als eigene Fußnote im Artikeltext angezeigt wird, sondern nur die jeweiligen Subreferenzen. Theoretisch ist es auch möglich, die Hauptreferenz im Artikeltext zu belassen (insbesondere, wenn man sie irgendwo bewusst zitieren möchte, z.B. weil man für eine bestimmte Stelle keine Seitenangabe hat).

Aber keine Sorge: Niemand muss Subreferenzen nutzen, insbesondere bei kleineren Artikeln mit wenigen Belegen ist das wohl auch nicht nötig. Aber sehr lange Artikel können so für Lesende deutlich übersichtlicher werden, vgl. z.B. mit Blick aufs Feedback in #Ein weiter Test auf beta-de-Wiki den EN-Abschnitt in Explosion des Oppauer Stickstoffwerkes#Einzelnachweise (103 EN) mit dem Betawiki-Test [7] (52 EN, die man sogar noch weiter zusammenfassen könnte). Der Test zeigt auch noch ein paar Bugs, die wir beheben müssen, aber die Tendenz dürfte sichtbar sein. --Johannes Richter (WMDE) (Diskussion) 11:19, 26. Aug. 2024 (CEST)

Automatische Zusammenfassung

Warum sollte ein Computer nicht in der Lage sein gleiche Tags zusammenzufassen? --Avron (Diskussion) 08:28, 28. Aug. 2024 (CEST)

Hallo Avron, tatsächlich war das eine Überlegung, als wir im Rahmen unseres Themenschwerpunktes Wiederverwendung von Einzelnachweisen recherchiert haben. Es ließe sich bestimmt eine technische Lösung finden, um automatisch gleiche (oder fast gleiche) Einzelnachweise zu gruppieren / zusammenzufassen. Das würde allerdings allen Erwartungen widersprechen, die User aktuell an den Wikitext und Einzelnachweise haben.

Ohne die Nutzung erweiterter Befehle wie name, group oder künftig extends ist die Erwartung, dass der Wikitext <ref>...</ref> in der Einzelnachweisliste eine einzelne Referenz erzeugt, so wie wir auch an anderen Stellen im Wikitext uns immer darauf verlassen können, dass bestimmte Wikitextelemente zu genau einer Darstellung führen und nicht womöglich "magisch" die Darstellung für Lesende später anders aussieht, als im Wikitext definiert. Zumal es ja auch Fälle geben kann, wo eigentlich gleiche Einzelnachweise bewusst nicht zusammengefasst wurden. Deshalb haben wir uns im Austausch mit den Communitys entschieden, mit dem neuen Feature Nutzenden künftig selbst die Möglichkeit zu geben, Einzelnachweise mit verschiedenen Details wiederzuverwenden. --Johannes Richter (WMDE) (Diskussion) 14:31, 29. Aug. 2024 (CEST)

Richtig cool! Gerne "extends" kürzen

Hallo! Ich finde das richtig toll! Ich kann das SO gut gebrauchen! Und die Liste der ENs wird viel übersichtlicher. Ich arbeite im Quelltext und habe jetzt den Quelltext getestet. Ich würde u.U. für die Implementierung zum Visuell wechseln, wenn es dort einfach implementiert wird. Für meine Mentees ist Visuell sehr wichtig. Das einzige, was ich auf hohem Niveau anmerken möchte, ist dass mir das Wort "extends" zu lang ist. Gerne hätte ich da eine kurze Formulierung, so 3 - 4 Buchstaben. Danke! Super Job!  DomenikaBo aka Gerd | Autistin | | | ❤ |  15:28, 28. Aug. 2024 (CEST)

Danke, DomenikaBo. Das ist toll! Das Feedback zu "extends" gebe ich weiter. -- Beste Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 09:58, 29. Aug. 2024 (CEST)

Literaturverzeichnis und Einzelnachweise

Ich habe mich entschlossen, meine Bemerkungen zum Thema Integration von Literaturverzeichnis und Einzelnachweisen aus dem gleichnamigen Abschnitt hier zu entnehmen und einen eigenen Abschnitt daraus zu machen. Der Grund dafür ist, dass die Diskussion oben weitgehend abgeschlossen war und sich zuvor in Details verloren hatte. Vor allem aber ist zwar das Problem dasselbe, aber mein Ansatz ganz anders: gekürzte Einzelnachweise sind nicht mehr nötig – die Diskussion, wie man das macht, ist obsolet. Es geht nur noch darum, wie die bibliografischen zwischen Literaturverzeichnis und Einzelnachweisen zuverlässig zu koordinieren.

Es folgt die bisherige Diskussion, die ich mit allen Beiträgen unverändert hierher verschoben habe, beginnend mit einem Beitrag von mir von vor drei Tagen. --Lantani (Diskussion) 16:23, 8. Sep. 2024 (CEST)

Das Thema Integration von Literaturverzeichnis und Einzelnachweisen liegt mir sehr am Herzen, vor allem, weil ich vermeiden will, dass bibliographische Angaben getrennt erfasst werden und damit auseinanderlaufen können. Vielleicht ist das alles ja schon im neuen Modell enthalten: dann bitte ich um kurze Erläuterung, wie.

Meine Anliegen sind:

• Literaturstellen, die mehrfach vorkommen, sollen nur einmal angegeben werden müssen, auch dann, wenn sie sowohl in Literatur (LIT) als auch in Einzelnachweisen (EN) vorkommen. Dass sie in bestehenden Artikeln sehr oft mehrfach angegeben sind, weiß ich, kann das nicht ändern und hoffe, dass das bei vielfacher Überarbeitung der Artikel etwas seltener wird.
• Es ist mir überhaupt nicht wichtig, dass der Text in Einzelnachweisen eine Abkürzung der vollen Bibliographie ist. Im Gegenteil: ich hasse es, wenn ich bei einem EN nur „Müller 1954“ erfahre und dann noch in LIT den Rest suchen muss. Verlinkungen helfen wenig, weil sie nicht zielgenau sind und man dann doch länger suchen muss. Solche an das unselige „a. a. O.“ alter Zeiten erinnernden Behelfsmethoden waren vielleicht mal notwendig, weil man nicht bei 17 Zitaten die volle Bibliografie eines Werkes 18mal im gesamten Text haben will, nämlich in den 17 EN-Fußnoten und in LIT. Aber das fällt ja mit der Subreferenzierung weg: es sind dann eh nur 2 Stellen, wo die Bibliographie steht, nämlich als erste Zeile aller EN zu diesem Werk und einmal in LIT.

Das zu realisieren (falls es nicht von mir unbemerkt schon geschehen ist), erfordert m. E. keine großen Änderungen, sondern nur eine, nämlich einen zusätzlichen Parameter in <ref> (ich nenne ihn „hier“), mit dem bestimmt wird, dass der Inhalt nicht in einer Fußnote, sondern an der Aufrufstelle von <ref> eingefügt werden soll. Beispiel:

  Lorem ipsum<ref extends="Müller 1954">S. 137</ref> dolor sit amet, consetetur
  sadipscing elitr, sed diam<ref extends="Huber 1973">S. 26</ref> nonumy eirmod
  tempor<ref extends="Müller 1954">S. 155</ref> invidunt ut labore et dolore magna
  aliquyam erat, sed diam voluptua.

  == Literatur ==

  * <ref hier="hier" extends="Müller 1954">S. 110–157</ref>

  == Einzelnachweise ==

  <references>
    <ref name="Müller 1954">{{Literatur |Autor=Hieronymus Müller |Titel=Einführung in die Wikiologie |Ort=Hameln |Datum=1955}}</ref>
    <ref name="Huber 1973">{{Literatur |Autor=Balthasar Huber |Titel=Müllers Beitrag zur Wikiologie |Ort=Augsburg |Datum=1973}}</ref>
  </references>

Im Beispiel stehen in LIT die Seitenzahlen von Müllers Beitrag zu einem Sammelwerk, in den EN aber die genauen Seitenzahlen der Zitate.

Wenn so ein Parameter eingeführt wird, sollte er 3 mögliche Werte haben: Fußnote machen, hier hinschreiben, Hauptreferenz; Voreinstellung: Hauptreferenz innerhalb von <references>-Elementen, sonst Fußnote.

Wenn ich mich nicht irre, ist das einfacher als der Vorschlag von Vollbracht und deckt das Problem ab. --Lantani (Diskussion) 17:31, 5. Sep. 2024 (CEST)

Ich verstehe sehr gut, wenn Du Dich über Kurzreferenzen ärgerst, zu denen man die vollständigen Angaben erst suchen muss. Aber, wie kommst Du darauf, dass ein Link, der eine Kurzreferenz mit einem vollständigen Eintrag verbindet, "nicht zielgenau" sein könnte? Wenn es richtig gemacht wird (analog zu der <ref>-Mechanik), dann sieht man im EN-Verzeichnis den Link, und zumindest PC-Benutzer können onHoover sofort auch die vollständigen Infos sehen. Missverständnisse sind damit ausgeschlossen. Einzig, wenn wir in einem Artikel tatsächlich mal mehr als einen EN vom selben Autor aus demselben Jahr angeben sollten, reichen Nachname und Jahr allein nicht mehr. Aber wir sind ja nicht im enWiki. Wir generieren ja in der Regel die Kurznamen nicht automatisch und können entsprechend "Bond 2007a" und "Bond 2007b", oder "Bond 2007" und "Bond 2007 für Dummies" referenzieren. --Vollbracht (Diskussion) 21:33, 5. Sep. 2024 (CEST)

Mein wesentlicher Punkt ist, (1) dass man nur ein einziges Mal die volle Bibliografie eines Buches abliefern muss, so dass bei einer Änderung (z. B. neuer Link auf Digitalisat) bei allen Vorkommen, LIT wie alle ENs, die Änderung synchron vollzogen wird und (2) dass der Mehraufwand m. E. minimal ist, weil die Subreferenzierung bereits fast alles enthält, was man braucht, insbesondere die Möglichkeit, dass die LIT-Angabe in Details anders aussieht als die ENs. Das Ding mit „nicht zielgenau“ war eine weit weniger wichtige Randbemerkung.

Gemeint war damit: was beim Anklicken eines Links wirklich passiert, ist stark geräte- und browserabhängig. Wenn man bei den ENs ist, also am Ende des Artikels, stehen mit mittlerer Wahrscheinlichkeit die LITs weiter oben auf demselben Bildschirmfenster, nämlich dem, das am unteren Fensterrand das Ende des Artikels stehen hat. Bei vielen Browsern ändert aber der Sprung auf einen Anker, der schon dasteht, gar nichts. Man muss dann also das LIT-Verzeichnis mit den Augen absuchen, wo der Text steht, der passt. Wenn Hover auf dem Gerät existiert, also auf dem Smartphone schon mal nicht (oder hab ich was verpasst?), siehts besser aus. Jedenfalls kann man nicht garantieren, dass die bibliografischen Angaben zu einem EN gleich gefunden werden. Umgekehrt: wenn von Abkürzungsmöglichkeiten bei ENs kein Gebrauch gemacht wird, ist eh jeder EN komplett, egal ob beim Hovern angezeigt oder wirklich hingeklickt. Also kein Verlust gegenüber komplexeren Lösungen. --Lantani (Diskussion) 10:29, 6. Sep. 2024 (CEST)

O.k. Das erstaunt mich jetzt. Kannst Du ein Gerät (oder Browser) nennen, bei dem ein Link innerhalb einer Seite nicht funktioniert? --Vollbracht (Diskussion) 15:12, 6. Sep. 2024 (CEST)

Verstehe ich Dich richtig? Möchtest Du, dass eine detaillierte Literaturangabe zwar nur 1x eingetragen, aber mehrfach angezeigt wird? --Vollbracht (Diskussion) 15:15, 6. Sep. 2024 (CEST)

1. Frage: Ich kann ja mal ein Beispiel basteln, wo das vorkommt. – 2. Frage: Ja, steht am Anfang, 1× eintragen, 1× anzeigen (entweder LIT oder EN) oder 2× anzeigen(beides), nicht öfter. --Lantani (Diskussion) 16:47, 8. Sep. 2024 (CEST)

Als Attribut würde dann aber "hier" nicht in Frage kommen. Tags und Attribute müssen ja vor allem auch im enWiki verständlich sein. Hier könnte man mit pos="lit", pos="lit, ref" und default: pos="ref" arbeiten.

Eine Darstellung der vollständigen Literaturangabe sowohl im Literatur- als auch im EN-Verzeichnis würde ich eher nicht bevorzugen, bin dafür aber offen. Vor allem warte ich dazu natürlich auf Dein Beispiel. --Vollbracht (Diskussion) 18:12, 8. Sep. 2024 (CEST)

Vor allem würde ich mir allerdings für die Variante mit pos="lit" wünschen, dass in den Einzelnachweisen mit der Angabe der Textstelle innerhalb der Literatur eine Form existiert, aus der heraus nicht mit einem "¹", sondern mit einem sprechenden Link, vorzugsweise in Harvard-Notation in das Literaturverzeichnis hinein verwiesen wird. Wenn wir das strukturiert durchdenken, wie wird dann Deiner Meinung nach die Syntax am besten überzeugen? --Vollbracht (Diskussion) 18:23, 8. Sep. 2024 (CEST)

Mir ist gerade aufgefallen, dass Du die Möglichkeit in Betracht ziehst, eine Literaturangabe im Fließtext zu integrieren (ohne Fußnote). Traditionell müsste auch eine solche Literatur im Literaturverzeichnis (oder auch im EN-Verzeichnis) auftauchen. Bisher machen wir so etwas eher nicht. Hierbei würden wir natürlicherweise aber auch eine Redundanz schaffen, die es zu vermeiden gilt. Könntest Du Dich der Sicht anschließen, dass im Fließtext dann ein Kurzname als sprechender Link in das Literaturverzeichnis hinein verwendet werden sollte? --Vollbracht (Diskussion) 18:37, 8. Sep. 2024 (CEST)

Guter Punkt, an den ich nicht gedacht habe. Er hat einen inhaltlichen und einen Wikisyntax-Aspekt.

• Inhaltlich: Ich fände es in meinem Modell die richtige Vorgehensweise, die Hauptreferenz wie alle anderen im <references>-Element unterzubringen und mit Fußnote darauf zu verweisen. Wieviel man vom Namen des Autors, des Werkes und der Jahreszahl im Fließtext verrät und in welcher Form, muss der Autor entscheiden. Nein, er soll dort nicht die ganze bibliografische Referenz oder große Teile davon einfügen.
• Wiki-Syntax: Es ist richtig, mein Vorschlag lässt die Möglichkeit offen, die Einfügung des vollen Textes der Hauptreferenz nicht auf das LIT zu beschränken. Diese Möglichkeit war nicht beabsichtigt. Sie ist dadurch entstanden, dass man von einem <ref>-Element zwar syntaktisch feststellen kann, ob es Kind eines <references>-Elements ist, nicht aber, ob sie zum Scope einer Überschrift == Literatur == gehört: für die Wiki-Syntax ist das LIT Text wie jeder andere.

Wie die Syntax am Schluss aussieht, ist mir zwar nicht ganz egal, aber ich finde es zweitrangig. Ich werde mal ein Top-Down-Modell (was will der Bearbeiter schreiben und wie macht er das?) zusammenstellen, wo das auch vorkommt. Die jetzige Beschreibung von <ref> und Konsorten ist mir zu Bottom-Up (was bietet die Schnittstelle alles an und wozu kann man es gebrauchen?). Und weiter ist mir wichtig, dass das alles mit dem Werkzeug geht, das jetzt fertig geworden ist – mit allenfalls kleinen Modifikationen.

Für diesen Use-Case habe ich übrigens ein Beispiel von mir selbst: in Swahili (Sprache) #Ausbreitung zitiere ich Krapf, Steere, und Sacleux ohne Link – das sind keine Kandidaten für EN, sondern für LIT, und die kann man nicht verlinken (oder es muss einen dokumentierten Standard-Weg geben, das zu tun). --Lantani (Diskussion) 20:52, 8. Sep. 2024 (CEST)

Das Konzept der Subreferenzen hat mich überhaupt noch nicht überzeugt. Ich denke, wenn wir damit arbeiten, bleibt immer noch die Entscheidung, ob wir dieselbe Literatur zunächst im Literaturverzeichnis haben wollen, oder nicht. Wenn wir sie im Literaturverzeichnis haben wollen, dann sollte die vollständige Literaturangabe meiner Meinung nach nicht auch im EN-Verzeichnis stehen. Damit der Leser sofort sieht, dass es hier um wichtige Literatur geht, sollte statt dessen ins Literaturverzeichnis hinein verlinkt werden. Wenn das aber geschieht, wird eine Kurzbezeichnung als sprechender Linktext benötigt. Wenn die aber vorliegt, können ohne Subreferenzierungen kurze verständliche, schnell erfassbare aber nicht weniger eindeutige EN-Einträge erzeugt werden.

Die verlinkten Kurzbezeichnungen ermöglichen dann wiederum sehr überzeugend im Fließtext auf eine Literatur Bezug zu nehmen. Das (beide Konzepte!) sollte dann z. B. so aussehen:

Der erste Teil des Romans ist Die Gefährten. Da drin geht's los.^[1]

Literatur

• Die Gefährten - J. R. R. Tolkien: Der Herr der Ringe. Band I: Die Gefährten. Verlag, Stadt Datum.

Einzelnachweise

1. ↑Die Gefährten S. 1.

Und jetzt besteht die Frage, wie das für den Editor am einfachsten und verständlichsten zu codieren sein sollte. Mein erster Ansatz wäre in diesem Beispiel:

Der erste Teil des Romans ist <lit name="Die Gefährten>J. R. R. Tolkien: ''Der Herr der Ringe.'' Band I: ''Die Gefährten.'' Verlag, Stadt Datum.</lit>. Da drin geht's los.<ref><lit name="Die Gefährten" /> S. 1.</ref>

==== Literatur ====
<literatur />

==== Einzelnachweise ====
<references />

Das wurde von Johanna Strodt (WMDE) bereits als technisch sehr komplex kritisiert. Mein zweiter Ansatz erscheint mir etwas hakeliger: eine Spezialbehandlung für das <ref>-Tag für den fall, dass sein Attributwert "group" einen speziellen Wert, nämlich group="lit" annimmt In dem Fall müsste auch ein Attribut name="<Kurzbezeichnung>" gefordert werden. Das Beispiel hier wäre dann:

Der erste Teil des Romans ist <ref group="lit" name="Die Gefährten>J. R. R. Tolkien: ''Der Herr der Ringe.'' Band I: ''Die Gefährten.'' Verlag, Stadt Datum.</ref>. Da drin geht's los.<ref><ref group="lit" name="Die Gefährten" /> S. 1.</ref>
	
==== Literatur ====
<references group="lit" />
	
==== Einzelnachweise ====
<references />

Vermutlich würden zumindest in diesem zweiten Fall auch im Literaturverzeichnis Backlinks (1x ins EN-Verzeichnis und 1x in den Fließtext) erzeugt werden. Das wäre nicht das Schlechteste. Auch das <references group="lit" />-Tag würde sich mit diesem speziellen Wert seines "group"-Attributs geringfügig anders verhalten und an Stelle der Nummerierung den Wert des "name"-Attributs als Ordnungsmerkmal und als Linkanker verwenden.

Das ist, was ich mir unter top-down in Deinem Sinne vorstellen würde. Was siehst Du als Alternativen?

--Vollbracht (Diskussion) 21:44, 8. Sep. 2024 (CEST)

Mich hat das Konzept der Subreferenzen überzeugt, und deswegen habe ich den Versuch unternommen, genau auf Basis dieses Konzepts die LIT mit einzubinden, ohne alles anders zu machen. Das ist nicht dein Ansatz. Aber deswegen bin ich ja aus deinem Diskussionsabschnitt ausgezogen, um Lösungen auf dieser Basis zu diskutieren. Deine bisherigen Beiträge in diesem Abschnitt hier hatten damit zu tun, besonders der vorletzte. Der von heute 21:44 aber überhaupt nicht. Selbstverständlich hast du das Recht, eine andere Meinung zu haben und dazugehörige Vorschläge zu machen, aber diskutiere sie bitte nicht in diesem Abschnitt, sondern in dem oben oder in einem neuen. Hier geht es um die Einbindung von LIT in die Subreferenzierung, nicht um völlig neue Ideen zur Gestaltung des Literaturverzeichnisses. Den Off-Topic-Teil habe ich gelöscht; der Text steht ja in der Vorgängerversion für jeden zur Verfügung, der sich dafür interessiert.

Was finde ich am Konzept der Subreferenzen überzeugend? Ganz kurz:

• Für EN ist sie das, was wir brauchen.
• Wenn ich mich nicht irre, ist es einfach, sie zur Einbindung von LIT-Angaben mitzuverwenden – das ist diese Diskussion hier.
• Und am wichtigsten: es gibt sie jetzt schon im Probebetrieb; alles andere wäre ein völlig neuer Vorschlag mit entsprechender Vorlaufzeit. Ich will kein anderes Konzept, sondern suche nach einer Möglichkeit, das jetzt realisierte für einen weiteren Zweck (nämlich LIT) mitzuverwenden.

Aber auch diese Punkte bitte nicht hier diskutieren, sondern vielleicht in einem neuen Abschnitt. Schon der obere ist daran gestorben, dass er mit seitenweise Details überfrachtet wurde, bis ihn keiner mehr gelesen hat.

Ich schulde noch die Antwort auf die Frage, warum ich Links nicht toll finde, die auf eine Zeile in der Literaturliste zeigen. Die Antwort: Benutzer:Lantani/Literaturliste mit Ankern --Lantani (Diskussion) 00:23, 9. Sep. 2024 (CEST)

Danke, dass Du Dir die Mühe mit der Beispielseite gemacht hast. Deiner Bitte entsprechend habe ich auf der Diskussionsseite dieser Beispielseite dargelegt, weshalb mir dieses Beispiel als Argument nicht geeignet erscheint.

Offensichtlich versuche ich für Deinen Geschmack übertrieben präzise zu argumentieren. Umgekehrt erscheinen mir Deine Beiträge nicht immer verständlich genug. Deine Löschung von Teilen meines letzten Beitrags sollte, wenn ich Dich richtig verstanden habe, nur ein temporäres Phänomen sein. Sicher wolltest Du den Inhalt insbesondere mit der vollständigen Argumentationskette an anderer Stelle auf dieser Seite wieder herstellen. Eine solche Verschiebung erscheint mir nicht notwendig oder sinnvoll. Es geht immer noch darum, wie Literatur- und EN-Verzeichnis technisch elegant in Beziehung zu einander gesetzt werden sollten. Auf Nachfrage stelle ich gerne dar, wie ich mir die Kombination meines Vorschlags mit der Subreferenzierungsform vorstelle. Zunächst aber widerlege mir eines meiner Argumente in der Kette, denn um Geschmäcker muss es hier nicht gehen. Wichtiger aber sollte natürlich sein, dass Du vom Ziel (wie es hinterher aussehen soll) ausgehend Deine Wünsche präzisierst. --Vollbracht (Diskussion) 01:04, 9. Sep. 2024 (CEST)

Ich muss jetzt ein paar Tage Pause machen, sonst bleibt zu viel anderes liegen – innerhalb und außerhalb der WP. Fr den 13. peile ich mal an. --Lantani (Diskussion) 09:51, 9. Sep. 2024 (CEST)

Hallo zusammen, siehe dazu meine ausführliche Antwort weiter oben. Wir sind inzwischen aus dem Konzeptstadium heraus, weshalb wir so grundsätzliche Alternativvorschläge leider nicht mehr berücksichtigen können. Viele Grüße -- Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 14:13, 9. Sep. 2024 (CEST)

Hallo Johanna, deine Antwort bezieht sich ausschließlich auf die Vorschläge von Vollbracht, überhaupt nicht auf meinen. Die beiden haben nichts, aber auch gar nichts miteinander zu tun, sondern sind diametral entgegengesetzt:

• Vollbrachts Vorschlag kennst du. Er enthält eine Menge neuer Syntax, so dass er schon deswegen kaum jetzt realisierbar ist. Ob er sonst die Probleme löst, habe ich nicht genau untersucht.
• Mein Vorschlag geht dagegen genau von der jetzt implementierten Lösung mit Subreferenzierung aus und enthält nur ein einziges zusätzliches Feature: Man möge eine Möglichkeit schaffen, eine Hauptreferenz, die der Bearbeiter im <references>-Element als <ref name="… angelegt hat, mit ihrem Wortlaut auch in der Literaturliste (LIT) verwenden zu können. Das geht durch die Subreferenzierung auch dann, wenn die Literaturangabe etwas verschieden von den EN ist; siehe erstes Beispiel hier. Damit spart man sich nicht nur die Kopie (und anschließende Konsistenthaltung!) der bibliographischen Angaben (BIBLGR); vor allem kann (nicht muss!) man dann aufräumen, indem man alle BIBLGR als Hauptreferenzen in <references> setzt, egal, wie man sie verwenden will:
  • als Muster für EN mit Detailangaben (also mit „extends“), produziert Fußnote im Text
  • als Verweis aufs ganze Werk mit Fußnote (selten, kommt aber vor)
  • als Teil der LIT, ausgewählt und nach beliebigen Kriterien sortiert, Volltext der BIBLGR
  • natürlich auch mehrere dieser Optionen gleichzeitig

Dadurch kann man sich den ganzen Zirkus mit Kurzzitatformen („Meier 1995“) sparen, mit den man aus Einzelnachweisen in die Literaturliste springt. Das steht alles in meinen Beiträgen hier, die vielleicht ein wenig zu langatmig sind, aber doch in fünf oder zehn Minuten überflogen werden können.

Ich habe wirklich verzweifelt versucht, durch Verlagerung meines Beitrags weg vom bisherigen Abschnitt auf einen neuen die Diskussionen zu trennen, aber Vollbracht ließ es sich nicht nehmen, hier dazwischen lange Beispiele aus seinem Ansatz abzuladen, so dass tatsächlich optisch der Eindruck entstehen konnte, wir arbeiteten an derselben Idee. Ich wusste mir einmal nicht anders zu helfen, als etwas zu tun, was ich in den fast 20 Jahren hier noch nie getan habe: lange Passagen von meinem Vorredner einfach herauszuschneiden (und dabei deutlich darauf hinzuweisen), weil sie einfach meine Beiträge lawinenartig zuschütten – mit Erfolg, wie es scheint. Sie wurden natürlich von Vollbracht restauriert. Unmittelbar nach dieser Löschung stand in dem Abschnitt genau mein Vorschlag drin, dazu Rückfragen und deren Beantwortung. Diese Version ist die am leichtesten lesbare, wenn du erfahren willst, was ich wirklich vorgeschlagen habe und was meine Prioritäten bei der Beurteilung dieser Vorschläge sind. Ich bitte dich darum, das kurz zu tun. --Lantani (Diskussion) 08:57, 10. Sep. 2024 (CEST)

Hallo @Lantani, Verzeihung, das ist mir wirklich durchgerutscht. Ich schaue es mir an und melde mich (wahrscheinlich kommende Woche) wieder bei dir. Danke fürs Nachhaken. -- Viele Grüße, Johanna Strodt (WMDE) Diskussion Projekt Technische Wünsche 09:39, 10. Sep. 2024 (CEST)

Darf ich Dich bitten, den Text, den Du mit "Lorem ipsum ..." kodiert hast, hier zu simulieren, so, wie nach Deinen Vorstellungen für den Leser aussehen soll? --Vollbracht (Diskussion) 14:59, 10. Sep. 2024 (CEST)

Zum ganzen Beitrag: Ich will betonen, dass es mir vor allem um die Funktionalität Zugriff auf den Text von Referenzen nicht nur als Fußnoten geht, und gar nicht um die konkrete Syntax. Wenn jemand statt <ref hier="hier" extends="Müller 1954">S. 110–157</ref> lieber <lit extends="Müller 1954">S. 110–157</lit> hübscher findet, ist das genau so gut. Finde ich inzwischen sogar besser, weil die Syntax von <ref> mit Name sowieso schon zu viele verschiedene Bedeutungen hat (erkläre ich später).

Zur Frage von Vollbracht: Muss man nicht simulieren, kann man ausprobieren. Ich habe mich allerdings noch nicht in die Benutzung des Prototyps eingearbeitet. Wenns nur darum geht, dass der Inhalt des <ref>-Tags komplett », S. 110–157« hätte heißen müssen: Ja, hätte er.--Lantani (Diskussion) 18:15, 17. Sep. 2024 (CEST)

Syntax und Semantik des ref-Elements sehr komplex; könnte viel einfacher sein

Ich weiß nicht, ob der Syntax-Zug endgültig abgefahren ist, aber ich finde die Syntax unnötig komplex und damit fehleranfällig. <ref name="…"> hat schon jetzt eine verwirrende Syntax, und mit extends wirds noch schlimmer. Ich bin drauf gekommen, als ich mir überlegte, wie man die vielen Varianten so beschreiben kann, dass der Nutzer weiß, was er zu tun hat (siehe kurz ganz am Ende dieses Beitrags).

Bei allen WP-spezifischen Tags, also nicht nur <ref>, gilt jetzt schon für selbstschließende Tags im Wesentlichen die XML-Syntax (allerdings ohne die Regel, dass jedes Tag geschlossen werden muss), nicht die HTML5-Syntax. Nämlich: <tagname … /> ist äquivalent zu <tagname …></tagname>. (HTML5-Syntax wäre: <tagname … /> ist äquivalent zu <tagname …>. Für Tags ohne zugehöriges End-Tag ist das dasselbe; für welche mit End-Tag ist das verheerender Unfug, der aber leider Norm ist.) WP hat diese Entscheidung richtig getroffen; alles andere wäre Quatsch gewesen. Schon beim jetzigen Tag <ref name="…"> geht das so, und das ist wichtig, denn das Tag gibt es mit oder ohne Inhalt, und zwar mit völlig verschiedener Funktion. Und da fängt die bis jetzt noch leichte Verwirrung an:

Bisherige Syntax:

1. ohne Inhalt: <ref name="ABC" /> = <ref name="ABC"></ref> verwendet den Inhalt namens ABC durch Anbringen eines Fußnotenverweises.
2. mit Inhalt im <references>-Element: <ref name="ABC">Verweis auf ABC</ref> definiert den Inhalt namens ABC, hier „Verweis auf ABC“.
3. mit Inhalt woanders: <ref name="ABC">Verweis auf ABC</ref> definiert den Inhalt namens ABC, hier „Verweis auf ABC“ und verwendet ihn gleich an Ort und Stelle.
4. Eine Verwendung eines Textes mit einem definierten Namen ist nur durch Setzen einer Fußnote möglich, nicht aber als Bestandteil eines Literatur-Abschnitts. Das habe ich schon mal geschrieben, dass ich das schade finde. Ich diskutiere es hier nicht noch einmal – also hier nur als „ceterum censeo“.

Lassen wir die neue Syntax wie bisher vorgeschlagen, dann gilt folgendes:

Neue Syntax wie bisher entworfen:

1. ohne Inhalt, ohne extends: <ref name="ABC" /> = <ref name="ABC"></ref> verwendet den Inhalt namens ABC durch Anbringen eines Fußnotenverweises (wie bisher)
2. ohne Inhalt, mit extends : <ref extends="ABC" /> = <ref extends="ABC"></ref> ist genau dasselbe, weil das Anbringen eines leeren Zusatzes nichts verändert. (neue Syntax für alte Wirkung)
3. mit Inhalt im <references>-Element: <ref name="ABC">Verweis auf ABC</ref> definiert den Inhalt namens ABC, hier „Verweis auf ABC“. (wie bisher)
4. mit Inhalt im <references>-Element: <ref name="ABC1" extends="ABC">, Zusatz</ref> definiert den Inhalt namens ABC1, hier „Verweis auf ABC, Zusatz“.
5. mit Inhalt woanders: <ref name="ABC">Verweis auf ABC</ref> definiert den Inhalt namens ABC, hier „Verweis auf ABC“ und verwendet ihn gleich an Ort und Stelle (wie bisher)
6. mit Inhalt woanders: <ref name="ABC1" extends="ABC">, Zusatz</ref> definiert den Inhalt namens ABC1, hier „Verweis auf ABC, Zusatz“ und verwendet ihn gleich an Ort und Stelle.

Ob das Feature jetzt funktioniert, dass man einen neuen Inhalt unter Verwendung eines alten definieren kann (Fälle 4 und 6), weiß ich nicht. Eine naheliegende Semantik wäre es durchaus. Man muss natürlich die Zyklenfreiheit überprüfen.

Ich finde es sehr unübersichtlich, dass die zwei verschiedenen Funktionen Definition und Verwendung eines definierten Namens für ein Stück Text mit demselben Parameter name geschehen; ist ja bei <a name="…"> oder <div id="…"> auch nicht so. Jetzt wäre noch die Gelegenheit, es besser zu machen:

Vorschlag neue Syntax (ist logisch viel einfacher und nur selten anders):

• Verwendung eines definierten Inhalts mit oder ohne Zusatz immer mit text, das dieselbe Bedeutung hat wie oben extends. Weil das auch dann verwendet wird, wenn der bezeichnete Text ohne Zusatz verwendet wird, soll es nicht mehr extends heißen. Dabei kann auch ein Zusatz im Inhalt des <ref>-Elements mit angegeben werden wie beim jetzigen extends. Beispiel: <ref text="ABC">, Zusatz</ref> verwendet den unter dem Namen ABC definierten Text mit dem Zusatz „, Zusatz“. Ohne Zusatz genügt <ref text="ABC" />.
• Definition eines einzusetzenden Textes immer mit name wie bisher. Falls das durch Erweiterung eines schon definierten Inhalts geschieht, wird der mit text bezeichnet und der Inhalt des <ref>-Elements ist nur der neue Zusatz.

{ Nachtrag am 05.11.2024 15:14 }
Diese Zuordnung einer Bedeutung zu einem <ref>-Tag hat die Eigenschaft, dass alle variablen Felder des <ref>-Tags bei allen Verwendungen immer dasselbe bedeuten. Das ist weder bei der bisher gültigen Syntax noch bei der bisher geplanten Erweiterung mit extends der Fall; vielmehr ergibt sich dort die Bedeutung eines Parameters erst daraus, welche anderen auch vorkommen sowie aus der Stellung des Tags im Artikel (siehe beide Aufzählungen oben).

Das allgemeinste <ref>-Tag hat die Form

<ref [name="name-Parameter"] [text="text-Parameter"]>[Inhalt des Elements]</ref>

wobei jeder der drei eckig eingeklammerten Teile vorhanden sein oder fehlen kann (bis auf das Fehlen aller drei). In jeder Kombination ist die Bedeutung:

• Der vom <ref>-Element generierte Fußnotentext besteht aus dem Wert, der dem text-Parameter zugeordnet ist (soweit vorhanden), gefolgt vom Inhalt des Elements.
• Ist ein name-Parameter vorhanden, so wird ihm dieser Text als Wert zugeordnet und keine Fußnote erzeugt; andernfalls wird ein Verweis auf eine Fußnote mit diesem Text erzeugt.

{ Ende des Nachtrags }

Aus Kompatibilität mit bisheriger Syntax sollten die Fälle 1 und 3 der obersten Aufzählung weiter geduldet werden (Fall 2 bleibt ja, wie es ist). Geht widerspruchsfrei. Oder automatsich abändern (s. u.).

Meine Bemerkung „nur selten anders“ hat folgende Bewandtnis:

• Der jetzt weitaus häufigste Fall, dass die ganze Referenz komplett und ohne Zusätze an der Aufrufstelle steht, also <ref>…</ref>, wird weder von der Subreferenzierung noch von meinem neuen Syntaxvorschlag oder dessen Kompatibilitätsoption tangiert.
• Der Fall, dass die Referenz komplett und ohne Zusätze im <references>-Element steht (genau dort soll sie ja in genau dieser Syntax stehen), führt per Kompatibilitätsoption nur dazu, dass an anderer Stelle ein nacktes <ref name="ABC" /> so verarbeitet wird, als hätte statt name dort text gestanden. Aber <ref name="…" /> ohne Inhalt kommt sonst nicht vor, so dass keine Verwechslungsgefahr besteht.
• Die zweifelhafte Praxis, Namen von Textstücken an einer beliebigen Aufrufstelle zu definieren, muss man aus Kompatibilitätsgründen akzeptieren, dürfte aber schon jetzt nicht umwerfend häufig sein. Diese Fälle sind dann „depracated“, sollten folgenlos angemeckert und nach und nach eliminiert werden. Man kann sie auch bei einer Änderung des Artikels automatisch eliminieren, da alles bekannt ist: alle Inhaltstexte und der verwendete Name; so etwas ähnliches macht doch der VE auch (nur dass der dazu Namen erfindet).

Eine verständliche und übersichtliche Benutzereinführung zu schreiben, wäre mit dieser Änderung viel einfacher. Man könnte dann auf die vielen Optionen verzichten, was man auch anders hätte machen können, und einfach erklären: Jede Referenz steht entweder

• im <references>-Element, dann mit der Möglichkeit der Mehrfachverwendung mit möglichen Zusätzen und zusätzlich mit der Eigenschaft, dass eine fehlerhafte Referenz dort verbessert wird, wo man sie sieht und nicht dort, wo man nur einen Fußnotenverweis auf sie sieht, oder aber
• an Ort und Stelle der Verwendung, dann ohne diese Möglichkeiten und bei Fehlern mit Rätselraten, wo sie im Quelltext vorkommt.

Und eine kurze Erläuterung der historischen Syntaxformen, die man bitte nicht mehr verwenden soll. Kann ja sein, dass man sie antrifft. Aber es sollte nicht Ziel der Beschreibung sein, dass es jeder verschieden macht. --Lantani (Diskussion) 11:52, 4. Nov. 2024 (CET)

Hallo Lantani,

es mag vielleicht an meiner derzeitigen Verfassung liegen, aber ich habe mich durchaus schwer damit getan, mich Durch Deinen Beitrag zu arbeiten. Ich fasse das mal so zusammen: Literaturangaben sollten künftig nur noch direkt in den Verzeichnissen (Literaturverzeichnis / Einzelnachweise) codiert werden. Im Fließtext sollten dann nur noch seiteninterne Referenzen auf die Einträge codiert werden. Durch weniger Möglichkeiten werden Anleitungen kürzer und Fehler unwahrscheinlicher. Verstehe ich Dich richtig? Bezieht sich dieser Vorschlag nur auf die Literaturangaben, in denen mit Subreferenzen gearbeitet werden soll, oder auf alle Literaturangaben?

Im Detail schlägst Du dann noch vor, das "extends"-Attribut auf "text" umzubenennen, richtig? Welchen Vorteil versprichst Du Dir von der Namensänderung?

Gruß! --Vollbracht (Diskussion) 19:02, 4. Nov. 2024 (CET)

Also, ich sehe hier folgende Relevanzen:

1. Zusammenführung von redundanten Lit/EN
2. Einen möglichst missverständlich/intuitiven Atrributsnamen
3. Wie könnte das im Visual Editor implementiert werden

Ich selbst arbeite bisher stets auf Quelltextebene, kein Visual Editor.

Nach meinem Verständnis ist eine Literaturangabe für das gleiche Werk ein Oberbegriff für daraus EN(s).

Zu 1.) habe ich keine konkreten Vorschläge

Zu 2.) präferiere ich für fortgeschrittene WPianer:innen im Quelltext extends

Zu 3.) sollte es egal sein, wie das, on Top of obiges, realisiert werden könnte -- Heribert3 (Diskussion/Talk) 07:06, 5. Nov. 2024 (CET) (unvollständig signierter Beitrag von Heribert3 (Diskussion | Beiträge) )

Die Begründung für die vorgeschlagene Syntax habe ich nachgeliefert und gleich hineinkorrigiert, damit man sie findet, bevor man sie vermisst. --Lantani (Diskussion) 15:14, 5. Nov. 2024 (CET)