Perrypedia:Verbesserungsvorschläge: Unterschied zwischen den Versionen

Aus Perrypedia
Wechseln zu: Navigation, Suche
(W. K. Giesa Bild)
Zeile 20: Zeile 20:
 
{{TOC rechts}}
 
{{TOC rechts}}
 
<!--- NEUE FRAGE HIER DRUNTER EINFÜGEN, BITpTE MIT EINEM NEUEN KAPITEL (== Neues Fragethema == ) ABSETZEN: --->
 
<!--- NEUE FRAGE HIER DRUNTER EINFÜGEN, BITpTE MIT EINEM NEUEN KAPITEL (== Neues Fragethema == ) ABSETZEN: --->
 +
 +
== Portal-Arbeit sparen? ==
 +
 +
Ich habe mich gefragt, ob man die Portalseiten nicht (teilweise) automatisch generieren kann - viele der Listen dort könnte man erstellen, wenn man sagen könnte "Mach mir eine Liste von Artikeln die sowohl ZYKLUSKATEGORIE als auch KATEGORIE X haben".
 +
 +
Das würde mit SemanticMediaWiki funktionieren (damit könnte man auch noch Properties für Vor- und Nachnamen, etc. anlegen, und dann sogar die Personenliste generieren). Damit könnte man evtl. sogar die meisten Listenseiten automatisch erstellen, wenn man wollte. (1( Allerdings habe ich gesehen, dass es mit der Extension oft Probleme gegeben hat, deshalb ist das wohl keine Option.
 +
 +
Aber wie wäre es mit DynamicPageList [https://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia)]? Damit könnte man auch die meisten der Portal-Listen auf Basis der Kategorien generieren (aber nicht die Personenliste, wegen der Umstellung der Namen).
 +
 +
(Teile der) Portale automatisch zu generieren hätte nicht nur den Vorteil, dass weniger Arbeit zu machen ist, sondern würde (vermutlich?) auch zu vollständigeren Portalseiten führen.
 +
 +
Wenn eine dieser Extensions installiert würde, wäre ich gerne bereit, mit da reinzufuchsen und ein paar Textbausteine, die die Interna der Extension verstecken, und/oder eine Formatvorlage zu erstellen.
 +
 +
--- (1) Zugegebenermaßen würde das auf absehbare Zeit nur für neue Listen funktionieren, weil für bestehende Einträge Tags in die Artikel eingefügt werden müssten. Der Vorteil ist also eher theoretisch.
 +
 +
--[[Benutzer:Lars.juergenson|Lars Jürgenson]] ([[Benutzer Diskussion:Lars.juergenson|Diskussion]]) 10:58, 16. Aug. 2019 (CEST)
  
 
== W. K. Giesa Bild ==
 
== W. K. Giesa Bild ==

Version vom 16. August 2019, 09:58 Uhr

Google translator: Translate from German to English.
Google translator: Přeložte z němčiny do češtiny.
Google translator: Vertalen van Duits naar Nederlands.
Google translator: ドイツ語から日本語への翻訳
Google translator: Traduire de l'allemand vers le français.
Google translator: Traduzir do alemão para o português.

Um diese Seite übersichtlich zu gestalten, bitte

  • neue Beiträge/ Fragen oben und nach dieser Textbox einfügen.
  • jedem neuen Beitrag eine Überschrift geben (z.B: == Diskussionsthema ==).
  • mit zwei Bindestrichen und vier Tilden (--~~~~) unterschreiben.


Portal-Arbeit sparen?

Ich habe mich gefragt, ob man die Portalseiten nicht (teilweise) automatisch generieren kann - viele der Listen dort könnte man erstellen, wenn man sagen könnte "Mach mir eine Liste von Artikeln die sowohl ZYKLUSKATEGORIE als auch KATEGORIE X haben".

Das würde mit SemanticMediaWiki funktionieren (damit könnte man auch noch Properties für Vor- und Nachnamen, etc. anlegen, und dann sogar die Personenliste generieren). Damit könnte man evtl. sogar die meisten Listenseiten automatisch erstellen, wenn man wollte. (1( Allerdings habe ich gesehen, dass es mit der Extension oft Probleme gegeben hat, deshalb ist das wohl keine Option.

Aber wie wäre es mit DynamicPageList [1]? Damit könnte man auch die meisten der Portal-Listen auf Basis der Kategorien generieren (aber nicht die Personenliste, wegen der Umstellung der Namen).

(Teile der) Portale automatisch zu generieren hätte nicht nur den Vorteil, dass weniger Arbeit zu machen ist, sondern würde (vermutlich?) auch zu vollständigeren Portalseiten führen.

Wenn eine dieser Extensions installiert würde, wäre ich gerne bereit, mit da reinzufuchsen und ein paar Textbausteine, die die Interna der Extension verstecken, und/oder eine Formatvorlage zu erstellen.

--- (1) Zugegebenermaßen würde das auf absehbare Zeit nur für neue Listen funktionieren, weil für bestehende Einträge Tags in die Artikel eingefügt werden müssten. Der Vorteil ist also eher theoretisch.

--Lars Jürgenson (Diskussion) 10:58, 16. Aug. 2019 (CEST)

W. K. Giesa Bild

Können / Dürfen wir das Bild von W. K. Giesa hier auf der Perrypedia hochladen? Die Frage bezieht sich eher darauf, wenn der Blog jemals gelöscht wird, dann ist das Bild nicht mehr verfügbar. --Soulprayer (Diskussion) 14:05, 7. Aug. 2019 (CEST)

Dann wäre es kein Bildzitat mehr. Vielleicht wird der Blog ja aus genau dem Grund gelöscht, dass man nicht mehr möchte, dass das Bild online zu sehen ist. Ohne Genehmigung dürfen wir das Bild IMO nicht hochladen. --Johannes Kreis (Diskussion) 14:09, 7. Aug. 2019 (CEST)

Editor-Links Quellenangaben

Wäre es möglich, den Neo-Link unter "Quellenangaben innerhalb von Artikeln" in eine Vorlage für eine genauere Quellenangabe ändern? Also

<small>([[Quelle:PRNxx|PR&nbsp;Neo&nbsp;xx,&nbsp;Kap.&nbsp;x]])</small>

oder

<small>([[Quelle:PRNxx|PR&nbsp;Neo&nbsp;xx,&nbsp;S.&nbsp;x]])</small>

statt

<small>([[Quelle:PRNxx|PR&nbsp;Neo&nbsp;xx]])</small>

? (Als ebook-Leser wäre mir die "Kap"-Version am liebsten, aber ich könnte auch gut mit der "S."-Version Leben.)

Hintergrund: Grade bei Neo (aufgrund der Länge der einzelnen Romane) ist es eigentlich fast IMMER sinnvoll, eine genauere Angabe als nur den Roman zu machen. Das heißt ich muss bei jedem neuen Artikel mindestens einmal &nbsp;Kap.&nbsp;x tippen (oder anderswo herkopieren). Und es ist weniger Aufwand, das in den wenigen Fällen, wo keine genauere Angabe sinnvoll/machbar ist, rauszulöschen, als es fast immer hinzuzufügen.

Außerdem würde die längere Version als Standard-Baustein Autoren dazu ermutigen, öfter genauere Quellenangaben zu machen, was der Überprüfbarkeit gut tun würde. (Aus dem Grund würde die selbe Änderung evtl. auch für die anderen Serien sinnvoll sein?) --Lars Jürgenson (Diskussion) 13:26, 29. Jul. 2019 (CEST)

Ich befürworte diese Änderung. Allerdings sollten wir von Seitenzahlen absehen, da viele die Hefte als eBook haben und ich mir auch bei den PDF-Versionen nicht sicher bin, ob die Seitennummerierung passt. Ich denke die Angabe des Kapitels ist ausreichend. --Hb059 (Diskussion) 14:11, 29. Jul. 2019 (CEST)
Hah! Das hätte ich beinahe auch noch angefügt - mit den Seitenangaben ist es ja nicht nur so, dass Ebook-Leser sie nicht SETZEN können, sondern auch, dass sie für Ebook-Leser weitgehend nutzlos sind. Da die Kapitel nur sehr selten wirklich lang sind, befürworte ich Kapitel-Referenzen auch als Standard (und dass wir das unter Hilfe:Quellenangaben#Art_und_Weise_der_Quellenangabe auch so sagen). Aber vielleicht ist das eine separate Diskussion? --Lars Jürgenson (Diskussion) 14:20, 29. Jul. 2019 (CEST)
Habe grade gemerkt, dass der Link/Baustein erweitert wurde. Danke, @Klenzy! (nehme ich an?).
So ist es um einiges komfortabler, genaue Verweise zu setzen (was der Standard sein sollte)! --Lars Jürgenson (Diskussion) 17:03, 31. Jul. 2019 (CEST)
Ah, aber kleines Manko noch: Das letzte Leerzeichen (nach "Kap.") ist nicht "geschützt" (kein &nbsp;) --Lars Jürgenson (Diskussion) 17:06, 31. Jul. 2019 (CEST)
Stimmt, ein Tippselfehler. Erledigt. --Klenzy (Diskussion) 17:13, 31. Jul. 2019 (CEST)
Super, nochmal DANKE! --Lars Jürgenson (Diskussion) 17:19, 31. Jul. 2019 (CEST)

PP-Server

Bei unserem Server gab es innerhalb weniger Monate erneut ein Problem mit der Hardware. Die Maßnahme unseres Betreibes war in beiden Fällen kein Austausch von Teil-Komponeneten (Platten), sondern ein komplett Austausch des gesamten Servers. Was mich verwundert ist, dass STRATO uns gebrauchte Systeme zur Verfügung stellt. Deshalb sollten wir - in Ruhe - hier mögliche Verbesserungen zusammentragen diese auch kostenmäßig bewerten und dann entscheiden, was verbessert werden kann.

Status heute:

Die wichtigsten Konsequenzen unseres heutigen Systems, sind die dass STRATO uns nur ein ganz bestimmtes (dediziertes) Stück "Blech" vermietet und strommäßig am Laufen hält und unser SystemAdmin Klenzy sich um alle anderen Tätigkeiten kümmern muss. Wir haben sozusagen unsere "eigene" Hardware und sind unabhängig. Wir sind im Falle eines Defektes aber auch dann direkt betroffen.

Um diese Abhängigkeit zu reduzieren bietet sich heutzutage an, den Server zu virtualisieren. Damit werden wir zwar geräteunabhängig, aber wir benötigen zusätzliche kostenpflichtige Tools.

Aus meiner Sicht denkbar wäre eventuell folgende Konzeption (wenn man mit dedizierten Servern weiter arbeiten möchte):

Ein leistungsfähiger Server (ähnlich heute) als virtueller Host #1. Darauf läuft unsere produktive Perrypedia - wie heute. Einen zweiten Low-cost Server (gleiche Plattenkapazität aber z.b. mit weniger CPU-Leistung) als virtueller Host #2. Darauf läuft ein eigenständiges Perrypedia Testsystem (anders als heute). Dieses System könnte bei einem Hardwareproblem von Host #1 innerhalb kurzer Zeit als produktives Notfallsystem in Betrieb gehen. Man müßte mit STRATO zusammen bewerten lassen, welche Mehrkosten mit so einer Konstellation einhergeht.

Ich denke das reicht zuerst einmal fürs erste. Über euere Rückmeldungen würde ich mich freuen. --Norman (Diskussion) 08:27, 18. Jul. 2019 (CEST)

Von der technischen Seite habe ich nicht viel Ahnung, weiß aber, dass heutzutage virtuelle System durchaus Usus werden. Von daher sollte das kostentechnisch auch nicht (mehr) SO teuer werden. Zumindest denke ich, dass man da Verhandlungsspielraum hat. Ins Feld bringen kann man, dass wir doch ein sehr guter und langjähriger Kunde sind und das ja auch in Zukunft so bleiben wird. Ich fänds gut, wenn Ihr für jede Idee mehrere Angebote reinholt und man die dann vergleichen könnte, sowohl, was es rein praktisch/technisch an Vorteilen/Nachteilen bringt als auch die Kosten. In dem Zusammenhang würde mich zudem interessieren, wieviel Geld wir gerade auf dem Konto haben? --Pisanelli (Diskussion) 10:39, 18. Jul. 2019 (CEST)
Der Umzug auf einen neuen Server nur weil eine Platte kaputt ist, halte ich für sehr unglücklich. Bei Hetzner war da damals anders. Da wurde die Platte getauscht. Die war zwar auch nicht neu aber der Aufwand hielt sich in Grenzen. Gegen einen virtuellen Server gibt es nach meiner Meinung nichts einzuwenden. Vor ein paar Jahren gab es allerdings keinen virtuellen Server, der unseren Ansprüchen genügte. Das kann sich aber mittlerweile geändert haben. Auf einem virtuellen Server hätten wir zumindest keine Probleme mehr mit Hardwareausfällen. --Poldi (Diskussion) 11:01, 18. Jul. 2019 (CEST)
Das Projekt www.mobadaten.info läuft bei FHD. FHD ist ein kleiner IT-Dienstleister in Gütersloh. Die sind seit 1996 aktiv. Durch einen Kollegen von mir bin ich ich auf diese Firma aufmerksam geworden. FHD hat wohl Server bei Arvato in Gütersloh gemietet, so wie ich das verstanden habe. Bei dem Projekt handelt es sich, wie bei der Perrypedia auch, um eine Mediawiki-Installation. Seit 2009 betreibe ich dieses Projekt. Ich wollte gerne irgendwas mit Modellbahn, irgendwas mit Internet und irgendwas mit Programmieren machen und kann das bei diesem Projekt gut unter einen Hut bringen. Seit 2009 war das Projekt höchstens zwei, dreimal down. Und das auch nur stundenweise. Server- und Festplattenprobleme sind mir in den vergangenen zehn Jahren nie untergekommen.
Anfang Juni sind die Leute von FHD an mich herangetreten, weil die den "alten" Server, auf denen dieses Projekt noch lief, in den verdienten Ruhestand schicken wollen. Irgendwann mal sprachen die davon, dass das wohl noch ein 32-Bit-System sei. Der Umzug auf den neuen Server inkl. Datensicherungen und PHP-Update wurde binnen kurzer Zeit von FHD erledigt. Nach Absprache wurde dies von denen binnen Stunden erledigt. Danach konnte ich die MW-Version von 1.23 auf 1.31 hochziehen, die bei FHD haben dann PHP auf 7.2 gebracht und HTTPS aktiviert. Die wenigen Ungereimtheiten lagen entweder an Extensions, die noch nicht mit PHP 7.2 bzw. MW 1.31 klarkamen. Das konnte ich dann problemlos selbst regeln. Bei den wenigen Dingen, die seitens des Providers noch zu erledigen waren (beispielsweise das Rendern von PDFs zu Grafiken, da fehlten einige Tools auf dem Server) wurde ich bestens, kompetent, schnell und zu meiner vollste Zufriedenheit von FHD unterstützt. Ich bin da voll des Lobes!
Was man allerdings auch sagen muss: Ein Schnapp sind die nicht. Ich zahle da ca. 130€ im halben Jahr. Und das läuft nicht exklusiv auf einem eigenen Server (könnte man aber von denen auch bekommen, Kostenfrage). Auch habe ich da keinen Shell access. Lässt sich aber ein klein wenig mit Tools wie dem PHP File Manager zum Teil umschiffen. --WGK.derdicke (Diskussion) 15:03, 18. Jul. 2019 (CEST)

Ein paar Eckdaten zum aktuellen Status, dann eine Zusammenfassung der (derzeit online sichtbaren) Angebote von Strato.

  • Das Spendenkonto ist leider immer noch nicht aktuell abgerechnet. Nach Grobschätzung des PRFZ-Schatzmeisters sollen derzeit deutlich über 3000€ auf dem Konto sein.
  • Unser dedizierter Server (dediziert heißt: exklusiv unserer) kostet 44€/Monat. Dass bei einem Hardwareproblem gleich der ganze Server getauscht wird, wusste bis Dezember keiner von uns; der Vorteil der RAID-1-Plattenspiegelung ist damit leider größtenteils verschenkt. Ich nehme an, für Strato ist es wirtschaftlicher (= billiger), ein Ersatzgerät hinzustellen, als an dem vorhandenen Server herumzuschrauben. Zusätzliche Services (SLA = Service Level Agreement) kosten 19–129€/Monat zusätzlich zum Basispreis. Ab welchen SLA's ein Komponententausch möglich ist: leider undurchsichtig.
  • Geräte mit vergleichbarer Leistung wie unseres sind gar nicht mehr im Angebot. Aktuelle dedizierte Server haben deutlich bessere Ausstattung/Leistung und kosten 60-108€/Monat. Es gibt immer wieder Sonderangebote oder Angebotspakete, bei denen man kräftig sparen kann. Falls ein Hardwareproblem auftritt, trifft es uns aber wieder genauso wie jetzt bereits zweimal. Bei einem neueren Gerät ist lediglich die statistische Wahrscheinlichkeit größer, eine längere Zeit fehlerfrei zu fahren. Mehr Sicherheit verschafft wiederum ein SLA.
  • Managed Server kosten 26-118€/Monat, bereits das Gerät für 26€ ist ein wenig besser ausgestattet als unseres. Für diese Server übernimmt Strato die gesamte Serveradministration, der Kunde hat keinen Root-Zugriff. Wie das im Detail funktioniert, Installation von Mediawiki, Softwareupdates etc.: keine Ahnung.
  • Preislich sehr interessant sind die virtuellen Server, bei Strato heißen sie "V-Server", ab 5€/Monat (!). Hier haben sich in den vergangenen Jahren sowohl die Leistungswerte deutlich nach oben wie auch die Preise nach unten verschoben. Angesichts unserer Seitenabrufzahlen vermute ich, dass die untere Preisklasse mit 100-/500-MBit/s-Internetanbindung zu knapp ausgestattet ist; bleiben die V-Server mit 1000 MBit/s für 19–25€. Laut der technischen Beschreibung bringen diese mehr Leistung als unser aktueller Server. Wir hätten vollen Root-Zugriff. Etwas undurchsichtig ist die Beschreibung der automatischen Backups.
  • Eine andere Variante für mehr Sicherheit bietet die zweite von Norman angesprochene Möglichkeit: ein zweiter Server mit einer zweiten IP, sodass im Notfall innerhalb von wenigen Minuten auf den Ersatz umgeschaltet werden kann. Bei Strato läuft das unter dem Stichwort "ClusterIP" und ist, wenn ich es richtig verstehe, für dedizierte Server ebenso zu haben wie für V-Server. Genaue technische Details: Fehlanzeige. Preis: 9€/Monat.
  • Strato bietet auch eine vollständige cloudbasierte Lösung an. Ebenso wie bei V-Servern kann es bei "Server on demand" nahezu keine Hardwareprobleme mehr geben. Technisch innovativ, aber die Kosten: schwer zu durchschauen. Ich rate eindringlich davon ab. Schön, wenn wir im einen Monat sparen und nur 15€ zahlen - und was, wenn im nächsten Monat 150€ fällig sind?

Soviel als Zusammenfassung. An den Preisspannen sehen wir, dass es teurere, aber auch günstigere Lösungen gibt. Wer mehr wissen möchte, folge bitte dem Link, den Norman oben gesetzt hat. Die online verfügbaren Informationen lassen aber einige Fragen offen. Wir werden daher in einem ersten Schritt Rat bei Strato einholen und unsere Fragen klären, noch ohne uns auf überhaupt irgendwas festzulegen. --Klenzy (Diskussion) 10:44, 20. Jul. 2019 (CEST)

Bei dem Thema Keinen Root-Zugriff und wie das im Detail funktioniert kann ich aushelfen. Die Konstellation ist bei dem MoBaDaten-Wiki eine solche. So handhabe ich das da:
  • Auf den Webspace habe ich dort Zugriff mittels FTP. Der Zugriff erfolgt mit einem FTP-Client, in meinem Fall FireFTP im Firefox-Browser. Damit hat man Zugriff auf Dateien der Mediawiki-Software inkl. Extensions und den hochgeladenen Bildern. Diese werden ja nicht in der Datenbank gespeichert sondern als Files im Webspace.
  • Der Zugriff auf die Datenbank erfolgt mit phpMyAdmin.
  • Update (ohne Datenbankanpassung) von beispielsweise MW 1.31.2 auf MW 1.31.3 läuft beispielsweise so, dass die geänderten Dateien der neueren Version an die passende Stelle hochgeladen werden.
  • Update (mit Datenbankanpassung) von beispielsweise MW 1.31.x auf die nächste LTS-Version geschieht über der Web-Browser mit dem Update-Skript
  • Wenn es nicht die eigentliche Mediawiki-Software betrifft, ist der Provider gefragt. Der installiert beispielsweise eine neuere PHP-Version, eine benötigte PHP-Erweiterung oder sonstige Tools.
Bei dem zuvor erwähnten Umzug auf einen neuen Server inkl. Update der Mediawiki-Software ging dies folgendermaßen:
  • Nach Absprache mit dem Provider habe ich die Schreibsperre am Wiki aktiviert.
  • Nachdem ich den Provider informiert hatte, dass nun keine Datenänderungen mehr stattfinden, hat er Webspace und Datenbank gesichert (Es lief dort MW 1.23 unter PHP 5.3)
  • Danach hat der Provider dies auf dem neuen Server installiert. Dabei PHP auf Version 5.6 gebracht (ist mit MW 1.23 kompatibel).
  • Nachdem das Wiki einige Stunden später auf dem neuen Server wieder erreichbar war, wurde ich vom Provider darüber informiert.
  • Daraufhin habe ich die MW 1.31-Installation auf den Webspace kopiert und das Update-Skript aus dem Web-Browser gestartet.
  • Nachdem dies erfolgreich durchgelaufen war, habe ich den Provider informiert, so dass er nun PHP 7.2 aktivieren konnte.
  • Als das geschehen war, hat mich mein Provider informiert und ich konnte nun die noch notwendigen Änderungen an diverses Extensions durchführen (Manche davon sind nicht mehr softwaremäßig gepflegte alte Schätzchen oder modifizierte Versionen, die müssen dann an Dinge wie PHP 7.2 und/oder MW 1.31 angepasst werden).
  • Es zeigte sich, dass für die Extension PdfHandler noch die sog. xpdf-utils auf dem neuen Server fehlten. Diese hat dann der Provider auf Anforderung auf dem Gerät installiert.
  • Abschließend hat der Provider dann das Protokoll HTTPS aktiviert (Der alte Serve hatte das noch nicht).
  • Zu diesem Zeitpunkt habe ich die Schreibsperre wieder entfernen können, da im Prinzip alle Funktionalitäten wieder gegeben waren.
  • Dann und wann stoße ich noch auf Dinge, die nicht ganz rund laufen. Das sind dann Gegebenheiten, die eher selten gefordert sind. Aber ansonsten: Fertig.
--WGK.derdicke (Diskussion) 15:07, 20. Jul. 2019 (CEST)
Von der Materie verstehe ich bei Weitem nicht genug um sagen zu können, was die beste Lösung ist. Diese Entscheidung müssen die Fachleute unter uns ausdiskutieren.
Aber ich weiß, dass ich eine absturz- bzw. ausfallsichere PP haben möchte...und das sollte keine Frage des Geldes sein. Oben sehe ich aber auch keine aufgeführte Preisspanne, die mich erschreckt. --JoKaene 21:19, 28. Jul. 2019 (CEST)
Hier konnte ich in der letzten Zeit immer mal wieder von technischen Schwierigkeiten rund um den PP-Server lesen, bis hin zu dem aktuellen Tausch des physikalischen Geräts. Da steht wohl Strato als Provider in der Verantwortung - und kommt dieser wohl auch nach. Trotzdem ist die damit verbundene Downtime mindestens ärgerlich und bringt wohl nach dem Tausch von Hardware (Festplatte, komplettes Gerät) auch nicht unerheblichen Aufwand für die Systemadministration hier mit sich. Das ist gleich zweimal ärgerlich. Googelt man mal nach Strato und Erfahrungen, so bekommt man durchaus Ambivalentes zu lesen. Die technischen Schwierigkeiten hier scheinen auf den ersten Blick diesen Eindruck zu bestätigen. Zur Eingrenzung: Ich meine hier NICHT irgendwelche Konfigurationsaspekte, die von der Systemadministration erledigt werden. Ich meine lediglich die Dienste des Providers Strato.
Aus diesem Grunde habe ich hier einmal das oben erwähnten Projekt genannt und dessen Provider, weil ich zu dem Thema Hardwareprobleme in Zusammenhang mit diesem Provider absolut nichts sagen kann, da es in den 10 Jahren Laufzeit dieses Projektes keine gab und weil ich zu dem Thema Downtime in Zusammenhang mit diesem Provider praktisch kaum Erfahrungen habe, da in der gesamten Laufzeit über 10 Jahre das Projekt, bzw. der Server, auf dem das liegt, lediglich zwei- bis dreimal stundenweise down war. Zudem hat mich die Geschmeidigkeit, mit der der unlängst erfolgte Serverwechsel (wurde vom Provider erledigt) mit anschließendem Mediawiki-Update (habe ich erledigt) über die Bühne gegangen ist, höchst positiv überrascht.
Ob eine Konfiguration genau wie die bei dem von mir genannten Projekt für die PP eine sinnvolle ist, mag auch ich nicht beurteilen können und wollen, da der Traffic der PP wohl ungleich höher ist. Wohl eher nicht. Insofern mag eine PP als Mediawiki-Inistallation, welche mit mehreren bzw. vielen anderen Websites auf einem Server gehostet werden, wohl eher suboptimal sein.
Allerdings scheint mir das Thema Managed Server kein uninteressantes zu sein. Bei so einem „betreuten Server“ muss man sich nicht ab dem allerersten Bit Software höchstpersönlich und selbst darum kümmern. Das physikalische Gerät sowie dessen Betriebssystem, die Anbindung an das Internet, der Webserver und Software wie PHP (zum Betrieb der Mediawiki-Installation notwendig) werden durch den Provider bereitgestellt und gewartet. Eventuelle Anfoderungen an diesen Teil der Software klärt man dann mit dem Provider ab, der das dann einrichtet, statt mühselig selbst jede kleinste Einstellung vornehmen zu müssen. Die Mediawiki-Installation selbst mit ihren individuell installierten und zum Teil individuell erstellten Erweiterungen wird dann höchst persönlich erledigt. Meine Erfahrung sagt: auch da ist oftmals (insbesondere nach einem größeren Update der Mediawiki-Software) schon genug zu tun.--WGK.derdicke (Diskussion) 17:51, 3. Aug. 2019 (CEST)

Artikel zu Handlungssträngen mit Template:Tree chart gestalten

Ich habe mir die Mühe gemacht um einen Zyklus anhand eines Diagramms (missbräuchlich ;) mit {{Stammbaum}} gestaltet) die Handlungstränge abzubilden. https://www.perrypedia.proc.org/wiki/Benutzer:Ger77/Genesis_(Handlungsstränge) Das ist aber sehr mühsam. Im Zuge dessen bin ich auf die Möglichkeit des Template:Tree chart gestoßen, dass deutlich einfacher ist. Leider gibt es das nur im englischen Wiki. Wäre es denkbar, dieses Modul auch für die Perrypedia verfügar zu machen? Damit ließen sch die graphischen Darstellungen, die es vom Verlag für die Handlungsstränge von 1800 bis 2200 gab sehr leicht nachstellen. Für die weiteren Zyklen z.B: Genesis ebenfalls, womit diese dann sehr übersichtlich (evtl. aufklappbar?) aufscheinen würden. Wäre dieses Modul technisch mit vertretbaren Aufwand hinzufügbar? --Ger77 (Diskussion) 19:29, 20. Apr. 2019 (CEST)

Welche Vorteile versprichst Du dir vom Template:Tree chart? Es ist innendrin einfacher als unser Stammbaum (Template:Family tree in der englischen und deutschen Wikipedia); das liegt nach meinem ersten Eindruck daran, dass die ganze aufwendige Arbeit an ein Lua-Skript delegiert wird. Aber außenrum ist die Verwendung fast identisch, nur ein paar Parametercodes haben sich geändert. --Klenzy (Diskussion) 21:51, 20. Apr. 2019 (CEST)
Der Vorteil beim Tree chart ist, dass man einen Raster erhält indem man die Zeichen positionieren kann. Daher ist es sehr viel einfacher Linien von einer Box zu einer anderen zu ziehen. Man hat also nicht das Problem wie beim Stammbaum, dass man bei jeder Einfügung eines Strich einer Ecke, einer Kreuzung oder einer Box alles wieder neu positionieren muss. --Ger77 (Diskussion) 12:20, 21. Apr. 2019 (CEST)iehe https://en.wikipedia.org/wiki/Template:Tree_chart. :) --Ger77 (Diskussion) 12:20, 21. Apr. 2019 (CEST)
Wo ist der Unterschied zwischen [2] und [3]? Vielleicht habe ich Tomaten auf den Augen, aber ich sehe kein "Raster". --Klenzy (Diskussion) 12:38, 21. Apr. 2019 (CEST)
bei dem Family Tree wird die Positionierung der einzelnen Elemente wie Ecke, Linie, Kreuzung oder Box sehr schwierig, da diese je nach Länge sofort wieder die anderen Positionierungen verändern. Beim tree chart ist das viel einfacher weil da ein vorgegebenes Raster entsteht wenn man mit "|" dieses definiert. (Siehe Bild nach "The code above produces a table of size 9 rows x 10 columns as shown below.") Familiy tree wird deswegen in der englischen Wiki als obsolet (deprecated) betrachtet und darauf hingewiesen, dass man Tree Chart verwenden soll Ger77 (Diskussion) 16:47, 21. Apr. 2019 (CEST)
"Deswegen" sehe ich da zwar nirgends geschrieben, aber probieren wir es einfach aus. Das machen wir bitte im Testwiki. Du kannst die benötigten Vorlagen dort selbst reinkopieren; ich schaue anschließend, was auf dem Server alles installiert werden muss. --Klenzy (Diskussion) 18:39, 21. Apr. 2019 (CEST)
Bitte um Entschuldigung. Habe mich auf der englischen Wiki angemeldet und es dort in der sandbox meines users ausprobiert. Sobald ich die Boxen mit drei "|", also drei Spalten berechnet habe, passt alles ganz genau. Daher ist die Tree_chart genau wie die Family_tree nur erweitert, so wie du es schon bemerkt hast. Also kein echter Mehrwert für das was ich machen will. "Stammbaum" ist also ausreichend. Mein Fehler :( Danke. --Ger77 (Diskussion) 00:26, 22. Apr. 2019 (CEST)
Hey, kein Problem. Es hätte ja sein können. --Klenzy (Diskussion) 11:00, 22. Apr. 2019 (CEST)
Die Idee der grafischen Darstellung finde ich gar nicht schlecht, aber mit der Stammbaumdarstellung eher ungünstig umgesetzt. Wir haben aber auch EasyTimeline: Damit könnte es wesentlich kompakter und auch grafisch interessanter gestaltet werden. --JoKaene 22:06, 20. Apr. 2019 (CEST)
Ist diese Erweiterung tatsächlich in der Perrypedia verfügbar? Aber zudem geht.o es mir darum, so etwas wie dieses Bild https://web.archive.org/web/20071229073406/http://www.perry-rhodan.net/information/nathan/geschichte/handlung1800.html wikigerecht zu gestalten. Bei Handlungssträngen gibt es Verflechtungen, die ebenfalls dargestellt werden müssen. --Ger77 (Diskussion) 12:20, 21. Apr. 2019 (CEST)
Ja, die Extension ist bereits installiert. Benutzt wurde sie allerdings bislang nicht. Lediglich Poldi hat sie hier einmal angewendet. Schau es dir einfach mal an. --JoKaene 15:08, 21. Apr. 2019 (CEST)
Die EasyTimeline halte ich eines Versuches wert. Ich glaube, das wäre übersichtlicher als die Tree-Darstellung oder das damalige Bild von der PR-Webseite. --Klenzy (Diskussion) 11:00, 22. Apr. 2019 (CEST)
Easy Timeline ist ebenfalls veraltet. Offenbar bereits seit 2015 Siehe: https://de.wikipedia.org/wiki/Hilfe:Zeitleisten. Es scheint sich auch keine neue erstellen zu lassen. --Ger77 (Diskussion) 17:32, 22. Apr. 2019 (CEST)
Herrje ... es ist aber auch ein Zirkus mit den Extensions.
Dann schau ich im Lauf der Woche, dass ich die Graph-Extension im Testwiki installiert bekomme. --Klenzy (Diskussion) 17:54, 22. Apr. 2019 (CEST)
Hab Easy Timeline in der EN-wiki in der sandbox probiert. Dort geht es (https://en.wikipedia.org/wiki/User:AstroGK/sandbox). :O Hab mir Graph schon mal angeschaut, das ist viel komplexer. Vielleicht wäre es möglich, doch mit der einfachen, wenn auch veralteten Methode zu arbeiten? Allerdings scheinen die Vorschauen bei den Links nicht zu funktionieren. Es wird zwar der Tooltip z.B: "Quelle:PR705" angezeit aber keine Vorschau bei Poldi --Ger77 (Diskussion) 22:16, 22. Apr. 2019 (CEST)
Das hängt damit zusammen, dass EasyTimeline keinen HTML-Code erzeugt, sondern eine Grafik. In einer Grafik kann es als interaktive Elemente nur Tooltips geben, das wird wahrscheinlich (sicher weiß ich es nicht) auch in der Graph-Extension nicht anders sein. --Klenzy (Diskussion) 21:25, 23. Apr. 2019 (CEST)
Okay, dann warte ich jetzt dann mal bis du dankenswerterweise "Graph" im TestWiki eingefügt hast und schau dann ob es sich tatsächlich so verhält wie du sagst. Wäre schade da dann eigentlich kein Mehrwert für die User da wäre, zumindest den Aufwand nicht wert.--Ger77 (Diskussion) 18:33, 25. Apr. 2019 (CEST)
So, mit etwas Mühe habe ich jetzt die Graph-Extension im Testwiki installiert. Zumindest die einfachen Beispiele von [4] funktionieren: [5]
Ich muss aber gestehen, dass ich nicht die geringste Ahnung habe, wie das alles funktioniert. Neben Lua5.1 auf dem Server (das war der einfachste Teil der Arbeit) benötigt Graph außerdem 4 weitere Extensions sowie etwa 25 Vorlagen und Module. Ob das nun vollständig ist, weiß ich nicht. Es können sich jederzeit weitere Lücken auftun. Wer sich dieses verschachtelte Tohuwabohu ausgedacht hat ... und die Dokumentation ist, wie so oft, leider mangelhaft.
Es gibt neuere Lua-Versionen, aber die Mediawiki-Extensions funktionieren nur mit 5.1. Die Lua-Extension wurde von 2008 bis 2012 entwickelt und seitdem nicht mehr. Trotzdem ist sie nur als "experimentell" eingestuft. Man kann sie auch nicht auf dem üblichen Weg herunterladen, sie ist weder im Git noch im ExtensionDistributor - sondern ich müsste theoretisch das veraltete Versionsverwaltungstool SVN (siehe auch [6]) verwenden.
Ich kann derzeit nicht einschätzen, was das alles soll. Jedenfalls wäre das Testwiki jetzt bereit für, äh, erste vorsichtige Tests. Wenn Du jetzt noch Lust hast ;-) --Klenzy (Diskussion) 22:58, 25. Apr. 2019 (CEST)
Habe im Testwiki ein bisschen rumgespielt und in den dokus zu graph nachgelesen. Mir ist völlig unklargeblieben, wie man in diese generierte Graphiken Links einbetten kann. Ich finde auch kein Beispiel, dass wie die Easy-Timeline Graphik von Benutzer:Poldi/Mitarbeit aussieht. Dazu sind diese generierten Bilder von der Breite begrenzt womit sich keine 100 Elemente (ein Zyklus) ausgehen. Ich habe mit dem Stammbaum-Werkzeug eine Graphik erstellt zum Tolkanderzyklus (Benutzer:Ger77/Die_Tolkander_(Handlungsstränge)). So in etwa würde ich gerne die Zyklen aufbereiten (Hab mir dazu ein Excel erstellt zum Editieren des Sources) --Ger77 (Diskussion) 17:45, 1. Mai 2019 (CEST)

Artikel zu Handlungsebenen einheitlicher und übersichtlicher

Weil ich für meine beabsichtigte Arbeit für die Exzerpte der HZFs die Handlungeben der Zyklen durchgeschaut habe, ist mir aufgefallen, dass Romane in mehreren verschiedenen Ebenen aufgelistet werden. Was ist der Grund dafür? Bei Die_Tolkander_(Handlungsebenen) bis Der_Sternenozean_(Handlungsebenen) scheinen die vom Verlag veröffentlichten Handlungsstränge als Richtschnur gedient zu haben, da stimmt es noch. Dann ab Neuroversum_(Handlungsebenen) werden dieselben Romane mehrfach gelistet. Ganz stark ist das dann bei Genesis_(Handlungsebenen) sichtbar. 47 Romane sind hier mehrfach gelistet.
Der Verlag selbst hatte auf seiner alten Webseite diese Übersichten:
http://www.perry-rhodan.net/information/nathan/geschichte/handlung1800.html bis
/http://www.perry-rhodan.net/information/nathan/geschichte/handlung2225.html
Wäre es nicht klug sich an diesem Modell zu orientieren? Denn es sind eigentlich Handlungstränge so wie auf den Bildern, weniger Handlungsebenen. Daher wären zuerst nach Abschluss eines Zyklus die Romane so aufzudröseln und dann den Ebenen im Artikel zum jeweiligen Zyklus xxxxx_(Handlungsebene zuzuordnen, so dass jedes HZF nur einmal vorkommt jedoch ein erklärender Test die Aufsplittung oder Zusammenführung der Stränge beschreibt, falls dies in einem Roman passiert. Ansonsten sind diese Artikel für Leute die da reinschauen nicht besonders interessant oder brauchbar, jedenfalls aus meiner jetzigen Sicht darauf. Was meint ihr dazu? Ger77 (Diskussion) 20:58, 22. Mär 2019 (CET)

Handlungsstrang ist auch nur ein Begriff, um auszudrücken, dass die betreffenden Romane in irgendeiner Art und Weise zusammen gehören. Wir sagen Handlungsebene - irgendwer hat das mal so eingeführt - und meinen dasselbe. Die Anmerkung oben auf den betreffenden Seiten gibt klar Aufschluss über die Herkunft: »Einteilung und Benennung erfolgten subjektiv [...]«, heißt, jemand hat das irgendwann festgelegt, vielleicht kannte derjenige die von dir verlinkten verlagsseitigen Handlungsstränge, vielleicht auch nicht. Wer weiß?
Wir sind ein Wiki, bei Fehlerkorrekturen und kleinen Änderungen brauchst Du nicht erst zu fragen. Wenn Du etwas groß umstruktieren möchtest, empfehle ich, ein Beispiel zu machen und zur Diskussion zu stellen (zum Beispiel auf deiner Spielwiese oder bei ganz großen Dingen im Testwiki, wo Du nach Herzenslust fuhrwerken kannst). Ehrlich gesagt verstehe ich nämlich nicht ganz, worauf Du damit hinauswillst: nach Abschluss eines Zyklus die Romane aufdröseln und den Handlungsebenen zuordnen - soweit klar, ist aber genau das, was gemacht wurde; und: ... dass jede HZF nur einmal vorkommt - halte ich für eine Illusion. Egal wie Du es gliederst, es wird immer Romane geben, die zu mehreren Handlungsebenen/-strängen gehören.
Genau deshalb wäre ein Beispiel schön - damit ich/wir schneller kapiere(n), wie Du es meinst.
In einem Punkt bitte aufpassen: Es besteht ein enger Zusammenhang zwischen den Handlungsebenen-Seiten und der Navigationsleiste der HZF. Siehe zum Beispiel Die Dritte Macht (Handlungsebenen), die Überschriften sind dieselben! --Klenzy (Diskussion) 13:48, 23. Mär 2019 (CET)
PS. vergessen zu erwähnen: Die Handlungsebenen-Seiten und die Handlungsebenen-Navigation sind keineswegs fertig, sondern Baustelle seit ... ..., wo immer mal wieder jemand macht und tut und ... ;-) --Klenzy (Diskussion) 13:52, 23. Mär 2019 (CET)
Über Handlungsebenen kann man sicher im Einzelfall streiten.
Unstrittig halte auch ich, dass manche Romane zu mehreren Handlungsebenen gehören (die Ebenen haben Schnittmengen). In manchen Zyklen mehr, in anderen weniger.
Verlagssicht so vom Verlag kommuniziert ist sicher cool. Sollte aber denke ich nur ein Einflussfaktor sein.
Erinnere mich gerade an Hauptpersonenstatistiken. Gab es auch vom Verlag, die verlagsseitige Sache hatte aber massiv Fehler & Lücken?
Auch die PR-Macher machen nicht nur Primärquellen und bei allem, was sie von ihrem Hauptprodukt ableiten (z.B. - rein erfunden aber möglich - Praktikanten mal über Hefte schauen lassen und Hauptpersonenstatistik erstellen lassen) sind sie genauso Fehlern ausgesetzt wie wir.
Selbst wenn die oben verlinkte Handlungsstrang-Geschichte direkt aus dem Expose abgeleitet wäre, wäre z.B. möglich, dass sich halt ein Autor in einem Einzelroman nicht so ganz dran gehalten hat.
Generell finde ich gut zu schauen, ob der Verlag nicht eh was "offizielles" rausgegeben hat. Nur etwas aufpassen sollten wir halt immer. --NAN (Diskussion|Beiträge) 15:30, 23. Mär 2019 (CET)
Ich hätte es nicht besser ausdrücken, was Klenzy und NAN hierzu gesagt haben. Soweit mir bekannt ist, hat der Verlag nach 2300 herum keine übersichtsartigen Handlungsebenen mehr herausgegeben. Insofern besteht hier ein Gestaltungsfreiraum und jede nachvollziehbare Gruppierung ist willkmommen. Eine Gruppierung nach Personen ist auch kein Muss, denn dann sind Mehrfachnennungen kaum zu vermeiden. Auf den Handlungsebenen-Seiten haben wir bisher meist 2-stufige HIerachienen, wobei wir darauf geachtet haben, dass die oberste Stufe namensgleich ist mit der in der Navigationsleiste. Wie schon von Klenzy vorgeschlagen, wäre es gut einen Entwurf von dir vorgestellt zu bekommen. Vielleicht suchst du dir einen Zyklus aus, der noch nicht ausformuliert wurde (Die Linguiden, oder folgende) --Norman (Diskussion) 20:14, 24. Mär 2019 (CET)
Hier das Beispiel Benutzer:Ger77/Genesis_(Handlungsebenen) --Ger77 (Diskussion) 21:32, 29. Mär 2019 (CET)
Schön! Meine detailierte Antwort findest du dort Diskussion:Genesis (Handlungsebenen)#Restrukturierung: Übersicht Handlungsebenen Genesis --Norman (Diskussion) 09:25, 31. Mär 2019 (CEST)
Nicht nur deine Antwort; die Diskussion zum konkreten Beispiel geht insgesamt dort weiter -> Diskussion:Genesis (Handlungsebenen)#Restrukturierung: Übersicht Handlungsebenen Genesis. --Klenzy (Diskussion) 10:54, 1. Apr. 2019 (CEST)

Vorschautext für Heftromane?

Verlinkt man in Texten den Titel des Romanheft direkt z.B: PR1801 , statt der Quellenangabe PR1801 dann wird wenn der Cursor über den Link bewegt wird, eine Vorschau angezeigt, wie auch bei vielen anderen Schlagwörtern. Wenn man daher vor dem Absatz "Handlung" einen kurzen Text einfügt, dann wird dieser so wie bei den Schlagwörtern in dieser Vorschau angezeigt. (max. etwa 280 Zeichen) In Zyklen_und_Großzyklen:Abschnitt "Die_Tolkander" habe ich diese direkte Verlinkung gemacht zu jedem Roman der Handlungsfäden. Wenn ihr einverstanden wärt, würde ich nach und nach bei jeden Heftroman so eine Kurzfassung voranstellen, damit diese aufscheinen kann.
Beispiel : Heft 180! mit vorangestellter Kurzfassung
Hier auf dieser Seite könnten die Links ebenfalls durch die direkten ersetzt werden,, wodurch wenn man die Maus über die Links bewegt, die Hefte in Kurzfassung chronologisch lesen könnte. Die Arbeit des Austauschens ist nicht schwer, dazu reicht eine in Excel erstellte Tabelle.

Was sagt ihr zu diesem Vorschlag? Ger77 (Diskussion) 23:22, 20. Mär 2019 (CET)

(Hierher verschoben von Diskussion:Perry Rhodan-Heftromane#Vorschautext für Heftromane? mit der Bitte um nachträgliche Absolution. --Klenzy (Diskussion) 08:47, 21. Mär 2019 (CET))

Das ist insgesamt ein sehr schöner Vorschlag, um die Perrypedia für die Leser zu verbessern! Lass uns schauen, was wir daraus machen können. Zuerst einmal zu den Quellenlinks.
Es wird nicht nötig sein, die Links umzustellen. Die Vorschau für Quellen lässt sich ganz simpel mit einer Zeile im "Common.js" (js = Javascript) aktivieren: mw.config.set('wgContentNamespaces', [0, 100]); - 0 ist der Hauptnamensraum und ist der automatisch für jeden Benutzer gültige Standardwert. 100 sind die Quellen und sind nicht Standard. Ich habe das in meiner privaten Benutzer:Klenzy/common.js schon drin und bin schon so dran gewöhnt, dass ich nicht mehr dran gedacht habe, dass es eine private Einstellung für mich ist ...
Du kannst also zunächst dein privates "Common.js" anlegen, dann hast Du die Vorschau für dich selbst aktiviert, ganz ohne Ändern der Quellenlinks (wofür es, jetzt am Schluss kann ich es sagen, ungefähr umpfzehn Gegengründe gäbe).
Damit das für alle gilt, bleibt abschließend also nur die Frage zu klären, ob wir diese Einstellung mw.config.set('wgContentNamespaces', [0, 100]); als neuen Standard haben wollen - dann müssen wir das nämlich lediglich in das globale, für alle Nutzer gültige Mediawiki:Common.js einsetzen. Um das zu machen, hätte ich aber gern zuerst ein paar weitere Meinungen...! --Klenzy (Diskussion) 09:12, 21. Mär 2019 (CET)
Gute Idee! --Johannes Kreis (Diskussion) 10:18, 21. Mär 2019 (CET)
Fände das auch als sehr sinnvoll. Hatte damals den Quelle:-Namensraum angelegt, damit einerseits einfach einzelne Romane verlinkt werden können und wir gleichzeitig den Roman-Titel als Titel verwenden können. Sehe auch keinen Weg, wie wir das anders lösen könnten. Und jetzt überall die Links umzustellen ist nur ein Haufen unnötiger Arbeit. Selbst wenn es diesen Weg über common.js nicht gäbe, würde ich das daher programmatisch lösen wollen. --Aki 12:54, 21. Mär 2019 (CET)
Danke fürs Verschieben Klenzy und danke euch auch, dass der Vorschlag so positiv aufgenommen wird. Das ist ja noch viel einfacher als ich dachte. Verstehe ich das richtig, mit dieser Einstellung wird dann bei Mouseover über z.B PR1801 die Vorschau zu Die Herreach angezeigt? Und wo müsste dann die maximal 280 Zeichen lange Kurzfassung (der Exzerpt) des Romans platziert sein? In Quelle:PR1801 oder im weitergeleiteten Artikel Die_Herreach? Ger77 (Diskussion) 20:11, 21. Mär 2019 (CET)
So wie in deinem Beispiel, nur ohne Änderung des Quellenlinks - probier's aus! (Mit deiner Benutzerseite müsstest Du Namensraum "2" nehmen statt "100"). --Klenzy (Diskussion) 20:16, 21. Mär 2019 (CET)
Danke für den Tipp. common.js für mich angelegt, die Kurzfassung beim Romanartikel eingefügt. Das funktioniert prächtig :) So jetzt kommt die echte Arbeit. 3000 Kurzfassungen erstellen und einfügen ***schwitz*** ;) Ger77 (Diskussion)
Das war jetzt der erste, einfache Teil der Abstimmung. Bevor Du voller Enthusiasmus loslegst, möchte ich ein paar weitere Stimmen hören, ob wir die Handlungszusammenfassungen wie vorgeschlagen erweitern. Ich finde den Vorschlag grundsätzlich gut, und es gibt oben schon einigen Zuspruch. Zwei Dinge sind zu bedenken. Erstens, das ist bei den HZF ein Bruch mit der bisherigen Darstellung - es gibt Text oberhalb der Überschrift. (Das muss für die Seitenvorschau so sein, alles nach der ersten Überschrift wird nicht berücksichtigt, und dieses Verhalten lässt sich auch nicht beeinflussen.)
Zweitens, es gibt jetzt bereits HZF mit einer kurzen und einer langen Fassung, z. B. PR 8 und in späteren Zyklen viele, viele mehr. In so einem Fall hätten wir dann zukünftig drei Fassungen, Vorschau, kurz und lang.
Ich bitte das nicht als Gegenstimme zu verstehen. Möchte nur vermeiden, dass Du übereifrig losrennst und es - vielleicht - hinterher Kritik und Streit gibt. Mein Vorschlag für's weitere Vorgehen: Lass diese Diskussion noch eine Woche laufen. Es gibt Leute, die gucken nicht jeden Tag hier vorbei, aber auch die sollen eine fair Chance haben, gehört zu werden. Kommen dann keine Gegenstimmen, dann leg mal los für, sagen wir, einen 50er- oder meinetwegen 100er-Zyklus. Danach lass uns das nochmal begutachten und ein paar Tage darüber reden ... denn ja: Da hast Du dir gewaltig was vorgenommen! --Klenzy (Diskussion) 21:01, 21. Mär 2019 (CET)
Ich habe absichtlich einen Zwinker-Smilie angehängt, weil mir klar ist, dasss es hier noch weiteren Diskussionsbedarf bzw. Abstimmungsbedarf gibt. Daher habe ich nur für die zwei Romane PR1800, PR1801 die Zusammenfassung eingefügt. Damit man sich ein Bild machen kann, wie das gemeint war von mir. Klarerweise warte ich jetzt ab bzw. lege diese Exzerpte in meinem Namensraum ab, bis ein Entscheidung hier getroffen wurde. Ger77 (Diskussion) 21:29, 21. Mär 2019 (CET)
Zum Punkt "HZF mit einer kurzen und einer langen Fassung" . Hier könnte man pragmatisch die Überschrift "Kurzzusammenfassung" im HZF entfernen. Damit wird dann zwar nur der ein Teil dieses Textes in der Vorschau sichtbar, aber damit wäre der Dritte vermeidbar. Ger77 (Diskussion) 21:50, 21. Mär 2019 (CET)
Ich glaube, die nachhaltigste Lösung wäre, dann die Kurzzusammenfassung als Vorschau verwendbar zu machen. Angefasst werden müssen die Romanseiten ja eh, aber so wird vermieden, dass es drei verschiedene Versionen gibt. --Aki 23:00, 21. Mär 2019 (CET)
Ich finde Akis Vorschlag am sinnvollsten. Ich fände drei Fassungen jetzt auch nicht so prickelnd. Dann lieber die schon vorhandenen Kurzzusammenfassungen nehmen und die Überschriften entfernen, so dass denn die allgemeine Zustimmung fände und ich das richtig verstanden habe. --Pisanelli (Diskussion) 09:23, 22. Mär 2019 (CET)
Noch was. Mit einer kleinen Erweiterung kann man die (theoretische) dritte, nur für die Vorschau gedachte Zusammenfassung in der normalen Seitenansicht verschwinden lassen. Das geht mit HTML und CSS. Die neue Vorschauzusammenfassung muss dazu in ein <span style="display:none;"> blabla </span> gepackt werden. Siehe hier [7] und hier [8]. Vorteile: Die bisherige Optik der HZF bleibt erhalten; die Vorschauzusammenfassung kann passend zum Vorschaufenster extrem kurz gefasst werden so wie von Ger77 anfangs geplant. Nachteil: Beim Bearbeiten sind es dann immer noch drei Zusammenfassungen.
Leider geht das nicht per Vorlage, da Vorlageninhalte nie für das Vorschaufenster berücksichtigt werden.
Wir können natürlich auch wie von Aki und Pisanelli angedacht die Überschrift "Kurzzusammenfassung" herauskegeln. Vorteil: Für sehr viele HZF wäre dann sofort Text sichtbar. Nachteile: Die Kurzzusammenfassung ist normalerweise viel zu lang für die Vorschau; die fehlende Überschrift irritiert.
Alle erwähnten Vor-/Nachteile beider Varianten werden wohl von jedem individuell unterschiedlich gewichtet. Was mich betrifft, bin ich bisher völlig unschlüssig. Vielleicht gibt es auch noch andere tolle Ideen? @alle? --Klenzy (Diskussion) 11:35, 22. Mär 2019 (CET)
Nein, display:none-Zeug ist ganz böse. Lasst euch da von einer gesagt sein, die täglich mit SEO-Optimierungen, Webseiten-Pflege und ähnlichem zu tun hat. Wenn du Texte ausblendest, sehen die Leute nicht mehr, wo es Verbesserungsbedarf gibt. Suchmaschinen wittern Tricks und werten die Seite ab. Und zuletzt schwindet auch das Vertrauen, wenn Leute einen Inhalt beisteuern und der plötzlich „unsichtbar“ wird. Welche Lösung auch immer, aber bitte kein display:none. --Aki 02:24, 23. Mär 2019 (CET)
Starke Einwände. Lass uns mal sehen ...
Also, was die Suchmaschinen betrifft, deren Ranking für unsere Seiten ist mir ... sagen wir, sekundär relevant. Bedeutend wichtiger ist alles, was die Leser/Nutzer/Mitarbeiter betrifft.
Mit dem display:none ist der Text nur in der normalen Seitenansicht ausgeblendet. Die Idee dahinter ist, dass sich an der bisherigen Optik nichts ändert, falls jemand Probleme damit hätte (wobei ich bisher der Einzige bin, der solche Bedenken geäußert hat; aber die Beteiligung an dieser Diskussion ist bisher ja noch sehr überschaubar). In der Seitenvorschau sieht man den Text sehr wohl. Es ist ein sehr kurzer Text, ein, zwei Sätze. Da mag es ein paar mal Verbesserungsbedarf geben, aber irgendwann ist der Text stabil. Wer sich also für die Vorschau-HZF interessiert, wird die Texte also sehen und bei Bedarf auch korrigieren und für die anderen, die das nicht interessiert, ist es folglich auch nicht schlimm, nichts zu sehen.
Das letzte Argument verstehe ich nicht. Es wird nichts verschwinden, was irgend jemand beigesteuert hat. Derjenige, der diese Vorschau-HZF verfasst, weiß um die Bedeutung des display:none und verwendet es gezielt. Wer eine HZF aus einem anderen Grund bearbeitet, wird höchstens überrascht über den zusätzlichen Text sein; nun ist aber display:none schon ziemlich selbsterklärend. --Klenzy (Diskussion) 14:22, 23. Mär 2019 (CET)
PS. "Veto" war, nehme ich an, ein Späßle. Wenn es per Diskussion keine Einigung gibt, wäre das nach langer Zeit wieder ein Fall für ein Meinungsbild. Aber Vetos gibt's hier nicht. --Klenzy (Diskussion) 14:22, 23. Mär 2019 (CET)
Wie wäre es, wenn ich nur bei den HZF die schon eine Kurzzusammenfassung haben, mit dem nodisplay einen Exzerpt hinzufüge? Damit wird bei den meisten Romanen dieser angezeigt und bei denen die drei hätten, aber nur die bisherige Seite. Ich habe das als Beispiel mal bei Quelle:PR8 gemacht, der Exzerpt ist im Artikel unsichtbar. Bei Quelle:PR1801 dagegen ist der Exzerpt sichtbar. Ger77 (Diskussion) 12:26, 22. Mär 2019 (CET)
Fasse mal meine Gedanken zusammen, sorry, falls Wiederholung zu bereits gesagtem. :-)
Was ist der Nutzen?
O.k., wenn ich über den Link gehe mit der Maus (mobile browser sind damit schon mal außen vor?) sehe ich eine Vorschau.
Hm, ich kann mir Szenarien vorstellen, wo das cool ist. Für mich persönlich registriert das aber auch wirklich nur als nice-to-have feature (womit ich anderen nicht absprechen will, dass sie das als echten Nutzen sehen; nur eine Nutzerstimme unter vielen).
Sind die bestehenden Kurzzusammenfassungen geeignet, um diesen Nutzen zu erzeugen?
Glaube nicht. Selbst bin ich jemand, der gerne Kurzfassungen schrieb (z.B. Quelle:PR655 vorwärts). Als Leser fand ich immer gut je nachdem wie ich gerade lustig war, mir schnell eine Zusammenfassung reinziehen zu können, oder halt mehr Details nachzulesen. Als Schreiber habe ich daher immer erst eine Langfassung und dann eine (teils echt schwer, was streicht man, was nicht; wie komprimiert man, ohne Sinn zu verändern) Kurzfassung daraus abgeleitet. Seinerzeit übrigens umstritten, da einige nur Interesse an dem langen hatten und nicht wollten, dass noch was anderes bei uns steht.
Die Texte sind aber länger als 280 Zeichen. Sie sind so gefasst, dass sie eine Einheit bilden. Einfach die ersten 280-Zeichen bringen denke ich nicht den gewünschten Effekt.
Die Kurzzusammenfassungen zu kürzen (nicht nur aber ich gebe zu auch, weil ich da in einige Mühe gesteckt habe, will da gar nicht versuchen vorzugeben einfach nur mit Leser-Stimme zu sprechen ;-) ) fände ich dann aber auch uncool. Aber auch von dem egoistischen (habe teils selbst geschrieben) abgesehen: So als Leser fand ich "meist ungefähr so lang wie Info-Kasten rechts" eine gute Länge.
Noch einen Teaser vorne dran stellen. Quasi eine von uns geschriebener Untertitel?
Etwas länger als der Untertitel und aufgrund der dahinter stehenden Absicht eher Zusammenfassung/Teaser, als der echte Untertitel in vielen Fällen...
Kann ich mir vorstellen. Sieht für mich aber schon etwas verloren aus, so vor der ersten Überschrift.
Nodisplay/Exzerpt?
Klar, sofort: Am angezeigten Artikel ändert sich nix. Die Arbeit wird von Leuten gemacht, die die Arbeit machen wollen.
Was könnte man dagegen haben?
Fällt mir spontan zu ein, dass die exzerpts zu einem großen Teil inhaltlich falsch sein werden. ;-)
Erfahrung (wie oben geschildert): Einen Text komprimieren kann leicht zu einer - natürlich unbeabsichtigten - Verfälschung des Sinns führen. Je mehr komprimiert, desto höher das Risiko. Hat man den Roman gerade gelesen, sinkt das Risiko. Hat man das nicht und bezieht sich noch dazu auf eine (Lang-)Zusammenfassung, die vielleicht eh schon auf mehr als eine Weise interpretiert werden kann oder kleinere Fehler enthält, steigt das Risiko enorm.
Wo liegt meine Stimme?
Wenn Ger77 die Nodisplay/Exzerpt-Sache machen will, dann unterstütze ich das mit meiner Stimme. Wenig was wir hier machen ist perfekt. Alles hat seine pro & cons. Und mei, wenn einer von uns daran Freude hat, denke ich soll er machen (und Qualitätssicherung ist wie immer halt dann ein iteratives Geschäft). --NAN (Diskussion|Beiträge) 16:08, 22. Mär 2019 (CET)
Da es mir um den Spaß an das Sache geht und nicht um Ruhm zu ernten, es mein persönliches Freizeitvergnügen sein soll, ist es akzeptiert, wenn die Exzerpte nicht auf den Seiten aufscheinen. Ich würde also, wenn das okay ist, beginnen diese einzupflegen wo es mir gerade in den Sinn kommt. Der Vorteil des nodisplay ist sicher auch dass, weil ich naturgemäß nicht alle Seiten auf einmal pflegen kann, dass nur in der Vorschau dies auffallen würde. Vielleicht spendiert mir Klenzy(?) dann irgendwann einmal einen Button, mit dem ich nodisplay mit einem Klick einfügen kann :) und wenn dann diese Mini-Zusammenfassungen doch gewünscht werden, braucht man nur das NoDisplay entfernen.
Zu den Kurzfassungen die schon da sind. Hier ist eine schon bestehende in Quelle:PR682 die 172 Zeichen hat. Damit ist diese sogar kürzer als die ich machen würde :D Daher ist das NoDisplay für alle am sinnvollsten, weil damit all diese Klippen umschifft werden. Eventuell ist es sogar sinnvoll diese bestehenden Minis in NoDisplay zu packen? Ger77 (Diskussion) 21:38, 22. Mär 2019 (CET)
Gut fände ich es, wenn die Vorschaufunktion für Quellen zunächst einmal für alle freigeschaltet wird, damit auch jeder den aktuellen Zustand bewerten kann.
Ich selbst nutze die Funktion schon seit einiger Zeit mittels persönlicher Einstellungen. Zwar wird aktuell lediglich das Cover der Quelle angezeigt, aber das hat mir stets ausgereicht. Vielleicht geht es dabei ja nicht nur mir so?! --JoKaene 09:13, 23. Mär 2019 (CET)
Ich habe die Vorschaufunktion für Quellen jetzt für alle Benutzer freigeschaltet.
Wer das nicht haben möchte, kann dafür aber umgekehrt mit einem mw.config.set('wgContentNamespaces', [0]); im privaten "Common.js" die Vorschau für Quellen wieder abschalten. --Klenzy (Diskussion) 11:24, 23. Mär 2019 (CET)
Ich bin vielleicht das andere Extrem, aber ich gehöre zu den paar Hanseln, die JavaScript prinzipiell abgeschaltet haben. Ich halte die Idee aber für gut. Wenn wir schon zwei Inhaltsangaben haben, dann können wir die kürzere auch auf die maximale Länge für den Vorschautext eindampfen, das dürfte schneller zu machen sein als eine Neue zu schreiben. -ok- -Thinman (Diskussion) 17:37, 23. Mär 2019 (CET)
Auch OK. Ich warte mit weiteren Exzerpten gern bis zum Abschluss der Meinungsbildes. Und falls das die Mehrheitsmeinung ist, dampfe ich gern auch die bestehenden Kurzzusamenfassungen auf ein Exzerpt ein. Ger77 (Diskussion) 22:46, 23. Mär 2019 (CET)
P.S: unterschiedliche Texte mit Wörtern verschiedener Längen lösen offenbar verschiedene Vorschauen aus. Siehe die unterschiedlichen Ansichten bei 1800 bis 1803 (zwischen 230 und 260 Zeichen) zu denen im Testwiki (immer 252 Zeichen) und das extrem kurze bei 1804 (187 Zeichen - https://test.perrypedia.proc.org/wiki/Kampf_ums_%C3%9Cberleben) Es sind immer 8 Zeilen. Es ist also gut kurze Wörter zu nutzen. Ger77 (Diskussion) 22:40, 23. Mär 2019 (CET)
Ich war einige Tage verhindert, deshalb mein Kommentar hierzu erst jetzt.
1.) Für mich ist es auch ein "nice-to-have" und man sollte nicht weil es sehr schön jetzt, alles hektisch ummodeln. Lieber ein bißchen sich Zeit lassen für eine gute Lösung.
2.) Mir fällt auf, dass z.B. bei PR-Neo 151 ein Tibi mit hochkommt, bei Neo 151 aber nicht. Warum? (sieht nach einem anderem Problem aus, könnte aber auch bei den PR-HZF sowie anderen auftreten)
3.) Bei fast alle Neo Artikel hat sich Klenzy die Mühe gemacht, mit <ppdict> gekennzeichnete Absätze an den Anfang zu stellen. Wenn man jetzt den Aufwand betreibt Vorschautexte zu gestallten, dann sollte man diese auch gleich mit <ppdict> kennzeichnen! Oder?
4.) Mich würde es z.B. nicht stören, wenn die jetzigen Kurzzusammenfaßungen ungekürzt zu Vorschautexten werden. Oder hab ich da was noch nicht richtig verstanden?
--Norman (Diskussion) 23:15, 24. Mär 2019 (CET)
@Ger77: Da ich im Testwiki verschiedene Versionen der Extensions (Popups und TextExtracts) ausprobiert habe, war der Stand der Software abweichend vom Echtwiki. Jetzt müsste ..es wieder übereinstimmen.
@Norman: 1. Völlig richtig. Wir sind noch in der Phase des Diskutierens, aber auch des Experimentierens. Alles, was wir gerade probieren, kann jederzeit wieder gekippt werden.
2. Wie die Vorschau (Popups-Extension) das Bild auswählt, ist ein Algorithmus, den wir nicht beeinflussen können. Eine Supportanfrage meinerseits für mehr Details wurde bisher nicht beantwortet (... das sind alles Freiwillige, wie wir hier). Bekannt ist nur, dass es etwas mit dem Bildformat zu tun hat. Ich schau mir das mal an.
3. Nein, das sind völlig unterschiedliche Dinge. <ppdict> ist für die Wörterbucheinträge der "richtigen" (nicht HZF) Artikel, und (wie richtig erkannt) zzt. nur Neo. Hier geht es ausschließlich um HZF, und dabei vorrangig um die PR-Heftserie.
4. Das ist eine der Varianten, die nach wie vor im Raum stehen. Kann man machen. Die Nachteile dabei sind, dass wir erstens die Überschrift "Kurzzusammenfassung" rauswerfen müssten (kein Problem per Bot, aber ganz anderes Aussehen der HZF zukünftig); zweitens ist der Vorschautext begrenzt und weder beeinflussbar (wie die Bildauswahl), noch kann man scrollen. Der Nutzen, die ersten vier fünf Zeilen der heutigen Kurz-HZF zu sehen, ist geringer als die von Ger77 angestrebte superkurze Vorschau-HZF.
Gerade zum letzten Argument gibt es aber sogleich das Gegenargument, dass die Vorschau bei einem "normalen" Artikel ja auch nur den Anfang liefert, warum also nicht bei HZF?
Die Diskussion läuft noch, das Ergebnis ist noch offen. Im Moment meine ich eine leichte Mehrheit zu erkennen für "Kurz-HZF in der Vorschau verwenden". --Klenzy (Diskussion) 09:05, 25. Mär 2019 (CET)
@Klenzy: (Off-Topic) mir ist klar dass <ppdict> ein komplett anderes Thema ist und zuerst einmal nicht vermischt werden sollte mit den Vorschautexteten. Aber ich stelle mal - eine vielleicht ketzerische - Frage: Warum sind/müssen HZF von den Wörterbucheinträgen ausgeschlossen sein? Beides zusammen (Vorschautext & ppdict funktioniert doch gut zusammen). Oder habe ich etwas grundsätzliches übersehen? (diese Diskussion hier vielleicht besser auslagern). --Norman (Diskussion) 11:10, 25. Mär 2019 (CET)
zu 4.) Ich hätte kein Probleme damit nur die ersten 8 Zeilen eines Vorschautextes zu sehen (wie schon erwähnt, so ist es bei anderen Artikel ja auch) --Norman (Diskussion) 11:10, 25. Mär 2019 (CET)
Wie geht es jetzt weiter? Soll ich beginnen und erstmal nur mit NoDisply die Exzerpte einfügen? Oder noch warten? --Ger77 (Diskussion) 20:21, 29. Mär 2019 (CET)
Wenn ich die Diskussion bis hierher zusammenfasse:
  • Aki, Pisanelli und Norman würden die bestehenden Kurz-HZF als Vorschau verwendbar machen. Im Klartext: die Überschrift "Kurzzusammenfassung" entfernen.
  • Thinman würde vorhandene Kurz-HZF verwenden und wo nötig kürzen.
  • Ger77, NAN und ich könnten uns eine dritte Vorschau-HZF mit display:none vorstellen.
  • NAN hätte lieber die dritte Vorschau-HZF, als die bestehenden Kurz-HZF zu verwenden (oder sie womöglich zu kürzen).
  • Aki will auf keinen Fall display:none.
  • Johannes und JoKaene begrüßen die Idee des Vorschautextes, haben sich aber zum "wie" bisher nicht geäußert. Jo mit einer leichten Tendenz zu "Cover reicht, Text unnötig".
Habe ich jemand vergessen oder falsch einsortiert? Dann bitte rasch melden!
Das Votum ist zwar nicht ganz so eindeutig wie gehofft, aber ein Meinungsbild dürfte nicht notwendig sein. Ich zähle hier eine Mehrheit 4:3 dafür, die vorhandenen Kurz-HZF für die Vorschau zu verwenden. Wo vorhanden, wird die Überschrift "Kurzzusammenfassung" entfernt; keine Kürzung auf Anzeigelimit (davon würde ich auch abraten, da sich so etwas jederzeit in einer neuen Softwareversion ändern könnte); wo nicht vorhanden, wird eine neue Kurz-HZF ohne Überschrift erstellt.
Ich würde jetzt noch zwei Tage abwarten für eventuelle letzte Einwände - das soll's dann sein. --Klenzy (Diskussion) 21:02, 29. Mär 2019 (CET)
Bestätige noch einmal: Ja, mir reicht das bloße Coverbild. Aber ich bin auch skeptisch! Wofür braucht es an dieser Stelle eigentlich erläuternden Text? Bei allgemeinen Artikeln ist die Vorschaufunktion extrem hilfreich und erspart viele Clicks. Bei einer Quelle jedoch will ich entweder lediglich wissen, um welche Publikation es sich handelt, was ich bereits jetzt erkennen kann, oder ich will Näheres zum Inhalt – dann muss ich aber sowieso auf den Link clicken, und einen Vorschautext hätte ich nicht gebraucht. Für mich finde ich kein Argument, das diesen enormen Arbeitsaufwand (Tausende Quellen!) rechtfertigen würde. Zumal der Vorschautext aufgrund seiner Kürze kaum mehr Wert als eine Werbebotschaft hat.
Auch bei der Umsetzung sehe ich Probleme: Die Überschrift »Kurzzusammenfassung« wegzulassen bedeutet mir einen zu großen Eingriff in das Design der Quellenseiten. Sie verlieren an Eindeutigkeit. Zumindest Neunutzer könnten in dem Fall ebenso irritiert sein wie selbst ich es wäre, wenn offen eine weitere (Kurz-)Kurzusammenfassung eingefügt wird. Für mich (Entschuldigung) reinster Nonsens. Wenn technisch nichts dagegen spricht, sind in Quellenartikel eingefügte »unsichtbare« Texte also wohl die gangbare Lösung?! Aber wie schon angemerkt: Enormer Arbeitsaufwand, und bislang gibt es nur einen (Mit)Arbeiter, der das auf sich nehmen will!
Irgendwie erscheint mir das alles noch zu unausgegoren, als hätten wir die richtige Lösung noch nicht gefunden. Ich komme deshalb nicht umhin, mich – wenn auch als einsamer Rufer – gegen eine Umsetzung auszusprechen! --JoKaene 14:15, 31. Mär 2019 (CEST)
Meine Motivation warum ich für Vorschautexte bei den Quellenlinks, die Hefthandlung in minimalistischer Weise zusammenfassen. Bei den Handlungsebenen wäre durch den Vorschautext nachlesbar wie der Handlungsstrang verlaufen ist. Ebenso bei den Auflistungen der Hefte die zu einem Zyklus vorhanden sind. Und schlussendlich auch überall wo eine Heftquelle angegeben ist man nicht weiß was genau dahinter ist. Vorschaubild alleine ist nur bedingt brauchbar, weil es oft zu abgeschnitten wird und man so nicht mehr erkennen kann welchen Titel es getragen hat bzw. der Untertitel nicht lesbar ist. Ich möchte ja den Titel jeweils in den Vorschautext einarbeiten, soweit es passt. Beispiel: Quelle:PR1800 oder Quelle:PR1801. Und ja, die Arbeit wird im Moment nur von mir gemacht, aber soweit ich weiß hat die Perrypedia auch mit einer Person begonnen. Einfachsten ist es wenn ich alles mit noDisplay mache, bei Bedarf kann man dann wieder sichtbar machen und für die Vorschau reicht es :) --Ger77 (Diskussion) 18:08, 31. Mär 2019 (CEST)
Habe jetzt bei den Romanen 3000 bis 3008 den nodisplay Vorschautext eingefügt. Da ich diese Romane des neuen Zyklus alle lese, glaube ich den Text gut hinzukriegen. Das Argument dass man aus der vorhandenen Zusammenfassung keinen sehr guten Exzerpt erstellen kann, konnte an einem Beispiel (3007) selbst nachvollziehen. Daher werde ich nur für Romane die ich selbst gelesen habe, einen Exzerpt machen. --Ger77 (Diskussion) 13:25, 16. Apr. 2019 (CEST)
Ich entferne jetzt das nodisplay bei allen Exzerpten ab 3000. Da es bei zwei irrtümlich passiert ist und sich niemand daran gestoßen hat, denke ich das ist OK so. Mit dieser Änderung haben dann auch die Leute die Mobilgeräte haben den Text sobald sie auf den Link des Romans klicken:) bei den Teasertexten die ich für die Vorschauen vor 3000 mache, lasse ich das No Display --Ger77 (Diskussion) 23:25, 4. Jun. 2019 (CEST)

VisualEditor

Ich habe im Testwiki (https://test.perrypedia.proc.org/wiki/Hauptseite) probeweise den VisualEditor (VE) installiert. Ihr könnt nach Herzenslust ausprobieren. Der VE ist bei den Wiki-Nutzern teils heftig umstritten, ähnlich den Strukturierten Diskussionen, ist aber in vielen Wikis eingesetzt oder zumindest installiert. Der augenscheinlichste Unterschied ist die Wahlfreiheit: jeder Benutzer kann in seinen Einstellungen festlegen, ob er den VE angeboten bekommt (und wenn ja, kann man trotzdem jeden Edit mit oder ohne VE machen) oder ob er komplett ausgeblendet wird. Groß befasst habe ich mich mit dem Teil noch nicht, es scheint zumindest einige Mucken zu haben. Das sollt ihr euch aber unvorbelastet ansehen. --Klenzy (Diskussion) 16:57, 3. Mär 2019 (CET)

Oh, das dürfte die Hemmschwelle bei vielen erheblich verringern, Inhalte oder Ergänzungen beizutragen. Muss damit aber auch noch mal ausführlicher herumspielen. --Aki 12:58, 21. Mär 2019 (CET)
Das war mein Hintergedanke: die Hürden zum Mitmachen zu verringern. Das war auch der Grund, warum der VE entstanden ist. Inzwischen habe ich herausgefunden, dass innerhalb der WMF (Wikimedia Foundation) zwischen Entwicklern und Anwendern ein heftiger Richtungsstreit geführt wird, der unter anderem den VE betrifft. Angeblich wird das Ding weiterentwickelt, aber man hat mir klar zu verstehen gegeben, dass der Einsatz des VE für private Wikis (außerhalb der WMF) rein "experimentell" ist und es somit für uns keinen Support gibt, außer wenn jemand gerade zufällig Zeit hat. --Klenzy (Diskussion) 08:43, 25. Mär 2019 (CET)

Noexcerpt

Mithilfe der Mediawiki-Extensions ([9] und [10]) blenden wir zu den Hyperlinks ein kleines Vorschaufenster ein, mit dem Beginn des Artikeltextes und ggf. einem Bild. Seit dem Softwareupgrade erscheinen dort auch Anmerkungstexte (Anmerkungen vor der ersten Überschrift), was unerwünscht ist und früher von der Software automatisch bereinigt wurde. Nunmehr ist es dafür nötig, manuell ein HTML-Element <span class="noexcerpt"> anzugeben, Beispiel: https://www.perrypedia.proc.org/mediawiki/index.php?title=Interkosmo&type=revision&diff=1480969&oldid=1479388.
Das ist nicht sehr aufwendig und funktioniert erst mal. Die Frage ist, wie wir mit diesen Anmerkungen im Einleitungsabschnitt zukünftig umgehen wollen. Da sind völlig verschiedene Ansätze denkbar:

  • Solche Anmerkungen vermeiden und grundsätzlich nach weiter unten im Artikel verschieben.
  • Die manuelle Methode "noexcerpt" beibehalten.
  • Eine eigene Vorlage für Anmerkungen basteln, in der das noexcerpt dann automatisch enthalten ist.

Was meint ihr? --Klenzy (Diskussion) 15:44, 25. Feb. 2019 (CET)

Wir haben recht oft Anmerkungen an dieser Stelle, oder? --Johannes Kreis (Diskussion) 06:56, 26. Feb. 2019 (CET)
Aktuell habe ich 190 Artikel, bei denen die Anmerkung an dieser Stelle stand, im Popup-Fenster aufgetaucht ist und daher von mir manuell mit "noexcerpt" geschützt wurde.
Die Zahl erschreckt mich - hätte nicht gedacht, dass es so viele sind. Zudem glaube ich, dass es noch sehr viel mehr solche Fälle gibt, da ich mich fast ausschließlich um Begriffe aus dem Zyklus "Gänger des Netzes" gekümmert habe. --Klenzy (Diskussion) 09:36, 26. Feb. 2019 (CET)
Das sind vermutlich Anmerkungen zum Lemma, d.h. Realweltvorbilder für Namen und dergleichen. --Johannes Kreis (Diskussion) 11:09, 26. Feb. 2019 (CET)
Realweltbezüge; offene Fragen (Geschlecht, Volkszugehörigkeit, unterschiedliche Entfernungsangaben, echt oder fiktiv ...); Druckfehler und alternative Schreibweisen (oft); "mehr wissen wir nicht" uvm. Fast immer bezieht sich die Anmerkung unmittelbar auf das Lemma. Nach unten verschieben wäre möglich, aber dann müssten die jeweiligen Anmerkungen umformuliert werden. --Klenzy (Diskussion) 11:29, 26. Feb. 2019 (CET)
Ich vermute, wenn wir sie so Anmerkungen an früher Stelle haben, dann weil das gut da hin passt.
Prinzipiell setzen wir Anmerkungen ja an den Stellen im Text, zu denen sie Bezug haben. DA eine zusätzlich Regel "wegen Extension anders machen" fände ich uncool.
Die HTML-Sache ist natürlich auch nicht schön, aber finde o.k. --NAN (Diskussion|Beiträge) 19:43, 26. Feb. 2019 (CET)

Nicht Kanon

Nach Anregungen von Norman und NAN möchte ich hier [11] verdeutlichen, was "Nicht Kanon" für uns bedeutet. --Klenzy (Diskussion) 16:17, 22. Feb. 2019 (CET)

Einverstanden. --Johannes Kreis (Diskussion) 06:56, 26. Feb. 2019 (CET)
Sehe ich jetzt erst. Finde ich gut. --Pisanelli (Diskussion) 07:42, 26. Feb. 2019 (CET)
Was mir noch auffällt, das nirgendwo erklärt wird (in Prosa), warum etwas Kanon ist oder warum nicht. Also quasi die grundsätzliche Definition von Kanon. Scheint mir mal einen Gedanken und ein paar Sätze wert zu sein, denn da gibt es ja immer wieder Verständnisschwierigkeiten oder Diskussionsbedarf, oder? --Pisanelli (Diskussion) 07:46, 26. Feb. 2019 (CET)
Ein Gedanke dazu meinerseits, ich hab mal vor einiger Zeit (als ich noch relativ neu war) im Forum die Frage zu den Atlan Blaubänden gestellt, vielleicht kann das ja auch als Referenz in den Text oder wie von Pisanelli gefragt prosaisch dargestellt werden? --Soulprayer (Diskussion) 08:29, 26. Feb. 2019 (CET)
Kurzer Nachtrag: Warum wird in der Liste die Jupiter-Miniserie als nicht zum Kanon gehörend ausgeschlossen? Mit der Veröffentlichung wird doch das Buch "Jupiter" mit der Miniserie "überschrieben", oder was ist der Gedanke dabei? --Soulprayer (Diskussion) 08:34, 26. Feb. 2019 (CET)
@Pisanelli: Es steht schon da, was Du meinst; einmal der Link auf WP:Kanonisch (= "den Regeln entsprechend") und zum anderen der Absatz "Widersprüche in den Texten". Man muss aber mehr als zweimal hingucken, um deine Frage beantworten zu können.
@Soulprayer: Es besteht ein grundsätzlicher Unterschied zwischen "Kanon für die Autoren" und "Kanon für die Perrypedia". Für die Redaktion gelten die Blaubände als verbesserte Neuausgabe und damit höherwertig als die Hefte. Bei uns ist die Reihenfolge anders herum. Daher hilft uns der Link auf den betreffenden Post im Forum nicht weiter (... ist aber immerhin hiermit auf dieser Diskussionsseite dokumentiert).
Jupiter ist nicht ausgeschlossen, weder als Buch noch als Miniserie. Das geht wie folgt: Als Primärquelle gelten die Miniserien ohne Jupiter. Dafür gilt der Jupiter-Einzelroman als Primärquelle, versteckt unter "Neue Perry Rhodan-Taschenbuchserien". Der Einzelroman ist die Erstausgabe. Die Miniserie ist die Nachbearbeitung und folglich unter "Primärquelle eingeschränkt" einsortiert. --Klenzy (Diskussion) 09:30, 26. Feb. 2019 (CET)
Ich bin mir nicht sicher, ob ich das mit Jupiter richtig verstehe. Jupiter ist Kanon der Perry-Rhodan-Taschenbuchserie? Ich wusste nicht, dass es den gibt. Jupiter in Heftform ist zu erst erschienen und ist nach meinem bisherigen Verständnis zu 100% Kanon für das Perry-Rhodan-Classic-Universum. Jupiter in Buchform ist sekundär, es später erschienen ist und vermutlich überarbeitet wurde. --Poldi (Diskussion) 09:46, 26. Feb. 2019 (CET)
Habe ich vielleicht unglücklich ausgedrückt. Es gibt keinen separaten Kanon der Perry-Rhodan-Taschenbuchserie. In unserem Kanon steht das Taschenbuch zuerst (erschienen 2011), die Miniserie ist die später erschienene und um zusätzliche Handlung erweiterte Neuausgabe (2016), also gerade umgekehrt wie von dir angenommen. --Klenzy (Diskussion) 09:53, 26. Feb. 2019 (CET)
Um auf eine Fragestellung etwas weiter oben einzugehen:
Meiner Meinung nach bedeutet "Kanon" in unserem Kontext lediglich, welche Quellen wir für unsere Artikel verwenden/zulassen und welche Gruppen darin wir als höher/niederwertiger betrachten. Letzteres hat keine Bedeutung, solange keine Widersprüche. Solange in einer der "erlaubten" Quellen kann es in den Artikel. Falls Widersprüche entscheidet es lediglich, was kursiv als Anmerkung geschrieben wird und was im "normalen" Fließtext verarbeitet wird.
Möglich, dass man die Sache auch anders beschreiben kann, aber rein praktisch ist es nicht mehr als das.
Die Festlegung kommt "von uns" (bzw. den Leuten, die hier mit dem Wiki begonnen haben). Alles in allem in sich logisch/einleuchtend. Aber nix, was irgendwie eine "absolute Wahrheit" darstellt. Einfach eine Rahmen-Vereinbarung, die uns erlaubt Artikel zu schreiben, ohne, dass z.B. ein edit-war darüber entsteht, was kursiv ist oder Fließtext.
Wahrscheinlich könnte man auch vernünftig etwas anders machen (z.B. Verbesserungen in Nachauflagen als höherwertig sehen, als das Original, sind ja Verbesserungen; wäre genau umgekehrt, wie wir das machen). Aber es macht halt keinen Sinn eine in sich schlüssige Regelung (Kanon) durch eine andere ebenfalls in sich schlüssige Regelung (Kanon) zu ersetzen. Schafft keinen Wert, insbesondere wenn man bedenkt, dass inhaltlich ohnehin alles gleich bleibt, sich nur ändert, was kursiv und was nicht.
Die einzige weitere Verkomplizierung kommt daher, dass wir verschiedene Arten von Artikel im Wiki haben. Recht klar dürften "Neo-Artikel" "Classic-Artikel" sein. Weitere Arten sind dann so Sachen wie die Realwelt-Artikel oder Handlungszusammenfassung-zu-Comic-Artikel, etc.
Haben alle ihren eigenen Kanon. Genauer gesagt: Wir haben festgelegt, was wir jeweils in welcher "Reihenfolge" als Quellen verwenden und das schöne Wort "Kanon" verwendet.
Aus diesem meinen Blickwinkel heraus begrüße ich die Bemühungen von Klenzy, den Hilfe-Artikel etwas verständlicher zu formulieren. :-) --NAN (Diskussion|Beiträge) 19:59, 26. Feb. 2019 (CET)
Was soll ich sagen. Besser kann man es nicht beschreiben :–) Oft wird Kanon mit "gehört nicht in die Perrypedia" übersetzt und das stimmt sich so nicht. Ein Lemma Perry Rhodan (PRIB) mit den Quellen PRIB kann es sehr wohl hier geben. Sogar Perry Rhodan (DORGON) mit den Quellen der Dorgon-Hefte aus dem Fandom wäre formal denkbar. --Poldi (Diskussion) 20:23, 26. Feb. 2019 (CET)
Ist doch immer die Frage, in welchem Kontext zu dich bewegst. In Memory Alpha etwa stehen auch Sekundärquellen wie Romane mit drin, nur halt entsprechend gekennzeichnet. Ich denke, dagegen spricht nicht. Wäre sogar möglich, das optisch abzuheben. Und was die „großen“ Themen wie PR-Heftserie, NEO, ATLAN oder so etwas betrifft, ergibt sich das ja bereits aus den Kategorien. --Aki 22:51, 27. Feb. 2019 (CET)
Was ist Memory Alpha? --Klenzy (Diskussion) 08:44, 28. Feb. 2019 (CET)
Das ist ein Star Trek Fanwiki. --Johannes Kreis (Diskussion) 09:20, 28. Feb. 2019 (CET)
Bin jetzt endlich weit genug im „Eschbach“. Der Roman ist aus Sicht von Homer G. Adams geschrieben, der die Handlung aus Erinnerungen rekonstruiert. Durch dieses raffinierte Konstrukt hat Eschbach sich quasi selbst aus dem Kanon entfernt. Darauf musst du erst mal kommen. ;)
Dennoch sind die Details ja erwähnenswert, da er sich auf Fragmente in unterschiedlichen Romanen bezieht, wo Rhodan über seine Vergangenheit berichtet hat. Ich würde es halt wie oben vorgeschlagen ähnlich wie bei Memory Alpha machen und so etwas unter einer eigenen Überschrift im Artikel sammeln. --Aki 02:24, 4. Mär 2019 (CET)

Strukturierte Diskussionen

Es gibt eine Mediawiki-Extension, mit der man Diskussionen anders gestalten kann.

Entschieden ist noch gar nichts. Anschauen, ausprobieren, mitreden! --Klenzy (Diskussion) 15:53, 23. Jan. 2019 (CET)

Im Testwiki ist das "Feedback" jetzt soweit eingerichtet. Theoretisch kann ich das fürs Echtwiki in ein paar Minuten aktivieren.
Praktisch sieht es dagegen so aus, dass die Mediawiki-Leute vor ein paar Tagen eine Befragung gestartet haben (Februar bis Juni 2019), wie es mit den Diskussionsseiten überhaupt weitergehen soll.
Für Interessenten, der wohlformulierte Start ist hier: https://www.mediawiki.org/wiki/Talk_pages_consultation_2019
In der Vergangenheit gab es wohl (unter anderem über diese Extension) Streitigkeiten jenseits aller akzeptablen Grenzen.
Theoretisch sind alle Mediawiki-Nutzer, auch wir, dazu aufgerufen, uns zu beteiligen. Allerdings schrecke ich davor zurück, Zeit zu investieren: Die bisherigen Beiträge auf der zugehörenden Diskussionsseite zeigen, dass einige Teilnehmer ihren Feldzug in jeweils eigener Sache rücksichtslos fortsetzen. Sachliche Beiträge sind zwar auch anzutreffen, aber vernünftige Diskussion erscheint mir unmöglich.
Im Vergleich dazu sind die heftigsten Auseinandersetzungen, die es in der Perrypedia je gegeben hat, ein laues Sommersäuseln.
Auf der deutschen Wikipedia läuft es bisher gesittet ab: Wikipedia-logo.pngWikipedia:Projektdiskussion/Globale Konsultation zum Thema Kommunikation 2019. --Klenzy (Diskussion) 20:08, 26. Feb. 2019 (CET)

Neuer Helferlink: [[Kategorie:Perry Rhodan Neo]]?

Ich fände es sehr nützlich, wenn unter den Helferlinks, in der Zeile:

Kategorie des Artikels: [[Kategorie:Planeten]] · [[Kategorie:Personen]] · [[Kategorie:Raumschiffe]] · [[Kategorie:xxxx]]

auch [[Kategorie:Perry Rhodan Neo]] auftauchen würde ... ich weiß nicht, wie oft ich das getippt habe, aber es ist auf jeden Fall zu oft. Jeder Neo-Artikel braucht diese Kategorie, deshalb wäre es schön, das mit einen Klick hinzuzufügen zu können. (Und, wenn wir grade dabei sind: ein Helfer-Link [[Kategorie:xx (PR Neo)]] wäre auch schön (für die Staffel-Kategorien). Ist aber nicht so wichtig. --Lars Jürgenson (Diskussion) 18:09, 22. Jan. 2019 (CET)

It's a shame ...! Mach ich morgen. --Klenzy (Diskussion) 20:08, 22. Jan. 2019 (CET)
Cool, danke! --Lars Jürgenson (Diskussion) 21:22, 22. Jan. 2019 (CET)
Erledigt. --Klenzy (Diskussion) 11:59, 23. Jan. 2019 (CET)
Super, danke! --Lars Jürgenson (Diskussion) 15:31, 23. Jan. 2019 (CET)

Eingabemaske: Helferlinks nach oben?

Seit dem Versionsupdate hat das Eingabefeld ja das (sehr nützliche) Syntax-Highlighting. Vermutlich deshalb ist das Eingabefeld wesentlich größer als vorher. Beim Bearbeiten an einem Laptop-Bildschirm (also bei mir fast immer) muss man jedes Mal scrollen, um die "Helferlinks" zu sehen (also die Links, die Dinge wie Quellenangaben, Textbausteine und Sonderzeichen einfügen). Wäre es evtl. möglich/sinnvoll, diese Links (direkt) über das Haupt-Eingabefeld zu setzen? Das wäre wesentlich komfortabler. --Lars Jürgenson (Diskussion) 16:04, 3. Jan. 2019 (CET)

Das würde anderen (z.B. mir ...) nicht so gut gefallen und benutzergesteuert lässt sich das nicht einstellen.
Was aber geht, ist, die Größe des Eingabefelds zu ändern. Lege dazu eine eigene "common.css" an. Mein Bildschirm hat 1366x768 und mit dieser Benutzer:Klenzy/common.css Einstellung habe ich (beim Bearbeiten) exakt das Textfeld, die Zusammenfassung und die Vorlagen auf dem Bildschirm (Windows-Taskleiste ausgeblendet). Alles ab Copyrightwarnung sehe ich nur, wenn ich den Browserviewport scrolle. Die Schaltfläche "Änderungen speichern" brauche ich nicht, das geht mit Alt-Shift-S (oder Alt-Shift-P für Vorschau). Bei der Neuanlage stimmt's nicht ganz, weil oberhalb ein Hilfstext angezeigt wird, aber in diesem Fall muss ich den Browserviewport nur einmal etwas scrollen. Das ständige Wechseln zwischen den beiden Scrollleisten entfällt. Dafür ist das Eingabefeld wesentlich kleiner (ca. 13 Zeilen), aber ich komme gut klar. --Klenzy (Diskussion) 17:20, 3. Jan. 2019 (CET)
PS. Mit dem Syntaxhighlighting hat es nichts zu tun. Die Größe ist die Standardgröße des Editors. --Klenzy (Diskussion) 17:23, 3. Jan. 2019 (CET)
Oh, neat, wusste gar nicht, dass das geht. Klappt wunderbar. Danke! --Lars Jürgenson (Diskussion) 19:48, 3. Jan. 2019 (CET)
Arg, nein, funktioniert nicht. Muss ich irgendwas machen, damit die Seite Benutzer:Lars.juergenson/common.css als CSS interpretiert wird? --Lars Jürgenson (Diskussion) 20:12, 3. Jan. 2019 (CET)
Hat sich erledigt: Ich hatte die Seite erst falsch angelegt und dann unvorsichtigerweise auch noch an die richtige Stelle verschoben, dadurch wurde/wird die Seite nicht als css erkannt. Vermutlich geht es, wenn die Seite gelöscht wird, und ich sie dann neu anlege. --Lars Jürgenson (Diskussion) 22:12, 3. Jan. 2019 (CET)
Die Mediwiki-Software löst das "Problem" der Helferlinks mittlerweile anders. Bei uns ist das ein Text im MediaWiki:Copyrightwarning und eine Extension. Aktuell wird das aber nativ von der Mediawiki-Software über das Gadget Edittols gelöst. Das erscheint zwar auch unter der Edit Box, da es aber über Javascript dargestellt wird, kann man es vielleicht dadurch leichter anpassen? Ich kann kein Javascript, aber vielleicht findet sich jemand bei uns der das kann? --Poldi (Diskussion) 22:50, 3. Jan. 2019 (CET)
Der Nachteil mit den Edittools ist, dass die auf der Seite ganz unten erscheinen. Da ist unsere Anordnung unterhalb der Edit-Zusammenfassung deutlich sinnvoller (... bzw. Geschmackssache). Die Position verändern mittels Javascript müsste auch bei uns gehen, da es sich um zwei verschiedene CSS-Klassen handelt. Habe aber gerade keine Muße, nachzuforschen. --Klenzy (Diskussion) 19:45, 4. Jan. 2019 (CET)
Nur nochmal von mir, als derjenige, der den Thread angelegt hat: Ich bin mit der Lösung, eine eigenen common.css anzulegen, vollauf zufrieden. (Wenn ich wollte, könnte ich damit vermutlich sogar die Helferlinks über das Eingabefeld verschieben, brauche ich aber gar nicht, nachdem ich das Eingabefeld für mich etwas geschrumpft habe). --Lars Jürgenson (Diskussion)