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

message: === Das ist meine grundsätzliche Meinung zur vorgeschlagenen Lösung ===
* Das Einzelnachweissystem ist derzeit schon so unfassbar kompliziert geworden, ohne ein zweijähriges Studium ist das kaum zu bewältigen. Ich glaube nicht, daß die Einführung noch weiterer Möglichkeiten zielführend wären. Das macht es für Altautoren wie für Neuautoren immer komplizierter und unterstützt dann ohnehin nur den Einzelnachweiswahn. Schon jetzt glauben viel zu Viele, daß "Belege" = "Einzelnachweise" sind. Noch mehr Möglichkeiten würde wohl nur eine Zementierung dieses Unsinns sein. Marcus Cyron Reden 18:14, 12. Sep. 2016 (CEST)
replies: text: @PaterMcFly: Der Artikel Physik des Segelns ist leider ein böses Negativbeispiel. Gott bewahre, „Püschl“ (oder seine Cousine) wagt es, ein zweites Buch zu schreiben. Oder aber, irgend ein Depp kommt her und löscht das Buch aus der Literaturliste. Den Spaß, den man dann hat, kannst du in der Versionsgeschichte von Merseburger Zaubersprüche bestaunen. PS: Im ersten Augenblick habe ich nach einem Autor namens „Seemannschaft“ gesucht. Grrr.  hugarheimur 18:23, 15. Sep. 2016 (CEST)
replies: text:   Ok, das Risiko für so ein Chaos wäre wohl etwas reduziert, weil der Parser Fehler werfen würde, aber wenn der Bearbeiter da nicht drauf achtet, kann es genauso schief gehen. --PaterMcFly Diskussion Beiträge 21:30, 15. Sep. 2016 (CEST)

text: Hallo Avron, mit der Frage, ob gleiche Seitenzahlen automatisch zusammen gefügt werden sollten, haben wir uns auch schon beschäftigt. Letztendlich haben wir aber beschlossen, das als eine gesonderte Funktionalität anzusehen - wenn eine "normale" Quelle doppelt referenziert wird, wird sie ja bisher auch nicht automatisch nur einmal angezeigt. Deswegen habe ich beim Beispiel zunächst die bisher gängige Methode verwendet. Trotzdem wäre es natürlich möglich, zusätzlich zur hier besprochenen refines-Funktionalität auch über die Umsetzung einer "Zusammenfassungsfunktionalität" nachzudenken. Viele Grüße, Lea Voget (WMDE) (Diskussion) 11:47, 13. Sep. 2016 (CEST)
replies: text: Außerdem muss ich dann als Leser, ebenso wie als Autor, nicht mehr diese unsäglichen a.a.O. oder l.c.-Nachweise lesen, die die Schnitzeljagd erst so richtig lustig machen.--Meloe (Diskussion) 13:31, 13. Sep. 2016 (CEST)

text: zur Übersicht im Bearbeitungsmodus wurde ein neuer einfacher Zeilenumbruch nach jedem  </ref>  schon mal helfen ;-). lG --Hannes 24 (Diskussion) 20:11, 21. Sep. 2016 (CEST)
replies: text: Schnark, Hintergrund der Frage ist nicht die "technische Schwierigkeit", sondern die noch ausstehende notwendige Koordinierungsarbeit mit dem Visual Editor Team. Solange noch nicht klar ist, ob der Vorschlag hier überhaupt in Frage kommt, macht es keinen Sinn, sich dazu bereits mit dem VE Team abzustimmen. --Birgit Müller (WMDE) (Diskussion) 13:58, 15. Sep. 2016 (CEST)
replies: text: Die hier vorgeschlagene Änderung muss (auch) in Parsoid umgesetzt werden, und durch die Verzahnung von Parsoid und VE wird euch kaum etwas anderes übrig bleiben, als die Änderungen auch mit dem VE-Team abzustimmen, unabhängig davon, ob ihr die Funktionen zum Bearbeiten direkt mitimplementiert oder nicht. --Schnark 09:05, 16. Sep. 2016 (CEST)
replies: text: Ist klar :). Trotzdem spielt eine Implementierung der Funktion in den VE nochmal in einer anderen Absprache-Liga. VG, --Birgit Müller (WMDE) (Diskussion) 10:34, 16. Sep. 2016 (CEST)

text: Naja, bei der Gruppierung wird ja der Name der Gruppe im hochgestellten Text angegeben. Beim Vorschlag wird automatisch durchnummeriert (klar, könnte man mit Gruppen 1, 2, 3 usw. auch erreichen; hier wird aber wohl automatisch nummeriert, oder?). Grüße, —DerHexer (Disk., Bew.) 20:18, 12. Sep. 2016 (CEST)
replies: text: Zudem wird durch refines eine eindeutige Beziehung hergestellt, während group für diverse Fälle Anwendung findet.--Cirdan ± 20:29, 12. Sep. 2016 (CEST)
replies: text: Ich sehe es ähnlich wie Cirdan. Optisch kann mit group was ähnliches erreichen, aber mit dem Vorschlag ist es von der Struktur her sauberer und die Software weiss welche Einzelnachweise zu welchem Werk gehören. Damit könnte man sich noch einiges überlegen... Bei group klatscht man die Gruppe einfach unter eine Überschrift. Groups sehe ich eher für die Unterscheidung Einzelnachweise/Anmerkungen/... .--Avron (Diskussion) 20:36, 12. Sep. 2016 (CEST)
replies: text: Zusätzlich zu allem bisher Gesagten würde ich noch ergänzen, dass Groups neu mit der Aufzählung beginnen, während refines es Autoren ermöglicht, Referenzen innerhalb von Einzelnachweisen oder anderen Gruppen zu spezifizieren. Tatsächlich würde der refines-Parameter wahrscheinlich so funktionieren, dass er sich immer nur auf eine bestimmte Gruppe bezieht. Wenn also eine Quelle innerhalb eine Gruppe spezifiziert werden soll, die nicht die Standard-Einzelnachweise ist, müsste nicht nur der Quellenname bei 'refines' angegeben werden, sondern gleichzeitig auch die Gruppe mithilfe des group-Parameters explizit spezifiziert werden. --Lea Voget (WMDE) (Diskussion) 11:54, 13. Sep. 2016 (CEST)

text: Und wofür stehen dort "(G)", "(T)" und "(B)"? Benatrevqre …?! 15:51, 14. Sep. 2016 (CEST)
replies: text: Ich kann die Verschlechterung nicht nachvollziehen. Die Buchstaben sind ohnehin kryptisch; wenn ich wissen will was sich hinter einem Beleg verbirgt, dann fahre ich mit der Maus darüber und bekomme dazu den Text angezeigt. --Avron (Diskussion) 17:31, 14. Sep. 2016 (CEST)

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

message: * Das Einzelnachweissystem ist derzeit schon so unfassbar kompliziert geworden, ohne ein zweijähriges Studium ist das kaum zu bewältigen. Ich glaube nicht, daß die Einführung noch weiterer Möglichkeiten zielführend wären. Das macht es für Altautoren wie für Neuautoren immer komplizierter und unterstützt dann ohnehin nur den Einzelnachweiswahn. Schon jetzt glauben viel zu Viele, daß "Belege" = "Einzelnachweise" sind. Noch mehr Möglichkeiten würde wohl nur eine Zementierung dieses Unsinns sein. Marcus Cyron Reden 18:14, 12. Sep. 2016 (CEST)
replies: text: @PaterMcFly: Der Artikel Physik des Segelns ist leider ein böses Negativbeispiel. Gott bewahre, „Püschl“ (oder seine Cousine) wagt es, ein zweites Buch zu schreiben. Oder aber, irgend ein Depp kommt her und löscht das Buch aus der Literaturliste. Den Spaß, den man dann hat, kannst du in der Versionsgeschichte von Merseburger Zaubersprüche bestaunen. PS: Im ersten Augenblick habe ich nach einem Autor namens „Seemannschaft“ gesucht. Grrr.  hugarheimur 18:23, 15. Sep. 2016 (CEST)
replies: text:   Ok, das Risiko für so ein Chaos wäre wohl etwas reduziert, weil der Parser Fehler werfen würde, aber wenn der Bearbeiter da nicht drauf achtet, kann es genauso schief gehen. --PaterMcFly Diskussion Beiträge 21:30, 15. Sep. 2016 (CEST)

text: Hallo Avron, mit der Frage, ob gleiche Seitenzahlen automatisch zusammen gefügt werden sollten, haben wir uns auch schon beschäftigt. Letztendlich haben wir aber beschlossen, das als eine gesonderte Funktionalität anzusehen - wenn eine "normale" Quelle doppelt referenziert wird, wird sie ja bisher auch nicht automatisch nur einmal angezeigt. Deswegen habe ich beim Beispiel zunächst die bisher gängige Methode verwendet. Trotzdem wäre es natürlich möglich, zusätzlich zur hier besprochenen refines-Funktionalität auch über die Umsetzung einer "Zusammenfassungsfunktionalität" nachzudenken. Viele Grüße, Lea Voget (WMDE) (Diskussion) 11:47, 13. Sep. 2016 (CEST)
replies: text: Außerdem muss ich dann als Leser, ebenso wie als Autor, nicht mehr diese unsäglichen a.a.O. oder l.c.-Nachweise lesen, die die Schnitzeljagd erst so richtig lustig machen.--Meloe (Diskussion) 13:31, 13. Sep. 2016 (CEST)

text: zur Übersicht im Bearbeitungsmodus wurde ein neuer einfacher Zeilenumbruch nach jedem  </ref>  schon mal helfen ;-). lG --Hannes 24 (Diskussion) 20:11, 21. Sep. 2016 (CEST)
thread_title:  Das ist meine grundsätzliche Meinung zur vorgeschlagenen Lösung 

message: *Wichtig ist, dass das Basis ref in die vollständige Referenz zur Quelle liegt gut erkennbar ist, und bei entfernen eine entsprechend deutliche Fehlermeldung hinterlässt. — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
thread_title:  Das müsste bei der Umsetzung beachtet werden 

message: * ja, viele der komplizierteren Strukturen wird man wohl auf lange Zeit besser im Quellcode editieren.  Frohes Schaffen — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
replies: text: Schnark, Hintergrund der Frage ist nicht die "technische Schwierigkeit", sondern die noch ausstehende notwendige Koordinierungsarbeit mit dem Visual Editor Team. Solange noch nicht klar ist, ob der Vorschlag hier überhaupt in Frage kommt, macht es keinen Sinn, sich dazu bereits mit dem VE Team abzustimmen. --Birgit Müller (WMDE) (Diskussion) 13:58, 15. Sep. 2016 (CEST)
replies: text: Die hier vorgeschlagene Änderung muss (auch) in Parsoid umgesetzt werden, und durch die Verzahnung von Parsoid und VE wird euch kaum etwas anderes übrig bleiben, als die Änderungen auch mit dem VE-Team abzustimmen, unabhängig davon, ob ihr die Funktionen zum Bearbeiten direkt mitimplementiert oder nicht. --Schnark 09:05, 16. Sep. 2016 (CEST)
replies: text: Ist klar :). Trotzdem spielt eine Implementierung der Funktion in den VE nochmal in einer anderen Absprache-Liga. VG, --Birgit Müller (WMDE) (Diskussion) 10:34, 16. Sep. 2016 (CEST)
thread_title:  Sollte dieser Lösungsvorschlag auch umgesetzt werden, wenn noch nicht klar ist, ob dies auch in den VisualEditor integriert werden würde? 

message: * I18N: Schön wäre es wenn am die Verfeinerung pro Wiki im MediWiki-Namensraum festlegen könnte. Frohes Schaffen — Boshomi ⌨   19:14, 12. Sep. 2016 (CEST)
thread_title:  Weitere Anmerkungen 

message: Wenn das richtig verstehe ist das angestrebte doch bereits möglich mithilfe von "group". Insofern wüsste ich gerne was die Intention dieser Erneuerung ist. Lediglich eine Vereinfachung der Syntax? Oder welche Beziehungen und Unterschiede bestehen zur "group"-Variante?--Kmhkmh (Diskussion) 19:54, 12. Sep. 2016 (CEST)
replies: text: Naja, bei der Gruppierung wird ja der Name der Gruppe im hochgestellten Text angegeben. Beim Vorschlag wird automatisch durchnummeriert (klar, könnte man mit Gruppen 1, 2, 3 usw. auch erreichen; hier wird aber wohl automatisch nummeriert, oder?). Grüße, —DerHexer (Disk., Bew.) 20:18, 12. Sep. 2016 (CEST)
replies: text: Zudem wird durch refines eine eindeutige Beziehung hergestellt, während group für diverse Fälle Anwendung findet.--Cirdan ± 20:29, 12. Sep. 2016 (CEST)
replies: text: Ich sehe es ähnlich wie Cirdan. Optisch kann mit group was ähnliches erreichen, aber mit dem Vorschlag ist es von der Struktur her sauberer und die Software weiss welche Einzelnachweise zu welchem Werk gehören. Damit könnte man sich noch einiges überlegen... Bei group klatscht man die Gruppe einfach unter eine Überschrift. Groups sehe ich eher für die Unterscheidung Einzelnachweise/Anmerkungen/... .--Avron (Diskussion) 20:36, 12. Sep. 2016 (CEST)
replies: text: Zusätzlich zu allem bisher Gesagten würde ich noch ergänzen, dass Groups neu mit der Aufzählung beginnen, während refines es Autoren ermöglicht, Referenzen innerhalb von Einzelnachweisen oder anderen Gruppen zu spezifizieren. Tatsächlich würde der refines-Parameter wahrscheinlich so funktionieren, dass er sich immer nur auf eine bestimmte Gruppe bezieht. Wenn also eine Quelle innerhalb eine Gruppe spezifiziert werden soll, die nicht die Standard-Einzelnachweise ist, müsste nicht nur der Quellenname bei 'refines' angegeben werden, sondern gleichzeitig auch die Gruppe mithilfe des group-Parameters explizit spezifiziert werden. --Lea Voget (WMDE) (Diskussion) 11:54, 13. Sep. 2016 (CEST)

text: Und wofür stehen dort "(G)", "(T)" und "(B)"? Benatrevqre …?! 15:51, 14. Sep. 2016 (CEST)
replies: text: Ich kann die Verschlechterung nicht nachvollziehen. Die Buchstaben sind ohnehin kryptisch; wenn ich wissen will was sich hinter einem Beleg verbirgt, dann fahre ich mit der Maus darüber und bekomme dazu den Text angezeigt. --Avron (Diskussion) 17:31, 14. Sep. 2016 (CEST)

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

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

message: Nach dem heutigen Totalumbau der Vorderseite (Danke für das Update!) sind die älteren Diskussionsbeiträge auf dieser Seite teilweise nicht mehr zutreffend oder inzwischen ohne Bezug. Evtl. sollte das klar gekennzeichnet oder auch per Archivierung aufgeräumt werden.--Mabschaaf 23:17, 1. Okt. 2018 (CEST)
replies: text: Danke für den Hinweis. Ich schau mir das gerne an, schaffe es allerdings vermutlich erst kommende Woche nach der WikiCon. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 17:03, 2. Okt. 2018 (CEST)
replies: text:   Hier bin ich nochmal. Ich hab es noch nicht geschafft und bin jetzt bis Mitte November im Urlaub. Das Aufräumen der Diskussionsseite steht aber auf meiner Aufgabenliste, wird also nicht vergessen. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 15:21, 23. Okt. 2018 (CEST)

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

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

message: Was steht dies jetzt? Wird es noch umgesetzt? Wenn ja, wann (auf dieser Wikipedia)? 
Ich fand dazu https://phabricator.wikimedia.org/tag/cite-extends/ und https://phabricator.wikimedia.org/project/profile/4256/ --Enhancing999 (Diskussion) 12:09, 20. Dez. 2023 (CET)
replies: text: Hallo Enhancing999, ich bitte um Verzeihung für die späte Antwort. Unser Team nimmt die Arbeit an diesem Projekt gerade wieder auf und wir rechnen damit, im Laufe dieses Jahres fertig zu werden. -- Viele Grüße, Johanna Strodt (WMDE)  Diskussion  Projekt Technische Wünsche 17:40, 11. Jan. 2024 (CET)
thread_title:  2023 Dezember 20: Stand der Entwicklung der neuen Funktion 

message: :Danke für die Updates. Ref mit "extends" gibt z.Z.: S. 131  
: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)
thread_title:  Test der bisherigen Umsetzung im [[H:Wikisyntax|Wikitext]] 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Wiederverwendung eines Einzelnachweises aus der Literatur 

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

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

message: 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:
#Einzelnachweise können stringent wiederverwendet werden.
#Best Practices in der Erstellung wissenschaftlicher Literatur gelten weiterhin in der Wikipedia.
#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.
#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)
thread_title:  Integration von Literaturverzeichnis und Einzelnachweisen