PokéWiki:Allgemeine Diskussionsseite: Unterschied zwischen den Versionen

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Zeile 655: Zeile 655:
# Ich stimme den vorherigen Enthaltungen zum Großteil zu und hab nicht wirklich etwas hinzuzufügen [[Benutzer: BlauesSerpiroyal|BlauesSerpiroyal]] [[Datei:Pokémon-Icon_497_SW.png]][[Benutzer Diskussion:BlauesSerpiroyal|<sup>Diskussion</sup>]] 10:58, 11. Mär. 2022 (CET)
# Ich stimme den vorherigen Enthaltungen zum Großteil zu und hab nicht wirklich etwas hinzuzufügen [[Benutzer: BlauesSerpiroyal|BlauesSerpiroyal]] [[Datei:Pokémon-Icon_497_SW.png]][[Benutzer Diskussion:BlauesSerpiroyal|<sup>Diskussion</sup>]] 10:58, 11. Mär. 2022 (CET)
#Nach einigem hin und her bei all den Argumenten hier wo ich mich für keine Seite entscheiden kann denke ich, das eine Enthaltung für mich das beste wäre [[Datei:Pokémonsprite 399 Feld West HGSS.gif|link=|30xpx]] <span style="font-family: comic sans;">Ich kam, sah und bearbeitete</span> [[Benutzer:Bennett|Bennett]] <sup>[[Benutzer Diskussion:Bennett|Diskussion]]</sup> 20:11, 11. Mär. 2022 (CET)
#Nach einigem hin und her bei all den Argumenten hier wo ich mich für keine Seite entscheiden kann denke ich, das eine Enthaltung für mich das beste wäre [[Datei:Pokémonsprite 399 Feld West HGSS.gif|link=|30xpx]] <span style="font-family: comic sans;">Ich kam, sah und bearbeitete</span> [[Benutzer:Bennett|Bennett]] <sup>[[Benutzer Diskussion:Bennett|Diskussion]]</sup> 20:11, 11. Mär. 2022 (CET)
# Ich kann nicht einschaetzen, wie die Arbeitslast bei den wirklich relevanten Leuten ist, daher moechte ich nicht gleichgewichtet in die Diskussion eingehen wie die, die es betrifft. Ausserdem bin ich allgemein gegen zu viele Regeln, waere also vermutlich auch sonst ne Enthaltung. [[Benutzer:Nescientist|Nescientist]] ([[Benutzer Diskussion:Nescientist|Diskussion]]) 19:25, 15. Mär. 2022 (CET)


==== Pings ====
==== Pings ====
@[[Benutzer:Buoysel|Buoysel]], [[Benutzerin:Cliffichen|Cliffichen]], [[Benutzer:CLina|CLina]], [[Benutzer:DeepSpace|DeepSpace]], [[Benutzer:DeXter|DeXter]], [[Benutzer:DieTaube|DieTaube]], [[Benutzer:Feblue|Feblue]], [[Benutzer:GoPika|GoPika]], [[Benutzer:GrollenKette951|GrollenKette951]], [[Benutzer:Impoleon xy|Impoleon xy]], [[Benutzer:Isso08-15|Isso08-15]], [[Benutzer:Jones|Jones]], [[Benutzer:Kenaz-Hagalaz|Kenaz-Hagalaz]], [[Benutzer:Lombrero|Lombrero]], [[Benutzer:Luca12379|Luca12379]], [[Benutzer:Matze|Matze]], [[Benutzer:Maxmiran|Maxmiran]], [[Benutzer:Mecanno-man|Mecanno-man]], [[Benutzer:Mooni000|Mooni000]], [[Benutzer:Poffelino|Poffelino]], [[Benutzer:RobbiRobb|RobbiRobb]], [[Benutzer:Ryuichi|Ryuichi]], [[Benutzer:ShortyBuzz|ShortyBuzz]], [[Benutzer:Simonsees|Simonsees]], [[Benutzer:SwowoJonny|SwowoJonny]], [[Benutzer:Taisuke|Taisuke]], [[Benutzer:Vircaprae|Vircaprae]] [[Benutzer:AAWiki|AAWiki]], [[Benutzer:Arkany|Arkany]], [[Benutzer:Bennett|Bennett]], [[Benutzer:BeyJim|BeyJim]], [[Benutzer:BlauesSerpiroyal|BlauesSerpiroyal]], [[Benutzer:DaneeBound|DaneeBound]], [[Benutzer:DarkOkto|DarkOkto]], [[Benutzer:Der Sternendiamantritter|Der Sternendiamantritter]], [[Benutzer:Ediz|Ediz]], [[Benutzer:Goloer444|Goloer444]], [[Benutzer:Heikolino1010|Heikolino1010]], [[Benutzer:Jardan|Jardan]], [[Benutzer:Jass|Jass]], [[Benutzer:Kernseife|Kernseife]], [[Benutzer:Lasagne|Lasagne]], [[Benutzer:DasLunalein|DasLunalein]], [[Benutzer:Mario-WL|Mario-WL]], [[Benutzer:Nescientist|Nescientist]], [[Benutzer:Panflami|Panflami]], [[Benutzer:PokeMaestro|PokeMaestro]], [[Benutzerin:PokéSpe|PokéSpe]], [[Benutzer:Ratequaza|Ratequaza]], [[Benutzer:ScNoni|ScNoni]], [[Benutzer:Vaultysworld|Vaultysworld]] --''[[Datei:Sugimori 672.png|25px|link=]]'''[[Benutzer:Mecanno-man|<span style="color:#008B45;font-family:ka">Mecanno-man</span>]]'''<sup>[[User talk:Mecanno-man|<span style="color:#8B5A2B;font-family:Segoe Print">Mäh</span>]]</sup>'' 23:15, 6. Mär. 2022 (CET)
@[[Benutzer:Buoysel|Buoysel]], [[Benutzerin:Cliffichen|Cliffichen]], [[Benutzer:CLina|CLina]], [[Benutzer:DeepSpace|DeepSpace]], [[Benutzer:DeXter|DeXter]], [[Benutzer:DieTaube|DieTaube]], [[Benutzer:Feblue|Feblue]], [[Benutzer:GoPika|GoPika]], [[Benutzer:GrollenKette951|GrollenKette951]], [[Benutzer:Impoleon xy|Impoleon xy]], [[Benutzer:Isso08-15|Isso08-15]], [[Benutzer:Jones|Jones]], [[Benutzer:Kenaz-Hagalaz|Kenaz-Hagalaz]], [[Benutzer:Lombrero|Lombrero]], [[Benutzer:Luca12379|Luca12379]], [[Benutzer:Matze|Matze]], [[Benutzer:Maxmiran|Maxmiran]], [[Benutzer:Mecanno-man|Mecanno-man]], [[Benutzer:Mooni000|Mooni000]], [[Benutzer:Poffelino|Poffelino]], [[Benutzer:RobbiRobb|RobbiRobb]], [[Benutzer:Ryuichi|Ryuichi]], [[Benutzer:ShortyBuzz|ShortyBuzz]], [[Benutzer:Simonsees|Simonsees]], [[Benutzer:SwowoJonny|SwowoJonny]], [[Benutzer:Taisuke|Taisuke]], [[Benutzer:Vircaprae|Vircaprae]] [[Benutzer:AAWiki|AAWiki]], [[Benutzer:Arkany|Arkany]], [[Benutzer:Bennett|Bennett]], [[Benutzer:BeyJim|BeyJim]], [[Benutzer:BlauesSerpiroyal|BlauesSerpiroyal]], [[Benutzer:DaneeBound|DaneeBound]], [[Benutzer:DarkOkto|DarkOkto]], [[Benutzer:Der Sternendiamantritter|Der Sternendiamantritter]], [[Benutzer:Ediz|Ediz]], [[Benutzer:Goloer444|Goloer444]], [[Benutzer:Heikolino1010|Heikolino1010]], [[Benutzer:Jardan|Jardan]], [[Benutzer:Jass|Jass]], [[Benutzer:Kernseife|Kernseife]], [[Benutzer:Lasagne|Lasagne]], [[Benutzer:DasLunalein|DasLunalein]], [[Benutzer:Mario-WL|Mario-WL]], [[Benutzer:Nescientist|Nescientist]], [[Benutzer:Panflami|Panflami]], [[Benutzer:PokeMaestro|PokeMaestro]], [[Benutzerin:PokéSpe|PokéSpe]], [[Benutzer:Ratequaza|Ratequaza]], [[Benutzer:ScNoni|ScNoni]], [[Benutzer:Vaultysworld|Vaultysworld]] --''[[Datei:Sugimori 672.png|25px|link=]]'''[[Benutzer:Mecanno-man|<span style="color:#008B45;font-family:ka">Mecanno-man</span>]]'''<sup>[[User talk:Mecanno-man|<span style="color:#8B5A2B;font-family:Segoe Print">Mäh</span>]]</sup>'' 23:15, 6. Mär. 2022 (CET)

Version vom 15. März 2022, 20:25 Uhr


Zentrale Hinterlegung von Trainerdaten

→ Hauptseite: Zentrale Hinterlegung von Daten

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

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! msnsorry.gif

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

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-manMä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-manMä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-manMä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.pngPL ~ 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-manMä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.pngPL ~ 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.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 16:51, 7. Mär. 2021 (CET)

Parameter für Königsformen in Pokémon-Legenden: Arceus

Mit dem Erscheinen von Pokémon Legenden Arceus sind wieder neue Pokémonformen eingeführt und es geht wieder darum, ob sie einen eigenen Parameter bekommen. Königsformen werden momentan als Formen mit einem eigenen Parameter gelistet, allerdings denke ich, dass sie doch zu ähnlich zu den normalen Pokémon sind, als dass sie einen eigenen Parameter bräuchten. Die einzigen Punkte in denen sie sich unterscheiden sind Größe, Gewicht und Sprites. Da aber alles Andere identisch ist und die Könige nicht vom Spieler erhältlich sind, sehe ich eigentlich keinen Grund ihnen einen eigenen Parameter zu geben, wenn Herrscher-Pokémon auch nicht separat gelistet werden. Des Weiteren sollte auch beachtet werden in welchen Artikeln die Parameter für die Königspokémon würden, denn das wäre hauptsächlich bei den Orten und Attacken. Da ich sowieso plane die Königspokémon aus den Learnset-Tabellen zu streichen, würden sie letztenendes nur bei den Orten verwendet werden. Die Frage wäre dann halt was man mit den Sprites machen würde und wo die liegen sollten. Ich würde deshalb gerne noch ein paar mehr Meinungen hören. -- Mooni000 Pelipper-Post 11:26, 2. Feb. 2022 (CET)

So wie ich es Verstehe gibt es wohl eigenständige Learntabels (auch wenn dies ggf. ident sind). Die Formen werden in den Dumps separat gelistet, auch unterscheiden sich die Formen in Optik, Größe und Gewicht. Für mich wären Sie also gleichzusetzten mit anderen Formen die wir aufgelistet haben. Ich bin der Meinung die Streichung der Form kann schneller erfolgen wie sie ggf. Nachträglich wieder überall hinzuzufügen. Ich erwarte z.B. in nächster Zeit ein Update für HOME was PLA und SDLP kompatibel macht. Dann sieht man es z.B. genauer. Auch kann ich mir sehr gut Vorstellen das Sie in einem Anime oder Manga besonders hervorgehoben werden könnten. Ja derzeit viel Konjunktiv. Nur wie gesagt ich denke es ist sinnvoller die Daten aufgrund der derzeitigen Faktenlage gesplittet zu betrachten bis wir da weitere Informationen haben. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:49, 2. Feb. 2022 (CET)
Ausbinden aber erstmal als Option lassen, sie wieder zu verwenden, scheint mir ebenfalls am sinnvollsten. Grundsätzlich haben wir ja eigentlich Zeit das zu entscheiden bis wir die nächsten Formen von den Pokémon mit Königsformen kriegen - also wahrscheinlich mind. bis zum nächsten Hauptspiel. Würde sagen nichts überstürzen. --Datei:Sugimori 672.pngMecanno-manMäh 22:13, 3. Feb. 2022 (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.-- 260.png 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. --PoffelDiskussion 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.pngPL ~ 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! Pokémon-Icon_674.png 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.pngPL ~ 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: DeepSpaceDiskussionBeiträge)

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 ^^"Lugia 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, Gold Echo, Kaneros, Kirby aka Siss, KR7907, Kurapikachu, 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

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.pngPL ~ 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.pngPL ~ 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.pngPL ~ 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-manMä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.pngPL ~ 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-manMä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-manMä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. ~ 418.gif Buoysel 15:17, 9. Jun. 2021 (CEST)
Ich gebe hier dann auch einfach mal schnell meinen Senf dazu drop.gif 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? Pokémon-Icon_674.png 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-manMä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-manMä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-manMä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:


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

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

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

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.pngPL ~ 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.pngPL ~ 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-manMä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.pngPL ~ 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.pngPL ~ 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 02.05.2024 00:37 Uhr.

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

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? Pokémon-Icon_674.png 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-manMä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.pngPL ~ 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-manMä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-manMä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.pngPL ~ 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-manMä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 SystemWikipedia-Icon(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.pngPL ~ 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)

Unsere Lizenzvorlagen

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

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

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

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

Umbenennung der Artikel DV und AV

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

Deutsches Wiki = Deutsche Begriffe. Hat mein Pro * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 14:44, 21. Feb. 2022 (CET)
Die Problematik ist leider etwas grösser: Es sind nämlich nicht nur die zwei von Isso angesprochenen Werte, sondern auch noch „Basiswerte“ und „Artenspezifische Stärken“ nicht auf dem offiziellen Titel. Soweit ich verstehe ist das was wir aktuell als Basiswerte bezeichnen die artenspezifischen Stärken, während das was wir aktuell auf Fleiß-Punkte haben offiziell die Basiswerte sind. Insbesondere die plötzliche Verschiebung von „Basiswerte“ vom einen zum anderen (welches dann nicht mehr länger eine Basis ist!) würde wahrscheinlich relativ schnell zu negativer Kritik und auf längere Dauer wahrscheinlich zu grundlegender Verwirrung in der deutschsprachigen Community führen, da dieser Begriff nicht wirklich logisch ist und die meisten wahrscheinlich den alten Fanbegriff weiternutzen würden, was Neulingen den Einstieg erschwert. Generell bin ich zwar dafür die offiziellen Begriffe zu nutzen und dann halt mit dem Ergebnis des Chaos zu leben, doch denke ich muss man hier etwas genauer überlegen ob man das wirklich will. --Datei:Sugimori 672.pngMecanno-manMäh 22:15, 23. Feb. 2022 (CET)
Ich bin da bei Mec, gerade DV sind in der Pokémon-Community so fest verankert weil es eben jahrelang keinen offiziellen Begriff dazu gab. Lediglich die Bezeichnung auf der Pokémonseite scheint mir erstmal noch nicht genug. Ich würde bei einer so weitreichenden Veränderung erstmal noch die 9.Generation abwarten und schauen ob es ab dem Zeitpunkt auch in den Spielen einen offizieller Begriff geben wird und auch im nachhinein klar kommunizieren, dass dies nun die DV sind bzw ehemals DV genannt wurden. BeyJim Diskussion 20:59, 7. Mär. 2022 (CET)
Ryuichi konnte auf Discord zeigen, dass diese Begriffe ab der 7. Generation auch in Lösungsbüchern Einzug fanden. Weswegen scheinbar mehr Leute zu einer Verschiebung tendieren, wobei die jetzt verwendeten Begriffe als WL bleiben sollen. Das könnte Aufwand nach sich ziehen. Was halten die Strategen unter uns davon? @Poffelino, Luca12379: Das Isso 08/15 Konter 11:28, 9. Mär. 2022 (CET)
Ich stelle mir die Umsetzung im Strategie-Projekt schwierig vor. Im Moment wird Basiswerte in der in einigen Artikeln verwendet. In jedem Artikel müsste das ersetzt werden. Das ist viel Aufwand mit einem kaum vorhandenen Nutzen und sorgt für Verwirrung, während nicht alles ersetzt ist, und wahrscheinlich auch danach. Da die Strategie sehr an die englischen Begriffe gebunden. FP/DV sind genau die Äquivalente zu EV/IV. Die offiziellen Begriffe haben übersetzt eine andere Bedeutung. Auch wären einige Vorlagen betroffen. Beispielsweise ist in Moveset nicht genug Platz, um die voll ausgeschriebenen Begriffe aufzuschreiben. Außerdem müsste eine Lösung für Vorlagenparameter gefunden werden, was dann wahrscheinlich auch andere Bereiche im Wiki betrifft. --PoffelDiskussion 23:31, 10. Mär. 2022 (CET)

Moratorium auf Rang-Wahlen während Spielreleases

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

Abstimmung

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

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

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

Nein, Wahlen sollen weiterhin immer gestartet werden können

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

Enthaltung

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

Pings

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