Perrypedia:Verbesserungsvorschläge/Archiv 2017 - 2019

Aus Perrypedia
Zur Navigation springen Zur Suche springen

Hilfe:Redirect

Hinweis auf einen wichtigen Verbesserungsvorschlag: Hilfe Diskussion:Redirect#Neue Version. --Klenzy (Diskussion) 17:17, 5. Nov. 2019 (CET)

Sieht schon sehr gut aus. Wird aber trotzdem nicht verhindern, dass es immer mal wieder zu Diskussionen kommt :-) --Pisanelli (Diskussion) 15:58, 29. Dez. 2019 (CET)

Arbeitserleichterung durch Semantic Mediawiki (2. Versuch)

Hinweis auf einen wichtigen Verbesserungsvorschlag:

PP-Server (2)

Mit diesem Meinungsbild Perrypedia:Meinungsbilder#Hosting PP-Server (weitere_Vorgehensweise) haben wir uns klar dafür ausgesprochen, Alternativen zur derzeitigen Hardware der Perrypedia zu untersuchen. Nochmals Danke für eure Beteiligung und euer Vertrauen. Wie geht es nun weiter? Der Plan sieht folgendermaßen aus:

  1. virtuellen Server anmieten
  2. virtuellen Server einrichten
  3. sobald fertig eingerichtet, die neue Domain hier in der Perrypedia veröffentlichen mit der Bitte - an alle - um Mithilfe beim Test
    • (notwendige Korrekturen)
  4. Belastungstest mit Siege
    • (notwendige Korrekturen)
  5. Bewertung
    • (dann entweder von vorn ...
    • ... oder den Serverwechsel durchführen)

Bis zum finalen Serverwechsel wird der Betrieb der Perrypedia unverändert weitergehen.

Norman und ich haben mehrere Varianten durchgerechnet. Das mit Abstand attraktivste Angebot ist derzeit der "V-Server Linux V40" von Strato. Die Eckdaten:

  • 6 vCores (statt bisher einem QuadCore)
  • 12 GB RAM (statt bisher 8)
  • 600 GB SSD (statt bisher 1000 GB HDD plus RAID-Mirror)
  • 500 MBit/s Netzwerk (statt bisher 1000 MBit/s)
  • 6 Monate à 1€, danach 15€

Der geringere Festspeicher ist kein Problem, wir haben weiterhin Luft nach oben. Der RAID-Mirror, dessen Nutzen in der Vergangenheit fragwürdig war, entfällt ersatzlos. Ein Engpass könnte möglicherweise die halbierte Leistung der Netzwerkanbindung sein. Das lässt sich schwer abschätzen. Deswegen der oben erwähnte Belastungstest. Der Preis: ein Schnäppchen. Einziger erkennbarer Nachteil: wir binden uns für 12 Monate.

Die V-Server haben keinen frei verfügbaren FTP-Backupspace wie unser heutiger dedizierter Server. Die Snapshots der V-Server können im Fall von Datenverlust nur ganz oder gar nicht zurückgespielt werden. Ich möchte daher an der herkömmlichen Datensicherung festhalten, sodass ich jederzeit bis zu einem Monat alte Dateien oder Artikel einzeln wiederherstellen kann. Der ideale Ersatz für den FTP-Backupspace ist ein Strato HiDrive 1 TB, ebenfalls ein Schnäppchen: 6 Monate à 1€, danach 7,50€. Auch hier binden wir uns für 12 Monate. Das HiDrive würden wir aber auch dann behalten, wenn wir zuletzt bei einem anderen Anbieter landen.

Die Verträge werden weiterhin unter dem Dach der PRFZ gebündelt. In diesem Sinne schalte ich jetzt Nils Hirseland und die PRFZ ein. --Klenzy (Diskussion) 17:57, 18. Sep. 2019 (CEST)

Nur fürs Protokoll: der teuerste VPS Server von Contabo.de bietet 6-Kern-CPU mit 40GB RAM, 1400GB HDD/SDD und 1000MBit (bei 200GBit-Anbindung) für 12,99€ an. Nachtrag: Plus zubuchbarer BackupSpace von 100GB bis 2000 GB. --Soulprayer (Diskussion) 16:43, 19. Sep. 2019 (CEST)
Kannte ich noch nicht, behalten wir im Hinterstübchen - sehr interessantes Preis-Leistungs-Verhältnis. --Klenzy (Diskussion) 17:07, 19. Sep. 2019 (CEST)

Der erste V-Server (Strato)

Der testweise angemietete V-Server ist fertig eingerichtet und online: https://www.pptest1.proc.org

  • Das Wiki dort ist auf dem Stand der Datensicherung vom 19.09. nachts. Es ist ein Klon einschließlich eurer Benutzer und Kennwörter. Ihr könnt euch gerne gelegentlich dort anmelden und umschauen, herumspielen, testen, ändern. Benutzer, die später als 19.09. zu uns gekommen sind, müssen sich dort neu registrieren.
  • Alles, was ihr dort macht, wird später verworfen.
  • Die Geschwindigkeit des V-Servers hat noch keine Aussagekraft, da derzeit praktisch niemand darauf zugreift. Aus diesem Grund werde ich morgen mit dem Belastungstest beginnen: anfangs ca. 15.000 Seitenabrufe/Tag, kontinuierlich steigend bis ≈200.000 Seitenabrufe/Tag, das wären 20 % mehr als unsere jetztigen ungefähren Zugriffszahlen.
  • Die externe Datensicherung auf dem Strato-HiDrive ist noch nicht eingerichtet. Das wird teurer als gedacht. Ich habe mich von der Werbeaussage blenden lassen: »Mit den optionalen Protokollen binden Sie HiDrive flexibel in Ihre Systeme ein [...]« - optional heißt kostenpflichtig. So werden aus den angesetzten 7,50€ -> 14,50€/Monat, erst dann kann ich meine Backups mit FTP (oder fortschrittlicheren Protokollen) dort abladen. Das ist immer noch verhältnismäßig günstig (vgl. den oben erwähnten Contabo: dort kostet 1TB Backupspace 19,99€/Monat). Für den Moment geht es auch ohne. Das Thema kommt spätestens dann wieder auf die Agenda, wenn wir am Schluss über das Gesamtpaket abstimmen.

Fragen, Fehlermeldungen, Vorschläge: gern jederzeit, bitte gleich hier im Anschluss. --Klenzy (Diskussion) 17:24, 23. Sep. 2019 (CEST)

Ich habe meine letzten Änderungen zunächst auf dem neuen Server eingefügt. Probleme gab es nicht, aber es lief deutlich schneller als gewohnt. Vielleicht aber nur wegen geringerer Last. --Flocke (Diskussion) 13:08, 24. Sep. 2019 (CEST)
Das was ich bisher getestet habe funktioniert perfekt. Super Toll. Wie lange steht dieser Klone zur Verfügung? --Norman (Diskussion) 19:04, 24. Sep. 2019 (CEST)
Ist auf dem VServer genug Platz um das Backup laufen zu lassen? Das würde im Vergleich einen Anhaltspunkt für die Leistungsfähigkeit liefern.--Oldman (Diskussion) 22:42, 24. Sep. 2019 (CEST)
@Flocke64: Die Serverlast (Seitenabrufe) ist bisher minimal, weniger als 10% dessen, was die Perrypedia täglich durchschnittlich verarbeitet. Das werde ich in den kommenden Tagen kontinuierlich steigern.
@Norman: Bis wir sagen "Schluss".
@Oldman: Ja, gestern nacht lief erstmals der (interne) Backup erfolgreich durch. Kürzlich viel gescholten ... ist aber ein ungefährer Gradmesser der Festspeicher-Performance (Datenbank und Dateisystem). Das erste Ergebnis ist sehr ernüchternd. Der V-Server benötigt für den (internen) Backup 50 % länger bzw. der bisherige Backup ist 1/3 schneller (115 vs. 75 min.) - diese ersten unsortierten Daten besagen noch nicht viel, ich muss das erst tiefergehend analysieren. --Klenzy (Diskussion) 10:04, 25. Sep. 2019 (CEST)
Ganz ohne mein Zutun wird der Backup schneller. Vorgestern 93 min., gestern 83 min. und damit fast im Normbereich. Dennoch bin ich (u.a. deswegen) nicht ganz zufrieden und strebe an, demnächst einen anderen Anbieter auszuprobieren. --Klenzy (Diskussion) 13:28, 27. Sep. 2019 (CEST)
Das riecht für mich nach Auslastungsschwankungen des Gesamtsystems. Der Witz beim Virtualisieren ist ja, dass die vorhandene Leistung besser ausgenutzt wird, weil i.d.R. nicht alle VServer (VM) gleichzeitig viel CPU, RAM, Massenspeicher- oder Netzwerkdurchsatz benötigen. Ist die reale Plattform aller VMs allerdings gut ausgelastet, kann es sein, dass einzelne VMs nicht mehr die volle Leistung erhalten (können).
Das ist ähnlich wie beim Internetanschluss über Kabel-TV: Das Kabel hat eine maximale Bandbreite die sich alle Kunden an einem Strang teilen. Surfen Abends in einem Mietshaus alle gleichhzeitig wie die Weltmeister, sinkt die dem Einzelnen zur Verfügung stehende Bandbreite. Bei (V)DSL-Anschlüssen hat jeder seine Bandbreits ab Netzwerkverteiler für sich alleine und i.d.R. garantiert zur Verfügung. Engpässee treten dann erst im Backbone-Bereich auf.
--Oldman (Diskussion) 14:10, 27. Sep. 2019 (CEST)
Ähnlich meine Vermutung. Aber: CPU und RAM können es nicht sein, die sind uns exklusiv zugeordnet. Beim Festspeicher habe ich (bei dem Versuch einer Leistungsanalyse) die erste kleine Schranke gefunden: Ich kann den Festspeichercache nicht beeinflussen. Starkes Indiz, dass sich alle VM denselben Cache teilen. Nun, es hieß bereits vorher ganz offen: eingeschränkter Kernelzugriff. --Klenzy (Diskussion) 14:36, 27. Sep. 2019 (CEST)
6 virtuelle Kerne werden wir schon bekommen, aber wie "schnell" die wirklich dann laufen, deren Kontext gesichert und wieder hergestellt werden kann etc. hängt auch von der Gesamtsystemlast ab--Oldman (Diskussion) 17:18, 27. Sep. 2019 (CEST)
Es ist normal, dass man bei einer VM keine eigenen Festplatten mit einem eigenen Cache mehr hat. Es sind halt auch virtuelle Platten. Die können zum Teil im Memory, SSD, HDD oder sogar noch langsameren Devices abgebildet sein. Der Provider kann das steuern wenn man entsprechende Prioritäten vereinbart. Das gleiche auch für Memory- und Netzwerkzugriffe. Deshalb sollte man eine VM immer größer dimensionieren als eine physische Maschine. —Norman (Diskussion) 21:04, 27. Sep. 2019 (CEST)
Mit dem letzten Satz hast Du sehr schön meine Haupterkenntnis dieses ersten Tests zusammengefasst! Es macht halt doch einen Unterschied, ob man in der Theorie darüber liest oder es in der Praxis "zum Anfassen" vor sich hat. Vorbereitungen für einen weiteren Test laufen, diesmal bei einem anderen Provider. --Klenzy (Diskussion) 12:49, 28. Sep. 2019 (CEST)
Heute nacht hat jemand (anscheinend aus Bukarest) versucht, den V-Server zu stören, indem er massenweise Mails an fiktive "@proc.org"-Adressen zu verschicken vorgab. Soweit ich bisher sehen konnte, ist kein Schaden entstanden außer dass der Postfix-Mailserver abgestürzt ist. Interessanter neuer Fall ... werde ich noch genauer analysieren. --Klenzy (Diskussion) 16:00, 1. Okt. 2019 (CEST)
Der Testserver bei Strato läuft seit etwa einem Monat im Testbetrieb. Technische Probleme gibt es nicht. Die simulierte Serverlast liegt inzwischen bei ≈130.000 Abrufen pro Tag, etwa 20% weniger, als das Echtsystem durchschnittlich stemmt. Eine Simulation ist natürlich immer nur eine Annäherung an den Echtbetrieb. Die Leistung ist zufriedenstellend, mal etwas schneller als das Echtsystem, mal etwas langsamer. Wie oben festgestellt, wird das immer davon abhängen, was gerade die anderen V-Server auf derselben Hardware anstellen. Dieser V-Server V40 würde also notfalls für uns ausreichen, empfehlenswert wäre aber wohl, eine der größeren Konfigurationen zu nehmen, die dann jeweils etwas teurer sind.
Vorher möchte ich aber einen anderen Anbieter ausprobieren, Contabo, den Soulprayer ins Spiel gebracht hat. Das ist der bisher einzige Anbieter, soweit ich gesehen habe, bei dem man eine Wunsch-CPU angeben kann. Ob das den von mir erhofften Leistungsschub bringt, werden wir sehen. In den nächsten Tagen werden wir also mit einem weiteren Testserver ans Netz gehen. --Klenzy (Diskussion) 17:17, 25. Okt. 2019 (CEST)

Der zweite V-Server (Contabo)

Der VPS L SSD:

  • 8 vCores (statt bisher einem QuadCore)
  • 30 GB RAM (statt bisher 8)
  • 800 GB SSD (statt bisher 1000 GB HDD plus RAID-Mirror)
  • 600 MBit/s Netzwerk (statt bisher 1000 MBit/s)
  • 6 Monate à 14,99€

--Klenzy (Diskussion) 11:01, 26. Okt. 2019 (CEST)

Der zweite Testserver ist jetzt am Start: https://www.pptest2.proc.org

  • Das Wiki dort ist auf dem Stand der Datensicherung vom 26.10. nachts. Es ist ein Klon einschließlich eurer Benutzer und Kennwörter. Ihr könnt euch gerne gelegentlich dort anmelden und umschauen, herumspielen, testen, ändern. Benutzer, die später als 26.10. zu uns gekommen sind, müssen sich dort neu registrieren.
  • Alles, was ihr dort macht, wird später verworfen.
  • Die Geschwindigkeit des V-Servers hat noch keine Aussagekraft (Leerlauf). Heute nacht laufen - hoffentlich - die ersten Wartungsskripte, ab morgen der Belastungstest.

Fragen, Fehlermeldungen, Vorschläge: gern jederzeit, bitte gleich hier im Anschluss. --Klenzy (Diskussion) 16:45, 28. Okt. 2019 (CET)

Danke für die Bereitstellung. Auf den ersten Blick läuft alles sauber und schnell. --Norman (Diskussion) 23:44, 29. Okt. 2019 (CET)
Nach nur zwei Nächten zeichnet sich eine Tendenz ab. Der Contabo-Server ist deutlich schneller als die Strato-Systeme, etwa ein Drittel schneller bei einem primitiven Mathe-Benchmark (5000 Nachkommastellen von Pi => reine CPU-Leistung) wie auch beim nächtlichen Backup. Der Perrypedia-XML-Dump, den wir jeden Morgen in den Downloadbereich stellen, ist sogar mehr als doppelt so schnell.
Die Aussagekraft solcher hemdsärmeligen Messungen ist recht gering. Wir wissen nicht, was die anderen Mieter auf demselben physikalischen Server anstellen - vielleicht sind wir derzeit sogar allein. Die Serverlast ist noch niedrig, die Simulation erzeugt (Stand gestern) ≈43.000 Seitenabrufe. Was ich bisher sehe, gibt Anlass zu Optimismus. Ich möchte die Serverlast in den nächsten Tagen daher rasch nach oben schrauben und dann noch eine gute Woche lang beobachten, was sich tut. Wenn alles gut läuft, könnten wir noch im November zu einer Entscheidung kommen. --Klenzy (Diskussion) 10:06, 30. Okt. 2019 (CET)
Cool. Vielen Dank für Deinen unermüdlichen Einsatz! --Pisanelli (Diskussion) 10:23, 30. Okt. 2019 (CET)
Auch von mir danke, fürs machen und uns immer auf dem Laufenden halten! --Lars Jürgenson (Diskussion) 11:39, 30. Okt. 2019 (CET)

Testauswertung

Zeit für eine Auswertung. Zuerst ein paar technische Angaben, danach ein paar weitere Überlegungen, zuletzt mein Fazit und Ausblick.

  • Technische Angaben: Beide V-Server sind nach meiner Einschätzung unseren Anforderungen mehr als gewachsen. Die simulierte Serverlast liegt jeweils deutlich über dem Durchschnitt unseres Stammservers, ohne dass eins der Geräte schwächelt. Mit verschiedenen Leistungsmessungen habe ich versucht, einen eindeutigen Befund pro einen der beiden Server zu bekommen. Das ist mir nicht gelungen. Die Messungen sind uneindeutig. Beide haben ihre Stärken und Schwächen. Der verhältnismäßig schwächer ausgestattete Strato-V40 kann in fast allen Punkten mit der besseren Ausstattung des Contabo-VPS-L mithalten, übertrifft ihn sogar in einem Punkt: Der Strato-V40 verfügt über einen gigantischen Cache. Davon profitieren hauptsächlich die Passiv-Leser, d.h. die Seitenabrufe durch anonyme/nicht angemeldete Benutzer. Das Siege-Tool bescheinigt etwa 25-30% schnellere Transaktionen als bei Contabo. Der Contabo-VPS-L punktet dagegen bei der Datenbank. Die ist vor allem für die aktiven Mitarbeiter interessant. Die Datenbankwerte sind zugegeben ziemlich hemdsärmlig gemessen, das Siege-Tool taugt nicht für so einen Test. Orientiere ich mich an dem täglichen XML-Dump, den wir für den Download herrichten, dann ist der Contabo-VPS-L hier 15-30% schneller als der Strato-V40 (und bis zu 350% schneller als unser Stammserver). Es gibt gute Performancetools, bei denen auch die Datenbank ausgewertet wird, aber die sind sehr aufwendig. Ich könnte noch Wochen weiter testen.
  • Weitere Überlegungen:
    • Die Serversnapshots laufen unterschiedlich, bei Strato: automatisch irgendwann im Lauf eines Tages, aber ich kann den genauen Zeitpunkt nicht bestimmen. Bei Contabo manuell. Beide Anbieter betonen vollkommen seriös: Der Snapshot ersetzt keinen Backup!
    • Contabo betreibt nur ein Rechenzentrum in München. Den Perrypedia-Backup würde ich auf dem Strato-HiDrive ablegen und damit an einem anderen Standort. Strato betreibt zwei RZ in Berlin und Karslruhe mit Datenspiegelung; könnte also sein, dass die Daten an zwei Standorten sind, aber genau wissen tu ich's nicht.
    • Die Festspeicherbelegung beim Strato-V40 ist jetzt 42%, beim Contabo-VPS-L 32%. Auf beiden ist im Hintergrund bereits ein zweiter Perrypedia-Klon eingerichtet, es spricht also nichts dagegen, weiterhin Test- und Produktivwiki auf demselben Server zu betreiben.
    • Interessant in diesem Zusammenhang: Strato hat die nächste Kampfrunde eingeläutet, den V40 gibt es jetzt für's selbe Geld mit 8 vCores, 32 G RAM, 800 GB SSD.
    • Wenn wir uns für den Contabo-Server entscheiden, dann würde ich die Gelegenheit gern nutzen, die Domains zu bereinigen. Perrypedia.de ist aktuell eine Subdomain von Proc.org und läuft über das Webhosting-Paket der PRFZ. Das funktioniert sehr gut, es besteht auch keine Notwendigkeit zu einer Änderung. Es heißt nur lediglich, dass wir im Zweifel von der PRFZ abhängig sind, wenn man dort den Provider oder das Webhosting-Paket wechselt. Die eigene Hauptdomain bei Contabo kostet zusätzlich 0,99€/Monat.
  • Fazit: Mein Bauchgefühl spricht nur hauchdünn für den Contabo-VPS-L.
  • Wie geht's weiter? Jetzt ist noch Zeit für Meinungen, Vorschläge, Wünsche. In Kürze würde ich, sagen wir bis Freitag 15.11., ein abschließendes Meinungsbild vorbereiten: Contabo-VPS-L oder Strato-V40.

--Klenzy (Diskussion) 11:55, 9. Nov. 2019 (CET)

Mir fehlt leider die Sachkenntnis für eine fundierte Meinung, deshalb kann ich nur sagen, dass sich das alles sehr schlüssig anhört.
Zur Domain: Da wir (jemand) offensichtlich perrypedia.de besitzt, fände ich es nicht schlecht, wenn das auch die "Hauptadresse" würde. Einerseits weil es die "schönere"/"erwartbare" Adresse ist, andererseits weil, wie du sagst, die PP damit von einem anderen Server (bzw. den DNS-Settings dort) abhängig ist - das bedeutet einen zusätzlichen möglichen Point-of-failure, ohne große Vorteile zu bringen. perrypedia.proc.org sollte natürlich als Redirect (mit rewrite) weiterbestehen, wegen Verlinkungen, etc.
Evtl. könnte man "als Ausgleich" das Proc/PRFZ-Logo mit Link auf die Startseite setzen, um den Beitrag der PRFZ (Spendenkontoverwaltung, offizieller Träger/Impressum, etc.) sichtbar zu machen und zu würdigen. Das wäre ohnehin sichtbarer als nur die Tatsache, dass die pp auf einer subdomain läuft.--Lars Jürgenson (Diskussion) 13:30, 9. Nov. 2019 (CET)
Ja, (www.)perrypedia.proc.org als Subdomain mit der Umleitung auf die dann echte Hauptdomain (www.)perrypedia.de soll in jedem Fall weiter bestehen bleiben. --Klenzy (Diskussion) 13:45, 9. Nov. 2019 (CET)
Ich nehme beide Testserver vorübergehend vom Netz, um die Grundkonfiguration der Datenbank zu modernisieren (Latin1 nach UTF-8). --Klenzy (Diskussion) 10:33, 14. Nov. 2019 (CET)
Hat erstmal nicht geklappt. Morgen geht's weiter. --Klenzy (Diskussion) 22:24, 14. Nov. 2019 (CET)
Macht Probleme, habe ich erstmal nicht weiter verfolgt. --Klenzy (Diskussion) 17:30, 4. Dez. 2019 (CET)

Hier geht's weiter:

--Klenzy (Diskussion) 17:30, 4. Dez. 2019 (CET)

Markierung

In den letzten Änderungen taucht in der letzten Zeit regelmäßig als automatischer Kommentar zu einzelnen Änderungen der Hinweis (Markierungen: Mobile Bearbeitung, Mobile Web-Bearbeitung) auf. Hat das etwas anderes als eine rein statistische Bedeutung? Falls nicht würde das nicht reichen, diese auf ein externes Logfile umzuleiten ? --Thinman (Diskussion) 19:26, 18. Aug. 2019 (CEST)

"Markierungen" sind ein neues Feature seit der vorherigen Mediawiki-Version 1.27.x, haben da aber noch nicht richtig funktioniert. Seit 1.31 (bei uns Ende Januar) werden nun verschiedene automatische Markierungen (→ Spezial:Markierungen) korrekt gesetzt. Selbst wenn man diese Markierungen irgendwo anders verschwinden lassen könnte (was meines Wissens nicht geht), würde ich das nicht tun. Der Sinn ist ja gerade eben, dass man diese Markierungen zum einen sieht und zum anderen per Filter selektieren kann. --Klenzy (Diskussion) 11:28, 19. Aug. 2019 (CEST)

Vorlage Hallo und Spielwiese

Seit dem letzten Software-Update steht ja nun jedem Benutzer eine persönliche Spielwiese zur Verfügung. Ich würde daher gerne den Text in der Vorlage:Hallo ändern. Aktuell lautet der zugehörige Satz:

  • Wenn du mal etwas ausprobieren willst, dann ist auf der [[Perrypedia:Spielwiese|Spielwiese]] Platz dafür. Der Link zeigt auf die allgemeine Perrypedia:Spielwiese. Als Ersatz für diesen Link habe ich die Vorlage:Spielwiese angelegt, die auf die Benutzer-Spielwiese verlinkt.

Entsprechend könnte der Satz also lauten:

  • Wenn du mal etwas ausprobieren willst, dann ist auf deiner persönlichen {{Spielwiese}} Platz dafür.

Natürlich funktioniert die Vorlage nur auf den Diskussionsseiten eines Benutzers; den Link zur Spielwiese habe ich blau gefärbt, damit er nicht unnötig rot hervorsticht. Die korrekte Funktion habe ich im Testwiki überprüft. --JoKaene 19:20, 18. Aug. 2019 (CEST)

Gute Idee, sollten wir machen. Ich schlage außerdem vor, die funktionale Einschränkung (Diskussionsseiten des Benutzers) in der Vorlage:Spielwiese zu dokumentieren. --Klenzy (Diskussion) 11:40, 19. Aug. 2019 (CEST)
Ich habe sie mal entsprechend erweitert und auch kategorisiert. Einsatzbereit ist sie also von nun an. Aber vielleicht gibt's noch weitere Meinungen? --JoKaene 22:32, 19. Aug. 2019 (CEST)
Ich bin für die vorgeschlagene Änderung. Scheint mir sehr sinnvoll, und es hat noch den added benefit, dass der Neunutzer gleich sieht, wie er Unterseiten unter seiner Benutzerseite anlegen kann.
Zu Vorlage:Spielwiese: Ist es den Aufwand wert, eine {{#if ...}}-Abfrage zu bauen, die sicherstellt, dass der Link nur auf Benutzer-(Diskussions)Seiten angezeigt wird? Und wenn nicht, wäre es nicht günstiger, den eigentlichen Code in <includeonly>s zu setzen? Wen man momentan auf die Seite der Vorlage geht und oben auf den Link klickt, kommt man auf Vorlage:Spielwiese/Spielwiese ... verwirrend. (Kleinigkeiten, gerne ignorieren.)
--Lars Jürgenson (Diskussion) 21:40, 20. Aug. 2019 (CEST)
Dass sie nur auf Benutzerseiten sinnvoll funktioniert ist ja bereits dokumentiert. Ich bin nur in der Lage simpelste Vorlagen zu bauen. Deshalb: Wenn sie sich verbessern lässt, wäre ich der letzte, der etwas dagegen hätte. --JoKaene 22:02, 20. Aug. 2019 (CEST)
Ja, ist dokumentiert, aber viele Leute lesen keine Dokumentationen ;)
Ich habe jetzt mal schnell die <includeonly>s gesetzt (und stattdessen ein Beispiel in den Text eingefügt). Morgen schau ich mal, ob ich auch noch einen sinnvollen Test einbauen kann, so dass die Vorlage auf anderen Seiten eine Fehlermeldung anzeigt anstatt eines kaputten Links. --Lars Jürgenson (Diskussion) 23:01, 20. Aug. 2019 (CEST)
Habe zwei kleine Verbesserungen eingebaut:
1. Die Vorlage funktioniert jetzt auch auf Unterseiten von Benutzern (Benutzer:Lars.juergenson/bla/blubb). Weiß nicht, wie oft das nützlich ist, aber vielleicht irgendwann mal, und es macht 2. einfacher.
2. Wenn die Seite auf einer Nicht-Benutzer-Seite (= außerhalb der Benutzer (Diskussion):-Namespaces) benutzt wird, gibt sie eine Fehlermeldung zurück. Beispiel: Die Vorlage {{Spielwiese}} funktioniert nur auf Benutzerseiten und deren Diskussionsseiten!
Ich hoffe, das ist so in Ordnung? --Lars Jürgenson (Diskussion) 14:41, 21. Aug. 2019 (CEST)
Wie sinnvoll das ist sei mal dahingestellt, denn der Link steht ja sowieso ständig ganz oben in der Linkleiste zur Verfügung. Ich hatte es eigentlich nur als Hinweis für neu registrierte Benutzer gedacht. --JoKaene 15:35, 21. Aug. 2019 (CEST)
Ja, wie gesagt, Kleinigkeit. Irgendwo tief in mir drin ist wohl ein Programmierer versteckt, der denkt "Der Input sollte validiert werden. Wer weiß, wo irgendjemand die Vorlage zu verwenden versucht?" Ist vermutlich übertrieben, schadet aber auch nicht, oder? --Lars Jürgenson (Diskussion) 15:58, 21. Aug. 2019 (CEST)
Finde ich gut, ist sicherererer. --Klenzy (Diskussion) 16:44, 21. Aug. 2019 (CEST)
Da sich kein Widerspruch ergeben hat, stelle ich nun den Änderungsantrag. --JoKaene 20:59, 25. Aug. 2019 (CEST)

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)

Semantic Mediawiki (SMW) hat nur beim letzten Softwareupgrade Probleme bereitet (Laufzeit); vielleicht gäbe es inzwischen eine neuere und bessere Version. Wir verwenden es hauptsächlich deshalb nicht, weil es in der Community keine mehrheitliche Zustimmung gab (Perrypedia:Meinungsbilder/Archiv#Einführung von Semantic Mediawiki (SMW)).
DynamicPageList wäre ebenso wie SMW ein nettes Feature, beide stützen sich aber ausschließlich auf vorhandene Artikel. Die meisten Portale und Listen enthalten auch Wikipedia-Begriffe und rote Links. --Klenzy (Diskussion) 15:12, 16. Aug. 2019 (CEST)
Ah, das hatte ich nicht gefunden. Schade. Wobei ich sagen muss, dass ich verstehen kann, dass jemand die in der Diskussion vorgeschlagene Vorgehensweise (direkte Benutzung von #set, etc.) zu »exotisch« findet. Ich hätte mir was leichtgewichtigeres vorgestellt, zumindest für die Portale (also größtenteils ausnutzen von den Kategorie-Einträgen, die sowieso gesetzt werden). Und das könnte man auch machen, ohne die alten Umzustellen.
Rote Links in Listen scheinen mir recht nutzlos ... zumindest bei Neo sind das dann fast immer Einträge in denen NUR ein roter Link steht, und in mindestens 50% der Fälle ist total unklar, was die entsprechende Seite jetzt dokumentieren soll. Bei roten Links in Portalen sieht das ähnlich aus (bzw. gibt es sehr wenige, und außer mir editiert niemand die aktuellen Portale).
Aber manuelle Listen sind mir weniger ein Dorn im Auge. Ich lege momentan viele Artikel an (weil ich den verwegenen Plan habe, die PP ab PRN200 mehr oder wenig vollständig zu halten), und es bremst mich doch sehr aus, jedes Mal noch zwei andere Seiten bearbeiten zu müssen (Portal und Liste), zumal die Infos im Portal sich fast immer direkt aus den gesetzten Kategorien ergeben.
Es wäre schon viel geholfen wenn man/ich die Möglichkeit hätte, entweder per SMW oder DynamicPageList einen Großteil der NEUEN Portal-Listen zu genieren - keine Änderung am Artikelformat nötig (Infos aus den Kategorien), kein Bedarf, alte Portale umzustellen, und selbst wenn die Extension irgendwann deinstalliert werden muss, wäre der "Rückbau" überschaubar (die entsprechenden Portale müssten DANN halt händisch angelegt werden, oder vor dem deaktivieren der entsprechenden Extension per subst: hardcodiert werden).
--Lars Jürgenson (Diskussion) 16:10, 16. Aug. 2019 (CEST)
Ich denke, es schadet nicht, es als Option anzubieten. Auf der anderen Seite helfen mir die roten Links auch Fehlstellen zu lokalisieren. Gibt es irgendwo eine Option, rote Links der Texte einer Kategorie zu listen? --Hb059 (Diskussion) 16:27, 16. Aug. 2019 (CEST)
Für SMW müsstest Du ein neues Meinungsbild auf den Weg bringen, Lars, ich bitte um Verständnis.
DynamicPageList installiere ich die Tage mal probeweise im Testwiki, dann kannst Du/könnt ihr/können wir alle damit herumspielen.
Rote Links nach Kategorie gibt es leider nicht. --Klenzy (Diskussion) 16:43, 16. Aug. 2019 (CEST)
Dass für SMW erst ein neues Meinungsbild hermüsste, ist klar. Aber auch mit DPL ließe sich einiges vereinfachen (und man müsste nix an den Artikeln ändern). Vermutlich ist es besser, das hier im Testwiki zu installieren, als das oben verlinkte: [2] - das ist eine weiterentwickelte Version, die performanter sein soll. --Lars Jürgenson (Diskussion) 17:35, 16. Aug. 2019 (CEST)
Ja, das wäre meine nächste Frage gewesen ;-) Ich schau mal, ob ich morgen Zeit finde. --Klenzy (Diskussion) 18:14, 16. Aug. 2019 (CEST)
Ist jetzt im Testwiki aktiv. Beispiel: [3]
Wenn Du irgendwelche Konfigurationsparameter geändert haben möchtest, gib bitte Bescheid. Ich habe momentan zu wenig Zeit, um mich mit der Extension zu befassen. --Klenzy (Diskussion) 14:28, 17. Aug. 2019 (CEST)
Oh, toll, danke! Dann spiele ich mal ein bisschen damit herum! --Lars Jürgenson (Diskussion) 18:42, 17. Aug. 2019 (CEST)
@Klenzy: Könntest du $wgDplSettings['categoryStyleListCutoff'] auf 14 setzen? --Lars Jürgenson (Diskussion) 15:51, 21. Aug. 2019 (CEST)
Erledicht. --Klenzy (Diskussion) 16:42, 21. Aug. 2019 (CEST)
Merci! --Lars Jürgenson (Diskussion) 12:55, 22. Aug. 2019 (CEST)
Arg. Ich = Idiot. Ich meinte $wgDplSettings['maxCategoryCount'] ... das bitte auf 18 setzen, $wgDplSettings['categoryStyleListCutoff'] gerne wieder auf default. --Lars Jürgenson (Diskussion) 12:59, 22. Aug. 2019 (CEST)
Kein Problem. $wgDplSettings['categoryStyleListCutoff'] auskommentiert, $wgDplSettings['maxCategoryCount'] = 18; rein. Direktzugriff kann ich dir leider nicht einräumen, es muss über den Umweg über mich gehen. Du kannst auch "Mail an diesen Benutzer" auf meiner Benutzerseite verwenden. --Klenzy (Diskussion) 15:23, 22. Aug. 2019 (CEST)
Nochmal merci! Und Direktzugriff will ich gar nicht (u. a. wegen ich = Idiot). Wenn ich dann etwas warten muss, ist das okay. Aber danke für den Hinweis mit "Mail an diesen Benutzer", das hatte ich noch nicht gesehen (und mich schon gefragt, ob es nicht einen Weg gibt, PPnauten per Mail zu erreichen, falls nötig ...) --Lars Jürgenson (Diskussion) 18:05, 22. Aug. 2019 (CEST)
Nach etwas Experimentieren bin ich zu dem Schluss gekommen, dass DynamicPageList keine Option ist - hauptsächlich aus Performance-Gründen. Einzelne Abfragen gehen recht schnell, aber auf einer Portalseite braucht man 27 Abfragen (zumindest, wenn die generierte Seite genauso aussehen soll wie die Portale bisher). Auf [4] habe ich bis jetzt nur 10 Abfragen eingebaut, und die Seite braucht sehr lange (>1 sec), sich aufzubauen. Zwar gibt es ein einfaches cache-System (noch abgeschaltet), und die normalen Seitencaches greifen auch, aber es ist absehbar, dass das Laden der Seite ohne Cache / wenn der Cache veraltet ist so lange dauern wird, dass es nicht akzeptabel ist.
@Klenzy: Du kannst die Extension also wieder deaktivieren / deinstallieren. Ich habe im Testwiki ein paar Vorlagen angelegt ([5], [6], [7], [8], [9], [10]) wie bekomme ich die gelöscht? Oder ist das nicht nötig, weil Testwiki?
Ich denke, es besteht Grund zu der Annahme, dass SemanticMediaWiki wesentlich performanter ist (weil: viel aktiver entwickelt und von Anfang an für Zwecke wie unseren gebaut - DynamicPageList war anfangs als "Reporting"-Tool gedacht, und deshalb wurde vermutlich am Anfang wenig auf Performance geachtet). Deshalb werde ich mal eine Seite anlegen, auf der ich meine Idee für eine SMW-Umstellung mit wenig bis keiner Arbeit an bestehenden Artikeln vorstelle. Das stelle ich dann hier zur Diskussion, mit dem Ziel, zu gegebener Zeit ein neues Meinungsbild auf den Weg zu bringen.
Nochmal @Klenzy: Ist Perrypedia:Eine eigene Kopie der Perrypedia erstellen noch aktuell? Die aktuelle current.xml.bz ist von heute, als vermutlich schon? Ich würde mir gerne eine lokale Testumgebung bauen, in der ich SMW installieren kann zum ausprobieren. Damit ich nicht Dinge vorschlage, die gar nicht funktionieren.
--Lars Jürgenson (Diskussion) 12:39, 23. Aug. 2019 (CEST)
Das Testwiki bleibt, wie es ist. Alle paar Monate kommt dann die große Dampfwalze ( = Klenzy), macht das Testwiki platt und kopiert alles neu aus dem Echtwiki.
Die eigene Kopie sollte weiterhin so funktionieren wie dort beschrieben, die XML-Abzüge "current" und "full" werden täglich aktualisiert. Zuletzt habe ich vor ein paar Monaten "current" bei mir lokal installiert, für "full" ist mein Rechner zu lahm. Ich habe gute Erfahrungen mit dem Bitnami-WAMP-Stack gemacht, da fehlen dann nur noch die Mediawiki-Software & die Daten.
Ich möchte allerdings noch erwähnen, dass die Leistung des Testwikis nicht zu vergleichen ist. Dort sind fast alle Caches abgeschaltet. Jede Seite wird immer neu geladen, durch den Parser geschickt etc. --Klenzy (Diskussion) 14:42, 23. Aug. 2019 (CEST)
Zu den Abzügen: Sehr gut, "current" ist für meine Zwecke ja (mehr als) genug. Und zum Testwiki: Schön, dann muss ich mir keine Gedanken machen.
Zur Performance im Testwiki: Gut zu wissen. Aber die Ladezeiten der Seite wurde so schnell so lange, dass klar war, dass das auch als worst case (=alle caches veraltet) untragbar ist. Und: Die Extension kann zwar einiges, aber ist letztendlich doch sehr unflexibel, ich musste schon einiges tricksen, um die Liste auf dem Link so hinzubekommen. Und bisher habe ich bewusst nur Features genutzt, wie WENIGER performance-intensiv sein sollten - insgesamt denke ich also, dass DynamicPageLists auch unter anderen (Cache-)Bedingungen mittelfristig nicht tragbar ist.
& Danke für den Tip mit Bitnami - so ein Stack-Installer macht es einfacher (ich habe bis vor fünf, sechs Jahren regelmäßig PHP-Entwicklung betrieben, aber das ist zwei Rechnergenerationen her, und was ich damals benutzt hab, funktioniert vermutlich nicht mehr ...).
--Lars Jürgenson (Diskussion) 19:14, 23. Aug. 2019 (CEST)
Interessehalber mal gefragt: Habt ihr auch die verschiedenen DPL-Versionen alle mal getestet? Es hat da nämlich derer drei: [11] bzw. zwei wirklich unterschiedliche. Einmal DPL (Wikimedia), wie oben verlinkt, und dann DPL2 bzw. der Nachfolger DPL3 --WGK.derdicke (Diskussion) 21:37, 23. Aug. 2019 (CEST)
Nein, wir haben nur DPL3 getestet. Ich vermute aber, dass die Vorgänger eher noch langsamer sind. --Lars Jürgenson (Diskussion) 10:49, 24. Aug. 2019 (CEST)
Ah, danke für die Info. Der "Vorgänger" von DPL3 ist DPL2, soweit OK. Aber DPL (Wikimedia) ist eine komplett andere Erweiterung, die nichts mit DPL2/3 zu tun hat, außer dass sie ähnliche Funktionalitäten bietet. Wo diese Extension dann mit ihrer Geschwindigkeit steht, müsste man gucken.--WGK.derdicke (Diskussion) 16:26, 24. Aug. 2019 (CEST)

Einrückung wird ein bisschen viel ;) DPL (Wikimedia) hat eine echte Teilmenge der Funktionen von DPL2/3 - damit könnte es natürlich schneller sein, aber schon mit DPL3 hatte ich zu kämpfen, um das hinzubekommen, was wir für die Portale brauchen. SMW ist da viel flexibler, deshalb denke ich: WENN wir diese Funktionalität wollen, dann mit SMW. SMW würde es uns u.a. erlauben, auf recht einfache Weise weiterhin Redlinks in den Portalen zu haben. Und vielleicht sogar (Zukunftsmusik), ohne signifikanten Aufwand Listenseiten zu haben, die zwar die manuell eingepflegten Einträge aus den alten Listen enthalten, gleichzeitig aber neue Einträge automatisch aufnehmen (wenn dazu über Makros die Informationen in den Artikeln selbst setzen). Das würde dann sowohl einen inkrementellen Umstieg erlauben, als auch externe Links (e.g. Wikipedia) und die Legacy-Redirects-auf-Listen weiter so funktionieren lassen, wie sie das bisher tun. Aber ob das wirklich so klappt, wie ich mir das vorstelle, muss ich nochmal kucken. --Lars Jürgenson (Diskussion) 10:58, 25. Aug. 2019 (CEST)

Kein Problem. Ich wollte nur darauf hinweisen, dass die eine Extension unabhängig von den anderen Beiden zu betrachten ist.
In der Tat, mit DPL2/3 "kämpfe" ich auch an anderer Stelle (Der Link geht auf eine Seite, bei der DPL die Liste liefert). Ich hatte mir seinerzeit auch SMW angeguckt. Was mich da abgeschreckt hat, und so habe ich das verstanden, dass ich da überall und ständig auf jeder Seite Properties einfügen muss, um das zu bekommen, was ich mit dem dort angewendeten und etablierten Konzept für die Kategorisierung der Seiten und einer DPL-Abfrage der Seiten, die beispielsweise in dieser, jener und der anderen Kategorie sind, ohnehin bekomme. Das war für mich die Entscheidung, ob ich vorhandene Kategorien mit DPL abfrage oder ob ich in tausenden Artikeln erst einmal Properties anlege. Die Entscheidung hat DPL gewonnen.
Gleichwohl, so einfach man eine Liste mit DPL zustande bekommt, das Formatieren bis zum gewünschten Aussehen steht auf einem anderen Blatt. Sehr hilfreich ist da übrigens in Kombination mit der Array-Erweiterung die Erweiterung für Schleifen im Wikitext. Soweit ich weiß, ist die zweite hier nicht installiert. Die kann auch gut beim Enttüxeln von beispielsweise kommagetrennten Werten an Parametern von Vorlagen helfen.
Und, in der Tat, an manchen Stellen dauert es mit DPL doch ein wenig, bis die Seite da ist. Möglich, dass da SMW fixer ist.--WGK.derdicke (Diskussion) 11:34, 26. Aug. 2019 (CEST)
Nur zur Info, falls mal wieder so eine Entscheidung ansteht: SMW kann beides: Nach Kategorien suchen und nach (durch SMW-Syntax gesetzten) Properties mit bestimmten werden. Kann man auch mixen und mit AND und OR beliebig verknüpfen. Wo SMW bei der Abfrage eingeschränkter ist: Es gibt kein "notcategory" und auch keinen anderen Weg, zu sagen "hat nicht die Kategorie X" (wie überhaupt NOT sehr eingeschränkt verfügbar ist, ich nehme an aus Performancegründen). Und man kann nicht direkt nach Seitentitel filtern (also DPLs "title","titlematch").
Die Ausgabenformatierung ist dagegen SEHR viel flexibler und durchdachter. Wie das mit der Performance aussieht, muss man sehen.
Mein Plan ist momentan auch, erstmal nur vorhandene Kategorien der PP auszunutzen (damit bekommt man die Portale (fast) automatisch generiert). Das hat den Vorteil, dass (a) kaum Umstellungsaufwand besteht (nur auf den Portalseiten, und auch da nur, wo man es will) und dass der "Lock-in" minimal ist - wenn wir eines Tages SMW rauswerfen wollen/müssen, müssen maximal die bisher automatisch generierten Portalseiten händisch nach gepflegt werden, sonst bleibt alles, wie es ist.
Ob und wie dann weitere SMW-Funktionalität nützlich gemacht werden kann, müssen wir sehen.--Lars Jürgenson (Diskussion) 15:42, 26. Aug. 2019 (CEST)
Ah, Danke für die Info. Da habe ich dann ja intuitiv die "richtige" Entscheidung getroffen, da ich sowohl "title", "titlematch" als auch "notincategory" nutze und zudem auch das Feature, mit dem man einzelne Parameter-Werte eines Vorlagenaufrufs aus einer bestimmten Seite laden kann. Die oben verlinkte Seite nutzt das extensiv. Da gibt es (maximal) 252 DPL-Aufrufe, einen für die Gesamtanzahl der "betroffenen" Seiten, der zweite liefert die Liste der maximal 250 Seiten und für jede Seite wird auch noch das jeweilige Bild geladen (max. 250x). Dafür halte zumindest ich ich die Reaktionszeit dieser Seite von ca. 4,5 Sekunden akzeptabel, zumal man nicht genau weiß, wieviel Zeit wofür benötigt wird (Infrastruktur des Servers, Datenbankzugriff(e), eigentliche Laufzeit der PHP-Skripte von DPL und der Download der ganzen Bilder).
Ich hatte auch schon einmal selber im stillen Kämmerlein darüber nachgedacht, hier DPL vorzuschlagen, da viele Dinge hier einfach stumpf redundant aufgeführt sind (Beispiel: Listen der Hefte in der Zyklusübersicht). Alle dort gelisteten Daten finden sich quasi 1:1 in den Seiten zu den einzelnen Heften (Beispiel: PR3000). Warum also immer doppelt eintippen? Aber da ich Ende 2018 ein klein wenig mit Klenzy aneinander geraten bin, weil ich die schreiende gelb/rote Farbgestaltung von Hinweismeldungen bekrittelte, die mir recht kryptisch anmutenden Quellenangaben mit <small>-Tags und dem festen Leerzeichen ;nbsp; in die Nähe von Spaghetti-Code rückte, der Vorschlag eines anderen PP-Nauten, diese Quellenangaben in einer Vorlage zu kapseln, mit dem Hinweis auf Performancegründen quasi abgelehnt wurde und mein Hinweis auf flinke Seitenaufbauzeiten bei massiven Vorlageneinsatz zumindest in der Sache auf taube Ohren stießen, bin ich nun ein wenig vorsichtig mit Vorschlägen.--WGK.derdicke (Diskussion) 20:28, 26. Aug. 2019 (CEST)
Korrektur: Title(match)-Funktion gibt es doch in SMW.
Ja, die Redundanz war mir auch das Problem, und die Tatsache, dass Portaleinträge schnell vergessen werden (oder gar nicht gepflegt, bei Neo gibt es eine Reihe von Staffeln, wo es gar keine Portaleinträge gibt). Dein Beispiel ließe sich mit SMW lösen wie oben beschrieben: Man passt einfach die Vorlagen "Handlungszusammenfassung XX" an, so dass sie ausser der Anzeige der Daten diese auch als SMW-Properties speichern und zaubert sie dann in der Zyklusübersicht wieder aus dem Hut. Derjenige, der die Heftzusammenfassungsseite editiert, merkt davon gar nichts. Aber das fällt unter "später sehen, wie wir SMW noch nützlich machen könnten".
Der "andere PP-naut" war ich ;) Aber ich konnte Klenzy's Reaktion da gut nachvollziehen: Er hat ja auch nicht "nein" gesagt, sondern nur, dass er das erst testen wollen würde. Und dass er keine Zeit dazu hat. Letzteres ist leider nachzuvollziehen, weil er ja schon länger die Sysadminrolle faktisch alleine trägt (scheint mir). Und als Sysadmin ist er auch halt derjenige, bei dem alle heulend oder wütend anklopfen, wenn die PP langsamer wird. Und vermutlich sollte man sowas oft-verwendetes wie die Quellenangaben eher über eine kleine Extension lösen (dann braucht es keine Transklusion für jede Verwendung). Ich denke, für Vorschläge ist Klenzy / sind alle offen, insbesondere, wenn der Vorschläger sich direkt bereiterklärt, die Testarbeit zu übernehmen, bzw. ein Konzept im Testwiki auszuarbeiten, etc. Dass dann mal von der Community gesagt wird "Nee, wollen wir aber nicht so", damit muss man leben. Oder dass jemand mit dem technischen KnowHow eben sagt: Schöne Idee, aber ist mir als Verantwortlichem grade zu "gefährlich" auch. --Lars Jürgenson (Diskussion) 15:53, 27. Aug. 2019 (CEST)
Ich finde die Idee sehr gut. Du hast sie ja auch super ausgearbeitet. Aus meiner Sicht wäre es noch schön, die ganzen Zusammenfassungstabellen irgendwie automatisiert füllen zu können. Dann müssten die Artikel jedoch noch ein paar mehr auswertbare Informationen mit sich herumtragen. --Hb059 (Diskussion) 08:18, 12. Sep. 2019 (CEST)
Der Vollständigkeit halber:
Die von Hb059 erwähnte Ausarbeitung findet ihr hier: Perrypedia:Automatische Generierung von listenartigen Seiten(abschnitten): ein Vorschlag und die Diskussion darüber hier: Perrypedia Diskussion:Automatische Generierung von listenartigen Seiten(abschnitten): ein Vorschlag#Arbeitserleichterung durch Semantic Mediawiki (2. Versuch).
Die hiesige Diskussion, die sich hauptsächlich um DPL und den Vergleich DPL<->SMW dreht, kann wohl als weitgehend abgeschlossen betrachtet werden. --Klenzy (Diskussion) 21:30, 18. Sep. 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)

Meinungsbild über die Anmietung von Testservern in Vorbereitung, Abstimmung startet in Kürze: Perrypedia:Meinungsbilder#Hosting PP-Server (weitere Vorgehensweise). --Klenzy (Diskussion) 11:40, 30. Aug. 2019 (CEST)

Das Meinungsbild ist abgeschlossen: Perrypedia:Meinungsbilder#Hosting PP-Server (weitere_Vorgehensweise).
Danke für euer Vertrauen! --Klenzy (Diskussion) 16:53, 18. Sep. 2019 (CEST)
Hier geht es weiter: Perrypedia:Verbesserungsvorschläge#PP-Server (2). --Klenzy (Diskussion) 17:00, 18. Sep. 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 [12] und [13]? 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 [14] funktionieren: [15]
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 [16]) 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 [17] und hier [18]. 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 Perrypedia:Strukturierte Diskussionen|Strukturierten Diskussionen (gelöscht Juli 2024), 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 ([19] und [20]) 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 [21] 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.

  • Hier geht es zur Projektseite: Perrypedia:Strukturierte Diskussionen (gelöscht Juli 2024)
  • Hier geht es zur Diskussion: Perrypedia Diskussion:Strukturierte Diskussionen (gelöscht Juli 2024)

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.png Wikipedia: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)

Wikipedia-Links

Ich möchte die neue Vorlage:WP zur Diskussion stellen. Damit können Wikipedia-Links wesentlich einfacher als bisher erzeugt werden. Vorteilhaft ist vor allem die Kurzform, wenn WP-Artikelname und Linktext identisch sind. Nur dort, wo "Wikipedia: ..." als Text angezeigt werden soll, ist es mehr Schreibarbeit, sonst jeweils weniger.
Die Vorlage habe ich nicht selbst erfunden, sondern aus dem Mediawiki-Wiki abgekupfert - einschließlich dem Globus (das WP-Logo). Mir gefällt die Idee gut, dass der WP-Link durch den Globus sofort heraussticht.
Beispiel: [22]. Wir haben normalerweise nur wenige WP-Links im Artikeltext (erster Absatz). So etwas wie im PRTB282 gibt es nur selten (zweiter Absatz), und dort müssten eigentlich einige WP-Links durch interne Links auf echte Artikel ersetzt werden. Besonders im Zusammenhang mit anderen externen Links passt der Globus sehr gut (dritter Absatz).
Bei Nichtgefallen kann ich das Logo aber auch entfernen oder so einstellen, dass es nur bei Bedarf kommt. Wenn die Vorlage von euch angenommen wird, kann ich die vorhandenen WP-Links per Bot automatisiert umstellen. Ein weiterer Vorteil wäre dann, dass man über die Funktion "Links auf diese Seite" sehen kann, wo sich überall WP-Links verbergen (statt wie bisher nur über Volltextsuche). --Klenzy (Diskussion) 11:27, 26. Nov. 2018 (CET)

Finde ich gut. Danke für die Arbeit. --Pisanelli (Diskussion) 11:30, 26. Nov. 2018 (CET)
Super. Gefällt mir. --Norman (Diskussion) 11:41, 26. Nov. 2018 (CET)
Das ist eine gute und sinnvolle Vorlage. Auch das WP-Logo wäre eine gute Sache, nur leider ist es (zwangsläufig) so klein, dass es kaum bis gar nicht als solches zu erkennen ist. Vielleicht reicht an dieser Stelle das typische Wikipedia-W? (Eventuell auf hellgrauen, kreisförmigen und mit einer ein Pixel breiten schwarzen Outline?) --JoKaene 11:44, 26. Nov. 2018 (CET)
Mir gefällt's! --Johannes Kreis (Diskussion) 13:02, 26. Nov. 2018 (CET)
Vor allem die Markierung als externer Link finde ich sehr gut. Ist eine Art Schild mit der Warnung: »Sie verlassen jetzt die PP!« ;-) --Zoltar (Diskussion) 13:22, 26. Nov. 2018 (CET)
Ja, genau mein Gedanke.
Es stimmt schon, den Globus erkennt man erst bei maximaler Vergrößerung als Wikipedia-Logo. Ich setze darauf, dass man's durch Gewöhnung erlernt. Das Wikipedia-W würde wahrscheinlich den Lesefluss zu stark stören. --Klenzy (Diskussion) 17:17, 26. Nov. 2018 (CET)
Mir gefällt die WP-Vorlage auch sehr gut, danke für das Erstellen! Kleiner Bugreport (?):
{{WP|...}}-Links verhalten sich insofern anders als Standardlinks (mit [[...]]) oder Neo-Links (mit {{PRNA|...}}), dass nachfolgende Flexionsmorpheme nicht in den Link integriert werden: {{WP|Hawaiihemd}}en wird angezeigt als Link mit dem Text "Hawaiihemd", dann die Weltkugel, dann "en". Lässt sich das (einfach) ändern, so das Endungen (wie bei Standard- und PRNA-Links) mitverlinkt werden? --Lars Jürgenson (Diskussion) 15:17, 29. Dez. 2018 (CET)
Nein, leider nicht, sonst hätte ich's gemacht. Es geht nur (wie mittlerweile in der Vorlage beschrieben) {{WP|Hawaiihemd|Hawaiihemden}}.
Außerdem kann auch leider ein unschöner Zeilenumbruch entstehen: Link & Icon am Zeilenende, Punkt am Anfang der nächsten Zeile.
Beides könnte man allenfalls so beheben, indem das Icon vornedran gestellt wird. Wenn sich dafür eine Mehrheit findet? --Klenzy (Diskussion) 16:57, 29. Dez. 2018 (CET)
Vornedran würde denke ich immer noch gut aussehen. Zugleich könnte ich persönlich auch mit den kleinen Unschönheiten leben. --NAN (Diskussion|Beiträge) 18:15, 29. Dez. 2018 (CET)
Ich könnte mir vorstellen, dass Weltkugel-vorne sogar besser aussieht (unhabhängig von den kleineren Problemen, die es mit Weltkugel-hinten gibt). --Lars Jürgenson (Diskussion) 10:36, 30. Dez. 2018 (CET)
...und genau das hab' ich auch schon gedacht. --JoKaene 10:58, 30. Dez. 2018 (CET)
Ich wäre da völlig leidenschaftslos. Wenn es so praktikabler ist, habt ihr meine Stimme. --LaLe (Diskussion) 12:18, 30. Dez. 2018 (CET)
Dito. --Zoltar (Diskussion) 12:24, 30. Dez. 2018 (CET)
Fertig. --Klenzy (Diskussion) 15:44, 30. Dez. 2018 (CET)
Danke! Wie vermutet finde ich, dass die neue Version besser/schöner aussieht. --Lars Jürgenson (Diskussion) 13:03, 31. Dez. 2018 (CET)
Danke, Klenzy. Schaut gut aus. :-) --NAN (Diskussion|Beiträge) 13:25, 31. Dez. 2018 (CET)
Momentan funktioniert der Linktrail ({{WP|Hawaiihemd}}en) nicht. Komisch, ich hätte gedacht es geht. Muss mal schauen ... --Klenzy (Diskussion) 14:21, 31. Dez. 2018 (CET)
Das zuletzt leichtfertig hinzugefügte nowrap, das den unerwünschten Zeilenumbruch zwischen Logo und Begriff verhindert, blockiert den Linktrail. Wir können also nur das eine oder das andere haben ... und ich halte es für wichtiger, dass das gesamte Wort als Link angezeigt wird. Daher habe ich das nowrap rausgenommen. --Klenzy (Diskussion) 18:07, 31. Dez. 2018 (CET)

Volltextsuche mit geschütztem Leerzeichen

Hallo, für meine BTW (Fakt des Tages) gestalte ich immer mal wieder eine Volltext-Suche über alle Artikel in der Perrypedia. Möchte mal fragen, ob man das normale Leerzeichen und das geschützte Leerzeichen (&nbsp;) irgendwie in der Suche vereinen kann? Oft finde ich mit bspw "18. Dezember" weniger als mit "18.&nbsp;Dezember". --Soulprayer (Diskussion) 19:24, 24. Nov. 2018 (CET)

Mit der normalen Suchfunktion geht das wohl nicht. Um auf Nummer Sicher zu gehen, wirst du nach beiden Varianten suchen müssen. Der Standard im Quelltext ist das geschützte Leerzeichen. Die Suche danach sollte also die meisten, optimaler Weise sogar alle gesuchten Daten finden. --JoKaene 19:41, 24. Nov. 2018 (CET)
Es gibt leider keinen Weg, von außen in die Suchfunktion der Mediawiki-Software einzugreifen. Es gibt eine Extension mit einem anderen Suchmodul, aber ich weiß nicht, ob der Wunsch damit abgedeckt wäre. Wir haben das sogar mal ausprobiert. War sehr aufwendig und hat letzten Endes nicht viel gebracht. --Klenzy (Diskussion) 11:25, 25. Nov. 2018 (CET)

Wikisprache

Was haltet ihr von der Idee, den Abschnitt "Die Wikisprache ist Deutsch. Fremdsprachige Benutzer können durch..." nicht in Deutsch anzubieten, sondern nur als fremdsprachiger Inhalt? Also in Englisch, Tschechisch, Niederländisch, Japanisch und Portugiesisch. Für Japanisch kann ich einen Freund fragen, bzgl Portugiesisch könnten wir DIO fragen, Englisch sollte kein Problem sein, viele Niederländer können ein wenig Deutsch, bleibt eigentlich nur Tschechisch offen. --Soulprayer (Diskussion) 11:38, 30. Okt. 2018 (CET)

Meldungen auf jeder PP-Seite anzeigen

Momentan (19.10.2018) wird ja gerade der Hinweis auf der Hauptseite der PP angezeigt bezüglich des anstehenden Betriebssystemwechsels. Dies geschieht ausschließlich dort. Ich kann aber mir vorstellen, dass es Benutzer gibt, die sich ihre favorisierten Seiten der PP als direkte Favoriten in ihrem Browser abgespeichert haben und somit von diesem Umstand keinen Wind bekommen. Das könnte man ändern. Ich weiß nicht, ob es bekannt ist: Es gibt eine Seite im „MediaWiki“-Namensraum namens MediaWiki:Sitenotice. Der Inhalt dieser Seite wird, sofern sie im Wiki vorhanden ist und etwas anderes enthält als einen einzelnen Bindestrich, über jeder einzelnen Seite im Wiki dargestellt. So kann man auch Leute informieren, die partout nicht die Hauptseite als Einstiegsseite benutzen. Mehr Infos zu dieser Seite findet sich da: www.mediawiki.org/wiki/Manual:Interface/Sitenotice. Diese Sitenotice kann wegklickbar gestaltet werden, indem man die Erweiterung Extension:DismissableSiteNotice installiert und in der LocalSettings.php-Datei konfiguriert. Ich habe dies „bei mir im Wiki“ dazu benutzt, um automatisch Weihnachten, Neujahr und Ostern anzuzeigen. --WGK.derdicke (Diskussion) 02:30, 19. Okt. 2018 (CEST)

Wenn's funktioniert, bin ich dafür, dass wir das mal ausprobieren. Ich öffne auch nicht immer zuerst die Hauptseite. --Johannes Kreis (Diskussion) 06:36, 19. Okt. 2018 (CEST)
Sitenotice ist bekannt. Könnte mir aber vorstellen, dass es die Leser nervt, wenn das auf jeder Seite auftaucht.
Andererseits: DismissableSiteNotice kannte ich nicht. Danke für den Tipp! Ich installiere das im Testwiki, dann können sich das alle live anschauen. --Klenzy (Diskussion) 09:09, 19. Okt. 2018 (CEST)
Die Sitenotice verträgt sich nicht mit den Flaggen für den Google Translator. Schon möglich, dass ich bei den Flaggen was verpfuscht habe. https://test.perrypedia.proc.org/wiki/Hauptseite --Klenzy (Diskussion) 09:25, 19. Okt. 2018 (CEST)
😉 Nervende Stitenotices sind grell gelb im Hintergrund und mit einem dicken roten Rand versehen. 😉 Ich könnte mir vorstellen, dass ein punktuellerer Einsatz der Warnfarben Gelb und Rot bei so einer Meldung in Zusammenhang mit einem insgesamt etwas gedeckterem Design den Nervfaktor durchaus nicht unerheblich nach unten drücken würde. 😉 --WGK.derdicke (Diskussion) 09:40, 19. Okt. 2018 (CEST)

Neue Vorlagen für mehrspaltige Anzeigen

Eine hoffentlich recht nützliche Verbesserung für die Gestaltung von mehrspaltigen Artikeln sind die neuen Vorlagen

die ich hiermit vorstellen möchte.
Bisher haben wir die Spalten mit der Wiki-Tabellensyntax gebastelt: {| valign="top" border="0" ... usw., neu stehen jetzt diese Vorlagen zur Verfügung. In den jeweiligen Vorlagen steht, wie's geht.
Der Artikelquelltext wird übersichtlicher und leichter verständlich. Wie bisher ist eine fixe, vom Perrypedianauten vorgegebene Spalteneinteilung möglich, z.B. 33%-33%-34% oder viermal 25%. Die %-Angabe bezieht sich wie gehabt auf die verfügbare Fenstergröße. Neu besteht aber auch die Möglichkeit, die Spaltenbreite unabhängig von der Fenstergröße zu definieren, in "em" oder "px". Das bedeutet, dass der Browser so viele Spalten anzeigt, wie er bei der jeweiligen Fensterbreite unterbringt. Das ist besonders auf Smartphones und Tablets interessant, wenn die "klassische Ansicht" verwendet wird, aber auch im PC-Browser z.B. beim Verwenden des Zooms. Das Highlight ist aber sicher die Vorlage:Spalten automatisch Anfang. Wir müssen nur noch Anfang und Ende festlegen, den Rest macht der Browser für uns. Die Spalten werden gleichmäßig aufgefüllt, ohne dass wir einen Spaltenumbruch einfügen müssen.

Im Portal zeigt sich die große Stärke wie auch die kleine Schwäche der Lösung. Nie wieder manuelles austarieren der Spalten, neue Begriffe werden einfach alphabetisch einsortiert und fertig! Manko: In den alphabetisch untergliederten Abschnitten (Personen, Technologie, Raumschiffe, Völker) wird der Spaltenumbruch jedoch knallhart an der rechnerisch ermittelten Stelle eingefügt. Wir haben dort also keinen Buchstaben mehr als Überschrift am Spaltenanfang (vgl. Gegenbeispiel [23]), sondern die Aufzählung wird einfach mit dem nächsten Begriff fortgesetzt. Ich halte das für verschmerzbar, man sieht ja trotzdem, mit welchem Buchstaben die Spalte beginnt. Schlimmstenfalls endet eine Spalte mit der Überschrift für einen neuen Buchstaben, aber der erste Begriff des Buchstabens taucht erst in der nächsten Spalte auf. Gibt es in einer Spalte Begriffe, die mehr als eine Zeile benötigen, dann können unten ein oder mehrere überhängende Zeilen auftreten (das ist aber auch heute schon so).
Getestet habe ich mit Firefox, Chrome, Opera, Edge, Internet Explorer und Safari (alte Version - wird für Windows nicht mehr gepflegt), sowie auf meinem Smartphone (Android 6 Chrome) und Uralt-Tablet (Android 4 mit Firefox). Bitte schaut euch das mal an, besonders wenn ihr exotische (auch besonders alte) Browser oder Mobilgeräte habt. --Klenzy (Diskussion) 18:10, 12. Aug. 2018 (CEST)

Begrüße das!--Zoltar (Diskussion) 18:45, 12. Aug. 2018 (CEST)
Gefällt mir sehr gut! Ich muss mich aber erst mit den vielen Möglichkeiten vertraut machen. z.B. Was ist er Unterschied zwischen "em" und "px"? --Norman (Diskussion) 21:55, 12. Aug. 2018 (CEST)
CSS:Width. "px" sind Pixel - "100px" werden also immer schmaler, je größer der Bildschirm. "em" hängt dagegen von der Schriftart ab und ist somit völlig unabhängig von physikalischen Größen wie Bildschirm, Auflösung, Pixels etc. --Klenzy (Diskussion) 22:13, 12. Aug. 2018 (CEST)
Ich versuche mich mal an praktisch an dem Portal "Arkon-Trilogie". Gibt es Einwände? --Norman (Diskussion) 16:40, 21. Aug. 2018 (CEST)
Coole Sache, hab es auch schon ausprobiert. Läuft exzellent! --Ebbelwain (Diskussion) 11:16, 23. Aug. 2018 (CEST)
Dieses Feature macht echt viel Spaß und ist für mich mittlerweile eine Art Standard. Danke nochmals! Eine Frage zu den aufklappbaren Tabellen hätte ich noch: Wäre es möglich, für den Bearbeitungsmodus die Einklapp-Funktionalität abzuschalten? Ich finde es nervig, wenn ich immer wieder eine Tabelle aufklappen muss, um in der Vorabsicht einer gerade bearbeiteten Seite die Wirksamkeit meiner Einträge prüfen zu können. --Zoltar (Diskussion) 12:28, 30. Dez. 2018 (CET)
Kannst Du mich bitte dort (Vorlage Diskussion:Einklapp Anfang) daran erinnern? --Klenzy (Diskussion) 13:11, 31. Dez. 2018 (CET)

Leseansicht

Firefox bietet jetzt anscheinend eine neue Leseansicht, die nur Text anzeigt und andere Elemente ausblendet. Die PP ist zwar schon sehr textlastig (gut so), das Feature von Firefox wäre aber womöglich (v. a. bei großen Artikeln) auch nicht schlecht. Wenn ich Firefox aber richtig verstehe, muss diese Option auf der jeweiligen Seite vordefiniert werde, damit es überhaupt funktioniert. Wäre das etwas für uns?--Zoltar (Diskussion) 05:36, 23. Jun. 2018 (CEST)

Dazu kann ich nichts sagen, ich nutze den Browser nicht. Ich weiß aber, dass es Nutzer gibt, die sich an den Links stören. Würden die Links dann auch ausgeblendet werden? --Johannes Kreis (Diskussion) 09:55, 23. Jun. 2018 (CEST)
Das Feature gibt es schon seit mindestens drei Jahren. Ist aber ziemlicher Quark, weil FF selbst entscheidet, wann und wo die Leseansicht angeboten wird. Wir können das nicht beeinflussen. Die Links können nicht ausgeblendet werden. Das Ergebnis ähnelt sehr der "Mobilen Ansicht", und diese ist im Unterschied zur Leseansicht immer auf jeder Seite verfügbar.
@Johannes, woher kommt die Info, dass sich Benutzer an Links stören? Ich bin einigermaßen fassungslos ... --Klenzy (Diskussion) 13:59, 23. Jun. 2018 (CEST)
Das habe ich vor einiger Zeit irgendwo im offiziellen PR-Forum gelesen, es wurde mir von mindestens einem Leser meiner eigenen Homepage gemailt und wenn ich mich nicht sehr irre, hat irgendein angemeldeter PP-Nutzer das mal auf irgendeiner Diskussionsseite erwähnt. Die farbliche Darstellung der Links scheint den Lesefluss zu stören. Mir geht es nicht so, das kann aber auch an der jahrelangen Gewöhnung liegen. --Johannes Kreis (Diskussion) 16:30, 23. Jun. 2018 (CEST)
Dann wäre es vielleicht gar nicht so schlecht, sich mal eine Ansicht zu überlegen, die den Text nur schwarz-weiß, aber mit der Link-Funktionalität, darstellt? So eine Art Druckansicht für die PP.--Zoltar (Diskussion) 16:54, 23. Jun. 2018 (CEST)
Das kann jeder individuell in seinen Browsereinstellungen selbst definieren. Nicht unser Bier.
Beispiel Firefox: Einstellungen -> Allgemein -> Sprache und Erscheinungsbild -> Schriftarten & Farben -> Farben -> Link-Farben.
Der Witz an einem Wiki sind ja gerade eben die Links. --Klenzy (Diskussion) 19:01, 23. Jun. 2018 (CEST)
OK, geht mir genau so. Und jetzt kann ich argumentieren, falls irgendwo im PR-Forum Gemecker entstehen sollte. Danke! --Zoltar (Diskussion) 19:56, 23. Jun. 2018 (CEST)

Link von HZF zu den Veröffentlichungen des Jahres

Beispiel: [24]
Was haltet ihr davon? Die Vorlage:EVJ wäre zwar nicht nötig, reduziert aber die Tipparbeit. --Klenzy (Diskussion) 17:02, 17. Jun. 2018 (CEST)

Gefällt mir sehr! --JoKaene 18:02, 17. Jun. 2018 (CEST)
Gute Idee! --Johannes Kreis (Diskussion) 21:18, 17. Jun. 2018 (CEST)

Power Point-Hilfe

Ich mach das jetzt zu einem eigenen Punkt.

Um die Frage von Klenzy weiter unten aufzugreifen "Wer kanns, und wer machts?" ...

  • seufz* Eigentlich habe ich ja keine Zeit, aber ich versuche bis Ende Juni mal eine Version zu gestalten.

Rein aus Interesse: Wer ist noch PP-Könner? Tostan 23:28, 7. Jun. 2018 (CEST)

So es geht los mit der Ahnungslosigkeit hinsichtlich Perrypedia. Wie kann ich PP-Dateien hochladen? Ich hab mal vier Masterfolien erstellt, damit wir eine davon auswählen können. Tostan 09:48, 8. Jun. 2018 (CEST)
Die Upload-Berechtigung hast Du. In der Sidebar auf der linken Seite unter "Werkzeuge" steht "Datei hochladen", das ist der Menüpunkt der Wahl. Allerdings sind nur bestimmte Dateiendungen erlaubt, Powerpoint ist nicht dabei. Das würde auch nichts nützen, denn die Masterfolien könnte dann nur anschauen, wer Powerpoint oder mindestens den Powerpoint-Viewer hat. Kannst Du die Masterfolien als Grafik exportieren, am besten JPEG? --Klenzy (Diskussion) 10:16, 8. Jun. 2018 (CEST)
Wie wäre es die Powerpoint-Präsi vorher in eine Videodatei umzuwandeln? Das geht mit Microsoft PPT-Bordmitteln ("Speichern unter"; und als Dateityp z.b. Windows Media Video WMV, oder MP4 angeben). Momentan können diese Datei-Typen zwar auch nicht hochgeladen werden, aber das Abspielen von Videos wäre mit anderen Einstellungen doch eher und universeller machbar als ein PowerPoint-Plugin? Oder? --Norman (Diskussion) 11:30, 8. Jun. 2018 (CEST)
Gute Idee. --Metulski (Diskussion) 18:39, 8. Jun. 2018 (CEST)
Bevor ich es jetzt falsch mache, sicherheitshalber nur mal eine Folie ...https://www.perrypedia.proc.org/wiki/Datei:Verschlag_Tutorial_Masterfolie_1.JPG Der erstellt jedesmal eine eigene Bilddatei. Wo finde ich die dann in der PP? Tostan 21:20, 8. Jun. 2018 (CEST) (Hmpf. Und falsch benannt auch noch. Sollte Vorschlag heißen)
Ich verstehe die Frage nicht? Du vergibst den Namen und findest die Datei dann so: "Datei:gewählter Name". --Klenzy (Diskussion) 22:03, 8. Jun. 2018 (CEST)
:-D Ich bin der DAU. Hab Bilder bislang gemieden, daher wusste ich nicht, dass ich oben im Suchfeld "Datei:gewählter Name" eingeben kann :-)
Hier die 4 Vorschläge.

Sagt mal, welche euch besser gefallen. Und falls ihr noch andere Vorschläge habt, dann her damit. Tostan 22:34, 8. Jun. 2018 (CEST)

Quatsch, kein DAU. Wer's noch nie gemacht hat, kann's nicht wissen. Ich hab die Frage zuerst nicht verstanden.
Wenn ich wählen dürfte: Das PP-Logo nur 1 x, klein, rechts oben. Ansonsten die 3. --Klenzy (Diskussion) 22:48, 8. Jun. 2018 (CEST)
Also so: https://www.perrypedia.proc.org/wiki/Datei:Vorschlag_Tutorial_Masterfolie_5.jpeg

Tostan 23:14, 8. Jun. 2018 (CEST)

Wir könnten euch das Logo als Kopfzeile über die ganze Folie zeihen. Also mehrmals hintereinander.

Tostan 23:16, 8. Jun. 2018 (CEST)

Ich denke, das reicht jetzt, um eine auszuwählen. Machen wir da jetzt ne Abstimmung oder wer entscheidet darüber? Tostan 23:25, 8. Jun. 2018 (CEST)
Mir gefällt die 5 am besten, gefolgt von 3 und 1. Ich mag es dezent.
Da Du derjenige bist, der sich die Arbeit macht, entscheidest letzten Endes Du.
Vielleicht melden sich ja noch ein paar andere.
Wenn ich mich recht erinnere, dann ist die Masterfolie im Zweifel auch nachträglich austauschbar. --Klenzy (Diskussion) 11:43, 9. Jun. 2018 (CEST)

Bilder und Animationen

Thomas Röhrs mit seinen animierten Titelbildern, will der PP diese Animationen und auch die Grafiken von Schiffen zur Verfügung stellen. Ich denke, das ist eine coole Ergänzung. Was meint ihr? --Tostan 09:41, 6. Jun. 2018 (CEST)

Entschuldige bitte den Eingriff, ich denke das ist ein etwas anderes Thema und sollte daher in einem eigenen Abschnitt besprochen werden.
Passt für mich. Danke für die übersichtlichere Variante. --Tostan 10:32, 6. Jun. 2018 (CEST)
Ja, es ist (im Prinzip) eine coole Idee. Ich gebe aber zu bedenken: Wir sind ein Online-Lexikon für Perry Rhodan, keine Web-Plattform für Fanveröffentlichungen. Anscheinend gibt es dafür großen Bedarf, es ist die x-te Anfrage dieser Art. Wo es passt, machen wir auch mal Ausnahmen (z.B. Schlacht am Schlund Grafik von Zoltar, Mehandor Grafik von Lothar Bauer). Es sollen meiner Meinung nach Ausnahmen bleiben. --Klenzy (Diskussion) 10:09, 6. Jun. 2018 (CEST)
Hm ... die PP ist ja ein Nachschlagewerk, damit die Leser (und mittlerweile auch die Autoren) nachschlagen können. Und eine animierte Fangrafik/animation hilft beiden bei der Vorstellung. Vielleicht kann man das auf einer eigenen Seite sammeln und jeweils entsprechend verlinken. Ich denke, die PP sollte nicht auf so etwas verzichten. Die einzige heikle Frage: Wer bestimmt, ob die Qualität der Werke "gut genug" für die PP ist ... hm ... Bei Animationen ist es leicht, denn da musst gut sein, dass sie gut aussehen. Bei Bildern jedoch ... --Tostan 10:33, 6. Jun. 2018 (CEST)
Der Grat zwischen Fanveröffentlichung und sinnvoller Information ist schmal, da stimme ich zu. Aber gehört nicht auch das Fandom mit seinen Aktivitäten zum Perryversum. DORGON und die FanEdition sind ja auch in der PP, klar als Fanfiction gekennzeichnet. Warum sollten Grafiken, wenn sie gut und sinnvoll sind, außen vorbleiben, solange sie als unkanonisch gekennzeichnet sind. --Metulski (Diskussion) 11:06, 6. Jun. 2018 (CEST)
Gut und sinnvoll ist, was keine Verwirrung stiftet. Gerade bei Grafiken kann man sich schnell vertuen, weil das nicht immer so ersichtlich ist, was kanonisch ist und was nicht. Bei den Texten finde ich das einfacher. Dann sollten wir uns irgendwie eine gute Methode überlegen, wie wir die unkanonischen Zeichnungen deutlich kennzeichnen, dass da keine Unfälle passieren können. Aber ganz ehrlich: wir sind tatsächlich keine Plattform für Fansammlungen, wir wollen das Original bearbeiten. Von daher würde ich diese Art von FanFiction auch gerne begrenzt sehen bei uns. Bei DORGON habe ich persönlich schon Zahnschmerzen. Wenn's nach mir ginge, wäre die hier nicht drin. --Pisanelli (Diskussion) 11:13, 6. Jun. 2018 (CEST)
Dorgon ist die eine große Ausnahme und genießt hier (nur) historisch begründete Vorrechte.
Die Fan-Edition existiert hier nur als Auflistung der Veröffentlichungen, weiter nichts.
Weitere Meinungen zu Tostans bzw. Thomas Röhrs Angebot? --Klenzy (Diskussion) 11:41, 6. Jun. 2018 (CEST)
Ich finde gute Fangrafiken gut! :) --Johannes Kreis (Diskussion) 13:06, 6. Jun. 2018 (CEST)
Die Frage ist, wer beurteilt, ob es qualitativ hochwertig für die PP ist? Über jede Grafik oder Animation abzustimmen, ist unpraktikabel. Wenn, dann müsste man immer nur über eine Person abstimmen. D.h. zB Thomas Röhrs bietet der PP seine Grafiken an, schickt eine Auswahl, dann gibt es eine Grundsatzabstimmtung, ob die Grafiken genommen werden und dann ist er dabei oder eben nicht. Nur so verhindern wir Wildwuchs und beschränken es auf qualitativ Hochwertiges. CYA Tostan 6. Jun. 2018 18:20 (CEST)
Eine klare Regel dazu gibt es nicht. Einige Teile aus Hilfe:Was Perrypedia nicht ist tangieren Fanbeiträge am Rande:
3. »[...] folgende Arten von externen Links sind nicht gewollt: fremde Verlage, Shops, Apps, Rezensionen und Sekundärliteratur, Fanseiten und Fanprojekte (außer auf der Seite Fandom).« (betrifft folglich nicht hier eingestellte Fangrafiken)
4. »Perrypedia ist kein Ort für [...] Fan-Seiten. [...]« (der erläuternde Text zielt auf Artikel ab, aber die Intention ist eindeutig: PP ist keine Plattform, um auf eigenen Seiten eigene Werke zu veröffentlichen)
6. »Perrypedia ist keine Bildergalerie. Das Anlegen und die Inhalte von Bildergalerien wurden in einer Meinungsumfrage festgelegt.« (keine reinen Galerieseiten, außer den festgelegten Ausnahmen)
Folglich gibt es erst einmal keine Grundsatzentscheidung für oder gegen Fangrafiken oder -animationen in den Artikeln zu PR-spezifischen Begriffen.
Oben habe ich ja schon zwei Beispiele aufgezeigt. Ein weiterer, weit umfangreicherer Fall von Fangrafiken sind die Zeichnungen von Menura für PR Neo. Sie hat seinerzeit einfach angefangen, die Zeichnungen online zu stellen und dafür viel Zuspruch erhalten. Eine Abstimmung gab es nicht. Wir haben in diesem Zusammenhang lediglich die Reihenfolge festgelegt: "kanonische Darstellungen vorrangig vor Fangrafiken" (Benutzer_Diskussion:JoKaene/Archiv#Grafiken).
In ähnlichen Fällen wurde ähnlich entschieden (Diskussion:Makemake#Bild?, Diskussion:MATERIA).
Weitere ähnliche Diskussion hier, bis fast ganz unten.
Ich stimme zu, dass es nicht praktikabel ist, über jede einzelne Grafik zu diskutieren. Eine Grundsatzentscheidung für eine bestimmte Person kann es aber ebenfalls nicht geben; das wäre gleichbedeutend mit einem Freibrief. Ein Fan, der seine Grafiken hier einbringt, muss - wie jeder andere PPnaut - auf Reaktionen von Zuspruch bis Ablehnung gefasst sein, so läuft das nun mal in einem Wiki. Wie das Beispiel Menura zeigt, hat es zumindest in der Vergangenheit keine mühseligen Einzelfalldiskussionen gegeben.
Als PP-Mitarbeiter bin ich bei Fanproduktionen skeptisch, in der Rolle als Sysadmin müsste ich eigentlich neutral sein.
Was nun? 2 Skeptiker (Pisanelli, ich), 2 Befürworter (Tostan, Johannes). --Klenzy (Diskussion) 10:17, 7. Jun. 2018 (CEST)
Ich bin da auch skeptisch. Wir alle sollten eigentlich den Fall der Bruckschen SOL kennen. Bilder sagen halt soviel wie 1000 Worte.--Thinman (Diskussion) 16:01, 7. Jun. 2018 (CEST)
Ich würde den Fall mit Menura vergleichen. Da waren die Grafiken schon eine schöne und sinnvolle Bereicherung für uns. Unter den gleichen Regeln wie damals bei Menura würde ich weiteren Grafiken zustimmen. Klare Abgrenzung zur offiziellen Bildern des Verlags, wobei mir jetzt aktuell nicht ganz klar ist, warum wir das damals so gemacht haben. Bilder, Grafiken usw sind doch eh keine Kanon-Quellen, oder? --Poldi (Diskussion) 12:03, 7. Jun. 2018 (CEST)
Das hat hauptsächlich rechtliche Gründe. Was vom Verlag ist, darf keinesfalls kopiert oder weitergegeben werden. Was von Fans kommt, unterliegt gemäß den Bestimmungen des Wikis der GNU-FDL. Zum anderen geht es um die von Pisanelli angedeutete Verwechslungsgefahr. Der Leser muss wissen, was offiziell und was Fanbeitrag ist. Eine räumliche Trennung im Artikel ist dabei nicht notwendig, aber hilfreich. Und als letztes gilt: Bilder und Grafiken vom Verlag haben immer Vorrang, auch wenn sie später herauskommen als der Fanbeitrag und diesem widersprechen. Sonst könnten Fans mit ihren Bildern Fakten schaffen, die nicht zum Serienkanon passen. --Klenzy (Diskussion) 12:58, 7. Jun. 2018 (CEST)
Weil ich die zurückhaltende Meinung von Pisanelli und Klenzy zum Thema teile, reihe ich mich mal unter die Skeptiker ein. --NikNik (Diskussion) 19:17, 7. Jun. 2018 (CEST)
Vielleicht ist das jetzt die Kanone auf den Spatz, aber wie wäre es mit einer großen, sauberen Lösung, die mir in der jedipedia untergekommen ist. Die müssen sich ja mit der Kanonneufassung rumschlagen und haben sich deshalb für eine Lösung mit Tabs entscheiden: Kanon, Legends, Trivia. In der Perrypedia hießen diese Tabs dann Perryversum, Neoversum, Fandom (oder so) Wäre natürlich ein wenig Arbeit, aber dann hätte jeder gleich vor Augen, was kanonisch ist, und was nur der Veranschaulichung dient. --Metulski (Diskussion) 08:53, 8. Jun. 2018 (CEST)
Ist tatsächlich etwas überdimensioniert für die Unterbringung von Fangrafiken.
Es wäre theoretisch eine schöne alternative Lösung für die verschiedenen Kanons: Classic, Neo, Comic, Rollenspiel ...
Auf die Schnelle habe ich drei Extensions gefunden: "Tabs", "Tabber" und "Header Tabs".
Die ersten beiden sind aus technischen Gründen schätzungsweise nur geeignet für kleine Tabs, die Tabdefinition erfolgt über Wikitags bzw. Parserfunctions. Wir müssten z.B. den gesamten Artikel Terrania in den ersten Tab packen und Terrania (PR Neo) in den zweiten. Die Wahrscheinlichkeit ist groß, dass das schiefgeht.
Die "Header Tabs" nutzen clever die in den Wiki-Artikeln ungenutzte erste Überschriftenebene. Auch hier muss alles in einen Artikel gepackt werden. Das empfinde ich als unübersichtlich, könnte man aber verschmerzen, wenn es nicht den zweiten größeren Nachteil gäbe: Es funktioniert nicht in der Mobilansicht, da wird immer nur der erste Tab angezeigt. --Klenzy (Diskussion) 09:47, 8. Jun. 2018 (CEST)

Vorschlag für das mit der Öffentlichkeitsarbeit

Hi Klenzy, ich lagere das mal hier hin aus, weil es um eine konkrete Idee geht. FB hin oder her, ich bin da auch kein Freund von. Mit dem Heftehaufenblog habe ich allerdings die Erfahrung gemacht, dass sich dort viele der produktiven und interessierten Leute im Fandom rumtreiben (Nein, mir ist auch schleierhaft, warum man das nicht im richtigen Internet tut, aber egal.) Deshalb meine konkrete Idee: Eine Reihe mit Kurzinterviews von engagierten Perypedianauten: zwei, drei Fragen, ein Foto, gern bei mir auf dem Blog und anschließend ab in die Linkschleudern bei FB, Twitter und G+ damit. Einfach Sichtbarkeit schaffen. Das kostet kaum Zeit, erreicht aber eine Menge Leute. Nur so als Idee. --Metulski (Diskussion) 22:02, 5. Jun. 2018 (CEST)

Ich habe auch eine Idee: Ben Calvin Hary könnte doch in einem seiner monatlichen Youtube-Videos mal Werbung für die PP machen, oder? --Johannes Kreis (Diskussion) 06:52, 6. Jun. 2018 (CEST)
Ich habe ihn mal angeschrieben. Bin gespannt, wie er reagiert. Könnte ganz fein werden. Er hat ja ganz ordentlich Reichweite. --Metulski (Diskussion) 08:54, 6. Jun. 2018 (CEST)
Ja, schöne Idee - betrifft aber nicht nur mich, daher würde ich es doch gern auf die allgemeine Seite für Verbesserungsvorschläge schieben - einverstanden? --Klenzy (Diskussion) 08:21, 7. Jun. 2018 (CEST)
Klar! --Johannes Kreis (Diskussion) 08:59, 7. Jun. 2018 (CEST)
Hierher verschoben. --Klenzy (Diskussion) 16:42, 7. Jun. 2018 (CEST)
Ich habe Rückmeldung von Ben wegen der Videoidee. Die Themen der Videos bestimmt die Redaktion, er hat dort kein Mitspracherecht. Da es aber nur einen Videoslot pro Monat gibt, dürfte die Themenauswahl recht hart umkämpft sein. Ben hat geraten, eine Mail an den Verlag zu schreiben. Weniger als ein entschiedenes Nein kann ja nicht rauskommen. Wenn niemand Einspruch erhebt, kann ich Philine gern anschreiben. --Metulski (Diskussion) 18:33, 8. Jun. 2018 (CEST)
Mach das mal! Es würde ja reichen, wenn er die PP in einem Video erwähnt und zeigt - es muss sich ja nicht das ganze Video nur um die PP drehen. --Johannes Kreis (Diskussion) 12:23, 9. Jun. 2018 (CEST)
Läuft. Werde berichten. --Metulski (Diskussion) 00:02, 10. Jun. 2018 (CEST)
Philine Marie Rühmann ist der Idee gegenüber sehr aufgeschlossen und hat mir zurückgemeldet, dass sie das mit Ben bespricht. Sie hat signalisiert, dass zumindest eine Erwähnung innerhalb eines Videos durchaus machbar sei. Ich bin mal gespannt. --Metulski (Diskussion) 17:37, 13. Jun. 2018 (CEST)
Super! Vielen Dank! --Johannes Kreis (Diskussion) 06:36, 14. Jun. 2018 (CEST)
Da isset: https://www.youtube.com/watch?v=ZYNTsAZ6fdw&feature=youtu.be Sehr cooles Video, wie ich finde.Metulski (Diskussion) 17:23, 21. Aug. 2018 (CEST)
Super! Verschärftes Lob! --Norman (Diskussion) 17:40, 21. Aug. 2018 (CEST)
Sehr coole Sache. Dank und Respekt für die Orga.
(Bringt sogar einen Ex-Mitarbeiter wie mich dazu, sich mal wieder kurz zu rühren. ;-)) --NAN (Diskussion|Beiträge) 18:46, 21. Aug. 2018 (CEST)
Wow, ein Video von Ben ganz über die PP! Das ist echt klasse. Vielen Dank! --Johannes Kreis (Diskussion) 06:30, 22. Aug. 2018 (CEST)
+1 Like!
Hier [25] wurden wir übrigens auch schon erwähnt, ab 3:47. --Klenzy (Diskussion) 09:31, 22. Aug. 2018 (CEST)

Vorschläge aus Garching

Beim Perrypedia-Panel auf dem GarchingCon 2018 wurden einige Verbesserungsvorschläge diskutiert.
Um den NEO-Bereich aufzuhübschen, wäre es günstig, die NEO-Spoiler aus dem Forum übernehmen zu können. Eine entsprechende Anfrage habe ich eben gestellt.
Außerdem empfanden einige der anwesenden Teilnehmer die Hilfeseiten als schlecht sichtbar. Vielleicht könnte man hier potenzielle Mitarbeiter, denen die Benutzung der Wiki-Software noch fremd ist, ein wenig mehr an die Hand nehmen.
Desweiteren ging es um die Außendarstellung der Wikipedia. Die Artikelreihe in der SOL ist eine feine Sache, erreicht aber eben nur SOL-Abonnenten. Könnte man ähnliche Artikel nicht in den relevanten Facebookgruppen platzieren? Oder immer mal wieder kurze Interviews mit Perrypedianern einstreuen. Grundtenor: "Ich bin dabei, weil...".
Bei einigen Teilnehmern gab es eine große Unsicherheit über den "Wert" ihrer Mitarbeit. Hier denke ich, könnte noch klarer kommuniziert werden, dass selbst die Korrektur eines Kommafehlers ihren Wert hat. --Metulski (Diskussion) 10:11, 5. Jun. 2018 (CEST)

GruftiHH hat hier schon sein Einverständnis zur Übernahme der Spoilertexte erklärt. Jetzt müsste sich nur noch jemand die Arbeit machen, die Texte einzuarbeiten. Ich komme in nächster Zeit wahrscheinlich nicht dazu. Bei Facebook bin und bleibe ich unregistriert, auch hier müsste also sonst jemand aktiv werden, falls das gewünscht ist. Ansonsten versuchen wir neuen Perrypedianauten durchaus zu helfen, d.h. wir verweisen nicht einfach nur auf die Hilfeseiten. --Johannes Kreis (Diskussion) 14:41, 5. Jun. 2018 (CEST)
@Metulski, danke für die zusammenfassende Meldung vom Con!
Die Neo-Spoiler von GruftiHH kann ich übernehmen.
Dass die Hilfeseiten "schlecht sichtbar" seien, ist mir, hm, rätselhaft. Links in der Sidebar unter "Mitmachen" ist "Hilfe" die erste Auswahlmöglichkeit. Auf der Hauptseite befasst sich ein ganzer Abschnitt ("Wir freuen uns immer ...") mit leichten Einstiegsmöglichkeiten. Unter "Letzte Änderungen" sind ganz oben Hilfe-Links. Im Portal sind die Hilfe- und Kommunikationsseiten rechts deutlich hervorgehoben. Aber ich lasse mich gern überzeugen: Wo und wie können wir die Hilfeseiten noch sichtbarer machen?
Im PR-Forum sind wir mit einem eigenen Thread relativ weit oben im Fanbereich vertreten: https://forum.perry-rhodan.net/viewtopic.php?f=62&t=1609. Mehr Öffentlichkeitsarbeit kann ich derzeit nicht leisten (außerdem bin ich darin gar nicht so gut). Es müsste sich also für Facebook ein anderer freiwilliger PPnaut finden. Problematisch ist hier wie immer unsere begrenzte Kapazität. Persönlich bin ich vom Nutzen von FB nicht so überzeugt, aber das ist ein anderes Thema und gehört nicht hierher.
Den Umgang mit der Wiki-Oberfläche zu erlernen, können wir niemandem abnehmen, das muss jeder selbst anpacken - aber wie Johannes schreibt, versuchen wir aktiv zu helfen.
Was wir zeitlich wiederum nicht leisten können, ist ein unmittelbares Feedback zu jeder kleinen Änderung. Bei ein paar tausend Änderungen pro Monat ist das einfach unrealistisch. --Klenzy (Diskussion) 16:15, 5. Jun. 2018 (CEST)
Das mit den Hilfeseiten ist mir klar, es war nur so eine "gefühlte Schwierigkeit" einiger Teilnehmer. Ich hatte den Eindruck, dass die Menschen abgeholt werden wollen, ein wenig Bestätigung brauchen. Dass es die gibt, habe ich bei meinem Einstieg 2012 ja selbst erfahren und dass eine jahrelange nur sporadische Mitarbeit auch ok ist ... ach, ich glaube, die Leute wollen einfach nur, dass man ihn das aktiv erzählt. Die SOL-Artikel sind da ganz gut, der Rest geht vermutlich eh nur im persönlichen Gespräch. (Ist auf dem ColoniaCon auch ein Panel geplant).
Einer der Teilnehmer am Panel in Garchin war ehemaliger Wikipdianer und hatte ganz schlimme Angst vor Trollen und Editwars. So jemanden muss man einfach im persönlichen Gespräch überzeugen, dass das hier doch deutlich gesitteter zugeht.

Was die NEO-Spoiler angeht, gibt es im Forenthread noch eine Zusage außer der von GruftiHH. Ist es ausreichend, den Link zum entsprechenden Thread an die entsprechende Stelle zu den Genehmigungen zu kopieren?--Metulski (Diskussion) 21:55, 5. Jun. 2018 (CEST)

Besser wäre es, wenn wir das Einverständnis hier in der PP hätten. Wer weiß, wie lange das Forum noch existiert... --Johannes Kreis (Diskussion) 06:41, 6. Jun. 2018 (CEST)
Hinweis zum Einstieg zu Hilfe: @Klenzy: Ohne User-Anmeldung sieht man in der linken Navileiste einige Rubriken nur eingeklappt!; so auch "Mitmachen". Dann sieht man den Unterpunkt "Hilfe" nicht. Insofern kann ich den Punkt für absolute Neueinsteiger schon nachvollziehen. (Sowohl mit Safari, Edge, IE und Firefox). Hast du eine Idee, dass Hilfe immer erscheint? --Norman (Diskussion) 06:56, 6. Jun. 2018 (CEST)
Apropos Hilfe: Man könnte Videos mit kurzen Anleitungen erstellen: Wie melde ich mich an, wie bearbeite ich einen Artikel, wie erstelle ich einen neuen... Sowas mal sehen zu können ist bequemer, als ein Handbuch lesen zu müssen. Die Videos könnte man prominent (z.B. mit einem Screenshot) auf der Startseite einbinden. Dummerweise habe ich weder die entsprechende Software für sowas noch die Zeit oder die Kenntnisse... --Johannes Kreis (Diskussion) 07:12, 6. Jun. 2018 (CEST)
Guter Vorschlag! Das erleichtert erste Schritte ungemein, denn Lesen, das machen viele einfach nicht! Ich habe zwar keine Erfahrung zum Erstellen solcher Videos, aber ich kann mich da mal zeitlich ein bißchen reinhängen. Wenn aber ein anderer hierzu schon Erfahrung hat, bitte einfach melden! --Norman (Diskussion) 07:30, 6. Jun. 2018 (CEST)
Klingt nach einer guten Idee. Ich habe mir unter Linux mal Kazam angesehen. Das ist kein Hexenwerk. Ich denke, es wäre günstig, mehrere kurze Videos zu genau einem Thema zu machen. Das schauen mehr Leute an, als ein langes Video. Nach einer Minute ist bei vielen einfach Schluss. --Metulski (Diskussion) 08:51, 6. Jun. 2018 (CEST)
Snagit kann das auch. Die Software habe ich sogar, aber ich kann sie nicht gut genug bedienen :) --Johannes Kreis (Diskussion) 09:19, 6. Jun. 2018 (CEST)
Alternativ wäre ein Powerpoint-Tuturial, in dem die Schritte "Registrierung" "Artikel bearbeiten - Rechtschreibung, Gramatik etc", "Artikel - Inhalt bearbeiten mit Quellenangabe" und "Artikel neu erstellen" erklärt werden. Das kann erstmal rascher realisiert werden, als ein Video. Wobei ich das Video natürlich für die bessere Variante halte. Tostan 09:41, 6. Jun. 2018 (CEST)
Und ja, kurze Videos sind defintiv besser, eben immer mit einem Themenschwerpunkt für den DAU ... Tostan 09:46, 6. Jun. 2018 (CEST)
NAN hat mal für einen Con mit so etwas angefangen.
Die damalige Diskussion: https://www.perrypedia.proc.org/wiki/Perrypedia:Verbesserungsvorschl%C3%A4ge/Archiv_2014_-_2016#Hilfestellung_f.C3.BCr_neue_Benutzer_oder_interessierte_Fans
Die Projektseite: https://www.perrypedia.proc.org/wiki/Perrypedia:Tutorials_und_Workshops
NANs private Notizen dazu: https://www.perrypedia.proc.org/wiki/Benutzer:NAN/Tutorials
--Klenzy (Diskussion) 10:32, 6. Jun. 2018 (CEST)
@Norman: Das Wiki speichert in einem Cookie auf deinem Rechner, welche Elemente der Sidebar aufgeklappt sind und welche zu. Das ist unabhängig davon, ob Du angemeldet bist oder nicht. Beeinflussen kann ich das nicht. --Klenzy (Diskussion) 10:32, 6. Jun. 2018 (CEST)
@Klenzy: Das mit dem Cookie ist klar. Aber wie kommt es dann, wenn man auf einem "jungfräulichen" Rechner zum erstenmal die PP öffnet (Ohne jemals sich mit einem User darauf angemeldet zu haben) in der Sidebar alle Elemente zugeklappt sind, außer "Klassische Serie". Fakt ist, für eine Person, die zum aller-ersten Mal die PP öffnet, ist weder in der Sidebar der "Hilfe-Link" zu sehen noch im Homepage-Text. Hier gibt es zwar die Links "Willkommen" oder "Ich brauche Hilfe" (der ist für Ersteinsteiger aber wenig nützlich). Man muss erst "Mitmachen" oder "Willkommen" anklicken um an den Link Hilfe:Handbuch zu kommen. Ich will es nicht dramatisieren, aber für einige war das offensichtlich schon eine Hürde. Vielleicht genügt es schon den Hilfe-Link aus dem Element "Mitmachen" raus zu nehmen und auf die Hauptebene zu verschieben. --Norman (Diskussion) 11:20, 6. Jun. 2018 (CEST)

Den Link zur Hilfe:Handbuch kann man prominent dem Navigationsbereich der Sidebar hinzufügen, d. h. da, wo auch die Hauptseite, das Portal und die Kategorien aufgeführt sind. Noch oberhalb der Klassischen Serie. Der Link ist dann immer und für jeden permanent sichtbar. Es müsste nur auf der Seite MediaWiki:Sidebar eine weitere Zeile mit dem Inhalt ** Hilfe:Handbuch|Hilfe eingefügt werden. Beispielsweise unterhalb von der Zeile ** Spezial:Zufällige Seite|Zufällige Seite und oberhalb der Leerzeile über dem * Klassische Serie. --WGK.derdicke (Diskussion) 15:35, 6. Jun. 2018 (CEST)

Auch "Ich brauche Hilfe" verweist am Anfang wieder auf "Grundregeln" und "Handbuch" ...!
Entschuldigt bitte, wenn ich das jetzt krass ausdrücke: Jemand, der sich nicht traut, auf der Hauptseite "Willkommen" anzuklicken oder in der Sidebar das Untermenü "Mitmachen" aufzuklappen ... so jemand ist für mich kein geeigneter Kandidat für die Mitarbeit hier. Eure Argumentation ist für mich absurd. Ein paar Grundkenntnisse in der Bedienung von Computern müssen hier schon mitgebracht werden. Wetten, dass kein 10-Jähriger Schwierigkeiten hätte, in der Perrypedia die Hilfeseiten zu finden? Unser Problem ist, dass Perry Rhodan kaum noch 10-jährigen Nachwuchs hat. Das wird sich nicht ändern, wenn ich den Hilfe-Button nach oben schiebe. --Klenzy (Diskussion) 15:55, 6. Jun. 2018 (CEST)
Ich denke, dass es sich dabei um zwei verschiedene Klientel handelt.
Dass der 10-jährige Nachwuchs zur seltenen Spezies gerät, ist ja nun kein PR-spezifisches Dilemma. Das liegt dann eher an dem Transportmedium für PR: das geschriebene Wort. Dieses ist dann doch schon ein wenig abstrakter als irgend eine TV-Serie oder die Daddelei mit der Playsi und kann ziemlich dröge wirken. Und sicher kann man auch nicht den 10-jährigen Nachwuchs mit dem nach oben geschobenen Hilfe-Button hinter der Playsi hervorlocken.
Andererseits gibt es genug Leute, welche eine Mediawiki-Website (in der Regel die Wikipedia) irgendwie nur als Nur-Lesen-Website kennen und begreifen und über die eigentlich sehr einfache Möglichkeit des Mitwirkens einfach nicht Bescheid wissen. Oder das zwar wissen, vom Wikitext aber abgeschreckt werden. Und ich meine da nicht extensive Vorlagenprogrammierung sondern die "einfache" Formatierung von Überschriften, Fettschrift, Kursivschrift und die Links zu anderen Seiten. Es ist halt schon ein wenig nerdig. Aber auch dass ist kein PR-spezifisches Problem. Da kämpfen die bei der Wikpedia ja auch schon länger mit. Nicht umsonst gibt es da ja jetzt die Möglichkeit, nicht nur den Quelltext zu editieren sondern auch mit einem WYSIWYG-Editor die Seiten zu bearbeiten. Nun, und die Leute, die sich ein wenig schwer tun, werden möglicherweise von einem schwerer auffindbaren Hilfebereich abgeschreckt und geben schneller auf. Der Einwand zu den schlecht sichtbaren Hilfeseiten kam ja nun. Denen kann man aber helfen: mit einem nach oben geschobenen Hilfe-Button.
Der 10-jährige Nachwuchs ist eine andere Baustelle. --WGK.derdicke (Diskussion) 17:46, 6. Jun. 2018 (CEST)
In Garching haben mir viele Fans gesagt, sie würden gern mitmachen, haben aber Angst, dass sie etwas falsches reinstellen und dann gescholten werden. Einige meinten auch, dass nach dem ersten oder zweiten Artikel die PPnauten über sie hergefallen sind und die Arbeit in Frage gestellt haben. Ich kann jetzt leider keine Beispiele nennen, bin auch zu wenig aktiv, um das beurteilen zu können. Falls es so ist, sollte dieses Verhalten hinterfragt werden. Wir sollten die Leute aktiv loben, die sich neu anmelden. Nicht nur mit dem Standardtext, sondern persönlich. (Tostan) 18:22, 6. Jun. 2018 (CEST)
Ich lese das immer wieder. Und immer hätte ich gern konkrete Beispiele, es kommen aber keine. Ich selbst mache es so: Neuer Nutzer ändert einen Artikel oder schreibt einen eigenen, z.B. eine Handlungszusammenfassung. Ich lese das und ändere, was mir falsch vorkommt. Zunächst einmal belasse ich es dabei. Es könnte ja sein, dass ein Lerneffekt eintritt. Wenn der Nutzer dieselben Fehler aber immer wieder macht, versuche ich ihn in seiner Diskussionsseite vorsichtig darauf hinzuweisen, wie man es richtig machen kann. Also nicht in Form von aggressiver Kritik, sondern als Tipp formuliert. Keine Ahnung, ob mir das immer gelingt, aber hier haben wir das Problem, dass oft etwas beim Empfänger ganz anders ankommt, als der Sender es gemeint hat. Und ja, ich lobe durchaus, d.h. bevor ich sage, das und das solltest du so und so machen, kommt meistens ein Satz wie "Danke für deine Mitarbeit, du machst das gut" oder so. Manchmal habe ich den Eindruck, dass manche Leute einfach ein Problem damit haben, dass a) alle anderen ihre Texte ändern können und b) sie sich an Regeln halten sollen, die sich in der PP etabliert haben. Da kann man dann halt nichts machen. --Johannes Kreis (Diskussion) 06:46, 7. Jun. 2018 (CEST)
Genau. Da pflegt jeder seinen ganz eigenen Blickwinkel. Und so mancher Blickwinkel ist dann so gar nicht kompalibel. Ein generelles Problem scheint mir die immer stärker grassierende Kritikunfähigkeit zu sein. Viele kennen exakt genau zwei Meinungen zu jedem Thema: Die eigene und die falsche. Da ist dann Unmut vorprogrammiert. Allerdings steht auch die Tatsache, dass erst einmal alle alles ändern können, dies aber nur nach gewissen Konventionen, schon ein wenig konträr zur aktuell sehr egozentrisch ausgerichteten Gesellschaft. Da fühlt sich dann schon der oder jener ans Bein gepinkelt, wenn auch nur ein Komma von jemand anderem verschoben wird. Eine gewisse Teamfähigkeit braucht's schon beim Mitwirken an einem Wiki, an dem mehr als ein User aktiv ist. Vielleicht ist ja das ein Thema, die Teamfähigkeit, welches auf einer Seite wie Perrypedia:Willkommen ein wenig stärker thematisiert werden sollte. Auch kommt mit die Startseite des Handbuchs ein wenig technokratisch vor. Will sagen, der Schwerpunkt liegt da eher auf den technischen Aspekten. Wenn man da gleich zu Anfang ein wenig über die Art und Weise der Zusammenarbeit und dem Regelwerk unter sozialen Aspekten referrieren würde, ist vielleicht der Schock nicht ganz so groß, wenn etwas von anderen geändert wird, es zur Kritik kommt oder der Fingerzeig Richtung Regelwerk zeigt. Nicht jeder ist ja von Haus aus gleich sofort wikikompatibel, das muss man auch erst einmal lernen. Und wenn der Weg, wohin die Reise geht, gleich am Anfang klar benannt wird, ist die Enttäuschung vielleicht nicht mehr ganz so groß, als wenn einem später, nach getätigten Änderungen, aus heiterem Himmel der Blitz in Form von Kritik oder Verweise auf das Regelwerk ganz unvermutet erwischt. --WGK.derdicke (Diskussion) 09:54, 7. Jun. 2018 (CEST)
@WGK, zu deinem Beitrag von gestern 15:35, 6. Jun. 2018 (CEST). Gut, ich mach das mal mit dem Hilfe-Link. Es widerstrebt mir zwar, aber euer Votum ist eindeutig.
Meine Bedenken: Die Hilfe-Seite ist die Hilfe zum Mitmachen und steht genau deshalb unter "Mitmachen". An der neuen Stelle würde ich, gesetzt den Fall als unbedarfter Leser, es für eine allgemeine Hilfe zur Bedienung der Perrypedia halten. Das ist sie aber nicht. Damit der Link wenigstens in der räumlichen Nähe zu "Mitmachen" bleibt, schiebe ich auch das gesamte "Mitmachen" nach oben. Ich glaube nicht, dass das irgendwas bringt. Ich halte die "schlechte Sichtbarkeit" oder "schwerere Auffindbarkeit" der Hilfeseiten für ein vorgeschobenes Alibi für die fehlende Motivation. Die fehlende Motivation mag nun verschiedene Ursachen haben, da habe ich das mit den 10-Jährigen schon so ähnlich gemeint wie Du schreibst. Meine Überlegung ist, dass wir ein strukturelles Problem haben. 10- bis 20-Jährige hätten die Zeit, aber kein Interesse. 20- bis 60-Jährige hätten vielleicht Interesse, aber normalerweise keine Zeit. Und dann schiebt solchereiner, auf die Frage wer mitmachen will, gern eine billige Ausrede vor. --Klenzy (Diskussion) 10:38, 7. Jun. 2018 (CEST)
Vorstellen könnte man sich auch, dass dieser Link zweimal auftaucht. Oben und unter Mitmachen. Vorstellen könnte man sich auch, dass das Handbuch da bleibt, wo es war, nämlich unter der Rubrik Mitmachen und dass oben, dann vielleicht direkt unter dem Hauptseitenlink, auf die Willkommens-Seite (Linktext Willkommen) verlinkt wird. --WGK.derdicke (Diskussion) 11:47, 7. Jun. 2018 (CEST)
Jaaa, wir nähern uns einer guten Lösung. Neuer Versuch: Willkommen! ganz oben, dann Hauptseite, Portal, ... Hilfe wieder unter "Mitmachen", aber noch vor Classic/Neo. Doch, ich sehe den Vorteil, "Willkommen!" gibt es jetzt auf jeder Seite. Ok so? --Klenzy (Diskussion) 13:59, 7. Jun. 2018 (CEST)
Einen hätte ich ja noch :-) Ich persönlich finde die alte Reihenfolge der Klappmenüs etwas logischer als das Mitmachen vor den beiden inhaltlichen Rubriken, also diese Reihenfolge:
  • Klassische Serie
  • Perry Rhodan Neo
  • Mitmachen
  • Formatvorlagen
  • Werkzeuge
Diese ursprüngliche Reihenfolge liest sich dann für mich so:
  1. Worum geht's?
  2. Wenn man mitmachen will, wie?
  3. Und womit?
Wie gesagt, klingt für mich logisch. --WGK.derdicke (Diskussion) 15:45, 7. Jun. 2018 (CEST)
Na ja, das stimmt natürlich. Neuer Versuch ... --Klenzy (Diskussion) 15:58, 7. Jun. 2018 (CEST)
Wobei, ich hatte jetzt nicht damit gerechnet, dass der immer sichtbare Hilfe-Link unter der Zufälligen Seite nun wieder auftaucht. Ich dachte, dass der immer sichtbare Hilfe-Link hervorragend durch das zu oberst hinzugefügte Willkommen! ersetzt wird und eigentlich nur die Reihenfolge der Klappmenüs gemeint. Allerdings ist das auch nur meine bescheidene Meinung. So tut's auch. --WGK.derdicke (Diskussion) 17:45, 7. Jun. 2018 (CEST)
So, nun zu den ehemaligen und potentiellen Mitarbeitern (WGK 17:46, 6. Jun. 2018 (CEST), und darauffolgende Posts von Tostan, Johannes und WGK). Ursprünglich hielt ich mein Feedback zum Feedback für Off topic, aber mittlerweile haben alle Diskussionsteilnehmer den Punkt aufgegriffen, somit passt das nicht auf Tostans Diskussionsseite, wohin ich zuerst ausweichen wollte.
Einer der Punkte war: Mediawiki-Webseiten/Wikipedia/Perrypedia werden als Nur-Lesen-Website aufgefasst. Die Einschätzung teile ich nicht. Wer im Internet unteregs ist, dürfte im Normalfall wissen, dass die Wikipedia ein Online-Lexikon ist, das "irgendwie von irgendwelchen Leuten in ihrer Freizeit" gebastelt wird. In der Sidebar gibt es "Mitmachen", das ist unmissverständlich! Auf der Hauptseite befassen sich an prominenter Stelle zwei Absätze mit fünf Links mit verschiedenen Möglichkeiten des leichten Einstiegs. In der Erstauflage haben wir zweimal eine ganzseitige Anzeige mit einem Aufruf zur Mitarbeit geschaltet. Im PR-Forum wird ganz klar herausgestellt, dass PP ein Projekt von Fans für Fans ist. Wer dort unterwegs ist, weiß, dass jede(r) mitmachen kann und darf. Die Berichte von diesem und anderen Cons zeigen für mich, dass die dort anzutreffenden Fans das sehr wohl wissen.
Ein anderer Punkt ist der Wikitext. Da stimme ich zu, der wirkt anfangs abschreckend. Der Visual Editor spukt mir seit einiger Zeit im Hinterkopf herum. Zuvor allerdings steht andere Arbeit an, der Long-Term-Support für unser Linux 14.04 läuft April 2019 ab und für die Mediawiki 1.27.4 im Juni 2019. Das werde ich im Herbst angehen, da ich nicht bis zum letzten Tag warten will.
Dann: Angst, etwas falsch zu machen und gescholten zu werden (Tostan). Zunächst bekommt jeder, der sich hier anmeldet, eine Begrüßung mit einigen nützlichen Links, unter anderem "Vorstellung der Perrypedia" (wieder Perrypedia:Willkommen wie auf der Hauptseite) und "Sei mutig!" (Hilfe:Beteiligen, eine Seite, auf die man auch sehr schnell stößt, wenn man Hilfe:Handbuch aufschlägt). Ich bin nun schon ein paar Tage dabei, daher vielleicht betriebsblind? Nach meiner Meinung wird auf Hilfe:Beteiligen sehr detailliert und behutsam auf mögliche Sorgen eingegangen, auch Perrypedia:Willkommen widmet sich unter anderem der Zusammenarbeit im Team. Auf den späteren Post (WGK) bezogen: Also, wenn es da nicht ausführlich um soziale Fragen, um Fragen der Zusammenarbeit geht, dann weiß ich auch nicht. Man muss es halt aber auch lesen - das können wir niemandem abnehmen. Wenn wir noch mehr schreiben, wird die Zahl derjenigen, die es lesen, aller Voraussicht nach kleiner.
Ein heftiger Vorwurf ist: PPnauten sind über Anfänger hergefallen und haben die Beiträge in Frage gestellt. Tostan, Du hast dich fast dafür entschuldigt, keine Beispiele genannt zu haben; das darfst Du auch gar nicht, diese Leute haben sich vertrauensvoll an dich gewandt, dann wäre die Namen zu nennen ein Vertrauensbruch. Johannes ist schon ein wenig darauf eingegangen, ich möchte dazu ein wenig mehr aus der Sicht des Insiders schildern. In den vergangenen sechs Jahren, die ich jetzt dabei bin, wurde genau ein PPnaut vor die Tür gesetzt. Alle anderen, die aufgehört haben, sind freiwillig gegangen. Dabei gehen die meisten leise, ohne etwas zu sagen und solange wir es nicht besser wissen, dürfen wir davon ausgehen, dass es dafür unterschiedliche verständliche Gründe gibt. Keine Zeit mehr, keine Lust, andere Interessen. Das ist schade, aber durchaus nachvollziehbar, und da können wir auch absolut nichts tun. Dann gibt es diejenigen, die sich vorher zu Wort melden und das auf unterschiedliche Weise. Manche sind sehr engagiert, aber auch kompromissbereit, und mit denen haben wir uns immer einigen können. Einige wenige kommen aber her, wollen alles radikal verändern und werden laut und unsachlich, wenn Fragen gestellt werden. In einem Fall gipfelte das in Erpressung ("wenn nicht dies und jenes, dann gehe ich"). Da kann ich nur sagen: Wie es in den Wald hineinhallt ... wir gehen auf jeden erst einmal neutral-freundlich zu, wie Johannes beschrieben hat; aber wer das Maul aufreißt und unfreundlich wird, muss mit Gegenwind rechnen. Das ist in einem Wiki so. Aus Sicht des schon länger hier gewesenen ist das ebenso unerfreulich, es wird viel Zeit investiert, um einen Neuen "zum Laufen" zu bringen - das können schon 10, 20 oder mehr Stunden sein, und dann erweist sich derjenige als völlig beratungsresistent, wirft hin und geht womöglich noch mit einem großen Knall. Oder ein anderer Fall: Da wurde selbst behutsame Kritik gleich als vernichtende Breitseite verstanden. Aus der Perrypedia zog sich derjenige dann zurück und beschwerte sich dafür bei Nils Hirseland! Bedaure, dass ich dafür kein Verständnis habe und mit einem Zitat von I. van Bergen reagiere: Wer hinter meinem Rücken über mich redet, der redet mit meinem Arsch!
Unverzichtbar für die Mitarbeit in der Perrypedia ist die Fähigkeit, mit anderen Leuten zusammenzuarbeiten, Kompromisse einzugehen und - ja, auch das: sich an bestehende Regeln zu halten. Bei denjenigen, die in der letzten Zeit unter Protest hier aufgehört haben, war in jedem einzelnen Fall keineswegs irgendein böser PP-Mitarbeiter daran der Alleinschuldige, sondern es hat jeweils an mindestens einem dieser Punkte gekrankt.
Entschuldigt bitte, dass ich jetzt etwas ausführlicher und heftiger als geplant geworden bin. Was mir gelegentlich sauer aufstößt, ist die abseits der PP geäußerte Pauschalkritik an der PP. Fundierte Kritik ist natürlich jederzeit erlaubt. Wie man am Beispiel dieser Diskussion sieht, können dabei viele Ideen entstehen. Mehr Öffentlichkeitsarbeit; Videos; Powerpoint-Präsentationen ... kommen wir wie fast immer zu Killerfrage: Wer kanns, und wer machts?
(Diskussion) 7. Juni 2018, 12:46 Uhr

+

Entschuldigt bitte, dass ich jetzt etwas ausführlicher und heftiger als geplant geworden bin. Was mir gelegentlich sauer aufstößt, ist die abseits der PP geäußerte Pauschalkritik an der PP. Fundierte Kritik ist natürlich jederzeit erlaubt. Wie man am Beispiel dieser Diskussion sieht, können dabei viele Ideen entstehen. Mehr Öffentlichkeitsarbeit; Videos; Powerpoint-Präsentationen ... kommen wir wie fast immer zu Killerfrage: Wer kanns, und wer machts?

(Diskussion) 7. Juni 2018, 12:46 Uhr

Gute Zusammenfassung. Danke. Leider braucht man halt immer eine dicke Haut.
Zur Killerfrage. Da verhalte ich mich leider immer wie beim Bund, wenn es hieß "Freiwillige vor!" Und dann bleibt die Arbeit doch immer an einem Dummen hängen. --Thinman (Diskussion) 16:01, 7. Jun. 2018 (CEST)
Die meisten haben wahrscheinlich – bei grundsätzlichem Interesse - wie oben formuliert „Angst, etwas falsch zu machen“ (die rein technische Hemmschwelle der Wikibedienung halte ich für eher gering). Das beginnt schon beim Schreiben eines Artikels (wie gut kann ich kann das überhaupt, wie schwer fällt mir das etc.), das betrifft formale Aspekte und natürlich die Quellenangaben etc. Wenn ich mich an meinen Start erinnere, so wars auch ein Sprung ins „kalte Wasser“ und diesen Sprung kann man niemanden abnehmen. Und dann gibts natürlich anfangs eine Lernphase, in der man auch sich selbst einmal austesten muss. Stört es mich, wenn jemand eine Formulierung, auf die ich „stolz“ bin, umschreibt? Oder akzeptiere ich zB. die bessere Lesbarkeit des Artikels durch die Korrektur etc. Positives Feedback erleichtert natürlich den Einstieg. Und schließlich, ganz wichtig, soll es auch Spass machen. (Für mich wars zB. neben einem stressigen Job für viele Jahre ein guter Ausgleich, weil ich dabei an ganz etwas Anderes denken konnte.) Aber ich persönlich würde nicht den Anspruch der PP (wie Quellengenauigkeit, lesbare Artikel ...) für mehr Mitarbeiter aufgeben wollen. Aber natürlich sind es zu wenige, die hier mitmachen. Ich bin ja selbst derzeit auch nicht gerade ein leuchtendes Beispiel für eifrige Mitarbeit ... --NikNik (Diskussion) 19:09, 7. Jun. 2018 (CEST)
Die Hemmschwelle der Leute ist einfach groß. Angst, etwas falsch zu machen dominiert. Aber vielleicht hilft da ja Power Point. Tostan 23:39, 7. Jun. 2018 (CEST)
Da ich gerade vor kurzem im Forum folgenden Thread gelesen habe: https://forum.perry-rhodan.net/viewtopic.php?f=62&t=10699
Rein zwecks Hemmschwelle niedrig halten wäre natürlich am besten, Leute einfach machen zu lassen. Korrekturen wenn überhaupt auf formales beschränkt zu lassen. Jede Anmerkung zu "Fehlern" kann emotional total verständlich wenn jemand vielleicht initial ohnehin etwas zögerlich ist, abschreckend wirken.
Was für eine Art Formulierung beim auf Fehler hinweisen negativ ankommt lässt sich nun aber - gerade bei schriftlicher Kommunikation - nicht sagen. Man kennt die Menschen ja nicht und z.B. mag jemand auf Gewaltfreie Kommunikation total allergisch / sich verar... fühlend reagieren, um mal was zu nennen, was eigentlich spitze ist bezüglich Kommunikation. Oder darauf, dass der "eigene" Artikel 3 mal nachgebessert wurde, ohne dass einen jemand einfach klar drauf anspricht, was falsch läuft. Oder halt darauf, dass man klar darauf angesprochen wurde. Oder weil man keine vollständige Erklärung erhält. Oder genau weil man eine vollständige und damit elendig lange Erklärung erhalten hat. ...
Ist eine komplexe Geschichte, die sich nur durch allmählich gegeneinander herantasten und ausloten, was geht/was nicht geht, lösen lässt. Wie halt auch im "echten" Leben, wenn man zu einem neuen Team (sei es im Beruf oder auf Freizeit z.B. in einem Verein) kommt. Rein schriftlich nur so viel schwieriger. Kann nur mit beidseitig guten Willen und Geduld gelingen.
Unsere "Kundschaft" ist der weilen ob der Qualität entsetzt (Bezug zum Forum, siehe oben) und würde gleich alles radikal umstrukturieren.
Die Tendenz zur Umstrukturieren, äußerliches/formales ändern kenne ich auch aus der Arbeitswelt. Hab jetzt noch nie erlebt, dass das was gebracht hat.
Am Ende stehen im Kern doch immer die Menschen und deren Umgang miteinander und _gegenseitig_ . :-) --NAN (Diskussion|Beiträge) 15:17, 23. Dez. 2018 (CET)

Vorlagen – Trennung von Code, Doku und Diskussion

Wie in der Wikipedia oder auch in „meinem“ Wiki macht es imho Sinn, bei Vorlagen den Code, die dazugehörige Dokumentation und die darüber geführte Diskussion zu trennen. Dies dient einerseits der Übersicht. Für den Fall, dass die Dokumentation ursprünglich direkt in der Vorlage und nicht auf der Diskussionsseite hinterlegt war, ergibt sich zudem beim Parsen der Seiten, welche die Vorlagen verwenden, der Vorteil, dass weniger exkludierter und somit nicht zu parsender Text geladen werden muss.

Um die Trennung von Vorlage und Dokumentation zu erhalten, bei Aufruf der Vorlage aber trotzdem die Dokumentation angezeigt zu bekommen, habe ich eine Vorlage namens Vorlage:Dokumentation eingerichtet. Statt des in der Vorlage befindlichen Dokumentationstextes wird diese Vorlage dort aufgerufen. Der Dokumentationstext wird in einer separaten Unterseite dazu gespeichert. Wie die Vorgehensweise dabei ist, habe ich in der Dokumentation zu eben dieser Vorlage:Dokumentation beschrieben.

Bei der Vorlage:Tabellenelement Silber Edition habe ich die Anwendung demonstriert. Der Programmcode der eigentlichen Vorlage ist, wie gewohnt, in eben dieser zu finden (Vorlage:Tabellenelement Silber Edition). Ruft man diese Vorlage auf, so wird mittels der dort aufgerufenen Vorlage:Dokumentation die dazugehörige Dokumentationseite angezeigt. Die Dokumentation ist dabei in der Unterseite Vorlage:Tabellenelement Silber Edition/Doku gespeichert. Unabhängig davon kann dann die Diskussion über die Vorlage bzw. deren Dokumentation auf den jeweiligen Diskussionsseiten geführt werden. Dies wären dann Vorlage Diskussion:Tabellenelement Silber Edition für den Programmcode der Vorlage und, sofern man dies separieren möchte, Vorlage Diskussion:Tabellenelement Silber Edition/Doku für die Dokumentation der Vorlage.

Zur Kategorisierung der Dokumentationen habe ich die Kategorie:Vorlagendokumentation angelegt.

Ich hoffe ja, dass dies auf ein wenig Anklang trifft.--WGK.derdicke (Diskussion) 20:13, 17. Dez. 2017 (CET)

Ich bin nicht überzeugt. Mit deiner Dokumentationsvorlage ist zwar der Aufwand für die getrennte Pflege von Vorlage und Dokumentation minimal, leider erscheint mir aber auch der Nutzen minimal. Mir persönlich ist es lieber, Vorlage und Doku zusammen zu haben.
@all, wie seht ihr das? --Klenzy (Diskussion) 13:56, 18. Dez. 2017 (CET)
Weiß nicht. Für mich sind das böhmische Dörfer. Bin schon froh, Diskussionen hinzukriegen, tiefer werde ich nicht in die Materie einsteigen. An die Formatvorlagen gehe ich nur ganz selten und mische mich höchstens ein, wenn es um Inhalte geht. Zu kompliziert sollten wir es hier nicht handhaben, ist sowieso schon alles unübersichtlich genug und schwer zu lernen. Anfänger sind hier ja gerade nicht an jeder Ecke zu finden. Vielleicht sollten wir denen auch noch eine Chance lassen? Will sagen, wenn das nur für die Experten ist, macht ruhig. Wenn es alle benutzen müssen, dann lieber nicht. --Pisanelli (Diskussion) 19:11, 18. Dez. 2017 (CET)
Der Vorschlag beinhaltet auf jeden Fall eine saubere Strukturierung. Allerdings ist es mir schon fast zu abstrakt und es ist "nur" für Vorlagen relevant, die von den allermeisten "Normaluser" nur indirekt benutzt werden. Eine Umstellung (sprich Auftrennung in Cod & Doku) der schon vorhanden Vorlagen ist Aufwand, der "nur" strukturellen aber keinen funktionellen Charakter hat (Mehrwert?). Auf der anderen Seite, solten wir unser Neumitglied nicht demotivieren und es auch nicht als unnötig bewerten! Vielleicht können wir das zuerst einmal ja "nur" für neue Vorlagen so machen? Gibt es denn kein anderes Thema bei dem uns WGK.derdicke mit seinen Fähigikeiten / KnowHow helfen könnte? --Norman (Diskussion) 21:53, 18. Dez. 2017 (CET)
In der Tat findet der Mehrwert „nur“ unter der Motorhaube statt, ist also keine so offensichtliche Änderung wie eine Modifikation der Sidebar, der Mainpage oder so publikumswirksam wie eine völlige Änderung des Skins.
Dies hier ist der Mehrwert:
  • Performance #1 - Beim Erstellen/Änderung der Seiten wird Wikitext im Editor eingegeben. Der muss zur Anzeige zu HTML gemacht werden. Werden Vorlagen auf einer Seite verwendet, so wird bei Änderung der Seite der Inhalt jeder Vorlage bei jedem Aufruf der Vorlage zur Übersetzung von Wikitext nach HTML geladen. Hat man viel Kommentar direkt in der Vorlage, so wird erst immer viel Text geladen, dann aber doch nicht übersetzt, da in <noinclude>-Tags. Mit lediglich dem Aufruf der Vorlage:Dokumentation innerhalb der eigentlichen Vorlage wird die Menge des zu ladenden, aber nicht übersetzten Textes vermindert.
  • Performance #2 - Wird lediglich die Dokumentation einer Vorlage geändert, so werden, hat man den Kommentar direkt in der Vorlage, bei jeder Änderung auch immer diejenigen Seiten neu übersetzt, welche die Vorlage aufrufen. Liegt die Dokumentation in einer Unterseite der Vorlage, so wird lediglich die geänderte Unterseite bearbeitet.
  • Sicherheit - Befindet sich die Dokumentation einer Vorlage auf einer Unterseite, so kann die eigentliche Vorlage gesperrt bleiben, die Dokumentation kann aber verbessert werden, ohne die Vorlage vorab erst zu entsperren und danach wieder zu sperren.
  • Übersicht #1 - Würden alle Vorlagen unter Verwendung dieser Dokumentationsvorlage dokumentiert, so sieht man beim Aufruf der Vorlage sofort die Dokumentation, wenn vorhanden bzw. einen Hinweise, dass diese noch fehlt. Derzeit gibt es Vorlagen, welche die Dokumentation beim Aufruf direkt anzeigen, und andere, bei denen sie auf der Dokumentationsseite liegt und wieder andere, bei denen sie fehlt und man vielleicht erst mühselig die Verwendung beim Ersteller hinterfragen muss.
  • Übersicht #2 - Wird eine aufwändige Vorlage (im Entstehungsprozess) öfter geändert und die Dokumentation nebenbei angepasst, so zeigt die Versionshistorie der Vorlage, wenn man den Kommentar direkt in der Vorlage hat, linear alle Änderungen an Code und Dokumentation an. Die coderelevanten Änderungen sind schwerer in der Versionshbistorie identifizierbar. Der Code wird schwieriger zu warten.
  • Übersicht #3 - Wird die Vorlage auf der Diskussionsseite dokumentiert, so zeigt die Versionshistorie der Diskussionsseite linear alle Änderungen an der Dokumentation und den Stand der Diskussion. Es ist schwieriger zu identifizieren, ob eine Änderung an der Dokumentation vorliegt oder ob „lediglich Meinungsäußerung“ betrieben wird.
Die „allermeisten Normaluser“, denen es um Inhalte geht, sind von der Anwendung dieser Dokumentationsvorlage gar nicht betroffen, da sie in der Regel bestehende Vorlagen auf den Seiten anwenden und vielleicht einmal die Vorlage direkt aufrufen, um in der Dokumentation Hinweise auf die Verwendung zu finden. Es besteht also überhaupt kein Bedarf, tiefer in die Materie einzusteigen als bis dato auch. Insofern ist die Anwendung dieser Dokumentationsvorlage „nur für die Experten“, es ergeben sich keine Veränderungen für alle.
Für diejenigen, welche Vorlagen erstellen, ist, wie Klenzy es schjon sagte, „der Aufwand für die getrennte Pflege von Vorlage und Dokumentation minimal“. Die Verwendung der entsprechenden Tags zur Trennung von Code und Dokumentation in einer Vorlage ist ohnehin Pflicht für eine korrekte Funktionsweise. Und auch unter Verwendung der Dokumnentationsvorlage sind Vorlage und Doku quasi „zusammen“, da die Dokumentation nicht auf irgendeiner beliebigen Seite abgelegt wird sondern immer zusammen mit der Vorlage auf einer Unterseite dieser. Lautet der Vorlagenname "4711", so lautet der Name der Seite mit der Dokumentation dazu immer "4711/Doku".
Muss denn diese Dokumentationsvorlage jetzt umgehend bei allen Vorlagen angewendet werden? Wie man sieht, gibt es da kein hartes Entweder/Oder. Die Vorlage:Dokumentation wird bei der Vorlage:Tabellenelement Silber Edition verwendet, bei anderen Vorlagen nicht. Die Vorlage:Dokumentation steht zur Verfügung, und kann von jedem, der sie anwenden will, benutzt werden.
Zudem wird das Konzept der Vorlagendokumentation auf Unterseiten mittels einer Dokumentationsvorlage durchaus in vielen Wikis angewendet (Wikis in DE, Wikis weltweit). Da scheint also was dranne zu sein.
Und nun wünsche ich allen ein frohes und besinnliches Weihnachtsfest!--WGK.derdicke (Diskussion) 22:18, 23. Dez. 2017 (CET)
Servus WGK, danke für die ausführliche Erläuterung. Wäre nicht nötig gewesen, ich verstehe deine Argumentation ja, nur setze ich andere Prioritäten und komme daher zu einem anderen Ergebnis. Der Performancegewinn #1 beim <noinclude> ist für den Benutzer nicht messbar und für die Maschine vernachlässigbar gering. Für die Maschine relevant ist allenfalls #2, der Wegfall der Seitenaktualisierung, btw auch nur deshalb, weil Mediawiki zu doof ist zu erkennen, dass sich nur der Noinclude-Text geändert hat ... wir puffern das ab, indem die Vorlagen geschützt sind. Änderungen werden erst im Testwiki ausprobiert und wenn die Vorlage dann rund läuft und die Dokumentation passt, erfolgt einmalig die Übernahme ins Echtwiki. Das hat sich gut bewährt. Ich kann mich an keinen einzigen Fall erinnern, in dem nur die Dokumentation verbessert wurde; Codierung und Doku geschehen immer Hand in Hand.
Die Argumente zur Übersicht gewichte ich ebenfalls anders. #1: Unzutreffend, die Doku steht derzeit entweder auf der Vorlagenseite oder existiert nicht. Den einen Ausnahmefall mit getrennter Doku hast Du selbst erst geschaffen ;-) #3: Welche Vorlagen sollen das sein? Das geht natürlich nicht, das ist falsch. Übersicht #2 ist dagegen ein gutes Argument, das lasse ich gelten.
Alles in allem bin ich zwar weiterhin skeptisch. Die Argumente "Pro" halte ich für mager. Andererseits sehe ich keine irgendwie relevanten Argumente "Contra". Technische Bedenken habe ich nicht, und für die Verwendung von Vorlagen durch Otto Normalbenutzer ändert sich nichts. Den Kompromiss habt ihr, WGK und Norman, ja bereits umrissen: Die neue Vorgehensweise gilt für die Vorlage:Tabellenelement Silber Edition als akzeptiert und kann von nun an für neue Vorlagen verwendet werden. Passt.
In lediglich einem Punkt erhebe ich Einspruch. Ich bitte darum, die Kategorie:Vorlagendokumentation wieder abzuschaffen. Die Separat-Dokumentationen hätte ich gern unter derselben Kategorie wie die Vorlage, also Kategorie:Textbausteine. Mag sein, dass ich das später überdenke, aber derzeit erscheint es mir sinnvoller in einer Kategorie (in der ich dann, übrigens, mit einem Blick sehe, wo es eine Separat-Doku gibt und wo nicht).
Vor der Neuanlage von Kategorien bitte zukünftig unsere Hausregel beachten: Perrypedia Diskussion:Liste aller Kategorien. Danke & VG --Klenzy (Diskussion) 10:28, 27. Dez. 2017 (CET)
Hallo. Die Separat-Dokumentationen habe ich von Kategorie:Vorlagendokumentation nach Kategorie:Textbausteine verschoben, die Kategorie:Vorlagendokumentation aus der Perrypedia:Liste aller Kategorien entfernt und zum Löschen markiert. Den Hinweis auf Perrypedia Diskussion:Liste aller Kategorien zum Einrichten neuer Kategorien hatte ich nicht entdeckt, da ich nicht bis zur Disk gekommen bin. Die Kategorisierung von Nur-Doku-Vorlagen in einer separatenm Kategorie wird auch anderswo gepflegt und ist mir logisch. Deswegen bin ich da umgehend zur Tat geschritten. Allerdings ist auch Dein Gedankengang, alles „mit einem Blick“ zu sehen, nicht unsympathisch.
Den Performancegewinn beim <noinclude> kann ich in der Tat nicht beurteilen. Er ist aber da. Mag sein, dass er vernachlässigbar gering ausfällt. Die Entwicklung einer Vorlage in einem Testwiki ist natürlich komfortabel und erzeugt dann im „echten“ Wiki auch nicht eine längere und ggf. unübersichtliche Versionshistorie. Insofern ist der Performancegewinn durch weniger Seitenaktualisierung auch relativ. Zumal ja viele Vorlagen, zumindest die, die ich mir mal so angeschaut habe, eher einen kurzer Textbaustein statt ein aufwändiger komplexer Code darstellen und mit einer separaten Vorlagendokumentation selbst in meinen Augen :-) fast schon überdokumentiert wirken würden. Eine separaten Vorlagendokumentation bei komplexeren Vorlagen mit viel „echtem Wikicode“ in Kombination mit Entwicklung im „echten“ Wiki statt im Textwiki, erstellt im Zweifelsfall von mehreren Personen, ist dort ein wenig mehr zu Hause als bei einem kurzen, halbsatzlagen Textbaustein.
In der Tat habe ich keine Vorlagen gesehen, bei denen die Doku auf der Disk war. Ich hatte mir einige existierende Vorlagen angeschaut. Bei der einen Hälfte war die Doku in der Vorlage, bei der anderen Hälfte war die Doku nicht vorhanden. Aber die Kategorie:Textbausteine legt in ihrer „Anmoderation“ nahe, dass die Doku entweder „unter Textbausteine oder in der Diskussionsseite der jeweiligen Vorlage“ liegen würde. Insofern hatte ich vermutet, dass schon mal auch Doku auf Diskussionsseiten zu finden ist.
Auch von mir VG und ein frohes neues Jahr! --WGK.derdicke (Diskussion) 19:47, 27. Dez. 2017 (CET)
Ah, jetzt sehe ich es auch. Die Beschreibung der Kategorie ist Sch..marrn! Ich sehe schon, Du bist eine echte Bereicherung für uns. Danke für die Info! --Klenzy (Diskussion) 20:07, 27. Dez. 2017 (CET)

»Aktuelle Handlung« in der Sidebar

Die Sidebar (seitliche Menüleiste mit "Hauptseite, Portal, Kategorien, Exzellente Artikel...") liegt ja im Mediawiki-Namensraum und ist daher bewusst nur für Admins zu ändern. Das ist etwas unpraktisch, wenn ein neuer Zyklus oder eine neue Neo-Staffel beginnt. Daher gibt es ab jetzt Vorlage:Aktueller Zyklus und Vorlage:Aktuelle Neo-Staffel, die ist für alle bestätigten Benutzer (mind. 5 Edits) zugänglich. Dort könnt ihr bei Zyklus-/Staffelbeginn jeweils die neue Seite eintragen und die Sidebar weiß dann beim Klick auf "Aktuelle Handlung", wohin die Reise geht. --Klenzy (Diskussion) 09:51, 11. Dez. 2017 (CET)

PRNA !?

Was ich bis heute nicht kapiere, ist die Bedeutung des Namens der {{PRNA}}-Vorlage. Perry Rhodan Neo ... Also was? Ich würde die Vorlage gern umbenennen in {{Neo}}. Das geht per Bot vollautomatisch, ohne dass jemand was tun muss. --Klenzy (Diskussion) 13:38, 25. Okt. 2017 (CEST)

Den Namen hat Poldi kreiert. Heißt »PR Neo Artikel«. Lass das ruhig so, sonst muss ich mich auf meine alten Tagen noch umstellen. Ich kann damit umgehen, und bin sowieso der einziger, der es nutzt... --Ebbelwain (Diskussion) 19:15, 28. Okt. 2017 (CEST)
Artikel? Ah! Wieder was gelernt. --Klenzy (Diskussion) 20:23, 28. Okt. 2017 (CEST)

Perry Rhodan Neo

Wäre es nicht mal an der Zeit für eine eigene Neo Abteilung in der Perrypedia? Bei fast 160 Erschienenden Bänden wär das doch eine Idee wert. Die Neo Handlung hat sich ja nun schon weit entfernt was vor allem grad im Andromeda/MDI Zyklus stark Auffällt. —Der unsignierte Beitrag wurde hinzugefügt von Roi-Danton (Diskussion • Beiträge).

In der Perrypedia gibt es Stand heute 2815 Artikel zu Perry Rhodan Neo. Das sind etwas mehr als 5% aller Begriffe.
Da derzeit nur ein einziger Perrypedianaut das Neo-Feld beackert, können wir natürlich Verstärkung gebrauchen! Mach' mit - oder mach' Werbung für uns! --Klenzy (Diskussion) 16:25, 7. Okt. 2017 (CEST)
Was genau meinst du mit »Neo-Abteilung«? --Johannes Kreis (Diskussion) 11:53, 8. Okt. 2017 (CEST)

Naja eine Art Perrpedia für Neo also sowas wie ein Unterforum oder sowas. Eine Art Neo Perrypedia, aber unter Perrypedia erreichbar. Ich kenn mich da jetzt nicht so aus wie und ob das zu machen ist. LG Roi

Also eigentlich existiert das ja. Du findest es vielleicht nicht links in der Navigationsleiste, aber wenn du z.B. bei Perry Rhodan Neo über die Zyklus(Staffel)-Seiten oder Perry Rhodan (PR Neo) startest, dann bewegst du dich über die Links ganz automatisch in der Neo-Abteilung. Denn alle Artikel mit dem Zusatz (PR Neo) beschäftigen sich aussschließlich mit PR Neo! Und hier Kategorie:Perry Rhodan Neo findest du alle mehr als 2800 Neo-Artikel. Hoffe, dass hilft dir weiter. --Ebbelwain (Diskussion) 17:07, 9. Okt. 2017 (CEST)
Also ein eigenes Neo-Wiki? Diese Diskussion haben wir hier schon einmal geführt, ich finde sie nur gerade nicht. Ich war einer derjenigen, die ein eigenes Neo-Wiki nicht haben wollten und dafür waren, alles unter einem Dach zu behalten. --Johannes Kreis (Diskussion) 18:25, 9. Okt. 2017 (CEST)
Die Diskussion gab's hier. Ging recht eindeutig gegen ein eigenes Wiki aus. --JoKaene 18:37, 9. Okt. 2017 (CEST)
Ich könnte die Tage mal gucken, ob ich in der Sidebar etwas zaubern kann. --Klenzy (Diskussion) 20:42, 9. Okt. 2017 (CEST)
Das wäre klasse, Klenzy. Roi-Dantons Einwand ist im Grunde richtig, wir haben keinen geeigneten Einstieg ins Neoversum. --Ebbelwain (Diskussion) 21:11, 12. Okt. 2017 (CEST)
Welchen Einstieg haben wir denn ins Erstauflagenuniversum? --Johannes Kreis (Diskussion) 06:24, 13. Okt. 2017 (CEST)
Wenn ich die Menüpunkte in der Sidebar (linke Fensterseite) anschaue, sind wir schon sehr Hauptserien-orientiert. Jahreskalender, Aktuelle Handlung: bezieht sich auf die Hauptserie. Portal, Kategorien, Zyklen, Galerien: darin kommt Neo quasi "unter ferner liefen" vor.
Einen ersten Versuch habe ich im Testwiki schon gemacht: https://test.perrypedia.proc.org/wiki/Hauptseite
Bei den Galerien könnte ich mir vorstellen, Neo auch noch aufzuwerten, indem wir die Übersicht der Neo-Galerien in einen eigenen Artikel auslagern, also Galerien aufteilen in Galerien (nur Hauptserie) und [[Galerien (PR Neo)]]. Im Portal könnte man ganz unten die Gegenüberstellung Listen - Kategorien um die Neo-Listen erweitern. --Klenzy (Diskussion) 12:16, 13. Okt. 2017 (CEST)
OK, ich dachte, die Hauptseite sei gemeint. Da findet man ja alle möglichen Publikationen und dort ließe sich Neo leicht hervorheben, z.B. in Vorlage:Hauptseite Willkommen. Habe das gerade mal gemacht. --Johannes Kreis (Diskussion) 13:31, 13. Okt. 2017 (CEST)
Ist schon mal eine sehr gute Idee! --Klenzy (Diskussion) 14:31, 13. Okt. 2017 (CEST)

Datenschutzerklärung

Noch ein Thema für alle: Perrypedia Diskussion:Entwürfe/Datenschutz. --Klenzy (Diskussion) 09:49, 20. Sep. 2017 (CEST)

Perrypedia auf Englisch

Eine wichtige Diskussion, die alle angeht: Perrypedia:Diskussion#English_version_of_wiki! --Klenzy (Diskussion) 13:33, 14. Sep. 2017 (CEST)

Perrypedia-Wörterbuch für Kindle und EPUB

Eine wichtige Diskussion, die alle angeht: Perrypedia:Diskussion#Perrypedia-W.C3.B6rterbuch:_jetzt_kinderleicht.21! --Klenzy (Diskussion) 13:33, 14. Sep. 2017 (CEST)

Erweiterungen

Hey ihr Liebe, mir ist bei euren Erweiterungen etwas aufgefallen: Auf der MediaWiki-Seite der Erweiterung ExternalLinks wird explizit darauf hingewisen, dass sie aktuell nicht verwendet werde soll , da sie anfällig für XSS ist und daher ein vergleichsweise großes Sicherheitsrisiko darstellt. Da ihre einzige Aufgabe darin besteht, die externen Links aufzulisten denke ich nicht, dass es problematisch wäre, sie zu deaktivieren, bis die Probleme behoben sind.

Falls Interesse daran besteht hätte ich auch noch ein paar Erweiterungen vorzuschlagen:

  • Extension:Collection erlaubt es, Seiten als E-Books oder PDF zu exportieren und offline zu lesen
  • Extension:Popups zeigt beim Überstreichen wiki-interner Links eine Box mit dem ersten Abschnitt des verlinkten Artikels
  • Extension:Echo erlauben das versenden von Notifications
  • Extension:SecurePoll ist für Abstimmungen und Meinungsbilder ganz sinnvoll, wenn Bedarf besteht
  • Extension:RevisionSlider ist eine verbesserte Versionsübersicht, kann zusammen mit Extension:TwoColConflict eingesetzt werden
  • Extension:CodeMirror erlaubt Syntax-Highlighting im Wiki-Editor.
  • Extension:WikiEditor scheint zwar aktiviert zu sein, aber nicht aktiv in Benutzung. Wenn die entsprechenden Berechtigungen gesetzt werden, kann auch jeder Benutzer den neuen Editor aktivieren oder eben nicht (wobei es keinen Grund gibt, ihn nicht für alle an zu schalten).

Außerdem wird in den Einstellungen bei HotCat keine Beschreibung angezeigt (kann durch das Erstellen selbiger auf der Seite MediaWiki:Gadget-HotCat gefixt werden).

Wenn man in den Einstellungen nachschaut, scheint die Server-Zeit nicht der aktuellen Zeit in Deutschland zu entsprechen. Keine Ahnung, ob das Absicht ist oder nicht, falls nein, sollte man das ändern.

Edit 10:04 Uhr : Okay, jetzt zeigt es mir den neuen Editor an, keine Ahnung, wieso zuvor nicht. Mir ist auch noch aufgefallen, dass ich beim WebChat nur eine weiße Seite bekomme (sowohl in Chrome, als auch in Firefox).

Edit 10:35 Uhr : Mir ist noch aufgefallen, dass hier PHP5.5 zum Einsatz kommt, welches schon seit einiger Zeit sein EOL erreicht hat. Man sollte über ein Upgrade auf 7.1 nachdenken. Liegt aber vermutlich daran, dass Ubuntu 14.04 als OS zum Einsatz kommt und das nicht mehr die entsprechenden Updates bekommt. --Ghost Profil - Diskussion - Beiträge 10:36, 4. Sep. 2017 (CEST)

Servus Ghost, erst einmal auch von mir ein herzliches Willkommen! Ui, das sind viele Vorschläge. Der Reihe nach:
  • ExternalLinks: Danke für den Hinweis, die Sicherheitswarnung hatte ich tatsächlich übersehen. Ich gestehe außerdem, dass ich die Beschreibung der Exploits fast nicht verstehe. Wir benötigen die Extension zunächst noch, wenn nächste Woche die neue PR-Webseite kommt. Danach werde ich den Zugriff auf einige wenige User beschränken.
  • Collection: Klingt interessant, werde ich bei der nächsten Aktualisierung des Testwikis dort probeweise installieren.
  • Popups und CodeMirror: dito, beide sind aber derzeit Betaversionen.
  • Echo: Wenn ich das richtig verstehe, basiert das ganze neue Benachrichtigungssystem der MediaWiki-Software auf dieser Extension; über kurz oder lang ist anscheinend sowieso geplant, das in den Core zu integrieren. Ich kann das vielleicht mal im Testwiki zur Diskussion stellen. Meine private Meinung aus den Erfahrungen auf mediawiki.org: derzeit Schrott.
  • SecurePoll: Eine Extension für Polls (weiß nicht, ob es diese war) wurde mal andiskutiert und abgelehnt. Zu leicht manipulierbar. Evtl. wurde das behoben oder trifft für SecurePoll nicht zu? Lohnt sich der Testaufwand für die wenigen Abstimmungsfragen, die wir haben?
  • RevisionSlider: Das könnte sich lohnen.
  • HotCat: Schau ich mir nachher an.
  • Die Serverzeit ist immer GMT.
  • PHP 7: Ich müsste die neue Version aus einem fremden Repository ziehen. Kann ich machen, aber ich scheue den Aufwand im Verhältnis zum Nutzen. Das Sicherheitsrisiko ist mit einer älteren PHP-Version überschaubar (im Vergleich etwa zu einer abgelaufenen Apache- oder Mediawiki-Version).
--Klenzy (Diskussion) 16:26, 4. Sep. 2017 (CEST)
Zu PHP7 und Co. kann ich nur aus eigener Erfahrung sagen: Wenn nur MediaWiki oder andere halbwegs aktuelle CMS auf dem Server laufen sollte, dann ist der Aufwand eines Umstiegs nicht groß, da MW das aktuelle PHP voll unterstützt, problematisch wird es eben nur, bei selbst programmierten PHP-Skripten/Templates. Sowohl für PHP, als auch für apache2 gibt es, wie du schon angemerkt hast, PPAs, die die aktuellen mainline Versionen bereitstellen. Wenn man einen genaueren Blick in die Ubuntu-Quellen wirft, sieht man auch, dass die in 14.04 verwendeten Versionen von PHP und apache2 von den Ubuntu-Maintainern noch Backports bekommen, also noch gepatcht werden, da der Support für 14.04 im April 2019 ausläuft, wird ab da spätestens Schluss ein.
Noch ein Kommentar zu Echo: Die Mediawiki-Wikis nutzen das auch mit einigen zusätzlichen Erweiterungen, die mir auch nicht unbedingt gefallen. Es lohnt sich sicher, das mal im Testwiki auszuprobieren, dann kann sich da ja jeder seine Meinung zu bilden. Apropos Testwiki, ist es eigentlich Absicht, dass da alles so einen pastellgrünen Anstrich hat?
Und zu guter Letzt noch eine Frage aus Interesse: Wieso verwaltet ihr sowohl die Edittools als auch die Copyright-Hinweise über MediaWiki:Copyrightwarning, anstatt die Edittools, wie vorgesehen mit MediaWiki:Edittools einzubinden? --Ghost Profil - Diskussion - Beiträge 17:13, 4. Sep. 2017 (CEST)
Testwiki: Na, erfasse mal 50 Änderungen und stelle danach fest, dass Du im Testwiki warst. Nach diesem Erlebnis erschließt sich der Sinn der hässlichen Farbe von selbst ...
Edittools: Kaum zu glauben, aber wir hatten die Leiste mit den Sonderzeichen vor der deutschen WP. Und seitdem hat sich niemand die Mühe gemacht, das umzustellen. Was auch damit zusammenhängen könnte, dass Änderungen by MediaWiki meist dürftig, manchmal gar nicht kommuniziert werden. (Siehe dazu auch die neuen Hilfe-Schaltflächen auf vielen Perrypedia-Seiten, zwangsweise neu eingeführt mit MW 1.27, Kurzurteil: galoppierender Schwachkrampf.) --Klenzy (Diskussion) 18:47, 4. Sep. 2017 (CEST)
Die Edittools gab es von Anfang an, die Seite wurde bei euch aktiv gelöscht und an den jetzigen Platz verschoben, aber ist ja an sich nicht schlimm. Der einzige Unterscheid zur aktuellen Situation wäre, dass die Box getrennt unter dem Editor angezeigt werden würde, anstatt über der Urheberrechtswarnung. :) --Ghost Profil - Diskussion - Beiträge 19:05, 4. Sep. 2017 (CEST)
Ich meine, die Edittools gibt es in der dt. WP seit 2.12.2005, da war unsere Copyrightwarning bereits knapp 18 Monate alt. Vielleicht täusche ich mich aber. Jedenfalls ist unsere Bildschirmaufteilung deutlich ergonomischer als in der WP, Grund genug nichts zu ändern - es sei denn natürlich, es gäbe massive Benutzeranfragen für eine Änderung. --Klenzy (Diskussion) 19:25, 4. Sep. 2017 (CEST)
Sehr interessant. Auch wenn Links auf Listen im Speziellen und Redirects im Allgemeinen schon zu unerwarteten Ergebnissen führen können. Mir gefällt es dennoch. --JoKaene 13:42, 8. Okt. 2017 (CEST)
Da »Popups« ja nun installiert ist, möchte ich noch einmal ausdrücklich bestätigen, dass mir diese Erweiterung außerordentlich gut gefällt! Artikel werden so aus sich heraus informativer und viele clicks kann man sich einfach sparen.
Wäre natürlich schön, wenn es auch noch weitere Meinungen gibt. --JoKaene 21:33, 20. Okt. 2017 (CEST)
Da sind wir wenigstens zwei ;-) --Klenzy (Diskussion) 09:15, 23. Okt. 2017 (CEST)
  • RevisionSlider: Auf dem Testwiki installiert, funktioniert gut, für das Echtwiki sehr interessant. Meinungen? --Klenzy (Diskussion) 13:38, 8. Okt. 2017 (CEST)
Sorry, aber ich blick's nicht! Wie nutze ich RevisionSlider? (Dito für CodeMirror.) --JoKaene 14:05, 8. Okt. 2017 (CEST)
Ach so, klar, ich darf natürlich nicht von meinem Wissensstand ausgehen. In der Versionsgeschichte eines Artikels zwei Versionen vergleichen, dann erscheint oben ein aufklappbarer Bereich "Versionsgeschichte durchsuchen". Von da an selbsterklärend. --Klenzy (Diskussion) 14:16, 8. Okt. 2017 (CEST)
Bietet wohl einen besseren Überblick der Änderungen, ich persönlich brauche es nicht. Da ich es aber auch nicht nutzen muss, habe ich natürlich auch nichts gegen eine Installierung. --JoKaene 14:44, 8. Okt. 2017 (CEST)
  • CodeMirror: Auf dem Testwiki installiert, funktioniert gut, für das Echtwiki interessant. Meinungen?
Im Editorfenster die Rosette anklicken. --Klenzy (Diskussion) 14:16, 8. Okt. 2017 (CEST)
Im Moment erkenne ich noch keinen Mehrwert. --JoKaene 14:44, 8. Okt. 2017 (CEST)
Andererseits gewöhne ich mich langsam an die optische Unterstützung...  ;-) --JoKaene 19:14, 31. Okt. 2017 (CET)

Was bei allen 3 Extensions sympathisch ist: Man kann sie nutzen, muss aber nicht. --Klenzy (Diskussion) 13:43, 8. Okt. 2017 (CEST)

Perrypedia-Werbung in PR / neue Mailadresse

Derzeit erarbeitet Nils Hirseland eine Perrypedia-Werbung, die in der Erstauflage erscheinen soll. Die Initiative geht auf Klaus Böllhofener (PRFZ) zurück. Es wird unsere Webadresse genannt und ein Hinweis auf die Willkommensseite enthalten sein, es soll aber auch eine Mailadresse "hilfe (at) perrypedia . proc . org" angeboten werden, als erste Kontaktmöglichkeit für Interessenten. Das wird wie unsere Notfalladresse eine Verteilerliste sein, die zunächst Nils und mich enthält und möglichst noch 1-2 Freiwillige. Wer möchte mitmachen? --Klenzy (Diskussion) 16:21, 3. Sep. 2017 (CEST)

Kannst mich mit dazunehmen, ich bin allerdings manchmal nicht online, vor allem am Wochenende. --Johannes Kreis (Diskussion) 06:42, 4. Sep. 2017 (CEST)
Sehr gut, danke! Eine/n weitere/n Freiwillige/n noch? --Klenzy (Diskussion) 14:06, 4. Sep. 2017 (CEST)
Ich! --JoKaene 16:00, 4. Sep. 2017 (CEST)

Die Hilfe-Mailadresse ist ab heute aktiv, vgl. Quelle:PR2937 (Besonderes). --Klenzy (Diskussion) 13:33, 1. Dez. 2017 (CET)

OK. Danke für die Info. --JoKaene 13:34, 1. Dez. 2017 (CET)
Ha! Da muss ich wohl doch mal wieder die Printausgabe kaufen. --Johannes Kreis (Diskussion) 13:40, 1. Dez. 2017 (CET)
Mal ne Frage: Bin ich doch nicht auf der Liste gelandet oder ist die Resonanz bislang tatsächlich gleich Null? --JoKaene 17:35, 8. Dez. 2017 (CET)
Rundmail ist raus und laut den Logs des Mailservers ist das tatsächlich die erste Mail an diese Mailadresse seit 26. November. --Klenzy (Diskussion) 17:58, 8. Dez. 2017 (CET)
Okay, die Mailadresse funktioniert einwandfrei. Der Ansturm hält sich bisher in Grenzen. Das geht in dieselbe Richtung wie das, was Christina Hacker (SOL-Herausgeberin) im PR-Forum kürzlich beklagte: das Feedback der Fans ist überschaubar gering. --Klenzy (Diskussion) 19:46, 8. Dez. 2017 (CET)
Oder die PP ist so perfekt, dass es einfach keine Fragen gibt :) --Johannes Kreis (Diskussion) 06:46, 11. Dez. 2017 (CET)

Portale: wieso "Technologie und Raumschiffe"?

In den Zyklusportalen heißt die Hauptüberschrift "Technologie und Raumschiffe" mit den Unterabschnitten "Wissenschaft und Technik", "Raumschiffe / Raumstationen". Ich meine, für die Hauptüberschrift genügt "Technologie". Es versteht sich von selbst, dass dazu auch Raumschiffe gehören. --Klenzy (Diskussion) 10:39, 28. Aug. 2017 (CEST)

Da gebe ich Dir Recht. --Pisanelli (Diskussion) 11:41, 28. Aug. 2017 (CEST)

Aktionsaufruf für den PRFZ Newsletter

Nils Hirseland bietet uns an, im regelmäßig erscheinenden Newsletter der PRFZ - zunächst in der nächsten Ausgabe, eventuell regelmäßig - einen Aufruf zur Mitarbeit in der Perrypedia zu veröffentlichen. Sinngemäß: Fans, die sich mit der Serie auskennen und Fans, die der Sprache mächtig sind ;-) soll heißen, dass einerseits Inhalte beigesteuert werden sollen, aber auch Qualitätssicherung ein wichtiges Thema ist (z.B. Überprüfen von Inhalten auf Richtigkeit, artikelübergreifende Konsistenz, formale Kriterien). Das ist ein tolles Angebot, sollen wir darauf eingehen und wenn ja, wer traut sich zu, einen solchen Aufruf ca. 1000 Anschläge zu schreiben? Ich bitte um Meinungen und, bei Zustimmung, bitte direkt mit Nils Kontakt aufnehmen. Ich bin dann erstmal weg, für gut zwei Wochen ... --Klenzy (Diskussion) 16:57, 17. Jul. 2017 (CEST)

Ich habe vor einiger Zeit mal eine Kurzvorstellung der PP incl. Aufruf zur Mitarbeit für Christina Hacker geschrieben. Einen Teil davon könnte man vielleicht verwenden. Ich stelle deshalb folgenden Text zur Diskussion:
Die Perrypedia ist ein unabhängiges Fanprojekt nach dem Vorbild der Wikipedia. Ziel ist die vollständige Erfassung des Perryversums. Fast 40.000 vollwertige Artikel wurden bisher geschrieben, insgesamt enthält die Perrypedia um die 100.000 Seiten. Das ist viel, aber noch längst nicht genug! Lücken klaffen an unzähligen Stellen, zudem müssen die Artikel aus der laufenden Handlung ständig aktualisiert werden. Eine Qualitätssicherung und Rechtschreibprüfung der Artikel ist ebenso wichtig wie die technische Wartung und die Aktualisierung der Mediawiki-Software.
Neue Helfer sind deshalb immer gern gesehen und jeder Beitrag ist willkommen. Du hast einen Schreibfehler gefunden? Ärgere dich nicht darüber – korrigiere ihn! Du stellst fest, dass eine Handlungszusammenfassung unvollständig ist? Ergänze sie! Zu deiner Lieblingsfigur gibt es keinen Perrypedia-Artikel? Füge deinen eigenen Text ein! Programmierkenntnisse werden hierfür nicht benötigt und die aktiven Perrypedianauten helfen gern. Also: Mach mit! --Johannes Kreis (Diskussion) 06:46, 18. Jul. 2017 (CEST)
Das ist eine schöne, korrekte und ... sehr sachliche Beschreibung unserer Arbeit - aber lockt man damit jemanden hierher, um mitzumachen? Ich würde mich da gerne mal dran versuchen. Ich bin mir zwar sicher, dass auch da nicht viel bei rauskommt, denn ehrlich gesagt, man muss wahnsinnig sein, um hier mitzumachen (und ich habe keine Ahnung, wem man das zumuten sollte), aber ich will mal versuchen, den Text so kreativ zu gestalten, dass er zumindest mal reinschnuppern lässt. --Pisanelli (Diskussion) 11:03, 18. Jul. 2017 (CEST)
Hab hier mal was kreiiert. Wahrscheinlich mehr als 1000 Zeichen. Wir können gerne weiter dran rumbasteln. Ich packe es auf meine Spielwiese. --Pisanelli (Diskussion) 16:15, 18. Jul. 2017 (CEST)
Etwas mehr als 2500 Zeichen (ohne Leerzeichen). Ich möchte nur anmerken, dass ich nicht irre, bekloppt oder wahnsinnig bin :) --Johannes Kreis (Diskussion) 06:28, 19. Jul. 2017 (CEST)
Nein, nein, und nun husch, zurück in die Gummizelle ;) Ja, ich weiß, der Text ist zu lang, leider :) Wenn Ihr ihn in doof findet, können wir ihn auch löschen, übrigens. Ich wollte nur der Wahrheit ein lustiges Gesicht geben und man darf den Leuten auf jeden Fall nicht das Gefühl geben, dass das hier immer alles ganz einfach ist. Davon sind auch andere Wikis inzwischen weit entfernt ;) Und wir haben ja schon genug Anfänger wieder in die Flucht geschlagen, weil die mit unseren Korrekturen nicht zurecht gekommen sind. Und wie oft haben wir uns hier die Köppe eingeschlagen? Das ist echt nix für Leute mit labilem Nervenkostüm. Ich finde, das muss man schon ganz deutlich sagen. --Pisanelli (Diskussion) 07:51, 19. Jul. 2017 (CEST)
Also ich kann mit ruhigem Gewissen behaupten, dass ich noch keinen Perrypedianauten körperlich misshandelt habe :) Und ich hatte eigentlich gehofft, dass ich anderen PPnauten nicht etwa das Leben zur Hölle mache, sondern ihnen helfe ... --Johannes Kreis (Diskussion) 09:12, 19. Jul. 2017 (CEST)
So ist das, glaube ich, von jedem hier immer gemeint. Aber so wird es ja wohl nicht immer empfunden. Arroganz ist ja noch das netteste, was man zu hören kriegt ;) Klar, manchmal vergreift man sich auch im Ton (bin da ja auch nicht immer ein Ruhmesblatt), aber das ist dann wohl fehlender Geduld, Empathie und vor allem dem Fehlen eines tatsächlichen Gegenübers geschuldet. Ist ja immer was anderes, ob ich dem anderen während einer Diskussion in die Augen sehen kann, ne? Ich reagiere z.B. immer ganz allergisch auf das Argument, dass Sachen so gemacht werden, weil sie immer so gemacht wurden. Das ist für mich häufig der Boykott, sich auf Veränderungen auch nur einlassen zu wollen. Da kriege ich dann manchmal Hörner. Es gibt in meinem Büro eine Art Denkzettel, der für uns sehr wichtig ist: "Alle sagten, das geht nicht. Dann kam einer, der wusste das nicht - und hat's einfach gemacht." Man kommt immer nur weiter und kann Dinge besser machen, wenn man sie auch mal in Frage stellen lässt. Dann kann man es immer noch so belassen, aber die Gedanken müssen frei und kreativ bleiben dürfen. Auch in Wikis ;) Aber hier ist das mit Veränderungen (also, den großen, nicht den kleinen, dauernden) manchmal echt ein unglaublich anstrengender Prozeß. Und das muss man den Leuten auch offen sagen - finde ich. --Pisanelli (Diskussion) 10:48, 19. Jul. 2017 (CEST)
Der Text von Pisanelli geht m.M. nach in eine gute Richtung! Mir ist das Wort "irre" u.ä. allerdings zu häufig erwähnt. So schreckt der Text ungewollt sicher einige ab hier mit zu machen. Ich bin für weiter am Text feilen und bitte liebe Mitaktivisten fühlt Euch nicht persönlich angeklagt! Norman (Diskussion) 12:53, 19. Jul. 2017 (CEST)
Kannst gerne ändern, was immer Du ändern möchtest. Ich bin da schmerzfrei. Danke für die Rückmeldung. --Pisanelli (Diskussion) 13:01, 19. Jul. 2017 (CEST)
Habe eine erste Überarbeitung auf Pisanelli Spielwiese reingestellt. Norman (Diskussion) 15:44, 19. Jul. 2017 (CEST)
Du hast ja den ganzen Wahnsinn entfernt. Ihr wißt schon, der erste Schritt zur Heilung ist es, das Problem als solches zu akzeptieren? ;) Nein, ich sehe ein, das ist vermutlich auch nicht gerade einladend. Der Kompromiß ist schon besser. --Pisanelli (Diskussion) 18:54, 19. Jul. 2017 (CEST)

Leider immer noch 2000 Anschläge ohne Leerzeichen... --Johannes Kreis (Diskussion) 06:34, 20. Jul. 2017 (CEST)

Vielleicht ist auch Platz für 2000? Kannst Du nachfragen, oder soll Pisanelli oder ich nachfragen? Norman (Diskussion) 09:13, 20. Jul. 2017 (CEST)
Könnte jemand von euch das in die Hand nehmen? --Johannes Kreis (Diskussion) 11:10, 20. Jul. 2017 (CEST)
Ich habe gar keinen Kontakt zum PRFZ. Willst Du, Norman? --Pisanelli (Diskussion) 11:45, 20. Jul. 2017 (CEST)
Ich habe zwar auch keinen Kontakt, aber ich übernehme das. Ich bin allerdings ab morgen 21.7. für eine Woche in Urlaub. Ich schicke aber heute noch den Vorschlag an die e-mail-Adresse newsletter@prfz.de und H. Kessel. Norman (Diskussion) 15:52, 20. Jul. 2017 (CEST)
E-mail ist soeben raus. Mir ist aufgefallen, das wir auf jeden Fall noch hinzufügen müssen, wie die genau eine erste Kontaktaufnahme (sprich Account anlegen. usw.) stattfinden soll. Sollen wir für die Texte und eventuelle Folgeartikel eine Projektseite aufbauen? Norman (Diskussion) 16:17, 20. Jul. 2017 (CEST)
Nee, das führt zu weit, meiner Meinung nach. Wenn die Leute Interesse haben, kommen sie hier auf die Seite - und hier finden sie alle Informationen zum Anmelden etc. Da ist unsere Hilfe ja schon gut ausgetüftelt. --Pisanelli (Diskussion) 18:34, 20. Jul. 2017 (CEST)
Soeben habe ich folgende e-mail von Christina Hacker erhalten:
Von: SOL-Redaktion ...
Gesendet: Donnerstag, 20. Juli 2017 18:17
Betreff: AW: Beitrag für nächsten PRFZ Newsletter (Thema Perrypedia)
Hallo
vielen Dank für Deinen Text für den Newsletter. Er ist an der richtigen Stelle gelandet. Ich bereite gerade den Newsletter Nummer 20 vor und freue mich sehr darüber. Gerne
kannst Du mir auch für die kommenden Newsletter Texte schicken, die wir dann veröffentlichen werden.
Auch vom Umfang her ist der Beitrag völlig in Ordnung.
Liebe Grüße Christina
Das ging dann doch schnell und auch die Länge passt. Sollen wir noch einen Satz zur ersten Anmeldung mit aufnehmen? Norman (Diskussion) 22:06, 20. Jul. 2017 (CEST)
Cool. Nagut, formulier das mit der Anmeldung, wenn Du magst. --Pisanelli (Diskussion) 08:07, 21. Jul. 2017 (CEST)
Sehr schön, danke euch! --Klenzy (Diskussion) 13:21, 30. Jul. 2017 (CEST)
Ich habe gerade im Newsletter den Artikel gelesen und festgestellt, dass als Autor mein Name genannt wird. Das war so von mir NICHT beabsichtigt; zumal der Text auch nicht von mir stammt. Sorry. Norman (Diskussion) 11:19, 20. Aug. 2017 (CEST)
Für mich kein Problem. Mein Name muss da gar nicht stehen *wischmirerleichtertdenSchweißvonder Stirn* :)
Der Newsletter ist nun seit 10 Tagen erschienen. Hat jemand eine Resonanz darauf bemerkt? Wieviel neue User-Anmeldungen hatten wir bisher? Norman (Diskussion) 12:01, 29. Aug. 2017 (CEST)
Januar 2017: 4, Februar 3, März 8, April 11, Mai 7, Juni 3, Juli 4, August 3 (bis 15.8., seitdem keine).
Von den 43 neuen Benutzern in 2017 haben 31 überhaupt keine Beiträge verfasst, auf die 12 aktiv gewordenen Benutzer fallen 158 Edits (einschl. Benutzer- und Diskussionsseiten), davon 12 "echte" neue Artikel. Ohne Gewähr, da händisch ausgezählt. --Klenzy (Diskussion) 13:02, 29. Aug. 2017 (CEST)

Wichtiger Wartungshinweis

Beachtet bitte: Perrypedia:Wartung#SSL-Zertifikat_für_gesicherte_Verbindung. --Klenzy (Diskussion) 10:59, 1. Jun. 2017 (CEST)

Pretty URLs

Fragen kostet ja nix... Ich mochte die ursprüngliche Formatierung der Links (also /wiki/Quelle:PR313). Momentan wird der gesamte Titel des Heftes angezeigt. In der ursprünglichen Konfiguration konnte man recht schnell ein bestimmtes Heft eingrenzen, wenn man etwas bestimmtes sucht, indem man in der URL einfach die Heftzahl ändert. So hab ich oft schnell ein dutzend Hefte übersprungen, wenn ich etwas bestimmtes suchte, aber nicht genau wusste, wann die Handlung in der Serie spielte. Alternativ, falls das nicht geht, möchte ich vorschlagen, die Anzahl der angezeigten Nummern nach links und rechts ein wenig zu erhöhen, so von jeweils zwei auf vier links und rechts? Ich danke für Eure Aufmerksamkeit. --Soulprayer (Diskussion) 19:50, 12. Apr. 2017 (CEST)

Wann soll das gewesen sein? Die Aufteilung in Haupt- und Quellennamensraum und die dadurch bedingte Weiterleitung von Quelle:xxx auf den Romantitel gibt es fast seit Anbeginn der Perrypedia. Ich kann mich nicht erinnern, dass da mal die Heftnummer stand - vielleicht vor meiner Zeit?
Für schnelle Navigation zwischen mehreren Romanen empfiehlt es sich, mit mehreren Registerkarten zu arbeiten: Als erstes die Zyklusseite oder gleich Perry_Rhodan-Heftromane aufrufen, zum Aufruf einer HZF dann "Link in neuem Tab öffnen" (bei mir im Browser ist das Strg+Klick). Schneller geht's nicht. --Klenzy (Diskussion) 14:59, 13. Apr. 2017 (CEST)
Was Soulprayer meint, gab es schon zu deinen Zeiten. Wenn man direkt im Browser in der Adresszeile http://www.perrypedia.proc.org/wiki/Quelle:PR1531 eingab, wurde die entsprechende Seite aufgerufen. Da diese Seite aber ein Redirect ist, wird man zur HFZ weitergeleitet. Soweit so gut und das ist ja auch das was man erwartet. Der Unterschied ist nun aber, dass sich aktuell die Adresse im Adressfeld des Browsers ändert. Früher blieb Quelle:PR1531 da stehen nun steht da der Titiel der HFZ. Das ist die Änderung nach dem Update. --Poldi (Diskussion) 18:45, 13. Apr. 2017 (CEST)
Bei mir bleibt in der Adresszeile der Quellen-Redirect mit Nummer bestehen?!? --JoKaene 19:18, 13. Apr. 2017 (CEST)
@Poldi, eine bedenkliche Erinnerungslücke, ich kann mich echt nicht erinnern. Ich dachte das war immer so wie jetzt.
@JoKaene, wenn wir herausfinden, wie Du das machst, könnten wir Soulprayer vielleicht doch helfen. Welchen Browser hast Du? --Klenzy (Diskussion) 19:55, 13. Apr. 2017 (CEST)
Es liegt wohl tatsächlich am Browser.
Ich sitze hier nicht an meinem eigenen Rechner, und wenn ich den »okkupiere« läuft er zumeist bereits mit – festhalten – IE9! Wie auch heute. Mit aktuellem Firefox kann ich das Umspringen von Quellen- zu Zieladresse zwar beobachten, aber auch nicht verhindern.
Mit IE9 also geht es, kann ich aber überhaupt nicht empfehlen! --JoKaene 20:29, 13. Apr. 2017 (CEST)
Sorry für den Trubel, ich wollte ja eigentlich nur mal nachfragen. ;) Poldi hat schon richtig erkannt, dass die Umleitung vor dem Update die URL behalten hat. Ich probiere mal Klenzys Methode, auch wenn ich dem pragmatischen Weg ein wenig nachtrauere. ;-) Unabhängig davon fände ich es von der Navigation her gut, die Anzahl der Hops vorwärts und rückwärts in den Heften zu erhöhen. +/-2 ist einfach ein wenig happig (Meinung). --Soulprayer (Diskussion) 00:14, 14. Apr. 2017 (CEST)
Nachfragen ist immer erlaubt, und ich hätte echt schwören mögen, dass nach dem Redirect schon immer der Name des Ziel-Artikels dastand. Okay, das ist aber leider nichts, was wir irgendwie beeinflussen könnten.
Vielleicht sind zwei Hefte vor/zurück tatsächlich etwas zu wenig - das hab ich mir gelegentlich auch schon überlegt. Wie viele wären angemessen? Weitere Meinungen? --Klenzy (Diskussion) 11:58, 14. Apr. 2017 (CEST)
Vier Nummern fände ich auch besser. Würde auch den häufig genutzten Viererblocks der Handlungsebenen entsprechen. --JoKaene 12:07, 14. Apr. 2017 (CEST)
@Soulprayer, ich kann dir einen Workaround anbieten - ohne Garantie, ob und wie lange das funktioniert.
Das Umschalten der URL auf die Redirect-Zielseite wurde in Mediawiki 1.24 eingeführt. Es basiert auf Javascript. Daher: Wenn Du Javascript ausschaltest, bleibt in der URL "Quelle:PRxxxx" stehen.
Nun haben wir inzwischen eine Menge Funktionen, die auf Javascript basieren. Ausschalten bedeutet also, dass die Perrypedia nicht mehr einwandfrei funktioniert. Richte dir doch einfach einen zweiten Browser ein - Javascript ausschalten geht z.B. problemlos mit Safari oder Opera. Und diesen zweiten Browser verwendest Du gezielt, wenn Du in den HZF stöbern willst. --Klenzy (Diskussion) 20:47, 14. Apr. 2017 (CEST)
Hallo Klenzy, wie schon weiter oben begeistert gelesen, empfinde ich die Erhöhung der angezeigten Heftanzahl auf -4/+4 als sehr gute Verbesserung! Das mit der »editierbaren URL« wäre zwar toll, werde ich aber nicht mehr vermissen. :) Sehr vielen Dank. --Soulprayer (Diskussion) 11:23, 18. Apr. 2017 (CEST)
Okay, drei Stimmen dafür. Ich werde das mal gelegentlich auf dem Testserver versuchen. Die Navigationslisten sind ... nun ja, komplizierte Vorlagen. --Klenzy (Diskussion) 11:45, 18. Apr. 2017 (CEST)
Ich hab's nicht vergessen, möchte aber zuerst das Testwiki aktualisieren, damit ich dort ungestört an den Vorlagen herumwerkeln kann. --Klenzy (Diskussion) 11:51, 29. Apr. 2017 (CEST)

Neu in Mediawiki 1.27

  • Spezial:ExternalLinks für die Überprüfung von Weblinks.
  • Mobile Frontend: Erscheint bei Tablets und Smartphones automatisch. Auf dem PC kann man die Darstellung gezielt testen, wenn man ganz unten auf der Seite auf "Mobile Ansicht" klickt.

--Klenzy (Diskussion) 19:47, 10. Apr. 2017 (CEST)

  • Markierungen: Bestimmte Änderungen werden automatisch mit "Bearbeitungsmarkierungen" versehen. Bei unserer derzeitigen Konfiguration sind das "Mobile Bearbeitungen" und "Mobile Web-Bearbeitungen". In der Versionsgeschichte, bei den letzten Änderungen und bei den neuen Seiten kann man nach diesen Markierungen selektieren.
Markierungen selektieren.JPG

Die Funktion ist noch nicht ausgereift, man muss nach dem englischen Namen der Markierung selektieren.
Des weiteren können Admins auf Spezial:Markierungen eigene Markierungen anlegen und diese in der Versionsgeschichte bestimmten Versionen zuordnen, sowie später danach suchen.

Markierungen verwalten.JPG
Markierungen suchen.JPG

--Klenzy (Diskussion) 17:51, 16. Apr. 2017 (CEST)

Upgrade auf Mediawiki Version 1.27 - im Testwiki bitte testen

Das Testwiki habe ich jetzt auf die neue Mediawiki-Version 1.27 gehievt (long-term-support bis Mitte 2019, vgl. [26]).
Nach einer Reihe von kleineren und größeren Schwierigkeiten läuft das Testwiki jetzt stabil, einschließlich der bisher bekannten Extensions. Ich kann aber unmöglich alles selbst testen und bitte euch daher um Mithilfe! Schaut in den kommenden drei, vier Wochen doch mal im Testwiki vorbei und probiert eure Lieblingstätigkeiten dort aus. Beobachtungen bitte hier melden: Perrypedia:Wartung#Beobachtete Probleme, Fragen und Bearbeitungsstatus.
Im Testwiki habe ich auch zwei neue, interessante Extensions installiert:

  1. http://www.mediawiki.org/wiki/Extension:ExternalLinks fügt eine neue Spezialseite "Spezial:ExternalLinks" hinzu, mit der ganz leicht die Links nach außerhalb der Perrypedia geprüft werden können.
  2. http://www.mediawiki.org/wiki/Extension:MobileFrontend dient zur Optimierung der Wikiseiten für Tablets und Smartphones (und ist der eigentliche Grund für die Umstellung auf 1.27).

--Klenzy (Diskussion) 23:30, 29. Jan. 2017 (CET)

Insbesondere das MobileFrontend ist für uns interessant. Wenn alles problemlos läuft, könnte ich die Perrypedia (das Produktivwiki) im März auf die neue Mediawiki-Version umstellen. --Klenzy (Diskussion) 10:20, 3. Feb. 2017 (CET)

Abgerufen von „http://www.perrypedia.de/mediawiki/index.php?title=Perrypedia:Verbesserungsvorschläge/Archiv_2017_-_2019&oldid=2091771“