PokéWiki:Allgemeine Diskussionsseite

Allgemeine Diskussionsseite Zweck dieser Seite ist es, die Gestaltung und Organisation des Wikis zentral zu diskutieren. Wenn ihr neue Ideen für das Wiki habt, könnt ihr hier die Meinungen anderer User in Erfahrung bringen oder eine Abstimmung abhalten. Ebenso können hier Lösungen für akute Probleme im Wiki gemeinsam gesucht werden. Zusätzlich liefert euch diese Seite die Möglichkeit, mit den Admins in Kontakt zu treten. Wenn ihr eine konkrete Anfrage an sie habt, macht dies im Abschnittstitel kenntlich.

+

Vorhandene Archivierungen: 2012 • 2012-2 • 2013 • 2014 • 2015 2016 • 2017 • 2018 • 2019 • 2020 2021 • 2022 • 2023 - zuletzt archiviert von * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 21:10, 25. Mai 2022 (CEST)

Zentrale Hinterlegung von Trainerdaten

→ Hauptseite: Zentrale Hinterlegung von Daten

Das Thema wird an dieser Stelle echt Komplex wenn es auch mit Cargo nicht klappt dann muss weiter überlegt werden. Die Diskussion als solches hat allerdings bereits schon die Wichtigkeit aufgezeigt weshalb es unablässlich ist dies vollständig zu klären, daher habe ich dies auf eine eigene Seite ausgelagert und in Zukunft werden wir ja sehen wie weit wir sowas wie eine Datenbank auch ausweiten können. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:44, 11. Nov. 2021 (CET)

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 ~ Datei:Sugimori 004.png^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 29.04.2024 14:31 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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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). --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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 --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-man^Mäh 10:16, 18. Sep. 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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 19:16, 18. Sep. 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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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) --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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? --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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 Sugimori-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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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 29.04.2024 14:31 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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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. --Datei:Sugimori 672.pngMecanno-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)

Vereinheitlichung von Sprite-Kategorien

Hallo zusammen,

ich würde gerne etwas ansprechen, was mich schon seit längerer Zeit stört (eigentlich wollte ich das schon vor SDLP-Release ansprechen, aber naja). Es geht dabei um die Sprite-Kategorien der Hauptspiele, zur Übersicht werde ich die hier mal auflisten:

• Erste Generation: Kategorie:RG-Sprite, Kategorie:RB-Sprite, Kategorie:Gelb-Sprite, Kategorie:RBG-Sprite
• Zweite Generation: Kategorie:Gold-Sprite, Kategorie:Silber-Sprite, Kategorie:Kristall-Sprite, Kategorie:GSK-Sprite
• Dritte Generation: Kategorie:RS-Sprite, Kategorie:FRBG-Sprite, Kategorie:Smaragd-Sprite, Kategorie:RSS-Sprite
• Vierte Generation: Kategorie:DP-Sprite, Kategorie:Platin-Sprite, Kategorie:DPPT-Sprite, Kategorie:HGSS-Sprite
• Fünfte Generation: Kategorie:SW-Sprite, Kategorie:S2W2-Sprite
• Sechte Generation: Kategorie:XY-Sprite, Kategorie:ORAS-Sprite, Kategorie:3DS-Sprite
• Siebe Generation: Kategorie:SoMo-Sprite, Kategorie:USUM-Sprite, Kategorie:3DS-Sprite, Kategorie:LGPE-Sprite
• Achte Generation: Kategorie:SWSH-Sprite, Kategorie:SDLP-Sprite, Kategorie:PLA-Sprite

Es gibt hierbei einige uneinheitliche Sachen, das beste Beispiel ist wohl Kategorie:3DS-Sprite: Diese Kategorie enthält die Pokémon-Icons der 3DS-Spiele, also XY, ORAS, SoMo und USUM, da sie in allen Spielen gleich sind. Bei den DS-Spielen (Gen. 3, 4 und 5), in denen die Icons auch alle gleich sind, gibt es hingegen nicht Kategorie:DS-Sprite, sondern die Icons sind in den Kategorien der einzelnen Spiele. Außerdem sind auch die Pokémonsprites in den 3DS-Spielen gleich, diese sind allerdings nicht in Kategorie:3DS-Sprite, sondern in den Kategorien der einzelnen Spiele. Ein weiteres Beispiel sind die Overworldsprites: In Gen. 4 sind sie als DP-Sprite und Platin-Sprite kategorisiert (das wird generell ab Gen. 4 für die OW-Sprites und Modelle so gemacht), aber z. B. in Gen. 3 sind sie in der gemeinsamen Kategorie RSS-Sprite, wobei bei Unterschieden auch hier mit RS-Sprite bzw. Smaragd-Sprite kategorisiert wird. Was mich besonders stört, ist, dass nicht alle Sprites für ein Spiel in einer Kategorie aufzufinden sind, sondern bei manchen Spielen auf zwei Kategorien verteilt (vor allem bei z. B. OW-Sprites, wo einige in der einen Kategorie und andere OW-Sprites in einer anderen sind).

Mein Vorschlag wäre daher: Jeder Artikel kriegt eine (genau eine) Sprite-Kategorie. Für beispielsweise Gen. 4 wäre das Kategorie:DP-Sprite, Kategorie:Platin-Sprite und Kategorie:HGSS-Sprite; demzufolge würde Kategorie:DPPT-Sprite wegfallen. An sich wäre ich aber wahrscheinlich auch mit anderen Lösungen einverstanden, Hauptsache das wird etwas einheitlicher :) – Vircaprae 22:59, 9. Jul. 2022 (CEST)

Ich bin mir grad nicht ganz sicher ob ich dich richtig verstanden habe, Vir: Du schlägst vor, dass jede Datei nur noch eine Spiele-Kategorie bekommt, und keine Kombi-Kategorie? Wenn ja, dann bin ich da dagegen - denn die Icons sollten auch von Platin aus auffindbar sein. Dagegen die Mischkategorien aufzusplitten hätte ich jedoch nichts, sofern dann die Dateien aber alle treffenden Spiele-Kategorien erhalten (Könnte teilweise schwierig sein nicht zu viele zu geben, z. B. sollte man dann Giratina-Urform-Sprites nicht die DP-Kategorie geben, aber die Platin- *und* HGSS-Kategorien).

Was mir aber ebenfalls auffällt ist, das man hier mit viel mehr Unterkategorien arbeiten sollte. Wir haben genügend Sets an Dateien, die offensichtlich zusammengehören und trotzdem alle einfach nur da drin landen. Die Pokémon-Icons kann man sicherlich nach Spiel auftrennen, ebenso die normalen Sprites und iwie Backsprites und OWs wo's sie gibt. So würde man über die Kategorien zumindest halbwegs etwas finden, was man sucht. Aus meiner Sicht wäre es weiter sinnvoll, wenn in den Oberkategorien nur noch Sachen landen, die nicht in den Unterkategorien sind - dann findet man die komischen zusätzlichen Sachen viel eher, als wenn sie nur irgendwo in einer Kategorie mit tausenden von Dateien sind.

Zusätzlich sollte man nochmals anschauen wie das mit 3D-Modellen is; diese sollten ja eigentlich nicht in der Sprite-Kategorie landen (Ausnahmen Masters, weil Masters Render der Charaktere und Pokémon als Sprites nutzt). Aktuell sind die 3D-Modelle aber teilweise nicht nur in der Kategorie für Sprites sondern sind auch noch als „Pokémonsprite“ benannt, was aus meiner Sicht ebenso falsch ist. Wenn man da also schon gross durchbotten geht wäre ich dafür, die ebenfalls richtig zu machen. --Datei:Sugimori 672.pngMecanno-man^Mäh 12:49, 10. Jul. 2022 (CEST)

Also die Dateien sollen nicht nur eine Kategorie bekommen; es soll pro Artikel nur eine Kategorie geben, demzufolge würden die Mischkategorien dann wegfallen. Die Dateien sollten optimalerweise alle passenden Kategorien haben, wobei das beim aktuellen "System" auch bei weitem nicht gegeben ist (z. B. müssten die Pokémon-Backsprites aus Gen. 4 auch Kategorie:HGSS-Sprite haben, aktuell haben sie nur Kategorie:DPPT-Sprite).

Unterkategorien für Pokémonsprites wollte ich eigentlich irgendwann mal separat ansprechen. Aber ja, es wäre sinnvoll da welche zu haben (aktuell gibt es etwas mehr als 60.000 Pokémonsprites und außer seit kurzem Kategorie:Schillernder Pokémonsprite keine Unterkategorien). Nach Spiel auftrennen kann man auf jeden Fall (jedenfalls für die Hauptspiele und "größere" Spin-offs, bei "kleineren" habe ich gewisse Bedenken) und die Unterkategorie für Backsprites wäre vielleicht auch sinnvoll. Bei den OWs weiß ich nicht was du damit meinst, die haben doch schon Unterkategorien?

Eine strengere Unterscheidung zwischen Sprites und 3D-Modellen wäre formal natürlich korrekter, allerdings müssten wir dafür viel umstellen, vor allem was die Kategorienstruktur usw angeht. – Vircaprae 16:27, 12. Jul. 2022 (CEST)

So, Mec und ich haben über Discord in der Zwischenzeit noch ein Missverständnis geklärt. Um das nochmal klarzustellen, Dateien sollen auch weiterhin mehrere Kategorien haben können, z. B. so wie hier Kategorie:SoMo-Sprite und Kategorie:USUM-Sprite.

Wenn keiner was dagegen hat, können wir jetzt ja die Umsetzung etwas konkreter besprechen. Einige Dateien sollten am besten verschoben werden, z. B. die 3DS-Sprites zum entsprechenden Spiel. Bei anderen würde es vielleicht auch reichen, wenn man in Vorlage:Spritedatei einen Switch einbaut (für gewisse Dateien muss das vielleicht so gemacht werden). Es geht mir zwar eigentlich um die Vereinheitlichung der Kategorien, aber es wäre schön, wenn man auch hier ne gewisse Einheitlichkeit hätte. Also so wie es dann z. B. für DPPT-OWs gemacht wird, sollte es dann auch für RSS-OWs usw. gemacht werden. Gibt es da Meinungen zu? – Vircaprae 21:58, 20. Jul. 2022 (CEST)

Okay, ich werte das mal als Gleichgültigkeit / stille Zustimmung. Ich werde dann gleich bei den entsprechenden Kategorien einen Löschantrag setzen, damit klar ist was gelöscht werden muss, die können dann auch direkt gelöscht werden. Ich würde sagen die 3DS-Sprites werden zum richtigen Spiel verschoben (wird dann am besten per Bot gemacht) und für den Rest wird der Einfachheit halber ein Switch eingebaut (müsste einer mit der Berechtigung dazu machen). Dann muss man 1. die Dateien selber nicht verschieben und 2. die Einbindungen nicht anpassen; und man kann die ja auch später noch verschieben. Der Switch müsste dann in etwa so aussehen:

{{#switch:<Edition>

|RBG=[[Kategorie:RB-Sprite]][[Kategorie:Gelb-Sprite]]

|Gold|Silber=[[Kategorie:GS-Sprite]]

|GSK=[[Kategorie:GS-Sprite]][[Kategorie:Kristall-Sprite]]

|RSS=[[Kategorie:RS-Sprite]][[Kategorie:Smaragd-Sprite]]

|DPPT=[[Kategorie:DP-Sprite]][[Kategorie:Platin-Sprite]]

|#default=[[Kategorie:<Edition>-Sprite]]}}

Das gleiche müsste für Overworldsprites, 3D-Modelle, Overworldmodelle, VS-Sprites und Trainersprites eingebaut werden (eigentlich würde auch OWs und Trainersprites reichen, aber in der Spritedatei-Vorlage wird schon nach den fünf gefiltert), wobei man hier auch nur RBG, GSK und RSS und #default bräuchte. – Vircaprae 19:59, 7. Aug. 2022 (CEST)

Nachdem das eben mit den Bot-Aufträgen aufkam, habe ich mir das ganze mal genauer angeschaut und verstehe jetzt erst richtig, was du überhaupt vor hast. Da die Diskussion - mangels jeglicher Teilnahme von allen Seiten - inzwischen im Grunde beendet ist und mit der Umsetzung begonnen wurde, werde ich mich dem nicht mehr grundsätzlich in den Weg stellen. Bin ich teilweise auch selber schuld, während der Diskussion war ich mit meinem Studium beschäftigt und habe es dann diesen Monat einfach schleifen gelassen, weil ich nahezu nichts im Wiki gemacht habe. Aber ich möchte zumindest noch ein paar Gedanken zur Umsetzung teilen:

Und zwar lohnt es sich vermutlich, zunächst ein mal zu erklären, warum die Kategorien existieren, die existieren und wie das ganze entstanden ist. Ursprünglich wurden die Kategorien eingeführt als Alternativen zu unseren ach so tollen Sprite-Seiten, die im Grunde das waren, was wir jetzt in Kategorie-Form haben, eben eine Sammlung von Bildern sortiert nach den Spielen. Dabei haben wir uns bei den Namen damals primär einfach nach greenchu gerichtet, wo die ganzen Dateien ja alle in verschiedenen Ordnern liegen. Ziel war es unter anderem, so wenig Änderungen gegenüber dem alten Modell wie möglich zu haben. Gleichzeitig brachte das bereits bestehende System aber auch den Vorteil mit sich, dass wir zu diesem Zeitpunkt bereits etwas hatten, dass sich danach richtet, so viel wie möglich zusammen zu fassen. Das ist dabei die Grundlage für die Kategorien, die wir aktuell haben, wobei sowas wie die RSS-Kategorien daher kommen, dass es keine Unterschiede zwischen den verschiedenen Sprites gab und es aufgrund MediaWikis Duplikat-Funktion keinen Sinn darin gab, Dateien mehrfach hochzuladen. Das angestrebte Ziel war also im Grunde die größte Schnittmenge zu finden. Und bei den Icons haben wir uns daher entschieden, sie einfach alle zu 3DS-Sprites zusammen zu fassen. Die Icons waren über alle 3DS-Spiele hinweg identisch und die Technik, dass man bspw. nach Spiel unterscheiden muss, ob das Icon überhaupt eingebunden werden darf, gab es von vorne herein nicht, da die Icons sowieso nie im Kontext von Spielen, sondern Generationen eingebunden wurden. Und hier bin ich mir aktuell sehr unsicher, welche Folgen das haben wird. Erlauben wir in der Einbindung, dass zwischen XY und ORAS sowie SOMO und USUM getrennt wird? Wenn nein, was bringt es uns, bei den Sprites zu trennen, bei der Einbindung aber nicht? Wenn ja, wie soll das vernünftig umgesetzt und geprüft werden? Ich habe diesen Teil jetzt schon mehrfach neu geschrieben, weil sich immer wieder neue Probleme aufgetan haben, die sich zwar gelöst haben, aber irgendwie endet es nicht mit den Problemen. Hier brauch ich auf jeden Fall noch mal input, wie genau das jetzt gehen soll und was uns das bringt. Vielleicht ist es auch einfach zu spät.

Außerdem ist mir auch noch nicht klar, warum Gold und Silber zusammen geschoben werden sollen. Also ja, ich sehe den Gedanken, dass es dann einheitlich zu allen anderen Editionen ist, wo dann auch jeweils die Doppel-Editionen zusammen geschoben sind und würde Einheitlichkeit dort begrüßen, denke aber, dass hier die Übersicht doch darunter leidet. Weil die Spiele haben vollständig unterschiedliche Sprites, würde also bedeuten, dass wir in einer Kategorie für jedes Pokémon zwei Sprites haben. Und da geht dann eben die Übersichtlichkeit, dass man alle Sprites aus einem Spiel auf einen Blick haben kann, verloren, weil dann gemischt wird. Hier erscheint es mir also schlechter, wenn man die zusammen zieht, anstatt sie wie bisher getrennt zu lassen. -- RobbiRobb 04:47, 27. Aug. 2022 (CEST)

Also, es geht hier primär um die Vereinheitlichung der Sprite-Kategorien bzw. der Dateinamen. Die Gründe gegen die "3DS-Sprites" kannst du ja weiter oben finden. Zur genauen Umsetzung im Icon-Parser kann ich nichts sagen, weil der soweit ich weiß nirgendwo eingesehen werden kann. Aber wie ich beim Botauftrag schon meinte, bei Gen. 3, 4 und 5 wird es ja schon genau so gemacht, also ist es anscheinend möglich; statt RSS, DPPT und SW sind es hier halt XY, ORAS, SoMo und USUM. Die Einbindung kann von mir aus so bleiben wie sie jetzt ist, aber wenn dir das so wichtig ist, kannst du das auch entschieden. Das ist sowieso fast schon irrelevant, weil die Gen6/7-Icons nur auf sehr wenigen Seiten überhaupt verwendet werden. Wo die allerdings großflächig eingebunden sind ist auf den Spriteseiten, was es dann ermöglichen wird die Spiele dort richtig anzuzeigen, das ist bis jetzt nämlich teilweise falsch.

Die "Zusammenschiebung" von GS hat mehrere Gründe: 1. sollen die Kategorien halt vereinheitlicht werden, sodass alle Sprites aus einem Spiel in einer Kategorie zu finden sind, 2. sind nur die (Vorderseiten-)Pokémonsprites in Gold und Silber unterschiedlich, die Pokémon-Backsprites, die Pokémon-Icons, die Overworldsprites und die Trainersprites sind identisch und die sind deshalb in unterschiedlichen Kategorien, was ja nicht sein soll, 3. sind auch einige der Vorderseiten-Sprites identisch, welche dann unter Gold liegen, wodurch die in der Silber-Kategorie fehlen und 4. (wenn man mal einen Schritt weiter denkt) würden die Vorderseiten-Sprites und die Rückseiten-Sprites bei den spielespezifischen Pokémonsprite-Kategorien in unterschiedlichen Kategorien landen und auch das soll nicht so sein. – Vircaprae 04:34, 28. 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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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? --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-man^Mäh 10:03, 11. Sep. 2022 (CEST)

Color-Vorlagen

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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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. --Datei:Sugimori 672.pngMecanno-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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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 ~ Datei:Sugimori 004.png^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)