Kategorie Diskussion:Textbausteine

Textbausteine / Makros für Quellenangaben?

Das Makro Vorlage:PRNA ist sehr nützlich, um Links auf Neo-spezifische Artikel zu setzen. Statt [[Wega (PR Neo)|Wega]] kann man {{PRNA|Wega}} schreiben. Das ist weniger zu tippen, macht den Quelltext lesbarer und ist weniger fehleranfällig.

Mir scheint, dasselbe gilt für Quellenangaben. Bislang muss man Dinge schreiben wie:

[[Quelle:PRN184|PR Neo 184, S. 105]]

Oder, für die Hauptserie:

[[Quelle:PR2398|PR 2398, S. 56]]

Beides ist wenig lesbar und sehr fehleranfällig (ich habe das bei meinen ersten Edits gleich mal falsch gemacht).

Schöner wäre, etwa für die Hauptserie:

 {{Quelle:PR|2398|S. 56}}

Und für Neo:

 {{Quelle:Neo|184|S. 105}}

oder vielleicht:

 {{Quelle:PRN|184|S. 105}}

Natürlich sollten die Makros auch ohne dritten Parameter funktionieren:

 {{Quelle:PR|2398}}
 {{Quelle:Neo|184}}

Natürlich gibt es dann noch diverse Sonderfälle (TBs, Silber/Blaubände, usw.), allerdings:

1. Zeigt das für mich nur, dass solche Makros nützlich wären (weil diese Sonderfälle sonst bei dem setzen jedes Links zu beachten/recherchieren sind).
2. Könnte man mit den "üblichen" Fällen anfangen und dann schrittweise erweitern.

Ich bin gerne bereit, mich weit genug in die Mediawiki-Makro-Sprache einzulesen, um das umzusetzen, hätte aber gerne erstmal Feedback, ob das gewünscht ist ... und ob die Vorschläge oben sinnvoll erscheinen, oder das anders aussehen sollten.

--Lars.juergenson (Diskussion) 13:51, 20. Okt. 2018 (CEST)

Die PRNA-Vorlage ist eingeführt worden, weil anfangs häufig das (PR Neo) vergessen würde, und deshalb macht sie auch heute noch Sinn. Bei Quellenangaben hingegen sehe ich keinen Handlungsbedarf. --JoKaene 17:52, 20. Okt. 2018 (CEST)

Es sind keine Makros, es sind Vorlagen. Das ist ein eminenter Unterschied. Vorlagen werden durch Datenbankzugriffe aufgelöst. Natürlich sind die DB-Zugriffe durch verschiedene Caches stark optimiert, trotzdem möchte ich mal kurz die Größenordnung aufzeigen:

Eine der heute am häufigsten verwendeten Vorlagen ist Imagelink Allgemein, die rund 10.000 mal vorkommt. Davon wie häufig in einem Artikel? Ein-, drei-, fünfmal, vielleicht ausnahmsweise zehnmal. In ein paar ganz vereinzelten Seiten (Galerien) 100 mal.

Quellenangaben haben wir in praktisch allen vollwertigen Artikeln. Sicher viele Artikel, die auch nur eine, zwei oder drei Quellen enthalten. Perry Rhodan hat aktuell 622 Quellenangaben, Milchstraße 3716. Denkt auch an die Listen! Wir reden hier also von einer Vorlage, die insgesamt mehrere 100.000-mal, vll. 1 Million mal und öfter eingebunden wird. Und dabei sind unsere Quellenangaben noch keineswegs komplett.

Ich rate daher davon ab. Als Eingabehilfen gibt es unterhalb des Editorfensters vorformatierte Quellenangaben, das sind Makros. --Klenzy (Diskussion) 20:11, 20. Okt. 2018 (CEST)

Je geschmeidiger der Wikicode im Editor zu lesen ist, umso „barrierefreier“ wird es für die Leute, die zwar guten Willens sind, aber für die der Wikicode in seiner ganzen Pracht echtes Neuland darstellt bzw. diejenigen, die einfach nur einen Artikel erstellen wollen, aber dabei nicht mehr als die grundlegenden Formatierungen anwenden wollen, da sie sich mehr auf die Artikelarbeit konzentrieren wollen. Insofern ist der Vorschlag von Lars.juergenson sehr sinnvoll. Außerdem technisch durch eine Handvoll Vorlagen problemlos umgehend zu realisieren. Da ich davon ausgehe, dass hier in der PP die Artikelseiten gecacht werden, ist das Thema Datenbanbzugriffe doch eigentlich zu relativieren, da zwar beim Editieren eines Artikels Datenbankzugriffe geschehen (schon allein, um ihn dort zu speichern). Aber bei jedem nachfolgenden Lesezugriff wird die Seite nicht neu gerendert. Erst wieder beim Speichern nach einem Edit - korrigiert mich da, wenn ich falsch liegen sollte. Wenn es denn „nur“ darum geht, die sehr vielen vorhandenen Quellangaben dementsprechend anzupassen und dies ob der Menge zur Sisyphusarbeit geraten würde: Da mag die hier in der PP installierte Erweiterung Replace Text helfen.

Ich bin ein Freund solcher Vorlagen. Ja, es gibt die Eingabehilfen unterhalb des Editors. Aber  die werden  auch  dadurch  im  Quellcode  nicht  lesbarer. Falls gewünscht, ich wäre durchaus bereit, solche „Quellen“-Vorlagen einzurichten. Müsste dann danach nur noch einer die Eingabehilfen unterhalb des Editors anpassen (sofern das nicht jeder darf)… --WGK.derdicke (Diskussion) 00:07, 21. Okt. 2018 (CEST)

»Aber  die werden  auch  dadurch  im  Quellcode  nicht  lesbarer.«

Bitte behandle uns nicht als Idioten. --Klenzy (Diskussion) 11:49, 21. Okt. 2018 (CEST)

Ich muss zugeben, dass ich nicht daran gedacht hatte, dass Vorlagen/Textbausteine beim Rendern aufgelöst werden müssen (modulo caching). Ob das tatsächlich ein Problem darstellen würde, kann ich nicht sagen, neige aber dazu, Klenzy als Sysadmin glauben, wenn er das sagt.

Das Problem wäre sicher nicht, die "alten" Quellenangaben zu konvertieren. Das müsste ja gar nicht sofort gemacht werden (die neuen Quellenangaben wären für den Leser ja identisch mit den alten). Aber wenn zu erwarten steht, dass bei konsequenter Anwendung der neuen Vorlage irgendwann Performance-Probleme anstehen würden, ist das ein wichtiges Argument, dass gegen die Komplexität des Quelltextes aufzuwiegen ist. --Lars.juergenson (Diskussion) 12:32, 21. Okt. 2018 (CEST)

Ich habe die Weisheit auch nicht mit dem Löffel gefr... gegessen, und ich bin auch nicht grundsätzlich abgeneigt. Die Idee, Quellenangaben in Vorlagen zu verpacken, ist mir tatsächlich auch schon vor einiger Zeit durch den Kopf gegangen. Es geht dabei, da stimme ich WGK völlig zu, um einfachere Quelltextpflege (Quelltext jetzt hier im Sinne von Artikeltext). Wie genau die Belastung für die Datenbank wäre, kann ich nicht voraussehen. Ich weiß aber, dass unser derzeitiger Flaschenhals in der Perrypedia nur und ausschließlich die Datenbank ist (vgl. dazu auch Perrypedia:Beobachtete_Fehler#Perrypedia_langsam). Festspeicher: reichlich Platz (42% belegt, davon aber mehr als die Hälfte Software und PP-Backups, Papierkorb, temporäre Dateien und so Zeug); RAM und CPU: durchschnittliche Auslastung weniger als 50%; Apache Webserver und Netzwerkbandbreite: einige Luft nach oben.

Das Argument mit dem Cache ist teilweise richtig. Wobei ich hinzufügen möchte, dass die Perrypedia lange Jahre ohne Seitencache gefahren wurde; den Seitencache hab ich, mit Verlaub, selbst erst vor einiger Zeit eingeführt (1 oder 2 Jahre? Weiß nicht mehr genau). Der Seitencache hat aber nur Auswirkungen für anonyme (nicht angemeldete) Benutzer. Nur (!) die profitieren davon. Bei jedem mit eigenem Perrypedia-Konto angemeldeten Benutzer wird jeder Artikel bei jedem Seitenaufruf komplett neu aufgebaut. Das muss so sein, sonst würde der Benutzer seine Edits aufgrund einer evtl. veralteten Anzeige machen. Erneute Schwerstarbeit für die Datenbank ist dann das Speichern, siehe obigen Link: BLOBs zusammenbasteln, History, Update der Linktabelle. Und als letzter Schritt (im obigen Link noch gar nicht erwähnt) muss dann der Cache natürlich auch aktualisiert werden, d.h. die Seite muss noch einmal komplett neu aufgebaut werden.

Somit wird für die PP-Mitarbeiter alles mit Sicherheit nicht schneller, sondern langsamer.

Es käme auf einen Test an, das einmal zu versuchen. Da bin ich grundsätzlich nicht abgeneigt. Aktuell ist aber nicht der richtige Zeitpunkt. Ein großer Betriebssystemwechsel steht bevor (vgl. Perrypedia:Wartung#Betriebssystemwechsel), als nächstes steht dann ca. zum Jahreswechsel der Upgrade der Mediawiki-Software bevor. Es ist sinnlos, jetzt irgendwelche Messungen anzustellen, wenn in Kürze die gesamte Software ausgetauscht wird.

Hintergedanke bei den ganzen Upgrades ist auch, Anfang nächsten Jahres einen Probelauf mit dem Visual Editor zu machen. Meine versteckte Hoffnung ist, dass sich dadurch die gesamte  -Problematik, die ja nicht nur die Quellenangaben betrifft, erheblich entschärft. Danach können wir gern nochmal über Quellenvorlagen reden. Okay? --Klenzy (Diskussion) 13:06, 21. Okt. 2018 (CEST)

Klingt für mich sinnvoll. Du magst die Weisheit nicht für dich gepachtet haben, aber als Sysadmin weißt du eben, wann ein Test sinnvoll ist, und wo die Performance-Flaschenhälse liegen. Wenn sich die Problematik nicht durch die Software-Updates soweit entschärft, dass eine weitere Lösung unnötig ist, könnte man auch daran denken, zu schauen, ob sich die normale Link-Verarbeitung nicht durch eine Mediawiki "extension" erweitern lässt, um das Problem zu lindern. Es würde ja schon einiges lesbarer machen, wenn Links im "Quelle"-namespace automatisch eine CSS-Klasse erhalten, die die CSS-Eigenschaft "whitespace: pre;" hat (was früher der <nobr>-Tag gemacht hat). Dann hätte sich (für diese Links) die  -Problematik gelöst, und der Hauptserien-Link von oben schon nur noch:

[[Quelle:PR2398|PR 2398, S. 56]]

Immer noch redundant (und deshalb fehleranfällig), aber wesentlich lesbarer.

Ein Ansatz, der bei der Standard-Link-Verarbeitung ansetzt, dürfte wesentlich performanter sein als Vorlagen/Templates, bei denen ja (offenbar) bei jeder Verwendung die Vorlagen-Seite aus der Datenbank geholt und gerendert werden muss.

Aber, wie du sagst, momentan scheint es am besten, die Angelegenheit bis in den nächsten Frühling zu vertagen.

@Klenzy: Es war nicht meine Intention, irgend jemand mit dem  -Satz vorzuführen. Ich wollte nur damit aufzeigen, dass die Lesbarkeit von Quelltext durch solche Formatierungen stark leiden kann. Insbesondere für Mitstreiter, die in Sachen (komplexe) Vorlagen nicht im Thema stehen. Als Jemand mit ein klein wenig mehr Expertise mag man da dann vielleicht ein wenig entspannter drauf blicken, kann das problemlos entziffern und sieht keine Notwendigkeit für Handlungsbedarf während andere schon längst das Handtuch geworfen haben. Ich ertappe mich bei solchen Dingen auch oft genug, dass ich für mich verständliche Dinge dann als selbstverständlich für alle anderen betrachte und werde oft eines besseren belehrt. Insofern versuche ich oftmals, die Dinge auch durch andere Brillen zu sehen. Sicherlich kommen dadurch auch schon einmal Lösungen zustande, die rein technisch betrachtet nicht ganz das Optimum darstellen, die das dann aber durch beispielsweise Lesbarkeit/Wartbarkeit (bei Programmcode) auf anderem Felde wett machen.--WGK.derdicke (Diskussion) 13:35, 22. Okt. 2018 (CEST)

@WGK: Ja, verstanden.

@Lars: CSS ist gut ...! Erinnere mich bitte in einem halben Jahr nochmal. --Klenzy (Diskussion) 15:04, 22. Okt. 2018 (CEST)