PokéWiki:Allgemeine Diskussionsseite

Aus PokéWiki
Version vom 31. August 2021, 17:03 Uhr von GrollenKette951 (Diskussion | Beiträge) (Auf richtige Seite verchoben)
Zur Navigation springen Zur Suche springen


Zentrale Hinterlegung von Trainerdaten

Hab mir vor kurzem überlegt das es eigentlich unsinnig ist sowohl Vorlage:Team/Kopf als auch Vorlage:Orte Trainer/Kopf zu haben, da beide schlussendlich in etwa dasselbe machen. Bei der Idee, einfach im Charaker-Projekt die Orte-Vorlage zu nutzen ist mir dann aufgefallen, das es mehr Sinn machen würde, die Daten einfach in einem Artikel zu hinterlegen und dann daraus in die anderen zu ziehen. Ich würde deshalb vorschlagen, die ganzen Daten in den Orten und bei Charakteren aus den Trainer-Unterseiten zu ziehen, und da in nem includeonly ne Vorlage drum zu bauen, das man über nen Parameter auswählen kann welchen Trainer man haben möchte. Die tatsächliche technische Umstrukturierung würde ich aber vorschlagen nur Stück für Stück zu machen, da das nicht wirklich iwas is, was all zu wichtig ist. Wollte demnach nur mal fragen ob hier jemand grundsätzlich dagegen ist, insbesondere @GoPika, Cliffichen, Ryuichi und SortyBuzz, sowie RobbiRobb, an dem das ganze wahrscheinlich hängen bleiben wird... --Datei:Sugimori 672.pngMecanno-manMäh 17:46, 27. Feb. 2020 (CET)

Erstmal, der Name SortyBuzz gefällt mir grin.png. Dann kann ich mir nicht wirklich vorstellen, wie das funktioniert mit der von dir angesprochenen Datenhinterlegung über includeonly und Parameter. Aus diesem Grund kann ich mich noch nicht zu 100 % dafür aussprechen, wobei ich den Vorschlag nicht schlecht finde. Kann man dort auch irgendwie Vorlage:Berühmte Trainer und/oder Vorlage:Weitere Trainer einbinden? -- Cliffichen 22:56, 28. Feb. 2020 (CET)
Ne das geht nicht, es geht mir nur drum das die Orte/Trainer nicht an drei Orten mit identscher Befüllung steht. --Datei:Sugimori 672.pngMecanno-manMäh 23:06, 28. Feb. 2020 (CET)
An und für sich habe ich nichts dagegen einen Zentralen Platz zu schaffen von dem aus die Daten abgegriffen werden können, ob dieses dann auch funktioniert ist die andere Frage. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 23:31, 28. Feb. 2020 (CET)
Ich finde schön, dass schon davon ausgegangen wird, dass ich das übernehme. Das aber erst mal beiseite, ich halte es grundsätzlich für umsetzbar. Mit includeonlys und onlyincludes dürfte sich eine Struktur erstellen lassen, mit der sich alle Daten zentral an einem Ort lagern und in anderen Artikeln aufrufen lassen. Ich sehe allerdings zwei Probleme: Das System ist sehr anfällig, ein kleiner Fehler in den Konstrukten und es werden mehr als eine Seite zerlegt. Das führt auch gleich zum zweiten Problem: Einsteigerfreundlich sieht anders aus. Neue Nutzer werden schwierigkeiten haben, den Ursprung eines Fehler zu finden, helfen dadurch entweder gar nicht oder machen irgendwas anderes, um vielleicht doch noch ihr Ziel zu erreichen. In jedem Fall besteht die Gefahr, dass dabei ordentlich was schief geht. Sofern man aber bereit ist, dieses Risiko einzugehen, denke ich, dass man damit durchaus einen Gewinn haben könnte, da Daten dann global gleich sind. Vielleicht wäre es hier aber besser, noch in eine andere mögliche Richtung zu forschen, ob man die Daten nicht besser hinterlegen könnte. Wobei dann fragwürdig ist, ob es etwas gibt, dass sich leicht bedienen lässt und trotzdem in der Lage ist, unsere Daten zu speichern. -- RobbiRobb 23:33, 29. Feb. 2020 (CET)
So rein konzeptionell fällt mir keine Idee ein, auch nicht iwie mit externer Datenbank oder sowas, womit man die Daten von mehreren Orten aus ändern kann, ausser nem Bot der iwie auf Änderungen an der Vorlage achtet. Das halte ich aber für keine gute Idee. Demnach haben für mich alle potenziellen anderen Lösungen die von dir angesprochenen Userfreundlichkeits-Nachteile ebenfalls. Bezüglich das mit den mehreren Seiten kaputtmachen, ja das stimmt, gäbe es denn irgendwelche anderen Lösungen, die das umgehen und realistisch in der Umsetzung sind? --Datei:Sugimori 672.pngMecanno-manMäh 23:53, 29. Feb. 2020 (CET)
Die WMF-Extension LabeledSectionTransclusion könnte für so ein Unterfangen vermutlich hilfreich sein, und ist auch nicht allzu komplex. Das ermöglicht es, innerhalb einer Seite mehrere "benannte Onlyinclude" zu erstellen und per Parserfunktion einzubinden. Dadurch dürfte das Gesamtkonstrukt auch weniger fehleranfällig sein.
Eine umfangreiche Datenbanklösung neu aufzubauen (Zum Beispiel mit Wikibase, vermutlich alternativ mit Semantic MediaWiki oder Cargo) halte ich mit unseren personellen und technischen Ressourcen für unrealistisch, und wäre wenn ein Projekt, bei dem man sich mit Bulba kurzschließen sollte. Das Thema haben wir ja vor etwa 4 Jahren schon mal diskutiert.
-- Skelabra2509 (Diskussion | Beiträge) 17:44, 8. Mär. 2020 (CET)

Da die von Skel benannete Extension nun im Wiki installiert ist, geht es jetzt an die Umsetzung des Vorhabens. Dabei stehen für mich vor allem zwei große Fragen im Raum: Wo sollen die Daten hinterlegt werden und wie gehen wir die Umsetzung an? Bei der Hinterlegung gibt es entweder die Möglichkeit, diese in den Orten zu lagern oder in den Unterseiten der Trainerklassen bzw. in den Seiten der Charaktere (da diese ja ebenfalls die selbe Behandlung erfahren sollen). Beim wie gibt es ebenfalls zwei Möglichkeiten. Entweder, es wird immer ein Ort angepasst und die Trainer/Charakter-Seiten werden jedes mal bearbeitet, wenns nötig ist, oder es wird immer eine Trainerklasse/ein Charakter bearbeitet und dann alle von diesem betroffenen Orte angepasst. In jedem Fall wird ein Teil vielfach bearbeitet werden, mit dem Ergebnis, dass sich dort die Versionsgeschichten verlängern werden. Ich würde natürlich gerne darauf verzichten, aber da die Seiten alle untereinander voneinander abhängen, kann ich nicht einfach alles fertig machen und dann speichern, das ist zu viel. Es muss also irgendwas geopert werden. Wäre dankbar, wenn das die betroffenen Projektleiter (@Cliffichen, GoPika, Mecanno-man, Ryuichi, ShortyBuzz sowie Vircaprae als Ansprechpartner im Orte-Projekt) irgendwie unter sich das wohin und wie klären könnten; andere Meinungen sind sicherlich auch willkommen. Ich werde dann wie üblich das ausführende Organ spielen. -- RobbiRobb 01:55, 21. Dez. 2020 (CET)

Ich werde hier mal wiederholen, was ich schon auf Discord geschrieben habe: Ich finde es sinnvoll, wenn die Trainerdaten auch beim Trainer-Projekt hinterlegt sind, und die Trainerlisten sind ja wie gemacht dafür. Außerdem halte ich es für sinnvoll, auch das vielfache Bearbeiten dort zu machen, da die Listen bisher in den meisten Fällen nur eine geringe Editanzahl aufweisen und die Massenedits dort in der Versionsgeschichte vermutlich nicht so stören werden. Diese Ansichten hat vor mir bereits Cliffichen so geäußert.
Auch bei den Charakteren finde ich es sinnvoll, wenn die Daten beim Charakter-Projekt hinterlegt sind und auch wenn die Mehrfach-Edits auf den entsprechenden Seiten durchgeführt werden, obwohl das dort schon eher stört. Da man gegen viele Trainer aber „nur“ zwei, drei Mal pro Spiel kämpft, hält sich das hoffentlich trotzdem in Grenzen. Es sollte noch erwähnt werden, dass einige Charaktere schon in einer Trainerliste stehen (gutes Beispiel: Pokémon-Trainer (Trainerklasse)).
Ich sehe allerdings ein Problem bei meinem Vorschlag: Wenn jemand fehlende Trainer einträgt, geht er höchstwahrscheinlich nach den Orten vor, und muss dann pro Ort mehrere Edits machen statt nur einen. Ich finde aber trotzdem, dass man das so machen sollte, das mit den Edits ist dann halt so. – Vircaprae 03:52, 21. Dez. 2020 (CET)
@Robbi so richtig verstehe ich das noch nicht mit Massenedit. Könntest du mal ein zwei Beispiele im Testwiki machen damit das für mich nachvollziehbar wird. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 06:47, 21. Dez. 2020 (CET)
Schliesse mich hier Vir an. Da das ganze wahrscheinlich einiges an komplizierter Syntax erzeugt, welche so gut wie unbemerkt kaputt gemacht werden kann, fände ich es allerdings sinnvoll wenn alle Trainerklassen Unterseiten erhalten wo die Daten hergezogen werden, auch wenn es davon nur einen oder zwei Trainer gibt - iwie die Wissenshüterin und so.
Reihenfolge ist mir Wurst; Versionsgeschichten wirds spammen, wo is dann imo. auch egal. Was mir dabei allerdings wichtig wäre ist das aktuelle Diskrepanzen irgendwie getrackt werden; entweder beim botten oder im voraus. --Datei:Sugimori 672.pngMecanno-manMäh 17:27, 21. Dez. 2020 (CET)
Hm, ich glaube inzwischen, dass sich das Problem mit den Massenedits mehr oder weniger gelöst hat, oder zumindest weiß ich nicht mehr, warum ich das als Problem gesehen habe, denn im Moment weiß ich nicht mal mehr, wieso die überhaupt zustande kommen sollten. Ist aber im Endeffekt auch egal, wenns passiert, wirds vermutlich keinen Weg drumherum geben und wenn doch, möge man mich im Zweifel stoppen. Und um mich hier noch mal eben auf Mec zu beziehen, damit hier niemand verwirrt ist: Es wird nix gebottet, das ist Handarbeit. -- RobbiRobb 22:58, 21. Dez. 2020 (CET)


Der Punkt durch sich im Chattreffen vom 06.03.2021 angesehen. Hauptproblematik ist die Verwendung von Togglern innerhalb der Vorlagen mit Abweichenden Togglern. Bsp. Trainer in Alola sind zwischen SM und USUM getoggled und im Trainerprojekt separate seiten. Der Punkt bleibt erstmal offen bis wir uns überlegt haben von WO aus wir die Daten ziehen (Charakter, Trainer, Ort) und Kapazitäten haben diese Vorlage über die anderen Projekte zu verteilen. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:51, 7. Mär. 2021 (CET)

Ich habe mir mal das ganze angesehen und Überlegt wie wir das ganze Ausgestalten könnten. Vielerorts ist die Verwendung von Togglern sinnvoll die daher generell zu streichen fände ich den Falschen Weg. Wäre es nicht eine Überlegung das wir eine zusätzliche Seite machen. Bsp. Trainerdaten - Spielname dort listen wir rein die Daten und nummerieren Sie durch. Bsp:
== Trainernummer 0001 - Tali (Route 1, Starter Bauz, Kampf 1) ==
<section begin=NR-0001_Gewinn />100<section end=NR-0001_Gewinn />
<section begin=NR-0001_Trainerklasse />Pokémon-Trainer<section end=NR-0001_Trainerklasse />
<section begin=NR-0001_Trainername />Tali<section end=NR-0001_Trainername />
<section begin=NR-0001_Name />[[Tali]]<section end=NR-0001_Name />
<section begin=NR-0001_d1 />728<section end=NR-0001_id1 />
<section begin=NR-0001_lvl1 />5<section end=NR-0001_lv1 />
<section begin=NR-0001_geschlecht1 />w<section end=NR-0001_geshclecht1 />
<section begin=NR-0001_fähigkeit1 />Sturzbach<section end=NR-0001_fähigkeit1 />
<section begin=NR-0001_atk1_1 />Pfund<section end=NR-0001_atk1_1 />
<section begin=NR-0001_atk1_2 />Heuler<section end=NR-0001_atk1_2 />
<section begin=NR-0001_atk1_3 />Aquaknarre<section end=NR-0001_atk1_3 />
== Trainernummer 0002 - Tali (Route 1, Starter Flamiau, Kampf 1) ==
usw. für Trainernummer 2.....
== Trainernummer 0003 - Tali (Route 1, Starter Robball, Kampf 1) ==
>usw. für Trainernummer 3.....

So könnte man in der Theorie sämtliche Daten einmal Listen und müsste die Orte Trainer umstellen so das sie sich jeden Wert falls vorhanden aus dieser Liste zieht und ansonsten auf einen Default-wert zurück fällt (Sollte ich hier einen Denkfehler haben das dies nicht geht bitte um Info. Es würde dann reichen wenn wir in den Orte Zeilen dann lediglich dies schreiben:
{{Orte Trainer/Zeile|Edition=USUM|togglershow1=ja|TrainerNr=0001}}
durch Edition=USUM würde sich die richtige Liste gezogen, Toggler könnte weiterhin definiert werden und es würde dann lediglich die Trainernummer die wir festlegen benötigt werden. Da das ganze ja reingeparsed wird sollte es mMn keine Probleme mit den Limits (Vorlageneinbindung) geben. Falls hier i.wo Denkfehler usw. bestehen bitte anmerken. Da ein solches vorgehen natürlich einen Starken umbau der Zeilenvorlage bewirken würde und so oder so Umbauarbeiten aufgrund von Mobil geplant sind und Robbi eh mal angemerkt hat diverses auszulagern würde ich diese Option gerne erst einmal abklären. So braucht es nur einmal einen riesigen Umbau. WIe sind da eure Meinungen dazu? Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:55, 29. Mär. 2021 (CEST)
Technisch klingt das für mich umsetzbar, müsste man natürlich noch mal ein paar Sachen prüfen (bspw. ob {{#if:{{lst:...}}}} auch true ist, wenn in der Section nichts steht oder die Section gar nicht existiert), aber insgesamt halte ich das für machbar. Führt aber dazu, dass wir da eine mehr oder minder strukturierte Sammlung von Daten haben und das ganze eher einer Datenbank gleich kommt als tatsächlichem Inhalt - was meiner Meinung nach nicht im Artikel-Namensraum liegen sollte, weil es schlicht und ergreifend keine Inhaltsseite ist. Demnach wäre am ehesten der Projekt-Namensraum der passende, da dieser immer noch für alle Bentuzer zugänglich ist und gleichzeitig nicht den Anspruch hat, Inhalte immer in lesbarer Form zu präsentieren. Führt aber zu dem Problem, dass vor allem neue Leute Schwierigkeiten haben werden, Fehler auszubessern, weil sie nicht nachvollziehen können, woher die Daten kommen, weshalb ja der ursprüngliche Gedanke darin bestand, die Vorlagen als ganzes einzubinden, nicht deren Parameter.
Dein Gedanke ist also vermutlich realisierbar, wird aber nicht ohne Nachteile kommen. Ich könnte damit leben, aber keine Ahnung, wie andere dazu stehen. -- RobbiRobb 17:03, 29. Mär. 2021 (CEST)
Muss hier auch sagen, dass dies nicht mehr wirklich Einsteiger-freundlich ist. Insbesondere den Vorschlag mit den IDs scheint mir eher verwirrend. Ebenfalls frage ich mich spontan gerade, ob ein ganzes Spiel hier nicht mitunter die Maximale Seitenlänge sprengen würde, sowie wie effizient es noch ist hier so viele Transclusions zu haben, da meine spontane Vermutung ist, dass diese dann alle einzeln gezogen werden würden, statt einmal als ganzes. Hab das aber nicht getestet. Grundsätzlich leben damit könnte ich, aber so wirklich ein super-Fan bin ich davon jetzt auch nicht. --Datei:Sugimori 672.pngMecanno-manMäh 14:14, 31. Mär. 2021 (CEST)
Um einmal hier weiter voran zu kommen. Tests haben gezeigt das Beispielsweise ein {{#if:{{#lst:Seitenname|Abschnittsname}}|true|false}} funktioniert und ein true/false zurückgeben wird. Verschiedene Tests haben gezeigt das die Komplette Zeile ({{Orte Trainer/Zeile}}) nur ohne die Nutzung von Toggle funktionieren würde, da wir oft an verschiedenen Stellen für den gleichen Trainer keine oder abweichende Toggle wenden. Auch gäbe es die bereits oben Angesprochene Möglichkeit einer Extraseite. Über eine einfache Subst-Vorlage könnte man dort die Daten in eine einfache Tabellenform substen um sowohl Lesbarkeit wie auch Vollständigkeit zu gewährleisten. Manko ist allerdings das es für neue User schwerer sein könnte Daten zu korrigieren. Schätze mal, das wir so mindestens 200 bis 300 Trainer auf eine Seite bekommen können (je nach Größe einer Tabelle). (Müsste man Testen wieviel Quelltext bei einer vollen Tabelle benötigt wird und hochrechnen). Beispiele finden sich dazu auch im Testwiki. Folglich gibt es hier aus meiner Sicht drei mögliche Optionen:
  1. Toggle wird aus den Kopf- und Zeilenvorlagen ausgebaut und es wird gänzlich darauf verzichtet. Bedeutet Aufsplittung in Allen Orte- und Trainerartikeln (Individuelle Wünsche müsste jeder selber bauen)
  2. Wir lassen auf Wunsch von Mec die Toggle Funktion vorerst in der Vorlage für den Standardfall Starter (wo es nicht all zu viele geben sollte). Der Fall der S2W2-Modi wird so nicht möglich sein da einzelne Modi bei einzelnen Trainern ausgelagert sind. Für den Level/Gewinn-Kram hat Virce eine Option eingebaut die solche Fälle auf 1/3 Nutzung reduzieren würde (ausnahme Trainer mit verschiedenen PKMN/Movesets). Und alle anderen Toggle für Spiele, Verschiedene S2W2-Modi (könnte durch Virces Option so oder so obsolet werden), Spielfortschirtt usw. werden die Parameter aus der Zeilen- und Kopf-Vorlage entfernt und der komplette Toggle muss (falls benötigt) in den jeweiligen Trainer- und/oder Orte-Artikeln händisch nachgebaut werden. Betrifft grob 450 Artikel die händisch neu gebaut werden müssen. Hierbei hat Mec angemerkt das wohl von Robbi die Aussage kam das normale Toggle nicht mehr verwendet werden sollen, sondern nur noch clicktoggle!? Mir ist dazu nichts bekannt.
  3. Die Ortevorlage muss so oder so auf mobil angepasst werden (folglich in jedem Artikel neu eingefügt werden) entsprechend könnte man auch {{#lst:Seitenname|Abschnittsname}} in die entsprechenden Stellen einfügen. An der Darstellung der "Datenbankseite" lässt sich arbeiten. Eine Grundidee findet sich im Testwiki. Einzig die Handhabung ist denke ich etwas Umständlich obwohl sich da bestimmt auch einfach eine Copy&Paste-Vorlage bauen lässt damit ein User zurecht kommt.
Egal wie, ob Toggler entfernen, Toggler händisch bauen oder Über eine "Datenbank-Seite" wäre überall mit Arbeit verbunden. Bei den ersten beiden Optionen ist auch zu klären welche Seite die "Quellen"-Seite und welche die "Kopie"-Seite wird. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 19:18, 20. Apr. 2021 (CEST)
Hast du geprüft, wie sich {{#if:{{#lst:Seitenname|Abschnittsname}}|true|false}} verhält, wenn die Seite nicht existiert? Ist das was, was wir überhaupt beachten müssen? Abseits davon: Meine Aussage war, dass auf den alten Toggler verzichtet werden sollte, weil er mit Klassen arbeitet. Da wir jetzt im großen Stil Klassen für das CSS nutzen, könnte das ganze Probleme bei Überschneidungen geben, das ist meiner Meinung nach etwas, was nicht riskiert werden sollte und daher nach Möglichkeit auf den alten Toggler verzichtet werden sollte. Dazu kommt auch, dass der alte Toggler einfach nicht mehr zeitgemäß ist, er funktioniert nur mit Text. Wir nutzen ihn allerdings eigentlich immer in irgendwelchen Boxen, die aussehen wie Knöpfe, anklickbar ist aber trotzdem nur der Text. Vor allem im Hinblick auf mobile Nutzer der Seite, die keinen veränderten Courser im Mouseover haben, ist das vergleichsweise unpraktisch, das ganze sollte also ersetzt werden.
Im Hinblick auf die Datenbank-Lösung wäre für mich wichtig zu wissen, wie das ganze aus den Seiten gezogen werden soll; macht die Orte Trainer/Zeile-Vorlage das automatisch, indem man ihr sagt, von wo sie das ziehen soll, oder wird die Orte Trainer/Zeile-Vorlage wie bisher mit allen Parameter eingebunden und die Werte der Parameter dann einfach aus der Datenbank gezogen? -- RobbiRobb 22:48, 20. Apr. 2021 (CEST)
Ich bin an dieser Stelle für Option 2. Option 1 scheint mir nicht all zu sinnvoll und unterscheidet sich nur minim von Option 2, Option 3 ist imo. zu Nutzerunfreundlich. Wo die Daten hin sollen? Hatte da im Kopf das wir uns da schon auf die Trainer-Unterseiten geeinigt hatten? Was die S2W2-Modi angeht - wenn wir einige Sachen togglen dann ist es imo unsinnig bei anderen Trainern Sachen nicht zu togglen, demnach bin ich an der Stelle gegen Virs aktuelle Implementation. Wahrscheinlich ist es an der Stelle am sinnvollsten einfach auch nen Toggler aussen rum zu basteln. An der Stelle die Frage: Wenn das Trainer-Projekt auch was selbst togglen will, funktioniert nen section im per-default-nicht angezeigten toggle noch für andere Seiten? --Datei:Sugimori 672.pngMecanno-manMäh 03:46, 21. Apr. 2021 (CEST)
Bei Gedankengang 3 ist es so das man mit {{Orte Trainer/Zeile|Datenbank=Seitenname|Trainer-Nummer=Nummer auf der Datenbankseite}} sich alle Daten für die Vorlage ziehen würde und immernoch die Möglichkeit hätte toggler separat zu setzen oder Werte Manuell zu überschreiben. Dieses hier toggle und da toggle funktioniert NUR wenn die gleiche Anzahl der Toggle verwendet wird. Die Vorlage zieht sich den Namen des toggle aus der Kopfvorlage. Heißt Trainer die in den Orten auf die 3 Modi gesetzt sind und dann auf einer Seite eingebunden sind wo es nur Modi 2 und 3 gibt wo wir im Kopf dann die 2 als 1. Und 2. toggle definieren, kommt es folglich dazu das beim Kopf 1 nichts angezeigt wird, beim Kopf 2 der 2. Modi und Kopf 3 nicht definiert wurde und folglich wieder nicht angezeigt wird. Da die Togglerstelle 1,2 oder 3 in der Zeile steck. So zumindest wenn du die komplette Zeile mit eingebautem toggle als section definierst... Damit es mit toggle abgebildet wird braucht es immer die idente Anzahl toggle. Ein <toggle><section>blabla</section></toggle> (unabhängig das die Syntax nicht so ist und nur die Frage erläutern soll), also ein Section innerhalb eines toggle funktioniert unabhängig ob dieser Wert per-default ausgeblendet ist. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 07:14, 21. Apr. 2021 (CEST)
@Go, Cliffi, Shorty und Virce wie ist eure Meinung dazu? * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:23, 24. Apr. 2021 (CEST)
Meine Idee der Umgehung der Toggle-Problems bei z. B. Startern (wo es sinnvoll ist, den Toggler mit auszulagern, da er überall verwendet werden wird), wäre schlicht und einfach die Togglerauswahl direkt über die Zeile zu stellen und mit auszulagern. Das hat zusätzlich den Vorteil, dass das getogglete garantiert nah an der Auswahl ist. --Datei:Sugimori 672.pngMecanno-manMäh 14:36, 24. Apr. 2021 (CEST)
Starter werden i.d.R. bei Rivalen genutzt. Die Teams sind in Charakterartikeln fast immer durch zwischenüberschriften getrennt bzw. Hast du ja je Spielgruppe immer Idente Starter SoMo Bauz, Flamiau und Robball usw... da kannst du es genauso wie bisher auch machen... Du definierst beim Charakter oder der Trainerklasse im Kopf die Starter und bindest die Vorlage samt Toggle ein. Das ist nicht das Problem, dafür müsste man nichts ändern!!! Also bitte einfach mal diese ignorieren! Es geht hier allerdings um sämtliche anderen Toggle die Variieren wie Spiele SoMo vs. USUM, Fortschritt vor/nach Liga, S2W2-Modi usw. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:56, 24. Apr. 2021 (CEST)
Ich dachte abgesehen von Startern wird es nicht wirklich funktionieren, da überhaupt etwas zu togglen? Deshalb da auch meine Annahme, es ginge um die Rivalen-Toggler. Bei den meisten Anderen wäre es meines Erachtens nach am sinnvollsten gar keine Togglervariabeln auszulagern und wo nötig einfach nen grossen Toggler aussen rum zu bauen (bzw. eventuell sogar ne Vorlage für solche Toggler zu haben). --Datei:Sugimori 672.pngMecanno-manMäh 18:07, 24. Apr. 2021 (CEST)

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)

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, Cazzpa, DaneeBound, Der Sternendiamantritter, DomiDsLP, Erdnussflip007, EternalChimaera, Flyfunner, FusselTeddy, Kaneros, Kirby aka Siss, 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)

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)