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 10:51, 7. Mär. 2021 (CET)

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)

Sind weitere Pokémon-Formen als Parameter notwendig?

Hallo zusammen!

Wie einige von euch sicherlich schon mitbekommen haben, liegen die HOME-Sprites sämtlicher Pokémon seit Upload noch nahezu ungebraucht herum. Das Ganze liegt an mir und einer Entscheidung, die ich diesbezüglich treffen müsste. Wollt ihr also einen Schuldigen haben: Hier bin ich!

Um das Ganze nun aber mal zu lösen, verfrachte ich die Entscheidung hierher, um sie nicht alleine treffen zu müssen, denn das möchte ich nicht. Grundsätzlich gab es im Jahre 2018 bereits eine kurze Diskussion zu diesem Thema, die aber am Ende ohne wirkliches Ergebnis eingeschlafen ist. Dies führte dazu, dass wir teilweise Duplikate und teilweise Weiterleitungen haben und ganz allgemein es in verschiedenen Vorlagen unterschiedlich gehandhabt wird.

Wer keine Lust hat sich die vorangegangene Diskussion durchzulesen (auch wenn sie nicht wirklich lang ist), bekommt hier ne kurze Zusammenfassung des Problems:

Es gibt bestimmte Pokémon, die in den Spieldaten über Formen verfügen, die bei uns aber als solche nicht verstanden werden. Am einfachsten lässt sich das an einem Beispiel erklären, wie z. B. Meteno. Grundsätzlich kennen wir die Meteorform und die sieben farbigen Kerne. Jedoch gibt es innerhalb der Spieldaten nicht nur eine Meteorform, sondern sieben: Eine je farbigen Kern. Auch wenn dies nie irgendwo ersichtlich ist, so handelt es sich in den Spieldaten um verschiedene Datensätze. Ein ähnliches und aktuelleres Dilemma haben wir beispielsweise bei Riffex, dessen Gigadynamax-Form bei beiden Formen (Hoch- und Tief-Form) dieselbe ist, sie in den Spieldaten aber als zwei unterschiedliche gehandhabt werden. Darüber hinaus gibt es aber auch bestimmte Event-Pokémon, wie z. B. Wuffels, die sich zwar nicht optisch vom eigentlichen Pokémon unterscheiden, jedoch spielintern als separate Form aufgeführt werden. Mit Pokémon Schwert und Schild gibt es nun zudem diese Wuffels-Form (heißt: mit Tempomacher) auch in Dyna-Raids.

Daher gilt es nun zu schauen und anschließend zu entscheiden, ob man zusätzliche Parameter für solche Fälle haben möchte oder nicht. Sollte man sich für die Verwendung einiger solcher neuen Parameter entscheiden, würden bei optischer Gleichheit keine Duplikate der Sprites, sondern Datei-Weiterleitungen erstellt werden.

Bevor ich hier aber noch weiter ausschweife, habe ich mich mit Ryu zusammengesetzt, um zu überlegen, welche weiteren Formen wir bislang nicht mit Parametern bedacht haben, warum dies der Fall war und ob man daran nicht etwas ändern sollte. Am Ende unserer Gespräche haben wir diese Formen wie folgt zugeordnet:

Benötigt einen Parameter:

(A): 658a (Quajutsu mit Freundschaftsakt) + 658b (Ash-Quajutsu) → gibt es bereits!

(B): 718c (50%-Zygarde mit Scharwandel) + 718d (10%-Zygarde mit Scharwandel)

(C): 744a (Wuffels mit Tempomacher)

(D): 6 weitere Parameter für die Meteorform von Meteno (vom nicht ersichtlichen farbigen Kern abhängig; wie diese Parameter dann genannt werden, ist noch nicht beschlossen – ob generell vor den Kernformen oder immer im Wechsel)

Benötigt keinen Parameter:

(E): 20 weitere Purmel-Parameter (je nach Form des Vivillon am Ende)

(F): 20 weitere Puponcho-Parameter (je nach Form des Vivillon am Ende)

(G): Zygarde-Kern und Zygarde-Zelle → sind momentan noch als Parameter vorhanden!

(H): Zweiter Parameter für G-Riffex aufgrund zugrunde liegender Form

(I): Weitere Parameter für G-Pokusan aufgrund zugrunde liegender Form

(J): Schatten-Mewtu (nur in Pokémon Tekken)

(K): Schatten-Dialga (nur in PMD)

(L): Lila Kecleon (nur in PMD)

(M): Herrscher-Pokémon, Crypto-Pokémon und Ähnliches

(N): Ukulelen-Pichu (nur in Ranger)

(O): Thu-Fi-Zer (nur im Manga)

(P): Volly (nur im Manga)

(Q): Kristall-Onix (nur im Anime)

(R): Kostümierte Pokémon aus Shuffle & GO (lediglich Kostüme)

(S): Rüstungs-Mewtu (zwar unterschiedliche Medien mit Anime & GO, aber aus unserer Sicht ein Kostüm)

Keine eindeutige Entscheidung:

(T): Klon-Pokémon (sowohl im Anime als auch in Pokémon GO vorhanden)

(U): Crypto-Lugia (zentrales Pokémon des Spiels)

Nachträglich hinzugefügt:

(V): Moterpel (besitzt spielintern je nach Form von Burmy eine von drei Formen)

Den Entscheidungen liegt zugrunde, dass wir im Vorfeld alle möglichen Formen unterschiedlichster Medien gesammelt haben, ganz unabhängig, ob sie denn auch in Spielen vorkommen. Danach haben wir geschaut, ob diese Formen auch in mehr als einem Medium vorkommen, um deren Wichtigkeit einschätzen zu können. Vorrang hatten hierbei jedoch stets in den Hauptspielen auftretende Formen, die nicht zwingend in einem weiteren Medium berücksichtigt werden mussten.

Wir haben versucht, eine gewisse Balance zu wahren und stellen euch hiermit vor, welche Parameter wir am ehesten hinzufügen würden. Damit dieser Beitrag nicht noch mehr ausufert, habe ich die Begründungen für einzelne Fälle kurz gehalten oder gar ganz weggelassen. Für Rückfragen und Anregungen sind wir jedoch stets offen; wollen aber auch zeitnah eine Umsetzung anstreben. Deshalb wäre es cool, die Sache kurz abzunicken oder Verbesserungsvorschläge zu machen.

Abstimmung

Abstimmung abgeschlossen

Aus diesem Grund schließe ich diesen Beitrag mit einer zweiwöchigen Abstimmung (Ende: 27. Juli 2020 um 23:59 Uhr), bei der ihr euch entweder an unserer Einschätzung orientieren oder bestimmte Einzelfälle anders einschätzen könnt. Wahlberechtigt sind bei dieser Wahl alle stimmberechtigten Benutzer! Am Ende der zwei Wochen wird jeder Parameter mit einer ⅔-Mehrheit hinzugefügt oder eben nicht. Somit haben wir dann endlich mal eine bindende Grundlage für diese Entscheidung!

Legende:

✔ → Es soll einen Parameter für diesen Fall geben.

✘ → Es soll keinen Parameter für diesen Fall geben.

— → Ich enthalte mich, ob es für diesen Fall einen Parameter geben soll.

Benutzer	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q	R	S	T	U	V
Taisuke	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘
Ryuichi	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	—	✘
SwowoJonny	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	—	—	—	✘	✘	✔	✔	✘
Haijo18	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	—	✔	✘
BeyJim	—	—	—	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	✔	✘
Mooni000	✔	✔	✔	—	✘	✘	✘	✘	✘	✔	✔	✔	✘	✘	✘	✘	✘	✔	✔	—	✔	✘
Mecanno-man	✔	✔	✔	✔	✔	✔	✘	✔	✔	✘	✘	✘	✔	✘	✘	✘	✘	✔	✔	✔	✔	✔
Impoleon xy	✔	✔	✘	✔	✔	✔	✔	✔	✔	—	—	—	—	✘	✘	✘	✘	—	—	—	—	✔
GrollenKette951	✔	✔	✔	✔	—	—	✘	✔	✔	✘	✘	✘	—	✘	✘	✘	✘	✔	✔	✔	✔	—
DeXter	✔	✔	✔	✔	✔	✔	✘	✔	✔	✘	✘	✘	✔	✘	—	✘	✘	✔	✔	✔	—	✔
Nescientist	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Pk-fan	✔	✔	✔	✔	✔	✔	✔	✔	✔	✘	✘	✘	✔	✘	✘	✘	✘	✘	✘	✘	✘	✔
RobbiRobb	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✔	✘	✔	✘	✘	✘	✘	✘	✘	✘	✔	✘
Isso08-15	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	✘	✘	✘	✘	✔	✔	✔	✔	✘
Zeynex	✔	✘	✘	✘	✘	✘	✘	✘	✘	✔	✔	✔	✘	✘	✘	✘	✘	✔	✔	✔	✔	✘
BlauesSerpiroyal	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Lasagne	✔	✔	✔	—	—	—	✘	—	—	✘	✘	✘	✔	✘	✘	✘	✘	—	—	—	—	✘
Ergebnis

Kommentare

Ich habe bereits meine Stimmen für die einzelnen Fälle angegeben, sodass ihr euch an dem Muster orientieren bzw. die Zeile als Vorlage für eure Stimmen nutzen könnt. Und am Ende geht wie immer ein Ping an alle stimmberechtigten Benutzer, damit niemand sagen kann, er hätte von dieser Abstimmung nichts mitbekommen. :)

Grüße gehen raus an: Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny + AAWiki, BeyJim, BlauesSerpiroyal, Der Sternendiamantritter, Haijo18, Hydrokyu, Jass, Killuu, K0pplosio, Lasagne, Mario-WL, Mooni000, Nescientist, Pintauranimus, Pk-fan, PokéSpe, PokemontutorialTV, Vircaprae, Xatuhatu, Zeynex

Ich hoffe, nichts vergessen zu haben. ^_^ ~ Taisuke ^Diskussion 12:35, 13. Jul. 2020 (CEST)

Ich bin mir hier nicht vollständig im klaren darüber, für was für eine Änderung hier abgestimmt wird. Es ist meiner Meinung nach offensichtlich das einige Vorlagen einige dieser Sonderfälle irgendwie berücksichtigen müssen (z. B. Go-Sprites mit Hut) und andere nicht (irgendwelche Strategie-Sachen brauchen den ganzen Co-Kram garantiert nicht). Geht es hier einfach darum zu entscheiden, was die XXXa-Nummern etc. bekommt? Wenn ja, wie würden dann andere Sachen miteinbezogen, die nicht in dieses Schema passen? Wäre es evtl. eine Idee hierfür Schema wie XXXzz, XXXzy etc. zu nutzen, für non-Hauptspiel-Sachen? Oder hab ich hier völlig am Thema vorbeigeschossen und es geht um etwas anderes? --Datei:Sugimori 672.pngMecanno-man^Mäh 14:09, 13. Jul. 2020 (CEST)

PS: In der Liste fehlt Moterpel. Das hat spielintern auch drei Formen.

Danke für den Hinweis mit Moterpel, das habe ich als nun als weitere Option ergänzt. Da müsstet ihr Fünf (1, 2, 3, 4, 5) am besten nochmals schauen und eure Entscheidung diesbezüglich nachtragen. :)

Um aber auf deine eigentliche Frage zurückzukommen: In erster Linie sollte es hiermit eigentlich generell um neue Parameter gehen, die unserem bisherigen Schema folgen (XXXa), aber im Gegensatz zu den vorhandenen Formen (noch) nicht berücksichtigt werden. Die restlichen Punkte sind im Zuge dessen ins Auge gesprungen und haben für uns auch eine Erwähnung hier verdient, um zu schauen, ob wir solche Formen zukünftig auch berücksichtigen wollen. Momentan werden Spin-off-Sonderfälle wie die unzähligen Pikachu-Formen in Shuffle oder GO einfach als 025_X genutzt, sodass z. B. die Sprites-Vorlage auf diese zurückgreifen kann. Aber als eigenständige Parameter sind diese bislang nicht angelegt, da Vorlage:Namenr usw. mit diesem nie (?) genutzt werden würden. So ähnlich würde es doch vermutlich auch den anderen Spin-off-Sonderfällen gehen oder?

Falls das in der Art aber nicht mehr erwünscht wäre und wir dafür ein neues Parameter-Schema, wie von dir vorgeschlagen, nutzen wollen würden, wäre das für mich natürlich auch in Ordnung. ~ Taisuke ^Diskussion 14:20, 14. Jul. 2020 (CEST)

Danke für die Antwort; möchte hier noch kurz meine Stimmen erklären: Meiner Meinung nach macht es Sinn das aktuelle Schema nur für Hauptspiele + eventuell Go zu verwenden (wegen zukünftiger Home-Anbindung), da man nur bei diesen wirklich davon ausgehen kann das sie vorwärts getragen werden, irgendwie. Bei Formen die irgendwelche non-Unterschiede haben (Purmel, Moterpel etc.) macht es von mir aus gesehen weiter Sinn diese zu allokieren, damit nicht in Zukunft irgendwelche botgestüzte Programme beim durchgehen irgendeines Spiele-extracts durcheinander geraten. All zu viel Einfluss sollte das ja schlussendlich kaum haben, da diese Werte wahrscheinlich nirgends benutzt werden würden. Die anderen Spin-Off-Sachen (Shuffle, PMD, etc.) könnten in eine Art Nebenschema eingefügt werden, sei dies über 352zzz oder sowas wie 352lila, wobei letzteres wahrscheinlich sinnvoller wäre da so nicht ein Haufen kurioser Buchstabenketten entstehen - so können diese grundsätzlich auch über dieselben Vorlagen aufgerufen werden, wo nötig. Ich würde allerdings davon absehen Anime-, Manga und TCG-spezifische Sachen* aufzunehmen; selbst wenn man diese einfügt wüsste ich nicht wo man sie gescheit verwenden könnte. --Datei:Sugimori 672.pngMecanno-man^Mäh 15:59, 14. Jul. 2020 (CEST)

Ich vermute mal, dass Mecanno-man mit den TCG-spezifischen Sachen sowas wie Koiking-gokku Pikachu und Poncho o Kita Eievui meint, oder vergesse ich hier noch mehr TCG-Sonderfälle, die ich kenne sollte? GrollenKette951 00:17, 15. Jul. 2020 (CEST)

Naja, Delta-Pokémon könnte man diskutieren, aber die Kostüme war schon eher das was ich gemeint hab. Plus all die anderen sinnlosen, also iwie das einkaufende, das Fussballspielende etc. --Datei:Sugimori 672.pngMecanno-man^Mäh 01:12, 15. Jul. 2020 (CEST)

Als jemand, der sich mit diesem Thema noch nicht wirklich auseinandergesetzt hat, würde ich gerne wissen, was genau der Nutzen dieser zusätzlichen Parameter wäre, wenn die Sprites gleich sind. Ist es eine Absicherung für den Fall, dass z. B. irgendwann die Sprites von den Meteno-Meteorformen so geändert werden, dass man die Farbe des Kerns erkennen kann? Oder werden aktuell bzw. sollen irgendwann über Vorlagen zusätzliche Informationen anhand des eingestellten Form-Parameters dargestellt werden, z. B. die verfügbaren Fähigkeiten des Pokémon?
Eine Sache, die ich aber auf jeden Fall noch anmerken möchte, ist dass sowohl die Herrscher-Pokémon als auch die Pokémon in Herrscher-Größe (gegen erstere kämpft man in SM/USUM, letztere kann man in USUM erhalten) sich nicht nur durch ihre Darstellungsgröße unterscheiden, sondern zumindest laut Bulbapedia auch in den Werten Größe und Gewicht (ich weiß nicht, ob diese Werte im PokéWiki überhaupt irgendwo eingetragen sind, auf Bulbapedia stehen sie aber auf jeden Fall hier). Das erhöhte Gewicht dieser Pokémon in Herrscher-Größe hat sogar aufgrund von Attacken wie Rammboss oder Strauchler sogar Auswirkungen auf Kämpfe. Zudem haben diese Herrscher-Pokémon festgelegte Fähigkeiten. Auch wenn diese Formen bzw. Größen mit der 8. Generation wieder entfernt wurden, sind solche direkten spielerischen Unterschiede meiner Meinung nach ein besserer Grund für eigene Parameter als solche indirekten und ausschließlich optischen wie bei Meteno, zumindest wenn ich mit meinen Vermutungen bezüglich des Nutzens dieser Parameter einigermaßen richtig liege. -- Lasagne (Diskussion) 22:52, 14. Jul. 2020 (CEST)

Edit: Ich habe meinen Kommentar mal verschoben, da ich versehentlich in eine andere Diskussion reingegrätscht bin. Ich hoffe, diese Änderung geht so in Ordnung. Ich würde mich trotzdem freuen, wenn jemand noch meine Frage beantwortet. -- Lasagne (Diskussion) 12:54, 19. Jul. 2020 (CEST)

Die späte Antwort tut mir leid, Lasagne. Dein Beitrag ist tatsächlich etwas untergegangen bzw. mir einfach durchgerutscht. Kurz gefasst geht es um die Kennzeichnung von abweichenden Formen von Pokémon im Quelltext und eine andere Darstellung durch Vorlageneinbindungen. Hierdurch wird den Lesern und Benutzern angezeigt, dass es sich um eine andere Form handelt, die sich zwar nicht optisch, aber spielintern (z. B. durch eine andere spezielle Fähigkeit) unterscheiden. Es haben hierbei also nicht ausschließlich optische Unterschiede den Ausschlag gegeben. Vor allem in deinem Beispiel von Meteno, haben die Meteorformen optisch gar keinen Unterschied, weshalb ich das Beispiel nicht ganz verstehe und mir etwas unsicher bin, ob ich deine Frage überhaupt richtig verstanden habe. ^_^ ~ Taisuke ^Diskussion 14:01, 30. Jul. 2020 (CEST)

Danke für die Antwort, Taisuke, auch wenn sie für die Abstimmung etwas zu spät war. Damit verstehe ich schon ein bisschen besser, wozu diese Parameter eigentlich gut sind.
Mit dem Meteno-Beispiel meinte ich, dass Game Freak sich in irgendeiner späteren Generation dazu entscheiden könnte, das Design der Meteorform-Sprites so anzupassen, dass man die Farbe des Kerns erkennen kann. Auf diesen Fall wäre das PokéWiki vorbereitet, wenn jetzt diese Parameter hinzugefügt werden.
--Lasagne (Diskussion) 19:07, 30. Jul. 2020 (CEST)

Umsetzung

Danke an alle, die sich an der Abstimmung beteiligt haben! Ich werde mich um eine Umsetzung der mehrheitlich beschlossenen Parameter kümmern und im Anschluss hier nochmals auflisten. ~ Taisuke ^Diskussion 14:01, 30. Jul. 2020 (CEST)

Seh ich das richtig, das nur die Go-Klone eingefügt werden? Schliesslich bringt DeXters ver-ttte Stimme das ganze über die 2/3. --Datei:Sugimori 672.pngMecanno-man^Mäh 02:30, 31. Jul. 2020 (CEST)

Dafür hatte ich extra eine Ergebnis-Zeile eingefügt. Ja, die Klon-Pokémon werden eingefügt. Crypto-Lugia hat aber neben den vier ersten Fällen auch genügend Stimmen erhalten. ~ Taisuke ^Diskussion 12:53, 31. Jul. 2020 (CEST)

Du hast mich da leicht falsch verstanden. Meine Frage ist, ob die Go-Klone eingefügt werden, die Anime-Klone allerdings nicht. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:04, 31. Jul. 2020 (CEST)

Mein Fehler, entschuldige. Lediglich die Klone, die in beiden Medien zu finden sind: Bisaflor, Glurak, Turtok und Pikachu. Oder mit anderen Worten: Nur die GO-Klone. :D ~ Taisuke ^Diskussion 17:14, 31. Jul. 2020 (CEST)

Etwas, dass bei der Abstimmung entweder vielen nicht bewusst, oder möglicherweise auch egal war, ist mir leider erst jetzt im Nachhinein eingefallen: Und zwar sollen die Herrscher-Pokémon nicht in Vorlagen aufgenommen werden. Das bringt allerdings ein Problem mit sich: Wir haben nen ganzen Haufen Sprites der Herrscher-Pokémon, die ich jetzt zunächst ausgebunden bzw. gar nicht erst eingebunden habe. Das bringt nicht nur zusätzliche unbenutzte Dateien mit sich, sondern unterschlägt in gewissem Sinne auch Informationen, weil wir so tun, als hätten sie keine eigenen Sprites, was allerdings nicht korrekt ist. Jetzt also die Frage, vor der ich gerade stehe: Bleiben die Dateien uneingebunden, weil der Wunsch dieser Abstimmung darin besteht, dass sie nicht in Vorlagen beachtet werden, oder soll ich sie einfügen und damit gegen diese Abstimmung handeln, dafür aber die Dateien korrekt anzeigen? -- RobbiRobb 21:17, 11. Aug. 2020 (CEST)

Imo. sollten die eingebunden werden, aber nicht im normalen Schema, sondern iwie als "Herrscher-Rattikarl Sprite". Oder wie irgendwann von mir vorgeschlagen "023aherrscher" --Datei:Sugimori 672.pngMecanno-man^Mäh 00:17, 15. Aug. 2020 (CEST)

Ja, da liegen die bereits, siehe Datei:Pokémonsprite 020a Herrscher Bank.png. Der Punkt, den ich versuche zu machen, ist, dass die Abstimmung zum Ergebnis hatte, dass wir die Herrscher nicht in Vorlagen mit aufnehmen - mit dem Ergebnis, dass eben nicht nur Namenr, Nrname oder Id2Typ betroffen sind, sondern soweit ich das sehe auch sowas wie Sprites. Und dadurch sind die Dateien unbenutzt und werden überall als nicht-existent behandelt, was ich nicht für sinnvoll halte. Mein Ziel ist es im Grunde also, dass hier gegen das Ergebnis der Abstimmung gehandelt wird, was zwar nach unseren Regeln soweit ich das sehe nicht zwangsläufig verboten ist, definitiv aber nicht im Sinne einer Abstimmung ist, dass das Ergebnis hinterher ignoriert wird und trotzdem das Gegenteil passiert. Die Frage an dieser Stelle ist, warum sich die Benutzer, die gegen die Herrscher gestimmt haben, so entschieden haben, und ob sie sich des Problems, vor dem ich jetzt als mehr oder weniger Zuständiger für die Vorlage:Sprites stehe, bewusst waren, oder ob sie das ganze überhaupt nicht bedacht haben. -- RobbiRobb 01:47, 15. Aug. 2020 (CEST)

Die Herrschersprites sollen meiner Meinung nach, auch wenn das gegen das Ergebnis der Abstimmung geht, auf jeden Fall in die Spritevorlage aufgenommen werden. Ich glaube, dass das eher mit einem Sonderschema geregelt werden sollte, wie es oben auch schon geschrieben ist, als mit dem Standardschema. GrollenKette951 23:57, 15. Aug. 2020 (CEST)

An sich bin ich dafür, dass die Sprites eingebunden werden (so hab ich, glaube ich, auch abgestimmt), aber das hier war immer noch eine Abstimmung, deren Ergebnis mMn keines Falls ohne weiteres zum Teil ignoriert/angepasst/... werden sollte. Wenn dann sollte man mMn eine breite Zustimmung aller Stimmberechtigten haben, bevor da irgendwas gemacht wird. --DeXter 00:32, 16. Aug. 2020 (CEST)

So wie ich das sehe, sollte es ausreichen, wenn sich dazu die an der Abstimmung teilnehmenden Benutzern nochmals äußern, die gegen eine Aufnahme von Option (M) gestimmt haben. Sollte sich daraus dann im Nachhinein eine Mehrheit ergeben, sehe ich kein Problem darin, in diesem Fall entgegen dem ursprünglichen Abstimmungsergebnisses zu handeln. Schließlich muss ich gestehen, dass die Option nicht optimal von mir festgelegt wurde, da es mehrere verschiedene Elemente in einen Top wirft. Zumal die Option darüber hinaus auch noch Spin-off-Elemente (Crypto) mit Hauptspiel-Elementen (Herrscher) vermengt. Als einer derjenigen, die sich eigentlich gegen diese Parameter ausgesprochen hat, würde ich mich im Nachhinein bzgl. der Herrscher-Pokémon umentscheiden und diese nun doch befürworten. Weitere Argumente dafür lieferte übrigens Lasagne schon weiter oben in den Kommentaren des Spoilers. ~ Taisuke ^Diskussion 10:11, 16. Aug. 2020 (CEST)

Schwierig. Die Herrscher unterscheiden sich lediglich Storybasiert durch eine Aura und ansonsten nur in Größe/Gewicht. Das dieser Unterschied bei Sprites auffällt glaube ich nur bedingt. Ich kann mich hier nicht zu einem Pro durchringen. Daher enthalte ich mich in diesem Fall und überlasse es der Mehrheit, da ich auch mit einer Einbindung leben könnte. Ggf. sollte man nochmal einen Ping an die die abgestimmt haben absetzen. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:36, 16. Aug. 2020 (CEST)

Behandelt die Abstimmung überhaupt die Vorlage:Sprites? So wie ich das verstehe ging es doch nur um die IDs, also namenr, nrname, id2typ etc. --Datei:Sugimori 672.pngMecanno-man^Mäh 12:41, 16. Aug. 2020 (CEST)

Laut meinem Protokoll vom Chattreffen vom 06.03.2021 hatte Robbi angemerkt das nun die Herrscher Inexistent sind und es gab hier wohl noch offenen Diskussionsbedarf!? Der Punkt wurde dann geschoben aufgrund kurzfristiger Abwesenheit des ein oder anderen und ist dann im Chattreffen wohl etwas untergegangen. Bin mir daher über seine Archivierung im Unklaren. @Robbi kannst du es bitte hier noch einmal darlegen? Danke. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:51, 7. Mär. 2021 (CET)

Ich hatte noch mal geschaut und so wie es aussieht, habe ich die vorrübergehend unbenutzten Herrscher-Sprites wieder eingebunden, mit dem Ergebnis, dass ich damit gegen die Entscheidung der Abstimmung gehandelt habe. Ich denke allerdings, dass wir uns alle einig sein sollten, dass es Schwachsinn ist, die Sprites zu entfernen und so zu tun, als gäbe es sie nicht, wenn sie ziemlich offensichtlich aus den Spieledaten stammen und dementsprechend auch in den Spielen einsehbar sind. Bin mir daher etwas im Unklaren, wie genau wir hier weiter vorgehen wollen. -- RobbiRobb 16:42, 7. Mär. 2021 (CET)

Das so ein Fall wo sich lediglich der Sprite von allem anderen in der Größe Unterscheidet... sehe da die Problematik zwischen Abstimmung und Informationsvernichtung... wenn das Tai für Tai so in Ordnung ist und es sonst nichts weiteres dazu gibt können wir den Punkt auch ins Archiv schieben... Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:51, 7. Mär. 2021 (CET)

Wertschätzung - eine Umfrage an die SBs

Hallo liebe Stimmberechtigte User des Wikis! Gestern im internen Chattreffen ging es u. A. um das Thema Wertschätzung, bei dem wir darüber geredet haben, was wir ESBs z. B. im Umgang mit neuen Usern, in Bezug auf Rollbacks und Rückgängigmachungen, allgemein in Discord usw. besser machen können bzw. sollten. Dabei wurde gestern auch entschieden, dass wir darüber mit euch in möglichst großer Runde reden möchten, da ihr eine andere Sichtweise auf das Thema habt als wir und damit nochmal anderen Input geben könnt, den das Thema braucht.

Daher die Fragen bezogen auf Wertschätzung: Was für Probleme seht ihr? Gibt es etwas, das ihr euch allgemein oder vom ESB-Kreis wünscht? Wollt ihr dazu noch etwas anderes los werden?

Außerdem wünschen wir uns ein Chattreffen mit SBs zu dem Thema. Wenn es hier genügend Beteiligung seitens der SBs gibt, würde also eins geplant werden ^^

Hier noch der Ping AAWiki, Aklex, BeyJim, BlauesSerpiroyal, DeepSpace, Der Sternendiamantritter, DieTaube, Flonc, Haijo18, Jass, K0pplosio, Lasagne, Mario-WL, Maxmiran, Nescientist, Panflami, Pk-fan, Poffelino, PokéSpe, Pxmusic, Red Bull Salzbourg, Rolex, Rüdiger, Zeynex --DeXter 20:22, 7. Mär. 2021 (CET)

Mit dem Wertschätzung fällt aktuell nichts besonderes ein. Weder Probleme noch Wünsche.-- AAWiki ^Diskussion 21:01, 7. Mär. 2021 (CET)

Das Wichtigste ist der Austausch zwischen zwischen den erfahrenen und den erfahrenen und neuen Benutzern, z. B. Könnten die Bearbeitungen von Neulingen, die schon ein paar Bearbeitungen getätigt haben, bewertet werden und ein Feedback abgegeben werden. Sonst können sie nicht wissen, ob ihre Bearbeitungen im Sinne des Wikis sind, oder nur gut genug sind, damit sie nicht rückgängig gemacht werden. Rückgängigmachungen können natürlich sehr frustrierend sein, aber mit ausreichender Erklärung in Ordnung. Als bessere Alternative zu Rückgängigmachungen finde ich es, die veränderte Stelle zu verbessern, sodass alle zufrieden sind. Für ein Chattreffen wäre ich bereit. --Poffel — Diskussion 00:00, 8. Mär. 2021 (CET)

Hallo DeXter! Für mich ist es sehr klar : Ich habe nur positive Bemerkungen zu sagen.

Alle ESB, mit denen ich schon auf Discord gesprochen habe,

- sind hilfsbereit, involviert und ehrenhaft trotz meiner frz. Staatsbürgerschaft

- nehmen sich Zeit, um alle meine Fragen am schnellsten zu beantworten

- leiten mich an die richtige Person weiter, wenn sie etwas nicht wissen

- sagen mir deutlich, was an einer solchen Änderung nicht gut ist.

- klicken oft auf "danken", sogar manchmal für sehr kleine Änderungen von mir.

- vergeben Auszeichnungen, obwohl ich mich fast nur mit den anderen Sprachen beschäftigt habe.

Auch mit manchen SBs (Serpi und DieTaube z.B.) fühle ich diese Aspekte.

Das alles wurde möglich, weil die Stimmung im Server Pokéwiki auf Discord perfekt ist.

Über das Thema "Chattreffen mit ESB und SB" : Ich bin zu schüchtern und mein Niveau auf deutsch ist nicht genug fließend, um mitzureden, aber ich würde gern kommen und hören, wenn es existiert. ^^ Red Bull Salzbourg (Diskussion) 00:42, 8. Mär. 2021 (CET)

Heya also bis jetzt fällt mir nichts ein was ich auflisten könnte ... rollbacks habe ich noch nie mitgemacht und würde sagen das ich nicht aktiv genug im discord bin um da etwas beurteilen zu können :o wünsche habe ich auch keine ^^ Zeynex (Diskussion) 01:57, 8. Mär. 2021 (CET)

Ich hätte auch nichts negatives zu sagen, ich bin sehr zufrieden. Bei einem Chattreffen wäre ich auch dabei, aber da ich denke, dass ich nichts wirkliches beitragen kann, würde ich womöglich nur zuhören. Panflami ^Diskussion 09:31, 8. Mär. 2021 (CET)

Danke für eure ersten Feedbacks. Uns geht es darum Sachen wo wir besser werden können zu verbessern die wir ggf. mit der Zeit aus den Augen verloren haben. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:44, 8. Mär. 2021 (CET)

Ich weiß leider nicht richtig, wie sich die Wertschätzung auf komplett neue User auswirkt. Aus meiner Sicht als SB kann ich sagen, dass ich eigentlich wunschlos glücklich bin. Wenn etwas gemacht werden soll oder nach Meinungen gefragt wird, werden oft SBs und oft auch Leute unter SB berücksichtigt. Im Bezug auf die Rückgängigmachungen schließe ich mich Poffel an. Es sollte öfters die Benutzerdisku verwendet werden um Feedback zu geben. Das sehe ich hin und wieder, aber mMn nicht oft genug. An einem Chattreffen mit SBs habe ich nichts auszusetzen. Sollte es genügend Themen geben bei denen wir mitwirken können, wäre ich gerne dabei. ~~ DieTaube 12:46, 8. Mär. 2021 (CET)

Also in Sachen Wertschätzung und Feedback schließe ich mich auch den anderen an: Aus meiner Sicht sind alle sehr freundlich und sehr hilfsbereit, vor allem auf Discord. Ich denke ebenfalls, dass es manchmal sinnvoll wäre, bei Rückgängigmachungen in die Diskussion oder zumindest in die Zusammenfassung dazuzuschreiben, warum es rückgängig gemacht wurde, vor allem bei neuen Benutzern. Ich wäre auf jeden Fall bei einem Chattreffen dabei, wenn es meine Zeit zulässt. BlauesSerpiroyal ^Diskussion 16:11, 8. Mär. 2021 (CET)

Ich bin zwar wahrscheinlich kein Durchschnitts-SB, aber ich hatte schon so meine einzwei Erfahrungen mit Rückgängigmachungen/Änderungen (insb. von Projektleitern glaub ich), die ich ein wenig top-down und/oder wenig sinnvoll fand (mal unter falscher Annahme und ohne Erklärung, mal nach höflicher Nachfrage trotzdem falsch verstanden und verschlimmbessert). Ich hab das allerdings nie als mangelnde Wertschätzung empfunden, sondern einfach "kann passieren" oder vielleicht auch geschuldet der oftmals sinnvollen Annahme, dass man als Pokewiki-Profi es besser weiss. (Wie andere schon sagten, die Leute scheinen nett und alles, aber es war ja nach Kritik gefragt.)

Außerdem noch ein Punkt, der vielleicht indirekt dazugehört: Ich find das hier voll schwer "einzusteigen" und einfach zu editieren, soll heißen hier ist wirklich (insb. im Vergleich) sehr viel custom Zeugs, dass man erstmal wissen muss (verschachtelte Templates, Variablen, css, halt in erster Linie so Automatisierungs-freundliches Zeugs wozu man erstmal ein Handbuch brauch - und ich bin nun wahrlich kein Technik-Trottel). Da erinner ich mich sogar auch an ne Diskussion (warst du das nicht sogar, Ryuichi?), in der ich hinterher das Gefühl hatte, dass von Bearbeitern (implizit oder explizit) erwartet wird sich da vorher einzulesen. Von der Verantwortung her seh ich das eher umgekehrt; die Wartbarkeit für Top-Editierer und Top-Techniker entspricht nicht der Wartbarkeit allgemein. (Ich hoffe, dass klar wird was ich meine, könnt ich ggf. auch bei einem etwaigen Chattreffen nochmal erläutern, wenn das gefragt ist und ich dabei wär.) Nescientist (Diskussion) 20:15, 8. Mär. 2021 (CET)

Danke für das weitere Feedback! Ich möchte hier nur eben loswerden, dass es keine halben und nicht vollwertigen SBs gibt, sondern nur vollwertige. Deswegen seid ihr ja SBs und deswegen brauchen wir euer Feedback! ^^ Feblue 21:16, 8. Mär. 2021 (CET)

Hi zusammen! Ich geb mal noch meinen Senf dazu aus der Perspektive von jemandem, der Bestandteil dieser "Konflikte" im Rahmen dieser Diskussion war und der das Wiki schon viele Jahre beobachtet. Zunächst finde ich es toll, dass ihr euch mit dem Thema befasst und das Protokoll liest sich so, als wären da im Chattreffen viele Schmerzpunkte angesprochen worden. Das finde ich wichtig, weil man dann öfter dazu neigt, dann an Symptomen zu arbeiten und z. B. neue Auszeichnungen etc einzuführen, als "ans Eingemachte zu gehen". Im Groben sehe ich zwei Themen:

• Vertrauen: Das Wiki ist ohne Frage eines der Fanwikis mit der höchsten Qualität, die ich kenne. Dementsprechend wollen die User der höheren Ränge die hohe Qualität mit allen Mitteln schützen. Das hat in der Vergangenheit zu einem öfters mal pampigen Umgang mit Fehlern von Usern geführt und auch dazu, dass man quasi perfekt sein musste, um sich neue Rechte zu erarbeiten, weil der Anspruch gigantisch hoch war. Einerseits macht das euren Schreibtisch selbst voll, weil ihr euch um alles selbst kümmern müsst, und andererseits führt es zu dieser großen Einstiegsbarriere, weil Leute sich fürchten müssen, was falsch zu machen. Ich glaube, häufiger mal lockerlassen und auch mal kleinere Risiken eingehen tut nicht weh und fühlt sich für den User, den das betrifft, einfach auch gut an. "Das zu erklären kostet viel zu viel Zeit, dann mach ichs lieber selbst" ist keine gute Grundeinstellung, denn das befähigt neue Autoren nicht, zu lernen und euch Sachen perspektivisch abzunehmen. Leitfäden sind gut, aber viele lesen die halt einfach erst in einem späteren Schritt und wohl eher kaum als Einstieg in die Wikiarbeit.
• Wertschätzung: Über "der Ton macht die Musik" haben wir schon viel gesprochen und es ist auch deeeutlich anders als z. B. vor einem Jahr, was ich super finde. Klar, jeder Mensch ist verschieden, aber dennoch seid ihr in verantwortungsvoller Position bei einer echt großen Community, und das ist etwas, das man sich immer mal wieder bewusst machen muss. Je höher man klettert, desto weniger kann man von sich selbst oder anderen Leuten mit dickem Fell ausgehen, sondern desto mehr muss man versuchen, sich in empfindlichere Leute hineinzuversetzen. Nen ersten Eindruck machen Wiki und Community genau einmal, und wenn der daneben geht, dann sind User oder potenzielle Autoren für das Wiki verloren. Und diesen Eindruck kann man gut steuern: Begründungen liefern, Hilfe anbieten, habt ihr alles schon im Protokoll angesprochen. Manchmal tuts auch schon ein einfaches Verständnis zeigen à la "ich verstehe, was du meinst, da haben wir uns aber wegen xyz dagegen entschieden". Und wenn euch z. B. mal eine Frage nervt, dann antwortet lieber gar nicht als pampig, denn da kommt offensichtlich jemand mit einer Idee oder einer Nachfrage auf uns zu, und beide Fälle brauchen "Liebe". :P
• Bringt mich zum letzten kleinen Punkt als Fazit aus den beiden anderen: N bisschen mehr gucken aufs Positive würde, glaube ich, nicht schaden. Es wird zum Schutze des Wikis häufig über Probleme und Risiken argumentiert, dabei stecken in Ideen und Nachfragen ja auch viele Chancen, das Wiki nach vorne zu bringen. Wenn ein User was z. B. nicht findet, dann sollte man das nicht deuten als "der war zu blöde dazu", sondern im Sinne von "vielleicht fehlt hier ja im Wiki was, damit man sich gut zurechtfinden kann?" Dann begegnet man gleichzeitig den Leuten anders und bringt das Wiki noch weiter voran.

Danke euch für diese Initiative! Maxmiran 11:08, 9. Mär. 2021 (CET)

Ich bin zwar noch nicht allzu lange dabei und habe weder über das Wiki noch im Discord einen Überblick, aber ein paar Sachen könnte ich vielleicht auch dazu sagen.

• Bisher hatte ich nur mit Grollenkette wirklich Kontakt, aber wenn ich z.B bei der Kategorisierung etwas falsch gemacht habe oder auch am Anfang, als ich noch viele Fragen zum Upload der Karten hatte, hat er mir das ganz normal erklärt bzw mich darauf hingewiesen. Außerdem hat sich Taisuke bei mir auf der Diskussionsseite bedankt, was ich wirklich toll fand. Wie gesagt war ich noch nicht groß auf dem Discord und weiß nicht, ob es da mal Streit gab oder so etwas, aber an sich finde ich mich hier gut aufgehoben.

• Ich schließe mich der Meinung an, dass man Rückgängigmachungen und Bearbeitungen dem Nutzer, gerade neuen, evtl (besser) erklären könnte. Auch wenn ich selbst davon nicht betroffen bin, da mir bisher Grollenkette alle Fragen beantwortet hat. Da könntet ihr evtl eine neue Diskussion für Anfänger oder Nutzer mit wenig Erfahrung öffnen, wo sie ihre Fragen loswerden können (wobei, das können sie ja auch bei Discord bzw auf der Diskussionsseite des Artikels, also nevermind).

• Auch bin ich der Meinung, dass manche Bearbeitungen, Templates etc ziemlich kompliziert sind (habe mir das alles noch nicht wirklich angeschaut, aber auf den ersten Blick wirkten einige Dinge ziemlich schwierig). Zitat von Maxmiran: "andererseits führt es zu dieser großen Einstiegsbarriere, weil Leute sich fürchten müssen, was falsch zu machen" Ich weiß nicht, inwieweit das bereits der Fall ist (falls ja, einfach überlesen,), aber dazu sind doch die Diskussionsseiten da? Wenn also jemand unsicher ist, zb weil er das Template nicht einbauen kann oder nicht weiß, ob der Satzbau eines neuen Artikels fürs Wiki geeignet ist, dann können die Nutzer das doch einfach auf die Diskussionsseite schreiben. Dann ist es nicht auf der öffentlichen Seite und erfahrene Nutzer können sich das in Ruhe anschauen und soweit bearbeiten, bis es in Ordnung ist, ohne dass es jemanden auf der öffentlichen Seite stört oder rückgänging gemacht werden müsste. Wie gesagt weiß ich nicht wie sinnvoll dieser Abschnitt ist, denn das ist ja eigentlich der Sinn von Diskussionsseiten.

• Ein oder zwei Nutzer haben von einem Chatprotoll geschrieben, gab es also bereits ein Chattreffen? Falls ja, werde ich mir das mal ansehen und schauen, ob ich da noch was dazu sagen kann. (War das auf Discord?)

• Als weitere Einstiegshilfe für neue Benutzer könnte es vielleicht eine Standard-Vorlage für die Benutzerseite geben? Ich habe nicht geschaut, ob es da was gibt und weiß auch, dass sie nicht Pflicht ist, aber das könnte eine Hilfe für alle sein, die nicht so richtig mit den Templates klar kommen.

Ich finde diese Umfrage ist eine gute Idee, es gibt aber nichts, worüber ich mich wirklich "beschweren" wöllte. Im Gegenteil, ich freue mich, etwas zu diesen Diskussionen und zum Wiki betragen zu können und werde mir nach den Kartenuploads weitere Dinge anschauen. DeepSpace (Diskussion) 13:11, 9. Mär. 2021 (CET)

Hey DeepSpace! Danke auch dir für das Feedback. Das Protokoll findest du hier. Dieses Treffen wurde von den verlässlichen Benutzern und höher auf Discord im Voicechat abgehalten. Im Protokoll findest du alles, was wir besprochen haben. ^^ Wie genau stellst du dir die Standard-Vorlage vor? Wir haben ja schon Vorlage:Willkommen, oder würdest du neuen Benutzern etwas ganz anderes auf ihre Diskussionsseite schreiben wollen? Feblue 15:46, 9. Mär. 2021 (CET)

Bevor das zu stark vertieft wird bitte das Thema des Abschnittes (Wertschätzung) im Auge behalten und lieber "Neueinstieg und wie wir ihn verbessern können" in einem separaten Abschnitt behandeln. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:02, 9. Mär. 2021 (CET)

Hey Feblue, danke für den Link zum Protokoll, ich schaue es mir später mal an.

Nein, ich meine nicht Vorlage:Willkommen die auf der jeweiligen Diskussionsseite angezeigt wird, sondern die Benutzerseite, bei der die Nutzer etwas über sich selbst schreiben können. Dort scheint jeder, den ich bisher besucht habe, einen anderen Style zu verwenden (Farben, Aufbau usw). Ich möchte aber ungern jemandem seine Seite "klauen". Deshalb würde ich mir da eine Vorlage wünschen, die ich später mit mehr Erfahrung anpassen kann. (Nein, ich habe mich damit noch nicht beschäftigt (möchte erst einmal die Karten Uploads beenden) und es wäre für mich wahrscheinlich nicht schwer, von verschiedenen Benutzern Elemente zu nutzen und für mich anzupassen, aber es gibt sicher Nutzer, denen sowas möglicherweise zu kompliziert wäre).

Mir geht es hier also um die oben erwähnte Einstiegsbarrerie, auch wenn die Benutzerseite keine Pflicht ist. Dennoch hat Ryuichi Recht, das ist zu offtopic und wir solltten da einen neuen Abschnitt beginnen oder per PN weiterschreiben, falls gewünscht. (Der vorstehende nicht signierte Beitrag stammt von: DeepSpace • Diskussion • Beiträge • Sperren)

Na dann äußere ich mich doch auch mal ^^ Möchte mich erstmal der Menge anschließen, dass das Klima sehr perfekt ist, gerade auch durch den direkten Kontakt über Discord. Den Umgang mit neuen und unerfahrenen Usern dort kann ich eigentlich nur als positiv werten, alles wird freundlich gehandhabt, man fühlt sich schnell als Teil der Familie. Bei Meinungsverschiedenheiten hab ich bisher noch keine wie von damals beschrieben pampigen Antworten erlebt, sondern es wurde stets kompetent geholfen und erklärt, was es für Probleme gibt und wie man diese lösen kann. Gerade für Einsteiger finde ich das wichtig. Am Anfang sind viele entweder unsicher, handeln noch impulsiv und unüberlegt oder sind zu verspielt mit den Möglichkeiten des Wikis. Da ist es völlig normal, dass nicht alles wie gewünscht läuft. In dieser Phase sollten wir jede Unterstützung für den User nutzen, der möglicherweise der ESB von morgen sein könnte. Will heißen, dass ich auch befürworte, dem User auch mal Feedback zu geben, sei es über die Disku oder ein "Danke" sowie Rücksetzungen im Normalfall zu begründen. Dabei finde ich besonders wichtig, dass hier die Mithilfe im Vordergrund steht und nicht die Fehler. Durch mehr Wertschätzung und Akzeptanz denke ich, dass der User positive Eindrücke mitnimmt und so mehr Zutrauen ins Projekt Wiki fasst, sich helfen lassen oder selbst an den Schwachstellen arbeiten will.

Wie schon gesagt hab ich noch keinen falschen Umgangston erfahren und bin auch zu selten im Thema drin, daher kann ich nur schwer einschätzen, wie die aktuelle Situation aussieht. Maxmiran hat wie immer noch schöne Worte gefunden, denen ich mich anschließe. Das Chattreffen finde ich auch gut und werde möglichst erscheinen, auch wenn ich vlt doch eher noch nur zurückhaltender Zuhörer bin ^^" Pxmusic ^Diskussion 00:37, 10. Mär. 2021 (CET)

Terminfindung

Liebe SBs! Im Namen des ESB-Teams danke ich euch für das euer Feedback. Da es ein großflächiges Interesse an einem Chattreffen gibt, habe ich eine Doodle-Umfrage zur Terminfindung erstellt. Ihr könnt bei Interesse also dort mit eurem Wiki-Namen für einen Termin abstimmen. Berücksichtigt dabei aber, dass ihr möglichst alle Termine auswählt, an denen ihr erscheinen könntet, damit wir den bestmöglichen Termin finden, an dem möglichst viele von euch teilnehmen können. Falls ihr noch weitere Fragen habt bzw. etwas in der Umfrage nicht funktioniert, lasst es mich bitte schnellstmöglich wissen. Ihr könnt bis zum 26. März abstimmen. Die SBs, die hier bisher noch nicht geschrieben haben, können dies natürlich auch weiterhin tun!

Ping geht an AAWiki, Aklex, BeyJim, BlauesSerpiroyal, DeepSpace, Der Sternendiamantritter, DieTaube, Flonc, Jass, K0pplosio, Lasagne, Mario-WL, Maxmiran, Nescientist, Panflami, Pk-fan, Poffelino, PokéSpe, Pxmusic, Red Bull Salzbourg, Rolex, Rüdiger, Zeynex Feblue 21:34, 18. Mär. 2021 (CET)

Hallo zusammen! Die Mehrheit hat für den 10. April gestimmt, folglich lade ich euch ein, an diesem Tag auf Discord um 19 Uhr im Voicechat zu erscheinen. Bis dann! ^^ AAWiki, DaneeBound, Der Sternendiamantritter, DomiDsLP, Erdnussflip007, EternalChimaera, Flyfunner, FusselTeddy, Kaneros, Kirby aka Siss, KR7907, Nur, Pk-fan, Seesam Feblue 23:59, 26. Mär. 2021 (CET)

Spezies-Abschnitte in Pokémon-Artikeln

Es ist mittlerweile einige Jahre her seitdem beschlossen wurde, die Pokémon-Artikel umzustrukturieren und ihnen vor allem mit dem Spezies-Abschnitt mehr Fließtext bzw. Leben einzuhauchen. Dass der Prozess langwierig werden würde, war bestimmt allen Beteiligten klar, aber das wir heute noch nicht fertig sind, ist etwas schade. Die Gründe dafür dürften mannigfaltig sein. Anfangs war es bestimmt mitunter der Gegenwind einiger Personen, die sich an diesen für sie unnötigen Informationen – schließlich bringen sie für das Spielerlebnis keinen Vorteil und schieben somit relevantere Informationen weiter nach unten im Artikel – störten und ihren Unmut im Anschluss an die Abstimmung immer mal wieder benannten, aber auch die Schreiber der Texte waren rar gesät. Wir hatten einige sehr motivierte Benutzer, die große Teile unserer Fließtexte dort verfasst und dabei zu einem großen Teil sehr schöne Abschnitte geschaffen haben. Aber unter diesen Schreibern war auch immer mal wieder die Frage aufgekommen, ob man das Ganze nicht knapper zusammenfassen kann, da die Informationen sich oftmals doppelten. Dies ist mir als Projektleiter in all den Jahren auch nicht verborgen geblieben und hat es teilweise sehr schwer gemacht, objektiv zu kontrollieren und dann etwas auch als geprüft in den To-do-Listen zu markieren.

Damit dieser Einleitungstext nicht zu sehr ausufert, versuche ich mich fortan kurz zu fassen. Max hat als einer der fleißigen Schreiber und ehemaliger Projektleiter einen Vorschlag geäußert, wie man diese Redundanz in den Artikeln reduzieren kann, ohne die Texte komplett streichen bzw. nicht mehr schreiben zu müssen. Bei Interesse kann die vorangehende Diskussion dazu hier nachgelesen werden.

Zusammengefasst geht es in dieser Abstimmung um die drei Abschnitte Aussehen und Körperbau, Attacken und Fähigkeiten sowie Verhalten und Lebensraum. Diese drei Abschnitte sollen zu einem einzelnen zusammengefasst werden, da das Aussehen und der Körperbau in den beiden folgenden Abschnitten erneut aufgegriffen wird, um beispielsweise zu erläutern, dass die scharfkantigen Klauen für Attacken wie Schlitzer und Kratzer benutzt werden, um Gegner in die Flucht zu schlagen, oder dass die farbliche Gestaltung des Körpers dafür sorgt, dass sich das Pokémon in seinem Lebensraum perfekt verstecken kann. Es wird somit also sehr oft in den Abschnitten Attacken und Fähigkeiten sowie Verhalten und Lebensraum Dinge aus dem Aussehen und Körperbau-Abschnitt wiederholt. Das erweckt beim Lesen dieser Abschnitte den Eindruck, dass die Aufteilung in drei Abschnitte künstlich wirkt und sich bestimmte Teile immer wiederholen.

Aus diesem Grund sollen diese drei Abschnitte zu einem zusammengefasst werden. Ob dafür eine zusätzliche Überschrift sinnvoll ist, ist ebenfalls Bestandteil der Abstimmung. Da einige Pokémon mehr als nur eine Form besitzen, hat sich Max als Beispiel für die Veränderung Mauzi ausgesucht. Hier sind also die Unterüberschriften für die einzelnen Formen gewollt, aber nur bei Pokémon mit mehreren Formen so dann im Anschluss angedacht.

Beispielhafter Spezies-Abschnitt: momentane Struktur vs. vorgeschlagene Struktur

Sollte irgendetwas nicht klar sein, scheut euch bitte nicht bei den Kommentaren nachzufragen! Und falls jemand kein stimmberechtigter Benutzer sein sollte, aber dennoch seine Meinung dazu mit uns teilen möchte, kann er ebenfalls gerne den Kommentare-Abschnitt dafür nutzen. :) ~ Taisuke ^Diskussion 11:17, 30. Mär. 2021 (CEST)

Abstimmung

Abstimmung abgeschlossen

Diese Abstimmung dient der Entscheidung, ob die Abschnitte Aussehen und Körperbau, Attacken und Fähigkeiten sowie Verhalten und Lebensraum in den Pokémon-Artikeln zu einem einzigen zusammengefasst werden sollen. Jeder stimmberechtigte Benutzer kann eine Stimme abgeben. Die Abstimmung läuft bis zum 13. April 2021 um 23:59. Heute ist der 18.04.2024 07:19 Uhr.

Alte Struktur

1. Ihr braucht nicht, sich über solche Änderungen Kopfschmerzen zu machen. Es gibt sicherlich viele Themen, die viel dringlicher als das sind. Red Bull Salzbourg (Diskussion) 15:12, 30. Mär. 2021 (CEST)
2. Attacken, Fähigkeiten, Verhalten und Lebensraum interessieren mich nicht --Poffel — Diskussion 20:47, 31. Mär. 2021 (CEST)
3. Von den beiden zur Auswahl stehenden Optionen halte ich die aktuell verwendete Struktur für sinnvoller. Einerseits finde ich es persönlich schade, dass zumindest im Mauzi-Beispiel der Abschnitt Attacken und Fähigkeiten größtenteils weggefallen ist, der die Kampfeigenschaften eines Pokémon in einem Fließtext behandelt und mit dem Aussehen und Verhalten des Pokémon in Verbindung gebracht hat.
   Viel gravierender finde ich jedoch den Verlust der Strukturierung an sich. Auch wenn ich die genannten Probleme mit der aktuellen Struktur nachvollziehen kann, halte ich es nur wegen einiger doppelt genannter Informationen nicht für sinnvoll, die Strukturierung durch Überschriften bei vielen Pokémon ganz aufzugeben. Ohne Informationsvernichtung, von der ich in der Regel kein Freund bin, hätte man bei vielen Pokémon wie z. B. Bisasam auch auf den meisten großen Anzeigegeräten einen ganzen Bildschirm lang Freitext ohne eine einzige Überschrift dazwischen. Hier (und auch in weniger extremen Fällen) sehe ich das Problem, dass einige Leser den Fließtext möglicherweise ganz überspringen statt nur einzelne für sie interessante Abschnitte zu lesen. Außerdem ist ein solcher „unstrukturierter“ Abschnitt meiner Einschätzung nach auch schlechter wart- und erweiterbar.
   
   Ich denke aber auch, dass die aktuelle Struktur des Spezies-Fließtexts verbessert werden kann. Einerseits befürworte ich die klare Unterteilung nach Formen der vorgeschlagenen Struktur. Andererseits möchte ich, um auch etwas Konstruktives beizutragen, selbst einen Vorschlag machen, der hoffentlich einige der Probleme der aktuellen Struktur löst: Ich würde die Informationen, die aktuell im Abschnitt Aussehen und Körperbau stehen, ohne eigene Überschrift (abgesehen von der jeweiligen Form, falls vorhanden) aufführen und um naheliegende, allgemeine Informationen erweitern, die sich aktuell vor allem im Abschnitt Verhalten und Lebensraum befinden (also z. B. um die im ersten Beitrag dieser Umfrage genannten Infos zu scharfkantigen Klauen und der farblichen Gestaltung des Körpers). Das würde eine gute Einleitung in den Spezies-Fließtext darstellen. Der Abschnitt Verhalten und Lebensraum sollte dann eine Art Erweiterung hiervon sein, die aber nur dann eine eigene Überschrift benötigt, wenn sie eine gewisse Länge erreicht (z. B. sechs Zeilen), sonst sollte dieser Teil zum allgemeinen Abschnitt gehören. Der Abschnitt Attacken und Fähigkeiten ist dann eine weitere Erweiterung der Einleitung. Dieser Teil sollte in der Regel eine eigene Überschrift erhalten, da jedes Pokémon mit seinen Attacken und Fähigkeiten hierfür ausreichend Inhalte bieten sollte. Ganz abgesehen von der Umstrukturierung kann dieser Abschnitt zudem um kurze (!) Informationen zu den Statuswerten des Pokémon erweitert werden, z. B. „Mauzi hat insgesamt recht geringe Statuswerte, sein katzenartiger und schlanker Körperbau macht sich aber durch eine ausgeprägte Initiative bemerkbar“. (Ich sehe gerade, solche Infos stehen bei einigen Pokémon schon, aber bei vielen auch nicht.)
   Bei Pokémon mit mehreren Formen würde ich grundsätzlich auch innerhalb der Abschnitte für jede Form wie eben beschrieben weiter unterteilen wollen. Ich denke jedoch, dass in vielen Fällen die Abschnitte Attacken und Fähigkeiten sowie Verhalten und Lebensraum bei den alternativen Formen so kurz wären, dass sie mit der „Einleitung“ verbunden werden können und somit keine eigene Überschrift benötigen. Außerdem denke ich, dass bei Pokémon, die nicht mehrere gleichwertige Formen, sondern nur Mega-Entwicklungen oder Gigadynamax-Formen haben, keine zusätzliche Überschrift für die Normalform vonnöten ist. Bei Pokémon, deren verschiedene Formen sich fast nur im Aussehen unterscheiden, wie beispielweise bei Schalellos, könnte man die verschiedenen Formen wie bisher nur in der Einleitung erwähnen, statt strikt primär nach Formen zu unterteilen.
   
   Ich hoffe, ich konnte meinen Standpunkt zu diesem Thema einigermaßen verständlich rüberbringen. Mir ist bewusst, dass alternative Vorschläge besser während der Diskussionsrunde im Pokédex-Projekt gepasst hätten, aber ich wollte hier trotzdem nicht einfach „Nein“ sagen, ohne eine Alternative vorzuschlagen. -- Lasagne (Diskussion) 20:01, 2. Apr. 2021 (CEST)

Zusammenlegung der drei Abschnitte

1. Ich finde es gut, dass hier etwas doch so großes angepackt und verändert werden soll. Die angesprochenen Defizite der aktuellen Struktur kann ich nur wiederholen und mir gefällt Max’ Vorschlag enorm. Zweifel habe ich nur daran, wie lange das dauern wird, aber mit genügend Hilfe, die ich von meiner Seite aus auch gerne zuspreche, kann der Speziesabschnitt ein richtiges Schmuckstück der Pokédex-Artikel werden. mir würde auch die Überschrift "Spezies" genügen, darunter muss keine weitere Überschrift kommmen. ^^ Feblue 13:57, 30. Mär. 2021 (CEST)
2. Ich kann mich dem Ganzen nur anschließen. Die wiederholenden Aspekte in den Abschnitten können lästig sein und bedürfen definitiv eine Überarbeitung, jedoch habe ich immense Zweifel daran, dass das so gut läuft wie sich vorgestellt wird... Ich habe definitiv keine Zweifel an das Team, keinesfalls! Jedoch haben wir nun schon fast 900 Pokémon, die alle überarbeitet werden müssten. Dazu kommen auch noch die verschiedenen Formen. In der Zwischenzeit werden es natürlich auch nicht weniger... Ich werde aber definitiv versuchen, meinen Teil dazu beizutragen und das Ganze zu unterstützen. Ich hoffe das Ganze wird nicht einfach so nach einer Zeit in sich zusammenfallen, wenn sich auf einmal weniger Leute dafür interessieren. ~~ DieTaube 14:52, 30. Mär. 2021 (CEST)
3. Vor x Jahren habe ich ja auch einige Abschnitte geschrieben und kann definitiv sagen, dass es einfacher ist einen solchen Abschnitt zu verfassen, wenn er alles auf einmal aufgreift. Zeitgleich sieht es mMn. etwas hübscher aus einen komplexen großen Text zu haben, als bei vielen drei kürzere Texte, die vielleicht á 4 Zeilen lang sind, zu haben. Das ist bei den meisten Pokémon leider der Fall. Da diese drei Minitexte mir auch irgendwann zu anstrengend wurden, hat mich das etwas abgeschreckt. Vielleicht können sich so auch andere mehr motivieren? - -wowoJonny 19:26, 30. Mär. 2021 (CEST)
4. Die Argumente wurden ja schon ziemlich alle genannt, da brauch ich die nicht noch wiederholen. Das Problem mit der Masse an Pokémon-Artikeln ist natürlich gegeben, aber damit muss man denke ich zurecht kommen, wenn man den Bereich nicht wie er jetzt ist bis ans Ende aller Tage gleich bleiben lassen will. Beim Punkt mit oder ohne Überschrift passen mir beide Optionen, daher enthalte ich mich da.--DeXter 12:20, 31. Mär. 2021 (CEST)
5. BlauesSerpiroyal ^Diskussion 09:21, 1. Apr. 2021 (CEST)
6. Ich kann die Begründung, die Max für seinen Vorschlag angegeben hat, gut nachvollziehen: Es gibt relativ viele unnötige Dopplungen in den Texten und die starre Aufteilung in die drei Abschnitte ist dort nicht wirklich sinnvoll. Durch die neue Struktur wären diese Probleme beseitigt, daher bin ich für die Änderung. Es stimmt zwar dass das viel Arbeit bedeutet, aber ich sehe das wie Jones, sowas sollte nach Möglichkeit einer Verbesserung der Artikel nicht um Wege stehen. Ob das ganze mit oder ohne Überschrift ist, ist mir eigentlich egal. – Vircaprae 21:38, 3. Apr. 2021 (CEST)
7. Vor allem aufgrund der Vermeidung von Dopplungen und der Unterteilung der Abschnitte nach Formen anstatt nach den bisher verwendeten Überschriften gefällt mir diese Struktur viel besser als die alte. ~ ~ Simonsees ~ 16:43, 5. Apr. 2021 (CEST)
8. Zusammengelegt sicherlich besser. (Überschriften seh ich wie Mecanno-man, das sollte man nicht strikt regeln müssen.) Nescientist (Diskussion) 19:49, 7. Apr. 2021 (CEST)
9. Ich denke auch, dass es besser ist die Abschnitte nach den einzelnen Formen aufzuteilen und nicht nach Kategorien. So gibt es weniger Wiederholungen in den Texten. -- Cliffichen 10:59, 8. Apr. 2021 (CEST)

Mit eigener Überschrift oder direkt unter Spezies

Mit eigener Überschrift

Ohne eigene Überschrift

1. Direkt unter Spezies ^^ Feblue 13:57, 30. Mär. 2021 (CEST)
2. Ich denke, es sieht so besser aus BlauesSerpiroyal ^Diskussion 14:41, 30. Mär. 2021 (CEST)
3. Eine Überschrift dazwischen halte ich für unnötig ~~ DieTaube 14:52, 30. Mär. 2021 (CEST)
4. BeyJim ^Diskussion 15:04, 30. Mär. 2021 (CEST)
5. - -wowoJonny 19:26, 30. Mär. 2021 (CEST)
6. Rüdiger ^Diskussion 23:52, 30. Mär. 2021 (CEST)
7. habe mir ein teil von beiden versionen durchgelesen und zwar stimme ich nicht ganz dafür weil die alten halt etwas ausführlicher sind aber naja sie müssen halt bearbeitet werden und wenns einfacher ist ^^' also ich würde immernoch eine überschrift zu der spezies machen und halt denn rest also attacken fähigkeiten etc [wie robbi es nannte] verankern das man es über das inhaltsverzeichnes immernoch finden kann weil kaum ein user wird sich die zeit nehmen wenn er nur schnell etwas nachgucken/suchen will denn ganzen text durch zulesen um denn teil denn er sucht zu finden ansonsten fällt mir gerade nichts weiter ein Zeynex (Diskussion) 01:06, 31. Mär. 2021 (CEST)
8. mfG Lombrero ^Dis 10:18, 31. Mär. 2021 (CEST)
9. Die Überschrift wirkt relativ komisch, weil auf den ersten Anblick die drei Sachen nichts miteinander zu tun haben. Demnach fände ich es besser, wenn diese nicht genutzt wird. --Datei:Sugimori 672.pngMecanno-man^Mäh 14:35, 31. Mär. 2021 (CEST)
10. Auch wenn ich mir enthalte bei der Frage welche Struktur genommen werden soll, würde es meiner Meinung nach besser aussehen, wenn es dort keine weitere Überschrift unter Spezies geben würde. GrollenKette951 21:13, 2. Apr. 2021 (CEST)
11. Sieht meiner Meinung nach einfach besser aus. ~ ~ Simonsees ~ 16:43, 5. Apr. 2021 (CEST)
12. Cliffichen 10:59, 8. Apr. 2021 (CEST)

Enthaltung

1. Mir ist es grundsätzlich egal. Die Änderung bringt meiner Meinung nach keine Reduzierung des Aufwands mit sich, vor allem weil alle bereits vorhandenen Abschnitte dann wieder überarbeitet werden müssen. Gleichzeitig sehe ich aber auch keinen Grund, einem Änderungswunsch anderer im Weg zu stehen, wenn ihnen die Änderung besser gefällt. Daher enthalte ich mich an dieser Stelle. -- RobbiRobb 15:19, 31. Mär. 2021 (CEST)
2. Nachdem ich mir Lasagnes Argumentation durchgelesen habe, fällt mir auf, dass sowohl die alte, also auch die neue Struktur eine grundlegende Schwäche haben: Sie sind zu strikt. Sinnvoll wäre wahrscheinlich, das setzen von Überschriften freiwilling zu machen und nur festzulegen, was irgendwo in einem der Unterabschnitte zu stehen hat, wie der obere Teil vom Spezies-Abschnitt auszusehen hat könnte man dann aber an das Pokémon anpassen. Überschriften können auch sinnvoll sein, wenn nicht gelingt eine Überleitung zu einem anderen Abschnitt zu machen, oder diese forciert klingt, in welchem Fall wohl kaum Doppelungen entstehen würden (und wenn doch wage ich zu behaupten, läge das an den Kompetenzen des Schreibers). Demnach wechsle ich jetzt mal meine Stimme zu einer Enthaltung, da beide Vorschläge mir nicht mehr wirklich zusagen. --Datei:Sugimori 672.pngMecanno-man^Mäh 20:35, 2. Apr. 2021 (CEST)
3. GrollenKette951 21:13, 2. Apr. 2021 (CEST)
4. Da ich bisher weder als User noch als Autor etwas mit diesem Bereich zu tun hatte, kann ich dazu nicht viel sagen. Auf der einen Seite gefällt mir zwar die Idee, dass die Überschrift freiwillig werden könnte um erzwungene Überleitungen etc zu vermeiden, auf der anderen Seite wäre ein wikiweiter Standard (also generell keine Überschrift) auch nicht schlecht, damit alle Artikel gleich aufgebaut sind. DeepSpace (Diskussion) 23:20, 9. Apr. 2021 (CEST)
5. Es ist schwierig, sich richtig festzulegen. Mir gefällt schon Pandas Vorschlag, aber ich war noch nie vollständig von dem Konzept mit der Lebensraum- und Verhaltens-Beschreibung überzeugt. Natürlich erscheint es mir sinnvoller nach Formen zu unterteilen, dennoch müssen sich wieder Schreiber finden, die das umsetzen, schon beim vorherigen Konzept war das schwierig. Das Isso 08/15 ^Konter 18:47, 13. Apr. 2021 (CEST)
6. Ich kann verstehen wenn gesagt wird, dass die Abschnitte sehr viel Platz am Anfang der Artikel in Anspruch nehmen, allerdings mag ich auch die alten Abschnitte und halte die dortige Strukturierung für sinnvoll. Momentan gleichen sich Vor- und Nachteile für mich aus und ich will mich für keine der beiden Varianten festlegen. -- Mooni000 ^{Pelipper-Post} 20:10, 13. Apr. 2021 (CEST)
7. Eine einfache Ja-Nein Entscheidung ist für mich in diesem fall leider nicht wirklich möglich. Beide Strukturen haben irgendwo ihre Vor- sowie Nachteile, (dies lässt mich in meinen Gedanken immer hin und her pendeln). Vielleicht hätte man nur (grob) entscheiden sollen ob oder was sich was ändern muss, oder/und dann zusammen (z.B. wie letztens die Konferenz zum Thema Wertschätzung auf Discord) ein Konzept erarbeiten sollen was somit automatisch alle Meinungen berücksichtigt?) Das nach Regionalformen getrennt wird, bin ich aber grundsätzlich dafür, da sich diese ja oft sogar erheblich voneinander unterscheiden. Aklex (Diskussion) 23:58, 13. Apr. 2021 (CEST)

Kommentare

Einmal der obligatorische Ping an alle hierfür stimmberechtigten Benutzer: AAWiki, Aklex, BeyJim, BlauesSerpiroyal, Buoysel, Cliffichen, CLina, DeepSpace, Der Sternendiamantritter, DeXter, DieTaube, Feblue, Flonc, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jass, Kenaz-Hagalaz, K0pplosio, Lasagne, Lombrero, Luca12379, Mario-WL, Matze, Maxmiran, Mecanno-man, Mooni000, Nescientist, Panflami, Pk-fan, Poffelino, PokéSpe, Pxmusic, Red Bull Salzbourg, RobbiRobb, Rolex, Rüdiger, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae und Zeynex. ~ Taisuke ^Diskussion 11:18, 30. Mär. 2021 (CEST)

Ich wollte hier noch kurz nachfragen wie die Überschriften-Abstimmung gehandhabt wird. Den Abschnitt-Überschriften-Ebenen nach würde ich urteilen, dass das eine separate Unter-Abstimmung ist. Jetzt haben bloß ein paar Leute nur in einer und ein paar in beiden abgestimmt, weshalb ich am Anfang etwas verwirrt war.--DeXter 12:20, 31. Mär. 2021 (CEST)

Grundsätzlich geht es mir um eine Entscheidung bezüglich der Zusammenlegung der drei genannten Abschnitte. Da die Struktur einen längeren Findungsprozess hinter sich hat, an der sich viele verschiedene Benutzer beteiligt haben. Daher war mir eine Abstimmung wichtig. :)

Ob das Ganze dann eine eigene Überschrift erhält, empfand ich als eine gute Gelegenheit, diesbezüglich auch gleich Meinungen zu sammeln. Wer da keine Stimme abgibt, aber trotzdem für eine Zusammenlegung stimmt und dort nichts explizit dazu schreibt, wird von mir als neutral gewertet. Das betrifft übrigens bislang nur dich. ^_^

Hat hingegen jemand nur bei der Überschriftsfrage abgestimmt ergibt sich ja gar keine Frage, weil dieser automatisch für eine Zusammenlegung ist. Wenn also an einer der beiden Stelle eine Stimme fehlen sollte, ist das gar kein Problem. ~ Taisuke ^Diskussion 14:23, 31. Mär. 2021 (CEST)

Dieser Umkehrschluss scheint meiner Sicht nach trügerisch, da man auch den Gedankengang „Is mir eigentlich egal, aber wenn dann mit der Überschrift“ oder so ähnlich haben könnte. --Datei:Sugimori 672.pngMecanno-man^Mäh 14:35, 31. Mär. 2021 (CEST)

Vielleicht sollte man vor der eigentlichen Abstimmung eine weitere Abstimmung machen, ob die Abstimmungsoptionen wasserfest und zu 100 Prozent unmissverständlich formuliert sind. Ne, mal im Ernst. Ich glaube nicht, dass mein Gedankengang trügerisch ist. Sollte ich mich irren, dürfen BlauesSerpiroyal, BeyJim, Rüdiger oder Lombrero gerne nochmals hier nachlesen, wie ich die Abschnitte verstehe und ggf. ihre Stimme korrigieren. ~ Taisuke ^Diskussion 14:42, 31. Mär. 2021 (CEST)

Nach meiner Änderung bin ich mir jetzt nicht mehr im Klaren, wie meine Stimme bei dieser Abstimmung gezählt wird. --Datei:Sugimori 672.pngMecanno-man^Mäh 20:35, 2. Apr. 2021 (CEST)

Übrigens, @Lasagne: Die Idee mit den Statuswerten meine ich war etwas, was man bewusst vermeiden soll, denn Statuswerte sind etwas spiele-spezifisches, während der Spezies-Abschnitt medienübergreifend sein soll. --Datei:Sugimori 672.pngMecanno-man^Mäh 20:35, 2. Apr. 2021 (CEST)

Ohne mich zu sehr an der Diskussion zu beteiligen, möchte ich doch zumindestens mal meine Meinung hierlassen: Gründe wie "interessieren mich nicht" oder "wir haben andere Themen" sollten niemals ein Grund sein gegen Veränderungen zu sein. Möglicherweise wird etwas beschlossen, was erst in Jahren komplett umgesetzt wird, aber warum sollte man in der Zwischenzeit mit einem ungenügenden Konzept arbeiten? Vllt findet sich ja morgen einer, der sich nur darauf konzentriert, diese Abschnitte zu schreiben? Falls das Thema einen nicht interessiert, gibt es dafür extra die Möglichkeit der "Enthaltung".
Zum Thema: Ich habe mich bei den bisherigen Abschnitten häufig schwer getan Unterschiede zu entdecken. Ja, der Fokus ist teils ein anderer, schlussendlich basieren die Abschnitte aber doch immer auf denselben Informationen und sind dementsprechend ähnlich. Ebenfalls wird aktuell immer zwischen Formen hin und her gesprungen (gerade bei so extrem Beispielen wie Mauzi), obwohl diese teils doch recht unterschiedlich sind. Das "Problem" zeigt sich mMn auch schon dadurch, dass PdWs im Grunde komprimierte Zusammenfassungen aller drei Abschnitte sind - wenn also ein PdW es schafft die Informationen gemeinsam darzustellen, warum dann also nicht die Artikel? Und gerade die in Max' Beispiel vorgenommene Trennung der Formen gefällt mir sehr gut.
Und ja, bei einer Änderung müssten auch die bisherigen Artikel überarbeitet werden. Aber man könnte ja priorisieren: Alle bisher noch gar nicht angepackten Artikel würden nach der neuen Struktur überarbeitet, alle bereits überarbeiteten bleiben vorerst so. Sobald dann (irgendwann) alle Artikel zumindest einmal angepackt wurden, muss man "nur" die alten überarbeiten. Würde man erstmal alle nach der alten Struktur überarbeiten und dann das Thema nochmal angehen, müssten wirklich alle nochmal überarbeitet werden. Jones ^Albtraum? 02:35, 3. Apr. 2021 (CEST)

Ich darf ja nicht abstimmen, aber generell hat mich bei der ganzen Sache schon immer gestört, dass insbesondere der Aussehen-Abschnitt meistens eher ein bisschen.... ja, ich weiß auch nicht, komisch(?) ist. Beispiel Nidorino: "Es besitzt eine Schnauze, an deren Spitze sich die Nasenlöcher befinden. (...) Schließlich wächst aus seiner Stirn ein langes, spitzes Horn." Da stehen halt meistens Infos drin, die ich auch sehe, wenn ich mir das Bildchen rechts daneben anschaue. Von dieser Warte aus, macht es total Sinn, diese Abschnitte zusammenzufassen, weil dann so "random" Fakten in einen vernünftigen Zusammenhang gebracht werden. Insgesamt, ich glaube aber, das hatte ich schon vor ein paar Jahren mal erwähnt, würde ich den Abschnitt auch weiter unten im Artikel platzieren, weil man meistens doch eher andere Infos sucht, wenn man einen Pokémon-Artikel öffnet (Fundorte, Attacken, wie entwickel ich das Ding, etc.). Aktuell muss man da doch bei manchen Pokémon etwas viel scrollen. Aber das ist ein anderes Thema, aber nur so nochmal als Anreiz. Fröhliches Edieren und bis in 6 Monaten. --Vorsicht, heiß! Killuu 15:56, 13. Apr. 2021 (CET)

Umsetzung

Danke für die rege Teilnahme an der Abstimmung und auch für die vielen verschiedenen Argumentationen, die im Laufe der Abstimmung für und gegen die geplante Änderung mitgeteilt wurden. Ich denke, dass wir mit der Zusammenlegung der Abschnitte eine gute Entscheidung getroffen haben und werde mich zeitnah um eine Aktualisierung der To-do-Listen sowie Musterstruktur kümmern, damit der Stand dieser Änderung auch nachvollziehbar bleibt und Max eifrig mit dem Umschreiben beginnen kann. Sollte euch etwas Grundlegendes bei der Umsetzung auffallen, sprecht es gerne auf der Diskussionsseite des Pokédex-Projekts an. Nur weil wir etwas per Abstimmung beschlossen haben, sind wir nicht taub für weiteres Feedback dazu. :)

Darüber hinaus versuche ich in den nächsten Tagen hier noch auf die ein oder andere Stimme näher einzugehen. ~ Taisuke ^Diskussion 07:39, 14. Apr. 2021 (CEST)

VB-Wahlen: Die erste Wahlrunde

Hallo zusammen! Auf Discord ist nochmal ein kleiner Impuls zu den VB-Wahlen entstanden. Es geht um die erste Runde der VB-Wahlen.

Als das System eingeführt wurde, wurde sich gegen eine Stimmpflicht in der ersten Runde entschieden, während die zweite Wahlrunde zeitlich befristet ist. Somit wird zwar versichert, dass nach dem Ende der ersten Wahlrunde nach einer Woche, in der die zweite Wahlrunde läuft, ein Ergebnis mit allen dazugehörigen Stimmen vorliegen wird, aber nicht dasselbe für die erste Wahlrunde gilt. Das hat den Effekt, dass sich die vorgeschlagenen Kandidaten ungewiss darüber sind, was aus ihrer Abstimmung wird. Diese Unsicherheit gehört beseitigt.

Die einfachste Idee liegt darin, auch die erste Wahlrunde zeitlich zu begrenzen, sodass nach dem Ablauf der Zeit (Vorschlag: eine Woche) die Stimmen der ersten Wahlrunde ausgezählt werden. Somit bestünde keine Stimmpflicht. Fallen die Stimmen positiv aus, wird die zweite Wahlrunde initiiert. Auch hier sollte gelten, dass die zeitliche Begrenzung übersprungen werden kann, sofern eine Mehrheit von 2/3 unter den Stimmberechtigten dieser Wahlrunde vorliegt.

Wie findet ihr die Idee? Ich freue mich auf das Feedback dazu. --Feblue 20:43, 23. Apr. 2021 (CEST)

Finde die Idee nicht gut, eine Zeitliche Befristung untergräbt ein Mindestmaß der Entscheidungsnotwendigkeit wenn nur ggf. 2 Stimmen aus der ersten Woche gewertet würden. Die Unbefristung ist ein guter Kompromiss zur Stimmpflicht. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 21:01, 23. Apr. 2021 (CEST)

Ich schließe mich bezüglich der Zeit-Beschränkung Ryu hier an. Gerade bei Redakteurswahlen, bei der nur die Administratoren abstimmmen, gab es bisher üblicherweise keine Probleme, weshalb ich auch bei den VB-Wahlen hier keinen Grund einer zeitlichen Beschränkung sehe.

Wo ich jetzt eher son bisschen das Problem sehe (zumindest in Max und meinem Fall) ist das Warten auf "Formalitäten" - 5/6 benötigten Stimmen hatten wir innerhalb eines Tages, die letzte Stimme hat dann drei Tage gedauert. Das die Wahlrunde noch scheitert war somit eigentlich nahezu ausgeschlossen (da alle Stimmen bisher pro waren). Vielleicht wäre daher eher eine Anpassung denkbar, dass die Administration die zweite Wahlrunde auch bereits vorzeitig starten kann, sofern das Ergebnis sich abzeichnet. Damit hätte im jetzigen Fall beispielsweise die zweite Runde bereits früher gestartet werden können, umstrittene Wahlen (auch wenn wir davon ehrlicherweise bisher wenige hatten) würden hingegen weiterlaufen, ebenso wie Ryus Beispiel.

Eine andere Idee wäre ein "Inaktivitäts"passus: Wenn eine Zeit X (zB eine Woche) keine Stimme abgegeben wurde, werden die fehlenden Leute nochmal gepingt und sollte in einer Zeit Y (zB zwei Tage) keine weitere Stimme abgegeben wird (oder zumindest der Wille einer Stimmabgabe geäußert wird, wie auch immer man das definiert), wird die Wahlrunde beendet und ausgewertet.

Insgesamt gefällt mir die erste Variante (Administration kann entscheiden) am ehesten, da sie einfach diesen Ermessensspielraum lässt um (hart gesagt) unnötige Formalitäten auszuhebeln, ohne gleich den grundsätzlichen Gedanken hinter der ersten Runde zu boykottieren (sonst könnte man auch einfach eine Gesamtrunde über zwei Wochen abhalten). Jones ^Albtraum? 21:29, 23. Apr. 2021 (CEST)

Persönlich gesagt war ich gegen eine Wahl bei Max und Jones da ich mich dort an einen Passus auf der Veteranenseite orientierte die SB- und VB-Recht durch Admins vorsah. Hier gab es eine Überstimmung und es wurde sich dafür ausgesprochen jeden User durch die Wahl zu schicken unabhängig möglichen Durchwinkens aufgrund seiner Erfahrung usw.... Die Überbürokratisierung ist gewollt und somit lässt sich da nichts beschleunigen. Gegen einen Reminder nach 14 Tagen habe ich keine Einwände. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 21:40, 23. Apr. 2021 (CEST)

Das was Ryu da anstößt, ist der knackende Punkt: Die Wahlen wurden ja genau deshalb erschaffen, um VB-Ernennungen transparenter zu machen. Wenn da jetzt auf einmal wieder eine Rechtestufe irgendwas verändern darf und einfach abgeschätzt wird, wie der Rest der Abstimmung verlaufen wird, dann trifft das den Sinn der Wahlen nicht mehr. In der Begrenzung der Zeit sehe ich kein Problem, denn das aktuelle Bild zeigt deutlich, dass die benötigte Stimmanzahl bereits nach 13 Stunden fast erreicht war. Meine Wahl ging nach nur vier Tagen in die zweite Runde, bei Virca und Mooni waren es sechs - Ich habe da vollstes Vertrauen in die Reds und Admins, dass die erste Runde nicht mit einer Stimme beendet wird. --Feblue 21:58, 23. Apr. 2021 (CEST)

Eine Transparenz schließt nicht "Sonderfälle" aus. Ich weiß echt nicht woher dieser Irrglaube kommt. Heißt man hätte auf Admin- und oder Redebene das ganze Besprechen können und mittels einem Eintrag auf der Disku von Max oder Jones schreiben können das Aufgrund der Leistung XY eine WIEDER-VB-Vergabe (sowas ist mMn nur bei Veteranen anwendbar) beschlossen wurde, Punkt. Es wäre mMn Ausreichend transparent und nicht so Überbürokratisiert. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:34, 23. Apr. 2021 (CEST)

Die aktuelle Lösung ist bekanntlich eine Kompromisslösung daraus, dass eine Stimmpflicht für Redakteure und Admins gewünscht wurde, wir allerdings nicht wirklich irgendwelche verhältnismässige Sanktionsmöglichkeiten für Reds und Admins haben, die in einer bestimmten Zeit nicht abstimmen. Man könnte diese Stimmpflicht jetzt auch stumpf durch eine Zeitfrist ersetzen, allerdings sehe ich keinen wirklichen Bedarf dafür, zumindest nicht aus diesen Wahlen heraus. Es ging mit dem aktuellen System drei Tage, eine Frist wär garantiert nicht unter sieben Tagen. Wenn's wirklich nicht vorangeht ist bei denen, die noch abstimmen sollen, sicherlich sinnvoll nachzufragen, warum sie dies nicht gemacht haben. Drei Tage ohne Stimme sind aber, denke ich, vertretbar.

Eine andere Frage, die bei mir aufgekommen ist (welche schlussendlich dazu führte, dass ich die Wahlen verpasst habe) ist, ob Reds und Admins Enthaltung stimmen dürfen. Bei den Redakteurswahlen ist es den Admins nicht erlaubt, sich zu enthalten (als Ergebnis auf eine Wahl von Cosi, bei der dann die Frage war, ob 2/3 aller Admins oder 2/3 aller sich nicht enthaltenden Admins zu zählen sei). Die VB-Wahlen basieren auf den Red-Wahlen, jedoch steht dieser Satz spezifisch nicht in den Regeln zu den VB-Wahlen. Ich kann mich nicht erinnern, dass jemals über diesen Punkt diskutiert wurde, und falls tatsächlich gewünscht ist, dass Admins und Reds sich enthalten dürfen, dann müsste man auch sicherstellen, dass eine Enthaltung nicht effektiv ein Contra ist. --Datei:Sugimori 672.pngMecanno-man^Mäh 15:00, 24. Apr. 2021 (CEST)

Der eigentliche Vorschlag, die erste Wahlrunde zeitlich zu begrenzen, erscheint mir sinnig und würde ich mittragen.

Dennoch kann ich nicht einordnen, woher dieser zeitliche Druck auf einmal kommt. Die ersten Wahlrunden zu Jones und Max liefen knapp drei Tage (20.–23. April) und es wird auf Discord eindrücklich und öffentlich zur Eile gemahnt. Woher kommt dieser Druck? Es gab doch bislang keine negativen Erfahrungen der zeitlich nicht begrenzten Wahlrunde (siehe vorherige Wahlen). Gemäß dieses Aufschreis müsste die erste Wahlrunde doch zeitlich auf höchstens vier Tage gesetzt werden, um diesen Aufforderungen zu diesem Zeitpunkt gerecht zu werden. Da fehlt mir anscheinend leider das Verständnis, um das in dieser Situation nachvollziehen zu können. Wie bereits geschrieben, hätte eine kurze Erinnerung der Benutzer, die noch nicht abgestimmt hatten, völlig ausgereicht. Nun gut, ich möchte da jetzt eigentlich auch keine weitere Diskussion mit lostreten, sondern nur meine Verwirrung über die Entstehung kundtun. Aber wie bereits zu Anfang gesagt: Für mich wäre eine zeitliche Begrenzung total fein, um einer möglichen Demotivation vorzubeugen, dass eine erste Wahlrunde in der Theorie ewig andauern kann, auch wenn dieser Fall noch nie auch nur ansatzweise eingetreten ist. ~ Taisuke ^Diskussion 15:10, 24. Apr. 2021 (CEST)

Dies Schnell schnell ist in Meinen Augen einfach zu erklären da es hier nicht um die Ernennung neuer VBs ging sondern um die Wiederernennung alter. Die Wahl ist wie gesagt mehr oder weniger proforma und keine gefühlte Wahl. Dies zeigt sich auch in der Art und Weise durch vorrangiges Signieren. Der Großteil kennt die lange und gute Arbeit von Jones oder Max, sie sind aus persönlichen Gründen zurück getreten und nicht weil sie Mist gemacht haben. Beide kamen wieder und haben schnell gezeigt das sie nichts verlernt haben und einfach nur zügig weiter machen wollen mit Sachen wofür sie mind. VB benötigen. Ich denke wenn es die nächsten 1-2 Jahre nur neue Ernennungen gegeben hätte dann wäre dieser Punkt nie in der Art aufgekommen. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:24, 24. Apr. 2021 (CEST)

Ich stimme zwecks Thema Eile Tai zu. Meiner Ansicht nach gingen alle Wahlen bisher recht flott durch und da noch weiter nachzudrücken war zumindest bisher mMn nicht nötig.

Zu dem 'gewollten Überbürokratisieren' von Ryu: Mir geht es hauptsächlich darum nicht im verschlossenen internen Raum für manche Leute eine Extrawurst zu entscheiden. Bei einer einfachen Wahl, die innerhalb von ein paar Tagen durch ist, hab ich kein Problem mit. So wurde das auch beim Entwerfen des Wahlkonzepts entschieden. Wenn der Umgang mit Vet-SBs geändert werden soll, kann man das aber doch mal allgemein diskutieren. Diesmal aber bitte ohne Aussetzen der Wahlen ;) --DeXter 17:38, 24. Apr. 2021 (CEST)

CSS-Klassen für das responsive Design

Wie bekannt sein sollte, wird derzeit an der Umsetzung eines responsiven Designs des Wikis gearbeitet. Es hat sich allerdings bereits früh herausgestellt, dass einige CSS-Regeln immer wieder auftreten, weshalb Stimmen laut geworden sind, die eine global einheitliche Umsetzung fordern und die ich unterstützen möchte. Bislang sehe ich hauptsächlich einen Anwendungsfall, nämlich das Umspringen von Infoboxen ab einer Device-Breite von 480px auf die volle Seitenbreite. Die Idee wäre es hier jetzt also, eine CSS-Klasse bereitzustellen, die das global übernimmt und so Redundanzen in den einzelnen Style-Sheets reduziert. Der große Vorteil wäre, dass man einheitliches Verhalten gewährleisten kann und bei Bedarf mit dem Wachsen der Technik in Zukunft auch einfacher Anpassungen an der Infrastruktur vornehmen kann, ohne gleich wieder hunderte Seiten zu bearbeiten. Da ein Verzicht auf sowas garantiert über kurz oder lang zu Chaos führen wird, möchte ich die Idee selbst auch gar nicht groß zur Diskussion stellen, sondern einfach ankündigen, dass es irgendwas in diese Richtung geben wird. Wenn ihr doch irgendwelche Gründe habt, die dagegen sprechen sollten, nur zu, vielleicht übersehe ich etwas, aber insgesamt erscheint mir, dass dies die sinnvollste Lösung ist. Viel wichtiger wäre es mir hier, wenn mir folgende Fragen von einem größeren Kreis der Userschaft beantwortet würden: Wo seht ihr Bedarf für solche Klassen abseits von Infoboxen? Ist euch etwas aufgefallen, wo es sinnvoll ist, sowas global zu deklarieren, damit man es überall nutzen kann? Und außerdem: Was würdet ihr vorschlagen, wo man sowas unterbringen sollte? Gibt es dort wohl häufiger Änderungsbedarf, ist das etwas, was man in einer Vorlage unterbringen sollte und dann über das Common.css laden sollte? Oder einfach nur eine Vorlage, die bei Bedarf wie andere Style-Sheets auch geladen werden sollten? Oder wird das relativ statisch sein mit wenigen Änderungen im Laufe der Jahre und insgesamt zu große Gefahr mit sich bringen, dass sich eine Unterbringung außerhalb des Common.css nicht lohnt? Ich bin da für alle drei Ideen offen, halte allerdings eine der beiden Möglichkeiten, die das Common.css verwenden, für die sinnvollsten. Wie seht ihr das? -- RobbiRobb 22:36, 2. Jun. 2021 (CEST)

Wüsste nicht, warum man das irgendwo abgesehen vom common.css haben sollte, bin aber definitiv auch dafür. Nachdem ich mir das mal eben aber angesehen habe wie eine Infobox mit Fliesstext daneben aussieht denke ich das 480 ein zu niedriger Breakpoint für Infoboxen ist und hätte den gerne höher. Klassen lassen sich vielleicht auch für andere häufig genutzte Vorlagentypen erstellen, z. B. Navboxen und PrevNexts, aber ob man da was reinnehmen kann bin ich mir unsicher. --Datei:Sugimori 672.pngMecanno-man^Mäh 00:08, 3. Jun. 2021 (CEST)

Globale Klassen haben mein Pro. Abgesehen von dem Umspringen bei Infoboxen, könnte ich mir das auch sinnvoll für Klassen vorstellen, die das jew. Element unter einer bestimmten Breite ausblenden. Es ist glaube ich recht weit verbreitet, dass Tabellen bei uns 'Komfort-Angaben' haben. D. h. Daten, die man auch über nen Klick auf einen Link kriegen könnte, aber so auf einen Blick direkt hat (z. B. bei Learnset-Tabellen die Stärke, Genauigkeit, AP, Typ und Schadensklasse der jew. Attacke). An einigen Stellen wird man für eine Verringerung der Breite denke ich nicht drum rum kommen manche dieser Angaben zum Teil auszublenden. Z. B. die Learnset-Tabellen in Pokémon-Artikeln können bei manchen Learnarten mit allen Spalten nicht die 320px Breite unterstützen, da sie selbst breiter sind. --DeXter 00:32, 3. Jun. 2021 (CEST)

Ich wäre da auch für common.css, einfach der Handhabbarkeit halber. Ansonsten fällt mir bisher nicht viel ein, bis auf eben sowas, was DeXter nannte. IaS, Synchronsprecher, Learnsettabellen, das sind alles Vorlagen, die bisher unabhängig voneinander ihre Breiten regeln. Wenn ich mich nicht irre, dann könnte man sogar so weit gehen, dass man einfach allen Vorlagen bei 480px und weniger volle Breite gibt. Inhaltsausblendung wird es dann wahrscheinlich auch bei ein paar Vorlagen geben müssen. -- Feblue 23:39, 3. Jun. 2021 (CEST)

Andere Vorlagen-Typen halte ich für problematisch, PrevNexts eine allgemeine Struktur zu geben halte ich noch für Realisierbar, Navboxen sind aber alle individuell gestaltet, ihre interne Struktur hängt dabei vom Inhalt ab und lässt sich nicht verallgemeinern. Eine Klasse für alles halte ich da also für nicht Realisierbar. Für einen höheren Breakpoint für Infoboxen bin ich offen, hätte da aber gerne konkrete Vorschläge. Klassen zum Ausblenden von Inhalten kann ich mir als praktisch vorstellen, ist hier aber die Frage, ob man da eine feste Mengen von Klassen für bestimmte Breiten festlegen möchte, oder ob man sowas nicht lieber flexibel hält und den Vorlagen-Schreibern überlässt, ob sie das für irgendwelche Inhalte spezifisch festlegen. Denn ich will da keine riesige Menge Klassen für alle paar Pixel haben, mit zu wenigen läuft man aber Gefahr, dass der Inhalt einfach mal nicht passen kann und man vielleicht zwanzig Pixel mehr bräuchte. Bezüglich Feblues Vorschlag, einfach allgemein alles auf volle Breite zu ziehen, möchte ich mich allerdings stark dagegen aussprechen, das ganze bietet entweder keinen Vorteil (weil die meisten Vorlagen entweder bereits vorher auf die volle Breite gehen oder eben ihr eigenes Ding machen und dann auf die Volle Breite gehen) oder im schlimmsten Fall sogar einen Nachteil (etwa bei Vorlagen, die flexibelste Breiten unterstützen, und dann dadurch negative Seiteneffekte erfahren könnten). Klassen für sowas halte ich für sinnvoll, einfach allgemein alles betreffend aber definitiv nicht. Mal davon abgesehen, dass sowas in der Realisierung unnötig kompliziert wäre. -- RobbiRobb 00:30, 4. Jun. 2021 (CEST)

Ich würde mich statt Nutzung der Common.css für die Nutzung eines gemeinsamen TemplateStyles für alle Infoboxen aussprechen, da nicht auf allen Seiten tatsächlich Infoboxen genutzt werden. Da der Anteil aber doch relativ hoch ist, sind die Common.css gewiss auch eine gangbare Alternative. Man könnte allgemein aber noch überlegen, ein bisschen von dort in TemplateStyles auszulagern, das bietet sich insbesondere für die Hauptseite an.

Ansonsten könnten die Typ-Schwächen für Pokémon mit mehreren Formen noch einen Breakpoint vertragen. (Zumindest in Timeless brechen die Attackenboxen bereits um.)

Gibt es irgendwo eine kanonische Vorschau des neuen Designs? -- Skelabra2509 (Diskussion | Beiträge) 14:01, 10. Aug. 2021 (CEST)

Ich würde vllt noch ne allgemeine Tabellen Klasse haben, die ab X Pixel (grad nicht mehr sicher ab wann wir festgelegt haben) auf 100% Breite umschalten. Sicherlich wird nicht jede Tabelle die nutzen, es gibt sicher einige die vorher umstellen müssen, aber für viele Tabellen würde das ausreichen (Oder man hängst direkt an unsere aktuelle Tabellenklasse und überarbeitet diese direkt mit?). Ansonsten fällt mir auf Anhieb auch nicht viel mehr ein. Mehr ist auch beim Spiele-Projekt unterm Strich nicht geteilt zwischen den einzelnen Vorlangen.

Was die Verortung angeht: Für alles spezielle bin ich glaube ich auch eher dafür das in die TemplateStyles auszulagern. Für die Sachen, die wirklich allgemein sind (eben zB ne allgemeine Tabellenklasse) würde ich fast schon eher vorschlagen das unter dem Stylespezifischen CSS abzulegen (zB pokewiki.css wenn der Skin pokewiki heißt). Auch wenn wir gesagt haben die anderen Skins deaktivieren zu wollen, erleichtert das vermutlich auch zukünftige Tests neuer Skins (sollte es dieses Thema nochmal geben). Technisch macht es unterm Strich vermutlich erstmal keinen Unterschied. Jones ^Albtraum? 22:24, 3. Nov. 2021 (CET)

Styles für einen spezifischen Skin kann ich mir als sinnvoll vorstellen, dafür aber eigene TemplateStyles anzulegen halte ich für nicht sonderlich sinnvoll, da wird man nur wahnsinnig dabei die einzubinden und vor allem weniger erfahrene Benutzer werden Schwierigkeiten haben, zurückzuverfolgen, woher das ganze kommt und welches Stylesheet sie einbinden müssen. Außerhalb des MW-NS halte ich das ganze daher für unpraktikabel.

Bei allgemeinen Styles für Tabellen bin ich auch eher skeptisch, unsere Tabellen reichen von kleinen Listen zu ewig breite Tabellen über die ganze Seitenbreite. Bin mir daher sicher, dass wir dafür keine einheitliche Lösung finden werden und erst recht keinen einheitlichen Breakpoint. Denke daher nicht, dass das zielführend ist. -- RobbiRobb 00:25, 4. Nov. 2021 (CET)

Dem ersten Punkt stimme ich vollkommen zu. Bezüglich des zweiten Punktes habe ich keine Übersicht (mehr), aber viele Tabellen lassen sich doch bestimmten Typen zuordnen, bspw. Infoboxen. Wenn auch nicht alle, könnte man doch viele Tabellen auf diese Weise über einen Kamm scheren. Man sollte auf jeden Fall mal schauen, ob irgendwo noch max-width und width unabhängig von der Breite unter 100 % gesetzt werden. Das dürfte nämlich in keinem Fall sinnvoll sein. -- Skelabra2509 (Diskussion | Beiträge) 23:27, 10. Nov. 2021 (CET)

Sammelartikel für Anspielungen in anderen Franchises

Hallo! Ich habe mich schon ein paar Mal mit verschiedenen Anspielungen von anderen Franchsies, wie Filme, Videospiele oder Serien, beschäftigt, welche auf Pokémon anspielen. Klar kann man davon vieles in die Trivia des jeweiligen Inhalts stecken (siehe Missingno.#Trivia), jedoch lassen sich viele dieser Anspielungen nicht wirklich in eine Trivia einbauen, wenn sie Pokémon allgemein ansprechen. So beispielsweise Zitate aus Film und Fernsehen, die Pokémon als Kulturphänomen erwähnen. Mein Vorschlag: Ein Sammelartikel für all diese Anspielungen. Hier möchte ich Zitate oder Spielinhaltsanspielungen gerne zusammenfassen. Hier möchte ich jedoch einwas ansprechen: Vulgäre Beispiele. Ein Beispiel, was mir da schon lange im Kopf rumschwirrt, ist ein Zitat aus der Serie American Gods, in welcher einer der Antagonisten die Taten seines Gegenspielers als das "Sammeln von verf**** Pokémon" bezeichnet. So etwas ist natürlich schwierig einzubringen, wenn es ein dann doch schon an Jüngere gerichtetes Wiki ist, jedoch finde ich es andererseits auch wieder falsch so etwas zu ignorieren, da wir ja dennoch eine enzyklopädische Aufgabe haben. Wie steht ihr dazu? - -wowoJonny 02:39, 7. Jun. 2021 (CEST)

Pro zur generellen Idee; @Buoysels Entscheid für die frage mit den vulgären Beispielen. Wenn man die aber nicht hinzufügt denke ich ist es fast besser das ganze zu lassen, weil wenn du's nicht machst wirds wer anderes machen und dann haben wir auf ewig ne Diskussion was da reingehört und was nicht. Ich denke aber das es sinnvoll wäre das ganze auf tatsächliche Erwähnungen von Pokémon zu beschränken und nicht auch Sachen reinzunehmen, die nur daran angelehnt sind (auch in Fällen wo's offensichtlich ist, wie in anohana z. B.); ansonsten wird das auch ein riesiges Fass was spezifisch Pokémon ist und was nur iwie das Mon-Konzept oder n allgemeines AR-Spiel was Ähnlichkeiten zu Pokémon GO etc. hat. Ausserdem sollte man spezifisch Fankreationen rausschmeissen, weils davon eh zu viele gibt - also kein Pixelmon oder Ähnliches. --Datei:Sugimori 672.pngMecanno-man^Mäh 03:25, 7. Jun. 2021 (CEST)

Wie weit würde deine Definition denn gehen? Wäre sowas wie die "Chinpokomon"-Folge aus South Park ([1]) jetzt also schon in dem Sinne eine direkte Anspielung oder doch nur die Kopie des Mon-Konzepts für jenes Folgenspecial? - -wowoJonny 09:23, 7. Jun. 2021 (CEST)

Den Vorschlag finde ich toll, hat also mein Pro. Vulgäre Beispiele könnte man ja z. B. gesammelt hinter nem Spoiler o. ä. verstecken und im Spoiler-Text klarmachen, was die Leute erwartet. Das würde für mich dann eigtl. reichen. Zwecks Definition was man rein nimmt, hab ich nen zu geringen Überblick was es alles gibt, ich will bloß anmerken, dass man nicht den alles oder gar nichts Ansatz verfolgen sollte. Nichts muss perfekt sein, erst recht nicht von Anfang an. Ich fänd ne Sammlung schön, auch wenn sie unvollständig sein mag ^^ --DeXter 23:01, 8. Jun. 2021 (CEST)

Tolle Idee. Und ich stimme DeXters Vorschlag zu, sowas könnte man ganz gut hinter einem Spoiler verstecken. Jedoch sollten derbe Begriffe selbst da dann besser mit Sternchen versehen werden, um eventuelle Kinderblocker nicht zu triggern. ~ Buoysel 15:17, 9. Jun. 2021 (CEST)

Ich gebe hier dann auch einfach mal schnell meinen Senf dazu zum vorschlag an sich: definitiv ne gute Idee. Was ich aber vllt. noch eine möglichkeit wäre, was man hinzufügen könnte, wäre das genau umgekehrte, also Anspielungen an andere Franchises in Pokémon spiele, da es da ja auch mit Sicherheit zur genüge welche gibt. Bennett ^Sturzflug 16:39, 9. Jun. 2021 (CEST)

Finde ich eine großartige Idee und bin unbedingt dafür. Wir haben das im letzten Jahr ja auch für die Pokémonspezies andiskutiert, vielleicht lässt sich bei der Abwägung, was enthalten sein sollte und was nicht, ja daran anknüpfen, bevor von 0 ausgegangen werden muss? Maxmiran 17:38, 9. Jun. 2021 (CEST)

@SwowoJonny: Chinpokomon wäre genau derselbe Fall wie mein anohana-Beispiel - offensichtlich aber nicht namentlich erwähnt; würd ich also eher zu weglassen tendieren. Hatte da nur leider kein Beispiel bei was bekannter ist. --Datei:Sugimori 672.pngMecanno-man^Mäh 03:01, 10. Jun. 2021 (CEST)

Artikel und ihre Kategorien

Ein Thema, welches augenscheinlich bereits seit ca 2012 eine Stolperfalle darstellt, sind Artikel mit einer zugehören Kategorie, die aber unterschiedlich heißen. Konkrete Beispiele hierzu sind der Artikel Gary Eich und die :Kategorie:Gary oder auch Professor Samuel Eich und :Kategorie:Professor Eich, ohne jetzt konkret geprüft zu haben, bin ich mir aber sicher, dass es kein reines Charakter-Problem ist (bspw das Spiele-Projekt legt üblicherweise auch pro Spiele-Artikel eine Kategorie an, da bin ich mir auch fast sicher, dass die nicht alle Verschiebungen mitgemacht haben). Um hier Verwirrungen zu vermeiden (gerade bei Datei-Uploads ohne Vorschau) wäre mein Vorschlag projektübergreifend festzulegen, dass solche Kategorien idealerweise denselben Namen wie der zugehörige Artikel bekommen (Ausnahmen sind bspw Artikelzusätze wie (Charakter), welche natürlich nicht in die Kategorie übernommen werden sollten oder begründete Ausnahmefälle). Gibt es hier Gründe, die dagegen sprechen würden? Ansonsten könnten zumindest die beiden Fälle wohl gebottet werden und andere könnte man vermutlich auch via Bot ermitteln. Jones ^Albtraum? 17:28, 1. Jul. 2021 (CEST) PS: Auf Discord gab es bereits eine ganz kurze Minimalstumfrage, welche unter dem Link gefunden werden kann.

Ich finde es ist eher die mangelnde Konsistenz zwischen Kategorien die sich eher als Stolperfalle darstellt. Ich lade da so die Titelseiten der Asiatisch-Englischen Auflage von Dengeki Pikachu hoch und alle anderen Titelseiten mit einem gewissen Ash Ketchum drauf sind mit [[:Kategorie:Ash Ketchum]] getagt, also erwarte ich, natürlich, dass andere Figuren mit bekannten Nachnamen genauso getagt sind, wie z.B. Gary Eich zu [[:Kategorie:Gary Eich]], richtig? Falsch, für Gary isses es "nur" [[:Kategorie:Gary]]. An dieser Stelle versteht sich zwar das beide Verfahrensweisen – nur Rufname oder vollständiger Name (falls bekannt) – eine gewisse Sinnigkeit haben, nur müsste man sich zwischen eine von beiden entscheiden und diese dann konsequent durchziehen. Persönlich würde ich auf nur Rufnamen tippen. Figuren wie Ash, Gary, Todd, Platinum, Y, Soro und andere haben zwar einen bekannten Nachnamen aber damit sind diese eher die Ausnahme als die Regel, wenn verglichen mit 95% aller anderen menschlichen Figuren im Pokémon-Universum. Und deren Rufnahmen sind generell unikal genug (keine andere Figur heißt Todd), das man den Nachnamen in der Kategorie streng-genommen nicht braucht. --DaneeBound ^{Diskussion Gäste} 22:19, 1. Jul. 2021 (CEST)

Denke auch das Konsistenz hier das wichtigste ist; mir als Charakter-Projektleiter ist grundsätzlich egal in welche Richtung wir hier schieben, so lange es nicht zu Verwirrung kommt was mit der Kategorie gemeint ist. Kategorie:Blau Eich zu Kategorie:Blau zu schieben fände ich z. B. nicht gut, da dann nicht mehr klar ist wer oder was gemeint ist. Bei Fällen wo das klar ist hab ich jedoch grundsätzlich auch nix dagegen Rufnamen zu verwenden (also z. B. Kategorie:N) - solange das ganze irgendwie konsistent ist, was es aktuell nicht zu sein scheint. --Datei:Sugimori 672.pngMecanno-man^Mäh 02:57, 2. Jul. 2021 (CEST)

Generell die Rufnamen zu nehmen ist keine schlechte Idee, allerdings befürchte ich, dass sich dann die Kategorien (wie schon in Mecs Beispiel) einfach augenscheinlich nicht schnell unterscheiden lassen und vielleicht sogar für Verwirrung sorgen. Daher wäre ich generell für die vollen Namen. Wir verwenden sie ja schließlich auch in den Artikelnamen. Bevor dann ein neuer Charakter eingefügt wird, der per Rufname genau gleich heißt, wir die erste Kategorie dann vom Rufnamen wegschieben müssen und damit die Konsistenz schon gestört ist, würde ich dann doch lieber zur Variante der vollen Namen tendieren. -- Feblue 10:24, 2. Jul. 2021 (CEST)

Folge da Fe komplett. Zumal: Warum die Kategorie aus Einfachheitsgründen unter Rufnamen, die Artikel dann aber unter Vollnamen? IMHO macht es da keinen Sinn unterschiedliche Regeln zu haben. Und wie im Ursprungspunkt angemerkt: Ich bin mir 99% sicher, dass es nicht nur Charaktere betrifft, wie definieren wir dann wieder Rufnamen bei zB Spielen, wo wir schon in der Vergangenheit längere Diskussionen geführt haben, was denn nun der Vollname ist? Jones ^Albtraum? 21:07, 2. Jul. 2021 (CEST)

Ich spreche mich auch dafür aus, den Namen einer Kategorie dem Namen seines dazugehörigen Hauptartikels anzupassen. Somit wäre es konsistent. -MfG, Kenaz-Hagalaz ^Disku 21:20, 2. Jul. 2021 (CEST)

Schließe mich hier der Meinung von Kenaz an. ~ Taisuke ^Diskussion 23:43, 2. Jul. 2021 (CEST)

Da sich hier inzwischen ein Konsens abzeichnet (Kategoriename = Artikelname - Klammerzusätze) würde ich hiermit nochmal eine Frist bis Mittwoch (14.7.2021) setzen um das Ganze abzuschließen. Anschließend würde ich einen der aktuellen Botbetreiber die Verschiebungen vorzunehmen. Jones ^Albtraum? 13:17, 10. Jul. 2021 (CEST)

...falls der Artikelname ohne Klammern noch eindeutig ist. Müsste man wahrscheinlich für jeden Fall einzeln prüfen. --Datei:Sugimori 672.pngMecanno-man^Mäh 13:11, 12. Jul. 2021 (CEST)

Da die Frist ohne weitere Einsprüche verstrichen ist, halte ich hiermit die obige Entscheidung fest. Jones ^Albtraum? 19:48, 16. Jul. 2021 (CEST)

Veränderung der Entwicklungsreihen Info

Vorab, tut mir leid falls das hier der falsche Ort ist für diese Diskussion. Nach einigem rumschauen ist es mir nicht möglich gewesen, einen besseren Ort zu finden.

Ich möchte mich stark gegen die neue Version der Entwicklungsinfos aussprechen. Nicht nur sind die Pokemon jetzt kleiner, was es teilweise schwierig machen kann sie richtig zu erkennen, es bringt auch unnötiges Geklicke, weil die Infos jetzt nicht mehr alle zusammen angezeigt werden. Ein guter Teil der Pokemon sind von letzterem nicht übermäßig betroffen, aber meine Güte ist es unnötig verkompliziert ohne weiteren Nutzen.

Das hier ist die Seite von Evoli (Screenshot). Fast die ganze vertikale Länge der Seite und trotzdem nur unnötig kleine Bildchen. Warum man Entwicklungsstufen anklicken muss, damit sie halbwegs akzeptabel sichtbar sind ist mir schleierhaft.

Ja, das ist ein extremes Beispiel, aber das ist da um zu demonstrieren wie wenig die Veränderung hilft. Ich war immer der Ansicht, dass PokeWiki die beste Wikiseite für Pokemon ist, weil selbst andersprachige Alternativen oft Informationen an "falsche" Plätze setzen, wie Bulbapedia die Entwicklungsinformationen in der Regel in die untere Hälfte des Artikels werfen. Aber selbst die haben eine bessere Möglichkeit für Entwicklungsdarstellung gefunden (Screenshot). Das wurde auf der gleichen Größe aufgenommen, auf der ich Pokewiki habe und guck mal an, da ist alles bündig und gut sichtbar zusammengefasst! Ich denke, dass die vorherige Version der Entwicklungsinfo, die wir hier hatten, dass mindeste ist und kann zur Veränderung nur den Kopf schütteln.

Hoffe, dass Sinn hier gewinnt und man nicht einfach Dinge versucht zu reparieren, die nie kaputt waren. -- Elogan 23.07.2021 (CEST)

Hallo Elogan, zunächst ein mal kann ich dich beruhigen, das hier ist ein sehr guter Platz für eine solche Anmerkung, du musst dir also keine Sorgen machen, dass du da am falschen Platz bist. Es ist natürlich schade, dass dir das neue Design der Entwicklungs-Vorlage so nicht gefällt, ich fürchte allerdings, dass du dich damit abfinden werden musst. Selbstverständlich haben wir nicht einfach geändert, um zu ändern, das ganze verfolgt natürlich einen Zweck. Und zwar entwickeln wir ein responsives Design für das PokéWiki, um vor allem auf Mobilgeräten in Zukunft ein besseres Erlebnis bieten zu können. Um dies zu erreichen ist es allerdings notwendig, alle Inhalte auch auf geringen Seitenbreiten korrekt anzeigen zu können, speziell ist unsere Untergrenze 320 Pixel - was nicht viel ist. Dementsprechend müssen unsere Inhalte bei Bedarf in der Breite schrumpfen können, was besonders bei der Entwicklungs-Vorlage extrem schwierig ist, weil wir variable Inhalte haben, für die ein allgemeingültiges Konzept gefunden werden musste. Das Ergebnis ist daher das, was du siehst, die Inhalte sind jetzt so schmal, dass sie entweder direkt passen oder in Zukunft bei Bedarf von horizontal auf vertikal umbrechen werden, um auch weiterhin alles korrekt anzeigen zu können. Inhaltlich sollte sich nichts geändert haben, es ist jetzt nur leider notwendig, auf das jeweilige Pokémon zu klicken, um an die dazugehörigen Informationen zu gelangen. Um auf dein Beispiel einzugehen: Evoli ist aktuell leider etwas extrem, das hängt damit zusammen, dass Feelinara sehr viel Text hat, wodurch die anderen genau so viel Platz verbrauchen, um ein einheitliches Bild zu bieten. Uns ist bewusst, dass es ein paar Fälle gibt, die da sehr ausladend sind, wir werden uns in den kommenden Tagen darum bemühen, solche Problemfälle noch weiter zu verringern, wobei das natürlich auf Kosten der Informationsmenge gehen könnte. Wir werden daher einen gesunden Mittelweg gehen. Daher lass mich dir versichern, dass wir hier nichts reparieren, was nicht kaputt ist, sondern nur das reparieren, was in absehbarer Zukunft definitiv kaputt gehen würde, was genau hier der Fall war. -- RobbiRobb 15:54, 23. Jul. 2021 (CEST)

Hallo Robbi, danke für die Antwort! Ich hatte erwartet, dass es mit der Mobilerfahrung zu tun hat, wie leider viele Seiten die Desktoperfahrung an zweite Stelle setzen. Ich kann verstehen, dass viele Nutzer die Seite so aufrufen, auch wenn ich nicht dazugehöre. Ich denke ich hatte einfach gehofft, dass es für mobil jeweils Extraseiten gibt wie Wikipedia u.ä. es handhaben. Ich nehme mal an, dass das wahrscheinlich schon durchüberlegt wurde und aus welchem Grund auch immer nicht durchkam (Zeit, Ressourcen, etc). Abgesehen davon könnte ich mir vorstellen (wenn das überhaupt geht), dass man die Entwicklungsinfo zum Beispiel toggeln kann von einer Version zur anderen, mit der aktuellen als Voreinstellung. Mobile Nutzer müssten dann nichts ändern und falls sie rumtogglen (wenn sie das überhaupt können in dem Fall) könnten sie ja direkt zurück zur mobilfreundlichen Version. Nur ein paar Gedanken in den Ring geworfen. Ich würde mich freuen, wenn es in Zukunft irgendeine Möglichkeit gibt, das für beide Erfahrungen gut zu lösen.

Nochmal danke für die nette Erklärung der Situation -- Elogan 18:39, 24.07.2021 (CEST)

Zuschneidung der Trainer-Sprites

Pings:

• Trainer-Projekt: @Cliffichen, @GoPika
• Charakter-Projekt: @Mecanno-man
• Beteiligte: @Ryuichi (Orte-Projekt), @Taisuke (Pokédex-, Spin-off-Projekt)

Ryuichi und ich sind im Discord im Orte-Projekt-Kanal #orte auf die Frage gekommen, wieso die Trainer-Sprites nicht zugeschnitten sind. Da ich momentan im Zuge der Sinnoh-Initiative sämtliche Trainer-Infos der 4. Gen korrigiere und ergänze, wollte ich im Artikel Jubelstadt die Sprites von Lucia und Lucius, sowie die der beiden Galaktiker Rüpel nebeneinander statt untereinander anordnen. Dafür muss ich die Pixelgröße selber einstellen, da der Whitespace der Sprites so groß ist, dass sie verschoben werden. (In der Spritebox ist 147px-Breite Platz, beide Sprites sind 80x80) Wenn diese Sprites zugeschnitten wären, würden diese sich automatisch nebeneinander anordnen.

Das sollte natürlich mit den zugehörigen Personen abgesprochen werden. Hier sollte ganz klar zwischen Pokémon- und Trainer-Sprites unterschieden werden. Dass die Pokémon nicht zugeschnitten werden ist klar, es geht nur um die Trainer. Die Trainer-Sprites aus Sonne und Mond scheinen außerdem sogar schon zugeschnitten zu sein, wie man hier beispielsweise sehen kann. Wäre es in Ordnung, zumindest die Sprites der vierten Generation zuzuschneiden? Über die anderen Generationen könnte man dann noch diskutieren, mir geht es erstmal nur um die aus der vierten Gen. ~~ DieTaube 17:01, 21. Aug. 2021 (CEST)

Ich hab von meiner Seite her zumindest nichts prinzipiell dagegen einzuwenden die Sprites zuzuschneiden - habe lediglich bemerkt das die Sprites der Pokémon auch nicht zugeschnitten sind, was eventuell für die Einheitlichkeit irgendwo problematisch werden könnte. Sofern die Sprites nirgendwo alle auf eine fixe Grösse runterskaliert werden verliert man auch keine Grössenverhältnisse - und das ist soweit ich sehen kann aktuell nirgends der Fall. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:11, 21. Aug. 2021 (CEST)

Wie schon auf Discord geschrieben, mir ist es recht egal. Ich denke den Whitespace links und rechts zu entfernen sollte so keine Auswirkungen haben. Wichtig ist einzig das die Höhe bei den Sprites je Spielgruppe Ident ist. Nicht das die Göre kleiner ist wie der Teenager. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:53, 21. Aug. 2021 (CEST)

Ich sehe nicht so wirklich den Grund darin, die Trainer in ihrer Originalgröße zu behalten. Daher wäre ich ein Befürworter vom Zuschneiden, das stört mich unter Anderem in den Sprite-Boxen der Trainerklassen auch schon immer. -- Cliffichen 20:47, 21. Aug. 2021 (CEST)

Alles wichtige wie mit den Größenverhältnissen wurde gesagt, ich habe auch nichts gegen zuschneiden. - - "I'm gonna swing from the chandelier" GoPika ^Disku 11:18, 22. Aug. 2021 (CEST)

Ich sehe das dann als eine beschlossene Sache an. Ich würde dann alle Dateien in den Kategorien DP-Trainersprite, Platin-Trainersprite und HGSS-Trainersprite zuschneiden und dementsprechend updaten ^^ Fehlen da noch mehr Kategorien, die angepasst werden sollten? ~~ DieTaube 14:21, 26. Aug. 2021 (CEST)

Die Frage habe ich auch noch, ob wir das auch für andere Spiele bzw. Kategorien beschliessen können. Also von meiner Seite aus sollten alle VS-, Trainer-, OW-Sprites und 3D-Modelle zugeschnitten sein. Ich bin auch selbst dazu bereit, das nach und nach zu machen. -- Cliffichen 15:33, 27. Aug. 2021 (CEST)

Stelle mich auch gerne dazu bereit, war sogar am überlegen die fünfte Gen noch zu machen. Die ganze vierte Gen müsste jetzt zugeschnitten sein. Die einzigen Ausnahmen die ich da gemacht habe sind die Intro-Sprites wie bspw. Trainersprite Lucius Intro DP.png. Auch ist mir am Beispiel von Trainersprite Lyra Pokéathlon HGSS.png hier aufgefallen, dass es doch leider tatsächlich Trainersprites ohne Kategorie gibt. Ich bin natürlich nur die Dateien aus den Kategorien durchgegangen, weswegen ich es für möglich halte, dass es mehr solcher Exemplare gibt. Bin aber abgesehen davon auch dafür, dass das alles zugeschnitten sein sollte. ~~ DieTaube 15:48, 27. Aug. 2021 (CEST)

Könnte sein das es bei einigen anderen dann zu Probleme mit Grössenverhältnissen kommt, insbesondere wenn man an Navleisten und so denkt. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:35, 27. Aug. 2021 (CEST)

Tai hatte auch noch bedenken und hat sich hier bisher noch nicht geäußert. Das würde ich gerne noch hören. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 07:33, 28. Aug. 2021 (CEST)

Da es in dieser Diskussion nur um die Trainer-Sprites geht, habe ich mich hier bewusst nicht weiter dazu geäußert. ~ Taisuke ^Diskussion 18:09, 28. Aug. 2021 (CEST)

Spielekürzel oder Kurzformen in Artikelnamen (Unterseite und Klammerzusatz)

Vorherige Bereits archivierte Diskussion

Heyho, ich bin mir grad nicht sicher, ob wir die Diskussion nicht schonmal hatten, möchte sie im Zweifel aber nochmal anstoßen. Und zwar geht es mir um die Nutzung von Spielekürzeln in Artikelnamen, insbesondere als Klammerzusatz. Im konkreten Fall gehts mir um Partner-Pokémon (LGPE), ich bin mir aber sicher mit nen bissl suchen findet man noch andere. Gerade wenn eh schon ein Klammerzusatz zur Unterscheidung nötig ist, wäre ich dafür diesen auch auszuschreiben (also Partner-Pokémon (Pokémon: Let’s Go, Pikachu! und Let’s Go, Evoli!)) damit die Artikel auch wirklich klar da sind wo sie hingehören. Die Kürzel kann man gerne als WL lassen, auch wenn ich eher bezweifel, dass sie gebraucht werden (wer sucht wird eh erst auf der entsprechenden BKL landen und danach macht der Klammerzusatz auch nichts mehr). Technisch oder sonst wie macht das keinen Unterschied, es geht hier einfach um etwas klarere Regeln damits einheitlich ist und mMn ist der ausgeschriebene Name deutlicher. Jones ^Albtraum? 15:57, 5. Feb. 2019 (CET)

Würde ich so definitiv unterstützen. Die gekürzte Variante sieht auch einfach nicht schön aus als Artikelname. Entweder ganz oder gar nicht.. SwowoJonny 19:00, 5. Feb. 2019 (CET)

Pro Jones' Vorschlag Das Isso 08/15 ^Konter 22:47, 5. Feb. 2019 (CET)

Würde ich so auch definitiv unterstützen. Vielleicht wäre hier eine Abstimmung die beste Option?--❄❄ Pk-fan 00:02, 6. Feb. 2019 (CET)

Den Vorschlag würde ich ebenfalls unterstützen. Die gekürzte Variante passt meiner Meinung nach einfach nicht zu einem Artikelnamen. GrollenKette951 02:04, 6. Feb. 2019 (CET)

Eine Abstimmung brauchts erst wenn hier jemand für die Kürzel argumentiert... --Datei:Sugimori 672.pngMecanno-man^Mäh 02:56, 6. Feb. 2019 (CET)

Bisher ist die Meinung recht eindeutig, insofern würd ich da jetzt auch keine Abstimmung starten und einfach ne Frist bis Sonntag setzen. Abstimmung hat auch immer den Nachteil, dass keine richtige Diskussion entsteht, evtl hat ja doch einer ne gute Argumentation parat für die Kurzversion :ka: Jones ^Albtraum? 09:12, 6. Feb. 2019 (CET)

Ich bin auch gegen Kürzel. Aber geht es nur darum, dass Kürzel vermieden werden sollen, oder geht es auch um eine Regel, wie genau die Spielenamen in Klammerzusätzen ausgeschrieben werden sollen, z. B. (Ranger 2) vs. (Pokémon Ranger: Finsternis über Almia)? – shadowtweaker 11:58, 6. Feb. 2019 (CET)

Wohl eher ersteres, Shadow, aufgrund der Länge.. Ich meine ich denke mal an Pokémon Mystery Dungeon.... Partner (Pokémon Mystery Dungeon: Erkundungsteam Zeit, Erkundungsteam Dunkelheit und Erkundungsteam Himmel). Also bei Spielen, die zu einer aneinanderreihenden Serie gehören, würde ich das bevorzugen. SwowoJonny 12:48, 6. Feb. 2019 (CET)

Aufgrund der Länge würde ich gerne vermeiden, dass zu lange Klammerzusätze verwendet werden, ehe man zu Situationen wie bei Pokémon – Der Film: Schwarz – Victini und Reshiram/Pokémon – Der Film: Weiß – Victini und Zekrom kommt. -- Skelabra2509 (Diskussion | Beiträge) 01:03, 9. Feb. 2019 (CET)

Basierend auf der obigen "Diskussion" setz ich mal folgendes Regelwerk auf:

1. Klammerzusätze sollten im Idealfall den vollständigen Spielenamen beinhalten
2. Sollte dieser zu lang sein (Beispiel PMD von Swowo oben) kann er gekürzt werden (bspw zu Pokémon Mystery Dungeon 2)
3. Reine Kürzel sollen vermieden werden (Beispiel von oben: PMD2 ist als Klammerzusatz unerwünscht)
4. Klammerzusätze sollten einheitlich sein, dies betrifft insbesondere den Fall von Kürzungen

Einspruch kann morgen eingelegt werden, ansonsten sehe ich das ganze als beschlossen an und setze es zumindest für die mir bekannten Fälle um, ebenfalls dienen die Punkte dann auch als Referenzbeschluss für zukünfige Fälle. Jones ^Albtraum? 23:24, 27. Feb. 2019 (CET)

Die Im Spoiler ersichtliche Diskussion fand 2019 statt wo es auch Diskussionen usw via Discord gab. Kurzum mir war es entfallen das wir das schon mal so festgelegt hatten. Im Zuge einer Änderung im Orte-Projekt und dem Hinweis zur Handhabung des Trainer-Projektes gab es meinerseits eine Abstimmung wie nun Spielzusätze (unabhängig ob als Unterseite oder als Klammerzusatz) hinterlegt werden sollen. Es gab die Optionen

• Vollständig ausschreiben: Pokémon Goldene Edition HeartGold und Silberne Edition SoulSilver
• Gekürzt: Pokémon HeartGold und SoulSilver
• Spielkürzel: HGSS

Die vorläufige ABstimmung hinterlege ich einmal mit hier

3. Namensformat des Spielzusatzes

Jeder berechtigte Benutzer kann eine Stimmen abgeben.

Vollständig ausschreiben: Pokémon Goldene Edition HeartGold und Silberne Edition SoulSilver

1. Auch wenn die Namen etwas länger wirken finde ich es zielführender beim richtigen Namen zu bleiben. Entweder wir sind ein Wiki das auf korrektheit der Namensbezeichnung wert legt oder machen ein wie es mir gefällt. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:41, 24. Sep. 2021 (CEST)
2. - -wowoJonny 14:11, 16. Sep. 2021 (CEST)
3. Jones ^Albtraum? 14:39, 16. Sep. 2021 (CEST)
4. Flonc ^Diskussion ~ Stein oder nicht Stein, das ist hier die Frage! 20:27, 17. Sep. 2021 (CEST)
5. —DaneeBound 13:04, 24. Sep. 2021 (CEST)
6. Ich mache an dieser Stelle auf diese Diskussion aufmerksam und betone, dass ein Beschluss für gekürzte Spieltitel sich über den Beschluss dieser damaligen Diskussion, der Wikiweit gilt, hinwegsetzen würde. Es ist demnach zwar erlaubt, zu kürzen, dennoch sollte das meiner Meinung nach nur in Ausnahmefällen gemacht werden, nicht quer durch einen gesamten Bereich des Wikis. -- RobbiRobb 01:02, 26. Sep. 2021 (CEST)

Gekürzt: Pokémon HeartGold und SoulSilver

1. Scheint mir am sinnvollsten, ist aber auch nur persönliche Präferenz. --Datei:Sugimori 672.pngMecanno-man^Mäh 12:59, 16. Sep. 2021 (CEST)
2. Poffel — Diskussion 14:31, 16. Sep. 2021 (CEST)
3. War nie ein Freund der langen Titel. Die Editionen würde ohnehin fast nie ein Leser beim vollen Namen nennen.--✦✧  Pk-fan ✧✦ 17:06, 16. Sep. 2021 (CEST)
4. -- feblue 19:59, 16. Sep. 2021 (CEST)
5. Red Bull Salzbourg (Diskussion) 22:34, 16. Sep. 2021 (CEST)
6. Schwierige Entscheidung, aber ich bin leicht auf dieser Seite. – Vircaprae 18:42, 18. Sep. 2021 (CEST)
7. lange Titel oder nur die Spielekürzel erscheinen mir leicht verwirrend BlauesSerpiroyal ^Diskussion 13:50, 19. Sep. 2021 (CEST)
8. MfG Goloer444 15:16, 19. Sep. 2021 (CEST)
9. Wegen der Länge der Artikelnamen sollten hier nicht die vollständigen Editionstitel verwendet werden. Mir würden die Spielkürzel zwar auch ausreichen, da die aber für viele Benutzer verwirrend sein könnten, scheinen mir die gekürzten Namen die beste Wahl zu sein. Lasagne (Diskussion) 15:13, 23. Sep. 2021 (CEST)
10. Das Isso 08/15 ^Konter 14:44, 24. Sep. 2021 (CEST)

Spielkürzel: HGSS

Enthaltung

Durch den Hinweise von Robbi ist mir diese Entscheidung wieder bewusst geworden was eine Abstimmung obsolet macht. Die vorzeitige Beendigung ist nicht überall auf Anklang gefallen. Ich finde es nur unnötig wenn wir innerhalb des Orte-Projektes eine andere Schiene Fahren wie im Rest des Wikis. Daher eröffne ich den Diskussionspunkt hier einmal erneut.

Bisherige Kommentare auf der Orte-Projektseite

Bei der vorzeitig beendeten Abstimmung zum Namensformat des Spielzusatzes stellt sich mir folgende Frage: Ist ein Wiki-weiter Beschluss, der vor über zwei Jahren ohne Abstimmung getroffen wurde, wirklich mehr wert als eine aktuelle Abstimmung? Zumal es mehrere Gründe gibt, die Anwendbarkeit dieses Beschlusses für diesen Fall in Frage zu stellen:

• Erstens war zum damaligen Zeitpunkt nicht die Tragweite der zu treffenden Entscheidung klar, was vermutlich dazu geführt hat, dass sich viele stimmberechtigte Nutzer weniger Gedanken darüber gemacht oder gar nicht erst an der Diskussion beteiligt haben. Dass sich die Meinungen von Nutzern ändern können, wenn die Bedeutung der Entscheidung klar ist, zeigt sich auch daran, dass viele der Nutzer, die damals für ein Verbot von Spielekürzeln argumentiert haben, jetzt für die gekürzten Namen abgestimmt haben (Isso08-15, Pk-fan und Mecanno-man).
• Zweitens ging es in der Diskussion damals um Spielekürzel und nicht um gekürzte Namen. Der letztendliche Beschluss spricht sich zwar auch gegen die Verwendung gekürzter Namen aus, allerdings bezweifle ich, dass in der Zeitspanne von nur einem Tag (!), in der Widerspruch gegen den Beschluss eingelegt werden konnte, alle stimmberechtigten Nutzer daran gedacht haben.
• Drittens verbietet der Beschluss gekürzte Namen nicht gänzlich und nennt explizit die Kürzung von Spieletiteln als Option, wenn ein Artikelname zu lang wird. Außerdem spricht der Beschluss sich für eine einheitliche Behandlung von Spielezusätzen in Bezug auf Kürzung aus. Nach meinem Verständnis bedeutet das, dass eine einheitliche Verwendung gekürzter Spieletitel in den Artikelnamen von Orte-Artikeln mit diesem Beschluss vereinbar ist, wenn die Verwendung vollständiger Spieletitel in einigen Fällen als zu lang empfunden wird.
• Viertens ist der Beschluss technisch gesehen nicht anwendbar, wenn sich hier Option A oder B bei Hauptabstimmung 2 durchsetzt, da der Beschluss sich auf Klammerzusätze und nicht auf Zusätze nach einem Schrägstrich bezieht (ich weiß, das ist kleinlich, aber meiner Meinung nach ist es ebenfalls recht kleinlich, diesen Beschluss auch gegen gekürzte Namen und nicht nur gegen Spielekürzel anzuwenden).

Grüße, Lasagne (Diskussion) 13:12, 27. Sep. 2021 (CEST) (Punkt 3 ergänzt und Rest leicht überarbeitet: Lasagne (Diskussion) 13:41, 27. Sep. 2021 (CEST))

Der Beschluss ist Projektübergreifend und war mir als solches nicht mehr bekannt. Nach Projektinterner Rücksprache sind wir mehrheitlich der Meinung wir beenden diese Abstimmung vorzeitig aufgrund des Beschlusses. Und in der Gewichtung liegt dieser als Wikibeschuss über dem Projektentschluss (unabhängig wie viele daran teilnehmen) höher. Wenn es hier eine Neue Handhabung geben sollte dann am besten auf der AD den Punkt Neueröffnen. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:20, 27. Sep. 2021 (CEST)

Robbis Argument, dass nicht in einem gesamten Bereich des Wikis gekürzte Spielnamen verwendet werden sollen, ist meiner Meinung nach irgendwie sinnfrei, weil genau das schon im Trainer-Projekt gemacht wird (siehe Kategorie:Trainerliste) Außerdem finde ich es falsch, die Abstimmung abzubrechen, aufgrund von einer Diskussion (Spielekürzel in Artikelnamen) in der eigentlich beschlossen wurde, dass Kurzformen weiterhin verwendet werden können... – Vircaprae 01:41, 28. Sep. 2021 (CEST)

Mir war nicht bewusst, dass das Trainer-Projekt da was eigenes macht, gefällt mir auch nicht wirklich. Mir ist bewusst, dass es die Möglichkeit gibt, trotzdem abzukürzen, das war soweit ich das in Erinnerung habe aber auch eher so gedacht, dass es für Extremfälle genutzt werden kann - in den Hauptspielen gibt es zumindest meiner Meinung nach keinen solchen Fall. Eher sowas wie PMD2, wo dann Zeit, Dunkelheit und Himmel zusammenkommen. Aber gut, wenn sowieso jeder so macht, wie er meint Ist ja auch nur meine Meinung mit entsprechender Begründung. -- RobbiRobb 02:19, 28. Sep. 2021 (CEST)

Ich interpretiere aus der Diskussion von damals das wir per Community-Entschied keine Spielkürzel (also sowas wie HGSS oder PMD2) in Artikeltiteln wollen; der Abschluss von Jones ist aber entweder eine ungüngstige Formulierung seitens Jones oder sein eigenes Ding das niemand bemerkt hat, nicht aber etwas wo wirklich die Community dahinter steht. --Datei:Sugimori 672.pngMecanno-man^Mäh 04:59, 28. Sep. 2021 (CEST)

Mein Fazit ist das ich die Herangehensweise von Jones weiterhin unterstützte. Kürzel sollen gar nicht verwendet werden und Kurzformen nur wenn die Länge übermäßig ist. Ich bin generell kein Freund vom kürzen. Es verfälscht den Originalen Titel. Da sich allerdings hier auch gezeigt haben das wiez.B. Mec sich Meinungen ändern können finde ich es sinnvoll das wir diesen Punkt noch einmal ausführlich Diskutieren und Wikiübergreifend behandeln. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:57, 28. Sep. 2021 (CEST)

Ich hab mir jetzt mal die Diskussion angeschaut und würde sagen, dass Kürzel (sowas wie SWSH, SoMo etc.) nicht genutzt werden sollten, Kürzungen bei übermäßiger Länge jedoch schon (siehen PMD2). Was jetzt hier diese großen Änderungen in der Orte-Abstimmung verursacht haben wird, wird wahrscheinlich die Tatsache sein, dass gefühlt niemand aus der Community sowas wie „Pokémon Goldene Edition HeartGold und Silberne Edition SoulSilver“ auch wirklich so nennt sondern eher „Pokémon HeartGold und SoulSilver“. Selbes wahrscheinlich auch bei den ganzen anderen Spielen, die ein Edition irgendwo drinnen haben. Ich würde mich an der Stelle auch eher für die Version ohne Edition aussprechen, da es einfach die geläufigste Variante des Namens ist. Mal schauen, was es hier noch für Input geben wird. Auf jeden Fall sollte man nach der Diskussion alle Kürzungen/nicht-Kürzungen vereinheitlichen. GrollenKette951 12:48, 28. Sep. 2021 (CEST)

Ich bleib bei meiner Meinung: ausschreiben und vorallem einheitlich. Bei Spiele Namen besteht immer ein bisschen das Problem zwischen "wie heißt es" vs "wie wirds genannt" (bspw eben der Editionszusatz, aber insbesondere auch zB Gelb), hier gab es dieselbe Diskussion in der Vergangenheit über die Namen der Spieleartikel und es wurde sich für die vollständigen Namen ausgesprochen. Insofern würde ich auch bei den Zusätzen für diese plädieren. Jones ^Albtraum? 13:41, 28. Sep. 2021 (CEST)

Gelb finde ich nicht gerade das beste Beispiel da wie man auf Datei:Pokémon Gelb.jpg sieht sowohl Pokémon Special Pikachu Edition als auch Pokémon Gelbe Edition zulässig wären. Im Endeffekt sollte allerdings die Unterseite oder der Klammerzusatz sich auch am im Wiki verwendeten Spielenamen orientieren. Wie im Eingangsbeispiel (2019) Pokémon: Let’s Go, Pikachu! und Let’s Go, Evoli! statt LGPE oder Let’s Go, Pikachu und Let’s Go, Evoli oder Let’s Go oder whatever. Auch wenn es hier und da einmal länger wird, so finde ich das dies korrekt und nicht willkürlich entsprechend der Gewohnheit gewählt wäre. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 14:19, 28. Sep. 2021 (CEST)

Ich möchte einwerfen, dass es sich bei den gekürzten Editionstiteln keineswegs nur um Fanbegriffe handelt, sondern sie zumindest teilweise auch offiziell verwendet werden, z. B. auf den offiziellen aktuellen deutschen Webseiten zu Smaragd, Diamant und Perl sowie HeartGold und SoulSilver. Tatsächlich werden die eigentlichen offiziellen Titel auf diesen Webseiten an keiner Stelle erwähnt. Bei den offiziellen Webseiten zu einigen anderen Editionen werden hingegen die Langformen verwendet, so z. B. bei Schwarz und Weiß.
In jedem Fall denke ich, dass die Verwendung beider Formen von offizieller Seite bedeutet, dass wir gekürzte Titel auf keinen Fall als verfälscht oder willkürlich ansehen sollten. Stattdessen sollten beide Formen als gleichwertig angesehen werden und im PokéWiki die jeweils besser passende Variante verwendet werden können. Und da die Kurzform geläufiger und natürlich kürzer ist, wird sie meiner Meinung nach in den meisten Fällen die bessere Wahl sein. Bei den Spiele-Artikeln selbst halte ich es hingegen weiterhin für sinnvoll, die "förmlichere" Langform im Titel und am Anfang der Einleitung zu verwenden, wobei man die Kurzform eventuell ebenfalls explizit in der Einleitung oder der Infobox nennen kann. --Lasagne (Diskussion) 15:49, 28. Sep. 2021 (CEST)

Habe grundsätzlich dieselbe Position wie Lasagne: Spiele-Artikel selbst bitte auf dem Volltitel lassen, aber in allen anderen Fällen macht es meiner Meinung nach Sinn die geläufige Form/"gekürzte Form" zu nutzen. Nicht aber die Spielekürzel (HGSS etc.), wie in der alten Diskussion eigentlich schon entschieden. --Datei:Sugimori 672.pngMecanno-man^Mäh 22:00, 28. Sep. 2021 (CEST)

Zunächst einmal finde ich auch, dass Spielekürzel wie HGSS nicht in Artikelnamen (oder Fließtexten...) verwendet werden sollen, aber ich denke mal das steht hier auch gar nicht zur Debatte. Meiner Meinung nach ist es jedoch sinnvoll, für Unterseiten die Kurzformen der Spiele zu verwenden (also die Versionen ohne "Edition", wie Peter meinte). Die Gründe dafür wurden schon genannt: mit den voll ausgeschriebenen Spielenamen können die Artikelnamen ziemlich lang werden (als relativ langes Beispiel Pokémon-Arena von Viola City (Pokémon Goldene Edition HeartGold und Silberne Edition SoulSilver)?, und bei anderen Spielegruppen wird es noch längere geben), von der Community wird der volle Name so gut wie gar nicht genutzt und auch von offizieller Seite werden Kurzformen verwendet. Die Spiele-Artikel selber sollten weiterhin den vollständigen Namen haben, aber ich denke auch das steht gar nicht zur Debatte.

Im Endeffekt: Spielekürzel sollten nicht verwendet werden, Kurzformen können verwendet werden (also wie es in der Diskussion damals wikiweit beschlossen wurde); wobei man bei Unterseiten lieber Kurzformen verwenden sollte (also wie Peter, Lasagne und Mec schon meinten). – Vircaprae 01:05, 29. Sep. 2021 (CEST)

Die Problematik bei der Pokémonseite ist das es für RBGRUSA keine gekürzten Bezeichnungen gibt bzw. diese generell in der Liste fehlen. Warum auch immer. Und diese Kürzungen lediglich auf Spiele vor Gen5 zutrifft, danach gibt es keine mehr. Auch wird "Pokémon Crystal (Kristall-Edition) für die Virtual Console" verwendet. Mir wäre nicht geläufig das Crystal eine Bezeichnung ist die im deutschsprachigen Raum groß bekannt oder genutzt wird. Gefühlt nutzt der Großteil Kristall. Eine Einheitliche Linie scheint es dort nicht zu geben, weshalb ich dies als Referenz auch mit Skepsis sehe. Auch Haben wir sowas wie Pokémon: Let’s Go, Pikachu! und Let’s Go, Evoli! was ich gefühlt genauso lang finde wie Pokémon Goldene Edition HeartGold und Silberne Edition SoulSilver, und nein ich habe jetzt keine Zeichnen gezählt^^. Im Großen und ganzen macht es für mich keinen Unterschied ob wir hier von Bezeichnungen nach dem / oder in Klammern reden. Ich wäre für eine einheitliche Linie wikiweit wie sie bereits seitens Jones vorgeschlagen wurde und würde zu einer Kürzung nur im äußersten Maße greifen. Obwohl ich auch sowas wie due PMD-Sache ausgeschrieben hätte. Bisher waren wir immer für eine genaue Bezeichnung, lange Bezeichnungen gibt es schon lange z.b. Pokémon – Der Film: Schwarz – Victini und Reshiram/Pokémon – Der Film: Weiß – Victini und Zekrom das ist für mich kein Argument zu kürzen und würde weiterhin dafür plädieren den Titel korrekt zu wählen. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:49, 29. Sep. 2021 (CEST)

Siehe diesen aktuellen Artikel für offizielle Verwendungen der Kurzformen Pokémon Gold, Silber, Kristall, Rot und Blau, hier für Pokémon Rubin und Saphir, hier für Pokémon Gelb, hier für Pokémon Feuerrot und Blattgrün und zuletzt hier für Pokémon Schwarz und Weiß. Die einzigen Kurzformen für Spiele der Hauptreihe, für die ich mit Google keine Verwendung auf der offiziellen Seite finden konnte, sind somit Pokémon Schwarz 2 und Weiß 2. Auch in aktuellen Artikeln zu diesen Spielen wird die Langform der Editionstitel verwendet (genauso wie übrigens für Schwarz und Weiß, wo ich aber eine Ausnahme finden konnte). Allerdings halte ich es nicht für willkürlich oder verfälschend, das von offizieller Seite genutzte Schema zur Kürzung von Editionstiteln auch auf diese Editionen anzuwenden. --Lasagne (Diskussion) 18:02, 29. Sep. 2021 (CEST)

Ich finde es schon willkürlich wenn man mal ausschreibt und mal kürzt. Auch zeigt die Geschichte von Pokémon immer wieder Anpassungen von Namen und Inhalten. Es gibt hier und dort Alternative Schreibweisen dies sagt allerdings null zur Handhabung fürs Wiki aus. Die Frage ist wie Schreiben wir die Namen der Editionen. Lassen wir Kürzungen zu die dann einheitlich sein sollten, einheitlich pro Projekt oder einheitlich fürs Wiki oder sollten wir einem Wiki entsprechend beim offiziellen Titel bleiben. Bis jetzt finde ich in der gesamten Diskussion kein Argument das für eine Kürzung und gegen die Langform spricht. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:39, 29. Sep. 2021 (CEST)

Ich bin auf jeden Fall auch dafür, die voll ausgeschriebenen Titel zu verwenden. Einheitlich zu den Spielenamen macht es das ganze deutlich übersichtlicher, sollte irgendwas zu den Spielen kategorisiert werden, bleibt es dann auch einheitlich. Wenn es wirklich darum geht, die gekürzten Titel zu verwenden, weil man zu faul ist, die vollen Titel zu schreiben, kann man von mir aus gerne Weiterleitungen für die Seiten anlegen, damit sie auch mit dem gekürzten Titel zu finden sind. Der tatsächliche Titel des Artikels sollte meiner Meinung nach aber konsistent zu den Spiele-Artikeln sein. -- RobbiRobb 23:25, 29. Sep. 2021 (CEST)

Bin da mal zum teil auf Robbis Seite. Und trotzdem mach ich mir eigentlich Sorgen bei Extremfällen, wie beim Artikelbeispiel „Heldenteam (Pokémon Fushigi no Dungeon: Susume! Honō no Bōkendan, Ikuzo! Arashi no Bōkendan und Mezase! Hikari no Bōkendan)/Zitate“. Da komm ich mit PMD2 ausgeschrieben inzwischen besser klar, als mit dem Desaster von PMD3. Diese Zeichenzahl ist immens. Bei so ziemlich jedem anderen Spiel wäre ich einverstanden. - -wowoJonny 00:07, 30. Sep. 2021 (CEST)

Abstimmung zur Nutzung der Sitenotice

Hallo zusammen! Im Chattreffen kam die Idee auf, die Sitenotice nicht nur für Gewinnspiele wie die Verbesserungswochen oder die Sinnoh-Initiative zu nutzen, sondern mit Hilfe der Sitenotice die Nutzer des PokéWikis aktiv auf Neuerungen hinzuweisen (wie z. B. auf die Entwicklungsvorlage oder die Stellenausschreibungen). Es besteht auch der Gedanke, mehrere Texte in die Sitenotice zu packen, die dann wie der Banner auf der Hauptseite nach ein paar Sekunden durchwechseln. Auf jeden Fall ist geplant, den Platz, den die Sitenotice bietet, relativ weitläufig auszunutzen. Das Ziel dahinter ist, besser mit den Nutzern des PokéWikis zu kommunizieren. Es wird allerdings auch befürchtet, dass die Sitenotice nach ein paar Wochen aus dem Auge des Lesers verloren geht und somit der Mitteilungseffekt nicht gegeben ist. Daher soll die folgende Abstimmung Klarheit darüber verschaffen, wie das Meinungsbild aussieht. Sollte es noch Fragen zu der Idee geben, können diese in den Kommentaren geäußert werden.

Abstimmung

Diese Abstimmung dient der Entscheidung über die Nutzung der Sitenotice für Neuerungen im PokéWiki. Jeder stimmberechtigte Benutzer darf eine Stimme abgeben. Die Abstimmung läuft bis zum 17. November 2021 um 23:59. Heute ist der 18.04.2024 07:19 Uhr.

Abstimmung abgeschlossen: Ja, die Sitenotice soll für Mitteilungen genutzt werden (Stimmen 21 Ja / 5 Nein)

Ja, die Sitenotice soll für Mitteilungen genutzt werden

1. Kann meiner Meinung nach ruhig dafür genutzt werden, allerdings sollte die Sitenotice nicht übernutzt werden, da sie sonst nach kurzer Zeit einfach übersehen wird. Sie sollte nur bei wirklich großen Änderungen benutzt werden und nicht zu lange bleiben, sodass sie weiterhin etwas "besonderes" bleibt. Als große Änderungen würde ich Vorlagen betrachten die sehr starke Änderungen im Design haben und in sehr vielen Artikeln eingebunden werden. Ein großes Problem ist wahrscheinlich eine Überbenutzung, wenn viele große Änderungen in einer kurzen Zeit folgen. In diesem Fall sollten also eventuell die Bedingungen verschärft werden. -- Mooni000 ^{Pelipper-Post} 10:20, 3. Nov. 2021 (CET)
2. Sehe das exakt wie Mooni. Keine Überbenutzung und wirklich nur beim Wichtigsten. Man könnte damit die generellen Änderungen zum mobilen Design zu Beginn ansprechen. Man kann sich das dann ja auch ein wenig anschauen und nach ein paar Monaten evaluieren, ob es doch keinen Mehrwert bringt, überbenutzt wird etc. - - "I'm gonna swing from the chandelier" GoPika ^Disku 10:43, 3. Nov. 2021 (CET)
3. Ich tue mich wirklich schwer damit nachzuvollziehen, woher der Gegendwind gegen eine solche Änderung kommt. Es ist ja nicht so, als würde die Sitenotice unsichtbar, nur weil sie permanent vorhanden ist. Das Problem ist nun mal, dass wir aktuell keine vernünftige Möglichkeit haben, auf Änderungen im Wiki aufmerksam zu machen, in welcher Form auch immer diese ausfallen. Auf der Hauptseite stehen und nur Neuigkeiten zu Pokémon, nicht aber zum Wiki selbst. Und selbst wenn dem so wäre würden sie vermutlich immer noch nur von einem Bruchteil wahrgenommen - was wir meiner Meinung nach also brauchen ist ein Banner, der auf jeder Seite sichtbar ist und auf aktuelle Änderungen im Wiki aufmerksam macht, damit die Leute nicht immer so überrascht werden, wenn sich wieder was ändert. (Stichwort Vorlagen-Umstrukturierung, Änderungen an Inhalten, große Strukturänderungen, zukünftig das mobile Design.) Viele Seiten im Netz haben irgendwo einen festen Banner, auf dem die wichtigsten Neuigkeiten gezeigt werden. Und bei uns eignet sich eben die Position der Sitenotice mit abstand am besten dafür. Es muss kein neuer Platz geschaffen werden, da er sowieso eben für die Sitenotice zur Verfügung steht. Dazu kommt, dass er extrem gut positioniert ist, da er am Seitenanfang von so gut wie jedem Benutzer gesehen wird. Anders als auf diesem Wege sehe ich aktuell leider einfach keinen Weg, wie wir die Besucher des Wikis über große Änderungen informieren sollen. Und mal wieder nicht informieren wird nur wieder für schlechte Laune bei denen Sorgen, die Zeit und Mühe investiert haben und dann wieder zu hören bekommen, wie schlecht doch alles ist und früher war alles besser. Und sollte sich wirklich herausstellen, dass das keine gute Idee ist, kann man das ganze ja immer noch wieder kippen. Aktuell sehe ich darin einfach eher einen Gewinn als einen Verlust. -- RobbiRobb 14:45, 3. Nov. 2021 (CET)
4. Ich würde ja in solchen Diskussionen gerne mehr begründen, aber sämtliche Begründungen, die ich hatte, haben die anderen auch genannt. Auch ich betone aber es wirklich nur bei wichtigen Dingen zu benutzen und die nicht dauerhaft einzubinden, sonst achtet iwann keiner mehr drauf. - -wowoJonny 17:37, 3. Nov. 2021 (CET)
5. Es gibt nur ein Medium, das alle Besucher des Wikis benutzen: Das Wiki selbst. Und das hat zwei antastbare Flächen, die überall zu sehen sind: Oben und unten. Unten sieht man höchst selten, also bleibt Oben als Sprachrohr. Der Punkt Aufmerksamkeit ist durch die Bewegung gedeckt. Ich hatte mir das so vorgestellt, dass wir pro Meldung eine Box haben und die Reihe an Boxen wird nach und nach durchrotiert (nicht nur erscheinen und verschwinden, sondern wirklich in den sichtbaren Bereich reinbewegen und dann kurz warten und wieder rausbewegen). So ist jede Meldung zu sehen und fällt auf. Dabei habe ich auch keine Befürchtung, dass das irgendwann untergehen könnte, denn Bewegung bzw. Veränderung fällt auf, egal wie lange sie schon passiert. Dass das eventuell zu ablenkend sein könnte, kann ich nachvollziehen, aber dann kann man denke ich einfach etwas nach unten scrollen und die Sitenotice ist nicht mehr zu sehen. Von demher sehe ich in der Sitenotice eine sehr gute wikiweite Kontaktmöglichkeit, die man nutzen sollte. --DeXter 20:18, 3. Nov. 2021 (CET)
6. Ich finde, dass die Sitenotice in der Hinsicht auch einfach mal genutzt werden kann. Wenn sich herausstellt, dass das doch nicht das Gelbe vom Ei ist, kann man die Sitenotice ja auch wieder rausnehmen. Für mich gilt aber erstmal, dass es versucht werden sollte. -- ~~ feblue 21:29, 3. Nov. 2021 (CET)
7. Ich finde die Nutzung der Sitenotice für sowas auch eine gute Idee, es wurde aber schon alles soweit dazu gesagt, deswegen habe ich dem nichts weiter hinzuzufügen Flonc ^Diskussion ~ Stein oder nicht Stein, das ist hier die Frage! 21:56, 3. Nov. 2021 (CET)
8. Ich denke, dass schon super Punkte dafür genannt wurden. Die Sitenotice ist vermutlich einer der Orte, auf die man als neuer Benutzer besonders achtet, bzw. welche die meiste Aufmerksamheit erzeugt. Sogar mir ist das bspw. nicht mit den Sinnoh-Initiativen oder den Spoilerwarnungen zu diversen Spielen entgangen. Overusing könnte ein Problem werden, aber zumindest spricht nichts dagegen, es einmal auszuprobieren. -- Arkany 21:39, 4. Nov. 2021 (CET)
9. Ich persönlich bin auch der Meinung, dass die Sitenotice erstmal dafür genutzt werden sollte aus den genannten Gründen. Mir als relativ neuer Nutzer wäre es bestimmt auch direkt aufgefallen. Man sollte ein Auge auf Overusing haben, aber ich bin auch der Auffassung, dass man es mal probieren sollte. Kernseife ^Diskussion 14:23, 5. Nov. 2021 (CET)
10. Nachdem ich jetzt die verschiedenen Meinungen gelesen habe, bin ich immer noch dafür. Man sollte es durchaus mal versuchen. Natürlich kann eine Animation oder Signalfarbe störend oder ablenkend sein, aber ohne es zu probieren können wir nicht wissen wie es ankommt. Und wenn es zu viele stört oder nicht die gewünschte Wirkung erzielt, dann kann man es immer noch wieder entfernen oder anpassen (Animation entfernen, Farbe ändern...). Von daher gebe ich den Gegenstimmen zwar recht, sehe aber keinen Grund es nicht zu versuchen. DeepSpace (Diskussion) 17:28, 7. Nov. 2021 (CET)
11. Alles was ich davon halte wurde eigentlich entweder bereits hier genannt oder von mir am Chattreffen gesagt. Der einzige Weg jeden Nutzer des Wikis direkt zu informieren ist auf jeder Seite eine Mitteilung einzublenden – und genau das ist eben die SiteNotice. Ich bin in jedem Fall der Nutzung dafür ein Begleitbild zu jeder Mitteilung hinzuzufügen, damit dieses die Aufmerksamkeit der Leser erwecken kann. Ansonsten sieht man immer nur blanken Text, den auf Dauer kein Mensch mehr richtig lesen wird. ~~ DieTaube 13:34, 8. Nov. 2021 (CET)
12. Ich kann mich nur allem hier bisher genanntem anschließen. Bennett ^Sturzflug 16:55, 8. Nov. 2021 (CET)
13. Ich sehe ebenfalls eine große Chance in der Nutzung der Sitenotice, um sowohl Benutzer als auch Besucher gut auf Neuigkeiten hinzuweisen. Die letzte Sitenotice zur Sinnoh-Initiative war auch von Mitte Mai bis Anfang Oktober zu sehen. An diesem langen Hinweis hat sich auch keiner gestört gefühlt, weshalb ich davon ausgehe, dass auch mit dem Vorhaben einer intensiveren Nutzung viele kein Problem haben werden. Der zeitliche Aspekt ist hier in jedem Fall aber wichtig. Man sollte sich Gedanken machen, was man wie lange dort stehen hat. Sollten die Informationen in kürzeren Abständen wechseln, sehe ich eigentlich keine Gefahr, dass die Hinweise nicht mehr wahrgenommen werden könnten. Man könnte den Wechsel ja auch farblich unterstreichen, indem man verschiedene Rahmen abwechselnd nutzt. Darüber hinaus glaube ich nicht, dass wir konsequent zu jedem Zeitpunkt etwas für die Sitenotice haben werden – auch wenn wir sie intensiver nutzen – und es somit trotzdem Tage geben wird, an denen dort nichts zu sehen ist. Ich würde dem Ganzen daher gerne eine Chance geben! :) ~ Taisuke ^Diskussion 08:03, 11. Nov. 2021 (CET)
14. Ich wäre auch für einen Versuch. Hatte im Grunde dieselbe Vorstellung wie DeXter es bereits geschildert hat. Eine paar kleine Punkte würde ich jedoch noch ergänzen wollen und zwar das man vielleicht zusätzlich bei mehreren Nachrichten Buttons zum Umschalten einfügen kann und mit der neusten Nachricht beginnen. MfG Goloer444 15:21, 14. Nov. 2021 (CET)
15. Ich bin dafür, die Sitenotice zu nutzen, um die PokéWiki-Besucher über größere Änderungen zu informieren. Wie viele andere denke ich aber auch, dass sie nicht zu intensiv genutzt werden sollte, was für mich bedeutet, dass sie zu mindestens 50 % der Tage in einem Jahr leer sein sollte. Mehreren wechselnden Nachrichten in der Sitenotice stehe ich ebenfalls skeptisch gegenüber. Ich hoffe, dass sich dieses Problem größtenteils dadurch erübrigt, dass bei der Umsetzung großer Änderungen darauf geachtet wird, nicht mehrere unabhängige von ihnen ungefähr gleichzeitig ins Wiki zu stellen. Bei großen Änderungen während eines langen Events wie der Sinnoh-Initiative könnte man den Hinweis über dieses Event für die Zeit, in der über die Änderung informiert wird, entweder ganz weglassen oder verkürzt zusammen mit der anderen Nachricht darstellen. --Lasagne (Diskussion) 16:56, 14. Nov. 2021 (CET)
16. Meiner Meinung nach spricht nicht viel dagegen. Es ist eben einer der besten Möglichkeiten (wenn nicht sogar die beste), um den Leser direkt auf den neusten Stand zu bringen. Solange es wirklich wichtig und gegebenfalls sogar anschaulich ist, bin ich also damit einverstanden.
    DarkOkto ^Diskussion 16:20, 15. Nov. 2021 (CET)
17. Ich tendiere eher zu pro. Es scheint wohl sowieso erstmal getestet zu werden. Das Isso 08/15 ^Konter 16:37, 15. Nov. 2021 (CET)
18. Nachdem ich mir die Begründungen dafür und dagegen hier durchgelesen habe, tendiere ich auch eher zu pro. Es stimmt, dass viele nicht mehr darauf achten werden wenn die Sitenotice zu häufig benutzt wird, aber wenn man das nur einmal im Jahr oder so (für sowas wie die Sinnoh-Initiative) benutzt, dann ist das auch keine optimale Ausnutzung. – Vircaprae 00:30, 17. Nov. 2021 (CET)
19. Ich hab nichts dagegen, dass die Sitenotice für wikiweite News benutzt wird. Dabei müssen wir aber auf jeden Fall darauf achten, dass die News nach nicht allzu langer Zeit entfernt werden und die Sitenotice nicht mit jedem Müll immer wieder aktiv gehalten wird. Sonst verlieren wir den Effekt, dass da mal was ist und mal nicht. GrollenKette951 01:13, 17. Nov. 2021 (CET)
20. Solange keine Überbenutzung stattfindet und die News dort nicht zu lange stehen, bzw. die Sitenotice immer mal wieder auch leer ist (also für z.B. ca. eine Woche verschwindet bis zur nächsten Mitteilung) und nicht direkt von einer auf die nächste News aktualisiert wird, könnte ich mir vorstellen das diese auch nicht so aus den Augen verloren wird wie befürchtet. Andererseits, das mit dem alle paar Sekunden durchwechseln könnte ich mir auch auf einer Seite praktisch und aufmerksamkeits erregend aber auf der anderen ebenfalls nervig vorstellen, kommt wohl auch drauf an wie viele es mitzuteilen gibt, und ob es deshalb ein durchwechseln zwischen mehreren Mitteilungen braucht. Ansonsten Hilft wohl nur ausprobieren, wirklich was zu verlieren hat man denke ich dabei nicht, wenn sich der gewünschte Effekt nicht so einstellt könnte man auch sofort wieder damit aufhören (es sollen ja keine hunderte Seiten umstrukturiert werden oder so, mal zum Vergleich). Was ich dann aber ggf. noch praktisch finden würde ist, wenn dann über die Sitenotice (Pokewiki-)News bekanntgegeben werden, ein Archiv dieser (z.B. wie PokéWiki:Hauptseite/Banner-Archiv), so das jeder Nutzer sehr einfach auch vergangene Mitteilungen nochmal nachlesen kann ohne die Versionsgeschichte durchklicken zu müssen. Auf dieses Archiv kann ja ggf. in (einer Ecke) der Sitenotice selber Verlinkt werden. - Aklex (Diskussion) 03:36, 17. Nov. 2021 (CET)
21. Ich kann da nur den vorherigen Meinungen zustimmen BlauesSerpiroyal ^Diskussion 17:51, 17. Nov. 2021 (CET)

Nein, die Sitenotice soll nicht für Mitteilungen genutzt werden

1. ist für mich der falsche Weg zur Nutzung des Sitenotice. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:08, 3. Nov. 2021 (CET)
2. Mich stört der Kasten generell. Wenn sich der Inhalt sogar noch immer verändert, würde der mich ständig ablenken und die Informationen bekomm ich sehr wahrscheinlich auch über einen anderen Weg, z. B. über die Hauptseite, mit. --Poffel — Diskussion 10:41, 3. Nov. 2021 (CET)
3. So wie ich das Chattreffen in Erinnerung habe war die Idee die Sitenotice nahezu dauerhaft besetzt zu haben - mit irgendwelchen Sachen zum Wiki und oftmals sogar durchrotierend. Das ist für mich der falsche Weg, denn dann fällt sie für das, was tatsächlich relevant ist, nicht mehr auf. --Datei:Sugimori 672.pngMecanno-man^Mäh 11:55, 3. Nov. 2021 (CET)
4. Also das Durchwechseln halte ich schonmal für keine gute Idee, da mich das persönlich ziemlich stören würde. Generell tendiere ich auch eher dazu, die Sitenotice nicht dafür zu nutzen, sondern das an anderer Stelle unterzubringen. Einzige Ausnahme wären große Änderungen/Neuerungen, bei denen man der Meinung ist, dass wirklich so ziemlich jeder Benutzer davon wissen sollte, da könnte man die Sitenotice dann für nutzen, da die wahrscheinlich tatsächlich früher oder später von jedem wahrgenommen wird. Also zusammengefasst: temporär für große Änderungen vielleicht, dauerhaft nein. Ratequaza 12:35, 3. Nov. 2021 (CET)
5. Wenn wir die Sitenotice zu inflationär benutzten, ignorieren sie die Leute irgendwann. In so einem Fall hätten wir uns ein nützliches Werkzeug kaputt gemacht.-MfG, Kenaz-Hagalaz ^Disku 11:21, 4. Nov. 2021 (CET)

Kommentare

Ein Ping in die große Runde. @Buoysel, Cliffichen, CLina, DeXter, DieTaube, Feblue, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Mooni000, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, Vircaprae, AAWiki, Aklex, Bennett, BeyJim, BlauesSerpiroyal, DaneeBound, DeepSpace, Der Sternendiamantritter, Flonc, Ediz, Goloer444, Jass, K0pplosio, Lasagne, Mario-WL, Nescientist, Panflami, Pk-fan, Poffelino, PokeMaestro, PokéSpe, Ratequaza, Red Bull Salzbourg, Vaultysworld, Zeynex: -- ~~ feblue 09:54, 3. Nov. 2021 (CET)

Ganz blöde Frage, aber was ist denn mit Sidenotice überhaupt gemeint? Das Bildbanner oben? Maxmiran 16:47, 3. Nov. 2021 (CET)

@Maxmiran: Das ist die Sitenotice; aktuell ist sie leer, aber in der Versionsgeschichte sind noch die ganzen alten Version. Das ist der Banner, in dem wir für gewöhnlich auf Gewinnspiele aufmerksam machen. Ist halt einfach ein Platz im Skin, an dem man eine bestimmte Nachricht laden kann, die über diese Systemseite definiert wird. Bei uns ist das im Bereich oben über der Suche bis links zum Logo. Und da können wir halt reinschreiben, was wir wollen. -- RobbiRobb 17:05, 3. Nov. 2021 (CET)

So wie die Abstimmung aktuell gestaltet ist tue ich mich sehr schwer irgendwie abzustimmen denn wie auch schon die bisherigen Antworten zeigen ist es kein einfaches ja/nein. Was ich grundsätzlich aus UX-Sicht sagen kann: Wenn das Ding jederzeit sichtbar ist, gehen Änderungen unter. Das was die Sitenotice aktuell auszeichnet ist ihr vorhandensein ("Da ist was neues"), dadurch fällt sie auf. Ist sie dauerhaft sichtbar gehen rein textuelle Änderungen sehr viel leichter unter bzw fallen nicht so stark ins Auge. Deshalb bin ich klar dagegen sie dauerhaft einzublenden. Auf der anderen Seite nutzen wir die Sitenotice aktuell recht selten (fast nur im Rahmen von Releases, die üblicherweise eh nur in der zweiten Jahreshälfte liegen). Deshalb bin ich andererseits auch klar dafür das Ding häufiger zu nutzen und warum dann nicht um auf größere Änderungen oder auf Diskussionen aufmerksam zu machen, bspw die Einführung der Stellenausschreibungen? Wie gesagt, weder ein klares ja noch klares nein meinerseits. Jones ^Albtraum? 22:00, 3. Nov. 2021 (CET)

Etwas was mir im Verlaufe des Abends aufgefallen ist, ist dass es (logischerweise) noch kein offizielles Konzept gibt, wie das ganze aussehen soll - und das sicherlich einige Wahlentscheidungen erklärt. Bspw. das Problem, dass die Auffälligkeit verloren geht, wenn es einfach immer im gleichen Stil verfasste Text-Nachrichten sind. Hier kann es denke ich abhilfe schaffen, wenn man mit Farben und vielleicht sogar Bildern/Icons spielt. Bislang hatte die Nachricht immer ein blasses blau als Hintergrund, ich denke man kann hier mit ähnlichen aber doch anderen Farben sicherlich den gewünschten Neuerungs-Effekt erzielen. Ein Icon für jeden Inhalt kann sicherlich auch nicht schaden, wobei sich natürlich nicht garantieren lässt, dass sich auch wirklich immer etwas findet. Muss man denke ich situationsbedingt entscheiden. Außerdem ist es zumindest auch nicht mein Ziel, die Sitenotice permanent zu halten. Das ganze soll dazu dienen, Neuigkeiten anzukündigen. Wenn etwas nicht mehr neu ist, kommt es raus. Und wenn es gar keine Neuigkeiten gibt, kann man auch einfach die gesamte Sitenotice entfernen, bis es wieder einen Grund zur Benachrichtigung gibt. Das wird nicht schaden, dort vorrübergehend keine Nachricht zu haben. Vielleicht wirkt es sich sogar positiv aus. Nur damit das gesagt ist, nicht dass hier jetzt jemand denkt, man müsste um jeden Preis dort permanent eine Nachricht drin haben. Wir haben nichts davon, Monate alte Nachrichten als neu zu verkaufen. -- RobbiRobb 00:25, 4. Nov. 2021 (CET)

@Kernseife: Da du jetzt zu den Stimmberechtigen Benutzern gehörst, darfst du ebenfalls an dieser Abstimmung teilnehmen. -- RobbiRobb 13:51, 5. Nov. 2021 (CET)

@Heikolino1010: Du darfst ebenfalls an der Abstimmung teilnehmen ^^ -- RobbiRobb 02:58, 6. Nov. 2021 (CET)

Iden die (möglicherweise) Nützlich sein könnten

Also… Das Pokéwiki hat mir in Sachen Pokémonspiele ECHT gute Dienste geleistet

und es tut mir leid falls das hier eine Vollkommen Unnsinnige und dumme Idee ist und hier kommt meine Idee :

Warum machen wir nicht mal Anleitungen z.b. Erstes Dyna-Raid oder Wie du am besten den arenaleiter … Besiegst und warum nicht auch einen Bereich wie die hilfeseite draus machen den man separat durchsuchen kann und/oder man könnte Theoretisch auch einen Habitat-Bereich machen wo man dann zum Beispiel Hokumil eingibt und dann bekommt man auf einer KARTE angezeigt wo man es im Spiel findet am besten wäre die Karten nach Generationen sortiert SO endlich habe ich mir meine Ideen von der Seele geschrieben… BlazeLight (piep) (Diskussion) 14:33, 13. Nov. 2021 (CET)

Hey BlazeLight, ich verstehe deine Ideen recht gut, aber Guides und ähnliches sind eher nicht Teil des Wikis. Das Wiki dient dazu, Informationen gebündelt an einer Stelle zu sammeln, nicht aber dazu, Handlungsempfehlungen für deine genannten Beispiele auszusprechen. ^^ -- ~~ feblue 17:19, 13. Nov. 2021 (CET)

Links auf Weiterleitungen

Aufgrund von Taisukes letztem Hinweis möchte ich ganz gerne nochmal ein Thema ansprechen, was mir schon länger immer mal wieder auffällt: Aktuell besteht der Wunsch/die Regel Links auf Weiterleitungen und BKLs zu ersetzen durch den eigentlichen "Ziellink". Bei BKLs macht das eindeutig Sinn, hier ist es eindeutig - entweder man möchte explizit auf andere Nutzungen verweisen oder es ist ein gezielter Artikel gewollt, ergo macht das Ersetzen Sinn. Bei "reinen" WLs (also zB Faunastatue => Flora-Statue) macht es mMn keinen Unterschied (WLs mit Falschschreibung mal ausgenommen), hier ist mir das Ersetzen ehrlicherweise egal, von mir aus kann man bei der aktuellen Regelung bleiben. Der Punkt, um den es mir eher geht, sind WLs auf Abschnitte, also bspw Hürdenlauf. Hier finde ich aus vielerlei Gründen, insbesondere Wartbarkeit, dass Links auf diese WLs weitaus sinnvoller sind, als in jedem Artikel separat auf den Abschnitt zu verlinken. Das Problem an solchen Links ist einfach, das die Anker an den Überschriften festgemacht werden. Wird nun der Abschnitt umbenannt, sind die Anker fehlerhaft (bzw funktionieren nicht mehr). Leider bietet MediaWiki hier keine Suche für, daher ist die Anpassung der Links recht aufwendig. Beschränkt man sich auf die WLs ist das Ganze um eine Komplexitätsstufen einfacher (und mit überschaubaren Aufwand auch via Bot ermittelbar). Auch finde ich zumindest es für den Autor passender einfach die WL herzunehmen, ansonsten ist es auch oft genug schon vorgekommen, das nicht der Anker-Link genommen wird, sondern nur der Zielartikel (also sowas wie [[Pokéathlon|Hürdenlauf]]). Alles in allem seh ich aktuell keinen Grund, der gegen solche WLs spricht, dafür jedoch einige, die dafür sprechen. Daher die Anregung hier die Regelung anzupassen und im Falle von Anker-Links mehr auf WLs als auf Direkt-Links zu gehen. Jones ^Albtraum? 13:40, 15. Nov. 2021 (CET)

Ich finde, dass das gar keine schlechte Idee ist. Es wird wahrscheinlich nur unfassbar aufwendig sein, all die Anker zu finden, die nicht mehr funktionieren / bei denen es wert ist, sie durch eine Weiterleitung zu ersetzen, aber das wäre halt ein Mehraufwand, den man angehen könnte. Im Sinne der Wartbarkeit auch ein riesiger Pluspunkt. -- ~~ feblue 14:31, 15. Nov. 2021 (CET)

Ein erster Schritt wäre ja schon die existierenden da zu lassen ;) Bei den WLs habe ich das vor einigen Jahren schonmal ausgebessert, bei Links könnte man mit einer Änderung der Regelung ja denselben Weg gehen wie aktuell: Wenn wer nen Artikel bearbeitet und einen Anker-Link findet ersetzt ihn durch ne WL (wo es eine gibt oder es Sinn macht eine anzulegen. Wird vermutlich auch Fälle geben wo eine WL keine Berechtigung hat, die bleiben dann entsprechend Anker-Links). Gezielt jetzt alle zu suchen und zu ersetzen ist mMn nicht notwendig. Jones ^Albtraum? 16:24, 15. Nov. 2021 (CET)

Pro von mir. ...wüsste aber ehrlichgesagt nicht, wo wir irgendwo niedergeschrieben haben, dass nicht auf WLs verlinkt werden soll (Hauptseite ausgenommen). Wäre demnach froh zu wissen, auf welche „Regelung“ du dich hier beziehst, Jones. Mein Stand ist nämlich, das wir genau deinen Vorschlag schon vor neun Jahren beschlossen haben. --Datei:Sugimori 672.pngMecanno-man^Mäh 19:27, 15. Nov. 2021 (CET)

Siehe auch-Abschnitte im gesamten Wiki

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)