PokéWiki:Allgemeine Diskussionsseite

Aus PokéWiki
Zur Navigation springen Zur Suche springen
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 13:24, 23. Sep. 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.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:44, 11. Nov. 2021 (CET)

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.pngPL ~ 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-manMä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)

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), 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-manMä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)

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:

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-manMä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 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. LunairlineBuchung 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.pngPL ~ 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 grin.png @Isso08-15: LunairlineBuchung 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-manMä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.pngPL ~ 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-manMä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.pngPL ~ 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-manMä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.pngPL ~ 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.pngPL ~ 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-manMä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. ka.gif Denke ist Geschmackssache da kannst dir es allerdings gerne nochmal ansehen. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ 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 ka.gif.
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

* Ryuichi ~ Datei:Sugimori 004.pngPL ~ 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.pngPL ~ 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)

Zukunft der Icons

Dem ein oder anderen wird es im Discord aufgefallen sein. Seit längerem versucht Jass in vielen Bereichen die HOME-Sprite statt der Icons zu etablieren. Hier gab es immer wieder Diskussion. Daher hier ein entsprechender Diskussionspunkt. Dieser soll klären welche Probleme mit HOME bestehen. Bestes Beispiel siehe hier. Können diese gelöst werden? Welche anderen Optionen gibt es. Wo gibt es überall auswirkungen? Mir fallen da Spontan Infoboxen, Fundorte-Vorlagen der Orte ein wo ein kleines HOME-Bild fehl am Platz ist aufgrund Matschigem Aussehen beim runterskalieren. Da dies ähnlich wie das Thema der anderen Icons eine sehr große Auswirkung auf das gesammte Wiki haben würde auch ein Ping @AAWiki, Arkany, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, Der Sternendiamantritter, DomiDsLP, Eden Ediz, Goloer444, Jardan, Jass, Lasagne, Mario-WL, Nescientist, Panflami, PokéSpe, Vaultysworld, Buoysel, Cliffichen, CLina, DeepSpace, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Kernseife, Killuu, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, Poffelino, Ratequaza, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae. Eure Meinungen sind gefragt Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:24, 23. Sep. 2022 (CEST)

An sich ist mir absolut schnuppe was da so eingebunden wird, generell ist so eine Anpassung natürlich mit Aufwand verbunden bei der Masse an Orten wo die jetzt eingebunden sind. Nen paar Punkte die bei HOME berücksichtigt werden sollen:
1. Meist kommt der HOME-Support erst später - was macht ihr also im ersten halben Jahr von zB KaPu?
2. Auch wenn aktuell HOME recht gut supported wird - spätestens beim nächsten Konsolenwechsel mach ich da zumindest mal nen kleines Fragezeichen hinter ob das so bleibt. Was dann?
3. Bei HOME wurden auch schon nachträglich Sachen geändert - meist nichts spektakuläres, aber eben schon Anpassungen (irgendwo gabs da mal nen Tweet von den bekannten Quellen zu), wie wird damit umgegangen?
Wie gesagt, nur nen paar Punkte die berücksichtigt werden sollten, an sich ists mir schnuppe. Jones Albtraum? 18:42, 23. Sep. 2022 (CEST)
Da das Wiki nun mal weiß ist und die Home-Sprite keine Outlines haben sieht es einfach nicht gut aus bei jeglichen weißen Pokémon, ein Hopplo z.B. ist nicht mehr wirklich erkennbar und da sehe ich den größten Kritikpunkt, die Sichtbarkeit. Würde man die Sprite alle mit einer millimeterdünnen Outline versehen wäre es eine Option, aber dann beginnt wieder die Diskussion über das verfälschen der Originaldaten deshalb kommt von mir ein allgemeines Nein. BeyJim Diskussion 19:01, 23. Sep. 2022 (CEST)
Da die HOME-Sprites anhand ihrer fehlenden Outlines berechtigterweise kritisiert werden, weil unsere Inhalte einfach bisher auf Icons mit Outline ausgerichtet waren, stellt sich die Frage, was man alles anstellen kann, um diese Idee zu realisieren, denn immerhin ist mit PLA ein Spiel erschienen, von dem wir keine solche Icons, wie wir sie bisher hatten, haben und daher brauchts eine Lösung. Ein kurzer Flug durch CSS bringt eine schnelle Lösung mit sich: drop-shadow. Fuscht nicht in den Icons rum, hat den Effekt, dass die Icons aus der Dimension der Tabelle herausstechen und verhindert das Verschwimmen mit unserem zu bestimmt 80% genutzten Weiß. Das ganze ist einmal optisch für Feuer und für Eis hinterlegt, wobei es bei den Eis-Pokémon am interessantesten sein sollte. Schaut mal drüber und legt die Live-Wiki und Test-Wiki-Version nebeneinander, da fällt der Effekt direkt auf. Der Schatten an sich kann natürlich noch verändert werden, ist alles Geschmackssache. ^^ -- ~~ feblue 23:23, 23. Sep. 2022 (CEST)
Hallo zusammen! Ich kann zunächst gut nachvollziehen, dass die herunterskalierten HOME-Icons nicht jedem gefallen. Gleichzeitig denke ich aber, dass künftig auch kein Weg daran vorbeiführen wird, da ich nicht daran glaube, dass es je wieder Spiele geben wird, die alle Pokémon(-Formen) enthalten. Mit HOME haben wir also (mit kleineren Ausnahmen) eine vollständige, einheitliche Sammlung von Bildern. Siehe Pokémon-Liste: Dort befindet sich nun eine wilde Mischung aus kleinen Icons, erneuerten großen Icons (war das Schwert und Schild, wo sie Icons vergrößert haben?) und Artworks. Ich plädiere an solchen Stellen für Einheitlichkeit. Auch finde ich persönlich, dass die HOME-Bilder eine moderne Optik haben. Für sie spricht auch, dass sie alle dieselbe Abmessung haben, wenn ich mich nicht täusche. Pokémon-Icon_674.png Maxmiran 15:41, 25. Sep. 2022 (CEST)

Aus meiner Sicht ist sowieso die Frage, warum wir an einigen Stellen die Icons mit neuen Spielen updaten. Da gehören zB die in Orten dazu - für Tabellen aus Gen 4 könnte man die Gen 4-Icons nutzen und das wäre näher an der Info, die der Spieler auch in den Spielen sieht. Geht natürlich nicht überall, da nicht alle Nutzungsorte an ein bestimmtes Spiel gebunden sind. Was an anderen Stellen tun? Persönlich sähe ich konzeptionell fast lieber kleine Artworks (aka das was früher als Sugimori bezeichnet wurde) als Home-Sprites, Hauptsächlich wegen Jones' Punkt 2; bin mir da aber nicht ganz sicher wie gut das in der Praxis dann tatsächlich funktionieren wird. Drop-Shadow sieht erstaunlich ok aus, wobei ich sowieso nicht zu den Leuten gehöre, die ästhetisch etwas gegen die Home-Icons haben. --Datei:Sugimori 672.pngMecanno-manMäh 19:04, 25. Sep. 2022 (CEST)

Abgerufen von „https://www.pokewiki.de/index.php?title=PokéWiki:Allgemeine_Diskussionsseite&oldid=2418743“