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 19.04.2024 22: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)

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 Basiswerte 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)

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 19.04.2024 22: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)