PokéWiki:Allgemeine Diskussionsseite/Archiv 2022

Diese Seite ist das abgeschlossene Archiv der Allgemeinen Diskussionsseite.

Bitte editiere hier nichts mehr.

Für Kommentare bitte die aktuelle Seite verwenden.

Siehe auch-Abschnitte im gesamten Wiki

Hallo zusammen! Durch die Umstellung einiger Navigationsleisten quer durch das Wiki ist mir aufgefallen, dass unsere Navigationsleisten zwar sehr gut dabei helfen, sich themenbezogen durch das Wiki zu bewegen, allerdings fehlt mir dabei eine kleine Komponente, die das Ganze meiner Meinung nach etwas förmlicher machen würde. Dabei geht es mir um einen separaten Abschnitt == Siehe auch == für jede Navigationsleiste oder Ansammlung an Navigationsleisten, die wir in unseren Artikeln benutzen. Für mich liegen die Vorteile klar auf der Hand: Einerseits hätte man direkt im TOC einen Hinweis, dass es zu diesem Artikel, den man sich gerade anschaut, auch andere, themenverwandte Artikel gibt. Der Artikelabschluss wäre andererseits förmlicher. Bisher machte sich bei mir der Eindruck breit, dass die Navigationsleisten ans Ende der Artikel gepackt werden, weil sie da sein müssen, weil es irgendeiner Projektmusterstruktur entspricht oder weil die da einfach hingehört. Der Artikelabschluss wäre also, genau weil es so oft so viele Navigationsleisten an Artikelenden gibt, durch diesen Abschnitt vereinheitlicht, sogar über das ganze Wiki. Wann immer es einen Siehe auch-Abschnitt gebe, kann man als Leser also definitiv von einer Navigationsleiste ausgehen und weiterlesen.

Ich bin gespannt auf eure Meinungen dazu, gerne auch mit Rückfragen zur genauen Vorstellung, wobei ich davon ausgehe, dass verstanden ist, dass jede Navigationsleisteneinbindung einen Artikel-Abschnitt bekommen soll. Hier auch noch ein paar Beispiele: Arceus, Band 2 (Pocket Monsters SPECIAL, Bisaflor, Claw City, Flammenwurf, Giovanni, Hyperball, Pokémon Sonne und Mond, Wizards Black Star Promos (TCG)

Grüße! -- ~~ feblue 00:41, 2. Jan. 2022 (CET)

Wären da erstmal nur die Navigationsleisten drin? Ich war erst verwirrt, weil ich an die "Siehe Auch" Abschnitte von Wikipedia gedacht hatte (siehe z. B. hier). An sich könnte man solche sonstigen Seitenlinks zum Weiterlesen ja auch in den Abschnitt packen (wegen optischer Gründe über die Navi-Vorlagen). Wär dann halt viel nach eigenem Ermessen, was imo. aber kein Ding ist. Also ich find die Idee gut :D Der Vorschlag an sich mit den Navis allein lässt sich ja auch flott botten, also gehts hier nicht um ein Mammutprojekt.--DeXter 01:07, 2. Jan. 2022 (CET)

Kann ich mich bei Orten nicht mit Anfreunden. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:24, 2. Jan. 2022 (CET)

Gegen Siehe-Auch-Abschnitte wie sie aktuell verwendet werden habe ich nichts und würde die Idee zumindest moralisch unterstützen wenn es darum ginge, mehr solcher Abschnitte im Wiki zu haben. Die Navigationsleisten aber da dran zu koppeln halte ich nicht für eine gute Idee - erstmal scheint es mir nicht sonderlich elegant nur für Navigationsleisten eine Überschrift zu haben in welcher sich sonst kein Inhalt befindet - wirkt auf mich als würden da Stichpunkte fehlen; ist aber nur ein subjektives Argument. Mehr Mühe habe ich damit, dass wenn wir Navigationsleisten als Teil der Seite statt als Seitenende betrachten dies dazu führen sollte, dass der (leider ebenfalls nur spärlich vorhandene) Einzelnachweis-Abschnitt sowie ein allfälliger Weblinks-Abschnitt unter die Navigationsleisten rutschen würde. Das scheint mir aus Nutzerfreundlichkeits-Sicht nicht sonderlich gut, denn wir hatten das System "navigationsleiste am Ende" nun schon so lange dass dies in Artikeln mit Einzelnachweisen oder Weblinks wahrscheinlich zu momentärer Verwirrung führen würde weil es "falsch" aussieht. Ausserdem sieht meiner Meinung nach irgendwas unter Navigationsleisten nicht schön aus. --Mecanno-man^Mäh 12:13, 2. Jan. 2022 (CET)

@Mec, die beiden Abschnitte, die du ansprichst, könnte man doch einfach über den Siehe Auch Abschnitt verlegen. Die sind ja i. d. R. recht kurz und wären dann wie bisher über den Navis. Zu dem subjektiven Argument von dir grob am Anfang deiner Nachricht: wie sähest du solche Seitenlinks wie ich sie beschrieben habe? Dann wäre da ja noch ne unordered list (die mit den Bobberle statt Zahlen) mit ein paar Links über den Navis.

@Ryu, was genau stört dich daran? Das allgemeine Konzept, einzelne Aspekte oder sonstiges? Wenn das klar wäre, könnte man damit arbeiten.--DeXter 12:23, 2. Jan. 2022 (CET)

Ich sehe nichts darin, was deinen Vorschlag von der aktuellen Handhabung im Wiki unterscheidet, Dexter - Demnach siehe da mein erster Satz. Soweit ich es verstehe ist ja nur gedacht, die Navleisten in diesen Abschnitt einzufügen oder, wenn er noch nicht existiert, ihn zu erstellen - an dem was schon drin ist würde aber nichts verändert.

Was die Ordnung der Stichpunkte-Listen-Abschnitte angeht: Konzeptionell sollten imo. Links ins Wiki über Links aus dem Wiki raus stehen. Wenn da nur Navleisten im siehe auch sind ists imo. kein Problem, aber wenn's auch einfache Links in Stichpunkten sind gehören die imo. über die externen Links. Und zwei Siehe-Auch-Abschnitte wären verwirrend, bevor das jemand vorschlägt. --Mecanno-man^Mäh 12:51, 2. Jan. 2022 (CET)

@DeXter: Genau, erstmal wären da nur die Navigationsleisten drin. Die Abschnitte sind mir auch aus Wikipedia bekannt, weswegen mir die Idee auch kam, aber mir kam jetzt kein sinnvolles Konzept in den Kopf, welche Links man in die Abschnitte packen könnte und welche nicht. Es gibt auch eine Hilfeseite auf Wikipedia dazu. Die Hinweise dort wären aber mit meinem Vorschlag schon nicht kompatibel. Grundsätzlich stände weiteren Links in diesen Abschnitten von mir aus nichts im Wege, nur konzeptionell sollen Links ja in Fließtexten verarbeitet werden und nur Links, die nicht eingebaut werden können, sollten in Siehe auch landen.

@Mec: Über die Position der Abschnitte hatte ich auch schon länger nachgedacht, bin allerdings zu dem Entschluss gekommen, dass interne Links, was die Navs eben sind, über Weblinks und Einzelnachweise gehören. Das ist aber auch mit der Grund, warum ich die Idee hier anbringe, denn wie du sagst, Navs am Ende waren sehr lange das System. Ich denke aber, dass diese Veränderung wie jede andere irgendwann geläufig wäre. Zur Subjektiven Meinung: Meine ist genau das Gegenteil, ich finds nicht störend, dass da noch Links unter den Navs sind, eigentlich finde ich es so sogar ordentlicher 😅 -- ~~ feblue 13:53, 2. Jan. 2022 (CET)

siehe auch ist für mich immer ein direkter oder indirekter Bezug zum Artikel was z.b. die Orte Nav nicht ist. Daher will ich es dort nicht haben. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:56, 2. Jan. 2022 (CET)

Ich denke etwas, was nur der Navigation dient, sollte in jedem Artikel an derselben Stelle vorfindbar sein - bisher war es das (zuunterst) und ich sehe eigentlich wenig Grund das zu verändern. --Mecanno-man^Mäh 16:38, 2. Jan. 2022 (CET)

Mir persönlich gefällt die Idee nicht. Visuell erweckt es den Eindruck, als stünde dort eine leere Überschrift, was ich persönlich als störend empfinde. Für mich gehört in den Siehe-auch-Abschnitt eine Sammlung direkter Links auf andere Artikel, die direkt mit diesem im Zusammenhang stehen. Das ganze kommt für mich dabei näher an unsere aktuell verwendeten Variationen-Abschnitte, da hier die Ähnlickeiten groß genug sind, um einen direkten Verweis anzuführen. Navigationsleisten hingegen sind eine Sammlung von Links innerhalb eines Themenbereichs, die zwar zusammengehören, aber nicht zwangsläufig einen direkten Bezug zueinander haben. So sollte meiner Meinung nach in einem Abschnitt beim Hyperball ein Verweis zu einigen anderen Pokébällen zu finden sein, nicht aber zu sowas wie dem Brückbrief W, der zwar ein Item ist und daher in der Navigationsleiste zu finden ist, im Grunde aber keinen Bezug zum Hyperball aufweist. Erstbestes Beispiel, dass mir dazu auf Wikipedia eingefallen ist: Space Launch System^⁠(en), hier gibt es sowohl einen Abschnitt „See also“, der direkte Verweise zu weiterführenden Artikeln zum Thema sowie Links zu vergleichbaren Raketen enthält, als auch eine Reihe von Navigationsleisten am Ende des Artikels, die Links zu allen Raketen bei Wikipedia enthält. Ob wir deswegen jetzt aber beides bei uns einführen sollten? Diese Frage werde ich vorerst unbeantwortet im Raum stehen lassen. -- RobbiRobb 15:08, 4. Jan. 2022 (CET)

Ich kann mich aus mehreren Gründen auch nicht wirklich mit der Idee anfreunden. Visuell sieht es einfach komisch aus, eine leere Überschrift über der Nav zu haben. Das wirkt für mich als würde dort ein Inhalt schlichtweg fehlen. Auch sehe ich einen „Siehe auch“-Abschnitt als den falschen Ort für die Navs, da zumindest aus meiner Sicht der Abschnitt eine Handvoll wichtige Links geben sollte (z. B. SWSH Black Star Promos bekommt Promokarten, Schwert & Schild-Zyklus und S-P Promotional cards) und nicht einen ganzen Überblick über alles in dem Bereich. Auch finde ich, dass Abschnitte wie „Einzelnachweise“ und „Weblinks“ unter „Siehe auch“ gehören, was aber mit dem aktuellen Vorschlag unter den Navs wäre, was eher kontraproduktiv ist.
Fazit: Navs dort lassen wo sie aktuell sind und keine extra Überschrift einfügen. Mehr „Siehe auch“-Abschnitte würde ich aber befürworten. GrollenKette951

Laut Chattreffen vom 09.04.2022 ist dieser Punkt erledigt und kann ins Archiv. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:58, 10. Apr. 2022 (CEST)

Unsere Lieben Icons

Vor einigen Jahren gab es mal eine Diskussion wie wir die Pokémon im Entwicklungsabschnitt darstellen. Im Zuge dessen war auch die Frage offen ob Icons Sugimoris usw. Damals hatten wir uns für Icons entschieden, einfach weil die in jedem Spiel immer aktualisiert wurden bzw. es im großen und ganzen kaum Änderungen gab. Seit dem die Spiele auf der Switch erscheinen werden nun keine vollständigen Pokémon Icons mehr implementiert sondern nur die fürs jeweilige Spiel. Mit SDLP fing es auch bei Items an und wird bei PLA ebenfalls so sein. Inzwischen kann man auch von keinen Icons mehr sprechen sondern eher kleinen Sprites. Was passiert wenn man diese Arg verkleinert um sie fürs Wiki passend darzustellen kann sich jeder denken bzw. gibt es im Testwiki auch ein PLA-Bsp.. Die Nächste Problematik ist z.b. Fukano und die Zorua-Reihe in Ihren Hisui-Formen denn die Regulärenen Formen sind nicht im Spiel enthalten. Wird auf alle Fälle für die Evo-Vorlage lustig werden wenn z.b. die Icons Aktualisiert werden wir sehen dann die neuen Icons und die alten oder sogar für Pichu, Pikachu und Raichu die neuen und Alola-Raichu halt ein altes Icon. Da fängt es schonmal an auch wird sich derartiger Mischmasch für andere Vorlagen und Artikel ergeben. z.b. TCG. Die Frage ist wie wollen wir das ganze auf unser System umwälzen? z.b. Benutzen andere Wikis keine IC Icons sondern lediglich Kürzel und Farben da könnte man ansetzen und dies ebenfalls erwägen nur für Items und Pokémon habe ich keine generelle Lösung. Bei Orten könnte man es durch Spielbezogene Icons lösen wo es dann über den gesamten Abschnitt einheitlich wäre aber für andere Artikel wüsste ich keine generelle Lösung außer wir basteln uns von jedem Pokémon unsere eigene Iconform? Wie sieht es mit anderen Meinungen oder Ideen zu dem Thema aus? Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 17:20, 21. Jan. 2022 (CET)

Ich kann bereits bestätigen, dass das bei den Items der Fall ist und auch bei den Pokémon. Das Hauptproblem ist hier auch, dass, wie bereits von dir erwähnt, die Bilder immer größer werden und kaum noch von Icons die Rede sein kann. Die Item-Bilder sind 128x128 Pixel, wenn man das auf eine Größe skaliert, wo es neben Text gut aussieht, ist da im Grunde nichts mehr drauf zu erkennen. Von demher werde ich diese Bilder auch nicht mehr als Item-Icons behandeln. Ich beabsichtige mit dem Erscheinen von PLA die Icons aus der Item-Liste zu entfernen, weil es einfach keine einheitlichen Designs mehr gibt. Und ich plane inzwischen auch, die Itemicons aus der Infobox zu entfernen und in den Galerie-Abschnitt zu verschieben, weil es inzwischen auch zu viele Items gibt, die mehr als ein Icon haben und das eine weitere Erklärung nötig hat und gleichzeitig auch einfach zu voll aussieht.

Insgesamt behaupte ich einfach mal, dass es wahrscheinlich eine Überlegung wert ist, sich an einigen Stellen von Sprites zu verabschieden. Generell geht der Trend im Netz ja ohnehin dazu, Seiten mit weniger Bildern zuzukleistern und etwas einfacherere Designs zu wählen. Von demher könnte man dem Gedanken folgen und einfach Icons entfernen, wo sie nicht zwingend nötig sind. Dadurch hätte man eben das vorliegende Problem nicht. Denn ich denke da groß zu mischen wird einfach nur unschön. -- RobbiRobb 23:51, 21. Jan. 2022 (CET)

Abstimmung beendet: Ergebnis → D: Eigene dauerhafte Icons

Abstimmung: Typ-Icons

Frage dieser Abstimmung ist: Wie wollen wir zukünftig verfahren? Jeder stimmberechtigte Benutzer darf eine Stimme abgeben. Die Abstimmung läuft bis zum 30. April 2022 um 23:00. Heute ist der 16.04.2024 09:13 Uhr.

Hintergrund: Wie man Beispielsweise hier sieht so werden die Typ-spezifischen Icons seit Jahren Größer und Größer vor allem in der Breite.

Folglich können diese Icons nicht ohne weiteres genutzt werden ohne das es bei diversen Vorlagen zu Darstellungsproblemen kommt. Peter hat einmal einen Möglichen Zuschnitt/abgewandelte Form zur Verfügung gestellt. In wie weit diese Icons verwendet werden können oder zu Darstellungsproblemen bei der Breite führen ist nicht sagbar. GGf. müssten solche Icons noch weiter verkleindert werden. Es sei erwähnt das es hierzu bereits schon einmal eine Abstimmung gab wo sich vorläufig Fix für Boden entschieden wurde da es von der Größe her am Praktikabelsten war. Während des Chattreffen vom 06.04.2022 hat Danee zwei Vorschläge in den Raum geworfen Klassisch nur der Name oder mit passendem Symbol. Die Vorschläge von Danee und Peter dienen rein der Visualisierung wie ein mögliches eigenes oder zugeschnittenes bzw. abgewandeltes Original-Icon aussehen könnte und sind keine Finalen Vorschläge. Desweiteren steht die Option im Raum es wie die SK mit einer fixen Breite zu machen z.B. SWSH. Wird sich in der Abstimmung Option D entschieden erfolgt nachträglich eine Brainstormphase. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)

Option A: Weiterhin Original-Icons aus Gen 7

1. Ich hadere zwischen A und D, aber tendiere eher zu A. BeyJim ^Diskussion 18:12, 10. Apr. 2022 (CEST)
2. Die Icons aus Generation 7 finde ich sehr passend zum PokéWiki-Design. Ich glaube nicht, dass man so gute Icons machen kann, dass sie die Entfernung von den offiziellen rechtfertigen, auch wenn die momentan verwendeten Icons nicht aktuell sind. Mit eigenen inoffiziellen Icons hab ich auch kein großes Problem, finde aber die Symbole nicht notwendig. --Poffel — Diskussion 20:19, 10. Apr. 2022 (CEST)
3. Entweder das oder D, bevorzuge aber diese Lösung ein bisschen mehr BlauesSerpiroyal ^Diskussion 23:26, 15. Apr. 2022 (CEST)
4. AAWiki ^Diskussion 21:09, 30. Apr. 2022 (CEST)

Option B: Aktuelle Original-Icons Verwenden

1. Sieht immer am besten aus und hat für mich den Sinn eines Wikis erfüllt. Die Arbeit sollte man in Kauf nehmen. -- MfG, SwowoJonny 12:46, 11. Apr. 2022 (CEST)
2. --Mario-WL (Diskussion) 20:07, 11. Apr. 2022 (CEST)

Option C: Zugeschnittes/Abgewandeltes Original-Icon

1. Sofern es dann eine Version der aktuellen Variante ist, auch in der Gefahr, dass die Diskussion in zwei Jahren wieder aufplöppt. Finde ja, dass alle Ideen ihren Charme haben. Außer A. Das schaut für mich dann einfach irgendwann veraltet aus. Man sollte schon mit der Zeit gehen. (Und die PLA Icons sehen schon nice aus *hust*) --Klein, aber fein. Killuu 22:37, 11. Apr. 2022 (CET)
2. Ich finde auch, man sollte mit der Zeit gehen und möglichst nah am Original bleiben. Das Isso 08/15 ^Konter 11:12, 14. Apr. 2022 (CEST)
3. MfG Goloer444 11:02, 15. Apr. 2022 (CEST)

Option D: Eigene dauerhafte Icons

1. Mich hat bereits während des Chattreffens die Klassische Namens-Version von Danee überzeugt. Sie ist einfach Zeitlos. Ich finde allerdings die Farben wirken eher suboptimal und sollten mehr an den im Wiki verwendeten Farben angelegt werden. Wie man in der Generationsübersicht der Artikel sieht gab es schon Änderungen bei den Symbolen daher wären solche Icons für mich keine rechte Option. Ob man diesen Klassischen Vorschlag nun mit Daten oder sk umsetzt ist mir da egal * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)
2. Keine Überraschung wie ich hier abstimmen werde. (Feedback wird gerne angenommen) —DaneeBound 17:02, 10. Apr. 2022 (CEST)
3. Wie das genau umgesetzt wird kann man ja noch diskutieren, grundsätzlich sehe ich eigene Icons aber auch als den richtigen Weg an. Dadurch haben wir eine Einheitlichkeit und müssen auch nicht jedes Mal wenn offizielle Icons geändert werden überlegen, wie man dann damit umgeht. Man könnte natürlich auch bei den Icons aus Gen 7 bleiben solange kein neuer Typ eingeführt wird, allerdings sehe ich bei eigenen Icons auch den Vorteil, sie möglichst gut nach unseren Anforderungen zu richten und nicht mit was vorgegebenem arbeiten zu müssen. Insofern bin ich für eigene dauerhafte Icons, da die im Zweifel auch zukunftssicherer sind. Ratequaza 18:48, 10. Apr. 2022 (CEST)
4. Dann haben wir weder Probleme mit Icons, die veraltet sind, noch mit solchen, die halb schwarz sind (SWSH/PLA). --Mecanno-man^Mäh 19:05, 10. Apr. 2022 (CEST)
5. Die einfachste und trotzdem hübsche Option -- Cliffichen 19:07, 10. Apr. 2022 (CEST)
6. Stimme hier auch für die eigenen Icons, da diese halt zeitlos und einfach erweiterbar sind. Vaulty 19:27, 10. Apr. 2022 (CEST)
7. Ich stimme den anderen ebenfalls zu. Panflami ^Diskussion 09:40, 11. Apr. 2022 (CEST)
8. Erinnert mich an die schönen, historischen Icons, und ist gleichzeitig hinreichend zeitlos und platzsparend. Maxmiran 14:17, 11. Apr. 2022 (CEST)
9. Dito Kernseife ^Diskussion 15:06, 11. Apr. 2022 (CEST)
10. Erscheint mir einfach für die Zukunft. Kommt ein neuer Typ, wird einfach ein neues Icon erstellt. -- ~~ feblue 23:50, 11. Apr. 2022 (CEST)
11. - - "I'm gonna swing from the chandelier" GoPika ^Disku 16:48, 12. Apr. 2022 (CEST)
12. Ich bin dafür, Icons im sk-Stil zu erstellen. Was Offizielles zu nehmen wäre normalerweise schöner, aber wenn die neuesten Icons ungeeignet sind (z. B. weil sie zu groß sind) dann sind sie halt ungeeignet; im Endeffekt sind wir ja nicht gezwungen, was Offizielles zu nehmen. – Vircaprae 22:55, 12. Apr. 2022 (CEST)
13. Eigene, zeitlose, farbige Schrift-Icons wären am besten, denke ich. Gerade weil die offiziellen Icons immer öfter schwierig für uns verwendbar werden. -MfG, Kenaz-Hagalaz ^Disku 14:06, 13. Apr. 2022 (CEST)
14. Ich stimme den anderen auch zu. Zukunftssicher, zeitlos, und im Falle des Falles auch updatebar. Meiner Meinung nach besser als jedes Mal die Icons zu erneuern oder bei einem veralteten Design zu bleiben. Arkany 23:43, 14. Apr. 2022 (CEST)
15. Ist denke ich auf lange Sicht, die einzige Option. Mit eigenen Icons könnten wir das Design auch gleich passend für den aktuellen Minimalistik-Trend im Internet machen, was denke ich mit dem mobilen Skin auch für uns so langsam relevant wird. Aber das ist nur ein Nebending. Am stärksten wirkt hier imo., dass wir nicht alle paar Monate das gleiche Problem haben.--DeXter 23:59, 14. Apr. 2022 (CEST)
16. Mir gefallen zwar auch die gut ins Wiki passenden offiziellen Typ-Icons aus der 7. Generation, aber auf lange Sicht sollten wir meiner Meinung nach auf eigene Icons umsteigen. Einerseits, weil die Icons aus der 7. Generation irgendwann zu stark veraltet aussehen werden, und andererseits, weil sich dadurch die Chance bietet, mit der bei den Spielekürzeln verwendeten Technik die Darstellung in verschiedenen Auflösungen deutlich zu verbessern. Die aktuellen offiziellen Icons haben abgesehen von den in vielen Spielen zu dunklen Farben und der zu hohen Breite meiner Meinung nach das Problem, dass die darin enthaltenen Symbole an vielen Stellen im PokéWiki stören würden. Und wenn man dieses Symbol mit einer Abwandlung entfernen würde, wäre der Unterschied zum Original-Icon zu groß, um in Bezug darauf, offiziell zu sein, einen großen Vorteil gegenüber eigenen Icons zu haben. --Lasagne (Diskussion) 10:57, 15. Apr. 2022 (CEST)
17. Ich hoffe, dass sich GF/werauchimmer mal irgendwann auf etwas festlegt. Bis dahin wahrscheinlich am besten das hier. Nescientist (Diskussion) 16:10, 16. Apr. 2022 (CEST)
18. Ich denke, es wird auf dauer die beste Lösung sein Ich kam, sah und bearbeitete Bennett ^Diskussion 18:03, 16. Apr. 2022 (CEST)
19. Ich denke, dass das hier die zukunftssicherste Version ist. Wir können nicht auf ewig darauf vertrauen, dass Gamefreak uns da wirklich nutzbare Icons aufm Silbertablett serviert. Mit dieser Varinate können wir die Icons weitaus einfacher auf unsere Bedürfnisse anpassen. Wenn es um Bilder vs CSS in Richtung der SKs geht, würde ich mich für zweiteres entscheiden, da CSS in der Theorie von allen angepasst werden kann. Bei Bildern ist das nicht zwingend so, da nicht jeder sich super gut mit Bildbearbeitung auskennt. GrollenKette951 23:36, 16. Apr. 2022 (CEST)
20. ~~ DieTaube 18:19, 17. Apr. 2022 (CEST)
21. -- Mooni000 ^{Pelipper-Post} 23:52, 29. Apr. 2022 (CEST)
22. Ich mag Danees Version am meisten, da sie zeitlos sind und ne gute Qualitätet haben. Schlicht und erfüllen ihre Aufgabe wunderbar. --Jass 11:15, 30. Apr. 2022 (CEST)
23. Da dies ein Wiki ist (und mir einige der neuen Icons gefallen), wäre ich normalerweise für die offiziellen Icons. Da es aber viele Probleme damit gibt und ich mir nicht sicher bin, ob etwas Zugeschnittenes oder Skaliertes gut aussehen würde (wohl eher weniger), wären eigene Icons wohl das Beste. Wie das dann umgesetzt wird, ist mir erstmal egal, nur kann ich bei HTML oder CSS nicht mitreden, auch wenn das wohl die bessere Variante ist, wenn man das dann einfacher anpassen kann. Vor allem wird aber auch niemand 900-1500x die Darstellung prüfen wollen, schon gar nicht bei jedem Release.
    DeepSpace (Diskussion) 20:56, 30. Apr. 2022 (CEST)

Enthaltung

1. Mit freundlichen Grüßen Lunairline^{Buchung zum Mond} 15:58, 11. Apr. 2022 (CEST)
2. Ich muss mich an dieser Stelle leider enthalten, aber nicht, weil mir das Thema egal ist, sondern weil ich einfach mit keiner der Lösungen wirklich zufrieden bin. Einerseits bin ich seit jeher ein großer Fan der (noch) aktuellen Typ-Icons, muss allerdings zugeben, dass sie langsam etwas in die Jahre kommen und spätestens wenn ein neuer Typ hinzukommt sowieso alle Hoffnung verloren ist. Dann müsste man entweder was eigenes dazu machen, was mir persönlich gar nicht gefallen würde, oder dann spontan auf die neuen wechseln, was möglicherweise an vielen Stellen im Wiki Probleme bereiten würde. Eine Lösung, die also bereits im Vorfeld darauf vorbereitet ist, wäre daher logischerweise wünschenswert. Die Verwendung der jeweils aktuellen Icons wäre zumindest für das nicht-Vorhandensein eine Lösung, allerdings ändern die ja jedes mal Größe und Design vollständig, was bedeutet, dass wir immer wieder prüfen müssen, ob hunderte oder tausende Seiten noch gut aussehen. Besonders, da zuletzt die Icons eher mäßig gut aussehen in Verbindung mit Text, besonders auch in Tabellen, wo die Icons einfach höher waren als Text in der selben Zeile, klingt das für mich nicht nach einer vernünftigen Lösung. Das ganze abzuwandeln kommt meiner Meinung nach dem Erstellen eigener Icons gleich, wenn man sich halt auch einfach nur etwas mehr bei den Spielen bedient. Und der Gedanke, etwas völlig eigenes zu machen, will mir hier halt einfach nicht gefallen, weil zumindest ich Wert darauf lege, dass Sachen aus den Spielen auch genau so aussehen. Hier dann jetzt eine völlig eigene Linie zu fahren will mir aktuell einfach nicht so recht gefallen. Da es aber klar darauf hinaus zu laufen scheint, möchte ich mich stark dafür aussprechen, dass wir etwas designen, was sich rein mit HTML und CSS einbauen lässt anstatt wie bisher Bilder. Hat den enormen vorteil, dass es in der Datenübertragung weniger aufwendig ist und erlaubt leichtere Änderungen in der Zukunft. -- RobbiRobb 23:52, 18. Apr. 2022 (CEST)
3. Super schwer. Es wird zwar auf Option D hinauslaufen, aber ich kann mich hier nicht festlegen. Einerseits sehe ich die Option B als richtig, da wir uns in einem Wiki befinden und entsprechend das aktuellste und vollständigste Nutzenb sollten, andererseits sind aber die Icons aus Gen 7, also Option A, die aktuell brauchbarsten. Option D finde ich leider nicht gut, da wir nicht einfach was eigenes erstellen sollten, das verfälscht einfach das Bild, was ein Wiki eben auch ist: originalgetreue Dokumentation zu den Spielen, etc. (und keine Fanarts ), auch wenn sie schön aussehen sollten. Das halte ich dennoch für falsch. GrüßeShortyBuzz 21:25, 30. Apr. 2022 (CEST)

Kommentare

Um mal ein Gefühl zu bekommen wenn wir jedes mal, wenn ein neues Icon kommt dies im Wiki anpassen würden. Laut Liste (dank Robbi) mit Stand heute müssten 837 Artikel (manuelle Einbindung) nachgeprüft werden, sowie 66 Vorlagen. Also Grob 900× müsste die Darstellung jedes mal kontrolliert werden. Andere Namensräume wie Benutzer, PokéWiki und Kategorie habe ich da einfach einmal Ignoriert. Würde man die dazu Zählen dann müssten immer ~1500 Seiten auf Darstellung geprüft werden. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:54, 11. Apr. 2022 (CEST)

Peters Bild kann ich nicht anschauen, da ist irgendwas am Imgur-Link kaputt. --Klein, aber fein. Killuu 21:27, 11. Apr. 2022 (CET)

Sollte eigentlich funktionieren. Ich hab den Link jetzt mal gegen den "richtigeren" Link ausgetauscht. Eigentlich sollen die Bilder nur zeigen was möglich ist und nicht als formaler Designvorschlag dienen. GrollenKette951 22:27, 11. Apr. 2022 (CEST)

Zumindest die Varianten ohne Icons sollten sích sogar über CSS realisieren lassen, was für mich aus einer Effizienzperspektive einen geringen, aber gewissen Reiz hat. -- Skelabra2509 (Diskussion | Beiträge) 14:26, 12. Apr. 2022 (CEST)

Ping

Hier der obligatorische Ping an die Abstimmungsberechtigten: @AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, DarkOkto, Der Sternendiamantritter, Ediz, Goloer444, Jardan, Jass, Kernseife, Killuu, Lasagne, DasLunalein, Mario-WL, Nescientist, Panflami, PokéSpe, ScNoni, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Vircaprae * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)

Ideensammlung, Kommentare und Vorplanung des Mini-VC

Da sich dessen bisher keiner angenommen hat und damit das hier endlich mal weiter geht folgendes. Im Spoiler befinden sich einige Vorschläge und Ideen ich bitte nun jeden der einen Ping erhält sich Gedanken zu machen und seine Vorschläge hier zu hinterlegen. Damit wir da auch zu Potte kommen einfach auch die Frist bis zum 01.09.2022 23:59 Nachdem die Frist rum ist machen wir einen kurzen VC, den Link habe ich bereits hier vorbereit. Abstimmfrist ist ebenfalls 01.09.2022 23:59. Dort besprechen wir nochmal ein paar Feinheiten was ggf. Hier und dort noch optimiert werden könnte und entweder legen wir die Icons direkt fest oder machen ne Abstimmung und fertig ist der Lack. Aufgrund der großen Auswirkungen fürs gesamte Wiki hier der Ping an @AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, Der Sternendiamantritter, DomiDsLP, Ediz, Goloer444, Jardan, Jass, Kernseife, Lasagne, DasLunalein, Mario-WL, Nescientist, Panflami, PokéSpe, ScNoni, Taisuke, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Vircaprae. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:59, 11. Aug. 2022 (CEST)

Nun ich hatte tatsächlich bereits heute Nachmittag nach der Frage von Jass nen kleinen Versuch an Icons per CSS im Testwiki gestartet. Dieser kann hier gefunden werden. Ich habe mich bewusst für eine CSS-Variante entschieden, da diese im Vergleich zu Bildbearbeitung einfacher für alle User zu bearbeiten sein sollte. Farben habe ich von SWSH und SDLP genommen. Manche sehen von SWSH besser aus, andere von SDLP. PLA habe ich bewusst nicht genommen, da diese farbstilistisch zu abweichend sind. Die Höhe der Icons ist im Vergleich zu den aus SoMo gleich geblieben. Nur die Breite hat ein kleines bisschen zugenommen, aber auch nicht extrem, daher sollten diese wenige Probleme verursachen. GrollenKette951 19:09, 11. Aug. 2022 (CEST)

Daran anknüpfend: Zum einen: Die Farben gefallen mir persönlich von SDLP besser, wie sieht das der Rest? Zum anderen denke ich, dass man evtl. noch eine andere Schriftart nehmen könnte, ich habe mal als Beispiel hier das Ganze mit Arial Black gemacht. Ratequaza 10:31, 12. Aug. 2022 (CEST)

Farblich gefällt mir weder SWSH noch SDLP zu 100%. Wasser, Feuer, Pflanze sieht z.B. bei SDLP besser aus, während Boden, Kampf, Eis bei SWSH besser aussehen. Stahl ist bei beiden bei mir nicht so passend. Ansonsten zu dem Versuch von @Ratequaza: Der Font würde dafür sorgen, dass die Icons noch mal 10 zusätzliche Pixel in die Breite brauchen. (Gen7-Icon: 48px; Meine Variante: 55px; Rati: ~68px damit es passt) Zudem funktioniert der Font auf Chrome (Mobil) bei mir nicht sondern defaultet auf den Wiki-Font. GrollenKette951 11:21, 12. Aug. 2022 (CEST)

Stimmt, auf mobile funktioniert bei mir auch weder die andere Schriftart, noch das Anpassen der Schriftdicke (was ich gerade noch probiert habe). Aber wenn das ohnehin aufgrund der Breite ein Problem darstellt, dann braucht man das natürlich sowieso nicht weiter zu verfolgen. Ratequaza 11:42, 12. Aug. 2022 (CEST)

Die neuen minimalistischen 'Icons' gefallen mir sehr gut. Die könnten denke ich auch besser in Text passen als die Icons, die wirklich Bilder sind. Also die bereits vor einiger Zeit vorgestellten Icons sehen echt super aus, keine Frage. Neben alleinstehender Optik und Zeitlosigkeit, fände ich bei neuen Icons aber auch eine im Vergleich zu früher bessere Kompatibilität mit Text sehr gut.--DeXter 19:33, 12. Aug. 2022 (CEST)

Ich denke in Text werden auch die neuen fehl am Platz sein, egal wie sie zum schluss aussehen. Was die Icons angeht: Ist denn angedacht, die Farben der Icons immer mal wieder zu erneuern, wenn wir hier bestimmte Spiele-Farben der aktuellen Spiele wollen? Ansonsten finde ich sähe der Text in nicht fett besser aus. --Mecanno-man^Mäh 12:24, 13. Aug. 2022 (CEST)

Mir gefällt das Design von GrollenKette sehr gut. Da finde ich seine Version auch besser als das von Rati, da sie sowieso optisch für mich ansprechender aussieht. Auch fände ich eine solche stilistisch minimalistische Variante besser als die traditionelle Variante, die vorher vorgeschlagen wurde und als eine Version mit kleinen Icons daneben, da diese mMn auf so einer Größe sowieso keine Rolle mehr spielen und nicht wirklich viel dazu beitragen würde, außer die Icons breiter zu machen.

Bezüglich der Farbe würde ich sagen wir setzen uns im VC zusammen und schauen individuell für jeden Typen nach einem (eigenen) Farbton, der den meisten am ehesten gefällt. Wenn wir jetzt nämlich anfangen Spielefarben von SwSh oder SDLP zu nehmen, dann werden definitiv in Zukunft Spiele erscheinen, die andere Farbtöne nutzen die manche User dann wieder besser finden.

Bezüglich Varianten, die im Text ebenfalls nutzbar sind, bin ich unentschlossen. Persönlich finde ich, dass farbige Dinge generell den Textfluss stören, daher bin ich eher dagegen so eine Option zu finden. Wenn jemand eine findet und diese doch überraschenderweise in Ordnung im Text lesbar ist, dann bin ich auf keinen Fall dagegen meine Meinung zu ändern, aber ich denke einfach nicht, dass sich da was finden ließe, das besagte Probleme für mich löst. ~~ DieTaube 13:29, 13. Aug. 2022 (CEST)

Die CSS-Variante gefällt mir schonmal sehr, aber warum benutzen wir nicht einfach die Typfarben aus unserer Typ/Color-Vorlage? Die Farben sind seit Jahren bewährt und werden in (zehn-?)tausenden Artikeln für die Einfärbung unserer Vorlagen benutzt, warum nicht auch hier? Dann sparen wir uns das Erneuern, wenn irgendwem irgendeine Typfarbe besser gefällt als die Vorherige. Ein farbliches Beispiel für jede Variante der Typ/Color-Vorlage habe ich auf einer Unterseite im Testwiki hinterlegt. Davon würde mir persönlich jetzt schonmal dunkel am besten gefallen. -- ~~ feblue 14:08, 13. Aug. 2022 (CEST)

Wenn wir die Typen-Farben nutzen werden wir schauen müssen dass das dann nirgendwo fliessende Übergänge mit was anderem verursacht; oder wir geben ihnen einfach ein margin/padding. Bei letzterem denke ich könnte es dann aber auch Vorlagen unschön aussehen lassen --Mecanno-man^Mäh 15:02, 13. Aug. 2022 (CEST)

Ohne Symbol finde ich schon mal deutlich besser geeignet. Diese hier sehen finde ich am hübschestens aus. Ich denke, es ist auch nicht schlimm, wenn die Icons Dateien bleiben, sind sie ja bisher auch. Nur auf weißem Hintergrund sehen de Icons vermutlich nicht so hübsch aus und ich weiß nicht wie groß sie generell sind, darum doch zurück zur css-Variante.... da finde ich dunkel oder SDLP am besten. Mit Hinblick auf die Zukunft aber eher dunkel, denn warum sollten wir in Gen 9 noch die Farben von SDLP nehmen? Und wieder anpassen, warum gab es denn diese Diskussion... auch wenn nur die Farbe zu ändern nicht so schwierig ist wie direkt das ganze Icon mit Breite etc. -- Cliffichen 16:43, 13. Aug. 2022 (CEST)

Die Idee, einfach direkt mit den Typenfarben zu arbeiten, hatte ich auch, aber leider wird es im gesamten Wiki sicherlich einige Stellen wie Pokémon XD: Der Dunkle Sturm geben, wo dunkel genutzt wird und da sieht das mit dem Icon nicht so gut aus. Und ne border außendrum sah bei dem was ich zu Anfang mit meinem Test probiert habe nicht wirklich gut aus. Dann müssen wir im VC halt mal schauen wie wir die Farben kombinieren. Bezüglich fett vs nicht fett: mMn sieht der Text ohne das fettmachen ein bisschen verloren aus. GrollenKette951 17:13, 13. Aug. 2022 (CEST)

🤔 an und für sich schwer zwischen CSS und Bildern, es hat beides seine Vorzüge. Tendenziell würde ich zu Danee wählen. Ich würde allerdings gerne im gleichen Atemzug Wettbewerb (Coolness etc.), Statusveränderungen (Paralyse etc.) sowie Kategorie (Status etc.) mit überlegen diese ebenfalls im selbigen Design zu machen so das wir ein solides Gesamtbild für diese Iconart haben. Wäre daher cool wenn Peter und Danee ihre Versionen noch um diese erweitern. Ob man dies schlussendlich so macht oder bei diversen beim bisherigen bleibt lässt sich ja im VC klären. hat sonst noch wer Vorschläge? * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:19, 13. Aug. 2022 (CEST)

So ich habe meine Seite mal noch um die gewünschten Sachen ergänzt. Farben sind direkt aus den vorhandenen Icons (Kategorie, Wettbewerb und ???) oder den SWSH-Icons (Statusveränderungen) gezogen. Bei den Wettbewerben würde es wieder ne Kollision mit den Attackenartikeln geben, wenn ich die vorhandene Vorlage nutzen würde. Zumindest bei den Statusveränderungen wüsste ich jetzt nicht, ob wir die überhaupt im Parser haben und die auch irgendwo aktiv nutzen. Bei den anderen weiß ich wo. Keine Ahnung, ob wir demnach da überhaupt was brauchen. Ansonsten sind die Farben erstmal nur zum Arbeiten, da können wir (Mec nicht) ja im VC drüber reden. GrollenKette951 10:55, 17. Aug. 2022 (CEST)

Ich habe mich auch mal an eigene CSS-Typ-Icons gewagt, die an die bisherigen Icons aus Generation 7 angelehnt sind. Sie sind mitsamt Vergleichen zu den Icons aus Generation 7 und denen von GrollenKette951 auf dieser Seite im Test-Wiki zu finden. Da meine Icons denen aus Generation 7 größentechnisch sehr nahe kommen, sollten sie sich mit weniger Problemen diesbezüglich ins PokéWiki einbinden lassen.
Ich kann bei meinen Icons gerne noch Änderungsvorschläge einarbeiten und ich bin auch gerne bereit, einen ganz anderen Entwurf für Typ-Icons zu unterstützen. Mit den von GrollenKette951 vorgestellten Icons kann ich mich aber noch nicht so recht anfreunden, da sie mir etwas zu simpel sind. Meiner Meinung nach sollten die Typ-Icons durch ein etwas komplexeres Design das Interesse der Leser wecken, genau wie es die Spiele-Icons bereits tun (z. B. USUMSDLPKAPU).
Was die anderen Icons zu Statusveränderungen, Attacken-Kategorien, Wettbewerbs-Kategorien, etc. betrifft, denke ich, dass sie sich optisch durch verschiedene Stile klar voneinander unterscheiden lassen müssen, z. B. durch eckige statt abgerundete Hintergründe, evtl. durch Verwendung von Symbolen bei Attacken-Kategorien... Jedenfalls sollten nicht alle Icons wie Typ-Icons mit anderer Größe aussehen. --Lasagne (Diskussion) 23:09, 18. Aug. 2022 (CEST)

Ich finde es gut, gleich alle Icons anzupassen. Nur wenn ich mir das bei GrollenKette anschaue, wirken einige "Icons" doch sehr ungewohnt. Die Statusveränderungen ohne Symbol beispielsweise. Daran könnte man sich mit der Zeit wohl noch gewöhnen, weil da bisher meistens auch Schrift im Icon war (neben dem Symbol). Phyisisch, Spezial und Status sind aber super seltsam so zu sehen. Das waren bisher immer nur Symbole, auch in den Spielen. Bulba nutzt auch Schrift, sieht finde ich aber auch blöd aus, ich war immer froh über unsere Symbole. Könnte man nicht bei den dreien statt Schriftzug die Symbole aus SWSH oder PLA von hier nehmen? Bei den Statusveränderungen hätte ich auch nichts gegen ein kleines Symbol neben der Schrift. Das würde auch ein wenig Abwechslung bringen, die Lasagne beschrieben hat. Ich denke auch, alle Icons genau gleich zu haben könnte verwirrend sein. Von der Form her sollten sie aber schon gleich sein, damit sie überall gut rein passen. Btw, ich habe deine Entwürfe gesehen Lasagne, aber da fehlt noch ein bisschen was, damit das tauglich ist (kein Zeilenumbruch, Farbe bis zum schwarzen Rand, padding).^^ -- Cliffichen 09:41, 19. Aug. 2022 (CEST)

Ich könnte bei Physisch und co mal bisschen rumprobieren. Bezüglich den Statusveränderungen kann ich meine Frage nur wiederholen: Brauchen wir die wirklich? Benutzen wir die überhaupt irgendwo im Wiki über den Parser oder haben wir halt seit SWSH die paar Dateien dafür und das wars? Ich wüsste jetzt nicht wo und wie wir die benutzen sollten. Zu Lasagnes Variante: Ich vermute mal, dass die Icons rein für den alten (noch aktuellen) Skin gebaut sind und noch nicht für den neuen. Der neue hat ne andere Schriftgröße. Ansonsten zeigt sich da genau das was ich vor paar Nachrichten meinte, dass Ränder nicht wirklich gut aussehen so lange du nicht sonst wie weit rein zoomst. Ich hatte da ja auch in diese Richtung probiert, um das ganze zu verwerfen und diese minimalistsicher Icons gebaut. GrollenKette951 10:00, 19. Aug. 2022 (CEST)

Muss hier GrollenKette zustimmen - die Ränder in Lasagnes Design wirken bei mir erst ab 150% Zoom sauber. Ich denke generell sprocht auch nichts prinzipiell gegen (technischen) minimalismus; auch die Icons von GrollenKette erzeugen meines Erachtens so genug Aufmerksamkeit. --Mecanno-man^Mäh 12:21, 20. Aug. 2022 (CEST)

Ich habe jetzt die Schriftgröße bei meinem Entwurf etwas angepasst, sodass es in der Beta-Test-Benutzeroberfläche keine Zeilenumbrüche mehr gibt. Dafür ist die Schrift im normalen PokéWiki-Skin jetzt etwas größer, als ich sie gerne hätte.
Mir ist übrigens aufgefallen, dass es mit meiner bisherigen Variante zwar Zeilenumbrüche in Chrome für PC gab, aber in Chrome für Android alles noch gepasst hat. Dass es da solche Unterschiede gibt, macht das Erstellen und Anpassen von solchen CSS-Vorlagen meiner Meinung nach sehr schwierig, weil man potenziell für aktuell 5 mögliche Benutzeroberflächen mal mindestens 2 Browser optimieren muss. Gibt es da mit CSS eine einfache Möglichkeit, für ein einheitliches Aussehen zu sorgen?
Was die Ränder angeht, habe ich jetzt die Farbe von schwarz zu dunkelgrau geändert, was für weichere Kanten sorgt. Hier würde ich gerne von GrollenKette951 und Mecanno-Man wissen, ob die Unsauberkeiten, die ihr bei den Rändern bisher gesehen habt, damit verschwunden sind. Wenn nicht, stellt sich für mich aber die Frage, wo der Unterschied zu anderen Stellen im PokéWiki mit abgerundeten Rändern liegt. Wenn abgerundete Ränder allgemein problematisch sind, müssten z. B. auch die Spielkürzel und zahlreiche Tabellenvorlagen hier im PokéWiki angepasst werden. --Lasagne (Diskussion) 14:19, 20. Aug. 2022 (CEST)

@Cliffichen: Die nicht ganz bis zum Rand gehende Farbe ist Absicht. In Anlehnung an die Icons aus Gen. 7 haben meine Icons einen Innenrand, der heller als das Innere gefärbt ist. Und hat sich das Problem, was du mit dem Padding gesehen hast, zusammen mit der veränderten Schriftgröße gelöst? --Lasagne (Diskussion) 14:46, 20. Aug. 2022 (CEST)

Hallo ihr Lieben! Freue mich sehr, dass ihr die Diskussion so öffentlich auf der allgemeinen Diskussionsseite statt irgendwo intern führt. Wärt ihr dann aber vielleicht noch so gut, die Vorschläge irgendwo hochzuladen/zu zeigen, wo jeder Leser der AD diese auch einsehen kann? Nicht-SBs haben nämlich keinen Zugriff aufs Testwiki und sehen daher nur eine Diskussion über Dinge, die sie gar nicht beurteilen können. Danke euch!--✦✧  Pk-fan ✧✦ 19:53, 22. Aug. 2022 (CEST)

@Pk: Dann hier einmal der ganze Spaß als Screenshots (GrollenKette951, Feblue, Lasagne). Dabei auch noch der Ping an Lasagne: Die inneren Ränder deiner Icons sehen zumindest für mich recht ungleichmäßig aus. Bei Normal z. B. sieht der Rand oben und unten größer aus als in der Abrundung. Woran das genau liegt weiß ich nicht, aber es sieht bei 100% Zoom eher mäßig aus. Sobald man bei mir auf 200% geht sieht es cleaner aus. GrollenKette951 20:26, 22. Aug. 2022 (CEST)

@GrollenKette951: Das liegt daran, dass an den Stellen, wo der Rand senkrecht oder waagerecht verläuft, genau eine Pixelreihe oder -Spalte für diesen Rand verwendet wird. An den abgerundeten Stellen wird der Rand dann nicht als "Treppe" dargestellt, sondern die Kanten werden geglättet, was den Rand zumindest bei einigen Farben dünner wirken lässt. Die 200 % sind dann bei dir vermutlich der Punkt, an dem auf 2 Pixel breite Ränder umgestiegen wird und dieses Problem kaum noch auftritt. Ich werde demnächst vermutlich noch einen Entwurf ohne und/oder mit weniger stark abgerundeten Ecken ergänzen, wo das nicht mehr bzw. weniger stark auftritt.
Ich möchte aber in der Diskussion um die Darstellung auf verschiedenen Zoomstufen darauf hinweisen, dass es viele Geräte mit hoher Pixeldichte wie z. B. Smartphones gibt. Auf solchen Geräten spielen diese von einigen als unsauber empfundenen Details vor allem in Kombination mit der neuen Benutzeroberfläche kaum noch eine Rolle. Das heißt natürlich nicht, dass die Darstellung auf Bildschirmen mit Standard-Auflösung egal ist (ist sie mir auch nicht, ich verwende selbst solch einen Bildschirm), aber es ist eben auch die einzige Wahrheit und wahrscheinlich nicht einmal der häufigste Nutzungsfall des PokéWikis. --Lasagne (Diskussion) 22:42, 22. Aug. 2022 (CEST)

Ich habe mich auch mal ein bisschen ausprobiert und möchte eine Version präsentieren:taddaaaaa!
Hatte erst überlegt, dass ich ein Bildchen in Icons wirklich mag, das ließ sich aber recht schwer umsetzen, ohne dass es zu breit wird. Falls es doch jemand hinbekommen sollte, würde ich mich auf jeden Fall freuen. Gerade da die SDLP/PLA-Icons laut eines Screenshots offenbar auch in KP weiterverwendet werden. Hab sogar versucht die Kanji der Typen als zeitloses Symbol einzubauen, nur um festzustellen, dass nicht jeder Typ eins hat. Mein Endergebnis ohne Bilder seht ihr oben, habe mich auch für einen inneren und äußeren Rahmen entschieden, da ich es einfach am schicksten Finde. Die dafür verwendeten Farben sind eine aufgehellte und eine abgedunkelte Version der LA-Icon-Farben. Die hab ich als Hintergrund gewählt, da sie nicht so grell sind wie die Icons nahezu aller anderen Spiele und damit weniger unangenehm ins Auge springen. Für Feedback bin ich gerne offen!--✦✧  Pk-fan ✧✦ 00:51, 23. Aug. 2022 (CEST)

Hey Pk, ich finde deine Icons sehr ansehnlich. Zuerst sahen sie etwas hoch und breit aus, aber sie sind 50px breit (korrigier mich wenn das falsch ist) und die anderen neuen 48px bzw. 55px, also voll in Ordnung. Bei einigen kommt der helle Innenrand auch richtig schön zur Geltung z.B. Käfer und Stahl, bei anderen verschwindet er ein bisschen, vielleicht könnte man das noch anpassen, z. B. Wasser und Fee. Ich habe einmal deinen Quelltext kopiert und ins Testwiki mit dem Beta-Skin gebracht (GrollenKette vielleicht kannst du das zu den Screenshots hinzufügen?), da machen einige Schriftzüge leider ein bisschen was sie wollen. Dafür müsste man wohl noch eine Lösung finden, aber sonst können die gut mit den bisher klassischen von GrollenKette und Danee mithalten, finde ich.^^ -- Cliffichen 08:52, 23. Aug. 2022 (CEST)

Ich finde, die Icons von Pk passen recht gut. Habe sie aber bisher nur mobil angeschaut. --Mecanno-man^Mäh 10:03, 27. Aug. 2022 (CEST)

Ich hab jetzt mal die Screenshots angepasst und Pks Variante einmal im Liveskin und im Mobilskin hinzugefügt. Sie sehen auf jeden Fall nicht schlecht aus, aber zumindest im mobilen Skin, der ja irgendwann unser aktueller wird, hängen die Texte ziemlich weit unten im Icon. Ansonsten bin ich noch nicht dazu gekommen mal bei Physisch und co an Cliffis Vorschlag zu arbeiten. GrollenKette951 12:41, 27. Aug. 2022 (CEST)

Nochmal ein Update des Links mit den Screenshots. Ich habe jetzt mal Cliffis Wunsch umgesetzt und die Schrift bei Status und co. gegen die Icons aus SWSH ausgetauscht. GrollenKette951 16:03, 30. Aug. 2022 (CEST)

Doodle ist beendet. Da Peter am 12. nicht kann fällt es auf den 17.09.2022 ab 18:00 damit es auch jeder auf dem Schirm hat hier noch der abschließende Ping @Pk-fan, AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, Der Sternendiamantritter, DomiDsLP, Eden Ediz, Goloer444, Jardan, Jass, Kernseife, Lasagne, DasLunalein, Mario-WL, Nescientist, Panflami, PokéSpe, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 20:56, 2. Sep. 2022 (CEST)

Ich habe meine Meinung hier noch nicht geäußert, zum einen weil ich abwarten wollte was für Vorschläge alles kommen und zum anderen weil ich vergessen habe was zu schreiben. Deshalb will ich noch kurz meine Meinung dazu festhalten, bevor das VC-Treffen stattfindet. Wie die meisten hier würde auch ich Icons im "sk-Stil" bevorzugen, also als Text mit css drumrum und nicht als Bilddatei. Die Version von Pk-fan gefällt mir dabei optisch am besten. Wegen den Farben würde ich einfach sagen die aus den Typ/Color-Vorlagen, wie feblue schon vorgeschlagen hat. Dann sind die Icons immer einheitlich mit dem Farbdesign in den Artikeln und werden, falls wir die Farben mal ändern, direkt mit angepasst. Bei Pks Vorschlag würden wegen den dunklen Rändern auch keine von Mec befürchteten fließenden Übergänge mit dem Hintergrund auftreten. Falls die neuen Icons doch zu groß für das Wiki sind, würde ich vorschlagen den Text nicht fett zu machen, dann kann man die Icons vermutlich etwas kleiner machen. – Vircaprae 04:17, 17. Sep. 2022 (CEST)

Ich werde heute Abend auch nicht dabei sein. Da ich grundsätzlich eher gerne weiterhin irgendwelche im Spiel benutzten Icons genutzt hätte, aber die Diskussion dazu verpasst habe, lasse ich dennoch meine Meinung zu dem Thema hier. Dank Virca kann ich mich extrem kurz fassen und mich einfach seiner Meinung anschließen.

Habt heute Abend eine entspannte Diskussion dazu und ich bin gespannt, welche Entscheidung dabei getroffen wird. Ich finde es auf jeden Fall gut, dass wir da jetzt vermutlich eine zukunftsfähige Lösung finden werden und nicht immer wieder eine Grundsatzdebatte dazu führen müssen. :) ~ Taisuke ^Diskussion 08:56, 17. Sep. 2022 (CEST)

Im Mini-Chattreffen (Anwesende: Pk, AAWiki, Danee, Jass, Lasagne, Panflami, DeepSpace, Taube, Peter, Mec, Mooni, Poffel, Robbi, Ryu und Simon) wurde die Vorangegangene Diskussion besprochen. Es wurde sich darauf geeinigt das zukünftig keine Bilder mehr verwendet werden sollen sondern CSS-Basierte Icons. Es wurde eine Anpassung für Typ-Icon, Wettbewerbs-Icons und Schadensklasse-Icons besprochen. Für Statusveränderungen wird es keine separaten Icons geben. Alle Icons bekommen einen halbtransparenten 2px Border. Typ und Wettbewerb zeigen ausschließlich Text. Bei Schadensklasse wurde sich für ausschließlich Symbol entschieden. Desweiteren wurde die Farbgebung der neuen Icons festgelegt. Diese orientieren sich an Icons aus Spielen:

• Typ Icon
  • Normal, Kampf, Gestein, Feuer bekommen die Farben aus SM
  • Flug, Elektro, Psycho bekommen die Farben aus SDLP
  • Gift, Boden, Geist, Wasser, Pflanze, Drache, Unlicht bekommen die Farben aus PLA
  • Käfer, Eis bekommen die Farben aus SWSH
  • Stahl bekommt die Farbe aus XY
  • Fee bekommt die Farbe von der Website
  • ??? bekommt die Farbe aus RUSASM
• Wettbewerb
  • Cooln. bekommt die Farbe aus ΩRαS
  • Schönheit, Putzigkeit, Klugheit bekommen die Farben aus HOME
  • Stärke bekommt die Farbe aus RUSASM
• Schadensklasse
  • Spezial, Physisch bekommen die Farben aus XYUSUM
  • Status bekommt die Farbe aus MA

Die Ergebnisse sind hier ersichtlich. Die Umsetzung in den Parser muss nun von Buoysel erfolgen. Bitte um Rückmeldung bis wann du dies circa umgesetzt haben könntest. Ansonsten bliebe noch die Option den Parser wieder durch eine Vorlage zu ersetzen und alles nochmal zu botten . Es wurde auch diskutiert in wie weit man auch die Farben von Typ/Color anpassen sollte um sie den neuen Icons anzunähern. Hier wurde sich dazu entschieden dies über einen separaten Punkt auf der AD zu klären. Sobald dies umgesetzt ist kann dieser Punkt dann endlich auch ins Archiv
Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:05, 17. Sep. 2022 (CEST)

Anmerkung: Mit „Website“ ist diese offizielle japanische Website gemeint, welche nochmals eigene Typ-Icons verwendet. --Mecanno-man^Mäh 10:16, 18. Sep. 2022 (CEST)

Die neuen Icons wurden seitens Buo am 22.09. im LiveWiki umgesetzt. Damit ist die Thematik unserer Lieben Icons Abgeschlossen und Punkt kann ist Archiv. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:19, 22. Sep. 2022 (CEST)

Unsere Lizenzvorlagen

Seid einer Weile schon stören mich unsere Lizenzvorlagen ein wenig. Es gibt da zwei Dinge, die mich stören:

1. interne Links. Es erschliesst sich mir nicht ganz, warum wir auf unsere Firmenartikel verlinken, und nicht auf die Websites der Firmen direkt, die in einem Rechtskontext nahezu sicherlich eher gesucht werden würden.
2. oftmals (insb, bei Vorlage:Bild-copyright-spiel) werden Firmen gelistet, die definitiv kein Urheberrecht an den Spielen haben - schlicht weil wir alle Firmen listen, die irgendwo Urheberrecht an dem entsprechenden Pokémon-Medium haben.

Ersteres liesse sich relativ einfach lösen (und würde den Anfang von Spezial:Gewünschte Seiten aufräumen), zweiteres ist jedoch wahrscheinlich eher aufwändiger zu lösen. Wir haben mittlerweiler über 100000 Spiele-Screenshots im Wiki. Wahrscheinlich liesse sich zwar über die Kategorien irgendwas botten (wobei man dann einfach alles für den default lässt, wo keine Spiele-Kat gesetzt ist) - doch was würden wir mit neuen Uploads machen? Ein Menü zur Auswahl eines Spiels beim Upload würde mir auf den ersten Blick sinnvoll erscheinen, wäre aber etwas zusätzliches was man neuen Benutzern erklären müsste; bin mir dementsprechend nicht sicher wie super das funktionieren würde. Ausserdem weiss ich gar nicht, ob ein zusätzliches Dropdown technisch möglich ist, oder ob wir an die MediaWiki-Felder gebunden sind, die bereits existieren. Zumindest die internen Dateilinks würde ich aber gerne durch externe ersetzt haben. Gibt es andere Meinungen zu diesem Thema, oder bin ich der einzige der sich darüber Gedanken gemacht hat? --Mecanno-man^Mäh 21:47, 23. Jan. 2022 (CET)

Gegen Redlinks entfernen habe ich auf jeden Fall nichts, wobei das vermutlich die wenigsten überraschen wird. Ob wir interne Links nutzen oder externe, ist mir ehrlich gesagt egal, ich kann mir vorstellen, dass es Vorteile hat, da auf die offiziellen Seiten zu verlinken, genau so aber auch Nachteile, eben weil es die offiziellen Seiten sind. Inhaltlich kann ich dazu nicht viel beitragen, wenn da ne Firma drin steht, die definitiv kein Urheberrecht an irgendwelchen Spielen hat, dann gerne raus damit. Funktionsfähige Erweiterung der Lizenz geht nicht ohne einzelne Lizenz-Auswahlen im Dropdown (geht aber möglicherweise, einfach immer auf die selbe Lizenz zu schießen aber mit anderem Parameter, da müsste man mal schauen). Von demher wird das vermutlich schwer zu erreichen. Bin mir daher unsicher, ob das die Lösung dafür ist. -- RobbiRobb 23:53, 26. Jan. 2022 (CET)

Buo hat sich gegen externe Links ausgesprochen. Durch derartige Links könnten Unternehmen sogar erst Aufmerksam auf die Verwendung werden. Man muss hier nicht unnötig schlafende Hunde wecken. Ebenso hält er eine Separate Unterseite die sämtliche Urheberrechtsinhaber listet für Unpraktikabel. Es wurde sich darauf geeinigt die derzeit vorhanden Redlinks durch Text zu ersetzen. Es spricht nichts gegen wenn später ein Link gesetzt wird sobald der Artikel existiert. Die Links wurden inzwischen von Mec und Taube entfernt und der Punkt kann damit ins Archiv. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:20, 10. Apr. 2022 (CEST)

Umbenennung der Artikel DV und AV

Hallo, hier im Wiki nutzen wir derzeit die englischen Begriffe DV und AV. Auf der offizieller Seite werden aber Individuelle Stärken und GO-Kräfte benutzt. Siehe: z.B. hier. Ich würde sie gerne verschieben und die anderen Begriffe als WL lassen. Einwände oder Anregungen? Das Isso 08/15 ^Konter 13:55, 21. Feb. 2022 (CET)

Deutsches Wiki = Deutsche Begriffe. Hat mein Pro * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 14:44, 21. Feb. 2022 (CET)

Die Problematik ist leider etwas grösser: Es sind nämlich nicht nur die zwei von Isso angesprochenen Werte, sondern auch noch „Basiswerte“ und „Artenspezifische Stärken“ nicht auf dem offiziellen Titel. Soweit ich verstehe ist das was wir aktuell als Fleiß-Punkte bezeichnen die artenspezifischen Stärken, während das was wir aktuell auf Fleiß-Punkte haben offiziell die Basiswerte sind. Insbesondere die plötzliche Verschiebung von „Basiswerte“ vom einen zum anderen (welches dann nicht mehr länger eine Basis ist!) würde wahrscheinlich relativ schnell zu negativer Kritik und auf längere Dauer wahrscheinlich zu grundlegender Verwirrung in der deutschsprachigen Community führen, da dieser Begriff nicht wirklich logisch ist und die meisten wahrscheinlich den alten Fanbegriff weiternutzen würden, was Neulingen den Einstieg erschwert. Generell bin ich zwar dafür die offiziellen Begriffe zu nutzen und dann halt mit dem Ergebnis des Chaos zu leben, doch denke ich muss man hier etwas genauer überlegen ob man das wirklich will. --Mecanno-man^Mäh 22:15, 23. Feb. 2022 (CET)

Ich bin da bei Mec, gerade DV sind in der Pokémon-Community so fest verankert weil es eben jahrelang keinen offiziellen Begriff dazu gab. Lediglich die Bezeichnung auf der Pokémonseite scheint mir erstmal noch nicht genug. Ich würde bei einer so weitreichenden Veränderung erstmal noch die 9.Generation abwarten und schauen ob es ab dem Zeitpunkt auch in den Spielen einen offizieller Begriff geben wird und auch im nachhinein klar kommunizieren, dass dies nun die DV sind bzw ehemals DV genannt wurden. BeyJim ^Diskussion 20:59, 7. Mär. 2022 (CET)

Ryuichi konnte auf Discord zeigen, dass diese Begriffe ab der 7. Generation auch in Lösungsbüchern Einzug fanden. Weswegen scheinbar mehr Leute zu einer Verschiebung tendieren, wobei die jetzt verwendeten Begriffe als WL bleiben sollen. Das könnte Aufwand nach sich ziehen. Was halten die Strategen unter uns davon? @Poffelino, Luca12379: Das Isso 08/15 ^Konter 11:28, 9. Mär. 2022 (CET)

Ich stelle mir die Umsetzung im Strategie-Projekt schwierig vor. Im Moment wird Basiswerte in der in einigen Artikeln verwendet. In jedem Artikel müsste das ersetzt werden. Das ist viel Aufwand mit einem kaum vorhandenen Nutzen und sorgt für Verwirrung, während nicht alles ersetzt ist, und wahrscheinlich auch danach. Da die Strategie sehr an die englischen Begriffe gebunden. FP/DV sind genau die Äquivalente zu EV/IV. Die offiziellen Begriffe haben übersetzt eine andere Bedeutung. Auch wären einige Vorlagen betroffen. Beispielsweise ist in Moveset nicht genug Platz, um die voll ausgeschriebenen Begriffe aufzuschreiben. Außerdem müsste eine Lösung für Vorlagenparameter gefunden werden, was dann wahrscheinlich auch andere Bereiche im Wiki betrifft. --Poffel — Diskussion 23:31, 10. Mär. 2022 (CET)

Wir sind uns einig das die Verschiebung von Awakening values nach Go-Kräfte keine Problematik darstellt. Bei der Verschiebung von Determinant Values nach Individuelle Stärken wird es eher eine kurzzeitige Umgewöhnung geben. Diese sollte allerdings auch ohne großen Einfluss sein. Bei der Eindeutschung der seit Generation 7 offiziellen Begriffe gibt es allerdings auch den Begriff Basiswert welcher von offizieller Seite etwas anderes bedeutet als wie er seit Jahrzehnten in der Community verwendet wird. Die Diskussion hat gezeigt das wir weiterhin am Grundsatz eines Wikis festhalten werden. Wir sind da zur bestmöglichen fachlichen Dokumentation und keine X-beliebige Fanseite die alles nach den Fans ausrichtet. Der Blick in die Community wurde alleridngs nicht ausgeblendet. Es wurde sich auf eine Übergangsfrist geeinigt. Mecs Vorschlag von 2 Jahren wurde aufgrund der Schnelllebigkeit des Internets abgelehnt. Es wurde sich darauf geeinigt das folgendes bereits jetzt durch Isso umgesetzt werden kann:

• Awakening values nach Go-Kräfte
• Determinant Values nach Individuelle Stärken
• Basiswert nach Artenspezifische Stärken

Nachfolgend soll mit einer Botsuche die Überreste der drei Begriffe im gesamten Wiki ausfindig gemacht werden und auf den offiziellen deutschen Begriff geändert werden. Der Begriff Basiswert wird erstmal zu einer BKL umgewandelt zur Erläuterung/Differnzierung von Fanbegriff und offizielle Bezeichnung. Nach frühestens 1-2 Monaten wird der letzte Begriff Fleißpunkte zum offiziellen Begriff Basiswerte geschoben. Bis dies geschehen ist bleibt der Punkt auf der AD offen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)

Die AV usw. Umbenennung ist schon >1,5 Monate her. Kann jemand mal schauen ob es noch irgendwo die alten Begriffe im Wiki gibt? Wenn alles beseitigt wurde können wir in nächster Zeit mit FP beginnen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 07:49, 2. Jun. 2022 (CEST)

Umbenennung ist vollzogen. Kann bitte jemand mal das Wiki nach Fleiß-Punkt, Fleißpunkt, Fleisspunkt, Fleiß Punkt, Fleiss Punkt sowie EV und Evs absuchen ob noch etwas übrig geblieben ist? Dann kann der Punkt nämlich auch als bald ins Archiv. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 19:16, 18. Sep. 2022 (CEST)

Moratorium auf Rang-Wahlen während Spielreleases

Situation: Wir hatten nahezu gleichzeitig zum Release von Legenden Arceus eine VB-Wahl und eine Red-Wahl - bei Wahlstart der beiden gab es in internen Kanälen einige Benutzer, die den Wahlstartzeitpunkt stark kritisierten weil es zu der Zeit „wichtigeres zu Tun gäbe“. Ich will hier jetzt aber keine grosse Diskussion daraus machen, ob Wahlen während Spiele-Release aufgeschoben werden sollen oder nicht, da diese wiederum das Potenzial hätte relativ langwierig zu werden und sich in Details zu verhedern (z. B. bei der Bestimmung der Dauer eines Releasezeitraums). Daher mach ich's kurz und Schnurz und mache hier einfach eine Abstimmung - ich denke die grundsätzlichen Stimmen ob ja/nein Moratorium werden sich ohnehin nicht an Details aufhängen - und bestimme die Zeitspanne des Releasezeitraums einfach selbst (siehe unten). --Mecanno-man^Mäh 22:42, 6. Mär. 2022 (CET)

Abstimmung

Abstimmung abgeschlossen: Ja, Wahlen sollen nicht während Hauptspielrelease gestartet werden können. (9 Pro, 7 Kontra, 11 Enthaltungen)

Frage dieser Abstimmung ist: Soll es während Releasezeitraum von Hauptspielen (1 Woche vor bis 2 Wochen nach Release) verboten sein, Wahlen zur Vergabe von Redakteurs- und Verlässlicher-Benutzer-Rechte zu starten? Jeder stimmberechtigte Benutzer darf eine Stimme abgeben. Die Abstimmung läuft bis zum 20. März 2022 um 23:00. Heute ist der 16.04.2024 09:13 Uhr.

Ja, Wahlen sollen nicht während Hauptspielrelease gestartet werden können

1. Da es unterschiedliche Prioritäten gibt, wird das Starten einer Wahl während des Releasezeitraums meiner Meinung nach nahezu immer zu Spannungen führen, da mehr als 33% der Admins und Redakteure irgendwie mit dem Release zu tun haben werden. Dies wird dazu führen, dass sich die, die sich eher um den Inhaltsbereich des Wikis kümmern wollen als um Teamverstärkung sich zusätzlich unter Druck gesetzt fühlen, zeitnah bei der Wahl abzustimmen, obwohl das eigentlich nicht ihre Priorität ist - was schlussendlich deren Lust etwas im Wiki zu machen senken könnte, was gerade während eines Spielereleases mMn. unbedingt zu vermeiden ist. Einige werden das wahrscheinlich trotzdem nicht zeitnah abstimmen, da sie ihre Prioritäten nicht ändern werden - was dazu führt, das die Wahlen zusätzlich länger dauern als andere. Dies könnte weiter bei Kandidaten dazu führen, das sie sich vernachlässigt fühlen - etwas was mMn. nicht passieren würde, wenn man von Vornherein einfach auf eine Regel verweist und die Wahl dann im Worst-Case drei Wochen später abhält. Ich schätze auch, das es keine grosse Gefahr ist, das während eines Hauptspielreleases potenzielle VBs abspringen, denn gerade dann ist sowohl der Pokémon-Hype am grössten als auch die Arbeitssuche im Wiki am einfachsten. Aus diesen Gründen bin ich dafür, Wahlen nicht mehr zuzulassen, wenn klar ist das viele Benutzer anderwertig im Wiki beschäftigt sein werden. --Mecanno-man^Mäh 22:42, 6. Mär. 2022 (CET)
2. Mich stört die Vezögerung der beiden aktuellen Wahlen ebenfalls, daher wäre ich dafür. Es sollte aber trotzdem die Wahl bzw der Kandidat angekündigt werden, denn dann hat jeder schon mal davon gehört und wenn Zeit ist kann man sich schon mal was überlegen. Alternativ (falls die Mehrheit dagegen ist) könnte man zumindest darauf hinweisen, wenn/dass es aktuell zu Verzögerungen kommen kann/wird. Wurde btw bereits beim ersten mal gepingt. DeepSpace (Diskussion) 23:34, 6. Mär. 2022 (CET)
3. Spiele-Releases sind ne stressige Zeit und sich dann noch die Zeit zu nehmen um sich eine Meinung zu bilden, gegebenenfalls Edits begutachten und analysieren kostet alles Zeit und Motivation, die man woanders reinstecken könnte. Also zieht es sich und das ist schlecht. BeyJim ^Diskussion 23:58, 6. Mär. 2022 (CET)
4. Grundsätzlich sehe ich es so, dass große Spielereleases eine Zeit sind, in der es wichtig ist, möglichst zügig möglichst viele Informationen bereitzustellen. Natürlich ist es auch richtig, dass für eine Wahl geeignete Benutzer diese auch möglichst schnell erhalten sollten, jedoch finde ich, dass der eigentliche Inhalt des Wikis in diesem Fall Priorität gegenüber Benutzerrechten haben sollte, da er auch ein deutlich größeres Publikum betrifft. Ich kann jedoch auch Feblues Argument, dass es für Kandidaten ungünstig wäre, bereits gesagt zu bekommen, dass sie geeignet sind und dann aber vorerst keine Möglichkeit für eine Wahl zu bekommen gut verstehen, da das ebenso zu unnötiger Wartezeit führt, die ja eigentlich durch diesen Vorschlag verhindert werden soll. Ich würde daher vorschlagen (vorschreiben kann man das natürlich nicht), dass tatsächlich auch die Information des Kandidaten über seine Eignung vorzugsweise nicht in diesem Zeitraum erfolgt. So muss dieser dann nicht trotz seines Wissens über die Eignung zur Wahl noch auf diese warten, sondern sie kann direkt nach Information und Zustimmung des Kandidaten erfolgen. Ich möchte in diesem Fall außerdem noch kurz anmerken, dass sich meine Argumentation nicht auf mich persönlich bezieht (ich habe kein großes Problem mit der Dauer meiner Wahl), sondern nur auf den allgemeinen Fall bezogen ist. Ratequaza 09:15, 7. Mär. 2022 (CET)
5. Ich bin der Meinung, dass man eine Wahlrunde vertagen kann oder eben einen langeren Zeitraum dafür ansätzen sollte. (Man kann einfach schreiben, dass die Kanidaten bei der nächsten Wahlrunde dabei sind.) Das vertagen einer Wahlrunde, aufgrund der Menge an Arbeit im Wiki ist meines Erachtes eine gute Erklährung, sollte aber keine feste Regel sein. Was die Kanidaten davon halten kann man nur erahnen. Ich meine aber das Alle, welche für einen VB oder Redacktor Titel infrage kommen auch verstehen würden, das es im Moment die Wahl etwas länger dauern kann. MfG Goloer444 19:51, 7. Mär. 2022 (CET)
6. Die Vergangenheit hat mir gezeigt, dass hier eine klare Regelung notwendig ist, um Situationen wie die kürzlich aufgetretene zu vermeiden. Wahlen kurz vor oder direkt nach einem Spielrelease zu starten führt wie ersichtlich nur dazu, dass sie liegenbleiben. Zum Release von Pokémon-Legenden: Arceus hatten wir jetzt zwei Wahlen; einen Vorschlag direkt vor Release, der dann um zwei Wochen verschoben wurde, und einen Vorschlag wenige Tage nach Release. Beide Wahlen laufen immer noch, obwohl inzwischen knapp vier Wochen vergangen sind. Mir ist zwar bewusst, dass ich in gewissem Maße selber daran schuld bin, immerhin habe ich bei einer noch nicht abgestimmt. Allerdings liegt das hauptsächlich daran, dass ich wegen des Releases noch nicht wirklich dazu gekommen bin. Denn hier hat vor allem Ryu ein Argument gebracht, dem ich zustimme (wenn auch nicht unbedingt dem Ausdruckston): Das Wiki ist allen voran für Besucher gedacht. Diese sind hier, um Informationen zu den Spielen zu erhalten. Wenn es die nicht gibt, gehen sie im Zweifel woanders hin, wovon wir nichts haben. Gleichzeitig kann ihnen auch egal sein, wer von uns die Informationen im Wiki einträgt, ob neuer Benutzer, SB, VB, Red oder Admin tut sich da gar nichts. Und aus genau diesem Grund habe ich bei den vergangenen und werde auch bei den zukünftigen Spielreleases die Inhalte gegenüber Wahlen vorziehen. Dazu kommt ebenfalls, dass ich nicht glaube, dass eine einfache Absprache das Problem aus der Welt schaffen würde, sonst hätten wir es nämlich gar nicht. Besonders mit den neuen VB-Wahlen, die jetzt einfach auch von Redakteuren gestartet werden können, ist eine solche Absprache hinten herunter gefallen. In der Vergangenheit haben sich die Admins immer noch mal kurz untereinander abgesprochen, ob der Zeitpunkt für eine Redakteurswahl passt. Die damaligen VB-Wahlen sind nicht wirklich damit zu vergleichen, da sie einfach auf Admin-Ebene abgesprochen wurden und dann die Überraschung kam, dass jemand ernannt wurde oder es halt keine Ernennung gab. Sowas kann es ja jetzt nicht mehr geben. Jedenfalls gibt es diese eine Instanz nun nicht mehr, die das Wahl-System kontrolliert hat, wodurch die aufgezeichneten Probleme entstanden sind. Ich möchte aber doch sagen, dass ich an dieser Stelle auch die Sicht der zur Wahl stehenden nachvollziehen kann. Besonders wenn man schon länger dabei ist und glaubt, dass man inzwischen den Punkt erreicht hat, an dem eine Beförderung kommen sollte, ist es ärgerlich, wenn sowas im Zweifel dann durch eine solche Regelung geblockt wird. Dennoch denke ich, dass besonders diese Regelung das besser macht, da sie weniger willkürlich erscheint, als wenn einfach gar nichts passiert. Außerdem bietet der Spielrelease die chance, sich schon mal im Voraus noch mal speziell hervorzutun, um dann bessere Chancen bei einer Wahl zu haben. Etwas, das mich aber überrascht ist die Aussage, dass scheinbar schon vor Start der Wahl groß klar sein soll, dass jemand gewählt werden soll? Klar, sobald derjenige gefragt wird, ob er überhaupt zur Wahl antreten will, ist es nur logisch, dass derjenige bescheid weiß. Aber davor wüsste ich nicht, warum das klar sein sollte. Bin ich da so untypisch, dass ich den Leuten nicht verrate, dass ich sie zu einer Wahl vorschlagen will? Wie dem auch sei, auf den ersten Blick erscheint mir hier eine klare Regelung der bessere Weg, denn der Stress, der mit einer solchen Wahl kommen kann, ist nicht zu unterschätzen und besonders, wenn es Sachen gibt, die in den eigenen Augen wichtiger erscheinen, die Wahl aber öffentlich ist und man dauernd von irgendwem getrieben wird, doch endlich mal abzustimmen, ist das alles nicht zielführend. Daher bitte eine Zwangspause bei Release, damit im Zweifel nach Release Wahlen gestartet werden können und nicht so lange rumliegen müssen. -- RobbiRobb 20:22, 7. Mär. 2022 (CET)
7. Ja, solang der 'Sperrzeitraum' maximalst die von Mec genannten 3 Wochen sein wird. Eigentlich bin ich klar und deutlich auf der Seite, die Wahlen für wichtig genug sieht, um sie jederzeit haben zu wollen, aber ich sehe hier bisher keine Kompromissmöglichkeit. Die Grundsätze und Prinzipen dahinter wurden bereits intern beredet und diskutiert und ich sehe keinen Sinn darin die hier nochmal durchzugehen. Ich sehe da nämlich aktuell leider keine Möglichkeit der Annäherung. Von demher wird eine Seite nachgeben müssen. Das Absprechen intern sehe ich insofern vorsichtig an, da wir mMn sehr drauf aufpassen sollten, dass die VB-Wahlen gerne auch mal zu früh gestartet werden, denn sonst werden wir vermutlich früher oder später in zu späte Bestätigungswahlen rutschen (meiner Meinung nach ist eine Wahl ohne Kontrastimmen eine zu späte Wahl). Bei einer Absprache in intern, ob der Moment passt, könnte es denke ich leicht passieren, dass man sich nebenbei noch allgemein zu den ersten Eindrücken in der Runde unterhält und am Ende dann gegen die Wahleröffnung entscheidet. Sowas will ich auf jeden Fall vermeiden. Wenn eine Wahl zu einem ungünstigen Zeitpunkt gestartet wird, wird die Seite, der der Release erstmal wichtiger ist, nicht abstimmen, aber der öffentliche Druck ist größer bzw. überhaupt vorhanden. Dass das Spannungen verursacht und verstärkt ist offensichtlich zu sehen. Von daher sehe ich in so einer Sperrzeit die einzige Möglichkeit möglichst spannungsfrei dieses Problem zu lösen, auch wenn meine Vorstellungen und Grundsätze konträr zu so etwas stehen.--DeXter 22:51, 7. Mär. 2022 (CET)
8. Ich bin hier auf eindeutig für eine Regelung, die den Zeitraum um einen Hauptspiel herum von Personal-Wahlen frei halten soll. Genau in dieser Phase um den Release herum wird es in der Regel für einige der Abstimmenden zeitlich knapper, da Inhalte zum neuen Spiel aus der Gesamtsicht des Wiki einfach wichtiger sind. Die aller allerwenigsten Besucher wissen überhaupt über unserer Rechtestruktur bescheid. Sie sind effektiv nur für die Inhalte zum Spiel hier und nicht für das Personal dahinter. Die letzten beiden Spielrelease (SDLP und PLA) haben gezeigt, dass die hohe Arbeitslast auf immer weniger Personen verteilt wird. Persönlich finde ich, dass in dieser Zeit einfach keine Wahl stattfinden sollte, da die Prioritäten des Wikis einfach anders verteilt sein sollten. Das heißt nicht, dass neue User fürs Team nicht auch wichtig sind, aber dieser knappe Monat um den Release herum ist meiner Meinung nach noch als wahlfreie Periode zu verkraften. Bezüglich des Druck kann ich nur sagen, dass dieser zu eine gewissen Grad da ist, auch wenn ihn einige andere in dieser Wahl nicht zwingend sehen. Das fängt schon damit an, dass auf Discord während der Wahlen immer wieder Hashtags in die Richtung „Macht UserX RollenfarbeY“ auftauchen oder auch das unterschwellige Ansprechen der Wahl in öffentlichen Kanälen auf Discord. Das sorgt dafür, dass diejenigen, die noch nicht abgestimmt haben, weil sie entweder wenig Zeit haben oder noch unentschlossen sind, zu einem gewissen Maß gehetzt werden. Auch verstehe ich hier nicht zwingend, warum feblue der Auffassung ist, dass ein User bereits vor der Nachfrage zur Wahl so sicher sein kann, dass er für eine Wahl vorgeschlagen werden wird. Eigentlich erfährt der User erst davon, wenn sich der Red/Admin bereits sicher ist mit der Wahl und diese auch innerhalb der nächsten Stunden starten wird. Es ist ja nicht so, dass ich ihn zu einem Zeitpunkt, zu dem er noch nicht wirklich fit für den VB ist, frage, ob er den wöllte. Deswegen sehe ich hier irgendwie nicht, wie ein User sich da schon Wochen vorher so sicher sein kann, dass er zur Wahl aufgestellt wird. GrollenKette951 03:43, 19. Mär. 2022 (CET)
9. Ich habe beim Spielerelease von PLA stark gemerkt, dass es bei allen und insbesondere bei den Admins oft zu Prioritätsabwägungen kam. Zu Spielerelease sollte die Priorität jedoch meiner Meinung nach komplett auf genau diesem liegen. Wenn man sich während dieser Zeit auf Wahlen konzentrieren muss - insbesondere wenn es mehrere sind - fällt einiges an Arbeit für die Spiele hinten über. Und das können wir absolut nicht gebrauchen, da man bei PLA gut genug gesehen hat wie wenige dafür überhaupt etwas tun können und wie viel Zeit diese Leute ins Wiki investieren können. Die Verschiebung sollte aber auch wirklich nicht länger als 3 Wochen andauern. Ich würde nicht denken, dass der Wahlkandidat in dem Fall niedergeschlagen sein sollte. Solange es eine festgelegte Regel ist die nicht mal eben so kurz vor der Wahl beschlossen wurde sollte es auf genügend Verständnis treffen, ansonsten würde ehrlich gesagt bei mir das Verständnis stoppen. ~~ DieTaube 12:32, 20. Mär. 2022 (CET)

Nein, Wahlen sollen weiterhin immer gestartet werden können

1. In den letzten Monaten und im ersten Jahr des neuen Wahlsystems hat sich abgezeichnet, dass das System noch nicht ganz auf allseitige Zustimmung trifft und es immer wieder Streitpunkte gibt, bei denen keine Einigung gefunden werden kann. In allen möglichen Kanälen wurde über das letzte Jahr sehr oft über die Problemstellen der Wahlen kommuniziert und teils gestritten. Von daher möchte ich hier schonmal mitschwingen lassen, dass ich die Bemühung, das gesamte Wahlsystem nochmal ein wenig zu verfeinern, anerkenne und loben möchte. Dennoch stelle ich meine Stimme gegen diese Veränderung. Mich stört nicht der Zeitraum, der hier angeschlagen wurde, sondern der Fakt, dass er existiert, und das ist nunmal der Grundvorschlag in dieser Abstimmung. Sowohl VB- als auch Red-Kandidaten können am eigenen Zeitinteresse und an Feedback, das sie in ihrer Zeit im PokéWiki sammeln, ablesen, wann sie sich selbst einem neuen Rang gewachsen sehen. Hat ein solcher Nutzer jemanden, der den Nutzer schon länger beobachtet und daher vorschlagen möchte, dann weiß der Kandidat umittelbar über diese Entscheidung Bescheid. Eine Situation, in der der Kandidat möglichst kurz verharren will. Der Eintritt des Wissens, dass der Kandidat darüber Bescheid weiß, dass er gewählt werden kann und es jemanden gibt, der ihn vorschlagen wird, und der Eintritt des Vorschlags auf der Wahlseite unterscheiden sich in diesem Fall nicht. In beiden Fällen ist dem Kandidaten bewusst, dass er aufsteigen kann. Der einzige Unterschied hierbei liegt an der Öffentlichkeit. Der Eintritt des Vorschlags macht den Vorschlag öffentlich, der Eintritt des Wissens nicht. Dieser geschieht in Privatnachrichten und internen Kanälen. In dieser Abstimmung entscheiden wir also darüber, ob die Stimmberechtigten der ersten Runde durch die Veröffentlichung des Vorschlags öffentlich unter Druck gesetzt werden oder ob dem Kandidaten über ein gewisses Zeitfenster der mögliche Aufstieg verwehrt wird. In diesem Fall entscheide ich mich zugunsten des Kandidaten und möchte mich dafür einsetzen, dass Kandidaten weiterhin jederzeit vorgeschlagen werden können. -- ~~ feblue 00:56, 7. Mär. 2022 (CET)
2. Ich glaube eine Moratorium bringt hier wenig. Es sollte doch eigentlich ausreichen, auf Discord oder halt auch hier auf einer Diskussionsseite nachzufragen, ob gerade ein guter Zeitpunkt ist oder man halt noch ein oder zwei Wochen wartet. Ein Verbot wird in einem halben Jahr vielleicht vergessen sein und dann wird versehentlich eine Wahl gestartet. Wenn die wieder abgebrochen werden soll, hilft das der Moral des zu Wählenden sicherlich auch nicht weiter und derjenige, der die Wahl gestartet hat, kriegt vielleicht auch noch eins auf den Deckel. Wir müssen nicht alles bis ins Detail mit Regeln und Verboten belegen, nur weil wir in Deutschland leben :D - - "I'm gonna swing from the chandelier" GoPika ^Disku 07:55, 7. Mär. 2022 (CET)
3. Es macht meiner Meinung nach nicht so viel Sinn, eine Wahl zu verschieben, um sie zu verkürzen. Selbst wenn viele Redakteure und Admins beschäftigt sind, können sie sich doch Gedanken machen und weniger beschäftigte bereits abstimmen. Dadurch sollten die Wahlen auch tendenziell etwas früher abgeschlossen werden. Für Kandidaten finde ich es unfair, zu verschweigen, dass sie vorgeschlagen sind. Auch zu sagen „Du bist vorgeschlagen, aber geht nicht wegen Regel“, ist auch nicht besser. Am besten fände ich es für Kandidaten, die Wahl sofort zu starten und sie darauf hinzuweisen, dass die Wahl wegen neuen Releases etwas länger dauern könnte. Den Druck auf Redakteure und Admins kann ich auch nur teilweise nachvollziehen, weil es für die erste Wahlrunde keine zeitliche Begrenzung gibt. Da hilft es möglicherweise zu versuchen, sich nicht unter Druck setzen zu lassen. Dazu besteht auch eigentlich kein Anlass, weil eine lange Dauer der Wahl für den Kandidaten kein Problem sind, wenn eine gute Begründung dafür vorliegt. Wenn man sich der Wahl zu sehr verpflichtet fühlt, kann man den Kandidaten auch einfach über Discord darüber informieren, dass sich die Abgabe der Stimme verzögert. --Poffel — Diskussion 11:42, 7. Mär. 2022 (CET)
4. Ich glaube, diese Abstimmung ist durch großen Zufall zustande gekommen. Wir haben pro Jahr einen (mit Ausnahme von Arceus zwei) Hauptspiele-Releases. Nun hatten wir bei den beiden letzen großen Releases eine Wahl gestartet. Entsprechend kommt dieser Fall generell sehr selten vor. Falls er jedoch vorkommt, wird eine generelle Verbots-Regel, wie schon von Vorredner angesprochen, unter Umständen vergessen. Daher bin ich gegen so eine allgemeine Regel. Hinzu kommt, dass die längere Wartezeit für Kandidaten zwar blöd sein kann, jedoch zeigt es doch auch, dass sich die Admins/Reds/VBS eben einige Gedanken dazu machen möchten. Solange nicht gedrängelt wird, man möchte doch bitte über einen Kandidaten abstimmen, sehe ich da kein großes Problem. Falls man sich unsicher ist, ob man nun während eines Spiel-Releases eine Wahl starten sollte oder nicht, kann man auf Discord nachfragen und bekommt ein freundliches, warte lieber zwei Wochen ab, zurück. Wenn jedoch trotz der Regel, weil sie vergessen wurde, eine Wahl gestartet wird, ist das "Gejammer" der anderen wahrscheinlich größer. -- Cliffichen 17:51, 7. Mär. 2022 (CET)
5. Meiner Meinung nach, sollen die Wahlen immer gestartet werden können. Die Wahl muss nicht direkt nach 2 Tagen autorisiert sein. Sie kann gestartet werden, aber wenn sie einwenig später autorisiert wird, entsteht sowohl keinen "Schaden" bei der Wahl, alsauch im Fortschritt der neuen Informationen des neuen Spiels. Lunairline^{Buchung zum Mond} 18:51, 7. Mär. 2022 (CET)
6. Jones ^Albtraum? 19:31, 7. Mär. 2022 (CET)
7. Eventuell sollte man darauf achten, nicht zu viele in der Release-Zeit zu haben. Das Isso 08/15 ^Konter 20:43, 7. Mär. 2022 (CET)

Enthaltung

1. Auch wenn sich vielleicht der ein oder andere nun auf den Schlips getreten fühlt. Nachfolgend meinbe Meinung zu dieser Abstimmung und wo ich die Probleme sehe:
   Ich weis gerade echt nicht wer mir mehr die Galle hoch treibt, Mec mit dieser Abstimmung oder die abgegebene Stimme von feblue. Eine derartige Abstimmung aus dem "nichts" heraus, kurz vor einem Chattreffen finde ich ziemlich Kontraproduktiv. Auch die Optionen sind nur Regel ja oder nein. Das ist ziemlicher Brechstangenmodus ohne überhaupt eine Diskussion eröffnet zu haben. Gerade weil es bereits aus Discord hervor ging das es hier starke kontroversen bei dem Thema gibt finde ich die Art und weise einfach nur zum K**zen.
   Eine Regel finde ich hier in keiner weise zielführend, entweder sie gerät in Vergessenheit oder schafft Unmut weil Wahlen wieder abgebrochen werden oder die Schuld den Regeln gegeben wird usw.
   Braucht es gerade in höheren Ebenen echt eine Überregelung für jeden Nonsens? Etwas Hirnschmalz, gesunder Menschenverstand und blick fürs Team sollte reichen. Deshalb kann ich definitiv nicht für Pro stimmen. Auf der Anderen Seite bin ich hier zwar bei GoPika, wenn man sich vorher abspricht ob gerade ein guter Zeitpunkt ist dann ist dies völlig ausreichend und man könnte in der Theorie jederzeit eine Wahl mit Rücksprache starten. Mich stört allerdings dieses generelle "jederzeit kann eine Wahl gestellt werden" da ich hier durch feblues immer wieder auftretende Blauäugigkeit um nicht sogar von Arroganz zu sprechen. Diese regelmäßigen Alleingänge wie sie bisher passiert sind, welche das gesamte Team unter Druck setzen gehen mir derbst gegen den Strich und sorgen eher für noch weniger User, denn auch ich schaue mir das nicht mehr lange an. Entweder wir arbeiten Zusammen an dem Großprojekt Wiki oder jeder kümmert sich nur noch um seinen kram und macht was er für richtig hält. Und ich schwöre das Schuss wird nach hinten Los gehen. Weg vom allgemeinem zurück zum Thema Wahl. Jemanden zur Wahl zu stellen wenn niemand Zeit hat wird die Wahlentscheidung immer verzögern und ich muss ganz ehrlich sagen ich lasse mich bei meinem Hobby nicht unter druck setzen. Es ist und bleibt ein Hobby. Auch finde ich das derartiges Verhalten eher dem gesamten Wiki schadet. Das Wiki ist für diejenigen die Mitarbeiten ein Hobby. Man macht es für sich und für die Leser und dem Leser ist es völlig egal ob der Inhalt von einem Admin, Redakteur oder sonst wem geschrieben wurde. Der Leser möchte für seine Suche schnell ausführlich fündig werden. Dies ist allerdings nicht möglich wenn man mit Großen Sachen abgehalten wird. Solche Wahlen schaden mehr wie sie nützen. Nicht jeder hat sämtliche User der LÄ auf dem Schirm. Das Bedeutet es müssen Beiträge Geprüft werden, sich ein Eindruck über die Entwicklung verschafft werden usw. Ich kann nur für mich sprechen, das ganze ist keine Sache die ich zwischen Tür und Angel mal schnell in fünf Minuten erledige. Sich dann noch hinzustellen und mit dem Finger drauf zu zeigen, du da ist noch eine Wahl wo du nicht abgestimmt hast, treibt mir dermaßen die Wut. Denn der Schuldige ist nicht derjenige der noch nicht abgestimmt hat sondern derjenige der Alleingänge macht und das gesamte Team damit tritt indem er zum ungünstigsten Zeitpunkt eine Wahl startet nur weil es ihm gerade in den Kopf schießt. In den seltensten Fällen kommt ein SB und sagt ich will VB werden selbiges gilt für VB zu Red oder Red zu Admin. In der Regel kommt ein höherrangiger User und fragt ob man sich zur Wahl stellen will. Das bedeutet den Zeitpunkt der Fragestellung wählt ein erfahrener Benutzer. Bei solchen Fällen wenn gerade ein Paar Tage nach einem Spielrelease eine Wahl gestartet wird. Damit fällt man wie gesagt dem gesamten Team in den Rücken. Statt hier einfach klar und deutlich zu sagen "Hey User XY ich würde dich gerne für Rang... vorschlagen? Derzeit ist ja der Spielrelease was viele sehr einspannt, danach würde ich deine Wahl weitergeben/starten, willst du zur Wahl gestellt werden?" Durch eine Vorankündigung kann jemand auch zeigen was er leisten kann. Da ich weder die fixe Regel unterstützen kann noch ein Generelles Nein jederzeit (da es Rücksprache nicht verpflichtet) bleibt mir lediglich die Enthaltung. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:38, 7. Mär. 2022 (CET)
2. Ich glaube auch, dass Augenmaß und Abstimmung untereinander sich hier richtiger anfühlen als eine weitere Regel. Maxmiran 19:04, 7. Mär. 2022 (CET)
3. Ja, man sollte mehr auf das jeweilige Ermessen setzen. Als Regel festsetzen würde ich es auch ungern, aber der Hinweis auf das Problem ist schon nicht unwichtig. -MfG, Kenaz-Hagalaz ^Disku 20:52, 7. Mär. 2022 (CET)
4. Ditto —DaneeBound 11:44, 9. Mär. 2022 (CET)
5. Ich seh das ähnlich wie Maximiran Kernseife ^Diskussion 14:27, 9. Mär. 2022 (CET)
6. Ich finde auch sehr wichtig, dass hier auf das Problem hier hingewiesen wurde. Am Anfang war ich generell gegen ein Verbot. Nachdem ich jedoch einige Beiträge durchgelesen habe, kann ich die Seite für ein Verbot durchaus nachvollziehen. Ich denke wie Maximiran, dass das besser nach Augenmaß entschieden werden sollte und sich eine Abstimmung untereinander besser anfühlt, anstatt eine festgelegte Regel einführen. Arkany 21:01, 10. Mär. 2022 (CET)
7. Ich kann die Begründung für die Regelung nachvollziehen; allerdings weiß ich nicht ob man dafür wirklich eine weitere feste Regel aufstellen muss. Es würde ja eigentlich auch reichen, wenn man sagt die Antragsteller sollen in Zukunft darauf achten, dass zu der Zeit nicht zu viel im Wiki zu tun ist. Und im worst case dauert die Wahl, so wie das jetzt der Fall war, halt etwas länger; ich glaube das ist nicht so problematisch wie das hier zum Teil dargestellt wurde. Ich will das mit meiner Stimme aber auch nicht blockieren, daher zumindest vorerst Enthaltung. – Vircaprae 22:35, 10. Mär. 2022 (CET)
8. Ich stimme den vorherigen Enthaltungen zum Großteil zu und hab nicht wirklich etwas hinzuzufügen BlauesSerpiroyal ^Diskussion 10:58, 11. Mär. 2022 (CET)
9. Nach einigem hin und her bei all den Argumenten hier wo ich mich für keine Seite entscheiden kann denke ich, das eine Enthaltung für mich das beste wäre Ich kam, sah und bearbeitete Bennett ^Diskussion 20:11, 11. Mär. 2022 (CET)
10. Ich kann nicht einschaetzen, wie die Arbeitslast bei den wirklich relevanten Leuten ist, daher moechte ich nicht gleichgewichtet in die Diskussion eingehen wie die, die es betrifft. Ausserdem bin ich allgemein gegen zu viele Regeln, waere also vermutlich auch sonst ne Enthaltung. Nescientist (Diskussion) 19:25, 15. Mär. 2022 (CET)
11. Ich möchte hier über nichts abstimmen, das mich vermutlich weder in Zukunft noch aktuell in irgendeiner Weise betrifft. Lasagne (Diskussion) 08:35, 17. Mär. 2022 (CET)

Pings

@Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, DarkOkto, Der Sternendiamantritter, Ediz, Goloer444, Heikolino1010, Jardan, Jass, Kernseife, Lasagne, DasLunalein, Mario-WL, Nescientist, Panflami, PokeMaestro, PokéSpe, Ratequaza, ScNoni, Vaultysworld --Mecanno-man^Mäh 23:15, 6. Mär. 2022 (CET)

Die Wahl ist Abgeschlossen und umgesetzt. Der Punkt kann folglich ins Archiv. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:20, 10. Apr. 2022 (CEST)

Anfrage auf Umbenennung und die Schaffung einer BKL

→ Hauptseite: Diskussion:Pokémon (Spezies)

Aufgrund der Wichtigkeit dieser Seite halte ich es für Sinnvoll die Abstimmung hier durchzuführen. Verlauf der Diskussion siehe hier. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)

Abstimmung beendet: Ergebnis → Option A: Pokémon [BKL], Franchise und Spezies erhalten passende Klammerzusätze

Abstimmung

Frage dieser Abstimmung ist: Wie sollen die Artikel für Spezies und Franchise benannt werden?' Die eckigen Klammern dienen Lediglich zur Erläuterung was sich zukünftig unter dem Artikelnamen Pokémon finden würde und sind kein Bestandteil des Namen. Jeder stimmberechtigte Benutzer darf eine Stimme abgeben. Die Abstimmung läuft bis zum 30. April 2022 um 23:00. Heute ist der 16.04.2024 09:13 Uhr.

Option A: Pokémon [BKL], Franchise und Spezies erhalten passende Klammerzusätze

1. Nachdem ich mir die komplette Diskussion nochmal in Ruhe durchgelesen habe scheint mir dies am sinnvollsten. Es beißt sich einfach das das Übergeordnete Franchise wie die Spezies heißt. Es erscheint für mich der sinnvollste Kompromis um nicht in einem Jahr wieder die Diskussion zu haben. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)
2. Wie bereits in der Ursprungsdiskussion genannt. Jones ^Albtraum? 19:58, 10. Apr. 2022 (CEST)
3. Beides ist Pokémon, eines dem anderen unterzuordnen fände ich nicht gut. BeyJim ^Diskussion 21:43, 10. Apr. 2022 (CEST)
4. --Mario-WL (Diskussion) 20:07, 11. Apr. 2022 (CEST)
5. Finde ich persönlich am sinnigsten. Ich kann Jones in der Ursprungsdiskussion nur zustimmen, würde aber zu Spezies tendieren, da wir in den Pokémonartikeln den Abschnitt ja Spezies nennen. Ich finde es nicht schlimm, dass wir für Singular und Plural dasselbe Wort benutzen, habe jedoch nichts dagegen den Artikel einen anderen Klammerzusatz zu geben. Persönlich würde ich die Unterteilung, nicht über Stamm einstufen, weil Reich Menschen mit Einschließen würden. MfG Goloer444 11:02, 15. Apr. 2022 (CEST)
6. kann mich nicht so recht zwischen A und B entscheiden, tendiere aber eher hierher BlauesSerpiroyal ^Diskussion 23:32, 15. Apr. 2022 (CEST)
7. Ich geh hier fast ausschliesslich nach dem, was Leute suchen, wenn sie "Pokémon" in die Suche eingeben, und da gibt es einfach zwei Moeglichkeiten, die relativ aehnlich wahrscheinlich sind. Alles andere sind fuer mich eher zweitrangige Argumente (hoechstens), oder sie verdrehen Ursache und Wirkung. Nescientist (Diskussion) 16:10, 16. Apr. 2022 (CEST)
8. Ich hatte nie ein Problem mit dem Begriff Spezies und daher erscheint mir das hier als die beste Option. ~~ DieTaube 18:19, 17. Apr. 2022 (CEST)
9. -MfG, Kenaz-Hagalaz ^Disku 17:13, 29. Apr. 2022 (CEST)
10. Ursprünglich war ich für die BKL, dann habe ich aber mal im Wiki Pokémon gesucht und gesehen, dass man dabei auf Franchise kommt, wo es bereits einen Hinweis zu (Spezies) gibt. Von daher bin ich mir nicht mehr sicher, da das für mich schon seinen Zweck erfüllt und man da nicht noch extra ne BKL vorschalten muss. Gleichzeitig finde ich es irgendwie blöd, nur einem von beiden einen Zusatz zu geben... Deshalb entscheide ich mich jetzt doch für die BKL, dann ist es wenigstens einheitlich und es hilft Leuten, die mit Pokémon nichts oder nur wenig zu tun haben, bei der Suche. Damit haben aber sowohl A als auch B 10 Stimmen, was auch nicht gerade hilfreich ist... :hexe: DeepSpace (Diskussion) 20:56, 30. Apr. 2022 (CEST)
11. AAWiki ^Diskussion 21:10, 30. Apr. 2022 (CEST)

Option B: Pokémon [Name für Spezies] und Franchise erhält passenden Klammerzusatz

1. Imo. befasst sich unser Wiki mehr mit der internen Pokémon-Welt als mit der Metaebene von Pokémon in der Realität; daher scheint es mir sinnvoller den Artikel für Pokémon als Spezies einfach nur Pokémon zu nennen - denn das ist es, was in der Pokémon-Welt mit „Pokémon“ bezeichnet wird. --Mecanno-man^Mäh 19:11, 10. Apr. 2022 (CEST)
2. So hätte es immer für mich sein sollen. Das wird das sein, das die meisten auch sehen wollen, wenn sie den Begriff suchen. -- MfG, SwowoJonny 12:47, 11. Apr. 2022 (CEST)
3. Diese Option liegt für mich auf der Hand, weil ich einerseits Mec bei der inhaltlichen Ebene zustimme (auch wenn ich verstehe, wie man das anders deuten kann). Zweitens ist es das, was ich aus Leserperspektive erwarten würde, wenn ich einfach nur nach "Pokémon" im Wiki suche. Drittens die organisatorische Sicht: Der Klammerzusatz für den Spezies-Artikel ist umstritten und bisher kam mir kein guter Vorschlag unter. Daraus ist ja die ganze Diskussion überhaupt erst erwachsen und eine BKL löst das Ursprungsproblem gar nich. Daher ist es einfach pragmatisch, ihn hier wegzulassen, dann stellt sich diese Folgefrage gar nicht. Maxmiran 17:39, 11. Apr. 2022 (CEST)
4. Aus allen bereits genannten Gründen finde ich diese Option am besten. Auf der Pokémon-Seite würde ja sicherlich oben weiter ein Link zum Franchise stehen. --Klein, aber fein. Killuu 21:27, 11. Apr. 2022 (CET)
5. Ich finde hier Mecs Argument entscheidend und schließe mich dem an. -- ~~ feblue 23:50, 11. Apr. 2022 (CEST)
6. Ich kann die Begründungen für Pokémon als Artikel über die Spezies oder das Franchise beide nachvollziehen und wäre mit beiden Optionen einverstanden. Ich finde allerdings, dass nicht beide Artikel einen Klammerzusatz haben sollten, weil für uns als PokéWiki Pokémon quasi der wichtigste Artikel ist und daher keine BKL sein sollte. – Vircaprae 23:59, 13. Apr. 2022 (CEST)
7. Pokémon (Spezies) halte ich für den interessanteren und besser geeigneten Artikel Pokémon. -- Cliffichen 10:32, 14. Apr. 2022 (CEST)
8. Ich denke die meisten Leute werden bei "Pokémon" erstmal an die Taschenmonster aus den Spielen denken. Zumindest ich habe bisher bei der Suche nach dem Begriff immer zum Taschenmonster-Artikel gewollt und hatte des öfteren einen ah ja, das andere liegt unter dem Namen im Wiki. Im Allgemeinen ist mir die Gleichberechtigung einer BKL lieber, aber hier haben wir so wichtige Artikel, dass die Userfreundlichkeit mMn überwiegt.--DeXter 23:59, 14. Apr. 2022 (CEST)
9. Meiner Meinung nach sollte das PokéWiki auf eine der augenscheinlich einfachsten Fragen ("Was ist/sind Pokémon?") nicht mit einer Gegenfrage ("Was meinst du mit Pokémon?") antworten. Stattdessen sollte es wie bislang einen normalen Artikel mit dem Namen "Pokémon" geben, der zu Beginn auf andere Artikel verweist, die mit diesem Begriff auch gemeint sein könnten.
   Nachdem ich mir dazu Gedanken gemacht und auch bei ein paar anderen Wikis geguckt habe, bin ich eigentlich der Meinung, dass der "Pokémon"-Artikel im PokéWiki das Franchise behandeln sollte. Allerdings ist es mir wichtiger, dass der "Pokémon"-Artikel keine Begriffserklärung wird, und es scheint bei dieser Abstimmung ärgerlicherweise keine Stichwahl zu geben. Deswegen gebe ich meine Stimme für Option B ab, die noch Chancen auf den Sieg hat und mit der ich auch gut leben kann. --Lasagne (Diskussion) 12:49, 28. Apr. 2022 (CEST)
10. -- Mooni000 ^{Pelipper-Post} 23:52, 29. Apr. 2022 (CEST)

Option C: Pokémon [Name für Franchise] und Spezies erhält passenden Klammerzusatz

1. Es ist ziemlich klar, dass alle Optionen schlecht sind. Für mich ist Pokémon noch mehr als nur die Lebewesen. Deshalb erwarte ich vom Artikel Pokémon auch Informationen über die Spiele, Anime usw. Außerdem sehe ich das Franchise den Lebewesen übergeordnet. Die Begriffsklärungsseite ist möglich, allerdings gleichzeitig eine sehr unschöne Lösung. Außerdem möchte ich nochmal eigentlichen Grund, mit dem Kenaz-Hagalaz die Diskussion gestartet hat, betonen. Der Name Pokémon (Spezies) kann sehr verwirrend sein, weil sowohl Pokémon als auch Spezies im Singular und Plural identisch sind. In der echten Welt wird in der Biologie Spezies synonym zu Art verwendet. Diese Verwendung passt aber mit dem Titel nicht zusammen, egal ob Pokémon im Singular oder Plural gemeint ist. Deshalb ist nur die formal falsche Bedeutung von Spezies, dass alle Pokémon eine Gruppe von Lebewesen sind, möglich. Diese Verwendung ist auch durch Zitate aus den Spielen bestätigt, jedoch sind die Zitate natürlich Umgangssprache, bei der Spezies auch möglicherweise in einer unpräzisen Bedeutung verwendet werden kann. Weiter unten in Pokémon (Spezies) wird der Begriff Spezies auch richtig für eine konkrete Art verwendet, zum Beispiel für Laschoking und seine Galar-Form. So ist es auch in allen Artikeln im Pokédex-Projekt. Deshalb bin ich ebenfalls für eine Änderung des Klammerzusatzes, falls dieser nicht durch Option B wegfällt, um den Fehler zu beheben und mögliche Verwirrung zu verhindern. Leider gibt es bisher keine zufriedenstellenden Vorschläge für einen Ersatz. Dass die bestehenden Vorschläge Lebe-/Wesen viel Gegenwind bekommen, kann ich gut verstehen. Das Beste, was mir eingefallen ist, ist Lebensform, was ein Kompromiss zwischen Spezies und Lebewesen ist und positiv wirkt. Mit dieser Wahl wird zwar wahrscheinlich abschließend geklärt, bei welchen Artikeln Klammerzusätze verwendet werden, aber nicht, welcher für die Lebewesen verwendet wird. --Poffel — Diskussion 19:28, 11. Apr. 2022 (CEST)
2. Ich denke ähnlich wie mein Vorredner. Pokémon bezeichnet für mich in erster Linie „ein Phänomen“, ich denke in erster Linie an die Spiele, wenn ich es höre. Fans des Anime würden an eben diesen denken usw. Kaum einer wird wirklich an eine Lebensform an sich denken(, auch wenn Eltern zuerst an Pikachu denken). Zumal mir "Spezies" auch nicht zusagt. Das Isso 08/15 ^Konter 11:23, 14. Apr. 2022 (CEST)

Enthaltung

1. Mir eigentlich egal. —DaneeBound 17:03, 10. Apr. 2022 (CEST)
2. Ehrlich gesagt kann ich mit allen Optionen eigentlich ganz gut leben, solange (falls sich gegen eine BKL entschieden wird) dann mit Dieser Artikel auf den Artikel verlinkt wird, der nicht unter "Pokémon" liegt (was ja derzeit auch der Fall ist). Man müsste halt theoretisch wissen, was Leute eher meinen, wenn sie hier "Pokémon" in die Suche eintippen, da ich das aber nicht genau einschätzen kann, bleibe ich mal bei Enthaltung. Ratequaza 18:48, 10. Apr. 2022 (CEST)
3. Kann mich da auch nur Vorerst enthalten, da ich auch hier noch keine wirkliche Meinung zu habe. Vaulty 19:32, 10. Apr. 2022 (CEST)
4. Habe hierzu keine Meinung um ehrlich zu sein Kernseife ^Diskussion 15:10, 11. Apr. 2022 (CEST)
5. Mit freundlichen Grüßen Lunairline^{Buchung zum Mond} 15:58, 11. Apr. 2022 (CEST)
6. Ich pendel hier immer wieder zwischen den Möglichkeiten hin und her, weil ich mir nicht wirklich sicher bin was eine Person, die das Wiki besucht wirklich mit der Suche nach Pokémon finden möchte. Beispielsweise Eltern, die sich nicht mit dem Thema auskennen. Suchen diese Informationen zu den Pokémon selber oder zu Pokémon als Serie/Franchise etc. Da ich mir hier absolut unsicher bin erstmal eine Enthaltung GrollenKette951 23:36, 16. Apr. 2022 (CEST)
7. Ich habe mich die letzten drei mal, als wir dieses Thema diskutiert haben, schon daraus gehalten, weil es mir recht egal ist, und werde mich auch dieses mal da raus halten. -- RobbiRobb 23:52, 18. Apr. 2022 (CEST)
8. Ich sehe ich allen Optionen positive und negative Punkte. - - "I'm gonna swing from the chandelier" GoPika ^Disku 12:57, 25. Apr. 2022 (CEST)
9. A klingt am logischsten, aber B hat auch seine Vorzüge. Ich kann mich mit beidem anfreunden, deswegen spiele ich heute nicht das Zünglein an der Waage :D GrüßeShortyBuzz 21:35, 30. Apr. 2022 (CEST)

Kommentare

Es verstößt in der Tat gegen die reine Lehre, aber ich finde Mecs Perspektive hier eingängig. Der Gegenstand des Wikis ist offenbar die Innenperspektive, alle anderen Artikel sind irgendwo Fremdkörper, mit denen wir uns schwertun. Ich erinnere mich da gut an unsere alte Diskussion, ob es bspw. einen Artikel über Pokéfans, Bisafans o.ä. geben sollte – das wäre zu erwarten, wenn wir tatsächlich Pokémon auch nur sekundär anstatt ganz hart am Rande als realweltliches Phänomen beschreiben wollen würden. -- Skelabra2509 (Diskussion | Beiträge) 14:19, 12. Apr. 2022 (CEST)

Dank Skel bin ich auf den Kommentar von Mec gestoßen Imo. befasst sich unser Wiki mit der internen Pokémon-Welt als mit der Metaebene von Pokémon in der Realität. Wenn ich den Satz richtig verstehe dann verstoßen doch Artikel zu Firmen, die Behandlung von Merchandise, Synchronsprecher sowie die ganzen Übersichten zu Manga, Anime und Spiel. Denn all das sind doch Artikel die sich auf einen Teil des Franchise beziehen und keine Artikel zur internen Pokémon-Welt wozu ich z.b. die Orte-, Pokédex-, Mangakapitel, Episodenartikel usw. zählen würde. Also entweder Verstehe ich hier den Kommentar von Mec nicht oder er ist so nicht richtig. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 14:42, 12. Apr. 2022 (CEST)

Tatsache, da fehlte irgend ein Vergleichswort. Hab mal ein "mehr" ergänzt. --Mecanno-man^Mäh 18:37, 12. Apr. 2022 (CEST)

Da ich es immer wieder raus lese und auch die Ursprungsdiskussion sich eher darauf bezog das viele den Klammerzusatz Spezies stört. Wenn es bis 18.04.2022 12:00 Uhr keine Einwände gibt dann können wir ja in der Abstimmung Spezies oder anderer Name sagen. Falls das die Problematik der Stimmen sein sollte? So könnte man ggf. in einem Brainstorming (je nach Ausgang der Abstimmung nach einem anderen Namen für Spezies suchen) Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:38, 14. Apr. 2022 (CEST) Aufgrund Poffels Nachricht via Discord, nur um Missverständnisse zu vermeiden die Optionen würde ich dann (bei keinen Einwänden) ändern in:

• Option A: Pokémon [BKL], Franchise und Spezies erhalten passende Klammerzusätze
• Option B: Pokémon [Name für Spezies] und Franchise erhält passenden Klammerzusatz
• Option C: Pokémon [Name für Franchise] und Spezies erhält passenden Klammerzusatz

Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:05, 14. Apr. 2022 (CEST)

Ping

Hier der obligatorische Ping an die Abstimmungsberechtigten: @AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, DarkOkto, Der Sternendiamantritter, Ediz, Goloer444, Jardan, Jass, Kernseife, Killuu, Lasagne, DasLunalein, Mario-WL, Nescientist, Panflami, PokéSpe, ScNoni, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Vircaprae * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:58, 10. Apr. 2022 (CEST)

Die Bürgermeister

Im Moment existiert der Artikel Bürgermeister, der auf mich uneindeutig wirkt. Es gibt in verschiedenen Spielen verschiedene Bürgermeister, weswegen mein Vorschlag lautet den aktuellen Bürgermeister zu "Bürgermeister von Freezedale" zu schieben. Wir haben auch schon eine BKL Bürgermeister, die ich lieber auf "Bürgermeister" sehen würde. Gibt es dazu weitere Meinungen? Das Isso 08/15 ^Konter 21:38, 7. Mai 2022 (CEST)

Zumindest für mich war die Begründung, den Bürgermeister von Freezdale einfach nur Bürgermeister zu nenn das kein anderer Charakter tatsächlich den Artikel "Bürgermeister" in anspruch nehmen würden, weil die anderen Bürgermeister alle Namen haben. Nach den anderen CHarakteren würde man folglich kaum als "Bürgermeister" suchen. Es fehlt mir jedoch eindeutig ein "Dieser Artikel" im Artikel des Bürgermeisters, der zur BKL linkt. --Mecanno-man^Mäh 22:45, 8. Mai 2022 (CEST)

Ich finde Issos Vorgehensweise hier vollkommen schlüssig. Wenn das Bürgermeistersein bei den anderen Bürgermeistern auch eine entscheidende Eigenschaft ist und es dadurch vorkommen kann, dass Leute nur "den Bürgermeister" suchen, reicht das für mich als Argument. LG --Fliegen bis zum Horizont. Killuu 19:43, 11. Mai 2022 (CET)

Ich muss sagen, ich finde es ein wenig komisch, dass ausgerechnet der eine Bürgermeister genau auf dem Artikelnamen liegt. Issos Vorschlag möchte ich unterstützen, damit man auch sieht, dass es nicht nur einen Bürgermeister gibt. Ich kannte nämlich zwei davon gar nicht :D -- ~~ feblue 14:30, 22. Mai 2022 (CEST)

Ich würde dann auch mal hier eine Frist bis 09.06.2022 20 Uhr setzen, damit der Punkt abgeschlossen werden kann. Folgendes würde ich bei Ablauf der Frist umsetzen:

1. Bürgermeister (Begriffserklärung) bleibt BKL, wird angepasst und zu Bürgermeister geschoben
2. Aktueller Bürgermeister wird zu Bürgermeister von Freezedale
3. Ein „Dieser Artikel“ bei allen Bürgermeistern, der auf die BKL linkt

Nochmal ein Ping an alle Diskussionsbeteiligten. Bitte meldet euch, ob das so in eurem Sinne ist. ^^ Isso08-15, Killuu, Mecanno-man -- ~~ feblue 10:50, 2. Jun. 2022 (CEST)

Jup. --Toben des Meeres. Killuu 15:39, 2. Jun. 2022 (CET)

Die Bürgermeister-BKL wurde in den letzten Tagen umgesetzt und ist somit erledigt. -- ~~ feblue 01:23, 13. Jun. 2022 (CEST)

Schadensklasse umbennen

Mir fiel vor einiger Zeit auf, dass Schadensklasse in den Spielen eigentlich Kategorie genannt wird. (Ich habe nicht mal gefunden, wann es je Schadensklasse hieß.) Ich suche nun nach einem sinnvollen Artikelnamen, da Kategorie auch für andere Sachen benutzt wird. Ihr dürft gerne Vorschläge machen. Das Isso 08/15 ^Konter 15:59, 8. Mai 2022 (CEST)

Namenvorschläge:

• Kategorie (Attackeneigenschaft) (in Anlehnung an Stärke (Attackeneigenschaft))

Ich finde den Vorschlag gut. Würde dann aber zeitgleich den anderen Kategorieartikel in "Kategorie (Art)" umbenennen und ne BKL erstellen auf beides. LG --Fliegen bis zum Horizont. Killuu 19:46, 11. Mai 2022 (CET)

Kategorie (Attackeneigenschaft) gefällt mir hier an sich sehr gut. Killus Einwand kann ich auch nur unterstützen. Für mich stellt sich jetzt nur die Frage, wie man dann bei der Umbenennung vorgeht: Weiterleitung oder nicht? Ich wäre gegen eine Weiterleitung und dafür, dass man sämtliche Links, auch wenn es viele sind, entsprechend anpasst, damit der falsche Begriff komplett entfernt wird. -- ~~ feblue 14:30, 22. Mai 2022 (CEST)

Wenn was falsch ist sollte es weg. --Mecanno-man^Mäh 16:28, 22. Mai 2022 (CEST)

Damit dieser Punkt nicht im Sand versinkt, gibts mal einen Ping an die betroffenen Projekte: Attacken-PLs (DeXter & Mooni000), Spiele-PLs (DieTaube & RobbiRobb), Pokédex-PLs (Maxmiran & Vircaprae) und die Admins, die bisher nicht gepingt wurden (GoPika, Mecanno-man & ShortyBuzz), weils tausende Artikel betrifft. Folgende Punkte sind umzusetzen:

1. Verschiebung von Schadensklasse nach Kategorie (Attackeneigenschaft)
2. Verschiebung von Kategorie nach Kategorie (Art)
3. Kategorie wird BKL für Kategorie (Art) und Kategorie (Attackeneigenschaft)
4. Links in sämtlichen Vorlagen und Artikeln werden angepasst, sodass Weiterleitungen nicht nötig sind

Bitte meldet euch bei Einwänden oder Fragen. Wenn bis 08.06. 16 Uhr kein Einwand kam, werde ich mich mit Isso08-15 zusammensetzen und die Umsetzung besprechen. -- ~~ feblue 15:17, 1. Jun. 2022 (CEST)

Generelles Pro von meiner Seite, bin aber mit dem Klammerzusatz "(Art)" nicht 100 % zufrieden... denke sowas wie "Kategorie (Pokémon)" wäre treffender; Art ist ja im Grunde genommen ein Synonym von Kategorie, was nicht dabei hilft die Begriffe zu differenzieren. --Mecanno-man^Mäh 22:14, 1. Jun. 2022 (CEST)

Hätte mein Pro. -- ~~ feblue 10:13, 2. Jun. 2022 (CEST)

Wenn man sich die Google-Ergebnisse anschaut, muss man wirklich zugeben, dass sich leider Gottes „Schadensklasse“ bei den meisten Pokémon-Fans (warum auch immer) falsch eingebürgert hat. Man findet mehr unter Schadensklasse als unter Schadenskategorie. Dennoch muss man dazu sagen, dass Schadensklasse schlichtweg falsch ist, ich allerdings eine Weiterleitung oder BKL begrüßen würde. Mec‘s Vorschlag hätte mein Pro. Blazery 11:01, 2. Jun. 2022 (CEST)

Ich muss zustimmen, dass der Artikel dann vielleicht über die Suche erstmal nicht auffindbar ist, weil man die Umbenennung noch nicht mitbekommen hat, aber ich finde, dass wir den falschen Begriff nicht behalten sollten, auch nicht als WL. -- ~~ feblue 11:13, 2. Jun. 2022 (CEST)

Dem schließe ich an. Viele werden vielleicht sogar sowieso eher Status, Spezial oder Physisch suchen, daher sehe ich dieses Problem als gering an. Das Isso 08/15 ^Konter 11:18, 2. Jun. 2022 (CEST)

Pro zu dieser Initiative, eure Argumente sind gut nachvollziehbar! Nur den Klammerzusatz (Art) finde ich unpassend, da schließe ich mich Mec an. "Pokémon" finde ich okay. Wenn man es gaz parallel zu Attacken machen möchte, dann vielleicht "Pokémon-Eigenschaft". Maxmiran 13:59, 2. Jun. 2022 (CEST)

Pokémon alleine fände ich etwas unkonkret. Hätte jetzt auch in die Richtung von Max gedacht. Tatsächlich habe ich kein vergleichbares Beispiel gerade gefunden. --Toben des Meeres. Killuu 15:37, 2. Jun. 2022 (CET)

Gegen die Verschiebung von "Schadensklasse" habe ich nichts einzuwenden, aber ich würde sagen dass man "Kategorie" nicht verschiebt und stattdessen mit Vorlage:Dieser Artikel arbeitet. – Vircaprae 10:25, 3. Jun. 2022 (CEST)

An sich fände ich auch das nicht verkehrt. Das würde den jetzigen Artikel "Kategorie" meiner Meinung nach nur über den anderen Artikel stellen. Da das allerdings persönliches Empfinden ist, will ich mal auf andere Meinungen warten. -- ~~ feblue 10:57, 3. Jun. 2022 (CEST)

Schadensklasse ist ein Begriff seit über 20 Jahren. Ich finde der Begriff sollte definitiv ins Fandom aufgenommen werden wo er erklärt wird mit der Verlinkung zum richtigen Titel. Ihn einfach unter den Teppich Kehren wäre massiv Userunfreundlich. Schließlich haben bei bei Basiswerte auch entschlossen den Usern einen Hinweis zu geben. Ansonsten der Auszug aus dem Lösungsbuch. Dort ist Pokémon-Art = Bisasam, Glumanda etc. und Art oder Kategorie = Samen-Pokémon usw. Folglich finde ich Kategorie (Art) völlig passend. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:52, 3. Jun. 2022 (CEST)

Gute Ergänzung mit dem Lösungsbuch. Würdest du dir dann konkret Schadensklasse als WL auf Fandom#Schadensklasse vorstellen können und dort ist dann mit Vorlage:Hauptartikel und einer Erklärung Kategorie (Attackeneigenschaft) verlinkt? -- ~~ feblue 14:10, 3. Jun. 2022 (CEST)

In Fandom? Sollen da nicht nur sachen hin, die gar keinen offiziellen Namen haben? Denke eine direkte WL nach Kategorie (Attackeneigenschaft) wäre sinnvoller. --Mecanno-man^Mäh 09:39, 4. Jun. 2022 (CEST)

Der Einleitung zufolge würde ich sagen, dass Schadensklasse genau dahin gehört, weil es eben ein Begriff ist, den wir nirgends in den Spielen auffinden konnten. Folglich muss der irgendwo anders herkommen und da er von Fans ja doch häufig benutzt wird, bietet sich die Einbettung in Fandom an. -- ~~ feblue 11:57, 4. Jun. 2022 (CEST)

Ich glaub du hast mich falsch oder nicht gänzlich verstanden; nein, den Begriff gibt es in der Tat nicht. Aber für das Ding an sich haben wir einen Begriff (Kategorie). Dies ist im gegensatz zu all den anderen Sachen im Artikel, wo nicht einmal das Konzept wirklich offiziell ist - Pseudolegendäre Pokémon, Signaturpokémon, Unterlevelung - all die Sachen haben keine offizielle Namen. Da jetzt Sachen hinzuzufügen, die einen Namen haben, Fans aber anders nennen würde nur ein bodenloses Fass aufmachen. --Mecanno-man^Mäh 12:31, 4. Jun. 2022 (CEST)

Die Umbenennung hat mein Pro. Bei "Kategorie (Art)" passt eventuell auch so etwas wie "Kategorie (Pokémon-Gruppe)". Ansonsten würde ich gerne "Schadensklasse" in irgendeiner Weise im Wiki haben, v. a. auch als möglichen Suchweg zu "Kategorie (Attackeneigenschaft)", weil das imo. der aktuell gängige Begriff ist. Wir haben mMn nicht nur das Ziel korrekte Infos anzubieten, sondern diese auch zugänglich und userfreundlich zu machen. Im Endeffekt unterscheidet uns Letzteres von einer rohen Datenbank. (mal schauen wie viele Doppelpunkte wir hier noch hinkriegen) --DeXter 22:43, 4. Jun. 2022 (CEST)

Hm, dann hatte ich das doch teils so verstanden, wie du das gemeint hast, Mec. Der Link auf Fandom wäre dann ja quasi ein Suchweg. Könnten wir nicht an der Stelle einfach sagen, dass in Fandom generell Fanbegriffe landen? Wir haben ja sogar Artikel unter diesen Begriffen, also wäre es doch nicht verkehrt, den Fanbegriff als WL auf Fandom zu einem Abschnitt mit dem korrekt verlinkten Titel zu lassen. -- ~~ feblue 23:27, 4. Jun. 2022 (CEST)

Ich würde knallhart den falschen Begriff als WL stehen lassen. Das ist mit Abstand am benutzerfreundlichsten und in die Einleitung packt man dann sowas wie "Kategorie (unter Fans häufig Schadensklasse genannt)...". Ich würde hier Nutzerfreundlichkeit vor "wir verwenden nur offizielle Begriffe als Lemma" stellen. Den aktuellen Kategorie-Artikel nur mit der Vorlage:Dieser Artikel zu ergänzen unterstütze ich übrigens nicht, falls das noch zur Debatte steht, weil dann, wie schon genannt, der eine Begriff über dem anderen stehen würde. Das fände ich an der Stelle nicht korrekt, beide sind aus meiner Sicht gleich viel "wert". --Kein Dschungel zu dicht... Killuu 23:35, 4. Jun. 2022 (CET)

Siehe Killuu; ich bin aber zusätzlich gegen den Umweg über Fandom, da das ein konzeptionell neues Fass aufmachen würde (nämlich das wir da jegliche Fanbegriffe drin hätten und nicht nur die, die wir im Wiki mangels offiziellem Begriff nutzen) --Mecanno-man^Mäh 01:27, 5. Jun. 2022 (CEST)

Sollten sich nicht etablierte Fanbegriffe so oder so im Wiki befinden? Mir ist egal ob es als WL bleibt oder unter Fandom kommt (was ich sinnvoller zwecks Erklärung fände). Ich bin lediglich gänzlich dagegen den bisherigen Begriff unter den Teppich zu kehren. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:19, 5. Jun. 2022 (CEST)

Hm, ich kann sowohl die eine als auch die andere Seite verstehen; Wir sind ein Wiki, sollten eigentlich seriös sein und ausschließlich die richtige Bezeichnung hier im Wiki haben. Aber man muss sich doch wirklich eingestehen, dass so gut wie jeder Spieler es nur über Schadensklasse kennt und wenn wir das dann plötzlich ändern ohne Weiterleitung o.ä. könnte es passieren, dass die Nutzer es bei uns suchen, nicht mehr finden und dann zu einem der deutlich schlechteren Mitbewerbern gehen, um Infos zu bekommen. Und ich denke gerade das sollte vermieden werden, auch wenn es offensichtlich falsch ist & durch eine Weiterleitung auf die richtige Bezeichnung werden es dann immer mehr Nutzer realisieren, dass es Kategorie heißt, und in paar Jahren könnte man dann ja eventuell auch die Weiterleitung entfernen. ༺ Blazery ༻ ^talk 17:30, 8. Jun. 2022 (CEST)

Dann bleibt von mir aus die WL stehen, wenn Fandom nicht der Ort dafür zu sein scheint. Für den Artikelnamen haben wir jetzt verschiedenste Vorschläge: Kategorie (Art) (wäre das nächste zum Lösungsbuch), Kategorie (Pokémon), Kategorie (Pokémon-Eigenschaft) oder Kategorie (Pokémon-Gruppe). Ich fände hier ersteres am passendsten. -- ~~ feblue 21:39, 8. Jun. 2022 (CEST)

Da jetzt länger keine Rückmeldung kam, setze ich eine erneute Frist auf den 23.06. 11 Uhr. Folgendes ist jetzt der Endstand:

1. Verschiebung von Schadensklasse nach Kategorie (Attackeneigenschaft)
2. Verschiebung von Kategorie nach Kategorie (Art)
3. Kategorie wird BKL für Kategorie (Art) und Kategorie (Attackeneigenschaft)
4. WL Schadensklasse bleibt für die Erreichbarkeit des Artikels bestehen

-- ~~ feblue 11:45, 16. Jun. 2022 (CEST)

Ich bleibe dabei, dass mir Kategorie (Art) nicht wirklich gefällt. Wie wäre es mit „Pokémoneigenschaft“ paralell zu Atatckeneigenschaft? --Mecanno-man^Mäh 21:39, 16. Jun. 2022 (CEST)

Von mir aus gerne. -- ~~ feblue 10:58, 17. Jun. 2022 (CEST)

Ich wäre weiterhin dafür, "Kategorie" nicht zu verschieben und stattdessen Vorlage:Dieser Artikel zu nutzen. – Vircaprae 19:02, 17. Jun. 2022 (CEST)

@Vircaprae: Ich verstehe noch nicht ganz, welchen Vorteil das bringen soll, außer dass wir uns auf keinen Klammerzusatz einigen müssten? Inwiefern ist der eine Kategorie-Artikel dem anderen übergeordnet? Ich glaube, eine Begründung deiner Meinung würde für die Diskussion hilfreich sein. Lg --Killuu 10:44, 19. Jun. 2022 (CEST)

Naja, so viel gibt es da nicht zu sagen. "Kategorie" hat halt mMn eine deutlich höhere Relevanz als die Attackeneigenschaft und von den vorgeschlagenen Klammerzusätzen finde ich auch keinen wirklich passend. Außerdem ist es für die Verschiebung von "Schadensklasse" ja egal, weil die Seite sowieso einen Klammerzusatz braucht. – Vircaprae 20:13, 20. Jun. 2022 (CEST)

Ich würde hier in die entgegengesetzte Richtung argumentieren: Kategorie/Art ist nur dekorativ im Pokédex, während die Attackeneigenschaft eine fundamentale Eigenschaft des Kampfsystems ist. Dementsprechend ist für mich die Attackeneigenschaft wichtiger als die Pokémoneigenschaft. Was wichtiger ist ist aber imo. sehr subjektiv, jemand der z. B. nur den Anime schaut wird die Attackeneigenschaft überhaupt nicht interessieren. Da es hier aus meiner Sicht keine Einigung geben kann was wichtiger ist ist mMn. eine BKL am sinnvollsten. --Mecanno-man^Mäh 21:57, 20. Jun. 2022 (CEST)

Es gibt ja z. B. auch Pokémon-Trainer und Pokémon-Trainer (Trainerklasse). Da ist aber der Klammerzusatz deutlich der Trainerklasse zuzuordenen, da diese unbedeutender ist (der erste Artikel ist merklich ausbaufähig, aber das ist ein anderes Thema). Verschieben von Schadensklasse allgemein: Pro von mir aus, da es offensichtlich der offizielle Name ist. BKL für Kategorie, genauso wie die WL von Schadensklasse sind ebenfalls fein. Ist auch nicht die erste "Fan-WL", die wir haben. Klammerzusatz Attackeneigenschaft passt denke ich. Art und Pokémoneiegnschaft für die andere Kategorie ist auch beides gut, daher ist das finde ich schwer zu entschieden. Ich denke aber, Pokémoneigenschaft ist etwas treffender. Beide Artikel sollten dann vermutlich noch ein {{Dieser Artikel}} mit einem Link auf die BKL oder den anderen Artikel erhalten. -- Cliffichen 16:53, 21. Jun. 2022 (CEST)

Gibt es noch Einwände oder weitere Meinungen? -- ~~ feblue 00:53, 26. Jun. 2022 (CEST)

Ich setze mal eine erneute Frist auf den 20.07. um 16 Uhr, da hier seit drei Wochen nichts passiert ist und so langsam eine Entscheidung gefällt werden muss. Das Ergebnis ist wie folgt:

1. Verschiebung von Schadensklasse nach Kategorie (Attackeneigenschaft)
2. Verschiebung von Kategorie nach Kategorie (Pokémoneigenschaft)
3. Kategorie wird BKL für Kategorie (Pokémoneigenschaft) und Kategorie (Attackeneigenschaft)
4. WL Schadensklasse bleibt für die Erreichbarkeit des Artikels bestehen
5. Beide Artikel erhalten ein Dieser Artikel zur BKL

-- ~~ feblue 15:54, 13. Jul. 2022 (CEST)

Die hierüber genannten Punkte sind jetzt umgesetzt. Allerdings hätte ich noch ein Anliegen, das bei der Umsetzung aufgefallen ist. Die drei Weiterleitungen Physisch (Attackeneigenschaft), Status (Attackeneigenschaft) und Spezial (Attackeneigenschaft) habe ich verschoben, in der Klammer stand zuvor Schadensklasse. Die Weiterleitung Schadensklasse war ja für die Erreichbarkeit gewünscht, hier ist es nur ein Klammerzusatz. Jetzt wäre meine Frage, ist das für alle in Ordnung so oder sollten noch Weiterleitungen des alten Namens neu erstellt werden? Ping an alle Diskussionsbeteiligten: Mecanno-man Vircaprae Killuu Cliffichen Isso08-15 Blazery DeXter Ryuichi

Sofern ihr nicht antwortet, gehe ich davon aus, dass ihr das so in Ordnung findet. -- ~~ feblue 02:19, 25. Jul. 2022 (CEST)

Ich sage einfach mal why not? Es sind denke ich keine notwendigen WLs, also ich könnte auch drauf verzichten, aber wie gesagt, why not. -- Cliffichen 09:24, 25. Jul. 2022 (CEST)

Mir wars bloß wichtig, dass man über den Begriff "Schadensklasse" auf den richtigen Pfad kommt. Die WLs können gerne dazukommen, brauchts imo. aber nicht dringend. Bin gleicher Meinung wie Cliffi. --DeXter 14:56, 28. Jul. 2022 (CEST)

Ich sehe keinen Grund dafür, diese Weiterleitungen wieder anzulegen. Klar, sie schaden auch nicht, aber ich denke, dass kaum jemand nach diesen Begriffen suchen würde, vor allem weil Physisch, Spezial und Status ohne Zusätze bereits als Weiterleitungen bzw. Begriffserklärungen existieren. Und sollte doch mal jemand diese Begriffe eingeben, würde er über die Suche schnell die richtigen Artikel finden (siehe Suche nach Physisch (Schadensklasse), Spezial (Schadensklasse) und Status (Schadensklasse)).
Da finde ich es viel wichtiger, die Weiterleitungen Physisch (Kategorie), Spezial (Kategorie) und Status (Kategorie) neu anzulegen oder die Weiterleitungen mit dem Attackeneigenschaft-Zusatz dorthin zu verschieben, weil "Kategorie" (und nicht "Attackeneigenschaft") die offizielle Bezeichnung dafür ist, was "Physisch", "Spezial" und "Status" in diesem Zusammenhang sind. --Lasagne (Diskussion) 10:00, 31. Jul. 2022 (CEST)

Bild Zuschnitt und andere Bearbeitungen bei Artworks

Wie gewünscht hier die Eröffnung des Beitrages wo es um die Grundfrage geht. Braucht es Artworks in x-tausendfacher Auflösung die nirgendwo im Wiki genutzt wird oder würde es reichen die einheitlichen Bilder von zokan in 570x570 zu nehmen. Wenn es die riesen Bilder braucht (warum auch immer) sollen diese verfälscht werden (es macht keinen unterschied ob 1 Pixel oder 100. Eine generierte Abweichung von der Releasedatei ist und bleibt eine Abwichung. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:40, 5. Jun. 2022 (CEST)

Um hier erstmal mehr Kontext zu geben: Auf Discord ging es darum ob wir bei den Hauptartwork-Artworks, die seit der achten Generation bei jedem Presserelease auf dem nicht-Japan-Presseserver weiße Ränder um das Artwork herum haben, diese entfernen sollten oder nicht. Die Überschrift ist dementsprechend nicht ganz so genau wie sie sein sollte.

Um jetzt die Fragen zu beantworten: Ich finde schon, dass es vertretbar ist diese weißen Ränder bei den großen Artworks vom Presseserver zu entfernen. Die Verwendung von großen, angepassten Artworks (in Richtung 4-10 Mega-Pixel) hat für mich mehrere Gründe: Zum einen erhalten wir auch vor der Veröffentlichung der kleinen, cleanen Artworks auf den Pokédex-Seiten (pokemon.com/zukan.pokemon.co.jp etc.) die Einheitlichkeit zu den älteren Artworks (vor Gen 8), da diese nie einen Release mit den Rändern hatten. Wenn ich das richtig in Erinnerung habe, haben die Artworks, die aus den weitaus geschützteren japanischen Presserleases kommen ebenfalls keine weißen Ränder. Zum anderen sehe ich keinen Grund warum wir, wenn wir große Artworks zu Verfügung haben, diese nicht auch nutzen sollten. Ja ich weiß, dass diese in den allermeisten Artikel nicht größer als 200 bis 300 Pixel eingebunden werden und dass dann auch die kleinen reichen würden, jedoch Verwenden auch einige Leute von außerhalb des Wikis die Artworks, die wir im Wiki hochgeladen haben, darunter für Fanarts, Thumbnails auf YouTube und aber auch gerade wir selber als Wiki für Posts auf Social-Media-Kanälen oder zum Beispiel auch für das Weihnachts-Gewinnspiel 2020. Das sind zwar nicht alles direkte Nutzen für uns als Wiki selber, jedoch binden wir so auch Besucher an uns indem wir eben diese großen Artworks im Wiki haben. Auch Abseits der Weiterverwendung der Bilder ermöglicht das einigen Leuten die Bilder im Wiki vergrößert anzuschauen und so genauere Details sehen zu können als bei einem Bild, dass nur knappe 600 mal 600 Pixel groß ist. Für mich sind das schon Gründe warum das Entfernen des weißen Randes kein Problem darstellen sollte. Wenn es ordentlich gemacht wird, wird das eigentliche Artwork mit dem schwarzen Rand auch nicht verändert, und wir wissen ja eigentlich auch, dass der weiße Rand nur etwas ist um ne zusätzliche Angrenzung der Artworks zu schaffen. Also sehe ich ehrlicherweise nicht, warum wir den nicht auch entfernen dürfen, wenn er eben nicht zum Artwork selbst gehört. Und wenn es um das generelle Anpassen von Bildern geht, dass können wir auch gleich den gesamten TCG-Bereich löschen gehen, weil die Rohdateien aus dem TCGO eben auch nicht die Kartenform haben sondern nach bestimmten Regeln vom Programm (und dann später von uns fürs Wiki) zugeschnitten werden. Ebenso haben anderen Bereiche, auch das Orte-Projekt, Dateien wo der Whitespace entfernt wurde. GrollenKette951 19:18, 5. Jun. 2022 (CEST)

Erstmal danke an GrollenKette das er mehr kontext niedergeschrieben hat hat.

Zunächst einmal möchte ich erwähnen, das ich die überschrift sehr bevorteilend für ryuichi geschrieben finde. Es hätte neutral gehalten werden sollen.

Die (in meinen Augen) beschuldigung, das hier Bilder verfälscht werden, muss mit vorsicht betrachtet werden, denn es werden keine bilder verfälscht.

Wie GrollenKette bereits geschrieben hat, es werden die weißen ränder der Pokémon Artworks entfernt welche von den nicht Japanischen Presseseiten stammen.

Es ist so das auf den nicht japanischen Presseseiten die offiziellen Artworks welche einen Transparenten hintergrund haben, einen sogenannten Glow effekt erhalten um diese auf den presse seiten besser darzustellen. Dadurch entsteht eine Weiße rahmen linie um das offizielle Artwork herum. Sogesehen erhalten wir vor release der Spiele keine offiziellen Original Artworks, sondern bereits mit einem Gloweffekt versehene Presse Artworks. (also bereits bearbeitete Artworks)

Erst wenn die Spiele offiziell veröffentlicht werden, findet man die offiziellen Artworks ohne Gloweffekt, also mit Transparentem freiem Hintergrund auf Webseiten wie z.b. der offiziellen Pokémon Seite (Pokemon.com). In ihrem offiziellen Pokedex, sind die offiziellen Artworks hinterlegt. Allesamt ohne Gloweffekt.

Darüber hinaus, werden die Offiziellen Artworks ausschließlich, auf den besser geschützten japanischen Presseseiten ohne Gloweffekt also im originalzustand veröffentlicht.

Doch diese sind wie gesagt geschütz.

GrollenKette nimmt sich die Zeit und nimmt die mühe auf sich den Weißen Rand (der dem Gloweffekt entsprang und nicht zum offiziellen Artwork dazu gehört) zu entfernen. Um uns allen das bestmögliche Angebot zu bieten, welches eben vor Release der neuen Spiele möglich ist.

Zudem stört sehr viele, ein Weißer Rand da dieser auch Optisch im Infokästchen negativ auffällt.Denn alle bisherigen Artworks haben ebenfalls keinen Weißen Rand mehr. Die Einheitlichkeit sollte man zudem also auch bedenken, da eine einheitliche handhabung Professioneller wirkt.

Zweitrangig für das Wiki, aber finde ich nicht zu verachten, ist das die Artworks ja auch weiterverwendet werden z.b. Youtuber für ihre Thumbnails, Kreative Hobby-Programmierer die ihren eigenen Pokedex für private zwecke schreiben wollen oder aber auch einfach Hobby- Künstler die sich die offiziellen Artworks zur brust nehmen, um ihnen die Shiny-Pokemon farben zu geben und wirklich gute Fanarts herbei zaubern.

Deswegen verfälscht Grollenkralle hier keineswegs die offiziellen Artworks. Vielmehr ist der Gloweffekt das, welches das Artwork verfälscht.

Aus diesem Grund/Gründen finde ich ist es legitim, den Weißen Rand zu entfernen.

Desweiteren wurde die frage gestellt, wofür man die großen Artworks auf den Datai-Seiten bräuchte. Man möchte keinen Pixelbrei wegen eines Zoomeffekts

Ich habe mir die großen Artworks angeschaut und diese wurden keineswegs herangezoomt, es gibt keinen Pixelbrei. Es sind schlichtweg Saubere Artworks nur einfach in größer als die der Infobox.

Wie GrollenKette bereits geschrieben hatte, wenn wir die bilder zur verfügung haben, dann sollten wir sie auch nutzen. Denke gerade das kann auch einige neue nutzer anlocken. Nncera (Diskussion) 22:12, 5. Jun. 2022 (CEST)

Was das entfernen des Randes angeht: Ich kann mich da nur anschliessen; generell sollten die Bilder einheitlich sein - insbesondere wenn wir Artworks auf nicht-weissen Hintergründen einbinden, z. B. in Vorlage:Trainerpkmn, sähe es ansonsten komisch aus. Eine Verschiebung in die andere Richtung - alle mit Glow-Effekte - ist nicht möglich, da wir von den meisten Artworks älterer Pokémon keine Versionen mit Glow-Effekt haben. Dementsprechend sollten wir mMn. die Glow-Effekte, wenn keine andere Versionen vorhanden sind, selber entfernen.

Ob wir tatsächlich die riesigen Artworks vom Presseserver brauchen stelle ich eher in Frage - die Versionen von pokemon.com scheinen mir in ihrer Grösse gross genug und haben den Vorteil, das wir da nicht selber etwas dran verändert haben, wo wir möglicherweise unentdeckt Fehler gemacht haben (ich erinnere mich da z. B. an eine alte Version der Logos von Pokémon XD, das schlecht bearbeitet wurde aber trotzdem relativ lange im Wiki war). Zudem sei hier gesagt, das wir z. B. im Anime-Bereich bewusst auf hohe Bildqualität verzichten - generell sind die Screenshots da nicht 1080p, obwohl dies technisch nicht schwer zu realisieren wäre?. Ich glaube aber auch, hier liegt eine grundlegende Definitionsfrage vor, ob das Bild an sich ein Endprodukt ist, oder ob es nur dazu dient Artikel aufzuschmücken. Mit der aktuellen Handhabung tendiere ich zu nein, denn würde man das Bild auch als Endprodukt ansehen würde wäre das weglöschen unbenutzter Dateien nur weil sie unbenutzt sind ein Informationsverlust. Ich habe allerdings noch nie jemand dagegen argumentieren sehen, der nicht zumindest irgendwie vor hatte die Bilder wieder zu verwenden.

That said, ich bin mir auch etwas unschlüssig, ob man die bearbeiteten grossen oder eher die unbearbeiteten kleinen im Wiki haben sollte, tendiere aber aktuell eher zu den kleinen. --Mecanno-man^Mäh 23:49, 5. Jun. 2022 (CEST)

Bearbeitete (mit Verlusten an Pixeln) Artworks die fürs PokéWiki übernatürlich gross sind und nirgends die Grösse eine Verwendung findet VS. Unbearbeitete, gut grosse Artworks die fürs PokéWiki vollkommen ausreichend sind.

Ich bin ganz klar für das zweitere, da ich finde ein Wiki sollte mit den seriösten Quellen arbeiten und auch die Dateien anbieten in der best möglichen offiziellen Form, daher finde ich die zukan Artworks super. Dazu muss man sagen, um die 80% der Galar-Artworks sind von zukane, diese bearbeiten Artworks machen nur einen kleinen Teil aus und sind daher unnötig, da es nicht mal riessige Artworks für alle Pokémon gibt. Ich frag mich auch, könnte es nicht rechtlich dem Wiki Probleme verursachen, wenn wir Bilder vom Presseserver nehmen und diese dann bearbeiten, da sie ja nicht vorhergesehen sind ohne Rand mhhh... --Jass 00:23, 6. Jun. 2022 (CEST)

Was den rechtlichen Aspekt angeht ist das im Zweifel sowieso egal, da wir als Wiki hier ja sogesehen fast nur Bilder nutzen, die uns nicht gehören und für die TPC/TPCi das Wiki einfach aus dem Weg räumen könnte.

Ich verstehe zwar, dass eine gewisse Angst besteht, dass die Artworks vom Presseserver beim Entfernen des weißen Randes zu sehr verändert werden, jedoch passe ich da schon sehr stark drauf auf und schaue ob ich nicht doch an irgendeiner Stelle was wichtiges vom Artwork kaputt mache. Dann beginnt der Spaß die Stelle separat noch vorsichtiger anzufassen. (Das XD-Logo sieht danach aus, dass da eben jemand keinen Plan davon hatte.) Ja, die Artworks, die von pokemon.com/zukan.pokemon.co.jp kommen sind in ihrere Größe für die Einbindung innerhalb der Artikel mehr oder weniger ausreichend, jedoch sehe ich da trotzdem das angesprochene Problem, dass die Dateien auch von außerhalb für verschiedenes benutzt werden eben weil die Dateiseiten auch so eine Art Archiv an Artworks darstellen. Und das finde ich ist mehr oder weniger auch ein "Service" des Wikis Artworks in einer größeren Größe zu haben, sei es zum Anschauen oder für andere zum Weiterverwenden. (Um da direkt ein Beispiel zu geben: Die TCGO-Scans. Davor hatten wir diese kleinen Bilder von der offiziellen Seite, die nur bedingt zu lesen waren wo auch das Artwork mehr Matsch als alles andere war. Jetzt mit den neuen Dateien kann man sich auf der Dateiseite die Artworks (und zur Not den Text) in einer hohen Auflösung anschauen.) Wie gesagt, wenn man mit den Bildern vorsichtig und gewissenhaft beim Bearbeiten umgeht, sollten auch keine "umbringenden" Fehler passieren, weil irgendwo was fehlt. Mit den richtigen Einstellungen wird nur der weiße Rand entfernt und mehr dann auch nicht. Neben dem Zuschneiden passieren keine anderen Veränderungen mehr an der Datei. Keine Farbanpassungen etc und auch nichts anderes. GrollenKette951 07:08, 6. Jun. 2022 (CEST)

pwtable1 und rowspan

pwtable1 ist unsere CSS-Klasse für eine moderne Tabelle, da diese allerdings den Hintergrund zwischen weiß und grau abwechselt, kommt es zu Problemen, wenn man einen geraden rowspan hat, da dann weiß auf weiß bzw. grau auf grau folgt. Dadurch lässt sich nicht mehr so gut erkennen, welche Zellen zu welcher Zeile gehören, siehe dazu dieses Bild von Serpi. Ich hatte daher zwei Lösungen bereitgestellt, die besagtes Problem lösen, eine erzeugt eine durchgezogene Linie unter der Zeile und die andere erzeugt diese Linie nur dort, wo auch wirklich gleiche Farben aneinander treffen. Ich mache hier jetzt keine Abstimmung draus, weils dafür zu klein und unwichtig ist, will aber primär einfach nur Meinungen und da jetzt keine ausartende Diskussion draus machen. Und da das bereits mehrfach versandet ist, gibts auch nur ne Woche Zeit, bis zum 19.06.2022, um 18:00 Uhr. Sollte sich zeigen, dass das nicht reicht, weil doch irgendwas aufkommt, können wir die Zeit gerne verlängern, aber ich denke, das sollte ausreichen, um genug Meinungen zu sammeln, um hier eine Entscheidung zu treffen. Also bitte, her mit Meinungen. -- RobbiRobb 18:31, 12. Jun. 2022 (CEST)

Wenn es eine Linie geben soll (die ich eigentlich für nicht benötigt halte, da die Tabelle ne Hoveranimation hat, die dieses Problem für mich schon löst), dann bitte auch durchgezogen. -- ~~ feblue 18:50, 12. Jun. 2022 (CEST)

Copy & Paste von Discord: Wenn Linie, dann auch über die gesamte Breite. GrollenKette951 21:34, 12. Jun. 2022 (CEST)

Musste den Text lesen um den Unterschied überhaupt zu bemerken, demnach von mir aus egal welche Version. Beide sind mMn. besser als der Status Quo. --Mecanno-man^Mäh 00:15, 13. Jun. 2022 (CEST)

Bin auch der Meinung, dass durchgezogen eindeutig besser aussieht. Und zu Fes Meinung mit der Hoveranimation: Auf den ersten Blick sieht es ziemlich unübersichtlich aus und bis du es gesagt hast wusste ich nicht einmal, dass es sie gibt, womit ich sicher nicht alleine bin. Vor allem Mobil ist das ziemlich unintuitiv, man müsste schon eher durch Zufall draufklicken. BlauesSerpiroyal ^Diskussion 21:53, 15. Jun. 2022 (CEST)

Eine Trennlinie macht das ganze übersichtlicher. Bitte ganz durchgezogen, das ist wesentlich konsistenter zum Rest und sieht auch besser aus. -- Cliffichen 22:01, 16. Jun. 2022 (CEST)

Kann mich den anderen nur anschließen, ggf. sollte man überlegen, die sanfte Linie dann sogar immer zu ziehen und nicht nur in den rowspan-Fällen. Lg --Und dann im Mondschein... Killuu 11:05, 19. Jun. 2022 (CET)

Da hier einstimmig für eine durchgezogene Linie gestimmt wurde, ist das nun entsprechend umgesetzt. -- RobbiRobb 19:28, 20. Jun. 2022 (CEST)

Sinn von pwtable1

Warum benutzen wir überhaupt pwtable1? Ich finde es absolut als unnötig Tabellen zu haben mir abswechselnden Farben und ich finde auch, ess macht alles unübersichtlicher wie bei eurem Problem, da man nicht sofort dadurch erkennt was, zu was gehört. Finde daher, wir sollten im Wiki lieber ganz auf pwtable1 verzichten, da ich nicht wirklich Vorteile darin sehe es zu benutzen, da die meisten Tabellen im Wiki halt auch normale Tabellen sind. --Jass 21:46, 12. Jun. 2022 (CEST)

Sorry, aber ich schieb das in einen eigenen Abschnitt, egal was dann aus der Diskussion wird. Ich hab keine Lust, dass die eigentliche Diskussion wieder völlig abdriftet. Ich bin gerne dafür offen, dass hier drüber diskutiert wird, aber bitte nicht im selben Zug wie einfach nur eine simple Design-Frage. Sollte man sich dazu entscheiden, pwtable1 gänzlich aus dem Wiki zu entfernen, kann man das natürlich machen, aber das ist jetzt erst mal für die Frage, ob wir ne Linie da haben wollen oder nicht völlig irrelevant. -- RobbiRobb 21:50, 12. Jun. 2022 (CEST)

Ich hätte auch nichts dagegen wenn die Tabelle grundsätzlich entfernt wird, zumindest dort wo sie mit rowspan genutzt wird (und sekundär generell, weil sie ansonsten wieder jemand mit rowspan nutzen wird). Ziel ist es einen guten Kontrast zu schaffen, was zu einer Zeile gehört und was nicht. Hier mit rowspan zu arbeiten erzeugt in diesem Sinn nur Chaos, egal ob mit oder ohne Linie, denn eigentlich sollte die Zeilenfärbung den rowspan beachten um sinnvoll zu sein. So weit ich sehe sollten es höchstens 67 Inhaltsseiten sein, die mit pwtable1 und rowspan arbeiten (Spoiler

Vorlage:PokéWiki:Aktuelles, PokéWiki:Orte-Projekt/Alola, PokéWiki:Orte-Projekt/Einall, PokéWiki:Orte-Projekt/Sevii Eilande, PokéWiki:Orte-Projekt/Hoenn, PokéWiki:Orte-Projekt/Sinnoh, PokéWiki:Orte-Projekt/Kanto, PokéWiki:Orte-Projekt/Johto, PokéWiki:Orte-Projekt/Kalos, Pokémon: Karpador Jump/Musterungen, Pocket Monsters Horizon, Satoshi to Pikachu, PokéWiki:Anime-Projekt/To-Do, Pocket Monsters R/S (Kosaku Anakubo), Systemverwalter, Pocket Monsters (Machito Gomi), Gesichtete Pokémon, Pocket Monsters: Dengeki Pikachu, Liste der spanischen Manga-Bände, Magical Pokémon Journey, Trainer-Individualisierung, Elite-Pokémon, Bericht, Orden, Spezialfähigkeit, Pokémon: Karpador Jump/Züchterrang, Kapsel-Deko, PokéWiki:Spiele-Projekt/Spiele-Artikel, Versteckte Fähigkeit/Fundorte (5. Generation), Versteckte Fähigkeit/Fundorte (7. Generation), Schaden, Entwicklung, Liste der speziellen Entwicklungen, Gehorsam, Versteckte Fähigkeit/Fundorte (6. Generation), Spezialattacke, Kampfipitis, Rocket-Gamer-Paradies, Zutrauen, Verwirrung, Liste der Pokémon-Spiele, Pokémon-Supermarkt, Wetter, Einkaufszentrum von Hauholi City, Tausch, Pokémon: Karpador Jump/Training, Kampfmetro/Pokémon-Liste, Pokémon: Karpador Jump/Futter, Pokémon: Karpador Jump/Level, Ditto-Chaining, Liste von Entwicklungen, Pokémon: Karpador Jump, Estefan, PokéWiki:Orte-Projekt, Wesen, Versteckte Fähigkeit/Fundorte (8. Generation), PokéWiki:Allgemeine Diskussionsseite, Kategorie, AR-Marken, Prismania-Einkaufscenter, Ei-Zyklen und Ei-Schritte, Ei-Gruppen, Johto, Farbe, Pokémon Gold und Silber (Vorabversion)/Space World 1997, Typenkombination, Fandom

), wobei so wie ich gesucht habe das nicht einmal zwingen in derselben Tabelle ist, was ja kein Problem darstellen würde. Von demher wäre es imo ein vertretbarer Aufwand zumindest die ungünstige Klassenkombination zu entfernen. --Mecanno-man^Mäh 00:15, 13. Jun. 2022 (CEST)

Ich fände es schade, jetzt eine der modernsten Tabellenklassen einfach aus dem Wiki zu entfernen, wo wir gerade dabei sind, alte Überreste im Zuge der Mobilumstellung abzuschaffen, aufzuräumen und neu zu designen. Das Entfernen dieser Klasse kommt dem nicht wirklich entgegen. -- ~~ feblue 00:26, 13. Jun. 2022 (CEST)

Bin auch ziemlich dagegen, pwtable1 abzuschaffen, da er meiner Meinung nach vor allem mit einer Trennlinie einfach auf den ersten Blick in viielen Fällen viel übersichtlicher und schöner als eine normale Tabelle ist. BlauesSerpiroyal ^Diskussion 21:53, 15. Jun. 2022 (CEST)

Ich mag diese Art der Tabelle, die abwechselnden, leichten Farben sehen hübsch aus, wesentlich besser als diese Standard grauen Tabellen, die sehen aus wie aus dem letzten Jahrtausend. Ich würde es daher Schade finden, wenn sie gelöscht werden würde. -- Cliffichen 22:01, 16. Jun. 2022 (CEST)

An sich mag ich diese Farbwechseltabellen nicht so gerne, das ist halt subjektives Empfinden. Eben auch, weil es dann so doofe Sonderfälle wie rowpan gibt, das Problem hatte ich schon an der Arbeit und irgendwie sind alle Umwege immer nicht ganz das Wahre. Ich finde aber beispielsweise die Tabellen aus den Pokémonartikeln super schick und auch modern. Insgesamt würde es sicherlich optisch gut und professionell wirken, wenn man sich im Wiki auf ein Tabellendesign festlegt. Was natürlich wieder eine neue Diskussion wäre, aber ich wollte es mal hier anmerken. Lg--Und dann im Mondschein... Killuu 11:05, 19. Jun. 2022 (CET)

In welche Spielgeneration gehört das Sammelkartenspiel Online?

So jetzt komme ich auch endlich mal zu diesem Thema, das schon ein ganzes Stücken offen rumliegt. Bereits vor mehreren Monaten ist mir aufgefallen, dass wir das TCGO aktuell in der vierten Spielgeneration listen, obwohl es nach Schwarz und Weiß erschienen ist. Aufgrund dessen habe ich das Thema mit Mec diskutiert, leider sind wir dennoch nicht auf eine gemeinsame Meinung dazu gekommen und haben uns deswegen dazu entschieden das Thema über eine Abstimmung auf der AD zu regeln (nun hier isse jetzt mal nach der ganzen Zeit). Im folgenden sind einzelne Argumente für die drei verschiedenen Abstimmungsmöglichkeiten gelistet:

4. Generation: Das Spiel ist zwar nach Schwarz und Weiß erschienen, enthält aber anfangs nur Karten aus dem HeartGold & SoulSilver-Zyklus, was durch den April-Release (in Deutschland sogar erst im Mai) der Erweiterung Schwarz & Weiß, die den Anfang des BW-TCG darstellt, bedingt ist.

5. Generation: Die erste Version als flash-basiertes Browserspiel erschien am 24. März 2011 und damit in allen Regionen (außer Südkorea) nach dem Release von Schwarz und Weiß. Der Launch der heutigen Version auf der Unity-Engine fand am 15. Mai 2012 statt, was ebenfalls während Generation 5 wäre.

6. Generation: Das TCGO verlässt den Beta-Status im Februar 2015.

Abstimmung

Abstimmung abgeschlossen: Das TCGO wird in die 5. Spielgeneration eingeordnet

Diese Abstimmung dient der Entscheidung über die Einordnung des Sammelkartenspiel Onlines in eine der drei gegebenen Spielgenerationen .Jeder stimmberechtigte Benutzer darf eine Stimme abgeben. Die Abstimmung läuft bis zum 28. Juni 2022 um 23:59. Heute ist der 16.04.2024 09:13 Uhr.

Option A: 4. Spielgeneration

1. Aus TCG-Sicht ist der Start von G5 imo. das TCG-Set Schwarz & Weiß. Demnach ist das TCGO, als TCG-Spiel, ein Spiel der vierten Generation. --Mecanno-man^Mäh 23:22, 15. Jun. 2022 (CEST)

Option B: 5. Spielgeneration

1. Meiner Meinung die einzige sinnvolle Möglichkeit, da dies eben genau der Einsortierung aller anderen Spiele entspricht. Strikt nach dem Releasedatum. Nur nach dem Inhalt des Spiels zu Release zu gehen, würde eher Probleme mit sowas wie Remakes machen, die ja in der Theorie Inhalte der Original-Gen in eine andere Generation bringen. Und nach dem Ende eines Beta-Status zu gehen ist auch nicht wirklich sinnvoll, da dieser in den meisten Fällen recht nichts sagend ist und von den Entwicklern genutzt wird um gewisse Vorteile im Play Store/App Store zu erhalten. GrollenKette951 23:00, 14. Jun. 2022 (CEST)
2. Denke auch, dass wir da wie immer nach Release gehen sollten. Dass Anfangs nur die HGSS-Karten da waren sehe ich kritisch, da eben jedes Spiel – egal ob Hauptspiel oder Spin-Off – Inhalte aus vorherigen Generationen nutzt. ~~ DieTaube 07:48, 15. Jun. 2022 (CEST)
3. Ich schließe mich meinen Vorrednern an. Das Release-Datum sollte ausschlaggebend sein. Kernseife ^Diskussion 08:40, 15. Jun. 2022 (CEST)
4. Es sollte nach Release-Datum gehen. ༺ Blazery ༻ ^talk 11:39, 15. Jun. 2022 (CEST)
5. Release-Datum --Poffel — Diskussion 12:39, 15. Jun. 2022 (CEST)
6. Würde da auch nach Release-Datum gehen. Ratequaza 16:07, 15. Jun. 2022 (CEST)
7. Habe da nichts hinzuzufügen Ich kam, sah und bearbeitete Bennett ^Diskussion 17:35, 15. Jun. 2022 (CEST)
8. Im Prinzip halte ich die 5. Generation erstmal für am Sinnvollsten. Wird ja bei Pokémon GO z. B. genauso gehandhabt. Release-Datum in der 6. Gen, aber erstmal nur Pokémon der 1. Gen. Darum sollte TCGO auch zur 5. Gen verschoben werden. Aber die Kommentare unter der Abstimmung sind auch interessant, eine allgemeine Kategorie für diese Spiele wäre auch sinnvoll. Vor allem fehlt da momentan einfach die Einheitlichkeit, wenn wir es so wie bei GO machen, müssten wir TCGO ab Gen 5 in jeder Generation listen, was ich aber auch nicht für die perfekte Lösung für eine Handvoll Spiele halte, zu viele Doppelungen mit der Zeit. Das ist jedoch Teil einer anderen Diskussion. -- Cliffichen 16:19, 22. Jun. 2022 (CEST)
9. Wenn das TCGO schon kurz nach Start wieder abgebrochen worden wäre und nie Sammelkarten aus dem Schwarz & Weiß-Zyklus erhalten hätte, wäre meine Stimme bei der 4. Generation. Allerdings wurden die SW-Karten schon recht früh nach dem Start hinzugefügt und nach dem, was ich bislang gelesen habe, scheint es mir auch so, dass das Spiel erst während des Schwarz & Weiß-Zyklus richtig an Fahrt aufgenommen hat (z. B. mit den QR-Code-Karten, die bei den Sammelkarten zur 4. Generation noch nicht beilagen). Zusammen mit dem den Hauptspielen nach in der 5. Generation liegenden Veröffentlichungsdatum bringt mich das zu der Meinung, dass dieses Spiel hauptsächlich in der 5. Generation eingeführt wurde und dort auch von den meisten Lesern erwartet wird, weswegen wir es dort einordnen sollten. Wenn wir aber irgendwann auf eine Einordnung umsteigen, mit der generationsübergreifende Spiele als solche dargestellt werden, wäre ich nicht dagegen, die 4. Generation als Anfangsgeneration für das TCGO zu wählen. Lasagne (Diskussion) 23:53, 28. Jun. 2022 (CEST)

Option C: 6. Spielgeneration

1. AAWiki ^Diskussion 02:08, 19. Jun. 2022 (CEST)

Enthaltung

1. Ich kann hier keine ordentliche Stimme abgeben. -- ~~ feblue 01:03, 15. Jun. 2022 (CEST)
2. Ich bin der Meinung, da Generationen übergreifende Spiele gerade im Smartphonebereich immer mehr werden sollte langfristig eine andere Lösung her, als die reguläre Einordnung in eine Generation. Als Beispiel wäre eine Kategorie Generationenübergreifend sinnig in der alle aktuell noch laufenden Apps enthalten sind, so als Gedanke. BeyJim ^Diskussion 09:41, 15. Jun. 2022 (CEST)
3. Siehe BeyJim. Generell kann es sowohl option B wie auch C sein alles eine Frage des Blickwinkels. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:22, 15. Jun. 2022 (CEST)
4. Obwohl ich von den drei oben genannten Optionen Option B am sinnvollsten finde, stimme ich BeyJim da zu. Eine Kategorie namens Generationsübergreifend für Fälle wie das TCGO oder GO gut. -MfG, Kenaz-Hagalaz ^Disku 14:41, 15. Jun. 2022 (CEST)
5. Stimme auch am ehesten BeyJim zu, einige solcher Sachen lassen sich vor allem dann durch größere Softwareupdates nicht mehr wirklich in eine Generation einordnen BlauesSerpiroyal ^Diskussion 21:36, 15. Jun. 2022 (CEST)
6. Auch ich würde sagen, dass es echt schwer ist, ein solches Spiel wie TCGO in eine Generation einzuordnen. Generationsübergreifend klingt gut, aber nach dem Release-Datum zu gehen, ist auch sinnvoll. (Der vorstehende nicht signierte Beitrag stammt von: Arkany • Diskussion • Beiträge • Sperren)
7. Ich persönlich enthalte mich, würde aber wenn dann auch am ehesten BeyJims Gedanke befürworten. Vaulty 16:03, 18. Jun. 2022 (CEST)
8. Alle drei Optionen sind für mich keine Option.--Mario-WL (Diskussion) 16:32, 18. Jun. 2022 (CEST)
9. Habe meinen Vorrednern hier nichts mehr hinzuzufügen. MfG Goloer444 20:31, 18. Jun. 2022 (CEST)
10. Sehe genau so wie die anderen. Lunairline^{Buchung zum Mond} 09:56, 20. Jun. 2022 (CEST)
11. Ich halte Gen 5 für die sinnvollste Option, finde aber auch die Idee mit der generationenübergreifenden Darstellung ansprechend. Deshalb wäre ich auch dafür, sich das einmal anzuschauen. DeepSpace (Diskussion) - 22:43, 20. Jun. 2022 (CEST)

Kommentare

Ping an alle SB+: AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, Blazery, DaneeBound, DarkOkto, Der Sternendiamantritter, DomiDsLP, Ediz, Goloer444, Jardan, Jass, Kernseife, Lasagne, DasLunalein, Mario-WL, Nescientist, Panflami, PokéSpe, ScNoni, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Vircaprae GrollenKette951 23:00, 14. Jun. 2022 (CEST)

Ich finde das Generationenkonzept für Spiele, die beständig weiter geupdated werden, schwierig. Ich denke an GO, Masters, UNITE... vielleicht ist hier eine ganz andere Lösung sinnvoll, und diese Spiele gehören in eine ganz neue Kategorie? Maxmiran 11:48, 15. Jun. 2022 (CEST)

Zumindest das TCGO sollte im besten Fall noch innerhalb diesen Jahres eingestampft werden, da ja bereits der Nachfoger, das TCG Live, in einer Kanada- und Mexiko-Beta ist. Damit wäre es keine Spiel mehr, dass noch Updates bekommt und müsste dann trotzdem in eine Gen kommen, wenn ich die Idee der Kategorie für fortlaufende Spiele verstehe. Und ehrlicherweise klingt das wie ein Thema, das in einer eigenen Diskussion im Spin-off-Projekt angesprochen werden sollte und nicht nur hier neben der Abstimmung, wo es im Zweifel nach Beendigung der Abstimmung vergessen wird. GrollenKette951 15:05, 15. Jun. 2022 (CEST)

Ich denke Max meint damit generell alle Spiele, die über einen längeren Zeitraum als nur eine Generation aktiv sind/waren.
Bislang machen wir es ja so, dass wir danach einordnen, in welcher zum Zeitpunkt der Veröffentlichung aktiven Generation sie erschienen sind (oder nicht?). GrüßeShortyBuzz 09:02, 16. Jun. 2022 (CEST)

Passionierte Spieler wissen, dass in Pokémon GO eigentlich nur noch eines an die sechste Generation erinnert: Die Schiller-Sternchen. Stimme demnach BeyJim zu.--Mario-WL (Diskussion) 16:32, 18. Jun. 2022 (CEST)

Die Frage für mich ist, ob wir denn super zwingend alles in Generationen einteilen müssen? Aus meiner Sicht spricht auch nichts dagegen, bestimmte Spin-Offs, wie oben schonmal genannt, einfach nicht in dieses Konzept mit aufzunehmen. In Vorlagen oder auf manchen Seiten könnte man das nur unter "Spiele ohne Generationszuordnung" laufen lassen. Also ergo ist keine Antwort oben für mich zufriedenstellend, auch Enthaltung nicht. Lg --Und dann im Mondschein... Killuu 11:05, 19. Jun. 2022 (CET)

Ich möchte kurz hinzufügen, dass ich die Idee die Spiele generationsübergreifend zu notieren sehr gut und nötig finde. Was ich aber definitiv nicht möchte: Eine Ausgrenzung aus den Generationen. Beispiel: Wir packen sagen wir mal GO, TCGO und Shuffle in einen Toggler namens "Generationsübergreifend" in die Navigationsleiste der Pokémon-Spiele landen. Was würde passieren? Nun bei GO erstmal nichts, GO ist seit Release am gedeihen und alles läuft echt gut. Nehmen wir nun aber mal Shuffle. Shuffle ist aus Gen 6 und hat in Gen 7 seinen Updatebetrieb eingestellt. Damit gehört es definitiv in die 8. Gen nicht mehr, zumal Café Mix dann kam. Aber was wenn dieses Spiel nun in der Navi steht bei all denen, die aktuell noch am laufen sind? Wohl angemerkt nur dieses als Beispiel. Meine Lösung: Meiner Meinung nach sollten in der Navi die Spiele, die weitergeupdatet wurden, in die jeweiligen Gentoggler rein. So steht bspw. GO also sowohl in Gen 6, 7, 8 und sehr wahrscheinlich auch 9 (natürlich bis dato abwartend), aber Shuffle steht dann nur in Gen 6 und 7. Im Artikel selbst kann man das dann auch so anmerken und im Spin-off-Artikel würde ich das aus den Tabellen gänzlich rauslassen, da diese ja wirklich ausschließlich nach Release sortiert ist. Vielleicht wäre da ein Extra-Abschnitt im Artikel angebracht. So lassen sich dann übrigens auch Probleme, wie Beta-Versionen, ganz einfach lösen. Indem man beim TCGO beispielsweise unter Gen 5 schreibt Sammelkartenspiel Online (Beta) und unter Gen 6 dann halt normal das schreibt.... Für was ich aber übrigens wäre, wäre ein Toggler für „nicht zuordnungsbare Spiele“, a la Meisterdetekiv Pikachu 2 und Sleep. Nur, dass mein Standpunkt mal verschriftlicht wurde. Wäre übrigens sehr dafür das als eine Auswahlmöglichkeit hinzuzufügen und die Abstimmung dementsprechend anzupassen. -- MfG, SwowoJonny 17:47, 22. Jun. 2022 (CEST)

Ich werde mich hier wieder wiederholen, aber diese Abstimmung soll nur entscheiden in welche Generation das TCGO mit dem aktuellen Spiele-Nav-System gehört. Genau deswegen werde ich diese Abstimmung auch nicht nachträglich anpassen. Ich bin der Meinung, dass diese grundsätzliche Veränderung der Vorlage auf die Vorlagendiskussion gehört oder im Zweifel auf die des Projektes, aber eben nicht hier hin, wo es erstmal nur um das TCGO geht. Zum Beta-Status des TCGO während Gen 5: Wirklich Beta war dann alles ab dem Unity-Client jetzt nicht wirklich (was das Flash-Game gemacht hat weiß ich nicht). Zumindest nicht in dem Sinne, wie es unser Artikel zu den Vorabversionen (der Beta als WL hat) benennt. Das Spiel war öffentlich verfügbar für alle und nicht nur auf Events oder wie aktuell beim TCGL regional beschränkt. GrollenKette951 18:08, 22. Jun. 2022 (CEST)

Die Verschiebung des TCGO in die fünfte Generation wird innerhalb der nächsten Tage vorgenommen. BeyJim und/oder SwowoJonny werden gebeten ihre Anmerkung bezüglich einer Veränderung der Vorlage auf die Diskussionseite des Projektes oder der Vorlage zu bringen. GrollenKette951 00:10, 29. Jun. 2022 (CEST)

Sortierung der Eventseiten

Aufgrund der Verteilung des schillernden Piepi von heute, was einen recht unegwöhnlichen Verteilungsraum hat, hatte ich eine Eventseite für asiatische Events außerhalb von Japan, Südkorea und China unter dem Namen Events/8. Generation/Asien angelegt damit wir die Infos erstmal im Wiki haben. Im selben Atemzug habe ich aber auf Discord nach Ideen/Meinungen dazu gefragt. Nachzulesen wäre der ganze Spaß hier. Im Laufe der Konversation sind mehrere Varianten in den Raum geworfen worden. Auch kam die Frage auf warum Australien eigentlich eine eigene Seite hat.

Deswegen hätte ich jetzt einen Vorschlag für eine Änderung der Aufteilung der Eventseiten. Aktuell sieht sie wie folgt aus: Japan, Nordamerika, Europa, Australien, Südkorea, China und seit heute für Gen 8 auch Asien. Mein Vorschlag wäre es das ganze wie folgt neu zu sortieren: Japan, Nordamerika, Europa, Südkorea und Sonstige/Weitere. Das würde ich aus folgenden Gründen machen: Wir haben einzelne Events, die nicht wirklich in eine der aktuellen Kategorien passen sowie chinesische Eventverteilungen, die absolut leer wären (Für Gen 8 gibt es nicht mal ne Seite). Die australischen Events sind effektiv eine Kopie der nordamerikanischen mit geringsten Änderungen. Die Seiten für Südkorea sollten meiner Meinung nach erhalten bleiben, da dieser Bereich doch schon eine größere Menge exklusiver Events hat. Die „Weitere“-Seite würde demnach folgende Events enthalten: Events, die im „Pokémon Asia“-Bereich verteilt wurden (Singapur, Thailand, Philippinen, Taiwan, Hongkong etc.), Events aus China sowie Events die komplett exklusiv in Australien stattgefunden haben (hier weiß ich nicht wie viel das überhaupt ist).

Wäre schön hier Meinungen zu dieser Idee zu haben. Da ich das Piepi-Event recht gerne in der nächsten Zeit besser platziert haben will, setze ich hier ein Limit bis zum 25. Juni um 23:59 Uhr. Sollte es in dieser Zeit kein großes negative Feedback zu meiner Idee geben, wird diese nach dem Ablauf der Frist umgesetzt.
GrollenKette951 16:25, 18. Jun. 2022 (CEST)

Ich stelle hier einmal etwas in Frage, was wir ansonsten nahezu nirgends in Frage stellen: Braucht es hier Einheitlichkeit über die Generationen wirklich? Für mich scheint es am sinnvollsten auf technischer Sicht zu schauen, mit welchen Spielversionen das Event empfangen werden kann. Wenn das iwie wie in G4 in Südkorea nur mit der koreanischen Variante geht, dann kriegt Korea ne eigene Unterseite; bei Spielen mit PAL-Versionen, wodurch es möglich is in Europa und Australien dieselben Events z. B. per Internetübertragung zu erhalten, die zusammentun und bei Spielen ohne region-block bei Events statt geographisch nach Art der Verteilung trennen. Australien und China aus Einheitlichkeit zusammenzutun auch wenn die Spiele nicht miteinander kompatibel sind sehe ich jedoch nicht als sinnvoll an. --Mecanno-man^Mäh 16:43, 18. Jun. 2022 (CEST)

Zwingend einheitlich muss das hier nicht bei allen Generationen sein. Was Generation 8 angeht könnte man das tatsächlich auch nach der Verteilungsart aufteilen. Das wären ja dann Passwort/Seriencode (da müsste man schauen ob zusammen oder auseinander) und Internet. Keine Ahnung ob die „Lokal“-Option in Gen 8 genutzt wird. Zu den anderen Generationen: PAL wäre ja dann Europa, Australien, Afrika(?) und Teile Asiens(?)? Da müsste aber wer mit mehr Ahnung schauen, ob das mit den Events tatsächlich die ganze Zeit zwischen Europa und Australien ging und wie das mit irgendwelchen skurillen Asien-Events aussieht. Japan, NA und Südkorea sollten auf jeden Fall ihre Seiten behalten. Wie man dann mit China in Gen 7 umgehen sollte weiß ich nicht. GrollenKette951 17:23, 18. Jun. 2022 (CEST)

Ich möchte mal kurz hier etwas einwerfen. Macht es überhaupt noch Sinn die Events nach Regionen aufzuteilen? Ich meine die meisten Events, die in der letzten Zeit verteilt wurden, waren sowieso weltweit verfügbar. Würde man nicht lieber die Struktur aufbrechen und sie nach z.B. Spielen sortieren. Ich kann mich irren aber meines Wissens nach waren in Gen8 nur ein Regigigas, ein Plinfa und ein hisui-Fukano (Was jedoch zu einem späteren Zeitpunkt nach Deutschland kam.) die nicht für deutsche Spiele erhältlich waren.
So kann erstmal leichter nachverfolgt werden, welche Events übersehen wurden. Auch für die Nutzer des Wikis wäre das evtl. besser nachvollziehbar. Für die wirklich regional geblockten Events konnte man ja z.B. die Flaggen in die Vorlage einbauen. MfG Goloer444 20:31, 18. Jun. 2022 (CEST)

Es geht nicht nur um die neusten, aber ja, das ist im Grunde ja (für die) mein Vorschlag. Dann eben eine Aufteilung nach Art, weils wahrscheinlich ansonsten zu viele sind. --Mecanno-man^Mäh 20:50, 18. Jun. 2022 (CEST)

Von der Konstanz her müssten wir nicht sowieso alle Events dann nach Kontinenten einteilen? Für Asien jetzt 3 Unterseiten zu haben, weil einige Länder einzelne Events haben, finde ich irgendwie komisch. Ich würde dann eben zu der Einteilung nach Kontinenten tendieren und dann einen Parameter einzufügen, in dem man ggf. angeben kann, falls das Event nur in einem bestimmten Land verfügbar war. Lg --Und dann im Mondschein... Killuu 11:05, 19. Jun. 2022 (CET)

Alle Seiten nach Kontinenten aufteilen wird aber im Zweifel nur bedingt funktionieren, weil ja zumindest bei den ganzen Events vor Gen 8 noch ein Regionlock vorhanden war. Du wirst Events haben, die nur mit ner japanischen Version gingen und anderen, die nur mit ner koreanischen Version gingen. Da finde ich die Variante mit, die aktuell im Wiki ist besser. Wenn niemand etwas dagegen hat könnte man (ich) zumindest die 8. Gen in die Unterseiten Seriencode, Passwort und Internetdownload verschieben/aufteilen. Bei den ganzen anderen Generationen müsste wie gesagt jemand mit mehr Wissen mal schauen wie das mit Europa, Australien und dem Rest von Asien bezüglich Kompatiblität aussieht. Nordamerika, Japan und Südkorea sollten ja alle nicht mit einander kompatibel sein. Auch die Frage wie das mit China in Gen 7 aussieht müsste geklärt werden. GrollenKette951 22:44, 22. Jun. 2022 (CEST)

Da es hier nicht mehr zu viel Aktivität kommt, setze ich jetzt mal ein Zeitlimit bis nächste Woche (28.07.) um 16 Uhr. Wenn sich in dieser Zeit kein Widerstand gegen die Aufteilung der Gen-8-Events auf Passwort, Seriencode und Internet zeigt werde ich diesen Punkt einfach durchführen. Wegen der Zusammenlegeung von Europa und Australien bei älteren Generationen bräuchte ich jedoch immer noch Expertenwissen von anderen, die sich damit mehr auskennen. Demnach bliebt zumindest der Punkt noch so halb offen. GrollenKette951 15:08, 21. Jul. 2022 (CEST)

Da es hier kein weiteres negatives Feedback zu Umstrukturierung von Gen 8 gab, wird dies in der nächsten Zeit umgesetzt. Sortiert wird in Zukunft für diese Generation nach Passwort, Seriencode und Internet. Passend zu dieser Diskussion wird geschaut Spielekürzel in die Eventvorlage einzubauen. Für alle weiteren Generationen werde ich Recherche betreiben wie genau sich Europa, Australien und die Reste von Asien miteinander vertragen. Ich hatte hier schon nen kurzen Blick auf eine Quelle und mich graut es bereits. GrollenKette951 18:20, 31. Jul. 2022 (CEST)

Ist zwar etwas spät, aber könnte man noch eine Seite hinzufügen für die Events, die mittels externer Software und externen Geräten erhältlich waren wie z.b.Events/8. Generation/Europa#Mew (Pokéball Plus)|Mew, Events/8. Generation/Europa#Bisasam (Pokémon HOME-Update 1.4.0)|Bisasam, Regi-Trio... MfG Goloer444 20:16, 4. Aug. 2022 (CEST)

Die Umstellung nach Verteilungsart bezieht sich nur auf Gen 8. HOME-Sachen hätte ich nach Internetverteilung gezogen, weil es da am besten hinpasst. Das Mew ist nochmal ne andere Sachen, wo ich mal genauer schauen müsste. GrollenKette951 20:40, 4. Aug. 2022 (CEST)

Pokémon-Tabellen in Typen-Artikeln

Guten Tag, ich habe mir vor längerer Zeit gedacht, dass die Tabellen mit den Pokémon in den Typen-Artikeln aufgehübscht gehören. Da sie meiner Meinung nach eine Modernisierung und ein etwas neues Design bräuchten. Hier könnt ihr euch meine neue Umsetzung einmal ansehen: [1] Dies aus verschiedensten Gründen: Die aktuelle Tabelle ist relativ aufeinander gepresst und nutzt veraltete Icons und dann wieder Sorites von aktuellen Spielen. Dieses unschöne Problem bewirkt eine inkonsistent und kann mit den Home-Sprites behoben werden. Ich weiß dass die Home-Sprites nicht die schönsten sind, aber sie sie konsistent und sie erfüllen ihren Job prima, einen kleinen Einblick auf das Aussehen des Pokémon zu geben. Ich finde mein neues Design auch viel cleaner und übersichtlich und es enthällt auch mehr Informationen, wie gewisse Formen. Meine Tabelle ist bestimmt nicht 100% perfekt, aber sie ist eine deutliche Erweiterung und Verbesserung der momentan verwendeten Tabelle im PokéWiki. Ich hab schon von einigen Usern positives Feedback erhalten und ich würde mich freuen mehr Kritik zu hören und vielleicht auch Verbesserungsvorschläge. Ich würde das neue Design am liebsten schnellstmöglich noch vor Release von Karmesin und Purpur einbauen, daher wäre ich für eine fixe Diskussion und vielleicht Abstimmung wirklich froh, wenn möglich :D --Jass 11:04, 11. Aug. 2022 (CEST)

Pokémon und Icons zu trennen halte ich für eine vernünftige Idee, ob man die Home-Sprites nutzen sollte ist eher debatierbar. Bin dem aber recht neutral gestimmt. --Mecanno-man^Mäh 23:49, 11. Aug. 2022 (CEST)

Hi zusammen! Die Ideen zur Gestaltung fand ich gut. Die haben wir in eine Vorlage gegossen, die die Tabellenzeilen vereinheitlicht, danke! Wird jetzt nach und nach ausgerollt. Eine offeme Frage bleibt noch: und zwar, nach welchen Kriterien wir Formen einzeln listen oder mit einem Kommentar zusammenfassen. Ist allerdings keine Raus-oder-Rein-Debatte, die Infos sind ja in jedem Fall drin. Nur der Detailgrad wird sich unterscheiden. Maxmiran 18:22, 16. Aug. 2022 (CEST)

Pokémon GO: Max. WP?

Hallo, ich möchte ein paar Meinungen sammeln. Es geht darum, was neben den max. WP angegeben werden soll. Eigentlich wären max. WP, die WP bei Trainerlevel 50 plus Bester Kumpel-Bonus. Das ist ziemlich schwer zu erreichen, weshalb die Bitte aufkam, vielleicht noch Level 40, 41 oder 50 aufzunehmen, weil dort quasi kleinere Grenzen auftreten. Deswegen mal eine kleine Umfrage. Bitte eintragen, welche WP ihr noch sehen wollt. Wobei ich oben genannte Max. WP auf jeden Fall als gesetzt sehe. Danke, Das Isso 08/15 ^Konter 18:21, 16. Aug. 2022 (CEST)

Ich möchte WP bei Level 50

Ich habe bereits einige male gesagt, das ich alle vier am ehesten benutzen würde, da jeder Wert ein Maximum darstellt. Level 50, da es ohne Kumpel das Maximum ist. Ich kam, sah und bearbeitete Bennett ^Diskussion 17:49, 17. Aug. 2022 (CEST)

Ich würde auch sagen das wir diesen Wert mit reinnehmen sollten, weil ich glaube das Level 50 von den meisten erwartet werden würde und weil viele Websites, welche sich mit go beschäftigen, 50 und 51 als Max angeben. MfG Goloer444 19:58, 21. Aug. 2022 (CEST)

Ich möchte WP bei Level 41

Level 41, da es das Maximum ohne XL Bonbons darstellt. Ich kam, sah und bearbeitete Bennett ^Diskussion 17:49, 17. Aug. 2022 (CEST)

Bei 41 bin ich mir unschlüssig. Natürlich bildet es eine wichtige Grenze. mMn könnte man auf diesen Wert am ehesten verzichten, außer wir machen einen extra Punkt für Max werte nur mit normalen Bonbons. MfG Goloer444 19:58, 21. Aug. 2022 (CEST)

Ich möchte WP bei Level 40

Hier ist die Grenze wo man dann XL-Bonbons benutzen soll. Daher hätte ich gerne ein Max-Wp mit XL-Bonbons und ein Max-Wp ohne XL-Bonbons. Lunairline^{Buchung zum Mond} 18:59, 16. Aug. 2022 (CEST)

Ich würd 40 sagen, weil das damals das maximale Level war. 41 erschließt sich mir in keinster Weise, warum 41, was ist da? Und nur 50 ohne den Bonus ist auch irgendwie seltsam, ist ja nahezu dasselbe (also viel zu nah beieinander liegend meine ich). Ansonsten ist aber nur 50 auch völlig in Ordnung eigentlich, aber naja. GrüßeShortyBuzz 11:38, 17. Aug. 2022 (CEST)

Level 40, da es ohne Kumpel und XL Bonbons das Maximum darstellt Ich kam, sah und bearbeitete Bennett ^Diskussion 17:49, 17. Aug. 2022 (CEST)

Max. WP reicht

In meinen Augen genügen die maximalen Wettkampfpunkte, die bei Level 50 mit Kumpelbonus (also im Grunde 51) erreicht sind. Sollte sich aber für weitere Werte oder aber eine verstellbare Anzeige, wie von Mec vorgeschlagen, entschieden werden, ist das für mich auch komplett in Ordnung und auch nachvollziehbar. Fernab des Ergebnisses dieser Diskussion bzw. Abstimmung habe ich noch einen Verbesserungsvorschlag für die Spin-off-Vorlage zu GO gemacht, der die Umsetzung, egal welcher Art sie sein wird, extrem vereinfachen bzw. automatisiert umsetzen ließe. :)

Das bedeutet auch, dass eine zukünftige erneute Anpassung bzgl. der maximalen WP oder unserer hier getroffenen Entscheidung, durch nur eine Vorlagenbearbeitung in sämtlichen Pokémon-Artikeln geändert werden könnte. Daher braucht es meiner Meinung nach eigentlich keine große Abstimmung, sondern nur eine Entscheidung von Isso als zuständige Unterleiterin des Bereichs. ~ Taisuke ^Diskussion 10:33, 18. Aug. 2022 (CEST)

Enthaltung

1. Mir ist es da völlig egal solange es einheitlich ist und erkenntlich ist um welches Level es sich handelt * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:36, 16. Aug. 2022 (CEST)
2. Sehe das genauso wie Ryuichi Kernseife ^Diskussion 08:47, 23. Aug. 2022 (CEST)

Kommentare

Ich bin mir aktuell nicht wirklich sicher was das hier werden soll. Soll das eine Abstimmung, die einfach komplett ohne Ping auskommt, sein? Weil zumindest das was Isso hier erreich will, ist eigentlich auch mit ganz normalem Schreiben erreichbar und nicht mit irgendwie mehreren Unterüberschriften. Da bin ich gerade ein bisschen verwirrt. GrollenKette951 11:48, 17. Aug. 2022 (CEST)

Hi Grollen! Ich glaub das soll keine Abstimmung sein. Soll einfach nur ein Meinungsstand sein. Wenn jetzt die Mehrheit für lv40 wäre,käme danach mit ping und allem drum und dran die Abstimmung, ob es überhaupt gemacht wird. Vielleicht liege ich ja auch falsch. Ich probiere jetzt mal den Ping im Wiki aus @Isso08-15: Lunairline^{Buchung zum Mond} 21:47, 17. Aug. 2022 (CEST)

Nun wir hatten das schon per PN auf Discord geklärt. Ansonsten: @ ist eine Vorlage, die gesubstet werden muss. GrollenKette951 21:50, 17. Aug. 2022 (CEST)

Spräche etwas dagegen dies irgendwie ähnlich zu den Statuswerten der Hauptspiele zu machen, sodass alle Level gewählt werden können? --Mecanno-man^Mäh 00:27, 18. Aug. 2022 (CEST)

Prinzipiell machbar, aber für einen guten Rechner, braucht es ja nicht nur die max. WP pro Level, oder? Das Isso 08/15 ^Konter 12:36, 18. Aug. 2022 (CEST)

Isso, was fehlt den noch um Mecs Vorschlag umzusetzen? MfG Goloer444 19:58, 21. Aug. 2022 (CEST)

Erste Wahlrunden

Ich möchte in diesem Abschnitt gerne diskutieren, ob es sinnvoll wäre, eine zeitliche Begrenzung in der ersten Wahlrunde bei VB- und Redakteurswahlen einzuführen. Ein aktuelles Beispiel für das „Warum“ ist die Wahl von Kernseife. Es finden sich aber auch weitere Beispiele in jüngster Vergangenheit. Ich weiß zwar nicht, wie es ihm damit ging und ob er es überhaupt als negativ empfunden hat, aber für mich und auch andere (z. B. Kenaz) war es unangenehm anzuschauen, dass sich die erste Wahlrunde über einen Zeitraum von drei Wochen gezogen hat. Auch für die Benutzer, die den Kandidaten vorgeschlagen haben – hier Ryu – muss es eine unangenehme Situation sein.

Ab jetzt schreibe ich allgemein und beziehe mich nicht auf Kernseife. Wenn eine Wahlrunde sich so lange zieht, fragt man sich doch schnell woran das liegen könnte. Als zur Wahl Gestellter kommen Fragen auf, wie z. B. „Sind die Beiträge doch nicht so gut gewesen?“ und „Vertrauen mir die höherrangigen Benutzer doch keine weiteren Rechte zu?“. Außenstehende bzw. Leute, die nicht an der ersten Wahlrunde teilnehmen können, haben vielleicht Fragen der Art „Ist es ihnen doch nicht wichtig, ein größeres Team zu haben?“ oder „Sind die Ansprüche so hoch, dass sich die höherrangigen Benutzer so viele Gedanken machen müssen? Dahin komme ich ja nie.“. Es kommen bestimmt auch andere Gedanken dazu auf, jedoch wollte ich dadurch nur aufzeigen, dass dieser ungewisse Abstimmungszeitraum unangenehmer wird, je länger er andauert. Und ohne eine Begrenzung tut er das aktuell mal gerne drei Wochen. Das ist in meinen Augen zu lang.

Schaue ich in unsere Regeln, finde ich zu Abstimmungen unter dem Punkt Allgemeines folgende Zeile: „Es ist eine Zeitbegrenzung zu setzen. Diese kann auch nachträglich verlängert werden, wenn genügend Gründe vorliegen.“. Und dennoch, die ersten Wahlrunden der beiden Wahlen scheinen die einzigen Abstimmungen im PokéWiki zu sein, die keine Zeitbegrenzung haben. Das passt doch nicht. Noch mehr passt es nicht, wenn man laut der Seiten zu verlässlichen Benutzern und Redakteuren für die zweite Wahlrunde grundsätzlich eine zeitliche Frist von nur einer Woche formuliert.

In meinen Augen spräche nichts dagegen, für die ersten Wahlrunden eine Zeitbegrenzung von zum Beispiel zwei Wochen einzuführen, um für alle Beteiligten eine klare Regelung zu haben. Sollte bei den höherrangigen Benutzern eine Vielzahl von Leuten in den zwei Wochen nicht die Zeit finden, eine fundierte Einschätzung des Benutzers abzugeben, kann man die Frist doch auch in totalen Ausnahmefällen noch um eine Woche verlängern (siehe oben zitierte Regel).

Ich lasse die Pings an dieser Stelle mal weg (bis auf die Admins Buoysel, DeXter, GoPika, Matze, Mecanno-man, RobbiRobb und ShortyBuzz) und bin gespannt, wer zu diesem Thema gerne diskutieren mag und welche Argumente ich nicht bedacht habe. :) ~ Taisuke ^Diskussion 07:35, 10. Sep. 2022 (CEST)

Anzumerken sei hier das wir im Chattreffen vom 22.10.2021 genau diesen Punkt auf der Agenda hatten. Ich verstehe hier auch klar Tai seinen Standpunkt bin allerdings anderer Meinung. Die Problematik ist nicht die Zeit sondern das Abstimmungsuser nicht offen kommunizieren wenn sie noch Zeit benötigen. Sei es zwecks Studium, arbeitsbedingt, nicht mit der Arbeit des Nutzers vertraut (einarbeiten in die getätigten Edits braucht seine Zeit) usw. An und für sich wurde es auch grob so besprochen das User bescheid sagen sollen wenn Sie nicht zeitnah abstimmen können. Daher finde ich die Ansprache von Tai gut, sehe jedoch das Problem wo anders. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:02, 10. Sep. 2022 (CEST)

Den Punkt kann ich nur bedingt nachvollziehen. Wenn es keine Frist gibt, komme ich ja überhaupt nicht in die Situation zu sagen, dass ich nicht zum Abstimmen komme. Es macht aber einen Unterschied, ob ich als vorschlagender Benutzer nach 14 Tagen alle Leute anpinge, die noch nicht abgestimmt haben, um diese dazu zu motivieren/erinnern und diese dann antworten, dass sie nicht dazu kommen oder ob diese es selbstständig im Vorfeld kommunizieren. Ohne eine Frist kommuniziert man das eher selten. Mit einer Frist hat man jedoch einen Grund das zu kommunizieren. Und grundsätzlich erwartet man doch von Redakteuren und Admins einen gewissenhaften Umgang mit Fristen und einer offenen selbstständigen Kommunikation, die ohne Nachfragen anderer Benutzer stattfindet. Ich bin vermutlich der letzte, der das voraussetzen darf, aber irgendjemand muss das ja aussprechen.

Es zeigt sich doch seit dem Chattreffen, dass kaum jemand davon Gebrauch macht. Und wenn das nicht geschieht, obwohl es so vereinbart wurde, erzeugt das Nichtabstimmen erst recht ein schlechtes Gefühl... ~ Taisuke ^Diskussion 08:20, 10. Sep. 2022 (CEST)

Ich muss zustimmen, dass mir die Wahl zu Lange ging. Bei den vorherigen Wahlen war dies, weil sie mitten in den PLA-Release reingegrätscht haben und einige User demnach entscheiden mussten, ob das beurteilen der User oder der Wiki-Inhalt wichtiger waren - und mehr als ein Drittel entschied sich für den Wiki-Inhalt. Diesen Grund gab es jedoch so hier nicht. Ich bin mir aber auch nicht sicher, ob man an Hand einer Wahl bereits das System ändern sollte. Die VB-Wahl soll ja im Grunde genommen eine Bestätigung durch die Community sein, und dieser Funktion wird sie nicht gerecht wenn ein signifikanter Teil der Community nicht abstimmt. Ich bin demnach gegen eine fixe Zeitspanne, aber über irgendein Mischding könnte man aus meiner Sicht reden, denn das eine erste Wahlrunde so lange dauert sollte auch nicht vorkommen. Vielleicht könnte man sagen, dass wenn eine Woche lang keine neue Stimme eintrifft, es keine Contra-Stimme gab und nur noch eine Pro-Stimme für die nächste Wahlrunde fehlt die Wahl dann in die Zweite Runde übergeht, oder so? Der Vorschlag ist jetzt aber mehr so aus dem Hut geschüttelt, man könnt auch sagen wenn eine Woche keine neue Stimme eintrifft, keine Contra-Stimme und mind. 50% abgestimmt haben. Ich denke aber wenn Contra-Stimmen vorhanden sind wäre es besser, wenn die Wahl wirklich bis zu den 2/3 geführt wird. --Mecanno-man^Mäh 10:03, 11. Sep. 2022 (CEST)

Ich sehe die Idee, Mec, irgendwas in die Richtung könnte man also optimieren. Einziges Problem: Im Zweifel verursacht man dann allerdings, dass zwei drei Leute ein Kontra reinhauen, nur weil diejenigen fürchten, keine Zeit zu haben, gerne abstimmen, aber nicht übergangen werden wollen. Das ist meiner Ansicht nach demotivierender für den Kandidaten als einfach zu warten. Letztendlich wird man aber sowas brauchen, weil was macht man, wenn ein Limit da wäre, aber bis dahin nur einer abgestimmt hat?

Ich will mich also schonmal generell der Idee anschließen, dass man von einer Mindeststimmzahl ausgeht und dann irgendwas in Richtung Zeitraum ohne Stimme angeht. Irgendeine Lösung muss es ja geben. Um Äußerungen zu den Stimmen zu stärken, könnte man ja auch vielleicht einfach sowas wie unten im Spoiler zu Beginn der Wahl erstellen und jeder schreibt für sich rein, wo er gerade so ist, damit wir die Wahlen einfach akiver gestalten.

Erste Wahlrunde

Wahluser

Vorgeschlagen von Feblue wird Wahluser

Erste Wahlrunde

Hier stimmen die Administratoren und Redakteure über den Vorschlag ab. Enthaltungen sind in der ersten Wahlrunde nicht erlaubt. Sobald ⅔ der Administratoren – Bürokraten nur einberechnet, wenn sie ihre Stimme abgeben – und Redakteure für den Vorschlag stimmen, gilt die Wahl als autorisiert und startet in die zweite Wahlrunde. In diesem Wahlgang sind nicht-Stimmberechtigte gerne dazu eingeladen, vorab die Nominierung des Kandidaten zu kommentieren.

Cliffichen:

DeXter:

Feblue:

GoPika:

GrollenKette951:

Mecanno-man:

Mooni000:

RobbiRobb:

Ryuichi:

ShortyBuzz:

SwowoJonny:

Kommentare

Pings für die erste Wahlrunde gehen raus an: ...

-- ~~ feblue 21:42, 3. Okt. 2022 (CEST)

Moin, ich möchte das Thema nochmal aufgreifen. Inzwischen läuft Issos Wahl bereits seit fast 7(!) Wochen, es sind drei eindeutige Pro-Stimmen gegeben, aber eine fehlt noch. Ja, es ist wieder in der Release-Phase, aber die Wahl hat zwei Wochen vorher gestartet und Isso ist mit 3 Jahren Erfahrung als Redakteur auch kein unbeschriebenes Blatt. Insofern zeigt mir die Wahl, dass es Änderungen am aktuellen System geben sollte. Bisher sehe ich ehrlicherweise auch keinen Grund, warum eine anpassbare Frist problematisch wäre - Abwesenheiten sollten die Admins untereinander eh absprechen, Release-Termine sind auch bekannt, wenn man also einen Standardzeitraum (zB zwei Wochen oder auch vier) festlegt, mit der Option diesen in Ausnahmen zu verlängern, sollte das denk ich klappen (aktuell) 4 Admins zu finden, die abstimmen. Sollte sich kurz vor Ablauf der Frist eine enge Wahl abzeichnen, kann man ggf ja dann auch nochmal verlängern. Aber leider wirkt bspw Issos Wahl aktuell eher so als ob sie vergessen wurde. Jones ^Albtraum? 15:07, 22. Dez. 2022 (CET)

Wir werden bei zukünftigen Wahlen GoPika wie einen Bürokraten behandeln und dadurch die Anzahl benötigter Stimmen senken; für seine aktuelle Inaktivität kann er nichts und sobald das, was ihn aktuell inaktiv macht, vorbei ist, meint er wird er wieder aktiv werden (werde hier nicht weiter darauf eingehen, was das ist, da das doch privat ist). Für die aktuelle Wahl wollten wir das aber nicht übertragen, da Robbi dem entweder zustimmt - in welchem Fall er auch gleich pro stimmen gehen kann, oder er ist dagegen, die anderen aber dafür und dann wäre das de facto Robbi einen Maulkorb zu verpassen. Was passiert falls Robbi Contra stimmt haben wir bewusst noch nicht entschieden, da wir seine Stimme nicht beeinflussen wollen. Robbi meinte er wolle heute oder morgen abstimmen, also sollten wir mit der Wahl relativ zeitnah weiterkommen. Durch die Zählung GoPikas als Bürokraten ist aus meiner Sicht das Problem in Zukunft ebenfalls bereits erledigt, da es nicht häufig vorkommen sollte, dass ein Admin langfristig inaktiv ist und seine Rechte behält - das hier ist aus meiner Sicht eine Ausnahme. --Mecanno-man^Mäh 20:28, 22. Dez. 2022 (CET)

Für den Fall, dass es nochmal vorkommt, dass ein Admin unerwartet fehlt (was ja durchaus vorkommen kann und darf), sollte denke ich auch mal eine Regel festgelegt werden, in etwa „Ist ein Admin einen Monat inaktiv, wird er in der Abstimmung als Bürokrat behandelt.“ Inaktiv wär da für mich einen Monat keinen Edit gemacht und die Behandlung als Bürokrat würde dann bei VB-Wahlen und Red-Wahlen Anwendung finden, wo anders ists ja eigentlich nicht nötig. Es sei denn, ihr braucht Stimmengen intern auf Discord, aber das muss dann getrennt vom Wiki behandelt werden. Fakt ist, diese automatisierende Regel würde gut funktionieren, weil der inaktive Admin dann schon automatisch rausgerechnet ist und falls er doch abstimmen möchte, dann kann er das ja tun und dadurch wird seine Stimme ja wieder wie eine unter Aktivität behandelt. Das löst zwar leider nicht das Problem, um das es hier eigentlich gehen soll, aber schonmal das Problem, wenn ein Admin inaktiv ist. Könnte man ja auch durchaus auf Redakteure bei VB-Wahlen ausweiten. -- ~~ feblue 20:01, 26. Dez. 2022 (CET)

Hmm. Die Idee das direkt als Präsedenzfall zu nehmen gefällt mir eigentlich ganz gut; würde als Inaktivitätskriterium aber eher zu zwei Monaten statt einem tendieren um Einheitlichkeit mit den SBs zu haben. Es auf Redakteure in der ersten Runde von VB-Wahlen auszudehnen hätte ich auch kein Problem mit. --Mecanno-man^Mäh 13:37, 27. Dez. 2022 (CET)

Ich finde die nun gefundene Lösung bzgl. längerer Abwesenheiten gut und würde es unterstützen, wenn es auch auf Redakteure bei VB-Wahlen ausgedehnt werden würde. Dann ist man gewappnet für zukünftige Eventualitäten. Die letzten Wahlen haben mir jedoch gezeigt, dass es kein exklusives Problem erster Wahlrunden ist, sondern auch bei zweiten Wahlrunden zum Vorschein kommen würde, wenn diese zeitlich nicht begrenzt wären. Daher stelle ich mir die Frage, woran die geringe bzw. späte Teilnahme bei solchen Wahlen liegt. Vielleicht findet sich darauf ja eine mögliche Antwort in der Diskussion zu Verlässlichen Benutzern und deren Aktivität. ~ Taisuke ^Diskussion 14:50, 28. Feb. 2023 (CET)

Soll der Präzedenzfall und die evt. Ausdehnung auf VB-Wahlen noch irgendwo auf den Seiten zu Redakteuren und evt. Verlässlichen Benutzern festgehalten werden? Dann könnte man diese Diskussion im Anschluss archivieren, da anscheinend nichts mehr zu diskutieren ist und sich seitens der Administration für einen Umgang mit langfristigen personellen Abwesenheiten entschieden wurde. ~ Taisuke ^Diskussion 14:56, 12. Apr. 2023 (CEST)

Ich würde diesen Diskussionspunkt gerne abhaken und bin nun eher zufällig im Protokoll zum Chattreffen vom 25. März 2023 auf Folgendes gestoßen: „Es wurde festgelegt, dass Stimmen von Reds/Admins, die eine bestimmte Zeit inaktiv sind, für die Wahl als Bürokrat gezählt werden. Als Aktivität zählt dabei jegliche Reaktion im Wiki (Kontrolle, Dank ect.). Es folgt demnächst eine Abstimmung, um den Zeitraum festzulegen. Zur Auswahl stehen: 1 Monat, 6 Wochen, 2 Monate.“ Da ich jedoch nicht anwesend gewesen bin, weiß ich nicht, für welchen Personenkreis die Abstimmung offen sein soll. Nur erweitert stimmberechtigt oder auch mit den Stimmberechtigten Benutzern? Daher bitte ich jemanden, der das weiß, diese Wahl mit den drei Optionen an meiner Stelle zeitnah zu initiieren. ~ Taisuke ^Diskussion 18:49, 2. Mai 2023 (CEST)

Tja, eigentlich hätte ich diese Abstimmung schon starten wollen, aber genau an dieser Frage hatte ich mich aufgehangen und es dann erstmal doch nicht gemacht. Vielleicht hilft ein kurzes Meinungsbild. -- ~~ feblue 21:30, 2. Mai 2023 (CEST)

Abstimmung

Hier geht es um die Frage, ab wann ein Admin / Redakteur als inaktiv gilt und er somit bei VB- und Red-Wahlen als Bürokrat behandelt wird. Als Aktivität zählt dabei jegliche Reaktion im Wiki (Kontrolle, Dank ect.).

Abstimmung beendet, Mehrheit spricht sich für 2 Monate aus (1 Stimme für einen Monat, 6 Stimmen für 6 Wochen, 8 Stimmen für zwei Monate)

Jeder Erweitert Stimmberechtigte Benutzer darf eine Stimme abgeben. Die Abstimmung läuft bis zum 24. Mai 2023 um 23:00 Uhr. Heute ist der 16.04.2024, 09:13 Uhr.

Ein Monat

1. Aus meiner Sicht reicht eine einmonatige Inaktivität aus, um die Stimme in der ersten Wahlrunde nicht zwingend erforderlich zu machen. Dadurch wird gewährleistet, dass wichtige Wahlen von Team-Mitgliedern weiterhin reibungslos verlaufen und nicht über Wochen hinweg in der ersten Wahlrunde feststecken. Derjenige wird in meinen Augen dadurch weder entmündigt noch wird seine Stimme komplett in Frage gestellt. Und von Ignorieren oder Verlust einer Stimmberechtigung kann auch nicht die Rede sein. Schließlich kann der Betroffene, sollte er die erste Wahlrunde verpassen, auch noch in einer zweiten Wahlrunde abstimmen. Ihm wäre sogar die Möglichkeit gegeben trotz dessen in der ersten Runde abzustimmen, auch wenn das unwahrscheinlich wäre. Zumal in jeder x-beliebigen anderen Abstimmung im Wiki bei Inaktivität auch kein Gebrauch von der Stimmberechtigung gemacht werden würde. In den oberen Rängen der Rechte-Hierarchie sollte ich genug Vertrauen in die Leute um mich herum haben, dass diese auch ohne meine Stimme eine vernünftige Entscheidung treffen können. Und sind wir mal ehrlich: Bei der Anwendung dieser Regel sollte es sich eh um eine Ausnahme handeln, die nicht bei jeder Wahl genutzt werden muss. :)
   Ich kann dennoch die Worte von Ryu gut verstehen. Das Problem der Demotivierung sehe ich jedoch auf beiden Seiten einer solchen Wahl. Nicht nur bei den Benutzern, die abstimmen, sondern auch bei den Benutzern, die wochenlang zur Wahl stehen und nicht über eine erste Wahlrunde hinauskommen. Ich finde daher deinen nächsten Punkt ganz wichtig, auch aus persönlicher Erfahrung: Der verantwortungsvolle Umgang mit Rechten. Und dazu gehört auch die freiwillige Abgabe, sofern die Kapazitäten nicht mehr da sind. Schließlich sind wir als Community keinem böse, der sagt, dass ihm die nötige Zeit, Motivation oder was auch sonst fehlt. Sollte sich das ändern, haben wir doch bislang jeden wieder mit offenen Armen empfangen!
   Rückblickend betrachtet habe ich meine Rechte vor einem Jahr zu spät abgeben und hätte es frühzeitiger tun sollen. Wäre ich bei Wahlen öffentlich ausgenommen gewesen, hätte ich meine Position vielleicht früher hinterfragt. Jedenfalls hat es mir einen deutlichen Anstoß gegeben, als wir uns intern darauf festgelegt haben, dass meine Stimme nicht mehr für einstimmige Entscheidungen benötigt wird. Dadurch wurde ich als Admin obsolet und habe gemerkt, dass es zum einen ohne mich funktioniert und zum anderen mir zum damaligen Zeitpunkt auch die Ausübung des Amtes nicht fehlt. Für mich ist die Regelung daher eher ein kleines und feines Instrument, um sowohl länger Abwesende sich selbst zu hinterfragen als auch potentiell zur Wahl gestellte Benutzer nicht ewig in der ersten Wahlrunde hängen zu lassen und eine Demotivierung zu riskieren.
   Darüber hinaus denke ich, dass die geringe Fluktuation in den höheren Rängen leider dazu beiträgt, diese eher zu spät als rechtzeitig abzugeben, da eine potentielle Wiedererlangung der damaligen Rechte mitunter sehr langwierig sein kann. Das ist aber wohl ein anderes Thema. ^_^
   Abschließend möchte ich anmerken, dass ich glaube, dass diese Regelung nur selten Anwendung finden wird, sie aber aufgrund meiner oben aufgezeigten Argumente durchaus dazu beitragen kann, positive Veränderungen hervorzubringen. Auch, wenn diese vielleicht nicht unmittelbar und für jeden sichtbar sein sollten. ~ Taisuke ^Diskussion 22:04, 15. Mai 2023 (CEST)

6 Wochen

1. Initial war ich hier für einen Monat. Von anderen Benutzern wurden sich aber zwei Monate gewünscht. Da das allerdings derselbe Zeitraum wie beim Verlust der Stimmberechtigung ist, finde ich das im Sinne der Rangordnung unverhältnismäßig und bin daher für den Kompromiss von 6 Wochen. -- ~~ feblue 14:41, 10. Mai 2023 (CEST)
2. Mitte als Kompromiss, Das Isso 08/15 ^Konter 15:13, 10. Mai 2023 (CEST)
3. -- 🗲 Hola, ciao und hallöle! 🗲 SwowoJonny 20:16, 10. Mai 2023 (CEST)
4. -- BeyJim ^Diskussion 22:32, 10. Mai 2023 (CEST)
5. Im sehr unwahrscheinlichen Fall, dass mehrere Benutzer im gleichen Zeitraum inaktiv werden, könnte eine Wahl acht Wochen dauern, was eindeutig zu lang ist. Vier Wochen sind gerade noch so akzeptabel, aber vereinzelt könnte innerhalb der nächsten zwei Wochen vielleicht doch noch eine Stimme erfolgen. Fast immer sollte der Zeitraum von sechs Wochen sowieso spätestens einen Monat nach Beginn der Wahl ablaufen. --Poffel — Diskussion 23:21, 10. Mai 2023 (CEST)
6. Kernseife ^Diskussion 13:25, 11. Mai 2023 (CEST)

Zwei Monate

1. Ein Monat ist hier eindeutig ein zu kleiner Zeitraum, den ein Admin oder Red inaktiv sein darf bevor er in der Wahl ignoriert wird, da das nochmal mehr Druck in ein Projekt während unserer Freizeit bringt. Die 6 Wochen sind aus meiner Sicht auch so ein komisches Zwischending, dass hier in unserer gesamten Rechtestruktur aus der Reihe tanzen würde. In dem Sinne hier meine Stimme für die 2 Monate, wie man sie auch vom Verlust des SB kennt, da es ab dem Zeitpunkt ja technisch gesehen sowieso ein Verlust der Stimmberechtigung wäre. GrollenKette951 15:22, 10. Mai 2023 (CEST)
2. Ich denke auch, das zwei Monte hier in Ordnung sind. Auf die zwei Wochen Unterschied zwischen 6 und 8 Wochen kommt es dann auch nicht mehr so sehr an und 6 Wochen ist einfach ein etwas seltsamer Zeitraum. Cliffichen 18:07, 10. Mai 2023 (CEST)
3. Schließe mich den anderen beiden an. ~~ DieTaube 19:34, 10. Mai 2023 (CEST)
4. --Mecanno-man^Mäh 22:49, 10. Mai 2023 (CEST)
5. Ich denke auch, dass zwei Monate naheliegend sind, da wir das ja schon für SB-Verlust als Grenze haben. Ratequaza 11:38, 11. Mai 2023 (CEST)
6. Für mich ist das gesamte Konstrukt hier eine Ausnahmeregelung, die um ehrlich zu sein im besten Falle niemals zum Einsatz kommt - auch wenn ich mir recht sicher bin, dass sie irgendwann sehr wohl zum Einsatz kommen wird. Denn die Vergangenheit hat uns gezeigt, dass so etwas nötig zu sein scheint, sei es Shadow, der nach langer Unerreichbarkeit zurückgetreten ist, Tai der immer wieder Inaktivitätsphasen hatte, die dann von stärkerer Aktivität durchzogen waren, oder aktuell GoPika, der inzwischen ebenfalls langfristig inaktiv ist. Und auch wenn ich das von mir gerne behaupten würde, ich kann nicht garantieren, dass ich nicht irgendwann in einer ähnlichen Situation enden werde. Das hat zwar das Potenzial, hier etwas abzuschweifen, aber ich denke es ist auch erwähnenswert, dass die andere Seite bei dem Inaktivitäts-Problem genau so blöd da steht. Denn niemand ist gerne derjenige, der nachfragt, ob da jetzt noch was kommt oder - um es salopp zu sagen - man jemanden aus dem Team werfen sollte, weil derjenige inaktiv ist. Macht einfach keinen Spaß, weil wir ohnehin nicht von Leuten überrannt werden und jeder Rücktritt einen Verlust darstellt. Andererseits ist es aber natürlich auch nicht gerade zielführend, einen inaktiven Benutzer in einer relevanten Position sitzen zu haben. Egal, ob das jetzt ein Admin oder Redakteur ist, dessen Stimme für Abstimmungen relevant ist, oder ob das jetzt ein Projektleiter ist, der sich nicht um sein Projekt kümmert.
   Und um ehrlich zu sein sehe ich die Ursache dafür noch etwas tiefer liegend. Denn meines Erachtens nach ist es problematisch, dass Redakteure und Administratoren von der SB-Regelung ausgenommen sind. Der Gedanke dahinter ist zwar ziemlich cool, dass man diesen Benutzern die Freiheit einräumt, selber einzuschätzen, welche Aktivität man in diesen Positionen an den Tag legen sollte und ab wann man vielleicht die Meinung vertritt, dass man den eigenen Ansprüchen und denen des Teams nicht mehr gerecht wird. Allerdings hat wie bereits erwähnt die Vergangenheit gezeigt, dass das nicht wirklich zu funktionieren scheint. In der Vergangenheit war bspw. das VB-Recht an sechsmonatige Inaktivität gekoppelt, Redakteure und Admins hatten einen nicht definierten Zeitraum, der aber logischerweise eher darüber gelegen hat. Da nun aber lediglich die Stimmberechtigung einen festen Zeitraum hat, ist es extrem schwer zu sagen, ab wann jemand zu inaktiv ist, um für eine solche Wahl noch gezählt zu werden. Nach zwei Monaten würde es regulär aber ohnehin zu einem Verlust der Stimmberechtigung führen, verhindert einzig durch die Sonderregelung für Redakteure und Admins. Deswegen ist dieser Zeitraum meiner Meinung nach der passende dafür.
   Das soll aber übrigens nicht heißen, dass ich mich jetzt auch gleichzeitig dafür aussprechen möchte, dass Redakteure und Admins nicht mehr vom SB-Verlust ausgenommen sein sollen. Aus genannten Gründen sehe ich einen Sinn darin, dass es diese Ausnahmeregelung gibt. Es soll aber allen Benutzern hier aufführen, dass dies eigentlich das Gegenteil bewirken sollte. Hochrangige Nutzern sollten sich vielleicht eher fragen, ob sie ausreichend Aktivität für ihren Posten zeigen und nicht auf den Rechten sitzen bleiben, weil es ja keine feste Regel gibt, die einen Entzug garantiert.
   Ich habe das ungute Gefühl, dass all diese Gedanken jetzt etwas wirr waren. Aber im Endeffekt will ich damit aufzeigen, dass ein Redakteur oder Admin bei zweimonatiger Inaktivität wirklich darüber nachdenken sollte, ob er für seine Position noch geeignet ist. Denn wäre er nicht in dieser Position, wäre jetzt schluss mit der Teilnahme an Abstimmungen. Dementsprechend denke ich das zwei Monate eine gute Frist dafür sind, um auch dem betroffenen Benutzer aufzuzeigen, dass die Aktivität nicht mehr ausreichend ist. -- RobbiRobb 23:59, 22. Mai 2023 (CEST)
7. Schließe mich dem Modellvorschlag mit zwei Monaten an. Grundsätzlich sollte es ja ein absoluter Ausnahmefall sein, dass jemand aus den höchsten Rechtegruppen plötzlich ohne jegliche Rückmeldung einfach über Monate hinweg vollständig inaktiv wird. Und selbst wenn dieser Worst Case eintritt, eine fehlende Person sollte normalerweise nicht das auf Mehrheiten basierende Wahlsystem blockieren können - alle anderen Personen derselben Rechtegruppe oder höher sind ja trotzdem weiterhin aktiv. Wenn sich eine Wahl also zu sehr in die Länge zieht, liegt das meiner Ansicht nach eher an einem fehlenden Zeitlimit oder an Unklarheiten/Unsicherheiten in Bezug auf das Wahlthema. Wenn ich meine eigene VB-Wahl als Beispiel nehme, so hat die erste Wahlrunde lediglich eine Woche gedauert, was wirklich beeindruckend schnell war. Mir ist durchaus bewusst, dass das nicht immer der Fall ist (die erste VB-Wahlrunde von BeyJim dauerte zum Beispiel über einen Monat), aber in solchen Fällen könnte man das Problem mit dem bereits erwähnten Zeitlimit lösen (das ja auch für die zweite Wahlrunde existiert) oder zumindest mehr darauf achten, dass man dem/der Gewählten zeitnahe eine Rückmeldung gibt, dass leider alles etwas länger dauert, die Wahl aber nicht einfach ignoriert oder als zu unwichtig empfunden wird. -Eden 16:03, 24. Mai 2023 (CEST)
8. GrüßeShortyBuzz 21:56, 24. Mai 2023 (CEST)

Enthaltung

1. An und für sich finde ich diese ganze Abstimmung sehr demotivietend. Erst kürzlich hat ein Benutzer eine bestimmte Rechtgruppe aufgegeben weil er privat sogut wie keine Zeit hat. Allerdings sich im gleichen Atemzug dafür ausgesprochen andere Rechtegruppen noch behalten zu wollen obwohl die Aktivität für alle Gruppen seit längerem gegen Null geht. Dies ist in meinen Augen die wahre Problematik. Für diverse Benutzer sind einige Rechtegruppen augenscheinlich Statussymbole die sie nur ungern abgeben wollen weshalb dann auf einmal größere Antwortzeiträume entstehen. Es ist daher schade das immer mehr Dinge in strikte Regeln gekippt werden. Des Weiteren da Abwesenheiten meist individuelle Gründe haben will ich mich nicht auf Zeiträume festlegen. Eher der Appell wenn man keine Zeit hat rechtzeitig runterstufen zu lassen oder temporär auszusetzen weil die Gründe absehbar sind. Eine Hochstufung ist ja bei jemanden der freiwillig runter gegangen ist immer einfacher wie bei jemanden der sich versteckt hat. Siehe Max von Red auf Vet und nun wieder VB vs. Tai von Admin auf Vet wieder zum VB. Die Kommentare in den jeweiligen Abstimmungen sind da ja eindeutig. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:51, 11. Mai 2023 (CEST)
2. Maxmiran 11:26, 15. Mai 2023 (CEST)

Kommentare

Ping an alle Erweitert Stimmberechtigten Benutzer: BeyJim, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Eden, Feblue, Goloer444, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Kernseife, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae -- ~~ feblue 14:41, 10. Mai 2023 (CEST)

Noch ne kleine Anmerkung zur Frage was als Aktivität zählt: Auch Aktionen im Testwiki sowie Aktivität in Wiki-Kanälen auf Discord sollten da auch bei der Frage nach der Aktivität in einem gewissen Maß berücksichtigt werden. Nur weil man aktuell keine Edits im (Live-)Wiki selber macht, ist man ja noch nicht zwingend inaktiv. Ansonsten noch die Frage an @Feblue warum die zwei Monate genau "unverhältnismäßig" sind. Das geht mir noch nicht so wirklich aus deiner Stimmer hervor. GrollenKette951 15:22, 10. Mai 2023 (CEST)

@GrollenKette951 Discord hier mit einzubeziehen halte ich nicht für sinnvoll - der Sinn der Regel ist es ja, dass man ins Wiki schaut. Wer nicht ins Wiki schaut, kann auch nicht wissen, was potentielle Kandidaten gerade abliefern. Daher würde ich auch das Testwiki nicht einbeziehen (wobei ich auch nicht glaube, dass sich irgendwer wochenlang nur im Testwiki rumtreibt und im Wiki dann auf einmal nichts kommt, nicht mal ein Dank / eine Kontrolle).

Nach zwei Monaten verliert ein Stimmberechtigter Benutzer seine Rechte. Soweit ist das in Ordnung, zwei Monate gehen klar. Aber aus meiner Sicht nicht für einen Redakteur / Admin, der deutlich mehr Aktivität auf dem Kasten haben sollte. Diese Ränge auch nur ansatzweise mit der Stimmberechtigung gleichzuziehen, finde ich unverhältnismäßig. Ich hoffe, dass das jetzt klarer ist. -- ~~ feblue 15:49, 10. Mai 2023 (CEST)

Wäre hier auch dabei das aufs Wiki zu beschränken; auf Discord kann die Aktivität eineseits in Kanälen sein, wo viele nicht reinsehen, zB intern_admin, was die Transparenz beeinträchtigen würde, andererseits kann eine Nachricht auf Discord auch ein "Btw, mir gehts nicht so gut, werd aber trotzdem bald mal versuchen wieder reinzuschauen" sein, was dann nicht wirklich hilft. Im Worst-case führt es sogar dazu, das sich die Person nicht auf dem Server melden will was los ist um nicht potenziell bei Red/VB-Wahlen als aktiv zu zählen, was völlig kontraproduktiv wäre. Testwiki hat das Problem der Nachvollziehbarkeit bei einem Reset. Denke wir brauchen das System hier nicht verkomplizieren - wenn jemand wirklich aktiv ist und nur keinen Edit gemacht hat verbiete das System dem Benutzer ja nicht trotzdem abzustimmen, es ist nur keine Pflicht mehr.

@Fe: Kontrolle und Dank - wo zählen wir das ansonsten als aktiv? Ist mir nichts bekannt. Generell gilt ansonsten glaub ich grundsätzlich alles was von MediaWiki als Aktivität zählt, was so ziemlich dem entspricht, was einen Eintrag in den eigenen Bearbeitungen gibt. Also edit, upload, move, etc. (Wobei ich mich gerade frage, wie das mit löschen und sperren is, die geben LÄ-Enträge aber nicht Bearbeitungs-Einträge) --Mecanno-man^Mäh 22:49, 10. Mai 2023 (CEST)

@Mec Kontrolle und Dank kommt aus dem Chattreffen, das wurde sich als zusätzliche Aktivitätsaufzeichnung gewünscht. -- ~~ feblue 22:59, 10. Mai 2023 (CEST)

Color-Vorlagen

bisherige Diskussion

Wie im Abschnitt zu unseren Icons ersichtlich sollten wir das Thema Color besprechen. Wie in dieser Tabelle ersichtlich:

Normal	Kampf	Flug	Gift	Boden	Gestein
Käfer	Geist	Stahl	Feuer	Wasser	Pflanze
Elektro	Psycho	Eis	Drache	Unlicht	Fee
???

Die neu gewählten Farben beißen sich teilweise mit unseren Typ/Color die Frage ist sollten wir Typ/Color an die neuen Iconfarben anpassen? Anpassen heißt nicht zwangsläufig gleiche Farbe. Ich dachte da eher an Abstufungen der Helligkeit. Aktuell nutzen wir folgende Vorlagen inkl. Farben: Zum Verwenden der Vorlagen {{Typ/Color/Parameter-hell+}}, {{Typ/Color/Parameter-hell}}, {{Typ/Color/Parameter-dunkel}} oder {{Typ/Color/Parameter-dunkel+}} nutzen.

Parameter	Typ/Color/-hell+			Typ/Color/-hell			Typ/Color/-dunkel			Typ/Color/-dunkel+
	Hex-Code	Farbe Background	Schriftfarbe	Hex-Code	Farbe Background	Schriftfarbe	Hex-Code	Farbe Background	Schriftfarbe	Hex-Code	Farbe Background	Schriftfarbe
Normal	e3e3dd	e3e3dd	e3e3dd	cfcfc3	cfcfc3	cfcfc3	a8a899	a8a899	a8a899	707066	707066	707066
Kampf	e3bbb4	e3bbb4	e3bbb4	cf887c	cf887c	cf887c	a84c3d	a84c3d	a84c3d	703328	703328	703328
Flug	d5e9ff	d5e9ff	d5e9ff	b5d9ff	b5d9ff	b5d9ff	87b5e5	87b5e5	87b5e5	5a7999	5a7999	5a7999
Gift	d4baeb	d4baeb	d4baeb	b486dc	b486dc	b486dc	864ab8	864ab8	864ab8	59317b	59317b	59317b
Boden	dbc7af	dbc7af	dbc7af	c09d74	c09d74	c09d74	956833	956833	956833	634522	634522	634522
Gestein	e3ddc1	e3ddc1	e3ddc1	cfc393	cfc393	cfc393	a8995b	a8995b	a8995b	70663d	70663d	70663d
Käfer	d3e6a9	d3e6a9	d3e6a9	b2d369	b2d369	b2d369	83ad25	83ad25	83ad25	577319	577319	577319
Geist	c5b3c5	c5b3c5	c5b3c5	997b9a	997b9a	997b9a	633c64	633c64	633c64	422843	422843	422843
Stahl	dddde3	dddde3	dddde3	c3c3cf	c3c3cf	c3c3cf	9999a8	9999a8	9999a8	666670	666670	666670
Feuer	ffb3a4	ffb3a4	ffb3a4	ff7a60	ff7a60	ff7a60	e53b19	e53b19	e53b19	992710	992710	992710
Wasser	aad7f3	aad7f3	aad7f3	6bb9eb	6bb9eb	6bb9eb	278bcc	278bcc	278bcc	1a5d88	1a5d88	1a5d88
Pflanze	c0e4bd	c0e4bd	c0e4bd	91d08b	91d08b	91d08b	58a951	58a951	58a951	3a7036	3a7036	3a7036
Elektro	fff199	fff199	fff199	ffe64c	ffe64c	ffe64c	e5c600	e5c600	e5c600	998400	998400	998400
Psycho	ffc0cc	ffc0cc	ffc0cc	ff91a6	ff91a6	ff91a6	e55973	e55973	e55973	993b4c	993b4c	993b4c
Eis	c7ebe5	c7ebe5	c7ebe5	9dddd2	9dddd2	9dddd2	68baac	68baac	68baac	457c73	457c73	457c73
Drache	bbc5e5	bbc5e5	bbc5e5	889ad1	889ad1	889ad1	4d64ab	4d64ab	4d64ab	334372	334372	334372
Unlicht	b8b4b4	b8b4b4	b8b4b4	837c7c	837c7c	837c7c	463e3e	463e3e	463e3e	2e2929	2e2929	2e2929
Fee	f7d2f5	f7d2f5	f7d2f5	f1b0ed	f1b0ed	f1b0ed	d480cf	d480cf	d480cf	8d558a	8d558a	8d558a
???	c2d9d2	c2d9d2	c2d9d2	95bcb1	95bcb1	95bcb1	5d9081	5d9081	5d9081	3e6056	3e6056	3e6056

Wie sind dazu die Meinungen? Wenn wir einmal die Farben besprechen würde ich auch nochmal den Punkt Auslagerung der Farben angehen das wir diese ins CSS verlagern. Gleiches auch für Orte/Color und Region/Color. Ein Punkt der mich noch stört ist das default bei Typ/Color die Farbe von ??? genutzt würde. Effektiv war dies ein Typ bis zur 4.ten Gen. Würde eher Vorschlagen das wir default immer das Wiki-blau nehmen. Bin mir gerade unsicher ob wir da für alle vier Fälle (hell, hell+, dunkel, dunkel+) bereits eine definierte Farbe haben. Das sollte allerdings nicht die Problematik darstellen. Wie sind weitere Meinungen hierzu? Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:00, 18. Sep. 2022 (CEST)

Das nutzen von Wiki-Blau anstelle von ??? in etlichen Vorlagen ist etwas, was ich auf jeden Fall unterstütze. Die tatsächlichen Farben... wahrscheinlich sollten einige geändert werden, andere aber nicht. Da wir bei den Icons einen Mischmasch haben denke ich ist es aber nicht wirklich sinnig die Farben von einer bestimmten Quelle zu nehmen. --Mecanno-man^Mäh 10:19, 18. Sep. 2022 (CEST)

Daher ja die Idee das die Basisfarbe von den neuen Icons deklariert wird und wir für unsere vier Farben Abstufungen davon nehmen. So hätten wir was Typ/Color angeht ein einheitliches Bild und müssten nicht nochmal eine ewige Farbdebatte führen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:25, 18. Sep. 2022 (CEST)

Ich sehe das wie Ryu. Wir haben für die Icons gezielt Farben gewählt, die wir als passend erachten und die sich ausreichend voneinander unterscheiden. Jetzt sollten wir Abstufungen dieser Farben als Typ-Farben verwenden. Und wenn, dann bitte für alle Farben gleich verfahren und dementsprechend alle Farben anpassen.--✦✧  Pk-fan ✧✦ 15:26, 18. Sep. 2022 (CEST)

Ich würde es auch begrüßen, wenn die Typ-Farben allesamt an das jeweils neue Icon angepasst werden, sodass feste Abstufungen des neu gewählten Farbtons genutzt werden. Sich aus den alten Farben die Rosinen herauszupicken und nur einen Teil anzupassen ergibt für mich wenig Sinn. ~ Taisuke ^Diskussion 06:58, 19. Sep. 2022 (CEST)

Da es ja soweit keine Gegenmeinungen gab hab ich einfach mal via Color-Hex geschaut welche Abstufungen es gäbe die ihr in der nachfolgenden Liste seht. Die Abstufung ist überall ident. Meinungen? Allen voran Gegenmeinungen...

Iconfarbe	Parameter	Typ/Color/-hell+			Typ/Color/-hell			Typ/Color/-dunkel			Typ/Color/-dunkel+
		Hex-Code	Farbe Background	Schriftfarbe	Hex-Code	Farbe Background	Schriftfarbe	Hex-Code	Farbe Background	Schriftfarbe	Hex-Code	Farbe Background	Schriftfarbe
bbbbaa	Normal	d6d6cc	d6d6cc	d6d6cc	c8c8bb	c8c8bb	c8c8bb	959588	959588	959588	5d5d55	5d5d55	5d5d55
bb5544	Kampf	ddaaa1	ddaaa1	ddaaa1	c87669	c87669	c87669	954436	954436	954436	5d2a22	5d2a22	5d2a22
96CAFF	Flug	cae4ff	cae4ff	cae4ff	abd4ff	abd4ff	abd4ff	78a1cc	78a1cc	78a1cc	4b657f	4b657f	4b657f
9553cd	Gift	caa9e6	caa9e6	caa9e6	aa75d7	aa75d7	aa75d7	7742a4	7742a4	7742a4	4a2966	4a2966	4a2966
a67439	Boden	d2b99c	d2b99c	d2b99c	b78f60	b78f60	b78f60	845c2d	845c2d	845c2d	533a1c	533a1c	533a1c
bbaa66	Gestein	ddd4b2	ddd4b2	ddd4b2	c8bb84	c8bb84	c8bb84	958851	958851	958851	5d5533	5d5533	5d5533
92C12A	Käfer	c8e094	c8e094	c8e094	a7cd54	a7cd54	a7cd54	749a21	749a21	749a21	496015	496015	496015
6e4370	Geist	b6a1b7	b6a1b7	b6a1b7	8b688c	8b688c	8b688c	583559	583559	583559	372138	372138	372138
aaaabb	Stahl	d4d4dd	d4d4dd	d4d4dd	bbbbc8	bbbbc8	bbbbc8	888895	888895	888895	55555d	55555d	55555d
ff421c	Feuer	ffa08d	ffa08d	ffa08d	ff5432	ff5432	ff5432	cc3416	cc3416	cc3416	7f210e	7f210e	7f210e
2c9be3	Wasser	95cdf1	95cdf1	95cdf1	56afe8	56afe8	56afe8	237cb5	237cb5	237cb5	164d71	164d71	164d71
62BC5A	Pflanze	b0ddac	b0ddac	b0ddac	81c97a	81c97a	81c97a	4e9648	4e9648	4e9648	315e2d	315e2d	315e2d
FFDC00	Elektro	ffed7f	ffed7f	ffed7f	ffe332	ffe332	ffe332	ccb000	ccb000	ccb000	7f6e00	7f6e00	7f6e00
FF6380	Psycho	ffb1bf	ffb1bf	ffb1bf	ff8299	ff8299	ff8299	cc4f66	cc4f66	cc4f66	7f3140	7f3140	7f3140
74CFC0	Eis	b9e7df	b9e7df	b9e7df	8fd8cc	8fd8cc	8fd8cc	5ca599	5ca599	5ca599	3a6760	3a6760	3a6760
5670be	Drache	aab7de	aab7de	aab7de	778ccb	778ccb	778ccb	445998	445998	445998	2b385f	2b385f	2b385f
4e4545	Unlicht	a6a2a2	a6a2a2	a6a2a2	716a6a	716a6a	716a6a	3e3737	3e3737	3e3737	272222	272222	272222
ec8fe6	Fee	f5c7f2	f5c7f2	f5c7f2	efa5eb	efa5eb	efa5eb	bc72b8	bc72b8	bc72b8	765773	765773	765773
68A090	???	b3cfc7	b3cfc7	b3cfc7	86b3a6	86b3a6	86b3a6	538073	538073	538073	345048	345048	345048
5c82ae	#default Wikiblau	adc0d6	adc0d6	adc0d6	7c9bbe	7c9bbe	7c9bbe	49688b	49688b	49688b	2e4157	2e4157	2e4157

* Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 17:38, 19. Sep. 2022 (CEST)

Is mir alles n Tick zu dunkel, insbesondere bei der -dunkel und der -hell+. Ansonsten passts aber im grossen und ganzen. Eventuell ist default und Drache n bisschen nahe beieinander, denke aber nicht das man am default-Wikiblau jetzt gross was ändern gehen sollte. --Mecanno-man^Mäh 19:43, 19. Sep. 2022 (CEST)

Mec schau einfach mal im Testwiki. Dort habe ich die Farben zur Veranschaulichung mal auf die Werte umgestellt. Finde die wirken nun Kräftiger und und nicht mehr so in Pastell-richtung. Denke ist Geschmackssache da kannst dir es allerdings gerne nochmal ansehen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 19:57, 19. Sep. 2022 (CEST)

Ich bin auch noch nicht so wirklich zufrieden mit den Farben. In der direkten Anwendung sind einige der Farben bei hell zwar kräftiger als das was wir aktuell haben, aber zumindest aus meiner Sicht aus einem falschen Grund: Sie sind insgesamt zu dunkel gewählt. Wahrscheinlich wäre es besser hier nochmal die Farben etwas heller zu wählen ebenso bei dunkel. Also effektiv dunkel wird mehr in Richtung von hell geschoben und hell noch ein bisschen angepasst. Ansonsten sieht bei hell vor allem Elektro, Feuer, Wasser und Gift sehr anstrengend aus und alle Farben bei dunkel+ haben etwas sehr graues/dreckiges an sich. Ich weiß aber auch gerade nicht mit welchen "Regeln" Ryu die Farben jetzt generiert hat .
PS: Ich hab mal die nicht vorhandene Klasse bei den Icons gegen inline-CSS getauscht. GrollenKette951 09:33, 20. Sep. 2022 (CEST)

Die Verwendung war im Prinzip ganz einfach. Ausgehend von der Tabelle 10 Stufen bis Schwarz bzw. Weiß habe ich die vier Stufen bei Hell+4, Hell+, Dunkel+ und Dunkel+4 gewählt. Ausgangspuntk war bei allen die Iconfarbe. Die entsprechende Tabelle setze ich einfach einmal mit hier rein, Wenn man sich das Farbspekturm ansieht fand ich eigentlich die Wahl weder zu Dunkel noch zu Hell gut. Wenn man nicht die ganze Tabelle betrachtet dann mag es einem zu Dunkel vorkommen. Durchaus möglich. Natürlich können auch andere Stufen gewählt werden. Mir war es einfach wichtig eine idente Abstufung bei allen Farben zu haben.

Farbtabelle

TYP

Hellste Abstufung #ffffff

Hell+8

Hell+7

Hell+6

Hell+5

Hell+4

Hell+3

Hell+2

Hell+

Hell

Iconfarbe

Dunkel

Dunkel+

Dunkel+2

Dunkel+3

Dunkel+4

Dunkel+5

Dunkel+6

Dunkel+7

Dunkel+8

Dunkelste Abstufung #000000

NORMAL

ffffff

f8f8f6

f1f1ee

eaeae5

e3e3dd

ddddd4

d6d6cc

cfcfc3

c8c8bb

c1c1b2

bbbbaa

a8a899

959588

828276

707066

5d5d55

4a4a44

383833

252522

121211

000000

KAMPF

f8eeec

f1ddd9

eaccc6

e3bbb4

ddaaa1

d6998e

cf887c

c87669

c16656

bb5544

a84c3d

954436

823b2f

703328

5d2a22

4a221b

381914

25110d

120806

FLUG

f4f9ff

eaf4ff

dfefff

d5e9ff

cae4ff

c0dfff

b5d9ff

abd4ff

a0cfff

96caff

87b5e5

78a1cc

698db2

5a7999

4b657f

3c5066

2d3c4c

1e2833

0f1419

GIFT

f4edfa

e9dcf5

dfcbf0

d4baeb

caa9e6

bf97e1

b486dc

aa75d7

9f64d2

9553cd

864ab8

7742a4

683a8f

59317b

4a2966

3b2152

2c183d

1d1029

0e0814

BODEN

f6f1eb

ede3d7

e4d5c3

dbc7af

d2b99c

c9ab88

c09d74

b78f60

ae814c

a67439

956833

845c2d

745127

634522

533a1c

422e16

312211

21170b

100b05

GESTEIN

f8f6ef

f1eee0

eae5d1

e3ddc1

ddd4b2

d6cca3

cfc393

c8bb84

c1b275

bbaa66

a8995b

958851

827647

70663d

5d5533

4a4428

38331e

252214

12110a

KÄFER

f4f8e9

e9f2d4

deecbf

d3e6a9

c8e094

bdd97f

b2d369

a7cd54

9cc73f

92c12a

83ad25

749a21

66871d

577319

496015

3a4d10

2b390c

1d2608

0e1304

GEIST

f0ecf0

e2d9e2

d3c6d4

c5b3c5

b6a1b7

a88ea9

997b9a

8b688c

7c557e

6e4370

633c64

583559

4d2e4e

422843

372138

2c1a2c

211421

160d16

0b060b

STAHL

f6f6f8

eeeef1

e5e5ea

dddde3

d4d4dd

ccccd6

c3c3cf

bbbbc8

b2b2c1

aaaabb

9999a8

888895

767682

666670

55555d

44444a

333338

222225

111112

FEUER

ffece8

ffd9d1

ffc6ba

ffb3a4

ffa08d

ff8d76

ff7a60

ff6749

ff5432

ff421c

e53b19

cc3416

b22e13

992710

7f210e

661a0b

4c1308

330d05

190602

WASSER

e9f5fc

d4ebf9

bfe1f6

aad7f3

95cdf1

80c3ee

6bb9eb

56afe8

41a5e5

2c9be3

278bcc

237cb5

1e6c9e

1a5d88

164d71

113e5a

0d2e44

081f2d

040f16

PFLANZE

eff8ee

dff1de

cfeacd

c0e4bd

b0ddac

a0d69c

91d08b

81c97a

71c26a

62bc5a

58a951

4e9648

44833e

3a7036

315e2d

274b24

1d381b

132512

091209

ELEKTRO

fffbe5

fff8cc

fff4b2

fff199

ffed7f

ffea66

ffe64c

ffe332

ffdf19

ffdc00

e5c600

ccb000

b29a00

998400

7f6e00

665800

4c4200

332c00

191600

PSYCHO

ffeff2

ffdfe5

ffd0d8

ffc0cc

ffb1bf

ffa1b2

ff91a6

ff8299

ff728c

ff6380

e55973

cc4f66

b24559

993b4c

7f3140

662733

4c1d26

331319

19090c

EIS

f1faf8

e3f5f2

d5f0ec

c7ebe5

b9e7df

abe2d9

9dddd2

8fd8cc

81d3c6

74cfc0

68baac

5ca599

519086

457c73

3a6760

2e524c

223e39

172926

0b1413

DRACHE

eef0f8

dde2f2

ccd4eb

bbc5e5

aab7de

99a9d8

889ad1

778ccb

667ec4

5670be

4d64ab

445998

3c4e85

334372

2b385f

222c4c

192139

111626

080b13

UNLICHT

edecec

dbd9d9

c9c7c7

b8b4b4

a6a2a2

948f8f

837c7c

716a6a

5f5757

4e4545

463e3e

3e3737

363030

2e2929

272222

1f1b1b

171414

0f0d0d

070606

FEE

fdf3fc

fbe8fa

f9ddf7

f7d2f5

f5c7f2

f3bbf0

f1b0ed

efa5eb

ed9ae8

ec8fe6

d480cf

bc72b8

a564a1

8d558a

764773

5e395c

462a45

2f1c2e

170e17

???

eff5f3

e0ece8

d1e2dd

c2d9d2

b3cfc7

a4c6bc

95bcb1

86b3a6

77a99b

68a090

5d9081

538073

487064

3e6056

345048

294039

1f302b

14201c

0a100e

Coolness

faedeb

f6dcd8

f2cac5

edb9b2

e9a79f

e5968c

e08479

dc7266

d86153

d45040

be4839

a94033

94382c

7f3026

6a2820

542019

3f1813

2a100c

150806

Schönheit

eff9fc

dff3fa

d0eef8

c0e8f6

b1e3f4

a1ddf1

91d7ef

82d2ed

72cceb

63c7e9

59b3d1

4f9fba

458ba3

3b778b

316374

274f5d

1d3b45

13272e

091317

Putzigkeit

fff2f8

ffe6f2

ffdaeb

ffcee5

ffc2de

ffb5d8

ffa9d1

ff9dcb

ff91c4

ff85be

e577ab

cc6a98

b25d85

994f72

7f425f

66354c

4c2739

331a26

190d13

Klugheit

edf8f1

dbf2e3

c9ecd5

b8e6c7

a6e0b9

94d9ab

83d39d

71cd8f

5fc781

4ec173

46ad67

3e9a5c

368750

2e7345

276039

1f4d2e

173922

0f2617

07130b

Stärke

fefaea

fdf5d5

fcf0c0

fcecac

fbe797

fae282

fade6e

f9d959

f8d444

f8d030

dfbb2b

c6a626

ad9121

947c1c

7c6818

635313

4a3e0e

312909

181404

#default Wikiblau

eef2f6

dee6ee

ced9e6

bdcdde

adc0d6

9db4ce

8ca7c6

7c9bbe

6c8eb6

5c82ae

52759c

49688b

405b79

374e68

2e4157

243445

1b2734

121a22

090d11

* Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:06, 20. Sep. 2022 (CEST)

Muss den beiden etwas weiter oben auch zustimmen. Die Farben sind mir auch zu dunkel. Die hell+-Farbe sollte man als Schriftfarbe auf weißem Hintergrund am besten fast gar nicht erkennen. Wenn ich mir deine Farbtabelle anschaue, würde ich die Iconfarbe als dunkel-Farbe im Wiki verwenden, Dunkel+2 als dunkel+-Farbe, Hell+2 als hell-Farbe und Hell+5 als hell+-Farbe. Dann wären das immer noch gleichmäßige Schritte zwischen den Farben aber er passt meiner Meinung nach besser zu den jeweiligen Nutzen der Farben im Wiki.--✦✧  Pk-fan ✧✦ 18:56, 22. Sep. 2022 (CEST)

Nach kurzer Überlegung gefällt mir Hell+7 → Hell+3 → Iconfarbe → Dunkel+3 vielleicht sogar noch besser. Grenzt die Farben nochmal besser ab, ist nah am Helligkeitsgrad der aktuell noch verwendeten Farben und trotzdem sind die Schritte zwischen den Farben gleich groß. Meinungen?--✦✧  Pk-fan ✧✦ 19:01, 22. Sep. 2022 (CEST)

Also Hell+7 finde ich viel zu hell da ich der Meinung bin das Schrift immer unabhängig der Farbe lesbar sein sollte was ich da schon zu grenzwertig finde. Wäre da für maximal hell+5. Und die Iconfarbe als Dunkel wäre ich auch dagegen damit für Probleme mit Hintergrund vermeiden. Daher ja das Icon im Zentrum von welcher wir die Abweichungen bestimmen. Würde daher sagen hell+5, hell+2, icon, dunkel/dunkel+ und dunkel+2/dunkel+3 was die Farben dadurch wieder insgesamt heller wie mein Vorschlag machen würde. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 19:30, 22. Sep. 2022 (CEST)

Aber haben wir nicht extra den transparenten Border bei den Icons angefügt, damit wir die Icon-Farbe als dunkel-Farbe dahinter verwenden können?--✦✧  Pk-fan ✧✦ 19:46, 22. Sep. 2022 (CEST)

Gute Initiative, hier Ordnung in die Farben zu kriegen. Bei den Abstufungen stimme ich Ryus letztem Beitrag zu, die Extremfarben sollten schwarz und weiß nicht zu sehr ähneln, sonst sind sie schwer tatsächlich verbaubar. Seinen Vorschlägen kann ich mich gut anschließen. Maxmiran 10:57, 28. Sep. 2022 (CEST)

Die aktuellen Farben im Testwiki sind mir etwas zu kräftig. Hatte mich gestern schon gewundert, warum das so sehr intensiv aussieht. Allgemein brauchen Farbextreme mMn nicht immer lesbar sein, da manche Farben auch allein für grafische Elemente, wie Ränder oder Hintergründe, da sein können. Ich finde außerdem, dass zumindest die hellen Extreme auch ruhig nah an komplettem Weiß dran sein können. Die brauchen dann halt nen Rand drum rum, können aber quasi ein weißer Hintergrund mit seichtem Farbtouch sein.--DeXter 15:06, 28. Sep. 2022 (CEST)

Ich habe mich nun jetzt endlich auch mal an den Farben versuchen können und muss sagen, dass die Tabelle von Ryu schonmal einen guten Aufschluss gibt, in welche Richtung das gehen sollte. Ich habe in einem Versuch hell+5, hell+3 und hell für hell, mittel und dunkel ausgesucht und diese Farben werden nun in den Pokémon-Artikeln im Testwiki verwendet. Schaut es euch gerne an. Ich finde, dass die helleren Farben einen deutlich leichteren Eindruck machen und nicht mehr so schwer wiegen wie unsere bisherigen. -- ~~ feblue 21:42, 3. Okt. 2022 (CEST)

Mein erster Eindruck war nicht gut. Erstens benötigen wir 4 Farben zweitens finde ich das ganze schon sehr Pastellhaft was mir überhaupt nicht zusagt. Ich finde eine Dunkle und eine sehr dunkle Farbe sollten immer dunkler wie der Ausgangspunkt sein und nicht heller * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:43, 3. Okt. 2022 (CEST)

Upsi, danke, dass du so schnell reagierst, den Anstoß hatte ich jetzt gar nicht mehr untergebracht: Ich würde generell auch versuchen wollen, von vier Farben wegzukommen. Unsere Tabellen und Vorlagen sollten mit maximal drei Farben gleichzeitig klarkommen können, es sei denn, irgendeine Stelle braucht optisch unbedingt vier, weil sonst die Tabellenhierarchie gestört ist. Da lasse ich mich auch gerne eines besseren belehren, da kann man dann natürlich auch noch eine vierte Farbe auswählen. Ich würde allerdings eher befürworten, dass diese Tabelle oder Vorlage dann umgebaut wird, damit wir in Zukunft auf drei Farben setzen. -- ~~ feblue 23:27, 3. Okt. 2022 (CEST)

Wir sprechen hier von über 5000 einbindungen die geprüft werden müssen ob ein verändertes Farbschema von 4 auf 3 noch passt. Generell bin ich nicht dagegen. Ich würde allerdings vorschlagen das wir erstmal noch bei unseren 4 Farben bleiben. Einfach damit die Diskussion voran kommt und vor KaPu umgesetzt werden kann. Nach dem Release kann man ja gerne nochmal eine separate Diskussion starten zwecks Reduktion auf drei. Das sprengt sonst i.wie den Rahmen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 07:48, 4. Okt. 2022 (CEST)

Nachtrag. @Fe hab mal die Vorlagen im Testwiki nochmal angepasst so das die Farbgebung überall zu sehen ist und sich nicht nur auf die Pokémon beschränkt. Bin nochmal Gedanklich die Farbtabelle durch und würde für mich Folgends bevorzugen:

• Hell+5 → Hell+
• Hell+2 → Hell
• Dunkel → Dunkel
• Dunkel+, Dunkel+2 oder Dunkel+3 → Dunkel+

Bei der dunkelsten Farbe bin ich noch etwas unentschlossen, tendiere allerdings zu Dunkel+3 Da es zum Dunklen Farbton ähnlich wie beim Hellen eine größere Steigerung ist. Zwischen Dunkel und Dunkel+2 finde ich den Kontrast nicht stark genug. zur besseren Übersicht die entsprechende Farbpalette auf die ich persönlich es eingrenzen würde.

TYP	Hell+ (Hell+5)	Hell (Hell+2)	Iconfarbe	Dunkel (Dunkel)	Dunkel+	Dunkel+2	Dunkel+ (Dunkel+3)
NORMAL	e3e3dd	cfcfc3	bbbbaa	a8a899	959588	828276	707066
KAMPF	e3bbb4	cf887c	bb5544	a84c3d	954436	823b2f	703328
FLUG	d5e9ff	b5d9ff	96caff	87b5e5	78a1cc	698db2	5a7999
GIFT	d4baeb	b486dc	9553cd	864ab8	7742a4	683a8f	59317b
BODEN	dbc7af	c09d74	a67439	956833	845c2d	745127	634522
GESTEIN	e3ddc1	cfc393	bbaa66	a8995b	958851	827647	70663d
KÄFER	d3e6a9	b2d369	92c12a	83ad25	749a21	66871d	577319
GEIST	c5b3c5	997b9a	6e4370	633c64	583559	4d2e4e	422843
STAHL	dddde3	c3c3cf	aaaabb	9999a8	888895	767682	666670
FEUER	ffb3a4	ff7a60	ff421c	e53b19	cc3416	b22e13	992710
WASSER	aad7f3	6bb9eb	2c9be3	278bcc	237cb5	1e6c9e	1a5d88
PFLANZE	c0e4bd	91d08b	62bc5a	58a951	4e9648	44833e	3a7036
ELEKTRO	fff199	ffe64c	ffdc00	e5c600	ccb000	b29a00	998400
PSYCHO	ffc0cc	ff91a6	ff6380	e55973	cc4f66	b24559	993b4c
EIS	c7ebe5	9dddd2	74cfc0	68baac	5ca599	519086	457c73
DRACHE	bbc5e5	889ad1	5670be	4d64ab	445998	3c4e85	334372
UNLICHT	b8b4b4	837c7c	4e4545	463e3e	3e3737	363030	2e2929
FEE	f7d2f5	f1b0ed	ec8fe6	d480cf	bc72b8	a564a1	8d558a
???	c2d9d2	95bcb1	68a090	5d9081	538073	487064	3e6056
Coolness	edb9b2	e08479	d45040	be4839	a94033	94382c	7f3026
Schönheit	c0e8f6	91d7ef	63c7e9	59b3d1	4f9fba	458ba3	3b778b
Putzigkeit	ffcee5	ffa9d1	ff85be	e577ab	cc6a98	b25d85	994f72
Klugheit	b8e6c7	83d39d	4ec173	46ad67	3e9a5c	368750	2e7345
Stärke	fcecac	fade6e	f8d030	dfbb2b	c6a626	ad9121	947c1c
#default Wikiblau	bdcdde	8ca7c6	5c82ae	52759c	49688b	405b79	374e68

* Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:48, 4. Okt. 2022 (CEST)

Ich habe mich gerade beispielhaft durch verschiedene Pokémon-Artikel im Testwiki geklickt und empfinde die dort von dir gewählten Farben als äußerst stimmig, Ryu. Mir gefällt der letztgenannte Vorschlag der Farben! ~ Taisuke ^Diskussion 17:33, 13. Okt. 2022 (CEST)

Danke Tai, persönlich gefällt es mir auch da es eine gute Mischung von hell und Dunkel ist. Damit das auch andere gut vergleichen können habe ich sämtliche Farben durch Hell+5 (→ Hell+), Hell+2 (→ Hell), Dunkel (→ Dunkel) und Dunkel+3 → (Dunkel+) im Testwiki mal ersetzt. Es wäre schön wenn sich alle beteiligten nochmal einen Überblick verschaffen (Taisuke, Mecanno-man, Pk-fan, Maxmiran, GrollenKette951, DeXter und Feblue. Wenn es keine gravierenden Gegenmeinungen gibt würde ich am Montag eine 14tägige 4-teilige Abstimmung starten (je Farbstufe) mit 3 Optionen (A: passt so; B: muss heller und C: muss dunkler) starten. So das wir ggf. inkl. Stichwahl bis KaPu das ganze erledigt haben. Die Verringerung auf lediglich 3 Farben würde ich bis nach KaPu-Release vertagen da es eh erstmal eine Auswertung bräuchte welche Kombinationen von hellen, dunklen sowie +-tönen genutzt werden. Da ja hier wenn auch Vorlagen Farbtechnisch angepasst werden müssten. Das ganze sprengt allerdings den Rahmen deshalb später. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:05, 13. Okt. 2022 (CEST)

Ich find die neuen Farben super, nur finde ich Gelb noch immer zu grell in den Infoboxen und auch das Icon sieht auf meinen Bildschirm matschig aus. Weiss nicht ob so ein grelles gelb für Vorlagen so geeignet ist. --Jass 16:15, 14. Okt. 2022 (CEST)

Ich bin auch happy mit den Farben aus dem Testwiki @Ryu. 👍
Muss Jass beim Elektro-Icon aber übrigens auch Recht geben. Es ist wirklich zu hell, sodass Buo(?) ihm sogar als einzigem einen Text-Shadow geben musste, was das Icon doch nochmal anders wirken lässt. Vielleicht sollten wir alle da noch mal über eine dunklere Farbe fürs Icon (und damit auch für die Color) nachdenken…--✦✧  Pk-fan ✧✦ 17:24, 14. Okt. 2022 (CEST)

Ich bleibe bei meinem Farbvorschlag aus dieser Version mit hell+5, hell+3, hell und dunkel+, um dem aktuellen Farbschema ein wenig zu entrinnen und hellere Farben auszusuchen, aber das soll jetzt nicht den Start einer Abstimmung verhindern. Von mir aus können wir das mit den drei Typ-Farben auch gerne nächstes Jahr besprechen, wenn das jetzt als zu viel Aufwand gesehen wird. Die Abstimmung und die Möglichkeiten an sich erscheinen mir sinnvoll, das sollte genug Spielraum geben, um ein schönes Ergebnis zu erhalten. 👍 -- ~~ feblue 00:07, 17. Okt. 2022 (CEST)

Ich hätte für Gelb eine Alternative von einer off. Seite hier https://sg.portal-pokemon.com/play/pokedex/025. Die Farbe wäre #e4b743 Die Farbe ist keiner der anderen Typen ähnlich und sie ist ohne Shadow auch gut leserlich. Was haltet ihr davon? Hier könnt ihr den Unterschied sehen: https://cdn.discordapp.com/attachments/247300276732559360/1037040852683477022/unknown.png https://cdn.discordapp.com/attachments/247300276732559360/1037040888754487376/unknown.png --Jass 17:29, 1. Nov. 2022 (CET)

Ein spannender Vorschlag, Jass. Diesen sollte man aber im Anschluss oder gesondert diskutieren, weil mit der Änderung der Icon-Farbe alle Color-Vorlagen des Elektro-Typs vermutlich ebenfalls angepasst werden müssten. ~ Taisuke ^Diskussion 19:24, 1. Nov. 2022 (CET)

Abstimmung beendet: Farbvorschlag passt→ Hell+: 12/21 Stimmen — Hell: 14/21 Stimmen — Dunkel+:18/21 Stimmen | Dunkel: Neue Abstimmung Teil 2 ↓

Abstimmung

In diesen 4 Abstimmungen geht es um die Farbdefinitionen für Typ/Color, sowie Wettbewerb/Color und unsere #default Farbe. Hierzu hatte ich die Farben auch im TestWiki einmal hinterlegt was allgemein auf Anklang stieß. Im Spoiler befindet sich eine Tabelle mit weiteren Abstufungen falls jemand mit den gewählten Farbstufe nicht zufrieden ist. Elektro weist häufig eine ähnlichkeit zu Stärke auf. Hier zeigte sich bereits in der Diskussion das ggf. hier noch einmal bei der Grundfarbe nachjustiert werden sollte. Dazu läuft bereits ein internes Meinungsbild. Dieses hat keinen Einfluss auf die Wahl der Farbintensitäten. Jeder stimmberechtigte Benutzer darf pro Abstimmung eine Stimme abgeben. Die Abstimmungen laufen bis zum 30. Oktober 2022 um 22:00. Heute ist der 16.04.2024 09:13 Uhr.

TYP	Hell+ (Hell+5)	Hell (Hell+2)	Iconfarbe	Dunkel (Dunkel+2)	Dunkel+ (Dunkel+3)
NORMAL	e3e3dd	cfcfc3	bbbbaa	828276	707066
KAMPF	e3bbb4	cf887c	bb5544	823b2f	703328
FLUG	d5e9ff	b5d9ff	96caff	698db2	5a7999
GIFT	d4baeb	b486dc	9553cd	683a8f	59317b
BODEN	dbc7af	c09d74	a67439	745127	634522
GESTEIN	e3ddc1	cfc393	bbaa66	827647	70663d
KÄFER	d3e6a9	b2d369	92c12a	66871d	577319
GEIST	c5b3c5	997b9a	6e4370	4d2e4e	422843
STAHL	dddde3	c3c3cf	aaaabb	767682	666670
FEUER	ffb3a4	ff7a60	ff421c	b22e13	992710
WASSER	aad7f3	6bb9eb	2c9be3	1e6c9e	1a5d88
PFLANZE	c0e4bd	91d08b	62bc5a	44833e	3a7036
ELEKTRO	fff199	ffe64c	ffdc00	b29a00	998400
PSYCHO	ffc0cc	ff91a6	ff6380	b24559	993b4c
EIS	c7ebe5	9dddd2	74cfc0	519086	457c73
DRACHE	bbc5e5	889ad1	5670be	3c4e85	334372
UNLICHT	b8b4b4	837c7c	4e4545	363030	2e2929
FEE	f7d2f5	f1b0ed	ec8fe6	a564a1	8d558a
???	c2d9d2	95bcb1	68a090	487064	3e6056
Coolness	edb9b2	e08479	d45040	94382c	7f3026
Schönheit	c0e8f6	91d7ef	63c7e9	458ba3	3b778b
Putzigkeit	ffcee5	ffa9d1	ff85be	b25d85	994f72
Klugheit	b8e6c7	83d39d	4ec173	368750	2e7345
Stärke	fcecac	fade6e	f8d030	ad9121	947c1c
#default Wikiblau	bdcdde	8ca7c6	5c82ae	405b79	374e68

Abstimmung 1: hell+

Für hell+ wurde die Abstufung HELL+5 aus der großen Tabelle gewählt. Setzt man diese Farbe als Hinergrund für unsere Icons würde dies Beispielsweise so aussehen:

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee
???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

Farbe soll heller sein

1. Bin für hell+7. Die hell+-Farben waren mal dazu gedacht, auf den dunkel+-Farben als Schriftfarbe nutzbar zu sein. Das wird erst möglich, wenn sie näher an weiß dran sind.--✦✧  Pk-fan ✧✦ 03:31, 19. Okt. 2022 (CEST)
2. --Mecanno-man^Mäh 12:04, 22. Okt. 2022 (CEST)
3. Ratequaza 14:02, 23. Okt. 2022 (CEST)
4. hell+ sollte sich nur schwach von weiß unterscheiden, daher bin ich auch für hell+7. – Vircaprae 23:57, 23. Okt. 2022 (CEST)
5. Eden 16:50, 24. Okt. 2022 (CEST)
6. Hell +6 oder Hell+7 fände ich hier besser Mooni000 ^{Pelipper-Post} 17:31, 25. Okt. 2022 (CEST)
7. BeyJim ^Diskussion 12:27, 27. Okt. 2022 (CEST)
8. BlauesSerpiroyal^{Disssskussion} 20:48, 27. Okt. 2022 (CEST)
9. hell+ ist helles Extremum, also sollte das imo. nur nen ganz seichten Farbtouch haben, bin für hell+7 --DeXter 17:55, 28. Okt. 2022 (CEST)

Farbwahl passt für mich

1. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:49, 17. Okt. 2022 (CEST)
2. ~~ DieTaube 18:03, 17. Okt. 2022 (CEST)
3. -- ~~ feblue 23:20, 17. Okt. 2022 (CEST)
4. Cliffichen 09:54, 18. Okt. 2022 (CEST)
5. —DaneeBound 11:51, 22. Okt. 2022 (CEST)
6. AAWiki ^Diskussion 00:18, 23. Okt. 2022 (CEST)
7. Noch näher an weiß heranrücken klingt für mich nicht sinnvoll, dann unterscheiden sich die Farben kaum untereinander. In entsprechenden Anwendungsfällen nimmt man dann halt tatsächliches weiß. Maxmiran 19:33, 24. Okt. 2022 (CEST)
8. Kernseife ^Diskussion 16:37, 25. Okt. 2022 (CEST)
9. Ich kam, sah und bearbeitete Bennett ^Diskussion 20:48, 28. Okt. 2022 (CEST)
10. ~ Taisuke ^Diskussion 20:02, 29. Okt. 2022 (CEST)
11. -- RobbiRobb 22:33, 29. Okt. 2022 (CEST)
12. GrollenKette951 22:39, 29. Okt. 2022 (CEST)
13. DeepSpace (Diskussion) - 22:03, 30. Okt. 2022 (CET)

soll dunkler sein

Enthaltung

Abstimmung 2: hell

Für hell wurde die Abstufung HELL+2 aus der großen Tabelle gewählt. Setzt man diese Farbe als Hintergrund für unsere Icons würde dies Beispielsweise so aussehen:

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee
???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

Farbe soll heller sein

1. Hell+3. -- ~~ feblue 23:20, 17. Okt. 2022 (CEST)
2. Bin auch für hell+3.--✦✧  Pk-fan ✧✦ 03:31, 19. Okt. 2022 (CEST)
3. Wenn hell+ und dunkel heller werden, sollte das auch heller werden. – Vircaprae 23:57, 23. Okt. 2022 (CEST)
4. Eden 16:50, 24. Okt. 2022 (CEST)
5. Hell+3 Mooni000 ^{Pelipper-Post} 17:31, 25. Okt. 2022 (CEST)
6. BlauesSerpiroyal^{Disssskussion} 20:48, 27. Okt. 2022 (CEST)
7. DeXter 17:55, 28. Okt. 2022 (CEST)

Farbwahl passt für mich

1. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:49, 17. Okt. 2022 (CEST)
2. ~~ DieTaube 18:03, 17. Okt. 2022 (CEST)
3. Cliffichen 09:54, 18. Okt. 2022 (CEST)
4. —DaneeBound 11:55, 22. Okt. 2022 (CEST)
5. --Mecanno-man^Mäh 12:04, 22. Okt. 2022 (CEST)
6. AAWiki ^Diskussion 00:16, 23. Okt. 2022 (CEST)
7. Ratequaza 14:02, 23. Okt. 2022 (CEST)
8. Maxmiran 19:33, 24. Okt. 2022 (CEST)
9. Kernseife ^Diskussion 16:37, 25. Okt. 2022 (CEST)
10. BeyJim ^Diskussion 12:27, 27. Okt. 2022 (CEST)
11. Ich kam, sah und bearbeitete Bennett ^Diskussion 20:48, 28. Okt. 2022 (CEST)
12. ~ Taisuke ^Diskussion 20:02, 29. Okt. 2022 (CEST)
13. -- RobbiRobb 22:33, 29. Okt. 2022 (CEST)
14. GrollenKette951 22:39, 29. Okt. 2022 (CEST)
15. DeepSpace (Diskussion) - 22:03, 30. Okt. 2022 (CET)

Farbe soll dunkler sein

Enthaltung

Abstimmung 3: dunkel

Für dunkel wurde die Abstufung DUNKEL aus der großen Tabelle gewählt. Setzt man diese Farbe als Hintergrund für unsere Icons würde dies Beispielsweise so aussehen:

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee
???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

Farbe soll heller sein

1. hell. -- ~~ feblue 23:20, 17. Okt. 2022 (CEST)
2. Bin für die Iconfarbe. Dann kann die dunkle Farbe gut als Hintergrund für die Icons genutzt werden, die durch ihren Rahmen automatisch gut vom Hintergrund abgrenzen. (Das war ja sogar eines der Argumente für die Einführung des Rahmens um die Icons.)--✦✧  Pk-fan ✧✦ 03:31, 19. Okt. 2022 (CEST)
3. --Mecanno-man^Mäh 12:04, 22. Okt. 2022 (CEST)
4. Es sollte bedacht werden, dass in vielen Artikeln schwarze Schrift auf der dunkel-Farbe benutzt wird. Bei z. B. Unlicht und Geist ist das kaum noch lesbar, daher müssen hier hellere Farben gewählt werden. – Vircaprae 23:57, 23. Okt. 2022 (CEST)
5. Eden 16:50, 24. Okt. 2022 (CEST)
6. Fände hier ein Zwischending zwischen Iconsfarbe und dunkel gut Mooni000 ^{Pelipper-Post} 17:31, 25. Okt. 2022 (CEST)
7. BlauesSerpiroyal^{Disssskussion} 20:48, 27. Okt. 2022 (CEST)
8. DeXter 17:55, 28. Okt. 2022 (CEST)
9. Ich kam, sah und bearbeitete Bennett ^Diskussion 20:48, 28. Okt. 2022 (CEST)
10. -- RobbiRobb 22:33, 29. Okt. 2022 (CEST)
11. GrollenKette951 22:39, 29. Okt. 2022 (CEST)
12. Zwei nur leicht verschiedene Farben sehen bisschen weird aus. Fände also auch Icon-Farbe besser. DeepSpace (Diskussion) - 22:03, 30. Okt. 2022 (CET)

Farbwahl passt für mich

1. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:49, 17. Okt. 2022 (CEST)
2. Cliffichen 09:54, 18. Okt. 2022 (CEST)
3. AAWiki ^Diskussion 00:18, 23. Okt. 2022 (CEST)
4. Maxmiran 19:33, 24. Okt. 2022 (CEST)
5. Kernseife ^Diskussion 16:37, 25. Okt. 2022 (CEST)
6. ~ Taisuke ^Diskussion 20:02, 29. Okt. 2022 (CEST)

Farbe soll dunkler sein

1. ~~ DieTaube 18:03, 17. Okt. 2022 (CEST)
2. —DaneeBound 11:55, 22. Okt. 2022 (CEST)
3. Ratequaza 14:02, 23. Okt. 2022 (CEST)
4. BeyJim ^Diskussion 12:27, 27. Okt. 2022 (CEST)

Enthaltung

Abstimmung 4: dunkel+

Für dunkel+ wurde die Abstufung DUNKEL+3 aus der großen Tabelle gewählt. Setzt man diese Farbe als Hintergrund für unsere Icons würde dies Beispielsweise so aussehen:

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee
???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

Farbe soll heller sein

1. Dunkel+. -- ~~ feblue 23:20, 17. Okt. 2022 (CEST)
2. Dunkel+ oder Dunkel+2 -- Cliffichen 09:54, 18. Okt. 2022 (CEST)

Farbwahl passt für mich

1. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:49, 17. Okt. 2022 (CEST)
2. ~~ DieTaube 18:03, 17. Okt. 2022 (CEST)
3. Passt, ist nicht zu weit von Schwarz weg, könnte als Schriftfarbe auf Weiß oder hell+ genutzt werden und sorgt für einen gleichmäßigen "Abstand" zwischen allen vier Farbvarianten, für die ich gestimmt habe.--✦✧  Pk-fan ✧✦ 03:31, 19. Okt. 2022 (CEST)
4. —DaneeBound 11:54, 22. Okt. 2022 (CEST)
5. AAWiki ^Diskussion 00:20, 23. Okt. 2022 (CEST)
6. Ratequaza 14:02, 23. Okt. 2022 (CEST)
7. – Vircaprae 23:57, 23. Okt. 2022 (CEST)
8. Eden 16:50, 24. Okt. 2022 (CEST)
9. Maxmiran 19:33, 24. Okt. 2022 (CEST)
10. Kernseife ^Diskussion 16:37, 25. Okt. 2022 (CEST)
11. Mooni000 ^{Pelipper-Post} 17:31, 25. Okt. 2022 (CEST)
12. BeyJim ^Diskussion 12:27, 27. Okt. 2022 (CEST)
13. BlauesSerpiroyal^{Disssskussion} 20:48, 27. Okt. 2022 (CEST)
14. DeXter 17:55, 28. Okt. 2022 (CEST)
15. Ich kam, sah und bearbeitete Bennett ^Diskussion 20:48, 28. Okt. 2022 (CEST)
16. ~ Taisuke ^Diskussion 20:02, 29. Okt. 2022 (CEST)
17. -- RobbiRobb 22:33, 29. Okt. 2022 (CEST)
18. GrollenKette951 22:39, 29. Okt. 2022 (CEST)
19. Heller sollte es wahrscheinlich nicht sein, denn dazu ist es ja dunkel+. DeepSpace (Diskussion) - 22:03, 30. Okt. 2022 (CET)

Farbe soll dunkler sein

Enthaltung

1. Bin generell nicht so ein Fan von dunkel+. --Mecanno-man^Mäh 12:04, 22. Okt. 2022 (CEST)

Kommentare

So nun noch der Ping an alle Abstimmungsberechtigten. AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, Der Sternendiamantritter, DomiDsLP, Eden Ediz, Goloer444, Jardan, Jass, Lasagne, Mario-WL, Nescientist, Panflami, PokéSpe, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Kernseife, Killuu, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:49, 17. Okt. 2022 (CEST)

Ich finde das Coolness-Icon sollte mehr orange sein. Das scheint mir völlig daneben. Das Isso 08/15 ^Konter 23:44, 17. Okt. 2022 (CEST)

Laut VC wurde die Farbe aus ΩRαS gewählt. Also aus diesem Icon . Auch das neuste Icon ist eher bräunlich. In Richtung Orange war es lediglich in der dritten Gen. Derartige Änderungen gehören allerdings nicht in diese Abstimmung da es hier rein um die allgemeinen Abstuffungen geht. Also wie hell, dunkel soll die Abstuffung werden. Bei der Grundfarbe des Icons kann man ja separat nochmal Diskutieren was plötzlich gegen die Farbe aus Gen6 spricht. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 23:51, 17. Okt. 2022 (CEST)

Abstimmung Teil 2 (Dunkel)

Abstimmung beendet: Option D: Dunkel für Dunkel 11/20 Stimmen

In dieser Abstimmung geht es um die Farbdefinitionen für Typ/Color, sowie Wettbewerb/Color und unsere #default Farbe für Dunkel. Hierzu hatte ich die Farben auch im TestWiki einmal hinterlegt was allgemein auf Anklang stieß. In der vorherigen Abstimmung gab es in innerhalb der Spalte Dunkel einen Fehler. Daher findet sich der reguläre Farbvorschlag nochmal in dieser Abstimmung. Jeder stimmberechtigte Benutzer darf pro Abstimmung eine Stimme abgeben. Die Abstimmungen laufen bis zum 6. November 2022 um 23:59. Heute ist der 16.04.2024 09:13 Uhr.

TYP	Farbe für Hell+	Farbe für Hell	Farbvorschläge für Dunkel				Farbe für Dunkel+
	Hell+5	Hell+2	Hell+	Hell	Iconfarbe	Dunkel	Dunkel+3
Normal	e3e3dd	cfcfc3	c8c8bb	c1c1b2	bbbbaa	a8a899	707066
Kampf	e3bbb4	cf887c	c87669	c16656	bb5544	a84c3d	703328
Flug	d5e9ff	b5d9ff	abd4ff	a0cfff	96caff	87b5e5	5a7999
Gift	d4baeb	b486dc	aa75d7	9f64d2	9553cd	864ab8	59317b
Boden	dbc7af	c09d74	b78f60	ae814c	a67439	956833	634522
Gestein	e3ddc1	cfc393	c8bb84	c1b275	bbaa66	a8995b	70663d
Käfer	d3e6a9	b2d369	a7cd54	9cc73f	92c12a	83ad25	577319
Geist	c5b3c5	997b9a	8b688c	7c557e	6e4370	633c64	422843
Stahl	dddde3	c3c3cf	bbbbc8	b2b2c1	aaaabb	9999a8	666670
Feuer	ffb3a4	ff7a60	ff6749	ff5432	ff421c	e53b19	992710
Wasser	aad7f3	6bb9eb	56afe8	41a5e5	2c9be3	278bcc	1a5d88
Pflanze	c0e4bd	91d08b	81c97a	71c26a	62bc5a	58a951	3a7036
Elektro	fff199	ffe64c	ffe332	ffdf19	ffdc00	e5c600	998400
Psycho	ffc0cc	ff91a6	ff8299	ff728c	ff6380	e55973	993b4c
Eis	c7ebe5	9dddd2	8fd8cc	81d3c6	74cfc0	68baac	457c73
Drache	bbc5e5	889ad1	778ccb	667ec4	5670be	4d64ab	334372
Unlicht	b8b4b4	837c7c	716a6a	5f5757	4e4545	463e3e	2e2929
Fee	f7d2f5	f1b0ed	efa5eb	ed9ae8	ec8fe6	d480cf	8d558a
???	c2d9d2	95bcb1	86b3a6	77a99b	68a090	5d9081	3e6056
Coolness	edb9b2	e08479	dc7266	d86153	d45040	be4839	7f3026
Schönheit	c0e8f6	91d7ef	82d2ed	72cceb	63c7e9	59b3d1	3b778b
Putzigkeit	ffcee5	ffa9d1	ff9dcb	ff91c4	ff85be	e577ab	994f72
Klugheit	b8e6c7	83d39d	71cd8f	5fc781	4ec173	46ad67	2e7345
Stärke	fcecac	fade6e	f9d959	f8d444	f8d030	dfbb2b	947c1c
#default Wikiblau	bdcdde	8ca7c6	7c9bbe	6c8eb6	5c82ae	52759c	374e68

Option A: Hell+ für Dunkel

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee	???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

Option B: Hell für Dunkel

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee	???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

Option C: Iconfarbe für Dunkel

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee	???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

1. Ist für mich optisch am ansprechendsten, gerade wenn es darum geht, die Icons auf der Farbe zu verwenden. Die dunkle Farbe ist mir im Vergleich zu den aktuellen Farben hingegen zu dunkel. Das fällt bspw. bei den Charakter-Infoboxen auf, bei denen aktuell mit schwarzer Schrift auf der dunklen Farbe geschrieben wird.--✦✧  Pk-fan ✧✦ 00:19, 31. Okt. 2022 (CET)
2. Ich schätze, es sollte passen. AAWiki ^Diskussion 15:46, 31. Okt. 2022 (CET)
3. Ich sehe keinen Grund dafür, dass die dunkel-Farbe dunkler als das Icon sein sollte. Die Namen hell und dunkel sind ja auch nur zur Unterscheidung voneinander, man hätte die genauso gut Farbe1, Farbe2, Farbe3 und Farbe4 nennen können. Ist ja auch nicht so, als ob die Iconfarbe irgendwie farblich neutral wäre. Ich denke passende Farben wären Hell oder die Iconfarbe, aber da bei Hell vermutlich keine Mehrheit zustande kommt, stimme ich hierfür. – Vircaprae 22:22, 2. Nov. 2022 (CET)
4. Ich würde mir zwar eigentlich noch eine kleine Abstufung von der Iconfarbe wünschen, aber von der Helligkeit passt das gut. Mooni000 ^{Pelipper-Post} 10:33, 3. Nov. 2022 (CET)
5. Im Verhältnis zu den anderen Farben ist diese Variante meiner Meinung nach am harmonischsten. ~ Eden 00:43, 4. Nov. 2022 (CET)
6. -- ~~ feblue 15:42, 5. Nov. 2022 (CET)
7. Ich erkenne ledigdlich einen geringen Unterschied zwischen den einzelnen Farbstufen, aber wenn ich hier noch mal alle vor mir sehe, gefällt mir diese Kombination am besten. Ich kam, sah und bearbeitete Bennett ^Diskussion 16:47, 6. Nov. 2022 (CET)
8. Ich denke, die Farbe der Icons sollte eine der benannten Farben im PokéWiki sein. Nach den bereits genannten Argumenten denke ich zudem, dass diese Farben aktuell besser an die Stellen im PokéWiki passen, an denen „Dunkel“ verwendet wird. Langfristig könnte man aber darüber nachdenken, diese Farbe in „Standard“ umzubenennen und den Namen „Dunkel“ stattdessen für eine zusätzliche Abstufung zwischen der Iconfarbe und „Dunkel+“ zu verwenden. --Lasagne (Diskussion) 18:06, 6. Nov. 2022 (CET)
9. Nach langer Überlegung und Abwägung viel meine Entscheidung auf diese Kombi, wirkt irgendwie am Besten Vaulty 23:38, 6. Nov. 2022 (CET)

Option D: Dunkel für Dunkel

Normal	Kampf	Flug	Gift	Boden	Gestein	Käfer	Geist	Stahl
Feuer	Wasser	Pflanze	Elektro	Psycho	Eis	Drache	Unlicht	Fee	???
Cooln.	Schönh.	Putzigk.	Klugh.	Stärke
#default

1. Wie auch schon in der vorherigen Abstimmung. Die Farben sollen eine Abstufung unserer Icons sein. Daher fände ich es falsch die Iconfarbe zu verwenden. Desweiteren geht es um die Farbe Dunkel. Sie sollte mMn daher auch Dunkler und nicht Heller wie der Ausgangspunkt sein. Daher bleibt für mich lediglich diese Option. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 23:41, 30. Okt. 2022 (CET)
2. Ich denke auch, dass die Iconfarbe der Ausgangspunkt ist. Unter "Dunkel" stelle ich mir daher etwas dunkleres als diese Farbe vor. -- Cliffichen 00:20, 31. Okt. 2022 (CET)
3. Für mich eine klare Sache, sehe das wie meine Vorredner. An der Iconfarbe orientieren und dann dunkler als die Iconfarbe. Kernseife ^Diskussion 08:38, 31. Okt. 2022 (CET)
4. Eigentlich finde ich selbst diese Variante zu hell, da der Abstand zu dunkel+ einfach immens ist, während der Abstand zur Icon-Farbe sehr klein ist. Maxmiran 12:36, 31. Okt. 2022 (CET)
5. Ich schließe mich da an, dunkel sollte dunkler als das Icon sein. Ratequaza 14:38, 31. Okt. 2022 (CET)
6. Sehe es ähnlich wie Max. ~ Taisuke ^Diskussion 19:24, 1. Nov. 2022 (CET)
7. Dunkel ist nicht wirklich dunkel, aber ja. GrüßeShortyBuzz 23:00, 1. Nov. 2022 (CET)
8. Nachdem ich jetzt endlich den Unterschied verstanden habe. --Toben des Meeres. Killuu 12:19, 3. Nov. 2022 (CET)
9. Ich hatte in der ursprünglichen Abstimmung gegen die dunkleren Farben in der Übersicht abgestimmt, obwohl diese nie zur Wahl standen und nur versehentlich in der Liste gelandet waren, während ich mit diesen Farben auch schon in der letzten Runde zufrieden gewesen wäre. Da das Missverständnis jetzt aber geklärt wurde, hier meine Stimme, auch wenn ich damit der Stimme aus meiner ersten Runde widerspreche. -- RobbiRobb 18:19, 5. Nov. 2022 (CET)
10. —DaneeBound 15:47, 6. Nov. 2022 (CET)
11. GrollenKette951 23:11, 6. Nov. 2022 (CET)

Enthaltung

Ich fürchte, meine Augen sind nicht gut genug, die sehen irgenwie alle gleich für mich aus. Das Isso 08/15 ^Konter 09:54, 2. Nov. 2022 (CET)

Kommentare

So nun noch der Ping an alle Abstimmungsberechtigten. AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, Der Sternendiamantritter, DomiDsLP, Eden Ediz, Jardan, Jass, Killuu, Lasagne, Mario-WL, Panflami, Pk-fan, PokéSpe, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, Goloer444, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Kernseife, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 23:40, 30. Okt. 2022 (CET)

Die Abstimmung ist beendet. Damit wurde die Basis für Typen, Kategorien sowie default in allen Vorlagen entsprechend der Abstimmungen hinterlegt. Im Verlauf dieser Haben sowohl Jass wie auch Isso Äußerungen getan das sie mit den gewählten Grundfarben für Elektro und Cooln. nicht zufrieden sind. Für Elektro gab es #intern ein Meinungsbild (6× Elektro passt, 4× Passt nicht und 4× ). Bei diesem haben allerdings lediglich die hälfte der VBs abgestimmt. Aufgrund der geringen Beteiligung und da es auch explizite Vorschläge für Elektro gibt wird dies in einem neuen Abschnitt behandelt. Und dieser fliegt ins Archiv (was die AD etwas entlassten sollte). Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 01:17, 7. Nov. 2022 (CET)

Geschlechtsneutrale Form von Protagonist/in, Spieler/in etc.

Hallo zusammen! Immer wieder kommt mir ein Thema unter, was ich hiermit mal in Worte gießen möchte, als Diskussionsgrundlage: Es geht um den Begriff der Protagonisten, den wir an vielen Stellen im Wiki benutzen. Der ist schön und treffgenau. Ich glaube, dass uns trotzdem aus verschiedenen Gründen eine Harmonisierung des Begriffs gut tun würde, der eine geschlechtsneutrale Form darstellt:

• Zunächst wird der Begriff nicht durchgängig verwendet, auch andere Bezeichnungen sind häufig. Z. B. verwenden wir manchmal Spieler/Spielerin, was vom Protagonisten/von der Protagonistin zu unterscheiden ist: Der Spieler sitzt vor dem Gerät, der Protagonist hingegen ist die Figur im Spiel. Hier könnte Vereinheitlichung nicht schaden.
• Wir sind recht umständlich mit den Geschlechtsunterschieden, vom generischen Maskulinum über "Protagonist/in" hin zu "der Protagonist oder die Protagonistin" habe ich schon alles gesehen. Man müsste sich quasi projektweise informieren, welche Form gewünscht ist.
• Ich glaube, dass eine geschlechtsneutrale Form das deutlich vereinfachen würde, auch weil man damit das Gender-Thema umgehen kann. In Zeiten, wo man eigentlich in jedem Spiel zwischen einem weiblichen oder männlichen Hauptcharakter unterscheiden kann, finde ich persönlich das wichtig.

Wie könnte das gelöst werden?

• Die offizielle Pokémon-Webseite verwendet häufig den Begriff Hauptcharakter, z. B. im aktuellen Portal zu Karmesin und Purpur.
• Ebenfalls häufig nutzen sie "Hauptfigur", z. B. im Portal zu Legenden: Arceus oder bei Masters EX.
• Beide Varianten finde ich gut und habe keine Vorliebe. Vielleicht ist ja sogar ein Variieren zwischen den beiden am schönsten.

Vielleicht ist ja eine Anregung dabei, die bei euch anklingt. Liebe Grüße! Maxmiran 11:38, 17. Okt. 2022 (CEST)

Danke für die Hinterlegung im Wiki. Ich finde es sehr wichtig das wir bei diversen Situationen wo es um den Menschen geht also der Person an der Konsole weiterhin Spieler nutzen. Beispielsweise Handhabung der Joy-Cons in LGPLGE. Ansonsten wenn es um den gespielten Charakter geht, sollte das bisher verwendete Spiler/Spielerin geändert werden. Zur Handhabung von Protagonist/Protagonistin muss ich sagen mich stört es nicht zu schreiben der Protagonist bzw. die Protagonistin. Ganz im Gegenteil. Sollte TPCi hier irgendwann meinen einen diversen Charakter einzuführen. Warum auch immer. Dann würde man dies klar im Text herauslesen können. Was bei einer generellen Neutralen schreibweise überhaupt nicht ins Auge fallen würde. Wenn man das jetzt für vergangenes Umschreibt würde mir z.B. der wichtige Unterschied zwischen GS und K (Einführung des zweiten Geschlechtes) an diversen Stellen verloren gehen was ich sehr schade finden würde. Im Orte-Projekt nutzen wird auch immer wieder die Namen der Charaktere statt stupiden Protagonist/Protagonistin, da gibt es bisher keine direkte Vorgabe. Habe allerdings keine generelle Problematik wenn wir zukünftig z.B. ab VIII oder IX nur noch Hauptcharakter schreiben da das zweite Geschlecht inzwischen etabliert ist. Muss allerdings sagen das ich generell gegen Hauptfigur bin. Beim Hauptcharakter impliziere ich automatisch Personen was bei Hauptfigur nicht der Fall ist. Für mich wäre z.b. Pikachu (Let’s Go) sowie Evoli (Let’s Go) im jeweiligen Spiel ebenfalls Hauptfiguren. Daher kommt dieses Wort für mich nicht in Frage und wäre ich ganz klar dagegen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:01, 17. Okt. 2022 (CEST)

Ich hätte kein Problem damit die Verwendung "Hauptcharakter" bzw. "Hauptfigur" zu nutzen. Ich finde persönlich jedoch die klare Abgrenzung von Spieler/-in und Protagonist/-in durchaus wichtig. Sie werden zwar synonym verwendet, unterscheiden sich aber in einem kleinem, aber wichtigen Detail. Sehe das wie Ryuichi, dass wir ab G8 bzw. G9 nun nur noch "Hauptcharakter" verwenden sollten/könnten. Kernseife ^Diskussion 13:19, 17. Okt. 2022 (CEST)

Hauptcharakter wird seit IX an vielen Orten genutzt. Auch sonst gab es keine Einwände. Damit kann der Punkt als zustimmend und folglich abgeschlossen betrachtet werden und ins Archiv. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:56, 11. Jan. 2023 (CET)

Nachjustierung Farbvorlagen

Siehe hierzu letzter Beitrag bei Color-Vorlagen. Ich setzte hier noch einmal die Nachrichten von Isso und Jass:

Isso: Ich finde das Coolness-Icon sollte mehr orange sein. Das scheint mir völlig daneben. Das Isso 08/15 ^Konter 23:44, 17. Okt. 2022 (CEST)

Jass: Ich hätte für Gelb eine Alternative von einer off. Seite hier https://sg.portal-pokemon.com/play/pokedex/025. Die Farbe wäre #e4b743 Die Farbe ist keiner der anderen Typen ähnlich und sie ist ohne Shadow auch gut leserlich. Was haltet ihr davon? Hier könnt ihr den Unterschied sehen: https://cdn.discordapp.com/attachments/247300276732559360/1037040852683477022/unknown.png https://cdn.discordapp.com/attachments/247300276732559360/1037040888754487376/unknown.png --Jass 17:29, 1. Nov. 2022 (CET)

Meines Wissens gab es von Isso keine direkten Vorschläge. @Isso mach einmal bitte Vorschläge oder jemand anderes. Wenn nichts kommt dann bleibt es bei jetzigem. → Cooln.

Und bzgl. Jass seinem Vorschlag. Ich habe es wie auch bei den anderen Vorlagen hier gesetzt und wieder Hell+5, Hell+2, Dunkel und Dunkel+3 gewählt. Dies ergibt folgendes Ergebnis:

Hell+	Hell	Icon	Dunkel	Dunkel+	Status
Elektro	Elektro	Elektro	Elektro	Elektro	Aktuell
Elektro f4e2b3	Elektro eccc7b	Elektro e4b743	Elektro cda43c	Elektro 886d28	Vorschlag Jass
Elektro fff399	Elektro ffea4c	Elektro ffe100	Elektro e5ca00	Elektro 998700	2.Farbe auf der Seite von Jass

Persönlich finde ich ja das die Farbe generell und auch in Abstufung eher wie ein Sandton wirkt. Finde sie für Elektro ungeeignet. Ich zumindest habe keine Leseschwierigkeiten. Wie sind hierzu die weiteren Meinungen? Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 01:47, 7. Nov. 2022 (CET)

Nachtrag: Auf der oben genannten Seite werden zwei Farben für den Typ genutzt. Habe diese noch einmal ergänzt. Sie ist mini-minimal dunkler wie unsere derzeitige Farbe, was denke mal keinem auffallen würde. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:35, 7. Nov. 2022 (CET)

Stimme Jass grundsätzlich zu, dass mir eine andere Elektro-Farbe lieber wäre. Jass' Vorschlag gefällt mir aber auch nicht, da ich die Farbe ebenfalls zu sandfarben finde. Ich wäre aus einem einfachen Grund trotzdem dafür, nochmal andere Optionen auszutesten: das aktuelle Elektro-Icon wirkt einfach anders als alle anderen Icons, da es als einziges einen Textschatten hat. Wenn wir eine Farbe finden könnten, die offiziell, gelb statt braun und trotzdem optisch zufriedenstellend und dunkel genug ist, um ohne Textschatten auszukommen, wäre das ideal. Wir nutzen ja aktuell die SDLP-Farbe und diese ist heller als alle bisherigen Elektro-Hauptspiel-Icons. Ich habe aus den Farben der Hauptspiel-Icons mal Wiki-Icons ohne Textschatten gebastelt:

Elektro	Elektro	Elektro	Elektro	Elektro	Elektro	Elektro	Elektro	Elektro
III	IV	V	VI	VII	LGPLGE	SWSH	SDLP (aktuell)	PLA

Ich würde die Icons aus Gen 6 und 7 zumindest nochmal ins Gespräch bringen wollen. Falls die meisten beim aktuellen Icon verbleiben wollen, kann ich das aber auch verstehen. Immerhin ist es demokratisch gewählt worden. Den Textschatten hätte ich aber trotzdem gerne entfernt…--✦✧  Pk-fan ✧✦ 23:06, 7. Nov. 2022 (CET)

Mir persönlich gleich. Ich kann mit SDLP leben, einzig der Schatten stört mich. Hab allerdings so keine Einwände gegen Pks Vorschläge. An die Anwesenden des damaligen Mini-VC AAWiki, Danee, Lasagne, Panflami, DeepSpace, Taube, Peter, Mec, Mooni, Poffel, Robbi und Simon. Es wäre schon von euch auch eine kurzes Statement zu bekommen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:20, 11. Nov. 2022 (CET)

Ich wollte mal nachfragen wie siehts hiermit aus, wäre ein VC sinnvoll um dies zu besprechen und abzustimmen oder machen wir das hier? --Jass 13:08, 25. Dez. 2022 (CET)

Aktuell sehe ich hier lediglich Pk und meine Meinung einstimmig das der Schatten weggehört. bzw. wir beide deinen Vorschlag als nicht sinnvoll erachten. Es gab weitere zwar Vorschläge von Pk und es ist auch ein Ping an AAWiki, Danee, Lasagne, Panflami, DeepSpace, Taube, Peter, Mec, Mooni, Poffel, Robbi und Simon erfolgt. Hier stand allerdings auch die Option im Raum das man es so lassen kann da es ja demokratisch gewählt wurde. Würde da ganz einfach sagen wenn diese sich nicht bis Ende diesen Jahres gemeldet haben bleibt es beim Status Quo da dann acht Wochen vergangen sind ohne das es weitere Meinungen oder Vorschläge gab. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:20, 25. Dez. 2022 (CET)

Finde abgesehen von PLA ehrlichgesagt keinen der Elektro-Vorschläge wirklich lesbar, und PLA wird vermutlich andere Probleme machen wenn mans als Farbe nimmt, weils relativ dunkel ist. Ist halt das Kernproblem, das das Ding gelb ist - gelb möchte ich jedoch lassen, Jass' Vorschlag ist mir dementsprechend zu sandfarben. SDLP ist da zugegebenermassen das hellste und vom demher nicht zwingend geeignet, aber so viel besser sind die anderen auch nicht imo. Kann vom Farbton her schlussendlich mit allem ausser dem grünlichen G4-Ding leben. Irgendwie schwarze Farbe für die Schrift oder so wär ne Option, wäre dann aber recht anders als die anderen Icons. --Mecanno-man^Mäh 15:44, 26. Dez. 2022 (CET)

Isso hat sich nicht mehr gemeldet. Folglich bleibt es bei Cooln.. Jass Vorschlag wurde als zu Sandfarben empfungen. Die restlichen die sich geäußert haben können auch mit dem Status Quo leben. Da es sonnst keine Einwände gab bleibt es bei Elektro und der Punkt kann ins Archiv. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:56, 11. Jan. 2023 (CET)

Eigene Artikel für Mode-Artikel

Seit längerem wurmt mich das die ganzen Kleidungsstücke in großer Zahl einfach auf den Boutique-Artikel leiten und mit KAPU kommt der nächste Schwung an Mode-Artikeln, diesmal nicht nur Kleidung sondern auch >50 Handyhüllen usw. Ab und an gibt es bisher eine BKL wegen Spin-Off oder Mehrfachbenutzungen. Spätestens seit XY ist die Kleidung ein fester Bestandteil der Hauptspiele und gerade in GO und UNITE ein Bestandteil vieler Events. Da dies keine Items sind will sich Robbi dem nicht annehmen. Obwohl es meiner Meinung auch i.wie Gegenstände sind die man besitzt. Aber gut ob das nun das Item-Projekt macht oder nicht darum geht es nicht zwangsläufig. Wie gesagt mich stört diese Unterpräsenz des sich stark erweiternden Features. Daher habe ich hier mal ein grobes Beispiel zusammen gezimmert. Was noch fehlt ist ein eventueller Spin-Off-Teil, Fundort-Vorlage und Navigationsleite. Auch kann ich mir gut vorstellen Freischaltbedingungen, Eventzeiträume oder auch Anime Abschnitte. Wo mir Beispielsweise Schiggy und seine Sonnenbrille einfällt. Ich finde es für Leser anregend wenn ich z.B. nach Langen Socken suche und statt durch ewige Listen zu wühlen sehe ich den Gegenstand und sämtliche Varianten inkl. Verzweigungen zu anderen Spielen und Franchises. Wie sind dazu die weiteren Meinungen. Wichtig wären für mich folgende Fragen: Einzelartikel anlegen? Sollte es einem Projekt zugeordnet werden? Sehe da das Item-Projekt da es doch i.wo Gegenstände nur in anderer Form sind oder das Spieleprojekt aufgrund des Umziehens (Spielmechanik). * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:55, 18. Nov. 2022 (CET)

Ich kenne mich mit der Kleidung in den unterschiedlichen Spielen jetzt nicht soo aus, aber was mir aufgefallen ist, als ich mich jetzt mal durchgeklickt habe, ist, dass die Kleidungssammelartikel, sofern sie überhaupt vorhanden sind, nicht gleich bezeichnet sind und irgendwie auch schwierig auffindbar. Beispielsweise kommt man über den Begriff "Kleidung" erstmal zur Trainer-Individualisierung. Da gibt es aber nur Fundorte. Wenn ich dann z.B. auf die Boutique gehe, finde ich erst Listen für die Spiele (aber eben auch nur welche, wo es eine Boutique gibt). Irgendwie müsste man also schonmal hier was vereinheitlichen. Ich bin mir nicht sicher, wie sinnvoll es ist, dass jedes Bekleidungsteil seine eigene Seite hat, aber zumindest so Zusammenfassungsseiten wie "Oberteile in X und Y" oder so wären bestimmt sinnvoll, inklusive aller Farbangaben. In den Tabellen, die ich jetzt gefunden habe, sind nämlich diese Sonderfarben gar nicht mit drin. Einer eigenen Seite wäre ich auch nicht abgeneigt, das ist halt deutlich mehr Arbeit. Und sollte nicht dazu führen, dass es die Übersichtsliste nicht mehr gibt (denke hier gerade an die Beerenlisten-Diskussion). Welches Projekt das behandeln sollte, da halte ich mich lieber raus, mir fällt aber auch gerade nichts anderes ein als dir, Ryu. Beste Grüße --Schöne Träume! Killuu 10:51, 9. Dez. 2022 (CET)

Für mich gibt es da mehrere wichtige Punkte zu klären bzw. mal aufzuwerten. An sich bin ich der Idee, einzelne Artikel für die Kleidungsstücke zu erstellen, nicht abgeneigt. Zu klären ist dann aber mMn auf jeden Fall, wer sich drum kümmert, weil sonst haben wir tausende Artikel erstellt und dann liegen sie rum. Daher haben DieTaube und ich uns entschlossen, dass wir das übernehmen würden. Vorher allerdings noch folgende Punkte:

1. Wenn wir Artikel zu jedem Kleidungsstück erstellen, was passiert mit den Sortiment-Artikeln? Gibts da schon Ideen? Bleiben die so, werden die gelöscht? Da wir ja dann z. B. einen Artikel zur Camping-Mütze hätten, in dem die Camping-Mütze in braun, grün, rot und schwarz zu finden ist, fände ich eine weitere Übersicht in dem Sortiment-Artikel obsolet.
2. Die WLs der Kleidungsstücke gingen dann zukünftig natürlich auf den jeweiligen Artikel dazu.
3. Haben wir wirklich die Datenlage dazu, für jedes Kleidungsstück einen Artikel zu erstellen, der eine Infobox mit japanischem / englischem Namen (die ich eher rauslassen würde), Bild (die wohl mit am wichtigsten sind, bei SWSH sehe ich größere Lücken), Spielen, Ankaufswerten, Festival-Münzen, Ligapunkten, Variationen usw. usf., Spin-offs, Fundorten, Freischaltbedingungen, Eventzeiträumen und ggf. Anime-Abschnitten beinhaltet? Die Sortiment-Artikel sind da zwar schonmal eine sehr gute Grundlage, aber ich wüsste nicht, dass wir irgendwo Freischaltbedingungen oder Events listen. Anime-Abschnitte müsste man dann mit der Zeit erstellen, weil dann erst wieder jemand durch alle Folgen gehen und eintragen muss (wofür mir als einziger Impo in den Sinn kommt, der das bewerkstelligen könnte).
4. Eine Navigationsleiste für die Kleidungsstücke bräuchte es dann auf jeden Fall, damit man als Leser auch mal nen Überblick kriegt (wäre auch noch ein Punkt, der den Übersichtsartikel obsoleter erscheinen lässt)

Soweit erstmal meine Gedanken dazu, die Grundidee ist auf jeden Fall sehr nutzerfreundlich im Gegensatz zu den Listen. -- ~~ feblue 16:33, 14. Dez. 2022 (CET)

Mal zu den einzelnen Punkten.

1. Würde ich nicht löschen da sie eine Spielbezogene Liste sind die allerdings in Variationen usw. gekürzt werden könnte da wir dann Einzelartikel haben wo wir für Details verlinken können. Z.b. Knöchelsocken gibt es wenn ich es richtig gesehen habe bereits in 3 Spielen.
2. Halte ich für selbstverständlich
3. LP und FM sind fixe Faktoren also Ja da haben wir die Daten. Bis Auf den einen Rucksack aus KAPU, könnte ich bei Wunsch von Jedem Kleidungsstück einen Screenshot machen. Also ja wäre auch vorhanden. Ankaufswerte finden Sich in den Listen oder Orten. Also ja auch vorhanden. Freischaltung steht auch in den Orten siehe Schneiderei. An und für sollten wir die benötigten Daten zu mindestens 80 % haben
4. Nav ist halt so eine Sache. Was soll diese Enthalten? Ansammlung aller Oberteile spielübergreifend wie z.b. bei den Fähigkeiten, eine Spielbezogene Nav aller Kleidungsgruppen (inkl./exkl.) Varianten.

Das soviel von meiner Seite. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 19:01, 14. Dez. 2022 (CET)

Alles klar, Einkürzen ist auch ne Möglichkeit. Da wir Fundorte, Preise, Bilder und Freischaltbedingungen haben, wäre das denke ich schonmal ein sehr guter Anfang, beim Rest muss man dann schauen, was man findet. Das was wir haben ist ja auch auf einen Blick einsehbar und die spielübergreifende Kleidung muss man dann halt zusammensuchen. Die Navigationsleiste würden wir nach Spiel, dann nach Kleidungsstück und dann nach männlich weiblich oder beides sortieren. Ein Entwurf findet sich auch im Testwiki. Funktioniert aktuell halt nur für XY und Kopfbedeckung, aber die Idee sollte klar werden. -- ~~ feblue 23:26, 14. Dez. 2022 (CET)

Klingt nach einem guten Plan. Würde ja fast vorschlagen man fängt bei KAPU an und arbeitet sich nach vorne. Falls ihr irgendwas braucht an Material oder infos sagt bescheid. Was das angeht bin ich relativ Up-To-Date. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 23:57, 14. Dez. 2022 (CET)