Perrypedia:Verbesserungsvorschläge

Kommunikationsseiten

Ich brauche Hilfe | Verbesserungsvorschläge | Diskussion | Beobachtete Fehler | Wartung | Vandalismus | Meinungsbilder | MediawikiChat

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

Archivierte Beiträge 2004–2006 | 2007–2008 | 2009–2010 | 2011–2013 | 2014–2016 | 2017–2019 | 2020–2022 | 2023–...

Keine Jahreszahlen im Header

Ab 19. Jahrhundert und davor sind die Jahreszahlen im Header der Artikel verschwunden. Dabei wird auf den Jahreskalender verwiesen. Den Jahreskalender entschlackt man dadurch natürlich. Aber in den Jahrhundert-Artikeln ist die Übersicht durchaus Übersicht stiftend. Zumal sie ja auch schon - früher mal - mit drin war. Gab es da eine Abstimmung zur Abschaffung? --Debugger (Diskussion) 13:01, 30. Sep. 2025 (CEST)

Kein besonderer Grund dafür oder dagegen, außer eben zum Abgleich mit dem Jahreskalender.

Kann man also auch wieder ergänzen. Und dann weiter, 18. Jh., 17. Jh., wo ziehen wir die Grenze für "mit" oder "ohne" Jahreszahlen? Nur so dahingefragt. --Klenzy (Diskussion) 17:02, 30. Sep. 2025 (CEST)

NGZ Redirects bei ATLANC-Zeit und ATLANC-Handlungsjahre

Ich sehe ein Problem auf uns zukommen, welches wir vielleicht vorher lösen sollten. Es wird nämlich aktiv auf Handlungsjahre der "ATLANC-Zeit" zugesteuert. Aktuell zeigen dort normale Redirects hin. Aber das ist ungünstig wenn die Jahre aktive Handlungsjahre werden oder umgekehrt. Noch ist es relativ einfach ATLANC-Jahre zu erkennen und umzubiegen. Ich würde vorschlagen in der Form der Lunaren Jahre. Also in der Form »2254 NGZ (ATLANC-Zeit)« oder so. Damit wir die "echten" NGZ-Artikel Zusatzfrei halten. --Debugger (Diskussion) 18:56, 26. Sep. 2025 (CEST)

Guter Vorschlag! --Norman (Diskussion) 19:27, 26. Sep. 2025 (CEST)

Ergibt Sinn, sollten wir so machen Etwaige Umrechnungsformeln kann man dann immer noch in Redirects reinnehmen. --Thinman (Diskussion) 16:36, 27. Sep. 2025 (CEST)

Hier habe ich mal zusammengefasst was sich ändern würde. Sollte ich etwas essentielles vergessen haben, bitte einfach reineditieren. --Debugger (Diskussion) 10:42, 30. Sep. 2025 (CEST)

Dann fang ich mal an. --Debugger (Diskussion) 10:36, 1. Okt. 2025 (CEST)

Habe nun alle Seiten umgestellt. Lediglich die Links nach 1517 NGZ fehlen noch. Folgendes Anliegen, klar, dass sind im Prinzip Handlungsjahre, aber ist 2254_NGZ_(ATLANC-Bordzeit) wirklich als eigener Artikel nötig? Sollte man den nicht besser, wie bei der lunaren Zeit, in den Jahrhundertartikel reinnehmen? M.E. würde es die Lesbarkeit und auch die Verlinkung untereinander, die Kontinuität betreffend, verbessern. Aber das ist nur meine Ansicht. --Debugger (Diskussion) 09:29, 2. Okt. 2025 (CEST)

Portalseiten - Jahreszahlen

Würde es nicht besser aussehen, wenn »Handlungszeitraum« und »Weitere Zeitangaben« untereinander stehen würden? Alles im Portal ist wohlgeordnet, nur diese beiden Punkte nicht. Was ziemlich unschön ausufern kann z.B. Portal_"Chaotarchen"_(Zyklus). Wenn man es untereinander machen würde, dann könnte man es deutlich platzsparender und ausgewogener formatieren. Ich bin auch gerne bereit die Portale zu ändern, daran soll es nicht scheitern. --Debugger (Diskussion) 08:28, 29. Jul. 2025 (CEST)

Könntest du das im Testwiki mal ausprobieren? --GolfSierra (Diskussion) 15:36, 31. Jul. 2025 (CEST)

Was ist das Testwiki? --Debugger (Diskussion) 11:41, 4. Aug. 2025 (CEST)

hier geht es zur Testumgebung: https://test.perrypedia.de/wiki/Hauptseite --Norman (Diskussion) 12:06, 4. Aug. 2025 (CEST)

Portal "Fragmente" Testwiki da hab ich mal das Format angepasst wie ich mir das vorstelle. --Debugger (Diskussion) 10:30, 5. Aug. 2025 (CEST)

Hier noch eine Umstellung auf der Testwiki Portal_"Das_Atopische_Tribunal"_(Zyklus) vs. Portal_"Das_Atopische_Tribunal"_(Zyklus)#Geschichte. Zumindest ein kleiner Kommentar wäre nett, oder ist allgemeines Schweigen als Zustimmung zu werten? --Debugger (Diskussion) 11:53, 11. Aug. 2025 (CEST)

Danke, sieht sehr viel aufgeräumter aus. Mir gefällt es. --GolfSierra (Diskussion) 14:23, 11. Aug. 2025 (CEST)

Sehr übersichtlich!

--Johann (Diskussion) 16:39, 11. Aug. 2025 (CEST)

Yep. --Thinman (Diskussion) 19:59, 11. Aug. 2025 (CEST)

Gefällt mir auch besser --Tek (Diskussion) 06:42, 12. Aug. 2025 (CEST)

Mir gefällt es auch. Keine Einwände meinerseits dies in anderen Portalen so umzusetzen. --Norman (Diskussion) 07:34, 16. Aug. 2025 (CEST)

Dann mache ich mich mal an die Arbeit. --Debugger (Diskussion) 10:21, 22. Aug. 2025 (CEST)

Sperrung der Anlage von neuen Benutzerkonten

Heute, am 28.7. wurde die PP wie die Tage zuvor auch schon, wiederholt angegriffen. Infolgedessen wurde von unserem Sysadmin die Anlage neuer Benutzerkonten gesperrt um die Situation zu entspannen. Wir beraten über die weitere Vorgehensweise. --Norman (Diskussion) 23:33, 28. Jul. 2025 (CEST)

Sollen wir eine Meldung auf der Hauptseite anzeigen und welche Vorlage verwendet man dafür? --Johannes Kreis (Diskussion) 09:14, 29. Jul. 2025 (CEST)

Ich habe gerade einen Text aktiviert. Bitte um Prüfung, ob ok. --Norman (Diskussion) 09:45, 29. Jul. 2025 (CEST)

Ich schlage vor, folgende Extension zu installieren: https://www.mediawiki.org/wiki/Extension:Moderation

Die Erweiterung erfordert ein wenig Konfigurations- und Anfangsaufwand und sollte vorab natürlich im Testwiki ausprobiert werden.

Wenn ich alles richtig verstehe, dann läuft es folgendermaßen ab:

• Änderungen an Wikiseiten sind zuerst nicht sichtbar (in den "letzten Änderungen" doch sichtbar, was ein Problem sein kann, aber vielleicht reicht die Maßnahme trotzdem aus).
• Statt dessen geht der Beitrag in die Moderationswarteschlange.
• Alle Benutzer mit "Moderator"-Rechten können die Änderungen in der Warteschlange freigeben oder, bei Spammern, verwerfen. Das ist ein wenig Aufwand, aber da es eine eigene Benutzergruppe ist, muss das nicht auf Admins begrenzt sein. Allerdings bestimmen die Admins, wer "Moderator" bekommt (so wie heute z.B. "File-Upload").
• Wenn ein neuer Benutzer seine guten Absichten bewiesen hat, können die Admins den neuen Benutzer mit "Automoderated" ausstatten. Von da an werden seine Änderungen sofort sichtbar, keine weitere Moderation.

Es bleibt nur zu klären, ob und wie die bisherigen Benutzer zügig "Automoderated" bekommen können.

Den Mehraufwand für die anfängliche Moderation halte ich für gering - dafür entfällt das bisherige Löschen der Spamseiten.

Das Löschen von Spambenutzern bleibt gleich. --Klenzy (Diskussion) 11:18, 29. Jul. 2025 (CEST)

Ziemlich viel Aufwand für ein kleines Problem. Was spricht dagegen, die echten neuen User nur per Klick reinzuwinken? Zu 99,9% erkennt man diese sofort an ihrem Namen. --Debugger (Diskussion) 11:39, 29. Jul. 2025 (CEST)

Bringt das was? Verwerfen müssen wir die Änderungan auch, das schenkt sich nichts.

Ich würde eher eine Moderatorengruppe zum Freischalten neuer Nutzer einrichten. Wenn man sieht, von welcher Seite aus die Neuanmeldung initiert wurde, kann man schon an den Namen sehen, ob es sich um einen Spammer handelt. --Thinman (Diskussion) 11:42, 29. Jul. 2025 (CEST)

Ich unterstütze den Vorschlag von Thinman. So gehen wir das Problem von der Wurzel her an. Den Vorschlag von Debugger lehne ich ab. Die Registrierung mit einer email-Adresse hat immer den Vorteil, Nutzer auch anschreiben zu können, was bei einer ein-Klick-Registrierung nicht möglich wäre. --GolfSierra (Diskussion) 09:46, 30. Jul. 2025 (CEST)

Du hast mich völlig missverstanden. Ich meinte damit, dass die Freischaltung mit einem manuellen Klick vom Admin gemacht wird, also Registrierung wie bisher aber Freigabe nur durch Admin/Whoever. Was deutlich weniger aufwendig ist, als die Option, die Klenzy vorschlägt. Zumal, wie Thinman es auch anspricht, das Problem selbst, durch die Sichtungserweiterung, nicht beseitigt wird. Die Edits würden dann doch gemacht werden können und müssten weiter manuell gelöscht werden. --Debugger (Diskussion) 10:33, 30. Jul. 2025 (CEST)

OK, dann ist das auch eine Möglichkeit. --GolfSierra (Diskussion) 11:05, 30. Jul. 2025 (CEST)

@Thinman: Ja, das bringt was, nämlich wie gewünscht eine Moderatorengruppe zur Freischaltung neuer Nutzer. Habe ich das so schlecht beschrieben? Wann die Freischaltung erfolgt, ob sofort nach der Anmeldung oder nach einem oder mehreren Edits, ist nicht vorgeschrieben, sondern muss von uns reguliert werden.

Das Problem ist offensichtlich eins, sonst wäre die Anmeldesperre nicht nötig, und es beschäftigt die Admins (derzeit übrigens nur noch 2) seit Monaten. Wie wär's mit ausprobieren und dann anschließend darüber beraten? --Klenzy (Diskussion) 10:35, 31. Jul. 2025 (CEST)

Wie würde das funktionieren? --Johannes Kreis (Diskussion) 12:33, 31. Jul. 2025 (CEST)

Eine Mediawiki-Extension kann nur der Sysadmin installieren. Erstmal im Testwiki ausprobieren, logischerweise. --Klenzy (Diskussion) 13:23, 31. Jul. 2025 (CEST)

@Johannes Kreis, das ist die Erweiterung, die auf der deutschen Wikipedia seit Jahrzehnten im Einsatz ist, die Sache mit den Bearbeitungssichtungen. Die Problematik dabei hat ja Thinman schon angesprochen, es würde nicht verhindern, dass der Spam geschrieben wird, es würde nur verhindert, dass ihn jemand sofort sieht. Dafür würde man ein zwei Klassensystem bei den Usern einführen. Die, die eben automatisch veröffentlicht werden, also die gehobene Klasse und die einfachen User, die von den anderen "gesichtet" werden müssen, ehe ihr Edit auftaucht. Der Punkt ist dabei, dass die Spamedits weiterhin gelöscht werden müssten durch die Admins, wenn man konsequent ist. Man könnte sie natürlich auch ungesichtet versauern lassen, aber dadurch würde diese Queue immer länger werden, denn die Spamaccountanmeldung bzw. den eigentlich Spambeitrag verhindert diese Erweiterung nicht. --Debugger (Diskussion) 15:19, 31. Jul. 2025 (CEST)

Falsch. Bitte nochmal lesen. --Klenzy (Diskussion) 15:26, 31. Jul. 2025 (CEST)

OK, dann wäre mir eine Lösung lieber, durch die verhindert wird, dass ein neuer User überhaupt irgendetwas ändert. Also eine Funktion zum Freischalten des neuen Users, nicht eine Funktion zum Freischalten der Edits des neuen Users. --Johannes Kreis (Diskussion) 15:28, 31. Jul. 2025 (CEST)

Die Extension tut beides, und das Freischalten der Edits ist nur nötig bis zum Freischalten des Benutzers. So wie ich es oben im Detail erläutert habe. --Klenzy (Diskussion) 15:32, 31. Jul. 2025 (CEST)

Bleibt noch eine Frage: Können nur Admins die Edits/Nutzer freischalten oder wird es ein Moderatorenteam geben? Welche Rollen/Berechtigungen müssen vergeben werden? --GolfSierra (Diskussion) 15:35, 31. Jul. 2025 (CEST)

2 Rollen, eigentlich heißt das in Mediawiki Berechtigungen, kommen neu dazu: "Moderator" und "Automoderated". Zunächst vergeben Admins die Berechtigungen, sinnvollerweise also "Moderator" für sich selbst. Weitere "Moderator" sind möglich, aber wahrscheinlich unnötig. Alle "Moderator" können Edits freischalten. Ob "Moderator" auch andere Nutzer auf "Automoderated" freischalten können, weiß ich nicht, muss getestet werden. Offen ist, wie oben in den Raum gestellt, ob mit einem überschaubaren Aufwand alle vorhandenen Nutzer auf "Automoderated" gesetzt werden können. Wenn nicht, dann ist die Extension zugegebenermaßen unbrauchbar. --Klenzy (Diskussion) 16:12, 31. Jul. 2025 (CEST)

Wie geht es jetzt weiter? --GolfSierra (Diskussion) 22:48, 13. Aug. 2025 (CEST)

@Klenzy dann hast du aber doch immer noch das Problem, dass die die Edits gemacht werden und manuell gelöscht werden müssen. Wo ist also der Vorteil, außer dass man die Edits nicht sieht? Für die Administration macht es doch genau dieselbe Arbeit wie bisher. Nur eben im Hintergrund. Oder was übersehe ich an Vorteil? --Debugger (Diskussion) 12:55, 14. Aug. 2025 (CEST)

@Golf, ich möchte es einfach mal im Testwiki ausprobieren. --Klenzy (Diskussion) 11:58, 15. Aug. 2025 (CEST)

Ja, wie soll es weitergehen? Auf jedenfall können wir die Anmeldung nicht einfach unverändert wieder öffnen. Bei allen Optionen muss zuvor vom Sysadmin eine Änderung im Testwiki implementiert und von uns allen getestet werden. a.) Einrichtung E-Mail-Adresse um neue Accounts manuell nach Admin-Sichtung freizuschalten. oder b.) Einrichtung Moderator-Extension. oder c.) Update Mediawiki (neue Version) plus neue Captca-Extension. d.) eventuell gibt es weitere Alternativen, die wir noch nicht näher betrachtet haben. Ich für meinen Teil plädiere für a.) oder b.), kann momentan aber nur abwarten was technisch einfacher oder schneller zum Testen zur Verfügung gestellt werden kann. --Norman (Diskussion) 07:47, 16. Aug. 2025 (CEST)

So wie die Spam-Bots bisher vorgegangen sind, haben sie zuerst das Captcha überwunden und haben dann nach spätesten einer Woche die eigene Benutzerseite geändert oder vielleicht noch einen Artikel im Hauptnamensraum angelegt. Auf den ersten Blick scheint man das mit der Extension AbuseFilter aufhalten zu können. Damit kann man beispielsweise eine Regel erstellen die bei Usern unter 10 Edits die Bearbeitung der Benutzerseite oder das Anlegen von neuen Seiten verhindert. Es kann auch verhindert werden, dass ein Link in der neu erstellten Seite erscheinen darf. Des weiteren wäre es auch möglich damit ein Captcha abzufragen, wenn der Spam-Bot doch einfach eine bestehende Seite ändert. Damit wäre die typische Arbeitsweise eines Spam-Bots erst einmal verhindert. Ich habe mir die Extension nur auf dem Papier angesehen und es kann völliger Blödsinn sein, was ich hier vorschlage. Vielleicht kann ja Klenzy mal einen Blick darauf werfen. --Poldi (Diskussion) 10:01, 16. Aug. 2025 (CEST)

Ach ja, AbuseFilter wäre vielleicht auch eine Möglichkeit - habe ich schon gehört, kenne ich aber nicht wirklich und habe einfach nicht daran gedacht.

Ich würde gern im Testwiki beides ausprobieren, AbuseFilter und Moderation. Vielleicht könnte der Sysadmin die beiden Extensions probeweise im Testwiki installieren. --Klenzy (Diskussion) 17:14, 16. Aug. 2025 (CEST)

Könnte die MediaWiki-Extension Extension:ConfirmAccount uns eine relativ einfache Abhilfe schaffen? --Norman (Diskussion) 11:11, 25. Aug. 2025 (CEST)

Auch einen Versuch wert. Jetzt wird es langsam Zeit, dass unser Sysadmin loslegt. --Klenzy (Diskussion) 11:49, 29. Aug. 2025 (CEST)

Da die Anlage neuer Benutzerkontos jetzt schon relativ lange gesperrt ist, wollte ich fragen ob es irgendwelche Neuigkeiten bzw. zeitliche Prognosen bzgl. einer Lösungsfindung und ihrer Umsetzung gibt. Ich will keinen Druck machen, da ich selber absolut keine Ahnung habe und das Problem selber nicht lösen könnte, aber da ein Wikipedia auch auf neue Mitglieder angewiesen ist, denke ich, dass es wichtig ist das Problem nach Möglichkeit zeitnah zu lösen. --Othello (Diskussion) 20:25, 20. Okt. 2025 (CEST)

Du hast völlig recht, das hat nichts mit Druck zu tun, sondern der Sysadmin muss jetzt endlich tätig werden. Ich habe ihn einige Male direkt angeschrieben, konnte aber bisher nichts bewirken. --Klenzy (Diskussion) 18:34, 22. Okt. 2025 (CEST)

Leider kann ich keinen Beitrag zu einer technischen Lösung beitragen und bin ehrlich gesagt einigermassen ratlos warum bisher nichts für uns sichtbares vorzuweisen ist. Gebt mir bitte ein paar Tage, dann melde ich mich wieder hierzu. --Norman (Diskussion) 19:56, 22. Okt. 2025 (CEST)

Passend dazu gibt es heute morgen Neuigkeiten, die Moderation-Extension ist seit gestern abend erfolgreich im Testwiki installiert. Ich werde in den kommenden Tagen testen, aber gebt mir bitte ebenfalls ein paar Tage - ich stecke noch in der Endphase eines Umzugs. Im Moment nutze ich zum Beispiel Nachbars Internetzugang, unserer funzt noch nicht. ConfirmAccount bereitet derzeit unbegreifliche technische Probleme. AbuseFilter müsste theoretisch automatisch vorhanden sein, ist aber unendlich komplex und kompliziert. --Klenzy (Diskussion) 10:12, 23. Okt. 2025 (CEST)

Viel Erfolg @Klenzy beim Austesten. Zwischenzeitlich habe ich mir eine Übgangslösung überlegt, nämlich eine manuell Neuanlage von interessierten Benutzern. Hierzu sollen diese eine Mail an eine auf dem PP-Server gehostete E-Mail-Adresse senden. Angaben sind nur a.) der gewünschte Benutzername b.) eine gültige E-Mail-Adresse. Aufgrund dieses Antrags kann dann ein Admin (zeitversetzt) den Benutzer manuell anlegen! Der neue Benutzer erhält dann eine E-Mail mit einem zufällig generierten Passwort zugeschickt. Was haltet ihr davon? --Norman (Diskussion) 10:47, 25. Okt. 2025 (CEST)

Was ich davon halte? Schnellstmöglich einführen. --Klenzy (Diskussion) 12:53, 25. Okt. 2025 (CEST)

Es ist bei weitem besser als der derzeitige Zustand. Schlimmer als der Spam, der sowieso in der Inbox landet kann es auch nicht sein. --Thinman (Diskussion) 20:52, 25. Okt. 2025 (CEST)

Dafür, falls noch nicht umgesetzt. --Debugger (Diskussion) 15:18, 11. Nov. 2025 (CET)

Wir haben Mitte November 2025. Ist die jetzige Lösung nun die neue Dauerlösung? Wie hat sich die Moderation-Extension im Testwiki geschlagen? --GolfSierra (Diskussion) 11:23, 18. Nov. 2025 (CET)

Ich kann zum aktuellen Status nur sagen, dass ich auch keine weitere Infomationen habe, beziehungsweise von keinen weiteren Aktivitäten berichten kann. Es sieht so aus, dass die Erweiterungen noch nicht läuft. Wir haben stattdessen aber ein funktionierendes manuelles Verfahren (Antrag per E-Mail), das bisher aber nur ein einziges mal von einem Interessierten in Anspruch genommen wurde. Insofern benötige ich die Extension nicht wirklich. --Norman (Diskussion) 11:03, 19. Nov. 2025 (CET)

Die Extensions sind noch ungetestet, ich möchte das weiter ergebnisoffen verfolgen. Die letzten 4 Wochen Untätigkeit gehen auf mein Konto. --Klenzy (Diskussion) 16:54, 19. Nov. 2025 (CET)

Extensions zur Spambekämpfung, Testergebnis

Die Verzögerung bitte ich zu entschuldigen.

• AbuseFilter: Sieht mega-kompliziert aus, erfordert einen enormen Aufwand zur Einarbeitung und Test. Daher nicht getestet.
• Moderation: Funktioniert eigentlich fast genau so, wie ich mir vorgestellt habe. Leider eine grottenschlechte Bedienung. Beispielsweise kann man als Moderator mit einem einzigen versehentlichen Klick alle in der Warteschlange stehenden Änderungen komplett verwerfen oder komplett freigeben, und damit ziemlich viel Unheil anrichten. Es kann außerdem zu Bearbeitungskonflikten kommen, wenn Änderungen noch nicht freigegeben wurden. Zu guter Letzt: Die noch nicht freigegebenen Änderungen eines Benutzers sind sogar für diesen selbst nicht sichtbar. Bei einem Spammer ist mir das egal oder sogar nützlich. Für jemanden, der ernsthaft mitarbeiten will, ist das extrem verwirrend, unzumutbar. Fazit: ungeeignet.
• ConfirmAccount: Macht genau das, was Norman derzeit als Übergangslösung eingerichtet hat. Der Interessent beantragt ein Benutzerkonto, nicht wie derzeit per Mail, sondern per Online-Formular. Die Admins erhalten ein Mail, dass ein neuer Antrag da ist. Einer der Admins kann den Antrag dann akzeptieren oder verwerfen (im Prinzip wie oben mehrfach gefordert "ein Klick").
  • Im Unterschied zu bisher muss der Antragsteller verpflichtend eine Mailadresse angeben.
  • Der Antragsteller bekommt zur Verifizierung einen Bestätigungslink per Mail. Damit sind falsche Mailadressen unmöglich.
  • Es ist nicht möglich, mit derselben Mailadresse weitere Benutzerkonten zu beantragen.
  • Nicht bearbeitete Anmeldungen verfallen nach einer gewissen Zeit. Ich finde nirgends eine Beschreibung, wie lang diese Zeit ist.
  • Unbedingt erforderlich ist eine klare Abstimmung unter den Admins, wer die Anträge wann bearbeitet.

Fazit: Nach meiner Einschätzung ist ConfirmAccount zur Abwehr von Spammern und Spambots geeignet. Der Nachteil ist eine deutlich erhöhte Einstiegshürde. --Klenzy (Diskussion) 12:13, 26. Nov. 2025 (CET)

Ich denke maximal ein Tag Verzögerung ist doch vertretbar, wahrscheinlich geht es in der Regel sogar schneller, wenn man den Account tagsüber anlegen will. Die Admins sind ja durchaus sehr aktiv. --Debugger (Diskussion) 12:51, 26. Nov. 2025 (CET)

@Klenzy: Vielen Dank für die Tests. Die Nutzung von ConfirmAccount und die damit verbundene (gering) erhöhte Einstiegshürde ist meiner Meinung nach ein guter Kompromis. Sie bietet uns Schutz gegen die automatisierte Flut von Spam-Accounts. Die Abstimmung unter uns Admins stelle ich mir so vor, dass wir dies händeln, wie bei den zu "löschenden Artikeln", als tägliche Aufgaben/Check. Umso mehr wäre es allerdings wünschenswert, wenn sich mindestens ein weiterer Admin als Kandidat auch außerplanmässig aufstellen lassen würde. --Norman (Diskussion) 08:31, 27. Nov. 2025 (CET)

Besser gut getestet als zu schnell entschieden. Wenn eines einen Admin schon vor der Instaltion erschlägt, scheidet es wohl zurecht aus. Das ConfirmAccount scheint unseren Anforderungen zu entsprechen, deswegen befürworte ich dessen Einsatz. --Thinman (Diskussion) 20:31, 27. Nov. 2025 (CET)

Konsistenz der Kopfvorlagen

Mir ist gerade etwas aufgefallen. Wenn man auf einem Roman einer Miniserie ist, dann wird im Kopfteil nur der Name der Miniserie genannt. Das ist ja okay, weil darüber Perry Rhodan-Miniserien verlinkt ist. Klickt man sich aber auf eine Zyklen-Übersicht, dann endet der Artikelname selbst auf ... (Serie), im Kopfteil steht aber ... (Miniserie) in den Links. Auch beim verlinkten Portal. Klickt man auf das Portal, ist der Arktikelname wieder nur ... (Serie). Und auch im Kopfteil ist nun wieder nur ... (Serie) verlinkt und nicht ... (Miniserie), wie bei der Zyklenseite. Das ist nur ein ganz kleines Detail, aber es ist in letzter Konsequenz nicht ganz konsistent durchkomponiert. --Debugger (Diskussion) 16:32, 11. Jul. 2025 (CEST)

Das wäre was für Cuore. --GolfSierra (Diskussion) 11:04, 30. Jul. 2025 (CEST)

Neue Captcha-Fragen?

Die Aktivität von SPAM-User nimmt aktuell wieder zu. Als kurzfristiges Abwehrmittel sehe ich momentan neue Captcha-Fragen zu hinterlegen? Ich habe ein paar nicht ganz so einfache PR-spezifische Fragen und Antworten formuliert. Spricht von Eurer Seite etwas dagegen diese durch unserem Serveradmin einbauen zu lassen? Gerne kann ich diese euch über einen anderen Weg zukommen lassen. --Norman (Diskussion) 07:54, 18. Mai 2025 (CEST)

Für mich OK. --Johannes Kreis (Diskussion) 10:33, 18. Mai 2025 (CEST)

Als Interim-Lösung OK. Langfristig müssen wir ein besseres System einführen. --GolfSierra (Diskussion) 20:31, 18. Mai 2025 (CEST)

Die neuen Fragen (ca. 20) werden bis Ende der Woche im Testwiki eingebaut. Wer mag darf testen. Rückmeldungen bitte hier. Wenn keine Einwände, werden die Fragen danach ohne weitere Ankündigung im Echt-Wiki eingebaut. --Norman (Diskussion) 10:27, 21. Mai 2025 (CEST)

Die neuen Fragen sind seit eingen Tagen im Test-Wiki aktiv. Meine Tests waren alle positiv! Könnte ihr das bestätigen? Dann könnte unser Sysadmin diese ins Echt-Wiki übernehmen. Hoffentlich entschärft dies für eine gewissen Zeit die unerwünschten Anmeldungen. --Norman (Diskussion) 20:27, 9. Jun. 2025 (CEST)

Getestet mit einer Neuanmeldung. Funktioniert. --GolfSierra (Diskussion) 22:49, 9. Jun. 2025 (CEST)

@Admins: Gibt es irgendwelche Einwände, wenn die neuen Captcha-Fragen zeitnah ins Echt-Wiki eingestellt werden? --Norman (Diskussion) 17:42, 10. Jun. 2025 (CEST)

Nicht von meiner Seite. --JoKaene 17:47, 10. Jun. 2025 (CEST)

Habe nichts dagegen. --Johannes Kreis (Diskussion) 20:58, 10. Jun. 2025 (CEST)

Sind nun in "Echt" aktiv! Dank an unseren SysAdmin. --Norman (Diskussion) 12:15, 12. Jun. 2025 (CEST)

Da bin ich aber mal gespannt, hoffentlich bringt's was. --Johannes Kreis (Diskussion) 13:01, 12. Jun. 2025 (CEST)

Um Johannes' Frage aufzugreifen: Ich glaube, die Antwort ist ein Nein! Es kommen immer noch eine Menge SPAM-Accounts, die Werbemüll posten. Vielleicht sind die Captcha-Fragen mit KI-Unterstützung zu einfach zu beantworten? Ich bin dafür, eine manuelle Freischaltung neuer Anmeldungen einzuführen. --GolfSierra (Diskussion) 15:22, 28. Jul. 2025 (CEST)

Ich stimme mittlerweile auch zu, diese Maßnahme mangels anderer Alternativen zumindest vorübergehend einzuführen. --Norman (Diskussion) 19:06, 28. Jul. 2025 (CEST)

Dito. --Johannes Kreis (Diskussion) 21:56, 28. Jul. 2025 (CEST)

Upgrade-Vorschlag zur Diskussion

Einleitung

Die Perrypedia ist die zentrale Wissensplattform rund um das Perry-Rhodan-Universum. Seit ihrer Gründung wurde sie von einer stetig wachsenden Community gepflegt und weiterentwickelt. Mit Millionen von Einträgen, Hintergrundinformationen, Querverweisen und Diskussionen hat sie sich als unverzichtbares Nachschlagewerk etabliert – sowohl für eingefleischte Fans als auch für neue Leser.

Das Projekt Perrypedia V2 zielt darauf ab, die technische Infrastruktur der Plattform grundlegend zu modernisieren. Es geht dabei nicht nur um ein Update der verwendeten Software, sondern um eine komplette Neuausrichtung der Plattform, die sowohl den gestiegenen technischen Anforderungen als auch den Wünschen der Community gerecht wird.

Projektziel

Das zentrale Ziel von Perrypedia V2 ist es, eine moderne, skalierbare und wartbare Plattform zu schaffen, die den Anforderungen der Zukunft gewachsen ist. Die Plattform soll so aufgestellt werden, dass sie kontinuierlich gewartet, optimiert und sicher betrieben werden kann, ohne dass die Nutzererfahrung oder die Arbeitsweise der Redaktion beeinträchtigt wird.

Ein weiterer Aspekt ist die Benutzerfreundlichkeit: sowohl für die Endanwender als auch für die Administratoren. Dabei stehen drei zentrale Ziele im Vordergrund:

1. Erhöhte Verfügbarkeit: Sicherstellung eines stabilen Betriebs auch bei hohem Nutzeraufkommen.
2. Skalierbarkeit: Möglichkeit zur Erweiterung und Anpassung der Plattform an künftige Anforderungen.
3. Benutzerfreundlichkeit: Verbesserung der Redaktionstools und des Zugangs für neue Mitwirkende.

Warum Perrypedia V2?

Die bisherige Infrastruktur der Perrypedia stieß zunehmend an ihre Grenzen. Viele der verwendeten Technologien waren veraltet, und die Plattform wies eine Reihe von Schwachstellen in den Bereichen Sicherheit, Skalierbarkeit und Benutzerfreundlichkeit auf. Mit Perrypedia V2 wird nun ein klarer Schritt in die Zukunft gemacht: moderne Architektur, leistungsfähige Container-Technologien und ein agiles Verwaltungskonzept, das die Community besser einbezieht.

Durch die Neuausrichtung wird die Perrypedia nicht nur schneller und stabiler, sondern auch langfristig zukunftssicher. Die Plattform wird so strukturiert, dass sie künftig leichter erweitert werden kann, und es wird eine solide Grundlage für kontinuierliche Verbesserung geschaffen.

Die neue Architektur im Überblick

Das Kernstück von Perrypedia V2 ist ein modernes, verteiltes System auf Basis von Docker Swarm. Die Plattform läuft auf mehreren VPS-Servern, wodurch eine hohe Verfügbarkeit und Ausfallsicherheit erreicht wird. Durch die Containerisierung lassen sich einzelne Dienste wie Webserver, Datenbanken und MediaWiki-Instanzen gezielt verwalten und skalieren, ohne dass der Gesamtbetrieb beeinträchtigt wird.

Ein umfassendes Monitoring sorgt dafür, dass auftretende Probleme schnell erkannt und behoben werden können. Zudem ermöglicht die modulare Architektur eine einfache Integration neuer Funktionen und Updates, was die Wartbarkeit deutlich verbessert.

Nutzerorientierung und Community-Fokus

Die neue Perrypedia wurde explizit mit Blick auf die Community entwickelt. Die redaktionellen Tools wurden umfassend überarbeitet, um einfacher und intuitiver nutzbar zu sein. Neue Nutzer können schnell und unkompliziert in die redaktionelle Arbeit einsteigen, was das Wachstum und die Qualität der Inhalte zusätzlich fördert.

Verbesserte Suchfunktionen, klare Strukturen und eine benutzerfreundliche Oberfläche sorgen dafür, dass sowohl erfahrene Nutzer als auch Neulinge effizient arbeiten können. Dadurch wird nicht nur die Mitarbeit erleichtert, sondern auch die Qualität und Aktualität der Inhalte nachhaltig gesichert.

Wartbarkeit, Sicherheit und Zukunftsfähigkeit

Ein zentrales Anliegen bei der Entwicklung von Perrypedia V2 ist die Wartbarkeit und Betriebssicherheit der Plattform. Alle Komponenten sind modular aufgebaut und ermöglichen unabhängige Wartung und Upgrades. Sicherheitskonzepte wie verschlüsselte Backups und regelmäßige automatische Validierungen stellen sicher, dass Datenverluste und Ausfälle minimiert werden.

Darüber hinaus ist die Plattform auf Wachstum und Anpassungsfähigkeit ausgelegt. Neue Anforderungen, sei es durch technische Innovationen oder steigende Nutzerzahlen, können flexibel integriert werden.

Organisatorischer Rahmen

Perrypedia V2 wird von einer engagierten Gruppe von Ehrenamtlichen entwickelt und gepflegt. Klare Rollenverteilungen und transparente Prozesse sorgen für effiziente Arbeitsabläufe. Die zentrale Dokumentation ermöglicht es, Wissen dauerhaft zu sichern und einfach zugänglich zu machen, sodass auch neue Mitwirkende schnell einsteigen können.

Fazit und Ausblick

Mit Perrypedia V2 erhält die Community eine Plattform, die technisch auf dem neuesten Stand ist und langfristig sicher betrieben werden kann. Die Neuausrichtung stellt sicher, dass die Perrypedia auch in Zukunft als wichtigste Informationsquelle für das Perry-Rhodan-Universum fungiert und weiter wachsen kann. (unsignierter Beitrag von Benutzer:HopeForPeace)

Zur Info hier einige Details zu Docker Swarm. Da Mediawiki ja anscheinend weiterverwendet wird, sollte sich durch die Änderung der Infrastruktur für die Nutzer optisch nichts verändern. Dann lese ich jedoch "Verbesserte Suchfunktionen, klare Strukturen und eine benutzerfreundliche Oberfläche" und mir stellt sich die Frage, wie denn das am Frontend (beim Nutzer) aussieht? Unser derzeitiger Provider Contabo bietet VPS-Server an. Die PP läuft derzeit auch auf einem VPS Server. Wenn jetzt davon gesprochen wird, mehrere Server ("Die Plattform läuft auf mehreren VPS-Servern") einzusetzen, wie sieht das dann finanziell aus? Kostet die PP dann über 100 € im Monat? --GolfSierra (Diskussion) 10:41, 4. Apr. 2025 (CEST)

Auf ausdrücklichen Wunsch vom Big Boss (Leo) habe ich mich bemüht nicht zu sehr in die technischen Details zu gehen.

Natürlich bringt jede generelle Änderung und Erneuerung meist auch Änderungen, unter Umständen auch direkt sichtbare, mit sich.

Ich werde diesbezüglich, wenn das ganze technische funktioniert und stabil ist, Vorschläge machen die ihr dann als Community beurteilen könnt.

Relativ weit unten in der Software Hierarchie ist weiterhin Mediawiki im Einsatz. Alles Webserver ist NGINX anstelle von Apache vorgesehen.

Darüber hinaus gibt es jede Menge Software die für unterschiedliche Zwecke zum Einsatz kommt.

Zur Zeit "betreibe" ich aus meiner Tasche 4 Server bei Contabo zum Entwickeln. Kosten zur Zeit rund 55 Euro. Eine, sofern gewünscht, scharfe Realisierung benötigt mehr Festplattenspeicher und könnte, je nach Vertragsschluss mit Contabo, in dem Bereich liegen.

Genaue technische Beschreibungen sind Teil der geplanten Dokumentation wie beschrieben.

Bei Bedarf könnt ihr mich gerne direkt per E-Mail kontaktieren für genauere Informationen.

--Serveradministrator (Diskussion) 14:20, 4. Apr. 2025 (CEST)

Danke für die Hinweise. Ich weiß die Arbeit zu schätzen, die allein in der Vorbereitung eines solchen Umbaus liegt, vielen Dank schon jetzt dafür. Wenn es den Betrieb der Perrypedia zukunftssicher macht (weil z.B. Softwaremodule, für die es absehbar keine Softwarepflege mehr geben wird, durch aktuelle Alternativen ersetzt werden) und es dann dem Serveradmin die Arbeit auch noch erleichtert, bin ich allein aus diesen zwei Gründen dafür. Wenn sich für die Nutzer Änderungen im Look-and-feel ergeben sollten, dann ist das eben so, daran kann man sich sicher gewöhnen. Wenn die Kosten dann auch noch im Rahmen bleiben, geht mein Daumen hoch. Idealerweise stellst Du uns mal die neue Nutzeroberfläche vor, gerne auch als Bild ohne Interaktion. --GolfSierra (Diskussion) 14:50, 4. Apr. 2025 (CEST)

Einleitend muss ich dazu erwähnen, dass HopeForPeace unbekannterweise im Hintergrund sehr aktiv ist um die Perrypedia technisch auf ein zeitgemäßes Niveau zu heben. Wie ihr wisst sind wir nicht mehr bei allen Systemkomponnten wie z.B. Mediawiki auf einem aktuellen Supportlevel. Noch läuft die Perrypedia stabil, aber mittelfristig besteht Handlungsbedarf. Ich bin froh, dass er nun seine Gedanken hier darlegen konnte, denn sie sollten Bestandteil von uns allen sein. Ich bitte Euch ihn bei seinem Vorhaben zu unterstützen. --Norman (Diskussion) 08:10, 5. Apr. 2025 (CEST)

Ich bin kein IT'ler, deshalb bin ich nicht in der Lage, den Großteil der obigen Erläuterungen in jedem Detail zu verstehen, und sie nur zu interpretieren oder mich auf Aussagen zu verlassen reicht mir (noch) nicht. (Z.B. »veraltete Technologie«: Die stark genutzte Wikipedia läuft meines Erachtens nach recht stabil, wenn auch unter der höheren Version 1.44) Auch eine weitergehende Suche im Netz hat mich nicht wirklich erleuchten können. Eine Meinungsfindung ist mir also aktuell nicht möglich. Was mir weiterhelfen würde, ist ein Anschauungsbeispiel. Gibt es Wikis, die bereits mit diesem System arbeiten?

Eine weitere Frage: Die Perrypedia hat nur sehr selten mehr als 10.000 Besucher am Tag (normal sind 3500–4000). Spielt das eine Rolle bei der Entscheidung, dieses komplexere System (mein Eindruck) zu wählen, und ergibt sich daraus ein vernünftiges Kosten-Nutzen-Verhältnis? --JoKaene 08:22, 5. Apr. 2025 (CEST)

Selbstverständlich müssen wir die Verhältnismässigkeit beachten. Deshalb ist es wichtig, dass wir mit HopeForPeace zusammen solche Einschätzungen teilen. Letzendlich ist er aber der Spezialist. Insofern hoffe ich dass diese Diskussionen hier und in diesem Rahmen endlich öffentlich stattfinden. --Norman (Diskussion) 09:17, 6. Apr. 2025 (CEST)

Technisch ist alles was unser Sysadmin sagt richtig. Docker sind quasi Industriestandard. Gleichwohl frage ich mich, ob die genannten Vorteile bei uns zum Tragen kommen. Wir haben drei Komponenten, Apache als Webserver, Mediawiki als Anwendung und MySql als Datenbank. Klar kann man die nun jeweils in einen Docker verschieben, was diese dann voneinander trennt. Man muss sich dann keine Sorgen mehr machen, dass Anwendung A andere Softwarepackete braucht als Anwendung B. Wir betreiben aber EIN Mediawiki, das kommt mehr oder weniger als ein Packet für alle drei Anwendungen. Ein weitere Punkt ist die Skalierbarkeit. Ich habe jetzt keine aktuellen Performancedaten zur Hand, aus meiner Vergangenheit weiß ich noch das CPU oder Bandbreite nie wirklich ein Problem waren. Zugegeben, wir hatten ein paar Mal Webcrawler etc, die uns Probleme bereiteten, aber normales Benutzerverhalten stellte zu meiner Zeit kein Problem dar. Wo Docker Vorteile bringen kann, ist beim Update. Dort wird für das Update der/die aktuellen Docker geclont und das Update auf einem Clon gefahren. Funktioniert alles, werden die alten Docker gelöscht, wenn es nicht funktioniert werden die alten Docker einfach wieder verwendet. Der Weg zurück ist schon sicherer. Docker selbst muss natürlich auch administriert werden, allerdings reichen dafür ein paar Befehle und Konfigurationsdateien aus. An sich auch keine Raketenwissenschaft. Ich muss gestehen, dass ich es nicht als ein Muss ansehe auf Docker zu gehen. Wenn ich es bezahlen müsste, dann würde ich es nicht tun. Wenn es jedoch jemand aus Spaß machen möchte, warum nicht. --Poldi (Diskussion) 11:52, 13. Apr. 2025 (CEST)

Container-Technologie, nicht notwendigerweise Docker, ist heute Standard, soweit Zustimmung. Davon zu unterscheiden ist aber Docker Swarm, was einer Container-Orchestrierung auf Basis von Docker ist. Und hier muss man festhalten, dass Docker Swarm ganz klar das Rennen der Orchestrierung-Lösungen gegen Kubernetes verloren hat. Setzen wir hier auf ein totes Pferd? --Cdoubleplusgood (Diskussion) 15:53, 13. Apr. 2025 (CEST)

Danke für eure bisherigen Beiträge. Ich kann leider mit meinen technischen Kenntnissen hier nicht mit mithalten, aber zusammenfassend lässt sich wohl sagen, dass heute die Performance stimmt und dass wir keine höhere Skalierbarkeit für das Tagesgeschäft benötigen. Soweit scheint der Ansatz mit Docker Swarm "zu komplex" und bezüglich der Kosten zu hoch zu sein. Was könnte aber stattdessen ein praktikabler Weg sein, um bezüglich der Releaseständen aller wichtigen Komponenten auf ein aktuelles System und somit auf zukunftsicheres System zu migrieren? --Norman (Diskussion) 09:00, 14. Apr. 2025 (CEST)

Docker Swarm ist out-of-the-box verständlich, schnell konfiguriert und erfordert keine komplexen YAML-Definitionen oder Helm-Charts wie Kubernetes. Ein einfacher Befehl wie docker swarm init reicht oft schon für ein funktionierendes Cluster – im Gegensatz zu Kubernetes mit seinen zahlreichen Komponenten (RBAC, etcd, CNI usw.). Für kleinere bis mittlere Teams oder Einzelentwickler ist das ein enormer Vorteil.

Swarm ist direkt in Docker integriert – es gibt keinen externen Overhead durch zusätzliche Services wie kubelet, API-Server oder etcd. Weniger Moving Parts bedeuten weniger Fehlerquellen, geringeren Wartungsaufwand und eine geringere Angriffsfläche. Gleichzeitig bleibt das bewährte Docker-Ökosystem mit Compose, CLI und Registry vollständig nutzbar.

Was viele vergessen: Docker Swarm unterstützt Rolling Updates, Replikation, Self-Healing und Platzierungsregeln – alles Features, die oft ausschließlich mit Kubernetes assoziiert werden. Auch Healthchecks und Auto-Restarts sind nativ integriert und leicht nutzbar.

Im Bereich Netzwerk punktet Swarm mit eingebautem Overlay-Netzwerk und DNS-basierter Service-Discovery. Externe Tools wie Calico, Flannel oder Cilium sind nicht notwendig. Mit Loadbalancern wie Traefik oder NGINX lässt sich ein vollständig swarm-kompatibler Reverse-Proxy aufbauen – simpel und effizient.

Ein weiterer Vorteil ist der geringe Ressourcenverbrauch. Swarm läuft problemlos auf kleinen VPS mit 2 GB RAM und 1 vCPU. Damit eignet es sich ideal für kostensensible Projekte, Edge-Deployments oder private Rechenzentren. Es braucht keine High-End-Master-Nodes oder große Infrastruktur.

Auch im Bereich CI/CD und GitOps ist Docker Swarm keinesfalls limitiert. Mit Tools wie Watchtower, Portainer, Ansible oder einfachen Shell-Skripten lässt sich ein schlanker DevOps-Workflow realisieren – ganz ohne Kubernetes-Overhead. Der Befehl docker stack deploy kann problemlos als Teil eines GitOps-Prozesses genutzt werden.

Swarm ist ausgereift, stabil und produktiv erprobt. Im Gegensatz zu Kubernetes gab es in Swarm nie disruptive API-Breaks oder instabile Versionen. Logs sind verständlich, Updates vorhersehbar. Auch Debugging und Monitoring sind ohne Zusatztools möglich.

Und schließlich: Swarm wird weiter unterstützt. Das Moby-Projekt ist aktiv, Docker Inc. äußert sich regelmäßig zum fortgesetzten Support. Werkzeuge wie Portainer, Libre.sh, CapRover oder OpenMediaVault setzen nach wie vor auf Swarm – nicht als Notlösung, sondern bewusst als pragmatische Wahl.

Ich will keine Clusterverwaltung lernen, sondern Services betreiben. Swarm erlaubt mir genau das – einfach, stabil und nachvollziehbar. Solange mein Setup nicht die Größe eines Großunternehmens annimmt, bleibe ich bei Docker Swarm – aus Überzeugung, nicht aus Bequemlichkeit.

Wenn der Tag kommt, an dem ich komplexe Anforderungen erfüllen muss (z. B. Multi-Tenant HA auf 100+ Nodes), dann kann ich jederzeit migrieren. Bis dahin ist Swarm die realistischere, wartungsärmere und ruhigere Lösung. --Serveradministrator (Diskussion) 15:11, 5. Jun. 2025 (CEST)

Zyklen und Kategorien

• Bitte die Admins um Prüfung, ob nicht alle Zyklen chronologisch ab Dritte Macht unter den Kategorien eingepflegt werden könnten - die jeweilige Auswahl wäre dann wesentlich leichter,

• es fehlt die small-Version auch für die TB,

• es gibt mehr Formatvorlagen als dafür eingepflegte Kategorien

--Johann (Diskussion) 19:52, 27. Jan. 2025 (CET)

Es tut mir leid, aber ich komm' einfach nicht drauf, was dein eigentliches Anliegen ist. --JoKaene 05:59, 28. Jan. 2025 (CET)

Punkt 2: Du meinst die Links bei »Quellenangabe im Fließtext« im Editiermodus, richtig? Ich habe leider keine Ahnung, wie man das ergänzt. --Johannes Kreis (Diskussion) 06:59, 28. Jan. 2025 (CET)

Das wäre einfach. Wenn aber auch alle Kategorien da hinein sollen, bin ich sehr dagegen. Das ergibt einen derart riesigen Block, der für mich jeden Rahmen sprengt. --JoKaene 07:11, 28. Jan. 2025 (CET)

Nachdem ich gerade nochmal in mich gegangen bin, und falls tatsächlich der Vorlagenblock im Edit-Modus gemeint ist, habe ich nun doch einen Lösungsansatz. Ich bitte aber Johann, sein Anliegen zu präzisieren. --JoKaene 07:36, 28. Jan. 2025 (CET)

Hallo miteinander,

1. ich wollte anregen, dass alle Zyklen ab Beginn chronologisch unter z.B. Kategorien Zyklen erfasst werden,

2. es fehlt unter Quellenangabe im Fließtext die Variante small für die TB,

3. es gibt insgesamt 10 Formatvorlagen, nur 3 sind in den Kategorien erfasst.

Dies betrifft den Vorlageblock.

--Johann (Diskussion) 12:03, 28. Jan. 2025 (CET)

Es wäre schön gewesen, wenn du meine Kernfrage beantwortet hättest, nämlich ob es um den Vorlagenblock im Editfenster geht. Auch wenn ich es mir inzwischen denken kann; bevor ich mir eine Menge Arbeit aufhalse, möchte ich von möglichst vielen Mitarbeitenden wissen:

1. Wer ist mit dem Vorlagenblock in seiner jetzigen Form zufrieden/unzufrieden?
2. Welche Vorlagen sind dort gewünscht?
3. Auf was kann verzichtet werden? --JoKaene 15:47, 28. Jan. 2025 (CET)

Ich verstehe den Vorschlag zu den Kategorien nicht ganz. Chronologisch macht nur bei den Zyklen Sinn und da wäre es noch hilfreich, ob nach Veröffentlichung getrennt oder nicht. Rhodan-Zyklen getrennt von Atlan-Zyklen. Und ganz wichtig wäre auf welcher Seite denn? Einige Seiten werden vom Wiki automatisch alphabetisch sortiert. Da sieht es dann schlecht aus. --Poldi (Diskussion) 16:01, 28. Jan. 2025 (CET)

Im Vorlagenblock könnte man bei Quellenangabe im Fließtext: (PR xxxx) · (Atlan xxx) · (PR Neo xxx, Kap. xx) noch (PR-TB xxxx) aufnehmen. Das denke ich hat Johann unter Punkt 2 gemeint.

Zu Punkt 3 (Formatvorlagen): mit denen arbeite ich gar nicht. Ich setze die Kategorie immer manuell ein. Also reichen die drei angeführten für mich völlig aus.

Wenn ich das mit den Zyklen in den Kategorien am Ende des Artikels richtig verstehe, bin ich mit der automatischen Befüllung aller Kategorien nicht ganz einverstanden, da bei einem Artikel nicht alle Kategorien zutreffen müssen. Und das ist nur Mehrarbeit, wenn man die überzähligen Kategorien händisch löschen müsste. Allerdings wäre es nicht schlecht, wenn die richtig angeführten Zyklus-Kategorien in der chronologischen Reihenfolge sortierbar wären, was ich aber nicht glaube. --Cuore (Diskussion) 16:32, 28. Jan. 2025 (CET)

Zum Vorlagenblock: Ich bin zufrieden. Ich wäre dagegeben diesen aufzublähen. Über den einen oder andern Punkt kann man nachdenken. --Norman (Diskussion) 17:23, 28. Jan. 2025 (CET)

Bezüglich der "chronolgisch" sortierten Kategorien, verstehe ich immer noch nicht was Johann gerne angepasst hätte. @Johann: Vielleicht hilft ein konkretes Beispiel uns allen weiter. Ansonsten gehen wir alle von irgendwelchen Vermutungen aus. --Norman (Diskussion) 17:23, 28. Jan. 2025 (CET)

Ich wollte bei den chronologisch Kategorien anregen, dass ab Dritte Macht die jeweiligen Zyklustitel unter einer Kategorie erfasst werden. Wenn das nicht geht, ist es erledigt.

--Johann (Diskussion) 19:29, 28. Jan. 2025 (CET)

Ich versteh's immer noch nicht. Wo soll das so sortiert sein? --Poldi (Diskussion) 19:42, 28. Jan. 2025 (CET)

Ich glaube zu ahnen, dass es darum geht, das Die Posbis vor den Meistern der Inseln, aber nicht nach den Altmutanten steht. --Thinman (Diskussion) 10:25, 29. Jan. 2025 (CET)

Ich habe jetzt mal die small-Variante für Taschenbuch-Quellen hinzugefügt. Im Testwiki habe ich zusätzlich das Design des Quellenblocks zur Anschauung geändert (z.B. hier eisehbar). Ich find's übersichtlicher. --JoKaene 05:43, 29. Jan. 2025 (CET)

Habe hier unabsichtlich doch für viel Wirbel gesorgt. Der Kollege Thinman hats erfasst. Nochmal zur Verdeutlichung:

Punkt 1: Unter einem neuen Kategoriepunkt der heißen könnte: Zyklen die dann chronologisch dort aufgeführt sind. Beispiel: Kategorie:Die Dritte Macht, Kategorie:Atlan und Arkon, Kategorie:Die Posbis und so fort. Ich weiß, einmal viel Arbeit, aber die Zyklen sind übersichtlich im Quellenblock ersichtlich und man erspart sich suchen woanders während man einen Artikel erstellt. Die Zyklentitel sind sofort verfügbar.

Punkt 2: Wunderbar erledigt.

Punkt 3: Wenn die Formatvorlagen eh nicht verwendet werden, warum stehen dann 3 im Quellenblock. Den Speicherplatz kann man sich doch sparen.

Ich will aber hier niemand unter Druck setzen. Wenn JoKaene als Admi meint, dass ist zu aufwendig, bitte ich den Vorschlag als erledigt zu betrachten.

--Johann (Diskussion) 17:28, 29. Jan. 2025 (CET)

Ich versuch noch mal, meine Ansicht zu erläutern.

Zu Punkt eins: Aufwand ist zwar gegeben, dennoch ist es natürlich machbar. Ich gebe aber zu bedenken, dass wir hier am Ende über etwa 120 Zykluskategorien reden. Denn wenn ich jetzt nur die Hauptserie berücksichtige ist abzusehen, dass Mitarbeitende, die andere Serien bearbeiten (Atlan, Miniserien, Neo, etc.) diese Möglichkeit ebenfalls einfordern. Bedenke bitte, wie groß dieser Block dann wird. Zwar kann ich ihn in ein ausklappbares Fenster verpacken, aber für mich macht das die Sache nicht attraktiver. Bevor ich das umsetze, will ich deshalb mehr Zustimmung für deinen Vorschlag sehen.

Zu Punkt zwei: Hier frage ich nochmal nach. Soll ich es so belassen, wie es aktuell hier im Hauptwiki dargestellt wird, oder soll ich die Variante, die ich im Testwiki angelegt habe, umsetzen (siehe oben eingefügten Link)?

Zu Punkt drei: Da blicke ich immer noch nicht ganz durch. Welche Formatvorlagen werden eh nicht verwendet und wo ist der Zusammenhang? Im Absatz Kategorien sind die drei vermutlich am häufigsten verwendeten Kategorien eingefügt. Dazu die Kategorie:xxxx, die sich schnell anpassen lässt. Auch hier: Natürlich kann ich diesen Block ebenfalls erweitern, frage mich aber auch in diesem Fall: Wo höre ich auf?

Ich stelle also noch einmal die Frage in die Runde: Welche Wünsche gibt es zu dem Vorlagenblock, was soll rein und was vielleicht raus? --JoKaene 18:45, 29. Jan. 2025 (CET)

Vorlagenblock: Ich bin dafür, diesen möglichst so zu belassen, wie er sich über Jahre hinweg bewährt hat. Gegenüber geringfügigen Änderungen bin aber ich offen. Bitte bedenkt, dass man nicht immer ein großen Bildschirm zur Verfügung hat. Bin ich z.B. nur mit einem Notebook unterwegs, dann möchte ich nicht bei jeder Anpassung ewig lang bis zum Button "Änderung speichern" runterscrollen müssen. --Norman (Diskussion) 09:44, 30. Jan. 2025 (CET)

Mit der Anpassung wie im Testwiki wäre ich einverstanden. --Norman (Diskussion) 09:44, 30. Jan. 2025 (CET)

Von mir aus könnten die Vorlagen im Vorlagenblock komplett rausgenommen werden, denn ALLE Formatvorlage findet man zum "rausschnipseln" in der linken Navileiste. Den Punkt chronlogisch sortierte Zyklenkategorien kann ich nun zwar besser einordnen, aber hier teile ich die Meinung von Cuore, dass eine "komplette (sortierte) Vorschlagliste" (in neuen Artiekln) nicht zielführend ist, da der jetztige (gute) Zustand tangiert werden würde. Der Vorschlag hat etwas, aber wir haben nun mal schon sehr viele Zyklen-Kategorien (siehe: Portale zur Handlung (Zyklenübersicht)) und ich würde ungern Zyklen der Erstauflage z.B. mit Zyklen der Miniserien vermischen wollen. --Norman (Diskussion) 09:44, 30. Jan. 2025 (CET)

Ich sehe das so wie Norman. --GolfSierra (Diskussion) 10:32, 30. Jan. 2025 (CET)