PokéWiki:Allgemeine Diskussionsseite: Unterschied zwischen den Versionen

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Zeile 356: Zeile 356:
::::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. -- [[Datei:Pokémon-Icon 380.png|link=Benutzer Diskussion:RobbiRobb]] [[Benutzer:RobbiRobb|<span style="font-family: Comic Sans MS; color: #088A08; text-shadow: 0 0 5px #01DF01, 0 0 10px #01DF01;">RobbiRobb</span>]] 23:33, 29. 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. -- [[Datei:Pokémon-Icon 380.png|link=Benutzer Diskussion:RobbiRobb]] [[Benutzer:RobbiRobb|<span style="font-family: Comic Sans MS; color: #088A08; text-shadow: 0 0 5px #01DF01, 0 0 10px #01DF01;">RobbiRobb</span>]] 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.png|25px|link=]]'''[[Benutzer:Mecanno-man|<span style="color:#008B45;font-family:ka">Mecanno-man</span>]]'''<sup>[[User talk:Mecanno-man|<span style="color:#8B5A2B;font-family:Segoe Print">Mäh</span>]]</sup>'' 23:53, 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.png|25px|link=]]'''[[Benutzer:Mecanno-man|<span style="color:#008B45;font-family:ka">Mecanno-man</span>]]'''<sup>[[User talk:Mecanno-man|<span style="color:#8B5A2B;font-family:Segoe Print">Mäh</span>]]</sup>'' 23:53, 29. Feb. 2020 (CET)
::::::der WMF-Extension [[wikipedia:mw:Extension:LabeledSectionTransclusion|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.
::::::<small>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.</small> --<span style="white-space:nowrap;"> [[Datei:Pokémon-Icon 609.png|link=User:Skelabra2509]] [[User:Skelabra2509|Skelabra2509]]</span> ([[User talk:Skelabra2509|Diskussion]]&nbsp;&#124;&nbsp;[[Spezial:Contribs/Skelabra2509|Beiträge]]) 17:44, 8. Mär. 2020 (CET)

Version vom 8. März 2020, 17:44 Uhr

Vorlage:TOC right

Überarbeitung der Firmen-Artikel

Ich hab mir gerade mal die Artikel angeguckt, die aus Vorlage:Firmen verlinkt werden und finde da muss mal was gemacht werden (ja, nicht nur da, aber irgendwo muss man ja mal anfangen). Da das ganze nach aktuellem Stand keinem Projekt zugeordnet ist (nein, das Spiele-Projekt kann nicht alles machen, auch wenn ich die Diskussion jetzt wieder anstoße), würde ich das ganze mal einfach hier besprechen wollen und dann im Laufe des Jahres da zu nem Ende kommen. Zum Start mal ein Überblick wie es aktuell ist: Kurze Einleitung, komplett unvollständige Liste aller entwickelten Spiele, Wikipedia-Link, wenns gut läuft noch nen Link zur Website der Firma, Vorlage, Ende. Das das nicht ansprechend ist muss ich denk ich keinem erklären. Was ich mir jetzt grob vorgestellt hätte als eine Art "Musterstruktur":

  • Infobox: Damit das Logo nicht komplett lose da rum fliegt wäre eine Infobox ala Wikipedia (natürlich etwas aufgehübscht) nicht ganz schlecht: Logo, Mitarbeiter(?), Gründung, Website, Sitz. Rechtsform oä brauchen wir denk ich nicht.
  • Kurze Einleitung (was hier genau rein sollte müsste man noch diskutieren)
  • Kurze Geschichte (wann aus welcher Firma hervorgegangen oä)
  • Bekannte Spielereihen (fehlt bisher komplett, zB bei Intelligent Systems die gesamte Fire-Emblem-Reihe)
  • Verbindung zu Pokémon (welche Spiele entwickelt, an welchen mitgearbeitet etc)
  • evtl Übersicht über die Verkaufsstärksten Spiele. Auf keinen Fall alle listen, das würde in einem Jahr wieder veraltet sein
  • Weiteres?

Andere Vorschläge, weitere Ideen, evtl fehlende Firmen, sonst was gewünschtes in dem Bereich? Jones Albtraum? 10:39, 17. Mär. 2018 (CET)

Gefällt mir, klingt schon fast nach einem Konzept, dass man so umsetzen könnte ^^ Aber gibt es wirklich genug Inhalt, um sowas auch ansprechend zu gestalten? Bisher haben die Artikel bis auf zwei Sätze in der Einleitung keinen Text und fünf Ein-Satz-Abschnitte schreiben, nur um die Abschnitte zu haben ist definitiv auch nicht die richtige Herangehensweise an das ganze... -- RobbiRobb 16:29, 17. Mär. 2018 (CET)
Finde ich gut so. Ich denke aber, die aufgezählten Punkte für das Konzept reichen. Geht ja eher um eine kurze Vorstellung. -- Liebe Grüße, Moltres 146.gif 16:57, 17. Mär. 2018 (CET)
Ich denke bei den meisten Firmen lässt sich deutlich mehr schreiben als aktuell der Fall. Guckt man bei (en) Wikipedia sieht man ja schon einiges mehr, da würde ich teilweise sogar eher weniger schreiben. Dazu sollen die Artikel ja auch nur grob nen Überblick liefern, was für ne Firma das ist und wie sie mit dem Pokémon-Franchise zu tun haben, bzw generell mit Nintendo.
Dazu noch nen Nachtrag: Abschnitte zu "Wichtigen Personen", wie aktuell bei Game Freak inc. würde ich streichen wollen. Die entsprechenden Personen werden sicherlich im Fließtext erwähnt, alles weitere sollte jedoch in Einzelartikeln (die in dem Fall ja auch alle haben) erläutert werden. Jones Albtraum? 17:09, 17. Mär. 2018 (CET)
Klingt gut --Datei:Sugimori 672.pngMecanno-manMäh 17:14, 17. Mär. 2018 (CET)

Zunächst mal: Das hier soll ne Diskussion werden, kein "Hört sich gut an, hauptsache ich muss nicht mitmachen" :$ Zum zweiten: Ich hatte oben schon angerissen, formulier es aber gerne auch nochmal deutlicher: Welche Firmen qualifizieren sich überhaupt für einen Artikel? Ich habe jetzt mal random geguckt: Der Entwickler von Pokémon Card Game Asobikata DS hat keinen Artikel, Niantic als GO-Entwickler hat keinen, bei einigen Spielen steht TPCi als Entwickler, wo ich mir grad ziemlich unsicher bin, ob sie wirklich selber entwickeln, bei vielen Apps ist Creatures als Entwickler eingetragen, mit Intelligent Systems hat jedoch der Entwickler von Puzzle League und Puzzle Challenge einen Artikel. Jones Albtraum? 23:54, 19. Mär. 2018 (CET)

Da sich SwowoJonny nun bereits die Mühe gemacht und eine entsprechende Infobox erstellt hat, wäre es vielleicht angebracht diese hier nochmals zu begutachten. An eine Strukturierung hat er sich zudem bereits in den Artikeln zu Chunsoft und Niantic gewagt. Insgesamt greift das viele der hier genannten Punkte von Jones auf und versucht sie umzusetzen. Dennoch habe ich das Gefühl, dass noch nicht alle Fragen in voller Gänze geklärt zu sein scheinen, z. B. welche Firmen sich für einen Artikel qualifizieren. Aus diesem Grund halte ich es für sinnvoll, an dieser Stelle nochmals durch ein Feedback an dem Konzept zu arbeiten, sodass wir diesen Punkt im Anschluss guten Gewissens abhaken können und eine Musterstruktur für alle (auch zukünftigen) Firmen-Artikel haben. ~ Taisuke Diskussion 00:11, 5. Jul. 2018 (CEST)
Alle Spiele-Firmen, welche bisher im Wiki vertreten waren, als auch Niantic, sind an sich vervollständigt. Aktuell arbeite ich noch am Artikel für Hudson Soft sowie den Artikel für Nintendo, welchen ich zu Gunsten der VBW gestalte. Jedoch haben wir noch nichts bezüglich den Firmen außerhalb der Spiele. Firmen, welche für den Anime, den Manga oder auch Merchandise oder Karten verantwortlich sind, liegen weit zurück. Mich würde es interessieren, an welchen Firmen Interesse liegt und an welchen nicht. Eure Meinungen? SwowoJonny 13:24, 4. Aug. 2018 (CEST)
Für den Anime schätzungsweise OLM, vom TCG-Bereich her wohl Wizards of the Coast, falls die damals auch in Deutschland zuständig für waren (weiss ich ehrlichgesagt gar nicht), und eventuell Amigo, ist aber imo nicht so wichtig. Aus dem Manga-Bereich hat Shōgakukan schon nen Artikel, den man mal überarbeiten sollte. Ansonsten vielleicht noch Panini? Müsste das Manga-Projekt entscheiden. --Datei:Sugimori 672.pngMecanno-manMäh 12:14, 30. Aug. 2018 (CEST)

Gestaltung der Stellenanzeigen/Ausschreibungen

vorrausgegangene Abstimmung

Hallo!
Vor Kurzem ergab die Abstimmung über die Einführung von Stellenanzeigen bzw. Ausschreibungen auf unserer Hauptseite, dass tatsächlich ein Bedarf für solche da zu sein scheint. Deshalb soll es in dieser Diskussionsrunde darum gehen, wie eine solche Box denn ganz konkret gestaltet und ausgeführt werden soll.
Die zu klärenden Fragen sind:

  1. Wie sieht das Layout der Box aus?
  2. Welche Hauptseiten-Position hat die Box?
  3. Wer darf die Vorlage, die zur Box gehört, bearbeiten?
  4. Was darf/muss alles in die Box?

Als Diskussionsbasis möchte ich hier nochmals meine beiden Beispiele einer möglichen Gestaltung anführen: Link zu den Beispielen
Die Antworten meiner Beispiele auf die oberen Fragen sind:

  1. Entwurf 1: Vertikal schmal; horizontal die Seitenbreite ausnutzend // Randfärbung hellrot, im Überschriftenteil mit Gradient // Überschrift: "Gesucht!" am linken Rand; am rechten Rand Links zu Missionsbrett und globaler To-do-Liste // Im Textfeld kursive, gereihte Kurzausschreibungen mit Projektlinks; ganz rechts Großlinse (als visuell-ansprechendes Element)
    Entwurf 2: Vertikal höher; horizontal einer gegenüberliegenden Box angepasst // Randfärbung blau, im Überschriftenteil mit Gradient // Überschrift "Ausschreibungen:" // Im Textfeld rote Überschrift "Gesucht!"; aufgelistete Kurzausschreibungen mit Projektlinks; unten abgesetzt Links zu Missionsbrett und globaler To-do-Liste; rechts ORAS-Ruinenmaniac-Artwork (als visuell-ansprechendes Element)
  2. Entwurf 1: unter "Willkommen im PokéWiki!" oder über "Aktuelles"
    Entwurf 2:Kein Plan drop.gif
  3. Die Vorlage soll ab dem VB-Rang bearbeitbar sein.
  4. Kurzbeschreibungen in Stichpunktform von gesuchten Positionen oder Funktionen. Es soll auch Mitgliederengpässen oder offene Aufgaben in den jew. Projekten aufmerksam gemacht werden, die von Neumitgliedern relativ leicht ausgefüllt/erfüllt werden können.


Nicht nur schriftliche Vorschläge und Einwände, sondern vor allem auch bildlich anschaubare Entwürfe (Testseiten-/Screenshot-Links) sind sehr erwünscht!
-MfG, Kenaz-Hagalaz Disku 18:10, 26. Mär. 2019 (CET)

Ich habe Entwurf 1 von Kenaz ein wenig abgewandelt und hier mal in einer "Testumgebung" dargestellt. Da ich noch unschlüssig bei der Farbe des unteren Teils und dem Standort bin, habe ich ein paar toggler eingebaut, dann könnt ihr, wenn ihr wollt euch das anschauen und beurteilen^^. Meine Antworten auf die Fragen:
  1. Wie Kenaz' erster Entwurf. Meine Änderungen: der untere Teil ist eine Tabelle um bessere Trenner zu ermöglichen und die Großlinse ist im oberen Teil.
  2. Wie bei Kenaz. Die Stellenanzeigen sollten meiner Meinung nach gut sichtbar sein und neben der dominanten Farbe, halte ich es für wichtig, dass man, am PC die Anzeigen ohne runter zu scrollen sehen kann.
  3. Erneut wie Kenaz^^. Auf der Hauptseite und auffällig --> mindestens ab VB.
  4. Wie Kenaz. Zusätzlich bin ich zur Zeit am überlegen wie man so etwas wie {{Tt}} auch "Smartphone-Nutzer-freundlich" umsetzen kann, um bei Bedarf zu den einzelnen Stichpunkten eine Erklärung abgeben zu können, da die angebenen Punkte sich hauptsächlich (klärt mich auf sollte ich die Haupt-Zielgruppe falsch verstanden haben) an neue Nutzer (und an zukünftige Nutzer) richten und einen relativ einfachen Schwierigkeitsgrad haben sollen. Außerdem könnte man damit ermöglichen auch mal ein bisschen anspruchsvollere Aufgaben mit ausreichender Erklärung zu stellen. --DeXter 21:54, 27. Mär. 2019 (CET)
  1. Mir gefällt da jetzt spontan die generelle Richtung von Entwurf 2 besser; finde allerdings dass da zu viel Farbe hervorsticht, hätte mir da einen wesentlich kleineren Rahmen, wenn überhaupt, vorgestellt (das ihr hier schon viel zu früh Farbe in die Diskussion werft, sei mal dahingestellt - so wird sich jetzt nämlich die Hälfte gegen dieses Orange und nicht gegen das Design aussprechen). Oh und um himmels willen, kein tt auf der Hauptseite - ist schon schlimm genug das wir das noch in Artikeln nutzen. Zeitgemäss ist das einfach nicht mehr.
  2. Spontaner Vorschlag - und müsste definitiv noch von Killuu und Isso genehmigt werden: über das schon gewusst und dafür das Zeichenlimit von AdW/PdW erhöhen, damit da kein Leerraum entsteht. Haben wir Kapazität dafür aus dem XdW-Bereich? Ich meine mich nämlich erinnern können das früher sich immer darüber beklagt wurde dass die Zeichenlimite da zu kurz sei.
  3. Es is sinnlos es PLs zu verbieten und SB und alles drunter traue ich dieses Recht nicht zu - ist immerhin die Hauptseite. Folglich Entweder VB+ oder PL+ - was genau hängt vor allem von der Umsetzung von Punkt 4 ab.
  4. ..doppelt sich entweder mit der To Do oder mit dem Missionsbrett, so wie die Diskussion läuft eher mit der To Do. Da deren Darstellung allerdings meine Idee war, sie nicht so wirklich funktioniert hat und ich nicht weiss, wie man sie verbessert, halte ich mich hier glaub besser raus. --Datei:Sugimori 672.pngMecanno-manMäh 18:35, 29. Apr. 2019 (CEST)
Zu dem Thema kann ich eigentlich nicht viel sagen, da ich erstens kein Fan dieser "Stellenausschreibungen" bin (soll jetzt keine weitere Debatte anstoßen, ich akzeptiere die Entscheidung) und zweitens ein furchtbares Gefühl für Design habe. Nur eine Bitte meinerseits: benutzt wenn möglich keine zu grellen roten und ins rote gehende Farben. Das beißt sich furchtbar mit dem Blau, das wir hier hauptsächlich verwenden. Fällt zwar sofort auf, lenkt aber auch vom Rest ab und ist zumindest für mich fast schon unangenehm anzusehen :x -- Datei:Pokémonsprite 359 Pinball2.png Korvel1 Diskussion 10:10, 4. Mai 2019 (CEST)
Ich habe das Design meiner Vorschläge ein wenig geändert (auch etwas mehr nach dem Stil der anderen Boxen auf der Hauptseite). Hoffe, dass das Aussehen euch eher zusagt^^. --DeXter 18:54, 4. Mai 2019 (CEST)
Ich finde Entwurf zwei eigentlich schicker. So schmale Boxen gefallen mir meistens nicht so. Zu Mecs Einwurf: Ja, wir haben teilweise XdWs die gerne eine höhere Zeichenzahl hätten, manchmal krebst man da aber auch am unteren Ende rum. Wenn man aber die XdW-Box vielleicht etwas quetscht, wird sie auch länger? Wobei man dann schauen müsste, ob das noch schön proportioniert ausschaut. Lg --Und dann im Mondschein... Killuu 22:23, 5. Mai 2019 (CET)
Danke für eure Rückmeldungen!
Ja, die tt-Vorlage sollte in dieser Box wirklich komplett vermieden werden. Allein schon, weil sie auf Mobilgerät-Browsern oft nicht richtig dargestellt wird, was dann meist die Zerstörung des Layouts zur Folge hat. Eventuelle weitere Nachteile der tt-Vorlage unterstützen diesen Punkt nur noch.
Ich denke auch, dass man die Farben der Box nicht zu grell gestalten sollte. Ich finde den Vorschlag, von der Signalfarbe Rot abzusehen, sehr interessant und bin zu dem Schluss gekommen, dass ein blauer oder grüner Farbton, wohl am besten passen würde. Z. B. die gleiche Farbe, wie die, der übrigen Boxen nur ggf. etwas dunkler oder eben ein Greenchu-Grün.
Als XdW-Autor habe ich auch immer wieder mit der Zeichenbegrenzung zu kämpfen. Als jemand, der gerne ein weites Spektrum an Formulierungsmöglichkeiten haben möchte, würde ich eine Aufstockung des Zeichenlimits begrüßen. Ich sehe aber auch, dass viele mit dem Mindestzeichensatz ringen. Das Problem der Proportionsästhetik entsteht durch eine allzu große Vergrößerung der XdW-Box leider auch. Ich hoffe, unsere Projektleiterin Isso kann uns ihre Einschätzung der Lage und der potenziellen Möglichkeiten geben.
Ich bin auch von der „Längsfassung“ (wie DeXters oder mein Entwurf 1) eher abgekommen, da ich ein Problem bei dieser sehe, wenn es zu viele oder zu wenige Gesuche geben sollte. Besser wäre es wohl, eine schmalere Box (wie mein Entwurf 2) zu haben, die sich nach Bedarf füllt oder erweitert. Ich würde sehr gerne auch eine solche Variante mal „in Aktion“ sehen. Da du dich, DeXter, für diese Sache sehr engagierst und deine Syntax-Fähigkeiten deutlich besser sind als meine, möchte ich dich bitten, mal deine Version dieser Variante zu erstellen. Bin gespannt, wie die wohl aussähe. :)
-MfG, Kenaz-Hagalaz Disku 16:32, 24. Jun. 2019 (CEST)
Kann ich gerne machen Kenaz^^. Sollte dann die nächsten Tage fertig werden, je nach dem wie schnell ich mit meinem Ergebnis zufrieden bin (nach Möglichkeit werd ich auch versuchen das irgendwie ins Haupseiten-Layout reinzubringen, bin da aber eher am zweifeln ob ich das in angemessener Zeit schaffe). Vorhin hatte ich mir auch noch eine Frage überlegt, die ich aber wieder vergessen habe drop.gif Sollte sie mir wieder einfallen, kommt nochmal was von mir. --DeXter 19:28, 24. Jun. 2019 (CEST)
Tada! Zwar nicht ganz fertig, aber das Einzige, was mich noch stört ist das "Gesucht!" und dafür hab ich bisher noch keine zufriedenstellende Lösung gefunden. Hoffentlich fällt euch was ein (muss auch nicht gleich in CSS sein; wenn nötig kann ich versuchen einen Vorschlag möglichst gut umzusetzen). Mit der restlichen Box bin ich sehr zufrieden (viell. könnte man auch noch den freien Platz unterm Bild entfernen, dafür müsste nur die Höhe des divs, in dem die Liste ist, geändert werden; dann wäre die Box auch kürzer). Ich hab mich am Design der restlichen Hauptseiten-Boxen orientiert und denke, dass das Bild auf jeden Fall ausreicht um auf die Box aufmerksam zu machen. --DeXter 18:58, 26. Jun. 2019 (CEST)
Passt anscheinend doch nicht. Das Entfernen der Scrollbar über scrollbar-width: none funktioniert in Firefox und dem Samsung Internet Browser für Handys (wie auch immer der genau heißt), aber nicht in Edge und dem Internet Explorer. Bei anderen Browsern weiß ich es nicht. Ich versuche in den nächsten Tagen das zu lösen. --DeXter 16:49, 27. Jun. 2019 (CEST)
@Kenaz (und alle, die hier mitwirken wollen^^), jetzt ist die Box (fast) fertig. Wie bereits gesagt stört mich noch das "Gesucht!"; ansonsten siehe meine vorletzte Nachricht. Hier nochmal der Link. Und noch etwas hintendran: Mec kritisierte grad auf Discord, dass man durch die unsichtbare Scrollbar nicht mehr sehen könne, dass die Liste hoch- und runtergescrollt werden kann und, dass somit der "08/15-Nutzer" nicht merken wird, dass die Liste diese Funktion hat. Meiner Meinung nach ist das kein Problem, da, auf meinem Handy und meinem PC, wenn die Liste lang genug ist, der unterste, sichtbare Listeneintrag (wenn die Box ganz hochgescrollt ist) vom Rand der Box angeschnitten wird und man sich somit erschließen kann, dass die Liste länger ist als das, was man sehen kann. Was sind eure Meinungen? --DeXter 19:08, 8. Jul. 2019 (CEST)
Durch das fehlen der Scrollbar interpretier zumindest ich das eher als n Designfehler als n Indikator zum Scrollen; irgend einen Indikator das man da Scrollen kann brauchts definitiv. --Datei:Sugimori 672.pngMecanno-manMäh 23:41, 8. Jul. 2019 (CEST)

Überarbeitung der Darstellung der Statuswerte

Ich habe mir gedacht, dass man die Statuswerte-Infobox, die in jedem Pokémon-Artikel enthalten ist, mit etwas sinnvolleren Informationen füllen könnte.

Die Basiswerte müssen dort natürlich unbedingt stehen, die Fleißpunkte (die man für das Besiegen des Pokémon bekommt) passen auch gut an diese Stelle, über den Rest kann man aber diskutieren. Meiner Meinung nach können die meisten der anderen Informationen so belassen werden, wie sie aktuell sind: Die Unterteilung in Level 50 und Level 100 ist sinnvoll, da beide im kompetitiven Spiel häufig genutzt werden, und sowohl die Angabe der Maximalwerte bei neutralem als auch die Angabe bei positivem Wesen kann hilfreich sein (wobei man überlegen könnte, einen der beiden Werte zu streichen, da man sich zumindest vom neutralen zum positiven Wesen den Wert sogar im Kopf ausrechnen kann).

Die Angabe der Maximalwerte bei negativem Wesen hilft aber so gut wie niemandem. Für kompetitiv spielende Trainer sind diese Werte uninteressant, da es praktisch nie sinnvoll ist, 252 Fleißpunkte in einen Wert mit negativem Wesen zu stecken, und gewöhnliche Trainer können diese Werte auch nicht gebrauchen, da sie wahrscheinlich nicht zufällig 31 DV auf diesem Wert haben und erst recht kein gezieltes Fleißpunkte-Training durchführen, um 252 Fleißpunkte auf dem Wert zu erreichen.

Stattdessen schlage ich vor, hier die Minimalwerte anzugeben, also die Werte, die bei 0 DV und 0 FP erreicht werden. Das wäre insbesondere beim Initiative-Wert für kompetitive Spieler interessant, aber auch für andere, da man so den gesamten Bereich sieht, in dem sich ein Wert befinden kann. Man kann auch mit den Werten seiner eigenen Pokémon vergleichen, um zu sehen, ob sich der Wert eher im oberen oder im unteren Teil des Bereichs befindet. Außerdem sieht man so direkt, in welchem Ausmaß FP-Training und maximale DV Werte steigern können.

Hier gibt es dann noch zwei Möglichkeiten, man könnte die Minimalwerte entweder bei negativem oder neutralen Wesen angeben. Der Vorteil bei negativem Wesen ist, dass man das wirkliche Minimum hat, ich halte aber die Angabe bei neutralem Wesen für besser, da die Umrechnung von neutralem zu negativem Wesen einfacher und immer eindeutig ist. (Im Gegensatz zur Umrechnung von negativem zu positivem Wesen, z.B. wird ein Wert, der bei neutralem Wesen 110 ist, bei negativem Wesen zu 110 * 0,9 = 99. Ist der Wert bei neutralem Wesen aber 111, kommt bei der Rechnung 111 * 0,9 = 99,9 raus, was ebenfalls zu 99 abgerundet wird.)

(Eine weitere Idee, die ich hatte, war die Angabe von tatsächlichen durchschnittlichen Werten, die mit 15 oder 16 DV, 85 FP und neutralem Wesen erreicht werden. Das wäre vielleicht interessant für Spieler, die sich überhaupt keine Gedanken über DV, FP und Wesen machen wollen, aber trotzdem wissen wollen, welche Werte sie von einem Pokémon ungefähr auf Level 50 bzw. 100 erwarten können. Diese Werte anzugeben, wäre aber meiner Meinung nach aber nur dann sinnvoll, wenn man sich dazu entscheidet, die Maximalwerte bei neutralem oder positivem Wesen zu streichen oder einen vierten Werteblock einzufügen, die Minimalwerte stufe ich jedenfalls als wichtiger ein.)

Also, um das Ganze kurzzufassen: In der Statuswerte-Infobox sollten die wenig sinnvollen Maximalwerte bei negativem Wesen durch die nützlicheren Minimalwerte bei neutralem oder negativem Wesen ersetzt werden. --Lasagne (Diskussion) 17:06, 25. Apr. 2019 (CEST)

Hi Lasagne! Die Darstellung dort ist nun schon soo lange da, dass ich sie noch nie hinterfragt habe... danke für die Anregung! Meine Meinung dazu ist, dass die Spezialwerte wie Maximal- oder Minimalwerte eigentlich in den Spezies-Artikeln nur wenig verloren haben. Wir haben schließlich auch Strategie-Artikel für die Pokémon, und selbst da hat sich das zuständige Projekt dafür entschieden, nur Basiswerte aufzuführen, wie es auch namhafte Strategieseiten wie Smogon machen. Statuswerte-Rechner gibt es an anderer Stelle bessere, und wenn wir sowas brauchen, dann ist es auf der Strategie-Seite oder auf einer eigenen Listenseite sinnvoller für die Leute, die sich für Competitive Play interessieren. Mein Gefühl ist aber, dass eine Liste einen Rechner niemals sinnvoll in der Darstellung ersetzen kann. Mein Plädoyer wäre also eher, alles bis auf die Basiswerte und Fleißpunkte aus den Spezies-Artikeln herauszunehmen. Welche Sonderwerte man sinnvoll braucht, kann ich aus deiner Argumentation nachvollziehen, aber hab dazu keine Meinung, weil ich mich mit Competitive Play nie beschäftigt habe. Mein Eindruck ist, selbst die Strategieler haben sich bei den Strategieseiten dagegen entschieden. Viele Grüße! Pokémon-Icon_674.png Maxmiran 11:45, 17. Mai 2019 (CEST)
Nach etwas weiterführendem Brainstorming auf Discord kam die Idee auf, einen auf alle Bedürfnisse zugeschneiderten interaktiven Rechner bereitzustellen, mit dem jeder bei Angabe des Pokémon, der DV, FP und Level sowie Wesen spezifisch für sein Pokémon die maximalen Werte ausrechnen kann. Da Buo dem gegenüber nicht abgeneigt ist, wäre dies also eine Möglichkeit, die Inhalte der Pokémon-Artikel auf ein Minimum zu reduzieren und dennoch den Besuchern keinen der Werte vorzuenthalten. Inwieweit das jetzt besser oder schlechter als die eingangs von Lasagne vorgeschlagenen Werte sind, müsste allerdings jemand beurteilen, der sich mehr mit sowas auseinandergesetzt hat als ich. -- RobbiRobb 14:47, 17. Mai 2019 (CEST)
Wenn ein direkt in die Pokémon-Artikel eingebetteter interaktiver Statuswerte-Rechner möglich ist, wäre das natürlich großartig und wohl die beste Lösung. Man könnte dann z.B. die Maximalwerte auf Level 100 (31 DV und 252 FP auf jedem Wert, neutrales oder positives Wesen) voreingestellt machen (ich weiß, aufgrund der FP ist ein Pokémon, das all diese Werte hat, nicht möglich, aber das halte ich nicht für problematisch). Außerdem wäre es sehr hilfreich, wenn es zwei Knöpfe gibt, mit denen man sofort alle FP und DV maximieren bzw. minimieren kann, da man sich damit mit nur einem Klick bis zu zwölf Eingaben spart.
Ich würde mich über diese Funktion auf jeden Fall sehr freuen und hoffe, dass die Umsetzung nicht zu viel Arbeit macht. Falls es aber doch zu viele Schwierigkeiten gibt und man bei einer statischen Darstellung bleiben möchte, sollte man meiner Meinung nach nicht nur die Basiswerte anzeigen, wie Maxmiran es vorgeschlagen hat.
Einerseits schadet es nicht, etwas mehr Informationen darzustellen, und die Statuswerte-Infobox wirkt meiner Meinung nach auch noch nicht zu überladen (wenn alle tatsächlichen Werte einfach gestrichen würden, sähe es mir sogar etwas zu karg aus).
Andererseits ist es aber auch so, dass Pokémon-Spieler, die sich nicht mit der Berechnung der Statuswerte auseinandergesetzt haben, mit den Basiswerten alleine nicht besonders viel anfangen können. In den Pokémon-Spielen selbst werden diese Basiswerte nie wirklich behandelt, es werden immer nur die tatsächlichen Werte angezeigt, deshalb sollte meiner Meinung nach auch im PokéWiki weiterhin in irgendeiner Form gezeigt werden, was die Basiswerte für die tatsächlichen Werte bedeuten. Es ist so ähnlich wie bei der Fangrate, wo man kaum was mit dem spielintern verwendeten Wert anfangen kann, ohne sich mit der Formel auseinanderzusetzen, die tatsächliche Chance hilft da oft schon eher.
Und auch für kompetitiv spielende Trainer können die tatsächlichen Werte oft interessant sein, auch wenn man diese auch auf einigen anderen Seiten nachrechnen kann. Auf diesen Seiten findet man dafür nämlich oft andere Informationen nicht, die man vielleicht braucht, z.B. wo man ein Pokémon bekommen kann oder welche Eltern man für bestimmte Zucht-Attacken braucht. Alle wichtigen Informationen auf derselben Seite zu bekommen, ist da schon recht hilfreich. --Lasagne (Diskussion) 20:07, 18. Mai 2019 (CEST)
Ich kann alle vorgeschlagenen Änderungen gut nachvollziehen und befürworte die. Ich sehe aber nachwievor nicht, wieso die berechneten Statuswerte in den Spezies-Artikeln besser aufgehoben sein sollten als in den Strategie-Artikeln, was ist dafür ein Argument? (Außer, dass es vielleicht noch nicht alle gibt, aber das ist schnell gezaubert) Pokémon-Icon_674.png Maxmiran 16:12, 19. Mai 2019 (CEST)
Das ist vielleicht eher eine Geschmacksfrage, meiner Meinung nach gehören die Statuswerte, auch die tatsächlichen, aber eher in die allgemeinen Pokémon-Artikel. Ein paar Gründe dafür:
- Die Strategie-Artikel enthalten bereits die tatsächlichen Statuswerte für die dort vorgestellten Sets, das ist meiner Meinung nach ausreichend.
- Die Strategie-Artikel sind meiner Auffassung nach eher dafür da, die Eigenschaften eines Pokémon zu bewerten, allgemeine Verwendungstipps zu geben und konkrete Spielweisen vorzustellen. Sie sind aber nicht dazu da, Spieldaten zu vermitteln, die so nicht im Pokémon-Artikel selbst stehen. Kurzgesagt: Der Pokémon-Artikel enthält die Daten (und viele weitere Informationen), der Strategie-Artikel die Interpretation dieser Daten.
- Jemand, der kein Pokémon-Profi ist und mit Basiswerten nichts anfangen kann, wird sich wahrscheinlich nicht zum Strategie-Artikel durchklicken, um die tatsächlichen Werte eines Pokémon zu prüfen. Einerseits, weil er sie vermutlich nicht dort erwartet, und andererseits, weil er das Pokémon vielleicht gar nicht strategisch-kompetitiv spielen möchte, sondern einfach nur wissen will, wie stark das Pokémon auf welchen Werten ist. --Lasagne (Diskussion) 22:25, 20. Mai 2019 (CEST)
Das Argument mit den Daten im Pokédex und der Deutung bei der Strategie sehe ich auch so und kann ich gut nachvollziehen. Danke für die Klärung! Ich würde es selbst am besten finden, dann die Spanne des Wertes anzugeben vom Minimal zum Maximalwert, aber ohne die Einflussfaktoren weiter aufzuschlüsseln. Einmal den Wert mit 0 DV, negativem Wesen und 0 FP und einmal das Gegenteil. Das Einordnen auf der Skala stelle ich mir auch für Laien interessant vor, wie du es vorgeschlagen hast. Alle anderen Fälle sehe ich aber dann bei nem Rechner, neutrales Wesen etc. Pokémon-Icon_674.png Maxmiran 07:48, 21. Mai 2019 (CEST)
Ich misch auch mal kurz mit :) Einerseits sagst du „Die Angabe der Maximalwerte bei negativem Wesen hilft aber so gut wie niemandem. Für kompetitiv spielende Trainer sind diese Werte uninteressant“, dann allerdings sagst du, dass sich nicht CP-Spieler garnicht erst zum Strategie-Artikel durcharbeiten. Und eben deswegen sollten die maximalen Werte bei negativem Wesen eben doch bestehen bleiben. Denn: ein nicht CP-Spieler fängt sich einfach ein Pokémon egal welchen Wesens und möchte aber dann vielleichgt trotzdem noch das beste damit rausholen. Also sind eben auch diese Werte für die Casual-Gamer sehr interessant und sollten keineswegs einfach ersetzt werden. Und wie du schon sagst: die, die es wissen und damit eben competitiv agieren wollen wissen entweder, was sie tun, oder suchen nach strategien und landen dann ohnehin auf den Strategie-Artikeln, wo eben bereits die Angaben zur besten Verteilung vorhanden sind. Ich sehe also in der jetzigen Aufmachung tatsächlich kein Probelm, spreche mich aber auch sehr gerne für einen Rechner aus, der sollte aber eine eigene Seite bekommen und legidlich verlinkt werden, das würde sonst Artikel einfach datentechnisch vermutlich sprengen. -- Grüße ShortyBuzz 11:14, 21. Mai 2019 (CEST)

Ich glaub es muss generell noch beschlossen werden wo man so einen Rechner hinplazieren sollte; entweder man bindet ihn in Artikel ein, oder man setzt ihn auf eine Spezialseite. Ich bin definitiv für ersteres, da bisher die Infos die wir bereits haben auch in diesen Artikeln stehen; gerne kann man aber auch noch zusätzlich eine Spezialseite anbieten, diese sollte den Rechner in den Artikeln aber nicht ersetzen. Was das Ladezeitproblem angeht wäre ich dafür das man den Rechner erst einfügt wenn die Attacken mal vernünftig gemacht sind (entweder shadow macht die neue Vorlage fertig oder wir lagern aus, aber eins muss da bald mal geschehen...) --Datei:Sugimori 672.pngMecanno-manMäh 17:09, 21. Mai 2019 (CEST)

Um mal etwas handfestes in diese Diskussion zu bringen, habe ich den gestrigen Abend damit verbracht, einen Prototypen für eine mögliche, in die Pokémon-Artikel integrierte, dynamische Darstellung der Statuswerte programmiert. Damit sich alle mit Interesse ein Bild davon machen können, ist dieser hier einsehbar (Achtung: Externe Seite, die nicht mit dem Wiki in Verbindung steht). Mir ist bewusst, dass wir uns mit dem Rechner von der ursprünglichen Idee, andere und eventuell besser gewählte Statuswerte anzubieten, entfernen, aber ich glaube, dass die zusätzliche Flexibilität durchaus ansprechend sein könnte. Es sei übrigens gesagt, dass es sich bei diesem Prototypen um ein Beispiel für eine integrierte Darstellung handelt, das Design entspricht also weitestgehend dem aktuellen Design der Statuswerte-Vorlage in unseren Artikeln. Abgesehen von einer kleineren technischen Herausforderung ließe sich das also entsprechend in die aktuelle Vorlage einbauen. Sollte der Wunsch bestehen, eine eigene Spezialseite für diesen Rechner anzubieten, müsste der Code noch um die Auswahl eines Pokémon in Verbindung mit einer Sammlung der Statuswerte verbunden werden, diese werden bislang einfach aus der Vorlage gezogen. Im Hinblick auf die Ladezeiten wird diese neue Vorlage keinen bis kaum einen Unterschied machen, statt wie bisher eine statische Berechnung durch den Prozessor durchzuführen, die die Seite verzögert lädt, wird das Laden der Seite durch den neuen Code vermutlich unwesentlich kürzer, diese Zeit wird dann aber für das kompilieren und ausführen des Javascripts, dass die Berechnung durchführt, gebraucht. Die Veränderung wird also vermutlich nicht so groß ausfallen, dass man explizit deswegen jetzt die Attacken auslagern sollte, dies ist etwas, was ohnehin nötig ist.
Da nun aber die technische Machbarkeit und die Grundsätzliche Bereitschaft einer solchen Umsetzung geklärt ist, steht als nächstes die Frage im Raum, ob ein solcher Rechner überhaupt allgemein befürwortet wird und wenn ja, an welcher Stelle dieser platziert werden soll (Pokémon-Artikel vs. Spezialseite). Ich denke die letztendliche Entscheidung wird sich am besten mit einer Abstimmung durchführen lassen, ich möchte diese aber nicht übereilt starten und stattdessen lieber noch etwas Zeit lassen, damit alle Interessierten sich dazu äußern können, vielleicht stellt sich ja heraus, dass es noch eine bessere Möglichkeit als diese gibt oder eine Mehrheit bereits vorweg für die Umsetzung des Vorschlags von Lasagne ist. -- RobbiRobb 12:29, 22. Mai 2019 (CEST)
Danke für die Vorarbeit, RobbiRobb! Die Prototyp-Lösung finde ich schon mal ganz gut. In dieser Form sollte es in den Pokémon-Artikeln umsetzbar sein. Von mir aus kann es aber auch als Spezialseite gemacht werden, auf die dann unter der bisherigen Tabelle verwiesen wird. ~ 418.gif Buoysel 12:46, 22. Mai 2019 (CEST)
Ich danke dir, dass sich aus unserem kleinen Gespräch darüber bereits dieser Prototyp ergeben hat, Robbi! Mir gefällt dieser Ansatz schon sehr, sodass ich mir diese Form der Berechnung auch in den Pokémon-Artikeln vorstellen könnte. Sollte sich bei einer Abstimmung aber für eine Spezialseite ausgesprochen werden, wäre dies ebenfalls für mich in Ordnung. Auf jeden Fall ist dies eine sehr gute Grundlage, um die Überarbeitung der Darstellung der Statuswerte stark voranzutreiben. ~ Taisuke Diskussion 15:48, 22. Mai 2019 (CEST)
Der Rechner gefällt mir auch sehr gut, ich wäre dafür, den Rechner auf eine Spezialseite zu packen und unter den bisherigen Tabellen zu verlinken. Ich denke dass man, vor allem wenn man mobil unterwegs ist, am liebsten direkt die maximalen Statuswerte sehen möchte und nicht erst noch 6 mal 252 FP und 31 DV eintippen will. Deshalb würde ich die Statuswertetabelle so ähnlich belassen, wie sie jetzt ist, man könnte vielleicht die Maximalwerte bei negativem Wesen entfernen. Luca12379 Diskussion 16:30, 22. Mai 2019 (CEST)
Der Prototyp ist zwar vom Design her sehr ansprechend, jedoch gibt es da funktional noch ein paar Problemchen, so kann man zur Zeit Buchstaben oder Zahlen grösser als 252 eingeben, was scheinbar auch nicht einfach so ohne weiteres behoben werden kann, verschiedenen Browsern sei dank. Wären aus diesem Grund eventuell Slider ne Idee, mit nem zusätzlichen um alle Werte gleichzeitig zu erhöhen? (Würde spontan auch den default woanders als Level 1 setzen, da sieht man kaum was) --Datei:Sugimori 672.pngMecanno-manMäh 17:06, 22. Mai 2019 (CEST)
Der Prototyp des Rechners ist meiner Meinung nach sehr gelungen, RobbiRobb! Als ich den Vorschlag zur Überarbeitung der Darstellung der Statuswerte ursprünglich gemacht hatte, dachte ich nicht daran, dass ein eingebetteter Rechner überhaupt eine realistische Option ist. Wie ich weiter oben schon geschrieben habe, halte ich diesen Rechner für eine bessere Lösung als eine statische Tabelle, auch wenn man meinen ursprünglichen Vorschlag umsetzt. Ich finde auch, dass dieser Rechner direkt in die Pokémon-Artikel eingebunden werden sollte, da man so den Statuswerte-Rechner und weitere Pokémon-Informationen auf derselben Seite hätte, was meiner Meinung nach ein großer Vorteil ist. Noch ein paar Verbesserungsvorschläge für die finale Version des Rechners:
- Sinnvolle Voreinstellung (z.B. Level 100, 252 FP und 31 DV auf jedem Wert, neutrales Wesen)
- Zwei Knöpfe, um sofort alle FP und DV zu maximieren bzw. minimieren (spart bis zu 12 Eingaben)
- Neben den Namen der Wesen auch kurz den Effekt in Klammern angeben (z.B. "Froh (+Init., -Sp.A.)")
--Lasagne (Diskussion) 20:45, 22. Mai 2019 (CEST)

Ich habe inzwischen mit einigen Benutzern Rücksprache gehalten und Feedback gesammelt, wo es möglich war und habe daher auf der Grundlage dieser eine etwas erweiterte Version der bisherigen Tabelle gebastelt, die hier zu finden ist. Dabei wurden vor allem folgende Aspekte verändert:

  1. Die Startwerte beim Laden der Seite sind jetzt direkt auf das Maximum gesetzt, dies betrifft sowohl den Level, die DVs, aber auch sämtliche FP, die damit zwar das vom Spiel vorgegebene Maximum übersteigen, dafür allerdings weiterhin das Maximum aller Werte gleichzeitig anzeigen kann. Daneben habe ich ein Wesen eingefügt, was standardmäßig ausgewählt ist und sich auf alle Werte positiv auswirkt. Im gleichen Zug habe ich eine geplante Funktion, die FP zu maximieren, damit sie eben jenes vom Spiel vorgegeben Maximum nicht übersteigen, nicht implementiert, dies hätte hier Konflikte verursacht.
  2. In der Kopfzeile finden sich neben den FP und den DVs Pfeile, die es ermöglichen, alle Werte dieser Spalte zu maximieren. Ich glaube nicht, dass es sich lohnt, einen Knopf einzufügen, der sowohl FP als auch DVs maximiert bzw. minimiert, wenn das von einer Mehrheit gewünscht ist, kann ich diesen aber sicherlich auch nich einfügen. Ansonsten würde ich es dabei belassen, das dürfte die Nutzung schon erheblich beschleunigen und komfortabler machen.
  3. Eine kurze Angabe, was genau die einzelnen Wesen bewirken, habe ich zunächst noch nicht eingefügt, dies lässt sich aber recht einfach nachtragen, wird sich aber vermutlich auf die Breite der Tabelle auswirken. Wenn das aber gewünscht ist, werde ich das selbstverständlich gerne ebenfalls einfügen, um die Verständlichkeit und Benutzerfreundlichkeit zu erhöhen.
  4. Im Hinblick auf die Sicherheit habe ich einige Mechanismen eingebaut, die verhindern, dass die einzelne Werte ihr erlaubtes Maximum über- oder unterschreiten. So kann nun kein Wert mehr unter 0 fallen, das Level kann nicht mal unter 1 fallen, gleichzeitig können die FP 255, die DVs 31 und das Level 100 nicht übersteigen. Gleichzeitig wird auch garantiert, dass es nicht zu merkwürdigen Ergebnissen kommt, wenn ein Feld leer ist. Das sind zwar nur kleinere Änderungen, verhindert aber, dass Benutzer plötzlich übergroße Balken oder einfach gar keine Balken mehr zu sehen bekommen oder sonst welchen Unfug anstellen (das würde uns zwar nicht beeinflussen, weil es Clientseitig ausgeführt wird und weder die Server noch die eigentlichen Seiten davon betroffen sind, es hinterlässt aber keinen allzu guten Eindruck, wenn das so schlampig programmiert wird).

Das sind die bisherigen Änderungen zur ersten Version, gibt es Änderungen, die dabei nicht so gut gefallen, fehlt noch irgendwas bzw. wird die Kurzbeschreibung der Wesen so stark gewünscht, dass ich diese auf jeden Fall übernehmen soll? Ansonsten bin ich auch für alle gefundenen Bugs offen, ich werde dann mein bestes versuchen, diese zu beheben. -- RobbiRobb 23:43, 22. Mai 2019 (CEST)

Ich war ja anfänglich eher skeptisch, ob das gut aussehen könnte, bin aber von dem Rechner mittlerweile ein großer Fan. Optisch "minimalinvasiv". :D Vielen Dank für all eure Beiträge und Robbi, für die Programmierung! Zum Wesen könnte ich mir vorstellen, dass man das wie in den Spielen löst und die erhöhte Werte rötlich färbt und die niedrigeren Werte hellblau... aber dass es irgendwie sichtbar sein sollte, da stimme ich Lasagne zu. Ich frage mich, ob es die Hoch- und Runterpfeile in den Feldern selbst wirklich braucht, die überladen das Layout ein bisschen und ich schätze, dass sie kaum genutzt werden werden, keiner wird z. B. von 31 auf 30 DV runterklicken oder FPs oder Level in Einerschritten durchschalten. Ich gehe davon aus, dass die meisten User das händisch eingeben werden, daher könnte man sie auch weglassen. Gilt nicht für die Minimal- und Maximalpfeile, die finde ich top. Ansonsten alles wunderbar und mir wird jetzt erst bewusst, wie cool ich das finde, dass wir da dynamische Balken drinnehaben. :)) Pokémon-Icon_674.png Maxmiran 10:00, 23. Mai 2019 (CEST)
Danke für die gute Überarbeitung, RobbiRobb! Die kleinen Pfeile neben "FP" und "DV" gefallen mir, einen Knopf zum Maximieren und Minimieren aller Werte braucht es damit meiner Meinung nach nicht mehr.
Beim Vergleich mit dem Smogon-Rechner habe ich aber einen Bug entdeckt: Beim voreingestellten Pokémon (Latias) werden auf Level 85 mit Wesen Scheu mit 252 FP und den DVs auf 31 beim Initiative-Wert 299 angegeben, obwohl es eigentlich 298 sein müssten. Bei negativem Wesen auf Initiative (mit sonst den gleichen Einstellungen) sind es 244 statt 243. Ich vermute, der Grund dafür ist, dass momentan nicht vor Einbezug des Wesens abgerundet wird (laut der Formel kommt vor dem Wesen ein Initiative-Wert von 271,9 raus, ohne Abrundung sind es mit positivem Wesen 299,09). Ich habe nochmal geprüft, ob diese Abrundung in Pokémon-Spielen aktuell tatsächlich noch gemacht wird und bin bei meinem Fuegro auf die Antwort gestoßen, das auf Level 57 mit Wesen Sacht (+Sp.V., -Sp.A.) und einem Spezial-Angriffs-DV von 31 auf einen Spezial-Angriffs-Wert von 101 kommt. Ohne Einbezug des Wesens würde hier 113,87 rauskommen, abgerundet 113. Rechnet man mit dem unabgerundeten Wert weiter, kommt man auf 102,483, also auf 102. Mit dem abgerundeten Wert kommt man auf 101,7, also auf 101, was der richtige Wert ist. Das ist momentan aber auch im Statuswerte-Artikel falsch erklärt, demnach wird diese Abrundung seit der fünften Generation nicht mehr gemacht, was offenbar falsch ist.
Zudem habe ich noch folgende (hauptsächlich kleinere) Verbesserungsvorschläge:
  1. Wird das Level bei der Neueingabe kurzzeitig ganz entfernt, wird momentan NaN ausgegeben, hier sollte man stattdessen die Werte für Level 1 anzeigen.
  2. Die FP-Obergrenze auf 252 statt 255 setzen (gilt seit der sechsten Generation und FP über 252 haben sowieso keine Auswirkungen).
  3. Durch die kleinen Pfeile neben den FP-Feldern die FP jeweils um vier erhöhen bzw. senken (noch besser: auf den nächsthöheren bzw. -niedrigeren durch vier teilbaren Wert setzen).
  4. Wenn man ein Wesen einbaut, das sich auf alle Werte (außer KP) positiv auswirkt, sollte man vielleicht auch eins einbauen, das auf alle Werte negativ wirkt. Man könnte diese "Wesen" dann z.B. "(positives Wesen)" und "(negatives Wesen)" oder "(+alle Werte)" und "(-alle Werte)" nennen.
  5. Vielleicht hast du sowieso schon daran gedacht, RobbiRobb, zur Sicherheit wollte ich es aber trotzdem noch erwähnen: Vor der Einbindung ins PokéWiki sollte der Ninjatom-KP-Spezialfall gesondert behandelt werden.
  6. "Spezifische Werte" sollte meiner Meinung nach irgendwie umbenannt werden, z.B. in "Permanente Werte" (finde ich auch nicht gut, so werden sie aber im Statuswerte-Artikel bezeichnet), "Resultierende Werte" oder nur "Statuswerte".
  7. Zum Thema Kurzbeschreibungen der Wesen können gerne noch ein paar weitere Nutzer ihre Meinung abgeben, die größere Breite der Tabelle sollte aber kein Problem sein, immerhin ist sie sowieso wesentlich schmaler als die aktuell verwendete Tabelle. (So viel schmaler sogar, dass man sich überlegen könnte, zusätzlich zum Rechner eine Doppelspalte (also Lv. 50 und Lv. 100) der bisherigen Tabelle beizubehalten. Muss aber nicht sein, ist nur eine Idee.)
Edit: Und noch ein "Bug": Die meisten Buchstaben kann man in die Felder nicht mehr eingeben, "e" aber schon. Und man kann damit z.B. die Obergrenze bei den FP umgehen, wenn man z.B. 5e5 eingibt (entspricht 500.000), dann sieht man wieder die riesigen Balken. Bei den DV hat das "e" auch eine Bedeutung, wird interessanterweise allerdings nicht so wie bei den FP ausgewertet. --Lasagne (Diskussion) 10:36, 23. Mai 2019 (CEST)
Hallo, ich melde mich jetzt auch mal zu dem Thema. Zu allererst mal, danke Robbi für die Programmierung, der Rechner ist wirklich gut geworden. Wenn es die Seiteladezeit nicht verlängert, dann würde ich es bevorzugen, wenn er im Pokémon-Artikel steht. Wozu so eine schöne Option auf eine Spezialseite bringen, wenn man dann sogar zusätzlich einen Pokémon-Button einprogrammieren müsste? Was die Wesen angeht könnte man überlegen ob man, wie Lasagne meinte, Kurzbeschreibung mit +Ang etc. hinter die Wesen schreibt, damit man noch vor dem Auswählen sieht, was das jeweilige Wesen bewirkt. Zur besseren Unterscheidung und der Hauptspiel-Orientierung könnte man ja das +Ang hinter dem Wesen zusätzlich rot einfärben und den negativen Wert hellblau. Also z. B. Solo (+Angr. -Vert.). Zusätzlich könnte man in diesem Fall den Schriftzug von Angriff rot färben und den von Verteidigung hellblau, das ist aber kein Muss. Bei dieser Methode müsste man dann gucken, wie lang die Tabelle dadurch wird. Zwei Kleinigkeiten, die ich noch etwas unschön finde: 1. die beiden verschieden „Balken-Blöcke“ sind sehr unverhältnismäßig. Z. B. in der Voreinstellung sind beide Spez.-Vert.-Balken gleich lang, obwohl der rechte 3x so groß sein müsste. Es muss nicht genau verhältnismäßig sein, aber die Basiswert-Balken könnten ja ein wenig kürzer und die anderen dafür länger, die nötige Breite ist ja noch vorhanden. Dadurch würden dann die Kurzbeschreibungen hinter den Wesen die Tabelle auch nicht zusätzlich verlängern. Dann stört mich noch optisch diese kleine weiße Spalte als Trennung. Könnte man die nicht ein wenig verändern, vielleicht auch lila einfärben, sprich eine kleine lila „Trennspalte“ daraus machen anstatt zwei? Cliffichen 10:56, 23. Mai 2019 (CEST)
Soweit ich mit Robbi gesprochen habe kommt der "Bug" mit e leider aus dem Browser (konkret aus Chrome) weil dieser e als Zahl akzeptiert (eben weil man 500000 auch als 5e5 schreiben darf) - andere Broswer, z. B. Firefox untersützen aber das "nur Zahlen eifügen" gar nicht, weshalb man da immernoch nach belieben Unsinn eingeben kann; aus diesem Grund wäre ich dagegen das NaN bei leerem Feld abzuändern, dieses wird beispielsweise auch bei Level f angezeigt, was sich nicht wirklich von Level (nichts) unterscheidet.
Ein anderes Ding das mir eigefallen ist: Müsste man diesen Rechner nicht auch noch für andere Generationen brauchbar machen? Es gibt ja genügend Pokémon die im Laufe der Zeit Änderungen an ihren Werten erfahren haben, es gab Änderungen in der Berechnung und es gab sogar andere Mechaniken in Gen 1 und 2. So spontan fällt mir auch noch Lets Go mit den Bonbons ein, die man wahrscheinlich auch noch berücksichtigen müsste...
Ich bin ehrlich, mich stören die Pfeile hier eher; die Idee um genau 4 zu senken gilt doch nur für Pokémon Level 100? Für tiefere Level meine ich sind die "sinnvollen" Unterschiede grösser, weshalb ich auch da davon absehen würde (und stattdessen die individuellen Pfeile einfach wegwerfen würde) --Datei:Sugimori 672.pngMecanno-manMäh 13:21, 23. Mai 2019 (CEST)
Zum e: Okay, trotzdem ist es möglich, bei der Berechnung maximal 252 FP zu nehmen. Man kann es aber natürlich auch so lassen, wie es jetzt ist, das wäre immerhin ein lustiges Easteregg. Ich habe mir noch die JavaScript-Datei zum Rechner angeguckt, um zu prüfen, warum das e bei den DV anders behandelt wird als bei den FP, und gesehen, dass bei den FP die Division durch vier noch im parseInt-Aufruf getätigt wird. Wenn man die Division außerhalb davon tätigt, würde das e wie bei den DV nicht als Exponent interpretiert werden. Dann müsste man aber noch Math.floor anwenden, um wieder auf eine Ganzzahl abzurunden.
Zum NaN: Meiner Meinung nach ist die Anzeige von NaN immer unschön und sollte falls möglich vermieden werden. In diesem Fall könnte man einfach mit einem Standardwert (z.B. Level 1) rechnen, wenn irgendein Unsinn oder nichts eingegeben wurde, genau wie das bei den FP und DVs bereits jetzt gemacht wird (mit 0 als Standardwert).
Zu den anderen Generationen: Meiner Meinung nach ist es nicht notwendig, den Rechner auch für Generation 1 und 2 nutzen zu können. Sie wurden in der bisherigen Tabelle bereits nicht behandelt (zumindest nicht bei den tatsächlichen Werten) und ich schätze mal, dass diese Funktion so selten gebraucht würde, dass es zu vertreten ist, wenn man auf eine externe Seite oder manuelles Rechnen ausweichen muss, um die Statuswerte dafür zu erhalten. Die Awakening values aus Pokémon Let's Go! sind da schon eine andere Sache, da sie zumindest aus einem aktuellen Spiel stammen. Meiner Meinung nach kann man sie aber ebenfalls ignorieren, da ihre Auswirkungen sehr leicht im Kopf zu berechnen sind (pro AV-Punkt ein Statuswerte-Punkt, unabhängig von Level und Wesen) und sie bei den "regulären" Pokémon-Editionen wohl auch in Zukunft nicht vorkommen werden (hoffe ich zumindest, werden wir ja in Schwert und Schild sehen).
Zu den Pfeilen: Ich finde gar nicht, dass die stören. Sie werden ja auch immer nur beim ausgewählten Feld angezeigt, sorgen also auch nicht für eine optische Überladung der Tabelle. Und der Sprung um jeweils vier Punkte ist deswegen sinnvoll, weil die FP immer durch vier geteilt und dann abgerundet werden. Nur auf Level 100 gibt es dabei zwar wirklich einen Statuswerte-Punkt pro vier FP, aber auch auf allen anderen Leveln können sich die Statuswerte nur bei durch vier teilbaren Fleißpunkten erhöhen. (Z.B. gibt es auf Level 80 grundsätzlich einen Statuswerte-Punkt pro fünf FP, wenn man das aber mit geraden DV und neutralem Wesen ausprobiert, sieht man, dass der Statuswert nicht bei 5 FP, 10 FP, 15 FP, usw., sondern bei 8 FP, 12 FP, 16 FP, 20 FP, 28 FP, usw. nach oben springt.) --Lasagne (Diskussion) 19:48, 23. Mai 2019 (CEST)
Wenn wir schon dabei sind sehe ich keinen Grund den Rechner nicht gleich für alte Generationen mitzuprogrammieren; was das NaN angeht: Robbi meinte da das das noch nicht fertig sei, was das verhindern von Unsinnseingaben angeht. Zur Sache mit den Pfeilen: Ich fürchte da müssen wir mal gross drüber wie verschiedene Browser das darstellen. Ich hab das auf Firefox/Ubuntu aufgerufen, das Ergebnis war schrecklich - ich sehe aber jetzt auch in Chrome/Windows 10 das es da schon sehr gut funktioniert. Schlussendlich wird man das wahrscheinlich einfach mal durch eine der Broswervergleichseiten hauen müssen wenns mal fertig ist. --Datei:Sugimori 672.pngMecanno-manMäh 21:35, 23. Mai 2019 (CEST)
Dass die Pfeile in anderen Browsern so schlimm aussehen, hätte ich nicht gedacht. In einigen anderen Browsern (z.B. Edge, Internet Explorer, Chrome für Android) werden sie einfach gar nicht angezeigt.
Ich habe mir übrigens die HTML- und JavaScript-Dateien nochmal genauer angeguckt und ein paar Dinge ausprobiert (habe mit HTML und JavaScript nicht viel Erfahrung):
- Dass die kleinen Pfeile (oder das Drücken der Pfeiltasten auf der Tastatur) bei den FP-Feldern den Wert auf den nächsthöheren bzw. -niedrigeren durch vier teilbaren Wert setzen, ist recht leicht umzusetzen, indem man das Attribut step="4" hinzufügt.
- Momentan werden die Werte alle 10 Millisekunden neu berechnet, unabhängig von den Eingaben. Das sorgt bei mir dafür, dass diese Seite alleine immer etwa 3 bis 6 % CPU-Leistung verbraucht, wenn ich sie anschaue, ohne Eingaben zu machen. Wenn ich die Methode setInterval() entferne und stattdessen das Attribut oninput="updateStatuswerte()" bei allen Feldern und onchange="updateStatuswerte()" bei der Auswahl des Wesens hinzufüge und in den Methoden minimizeFP() und Co. auch die Methode updateStatuswerte() aufrufe, kann ich den CPU-Verbrauch der Seite auf 0 bis 0,5 % senken, ohne die Funktionalität zu ändern.
Außerdem habe ich noch einen Bug entdeckt: Die Wesen Kühn und Mäßig funktionieren aufgrund der Sonderzeichen aktuell nicht.
--Lasagne (Diskussion) 23:11, 23. Mai 2019 (CEST)
Um den eigentlichen Code brauchst du dir keine Sorgen zu machen, im Moment sind wir in der Aufbauphase, optimiert wird, wenn alles korrekt ausgeführt wird zwinker3.gif -- RobbiRobb 23:24, 23. Mai 2019 (CEST)
Ich bitte nur darum, nicht nur zu berücksichtigen, was technisch alles möglich ist, sondern auch was aus Anwendersicht Sinn macht. So n Rechner sollte so viele Funktionen wie nötig und so wenige wie möglich enthalten. Daher sind, wie gesagt, die Einzelpfeile einfach nicht sinnvoll, weil es keinen sinnvollen Anwendungsfall gibt, wo Werte in Einerschritten durchgeschaltet anstatt manuell eingegeben werden. Lasst die Pfeile einfach weg, dann spart man sich das optimieren. ^^ Pokémon-Icon_674.png Maxmiran 10:17, 24. Mai 2019 (CEST)

Zeit für die nächsten Änderungen: Version 3 ist online. Im Vergleich zum letzten Mal sind die Änderungen allerdings um einiges kleiner ausgefallen, ich habe noch einmal die "Sicherheit" der Eingaben überarbeitet, ansonsten sind die meisten Vorschläge recht kleiner Natur gewesen. Hier noch einmal in Kürze die Änderungen:

  1. Das FP-Maximum ist auf 252 begrenzt, da alle Werte darüber ohnehin keine Auswirkungen haben. Den step auf 4 zu setzen ist jetzt allerdings leider nicht mehr möglich, da ich die Art der Eingabe geändert habe, dazu aber gleich mehr.
  2. Alle Eingaben haben jetzt ein Default, wird das Feld also leer gelassen, werden die Werte intern maximiert. So umgehen wir die unschönen NaN an dieser Stelle.
  3. Der Rechen-Fehler aufgrund der fehlenden Rundung ist jetzt auch eingefügt. Da ich gerade zum ersten Mal mit Statuswerten rechne, war mir das nicht bekannt und da unsere Formel im Hinblick darauf scheinbar falsch ist, habe ich das logischerweise falsch übernommen. Jetzt sollte dieser Fehler aber nicht mehr auftreten.
  4. Für eine zusätzliche Nutzerfreundlichkeit habe ich ein weiteres, negativstes Wesen eingefügt. Dies steht nun ebenfalls im dropdown zur Auswahl.
  5. Die Überschrift der Werte wurde geändert, 100 % zufrieden bin ich immer noch nicht, das zu ändern wird aber so einfach, dass man es selbst im bereits laufenden Betrieb noch erledigen könnte. Daher mache ich mir da keinen großen Gedanken, wenn wir da nicht direkt etwas perfektes haben.
  6. Aufgrund der scheinbar recht hohehn Unzufriedenheit mit den Pfeilen an den Eingabefeldern aufgrund vom Browser abhängiger Designs und scheinbarer Nutzlosigkeit, habe ich diese kurzerhand entfernt. Das ging aber nur, indem ich den Typ der Eingabefelder geändert habe, diese sind jetzt Textfelder, die alle Zeichen rausfiltern und lediglich die Eingabe von Zahlen sowie das Verwenden von Steuerungstasten erlauben. Somit ist es nun nahezu unmöglich, irgendwas unvernünftiges in die Felder einzugeben - und wenn es doch jemand macht, dann hat der halt einfach pech gehabt, in nen Taschenrechner gibt man auch keine Buchstaben ein und wundert sich dann, warum es merkwürdige Ergebnisse gibt. Was es noch zu testen gilt ist, ob das auch mobil funktioniert, da wäre es schön, wenn der eine oder andere das mal testen und mir mitteilen könnte ^^

Abschließend noch ein paar Hinweise so am Rande:

  1. Ja, der Spezialfall Ninjatom ist mir bekannt, bislang aber noch nicht implementiert. Wenn das ganze ins Wiki überführt wird, werde ich mich darum aber kümmern ^^
  2. Die unproportionale Länge der Balken wurde zur Kenntnis genommen, beim Übersetzen der Vorlage in Wiki-Code werde ich dafür sorgen, dass diese Diskrepanz nicht mehr auftritt.
  3. Da die Kennzeichnung der Auswirkungen der Wesen scheinbar noch für einiges an Gesprächsstoff sorgt, werde ich dort zunächst nichts machen, ich denke das muss auch nicht sofort entschieden werden, da können wir auch einfach erst mal noch ein paar Meinungen zu sammeln.
  4. Da ich ohnehin einen großteil der Inputs überarbeitet habe, habe ich auch die vorgeschlagenen Syntax-Änderungen zur Verringerung der Systemlast durchgeführt. Ich weiß auf jeden Fall noch das eine oder andere, was sich optimieren lässt, darum können wir uns wie gesagt aber auch noch kümmern, wenn wir mit Design und Funktionen zufrieden sind.

Das ist dann zunächst auch schon alles von mir. Ich denke, dass wir dann also zeitnah eine Abstimmung starten können, um darüber zu entscheiden, wohin das ganze soll. Wenn es also noch etwas gravierendes zu besprechen gibt, bevor wir diese Abstimmung durchführen, teilt mir das bitte jetzt mit, ansonsten werde ich die vermutlich im Laufe des morgigen Tages (Samstag) starten. -- RobbiRobb 11:58, 24. Mai 2019 (CEST)

Danke für die erneute Überarbeitung und die vielen Veresserungen, RobbiRobb! Mobil (zumindest in Chrome für Android) kann man jetzt jeglichen Unsinn in die Felder eingeben, dabei kommt dann auch NaN raus, zumindest bei den FP-Feldern.
Nochmal zur angeblichen Nutzlosigkeit der Zahlenfelder, mit denen die kleinen Pfeile daherkommen: Bei mobilen Browsern, die das unterstützen (z.B. Chrome), sorgen sie auch dafür, dass man eine Bildschirmtastaur angezeigt bekommt, mit der nur Zahlen eingegeben werden können, was ziemlich praktisch ist. Bei PCs kann man in unterstützen Browsern mit den Pfeiltasten der Tastatur den Wert erhöhen oder senken (nicht nur in Chrome, sondern z.B. auch in Edge), auch das ist oft praktischer, als den Wert immer manuell eingeben zu müssen. Und sie werden z.B. bei den EV-Feldern (bzw. FP-Feldern) im Damage Calculator (Schaden-Rechner) von Pokémon Showdown (gehört zu Smogon) verwendet, so nutzlos können sie also nicht sein. Dass sie in einigen Browsern unschön dargestellt werden, ist natürlich ein Problem, aber sie haben auch einige Vorteile.--Lasagne (Diskussion) 13:33, 24. Mai 2019 (CEST)

Abstimmung: Darstellung der Statuswerte

Abstimmung beendet: 1 Stimme für Option 2, 19 Stimmen für Option 4, 2 Enthaltungen. Option 4 wird umgesetzt.

Bei dem Ergebnis scheint das Ergebnis ja recht klar zu sein. Ich werde mich also darum kümmern, die Darstellung der Statuswerte zu überarbeiten, zunächst wird die Vorlage in den Pokémon-Artikeln überarbeitet, da diese eine höhere Präsenz hat und anschließend werde ich mich der Erstellung einer Spezialseite widmen. Sollte es noch weitere Verbesserungsvorschläge oder Verbesserungswünsche geben, lasst sie mich am besten direkt hier wissen, dann kann ich sie ggf. noch übernehmen ^^ -- RobbiRobb 01:46, 9. Jun. 2019 (CEST)

Inzwischen wurde der Statuswerte-Rechner ja implementiert und das Ergebnis kann sich meiner Meinung nach sehen lassen. Ich freue mich, das aus meinem ursprünglichen Vorschlag eine noch viel bessere Idee entstanden ist und jetzt auch umgesetzt wurde. Ich möchte trotzdem an dieser Stelle noch ein paar Fehler melden bzw. Verbesserungsvorschläge machen:
  • Wird ein FP- oder DV-Feld freigelassen, z. B. weil man einen neuen Wert eintippen möchte, wird momentan anscheinend mit -1 oder einem anderen negativen Wert gerechnet, dabei können sich auch Werte ergeben, die auf dem Level gar nicht möglich sind. Ich denke, es ist besser, wenn in diesem Fall stattdessen mit 0 gerechnet würde. Auch beim Level selbst wird anscheinend mit -1 gerechnet, wenn man das Feld freilässt, bei einem Pokémon wie Pottrott erhält man dabei sogar negative Statuswerte. Beim Level ist es wahrscheinlich am besten, bei einem leeren Feld mit einem Level von 1 zu rechnen.
  • Bei sehr langen Balken ändern sich die Größenverhältnisse zwischen den Spalten der Tabelle. Das ist grundsätzlich zwar kein Problem, aber bei Pokémon wie Heiteira gibt es dann „Sprünge“, die wahrscheinlich nicht gewollt sind, wenn man z. B. zwischen Level 100 und 10 wechselt oder die Pfeile benutzt. Dieses Problem tritt aber nur bei Pokémon mit solch extremen Werten auf (nach meinen Tests ab einem KP-Basiswert von 150 oder einem anderen Basiswert ab 173), die meisten Pokémon sind davon also verschont.
  • Für die meisten Begriffe wurden ja praktischerweise bereits Links zu den entsprechenden Artikeln eingefügt, meiner Meinung nach sollte man dann aber auch die Begriffe Statuswerte und DV entsprechend verlinken (evtl. auch FP ein zweites Mal).
  • Das hätte mir am besten bereits vor der Implementierung ins PokéWiki auffallen sollen: Ich denke, man sollte die Spalten FP und DV tauschen, sodass also erst die Basiswerte, dann die DVs, dann die FP und schließlich die resultierenden Werte kommen. Das ist natürlich keine so wichtige Sache, meiner Meinung nach wäre dies aber die sinnvollere Reihenfolge, dafür gibt es auch ein paar Gründe:
    • In der Statuswerte-Formel kommen diese Parameter auch in dieser Reihenfolge vor (Basiswert, DV, FP).
    • Man hat einen Übergang von einem festgelegten, nicht veränderbaren Wert (Basiswert) zu einem nicht festgelegten, nicht veränderbaren Wert (DV) zu einem nicht festgelegten, veränderbaren Wert (FP).
    • Diese Reihenfolge wird auch von anderen Statuswerte-Rechnern genutzt, z. B. auf Smogon.
  • Außerdem möchte ich noch auf die Kurzbeschreibungen der Wesen zu sprechen kommen: Es gab zwar leicht verschiedene Ideen, wie genau das umgesetzt werden könnte, soweit ich sehe, gab es aber niemanden, der sich explizit gegen eine solche Kurzbeschreibung ausgesprochen hat. Deswegen denke ich, dass diese Funktion noch irgendwie implementiert werden sollte. Am einfachsten wäre es, hinter dem Wesen kurz den Effekt in Klammern anzugeben (also z. B.
    „Hart (+Angr., -Sp.-Ang.)“). Noch schöner wäre es, den Vorschlag von Cliffichen umzusetzen und diese Kurzbeschreibung farblich zu markieren (also z. B.
    „Hart (+Angr., -Sp.-Ang.)“), falls das in einem Dropdown-Menü aber nicht ohne Weiteres möglich ist, sind auch die schwarzen Kurzbeschreibungen besser als gar keine, denke ich. Die Länge der Kurzbeschreibungen sollte jetzt jedenfalls kein Problem darstellen, rechts neben dem Wesen-Feld ist ja noch massenweise Platz. (Deswegen muss man auch nicht zu heftig abkürzen, sondern kann auch Angriff und Initiative ausschreiben, wie es aktuell auch in den Spielen gemacht wird.)
    Wenn man das umsetzt, kann man dabei auch die Reihenfolge der Wesen leicht ändern, momentan ist quasi der Wert Initiative vor Spezial-Angriff und Spezial-Verteidigung eingeordnet, obwohl er eigentlich dahinter kommen sollte. (Momentan ist die Reihenfolge:
    Robust (neutral), Solo (+Angr., -Vert.), Mutig (+Angr., -Init.), Hart (+Angr., -Sp.-Ang.), Frech (+Angr., -Sp.-Vert.), sie sollte aber sein:
    Robust (neutral), Solo (+Angr., -Vert.), Hart (+Angr., -Sp.-Ang.), Frech (+Angr., -Sp.-Vert.), Mutig (+Angr., -Init.)) --Lasagne (Diskussion) 21:09, 29. Jul. 2019 (CEST)
Während Buo sich bereits heute Vormittag um die technischen Änderungen gekümmert hat (inklusive des Fehlers, der hier zu finden ist), habe ich nun die anderen Kleinigkeiten nachgetragen. Zusammenfassung: Die Rechenfehler sollten jetzt behoben sein, DV und FP wurden vertauscht sowie verlinkt (beim Link bin ich noch sehr skeptisch, da er direkt neben den Knöpfen ist, eventuell müsste man den wieder entfernen emot-rolleyes.gif) und auch die kurzen Hinweise wurden hinzugefügt - allerdings nicht farblich, <option> unterstützt leider nur eine Farbe für den gesamten Text innerhalb der Option. Grund für den bisherigen "Reihenfolgen-Fehler" war, dass ich einfach die Wesen aus den Textdumps kopiert habe, weil ich wie bereits mehrfach erwähnt habe nicht den blassesten Schimmer habe, was das alles überhaupt zu bedeuten hat, ich kann nur etwas programmieren und nur Vorlagen schreiben :D Außerdem ist mir noch nicht klar, was das Problem bei den Größenverhältnissen der Tabellen sein soll, ich konnte zwar ein paar Unstimmigkeiten feststellen, die waren aber Browserseitig und es hat gereicht, das "Bild" neu korrekt zu erzeugen, indem man ein mal von der Tabelle weggescrollt hat und wieder hin, wenn nicht das das Problem ist, wäre ich für eine genauere Erklärung dankbar. Abgesehen davon habe ich jetzt hoffentlich aber alles. -- RobbiRobb 00:36, 4. Okt. 2019 (CEST)
Erstmal vielen Dank für die Überarbeitung!
  • Was ich mit den Größenverhältnissen in der Tabelle meinte, ist hier zu sehen. Wenn man zwischen Level 10 und 100 wechselt, ändert sich die Breite der letzten drei Spalten, obwohl dies nicht nötig wäre, da der 714 KP-Balken auch in die kleinere "Resultierende Werte"-Spalte gepasst hätte, die bei Level 10 dargestellt wird. Da das aber nur wenige Pokémon betrifft und nicht so störend ist, wäre es auch nicht so schlimm, wenn es so bleibt wie jetzt.
  • Und bei den Wesen meinte ich eigentlich, dass sich die geänderte Reihenfolge durch die gesamte Liste ziehen sollte, die von mir aufgezählten Wesen waren nur als Beispiel gedacht. Insgesamt sollte die Reihenfolge also sein:
    (Maximum, Minimum,) Robust, Solo, Hart, Frech, Mutig, Kühn, Sanft, Pfiffig, Lasch, Locker, Mäßig, Mild, Zaghaft, Hitzig, Ruhig, Still, Zart, Sacht, Kauzig, Forsch, Scheu, Hastig, Froh, Naiv, Ernst
    Das entspricht der Reihenfolge aus dem Wesen-Artikel, wenn man die Spalten hintereinander auflistet.
  • Als letztes ist mir aufgefallen, dass "Statuswerte" ganz links oben in der Tabelle noch nicht verlinkt wurde. Das wäre meiner Meinung nach noch ganz sinnvoll, da dort ja auch die Formel zu finden ist, auf der dieser Rechner basiert. -- Lasagne (Diskussion) 14:09, 4. Okt. 2019 (CEST)
So, die Reihenfolge wurde überarbeitet und der Link in der Tabelle oben hinzugefügt. Gegen das Verrutschen kann ich glaube ich nichts machen, das liegt am Browser. Die Felder haben keine Fixe breite sondern richten sich nach ihrem Inhalt und der Größe der gesamten Tabelle. Daher rutscht das, wenn das extrem breit wird (selbst, wenn noch genug Platz wäre) -- RobbiRobb 21:03, 7. Okt. 2019 (CEST)
Stumpfe Frage und hat überhaupt nix mit dem eigenen Diskussionsthema zu tun, aber: Hätte man nicht den Wesensartikel an die Vorlage anpassen sollen, wenn das die spielinterne Reihenfolge ist? (Von der ich btw ausgehe das sie irgendwo; z. B. bei diesem Wilde-Wesens-Beeinflusser aus Lets Go, sichtbar ist.) Oder ist die Wesensartikelreihenfolge irgendwo durch einen Guide oder so etwas bestätigt? --Datei:Sugimori 672.pngMecanno-manMäh 21:15, 7. Okt. 2019 (CEST)
Die Reihenfolge im Wesen-Artikel basiert auf der Reihenfolge, in der die Statuswerte im Spiel seit der zweiten Generation dargestellt werden: KP, Angriff, Verteidigung, Spezial-Angriff, Spezial-Verteidigung, Initiative. Da diese Reihenfolge sehr oft so in den Spielen gezeigt wird, ist es meiner Meinung nach sinnvoll, sie auch als Grundlage für die Reihenfolge der Wesen zu nehmen, anstatt eine spielinterne Reihenfolge zu verwenden, die in den meisten Spielen nirgendwo zu sehen ist. Ich weiß auch nicht genau, warum anscheinend spielintern diese andere Reihenfolge (KP, Angriff, Verteidigung, Initiative, Spezial-Angriff, Spezial-Verteidigung) zumindest stellenweise verwendet wird, ich schätze aber, dass dies historische Gründe hat. In der ersten Generation stand "Spezial" im Bericht noch hinter der Initiative, vielleicht wurden Spezial-Angriff und Spezial-Verteidigung, als sie in der zweiten Generation eingeführt bzw. getrennt wurden, einfach an die Stelle von "Spezial" eingefügt, also ans Ende der Statuswerte-Reihenfolge, und es wurde für die zukünftigen Spiele so gelassen? -- Lasagne (Diskussion) 21:37, 7. Okt. 2019 (CEST)

Änderungen an MediaWiki:Sidebar

Vorweg für die, die es nicht wissen: Die Sidebar ist für das Dropdown-Menü verantwortlich, dass ihr alle oben links unter dem Headerbanner sehen solltet. Da das nun aus dem Weg ist, komme ich zum eigentlichen Anliegen: Vor einiger Zeit, als mal wieder das Thema der Social-Media-Icons im VC auf Discord aufkam, kam Tai und mir die Idee, die Links doch zumindest mal in die Sidebar aufzunehmen, da die Icons selbst ja scheinbar nicht in absehbarer Zeit zum Einsatz kommen. Das Ergebnis habe ich kurzerhand im Testwiki umgesetzt, da das aber zeitnah zurückgesetzt wird, war ich so frei und habe das ganze archiviert, sodass ihr euch das hier auch weiterhin anschauen könnt. Selbstverständlich ist das ganze auch als Dropdown geladen, ihr könnt es euch also bereits im Einsatz auf dieser Seite anschauen. Wie unschwer zu erkennen sein sollte hat sich einiges verändert, daher möchte ich um Feedback bitten, ob sich einige Einträge vielleicht anders besser unterbringen lassen bzw. ob eine Änderung überhaupt gewünscht ist, möglicherweise ist ja auch der eine oder andere mit der aktuellen Version zufrieden(er). Auch für weitere Ergänzungen bin ich offen, wenn euch also irgendwas dazu einfällt, immer her damit ^^ -- RobbiRobb 20:39, 15. Okt. 2019 (CEST)

Die Änderung fände ich gut. Mal abgesehen davon, dass dann die Facebook- und Twitter-Accounts mehr Aufmerksamkeit erlangen könnten (ich habe erst über Discord erfahren, dass wir einen Facebook- und einen Twitter-Account haben, da ich damals nie irgendwo im Wiki was dazu gesehen habe (ich muss aber auch anmerken, dass ich sowieso vor meiner Anmeldung nicht wirklich mit offenen Augen durchs Wiki stolziert bin)), erhalten die Links unter der "Kommunikation"-Überschrift (und der Rest eigtl. auch) mehr Aufmerksamkeit, da dann weniger Links pro Spalte/Überschrift vorhanden sein würden. Und das Aussehen der Sidebar wäre im Allgemeinen mMn schöner (freier Platz neben dem Greenchu wird "verkleinert" bzw. von Inhalt "benutzt"). Änderungswünsche sind bei mir bisher nicht aufgetreten, bei Bedarf werde ich die euch natürlich mitteilen.--DeXter 21:30, 15. Okt. 2019 (CEST)
Es ist vielleicht noch anzumerken, dass neben der Integration unserer sozialen Kanäle auch etwas aus der Sidebar herausgenommen wurde, was in unseren Augen im heutigen Wiki nicht mehr in dem Maße genutzt wird, wie es vielleicht mal der Fall gewesen ist: Das PokéWiki:Portal. Für uns ersetzen die Portale auf der Hauptseite (siehe Vorlage:Hauptseite/Rampenlicht) weitestgehend das ältere Portal im Zusammenspiel mit der vorgeschlagenen und somit neuen Sidebar. Solltet ihr ebenfalls der Meinung sein, dass wir das alte Portal nicht mehr in dem Umfang nutzen, wie es für ein Portal nötig wäre, könntet ihr trotzdem einmal schauen, ob euch irgendetwas an Informationen aus diesem noch im neuen Zusammenspiel zwischen Sidebar + Rampenlicht fehlen würde. Natürlich könnt ihr euch auch dahingehend äußern, dass das alte Portal – in welcher Art und Weise auch immer – erhalten werden sollte. ;) ~ Taisuke Diskussion 08:54, 16. Okt. 2019 (CEST)
Kleiner Verbesserungsvorschlag von mir: Wer ist online? sollte nicht unter Kommunikation gelistet werden, da es keinerlei kommunikative Rolle einnimmt. Bin mir ehrlichgesagt aber grad auch nicht sicher ob man das überhaupt irgendwo vernünftig einbauen kann (PokéWiki passt auch nur so mässig), weshalb ich dazu tendieren würde dies ebenfalls zu entfernen. --Datei:Sugimori 672.pngMecanno-manMäh 11:08, 16. Okt. 2019 (CEST)
Grundsätzlich bin ich auch glücklich, dass eine Änderung des Portals geplant ist. Die sozialen Medien dort unterzubringen, finde ich fast schon überfällig, auch wenn ich nach wie vor eine prominentere Platzierung – außerhalb der Sidebar – bevorzugen würde. Das Portal muss meiner Meinung nach nicht unbedingt raus, da es deutlich strukturierter und umfangreicher als das Hauptseitenportal ist. Habt ihr zum Portal vielleicht Besucherzahlen verfügbar, um die Entscheidung zu erleichtern? Wie Mec bereits angesprochen hat, ist das „Wer ist online?“ an der Stelle fehl am Platz. Hier sollte man sich überlegen, welche Abschnitte des Portals sich an Besucher und welche an Autoren richten. Beides durchzumixen erscheint mir nicht sinnvoll und ob wir die Aktivitätenliste überhaupt in der Sidebar brauchen, ist nochmal ein anderer Punkt. Mir reicht es eigentlich, diese über die LÄ einzusehen. Auch erscheint es mir ein bisschen komisch, das Forum an erste Stelle zu setzen, wenn wir eigentlich schon länger stärker auf Discord bauen. Ich würde das Forum eigentlich eher hinter die sozialen Medien setzen. Vielleicht würde ich auch die AD stattdessen in den PokéWiki-Teil verschieben und bei Kommunikation stattdessen die Auskunft einfügen, damit wir Bereiche, die primär für Besucher sind, von Bereichen, die primär für Autoren sind, voneinander trennen. Vielleicht würde ich deswegen gar den Kommunikationsteil vor den PokéWiki-Teil setzen. Auch den Link für eine zufällige Seite könnte man meiner Meinung nach in den Navigationsteil verschieben, da er dort meiner Meinung nach besser untergebracht ist. Einen letzten (lang ersehnten) Wunsch hätte ich noch, wobei ich denke, dass dies über die Toolbox und nicht direkt über die Sidebar geregelt wird: Auf Benutzerseiten hätte ich gerne einen Link auf den jeweiligen Beitragszähler des Benutzers in der Sidebar. Falls das möglich sein sollte, wäre ich definitiv sehr glücklich.
Ich habe jetzt deutlich mehr als erwartet geschrieben und hoffe dass man trotzdem noch alle Vorschläge raus lesen kann. Sind letztendlich auch wirklich alles nur Vorschläge, schlecht ist das aktuelle Konzept auch nicht, aber vielleicht stimmt ihr mir ja in dem einen oder anderen Punkt zu. :) ✧✦ Pk-fan 18:14, 16. Okt. 2019 (CEST)
Sehe das zum Großteil wie Pk. Den "Wer ist online?"-Button halte ich für überflüssig in der Sidebar, der reicht in den LÄ. Auch sollte Discord vor filb erscheinen, schließlich ist das der Ort, wo wir uns am meisten austauschen. Die Allg. Diskussionsseite ist ja nicht wirklich zum kommunizieren da, sondern zum Besprechen von Wiki-Angelegenheiten, weswegen das unter dem Punkt auch besser aufgehoben wäre. Die Auskunft bietet sich da schon eher an, wobei das unter Hilfe auch nicht fehl am Platz ist. Ich kann da mit beidem leben. Einen Beitragszähler fände ich auch schön, möglich müsste das ja denke ich auch sein. -- Cliffichen 19:05, 16. Okt. 2019 (CEST)
Da der Link zum Beitragszähler weniger mit Ordnung und mehr mit erleichterte Bedienung zu tun, war ich so frei, Buo direkt zu bitten, diesen Link einzufügen. Es ist ab jetzt (wieder? emot-rolleyes.gif) möglich, direkt von der Benutzerseite sowie der Benutzerdiskussionsseite auf den Beitragszähler des Benutzers zuzugreifen :) -- RobbiRobb 19:22, 16. Okt. 2019 (CEST)
Oh, ja, Auskunft mit reinnehmen würde ich unterstützen. Tendiere dazu der Gewohnheit halber den PokéWiki-Teil vor den Kommunikations-Teil zu nehmen (hauptsächlich wegen der letzten Änderungen), dies ist aber wie gesagt nur der Gewohnheit wegen, was nicht wirklich ein gutes Argument ist. --Datei:Sugimori 672.pngMecanno-manMäh 23:42, 16. Okt. 2019 (CEST)
Robbi hat mich grad eines besseren gelehrt und gesagt das die Auskunft schon drin ist, hatte die übersehen da ich sie bei Kommunikation erwartet hatte. Würde die dann auch da hin packen wollen. --Datei:Sugimori 672.pngMecanno-manMäh 00:21, 17. Okt. 2019 (CEST)
Hm, der Discord von Filb.de hat mir nicht genug offiziellen Charakter. Ich bin dort ja auch nicht vertreten und weiß im Grunde nicht, was dort überhaupt passiert. Entsprechende „Verantwortung“ mag ich daher nicht übernehmen. Der PokéWiki-Discord-Server hingegen wäre von mir aus in Ordnung. Und wie RobbiRobb schon sagte, der Beitragszähler ist jetzt im Benutzer- und Benutzer-Diskussion-Namespace in der Sidebar verlinkt! ~ 418.gif Buoysel 09:56, 17. Okt. 2019 (CEST)

Zunächst einmal möchte ich mich schon mal für die bisherige Teilnahme an der Diskussion und das ganze Feedback bedanken. Allerdings scheinen einige Missverständnisse sowie Fragen aufgekommen zu sein, auf die ich an dieser Stelle gerne eingehen möchte:

  1. Zumindest von meiner Seite war keine Änderung am Portal geplant, ich habe lediglich den Link auf dieses entfernt, womit ihm eine kleinere Rolle zukommt, da es in meinen Augen nicht mehr so relevant ist, wie es mal war und viele Themen bereits an anderer Stelle besser aufgehoben sind. Änderungen sind natürlich möglich und durchaus auch gerne gesehen, aber das ist eigentlich nicht Bestandteil dieser Diskussion, woher das also kommt weiß ich jetzt nicht.
  2. Ich kann mich durchaus mit einer Entfernung des "Wer ist Online?"-Links anfreunden. Sollte er drin bleiben erschließt sich mir allerdings nicht ganz, warum er im Kommunikations-Abschnitt fehl am Platze sein soll, wie könnte Kommunikation einfacher sein als mit jemadem, der gerade online und erreichbar ist?
  3. Wie genau kommt jetzt der Filb-Discord-Server in diese Diskussion? Der hat da meiner Meinung nach absolut nix drin zu suchen, da er mit uns nichts mehr zu tun hat, sondern nur noch über eine Ecke (Filb selbst) erreichbar ist. Daher ist er auch nicht in dem Vorschlag drin.

Alles weitere meinerseits sind lediglich ein paar Meinungen zu dem bisher gesagten: Trennung von Besuchern und Autoren finde ich gut, hatte ich auch teils angestrebt, hat aber scheinbar nicht gereicht, damit dieser Eindruck auch rüber kommt. Leider haben wir außerhalb des Navigations-Bereichs lediglich die zufällige Seite, die ausgezeichneten Artikel sowie die Mitmachen-Seite, die sich für Besucher als interessant herausstellen könnte, alle weiteren angebotenen Funktionen richten sich ausschließlich an Autoren, da sie bei Bearbeitungen helfen, diese anregen oder eben einen Account benötigen. Daher ist eine derart strikte Trennung vermutlich unnötig, zumindest wenn das ganze einigermaßen ausgeglichen sein soll. Möglicherweise kann man aber anhand anderer Kriterien unterteilen. Das würde dann auch möglicherweise die Frage danach, wohin mit welchem Abschnitt, vereinfachen. Im Moment finde ich es nämlich auch schwer, abseits der einfachen schnellen Links richtet sich das ganze stark an Autoren, lediglich der Hilfen-Bereich ist auch für Besucher interessant, diese müssen sich also zuerst alles andere anschauen. Das kann natürlich hilfreich sein, da es aktiv ins Wiki einlädt, aber da wir mehr Besucher als Autoren haben, kann ich mir durchaus vorstellen, dass diese es praktischer finden würden, wenn die an die Mehrheit gerichteten Links leichter zugänglich sind (=weiter links in der Liste). -- RobbiRobb 12:36, 17. Okt. 2019 (CEST)

Verzeihung, ich hatte mich weiter oben verlesen und dachte, es sei der „Discord von filb“ gemeint gewesen, der hier ja wirklich nichts zu suchen hat. ~ 418.gif Buoysel 12:55, 17. Okt. 2019 (CEST)
Das PokéWiki-Forum würde ich in der „Kommunikation“-Spalte ganz nach unten schieben. Die AD sollte mMn auf jeden Fall über Discord bleiben (auch wenn Discord mehr zur Kommunikation beiträgt), da ich den Social-Media-Block (Discord, Facebook und Twitter) nicht auftrennen will. Der Punkt „Mitmachen“ ist für meinen Geschmack noch zu weit unten, den könnte man direkt unter „Hilfe“ schieben, dann würde er einem auch eher ins Auge fallen (meine Hoffnung mit dieser Umpositionierung ist, dass dann evtl. mehr Besucher auf die Seite stoßen und sich registrieren). Die Idee Besucher-relevante Sachen von Autoren-relevanten Sachen zu trennen finde ich an sich gut, aber sie sollte nicht umgesetzt werden indem man z. B. den Link auf die AD nach „PokéWiki“ verschiebt, da die AD mMn auf jeden Fall zur Kommunikation gehört (für mich ist das Besprechen von Dingen auch Kommunikation). Welche Überschrift wo ist, würde ich eher nach Besuchern als nach Autoren richten (also „Kommunikation“ vor „PokéWiki“ schieben). „Zufälliger Artikel“ passt auch mMn besser in „Navigation“. „Wer ist online?“ finde ich in der Sidebar eher überflüssig, da ich keinen Nutzen für Besucher daraus erkennen kann (für Fragen gibts ja extra die Auskunft). --DeXter 16:18, 17. Okt. 2019 (CEST)
Was das wer ist online angeht: Ich sehe dafür keine kommunikative Verwendung, die wir fördern wollen. Diese unter Kommunikation zu listen scheint mir eher als wäre eine zeitnahe (<1h) Antwort für einen neuen Benutzer wichtiger als die Frage von jemandem beantwortet zu haben, der zumindest glaubt zu wissen wovon er redet (Auskunft). Benutzerdiskussionsseiten sind darüberhinaus auch nicht wirklich der ideale Ort für einen Einstieg ins Wiki. Für Sachen wo der User tatsächlich ne schnelle Antwort haben will ist aber Discord besser geeignet. Für erfahrene Autoren bietet die Liste ebenfalls wenig Hilfe da sie 1) über die LÄ immer noch sehr einfach erreichbar ist und 2) erfahrene Autoren sich an den korrekten Ansprechpartner wenden, ungeachtet dessen ob er gerade on oder off ist. --Datei:Sugimori 672.pngMecanno-manMäh 17:12, 17. Okt. 2019 (CEST)
Sieht soweit gut aus. Aber wer nutzt denn Wer ist online? Das kann doch raus. Ansonsten AD lieber über Forum. Und Mitmachen könnte wirklich etwas höher. ;) Das Isso 08/15 Konter 20:45, 17. Okt. 2019 (CEST)
Ich habe das Herausnehmen des PokéWiki:Portals aus der Sidebar mit einer Löschung des Ganzen gleichgesetzt, weil es im Anschluss nur noch über einen zwei Links auf der Hauptseite und die LÄ zu erreichen ist. Die Besucherzahlen nach einer solchen Änderung werden dann auf jeden Fall nicht mehr stimmen. Für mich gibt es diesbezüglich nur zwei Optionen: a) Es bleibt in der Sidebar oder b) Es kommt raus und wird gelöscht. Aus diesem Grund ist das Portal in dieser Diskussion für mich schon gut aufgehoben. :x ~ Taisuke Diskussion 16:42, 27. Okt. 2019 (CET)

Datamining im PokéWiki

Wer die LÄ verfolgt hat wird festgestellt haben das es hier eine Diskussion gab ob der zugehörige Artikel in den Artikelnamensraum gehört oder nicht. Im Zuge dessen kam folgender Diskussionsbeitrag:

„Ich kann den Grundgedanken sehr gut nachvollziehen, die Quellen bzw. Daten auch irgendwie im PokéWiki zu hinterlegen. Das erlaubt mehr Personen als bisher einen Zugriff auf diese Daten, sodass ein Eintragen der Daten und Nachprüfen auf Fehler einfacher fallen könnte als bisher – sofern sich beim Importieren keine Fehler in die Daten geschlichen haben. In meinen Augen gehört eine solche Auflistung in dieser Form aber nicht in den Artikel-Namensraum. Würde der Artikel „Liste aller Fundorte in Pokémon Sonne und Mond“ heißen und die ganzen redundanten Informationen entfernt werden, sodass pro Ort nur eine Tabelle vorhanden wäre, dann hätte ich nichts gegen den Artikel-Namensraum einzuwenden. In der momentanen Verfassung gehört er aber nicht dorthin. Aber das nur mal als einleitende Randnotiz. ;)

Nehmen wir also mal an, der Artikel soll in seiner jetzigen Form in den PokéWiki-Namensraum. Grundsätzlich könnte man „PokéWiki:Spieldaten“ anlegen und dort erläutern, was es mit den Daten auf den Seiten auf sich hat; auf deren Unterseiten dann diese Seiten zu finden wären. Mein Problem an der ganzen Geschichte ist dann: Wo ziehen wir die Grenze? Belassen wir es nur bei den Encountern oder sollen dort dann bloße Auflistungen von anderen Dingen aus den Dumps ebenfalls zu finden sein (z. B. Zitate, Item + Beschreibungen, Pokémon + Dex-Einträge + Kategorie etc.)? Die Frage wird bestimmt irgendwann aufkommen, weshalb wir uns damit ruhig schon auseinandersetzen sollten. Wenn ja, haben wir ein Problem: Wir stellen damit im Grunde genommen großflächig Dumps offen zugänglich zur Verfügung, was eigentlich nicht unser Anliegen sein sollte.

Während des Schreibens gefällt mir die eingangs erwähnte Lösung für den Artikel-Namensraum irgendwie am besten...“
– Taisuke

Ich habe mir nun erlaubt die Encounter unter PokéWiki:Liste der Pokémon Encounter/Spiel XYZ zu verschieben. Das wieso warum gehört hier nicht her, jedoch finde ich die Grundsatzfrage wo ziehen wir die Grenze und was gehört ins Wiki von Datamining sollte einmal geklärt werden. Wir hatten vor längeren mal Ideen bzgl. einer DB hinter dem Wiki. Diese fand zum damaligen Zeitpunkt großen anklang, es scheiterte jedoch an der Umsetzung. Wie ist hier der heutige Stand der Dinge? Denn das was Tai alles aufgelistet hat sind ja Sachen die in den letzten Jahren aus dem Datamining kamen und händisch in diversen Formen ins Wiki gebracht wurden. Im Endeffekt finden sich diese Dumps aufgearbeitet und in vielen Artikel zerlegt und somit wäre eine Hinterlegung nur eine ansammlung aus allen Artikeln des Wikis. Ich persönlich würde sämtliches was aus Datamining stammt mit verweis auch ins Wiki nehmen wollen. Aber vielleicht lässt sich durch die Encounter auch nochmal das Thema Datenbank neu auffassen was eine Menge arbeit wäre sich aber vielleicht auch mit den vorhanden Datamining erstellen lässt sobald eine Basis in der es Eingetragen werden kann besteht. Wie ist die generelle Meinung dazu im Wiki? Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:49, 9. Nov. 2019 (CET)

Die Idee das iwie als Datenbank zu machen würde ich grundlegend unterstützen; alles öffentlich zugängig zu haben zugegebenermassen etwas weniger - die Dumps formatiert ins Wiki zu nehmen (so wie in der angesprochenen Liste) ist etwas was imo. @Buoysels Entscheidung ist; ich bin dann da zugegebenermassen doch leicht dagegen; sie irgendwo abzulegen wo man nur intern Zugriff drauf hat oder sehr versteckt ist (z. B. wie aktuell Robbis Seite, müsste man dann bloss iwie an Buo bringen) hätte ich nix dagegen, stellt sich dann aber die Frage wie sinnvoll das noch ist, wenn das ganze ziemlich leicht auch sonstwo herzubekommen ist. Falls wir das doch im Wiki machen würde ich jedoch auf einen neuen Namensraum plädieren, stur in den PokéWiki-Namensraum finde ich falsch (weils keine Wikiregeln oder Infos zum Wiki sind), Projektzugehörig scheint ungewünscht, Artikel haben sich schon viele, inkl. mir, dagegen ausgesprochen. --Datei:Sugimori 672.pngMecanno-manMäh 15:09, 9. Nov. 2019 (CET)

Puh, ich weiß ja nicht. Ich wäre eher dagegen, komplette Sammlungen von Spiel-Rohdaten direkt im Wiki zu speichern, da dies den Rechteinhabern womöglich auch ein Dorn im Auge sein könnte, selbst wenn man die Daten in eine HTML-/Wikitext-Darstellung umformt. Ich habe ein ungutes Gefühl dabei. ~ 418.gif Buoysel 16:52, 20. Dez. 2019 (CET)

Da Buo am Ende die Entscheidung zu treffen hat und sich hier gegen solche Artikel – in welcher Form auch immer – positioniert hat, wäre es schön, wenn du dich um die Löschung deiner Seiten kümmerst, Ryu. Im Anschluss kann dieser Diskussionsabschnitt als abgeschlossen angesehen werden. ~ Taisuke Diskussion 17:09, 16. Jan. 2020 (CET)
Für mich war das bisher nicht abgeschlossen da Buoysel auf die Nachfrage ``:thinking: Buo, betrifft dies auch die reinen Encounter? Oder beziehst du dich auf die Ansammlung sämtlichen Dataminings im Wiki? Und das mit der Frage zur DB hast du auch Unterschlagen:see_no_evil:`` bis zum heutigen Datum nie geantwortet hatte. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:16, 16. Jan. 2020 (CET)
🤔 Ich meine ich hatte dazu gesagt: Kein Abladen von Dumps in ihren Rohformaten, weder direkt im Wiki noch als „offizielle“ Wiki-DB. Man muss schon irgendetwas mit den Daten machen, sonst wäre es nur ein urheberrechtlich fragwürdiger Auszug. ~ 418.gif Buoysel 18:10, 18. Jan. 2020 (CET)
@Buoysel: Was sich mir daraus nicht erschließt ist ob etwas wie PokéWiki:Liste der Pokémon Encounter/Pokémon: Let’s Go, Pikachu! und Let’s Go, Evoli! als Liste noch urheberlich fraglich ist oder bereits ordentlich aufbereitet fürs Wiki ist? Sie sind definitiv nicht mehr in dem Rohformat in welche es von den Dataminern kam sondern ordentlich Tabellarisch strukturiert. Und da ist die Kernfrage löschen oder behalten oder weiter aufbereiten was auch immer das für diese Liste bedeuten würde (außer das man die Orte mit eindeutscht). Und falls man sie behält dann wohin damit. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:38, 18. Jan. 2020 (CET)
@Ryuichi: Wenn man die Namen alle auf Deutsch schreibt sowie alles mit passenden Artikeln verlinkt usw., dürfte es passen ^^ ~ 418.gif Buoysel 20:06, 18. Jan. 2020 (CET)
🤔 das sollte das wenigste sein. Nur wohin damit? Als regulärer Listenartikel sind die Meinungen zwiegespalten und rein Projekt könnte man im Notfall machen. Auch wenn ich es eher für Allgemeingut statt Projektzugehörig sehe. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 21:10, 18. Jan. 2020 (CET)
Gute Frage... Eine perfekte Lösung dafür habe ich auch nicht, aber vielleicht ginge es als Unterartikel der Spieleartikel? ~ 418.gif Buoysel 16:48, 27. Jan. 2020 (CET)
Der Artikelnamensraum ist nicht dafür gedacht, solche Artikel zu führen. Der gehört irgendwo in den PokéWiki-Namensraum. --Datei:Sugimori 672.pngMecanno-manMäh 02:21, 29. Jan. 2020 (CET)
Dort stecken sie derzeit. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 06:11, 29. Jan. 2020 (CET)

Installation von TemplateStyles

Die Installation der Extension TemplateStyles erscheint aus folgenden Gründen sinnvoll:

  • Die Stil-Anweisungen aus MediaWiki:Common.css, die sich auf spezifische Vorlagen beziehen, können auf entsprechende verschiedene Seiten verschoben werden, sodass sie nur noch geladen werden falls sie benötigt werden.
    • Der Schutzstatus kann hier beliebig angepasst werden und ist nicht mehr auf Administratoren beschränkt.
    • Weitere style-Anweisungen können in Klassen ausgelagert werden, um Vorlagencode zu vereinfachen und lesbarer zu machen. Die Bearbeitung wird dadurch nicht notwendigerweise eingeschränkt.
  • Es sollte erlauben, das Inhaltsmodell von Vorlage:Groupcolours.css auf sanitized-css zu ändern, sodass hier mögliche Angriffsvektoren für Redakteure wegfallen.

Es wäre übrigens möglich editinterface, edituserjson und editsitejson an weitere Gruppen, wie zum Beispiel die Redakteure, um die Benutzeroberfläche und in Skripten verwendete strukturierte Daten zu verwalten. Seit MediaWiki 1.32 ist es mit diesen Rechten nicht mehr möglich, rohes HTML oder globale JS-/CSS-Dateien zu verwalten, sodass der Zugriff auf die zuvor genannten Rechte nun deutlich unkritischer ist. -- Skelabra2509 (Diskussion | Beiträge) 00:59, 4. Dez. 2019 (CET)

Typenicons und wie wir entscheiden, welche wir nutzen.

Bekanntlich sind die neuen SWSH-Typenicons relativ einheitlich dunkel, weshalb sich die Frage stellt, ob wir diese überhaupt nutzen wollen. Da es hier nicht viele sachliche Argumente gibt (mir fallen konkret nur „Aktualität“ vs „Nutzerfreundlichkeit bzgl. Differenzierbarkeitsgeschwidigkeit“ ein) wäre ich dafür das irgendwie per Abstimmung zu machen. Da diese Entscheidung aber schlussendlich hauptsächlich Leser betrifft wäre ich dafür, diese auch in den Entscheidungsprozess mit einzubeziehen. Aus diesem Grund schlage ich vor, in unseren Social Media-Kanälen (also: FB und Twitter) Umfragen zu machen, welche Icons als Standard genutzt werden sollen (und die Stimmen einfach aufzuaddieren). So könnte man auch mal wieder unsere Social Media-Kanälen etwas Leben einhauchen. Hätte da irgendjemand etwas dagegen? --Datei:Sugimori 672.pngMecanno-manMäh 17:20, 15. Dez. 2019 (CET)

Bin der Idee, auch die Besucher in diese Entscheidung mit einzubeziehen, gegenüber aufgeschlossen, finde es nicht falsch, da auch weitere Meinungen zu berücksichtigen. Finde aber, dass eine ausschließliche Verwedung direkter Abstimmungen bei Twitter und Facebook das Problem auch nicht löst, da Benutzer, die dort keine Konten haben genau so ausgeschlossen sind, als würde man eine Abstimmung im Wiki durchführen; Unterschied wäre lediglich, dass die der Abstimmung zugrunde liegende Benutzerkontenzahl größer ist. Bringt im übrigen auch das Risiko mit sich, dass manche bei beiden Seiten an der Abstimmung teilnehmen werden und andere nicht, dadurch könnte das Ergebnis verfälscht werden. Mit am praktischsten wäre daher meiner Meinung nach eine Abstimmung, die zentral auf einer Seite ist und sowohl über Social Media als auch direkt im Wiki beworben wird und dort eine Teilnahme auch ohne Account ermöglicht. Ich sehe darin allerdings ganz klar auch Sicherheitsrisiken, da eine Abstimmung, bei der die Stimmen nicht eindeutig zugeordnet werden können, leicht verfälscht werden können, etwa wenn Stimmen über IPs gezählt werden, die sich vergleichsweise einfach ändern lassen. Für den Moment also mein Pro dazu, die breite Leserschaft mit einzubeziehen, allerdings gefällt mir die Methode nicht, wobei ich nicht sicher sagen kann, ob mein Vorschlag da so viel besser ist. -- RobbiRobb 21:59, 15. Dez. 2019 (CET)
Ich finde das mit der Doppelabstimmung auf beiden Seiten nicht wirklich problematisch, da die Leute die das tun werden wohl kaum etwas anderes bevorzugen als die Allgemeinheit, wodurch das schlussendliche Resultat nicht verändert wird. Geht allerdings zugegebenermassen auch nur bei so einer single-choice-Frage, nicht bei etwas komplexerem. Bezüglich dem Ausschliessen von Nutzern ohne Konto, die ein Konto im Wiki haben: Ich habe die Hoffnung, dass es so viele Stimmen geben wird, dass das irrelevant wird, weil wir so wenige Stimmen ausmachen. --Datei:Sugimori 672.pngMecanno-manMäh 22:44, 15. Dez. 2019 (CET)
Ich finde es ebenfalls gut die Meinung der Besucher einzubeziehen. Bezüglich der Zentralität, Sicherheit vor Mehrfachabstimmungen und der Möglichkeit einer Teilnahme ohne Konten bei Facebook und Twitter habe ich hier mal etwas über Google Formulare ausprobiert. (Ich bekomme nur die Antworten und den Zeitpunkt der Antwort zu sehen.) Natürlich bleibt zwar auch dort eine Beschränkung auf Leute mit Googlekonto, darin sehe ich jedoch kein allzu großes Problem, da vom Gefühl her fast jeder ein Googlekonto hat. Ich kann die Vorraussetzung auch rausnehmen, dann wären aber eine Mehrfachabstimmung wieder möglich. Über Feedback zu dieser Idee würde ich mich freuen. GrollenKette951 00:43, 16. Dez. 2019 (CET)
Würde diese Umfrage entscheiden, wie wir das mit den Typ-Icons handhaben wollen (siehe Überschrift des Abschnitts), oder soll sie die Follower auf Facebook und Twitter miteinbeziehen (siehe einleitender Text)? Das ist für mich ein kleiner, aber feiner Unterschied. Zudem vermag ich nicht grundsätzlich mein „Ok“ hier zu äußern, ohne zu wissen, wie eine solche Umfrage aussehen soll. Gibt es visuellen Input für die Abzustimmenden? Heißt grundsätzlich neu vs. alt oder auch beispielhafte Auswirkungen auf bestimmte Vorlagen. Mein Eindruck der Follower unserer sozialen Kanäle ist über die Jahre eher der, dass sie nicht die wirkliche Besucherbandbreite abbilden können. Allgemein behagt es mir, eine bzw. zwei Abstimmung(en) auf den beiden Kanälen durchzuführen, um über solch grundlegenden Dinge entscheiden zu lassen. ~ Taisuke Diskussion 10:29, 16. Dez. 2019 (CET)
Wenn wir das machen müsste es schon ein entscheiden sein, weil sich das ganz schlecht macht wenn wir ne Umfrage machen und die dann nicht umsetzen. Für mich ist es imo. grundsätzlich neu vs alt, mit Ausnahmen wie z. B. diese Tabelle. Etwas anderes zu machen macht imo aus rein technischer Sicht keinen Sinn, da damit relativ aufwändig für jeden Fall entschieden werden muss, ob man das neue oder das alte Icon nehmen will. Eine solche Entscheidung könnte man auch nicht über eine Abstimmung machen. Bezüglich der tatsächlichen Umsetzung finde ich durchaus, das Bildmaterial angeboten werden sollte; bevorzugterweise irgendwo an exponierter Einzelstelle, irgendwo in ner Aufzählung und auch einmal ne Aufzählung auf dunklerem Hintergrund. Über die genauen Bilder kann man aber definitiv noch reden. Die Idee das über eine Google-Umfrage zu machen finde ich allerdings auch gut, wenn nicht sogar für diese Zwecke besser; die Idee das per unsere Social Media-Kanäle zu machen hätte allerdings den Vorteil das diese zur Zeit relativ abgelegten Kanäle wieder irgendwas bieten. --Datei:Sugimori 672.pngMecanno-manMäh 23:33, 16. Dez. 2019 (CET)
Fürs Protokoll: Nach kurzen tests ist offensichtlich, dass Google Forms sich ohne Google Eccount lächerlich einfach austricksen lässt (bzw. Mehrfachbeantworten sogar zugelassen sind.) Das sollte man wenn mans nutzt also eindeutig mit Accountzwang machen. --Datei:Sugimori 672.pngMecanno-manMäh 23:47, 16. Dez. 2019 (CET)
Besucher miteinzubeziehen finde ich ebenfalls gut. Entscheidungen sollten aber mMn nicht durch eine Umfrage allein getroffen werden können. Durch derartige Umfragen z. B. über das Google Formular von Peter ist die "Bequemheit" zu groß, um alles bei dieser Entscheidung zu berücksichtigen, bevor man sie fällt (mal abgesehen von der mangelnden Erfahrung/Fachkenntnis der Besucher). Bei dem Formular wählt man eine Option aus, drückt auf "Senden" und fertig; das dauert wenige Sekunden, geht super einfach und man muss nicht viel nachdenken. Wenn man allerdings hier auf der AD etwas schreibt muss man erstmal seinen Text verfassen und liest nochmal drüber bevor man die Änderung speichert, das dauert länger und man denkt auch mehr über das Thema nach. Meiner Meinung nach sollten also solche Umfragen in Diskussionen wenn dann nur berücksichtigt werden, um die Nutzerfreundlichkeit bzw. den optischen Eindruck der Besucher zu ermitteln. Sollten solche Umfragen stattfinden, sollte mMn nach dem Beschluss eine Stellungnahme von uns warum es so entschieden wurde auf den Social Media Kanälen geposted werden, um je nach dem einen anderen Ausgang als den der Umfrage zu rechtfertigen, damit nicht der Eindruck entsteht wir würden Scheinumfragen o.ä. machen.--DeXter 15:24, 20. Dez. 2019 (CET)

Eingeschlafen oder geht es hier noch weiter? Wir verwenden immernoch die alten Icons. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:29, 13. Jan. 2020 (CET)

Überarbeitung oder Löschen der Vorlage "Gradient"

Ich glaube, dass wir sollten die Vorlage Gradient auf zwei separate Vorlagen aufteilen oder die Vorlage insgesamt löschen. Es ist so einfach, um Gradienten in CSS zu schreiben:

background-image: repeating-linear-gradient(to top right, red, yellow 5%, red 10%);

Das Ergebnis ist dieses Rechteck:

Keine Farben-Transition? Dein Browser kann nicht Gradienten darstellen!

Hinweis: Du auch brauchst background-color zu definieren, da auch heute viele Browser können Gradienten nicht darstellen. Viele Browser auch brauchen ein Präfix, um korrekt zu werken (z. B. Mozilla Firefox brauchte das Präfix "-moz-"). Akzeptiert Ihr meine Idee? --TrikephaloFan635 11:50, 4. Jan. 2020 (CET)

Veto, ein Großteil der Nutzer verwendet kein CSS bzw. ist die Nutzung dieser Vorlage für entsprechende Nutzer besser in der Handhabung und eine Änderung so nicht notwendig. * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 12:06, 4. Jan. 2020 (CET)
Die Nutzung dieser Vorlage erfolgt allerdings sinnvollerweise ohnehin nur in der Vorlagenprogrammierung. Da weiß ich nicht, ob da die CSS-Kenntnisse noch so relevant sind. Ich bezweifle ganz ehrlich in Gegenüberstellung, ob die Anwendung der Gradient-Vorlage tatsächlich einfacher ist; wir könnten wohl genauso gut auch zusammenfassen, wie die CSS-Deklarationen funktionieren. Die Vorlage dürfte mit immerhin 224 #replace jedenfalls recht ineffizient sein. -- Skelabra2509 (Diskussion | Beiträge) 11:45, 5. Jan. 2020 (CET)

Die DLCs

Ich weiß nicht, wie weit es schon klar ist, wie wir sie behandeln. Aber ich wäre für eigene Artikel und Kürzel. Z.B. IR=Insel der Rüstungen und SK=Schneelande der Krone. Weitere Meinungen dazu bitte. Das Isso 08/15 Konter 22:59, 9. Jan. 2020 (CET)

Da die DLCs Versionsunterschiede haben werden bräuchte man zumindest zwei/DLC, einfach nur IR und SK werden also nicht passen. --Datei:Sugimori 672.pngMecanno-manMäh 03:11, 10. Jan. 2020 (CET)
🤔 Für was überhaupt? Es ist immernoch die Galar-Region und immernoch Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/Sd. Wenn wir soetwas brauchen würden dann würde ich nicht die Einzelnen Inseln nehmen sondern ein in Gelb/Grün gehaltenes EX wie es die offizielle Seite macht oder EP für Erweiterungspass, natürlich in Sk-Optik. So lässt sich bei bedarf das Kürzel für den Erweiterungspass dahintersetzen, denn in diesem sind beide Inseln enthalten, denn die Unterschiede sind nicht zwischen den Inseln sondern weiterhin zwischen den Spielen. Und Linktechnisch hätte ich gesagt geht das EX/EP dann entweder zu StSd/EX bzw. EP oder man macht aufgrund des Kontent einen eigenständigen Artikel StSw EX bzw. EP. Grüße * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 08:51, 10. Jan. 2020 (CET)
Der Ansatz und das Design deiner Idee gefällt mir, Ryu. Leider gibt es zwischen den Inseln auch Unterschiede. So sind unterschiedliche Pokémon auf den Inseln erhältlich, z. B. Coronospa erst mit dem zweiten Teil des Erweiterungspasses. Daher brauchen wir in meinen Augen schon mehr als nur ein Kürzel. ~ Taisuke Diskussion 09:23, 10. Jan. 2020 (CET)
@Taisuke: Die unterschiedlichen Pokémon sind doch Schwert, Schild abhängig was auf der Rüstungsinsel und später auf der Krone kommt, da der EX-Pass für beide Inseln pro Spiel ist wüsste ich nicht für was es weitere Sks benötigt. Auf der Rüstungsinsel gäbe es 3 Kombinationen Vorlage:Spielkuerzel/StEX, Vorlage:Spielkuerzel/SdEX, und Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdEX oder man macht 3 einzelne Sk mit StEX, SdEX und StSdEX.... ob man da eines macht und das immer dran hängt oder 3 separate soll mir da egal sein, jedenfalls lässt sich mit diesen mMn eindeutig zeigen: das der Content Editionsabhängig ist und das dafür der EX-Pass benötigt wird der ja schließlich beide Inseln freischaltet. Somit hat jeder mit Zugang zur Rüstungsinsel später auch Zugang zur Krone.... daher kann ich der Notwendigkeit mehrerer Sks nicht ganz folgen da es ja nur ein Pass ist. Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:39, 10. Jan. 2020 (CET)
Man könnte auch nehmen was da ist ka.gif wie hier am Beispiel Sk plus das jeweilige Icon... mein Favorit ist aber weiterhin EX da es kurz prägnant und zudem in Kombination mit dem Spielkürzel mMn ausreichen wäre
Vorlage:Spielkuerzel/StDatei:Icon Rüstungsinsel.png
Vorlage:Spielkuerzel/StDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/StDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.png
Vorlage:Spielkuerzel/SdDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.png
Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Kronen-Schneelande.png
Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png
* Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:21, 10. Jan. 2020 (CET)
Ich wüsste nicht, was dagegen sprechen würde, für jeden Teil des Erweiterungspasses ein eigenes Spielkürzel, im Endeffekt also insgesamt vier neue (Schwert-Rüstung, Schild-Rüstung, Schwert-Krone, Schild-Krone) einzuführen. Ich kann für mich hauptsächlich für den Item-Bereich sprechen, aber ich kann mir auch vorstellen, dass auch andere Bereiche davon profitieren könnten. Und zwar möchte ich ungerne neue Item-Fundorte zu den bereits existierenden hinzufügen, um Besucher, die die DLCs nicht besitzen, nicht zu verwirren, wenn dort Fundorte für Orte angegeben sind, die sie überhaupt nicht erreichen können. Da beide DLCs jeweils einen neuen Bereich freischalten, würde ich da auch gerne die Fundorte getrennt anbieten können, sodass dort auch nicht gemischt wird. Ich denke, die Richtung, in die ich möchte, sollte klar werden ^^
Visuell wäre ich dafür, einfach einen weiteren Buchstaben anzuhängen, der neben dem Hauptspiel klar macht, welche Erweiterung gemeint ist: STR, SDR, STK, SDK. Damit wäre man für alle möglichen Lagen gewappnet und müsste sich keine Sorgen machen, wenn irgendwelche verrückten, Editions- und gleichzeitig auch noch DLC-Spezifischen Inhalte kommen, bei denen wir uns eigentlich sicher sein können, dass es sie geben wird. -- RobbiRobb 17:34, 10. Jan. 2020 (CET)
Ich denke auch, dass neue Spielkürzel sinnvoll wären. Die Anhängung eines weiteren Buchstabens, wie mein Vorredner es bereits verdeutlichte, finde ich als Lösung recht einfach und gut.
P.S.: Wir haben ja sogar n Spielkürzel für etwas, das nicht einmal ein Spiel ist: Pokémon Bank BANK :D also warum dann einer Erweiterung, die ja schon etwas neues ist, das verwehren? -- GrüßeShortyBuzz 17:43, 10. Jan. 2020 (CET)
Mein Problem ist eher das einige Sks sowohl für Rüstung als auch Krone wollen, wo ich bisher immernoch nicht den Sinn heraus sehe da ja jeder der DLCs beides beinhaltet (Rüstung und Krone) nur halt Zeitversetzte veröffentlichung in 2 teilen und jeder der sich im Herbst den Pass für Krone holt sollte damit auch zur Rüstung kommt, mir würde jetzt kein Szenario einfallen was beides benötigt. Aber lässt sich ja wenn es soweit ist alles nochmal ändern ka.gif Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:43, 10. Jan. 2020 (CET)
Ich würde das ganze erst einmal abwarten und schauen, in wie weit es wirklich notwendig ist. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 03:45, 12. Jan. 2020 (CET)

Dem kann ich nur zustimmen -- Opii Wunschtraum 17:21, 13. Jan. 2020 (CET)

Mal eine Frage, wie wollen wir Die Insel der Rüstung und Die Schneelande der Krone behandeln? AN und für sich sind sie durch Neue Handlung, neue Pokémon usw wie eine Zusatzedition die einfach nur direkt ins aktuelle Spielnachgepacht wird. Daher fände ich es sinnvoll die DLC wie eigenständige Zusatzeditionen inklusive Spieleartikel zu behandeln. WIe ist da hier die allgemeine Meinung zu? Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 19:31, 21. Jan. 2020 (CET)

Der Meinung bin ich nicht. Es bleibt dasselbe Spiel wie vorher, zumal ja die Pokémon auch für die dazugepatcht werden, die den DLC nicht erwerben. Gleichnis: Mario Kart 8 ist auch Mario Kart 8 geblieben, obwohl damals 4 neue Cups hinzugefügt wurden. Etwas anderes ist das hier auch nicht. Zudem bin ich der Ansicht, dass wir für solche Entscheidungen abwarten sollten, in wiefern die Erweiterungspässe wirklich wie "eigene Spiele" behandelt werden können. Außerdem bin ich der Meinung, dass die Idee dahinter gar nicht neu ist. Früher hat man halt solche neuen Inhalte schon vorher auf das Spiel gepackt und einfach nur (mehr oder weniger erfolgreich) versucht geheim zu halten (Eichs Brief, Azurflöte ...). Im Grunde waren das auch nichts weniger als kleine (kostenlose) DLCs. Mit dem Unterschied, dass heute so etwas wirklich geheim gehalten werden kann, indem man erst später in die Spiele einfügt.
Also kurzum: Ich bin nicht dafür, dass man diese DLCs so separiert betrachtet. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 21:35, 21. Jan. 2020 (CET)
Seh ich ähnlich wie TiMauzi; wir sind btw so auch schon mit vorherigen Zusatzinhalten so verfahren (z. B. die Updates in Go oder die Portale-DLCs) --Datei:Sugimori 672.pngMecanno-manMäh 22:23, 21. Jan. 2020 (CET)

Kategorien bei Datei-Weiterleitungen

Mir ist aufgefallen, dass bei dem oben genannten Thema Uneinheitlichkeit herrscht. Genauer gesagt ist meine Frage, ob wie zum Beispiel hier eine Datei-WL Kategorien erhalten sollte oder nicht. Vorteil ist, dass man sie leichter finden kann. Nachteil ist aber, dass Seiten, die keine Dateien sind, dann als solche kategorisiert werden. Egal wie darüber entschieden wird, müssen jetzt nicht direkt sämtliche Kategorien ergänzt oder entfernt werden, das ist den Aufwand wahrscheinlich nicht wert. Für die Zukunft wäre es aber für alle Wiki-Bereiche ganz gut zu wissen, wie wir damit verfahren. Darum interessieren mich eure Meinungen zu diesem Thema. -- Cliffichen 19:17, 10. Feb. 2020 (CET)

Eine Weiterleitung iwo einkategorisieren wo die Zielseite schon drin ist ist imo. auf jeden Fall sinnlos. Dasselbe gilt in Fällen wo das eine ne Unterkategorie vom anderen ist; bei Sachen wie spiele-spezifischen Sprites-Kategorien bin ich mir unschlüssig und hängt wohl damit zusammen wie die Kategorie konzeptionell aussehen sollte - also ob da alles drin sein soll oder nur das was neu in dem Spiel hinzugekommen ist. Je nach dem müssen dann Weiterleitungen einkategorisiert werden oder nicht. --Datei:Sugimori 672.pngMecanno-manMäh 21:23, 10. Feb. 2020 (CET)
Mir fällt gerade auf das es wahrscheinlich sinnvoller ist die Kategorie die man bei den Weiterleitungen einfügen würde direkt bei der Zieldatei reinzuschreiben, dann wird auch auf der Datei-Seite klar das der Sprites für mehrere Spiele gelten, was es aktuell nicht wird. --Datei:Sugimori 672.pngMecanno-manMäh 21:26, 10. Feb. 2020 (CET)
Wie wäre es, wenn man ganz ohne WLs auskäme und die Dateien gleich mit jedem Spielekürzel im Dateinamen versehen wurde, in der sie vorkommt? -MfG, Kenaz-Hagalaz Disku 19:33, 12. Feb. 2020 (CET)
Oh, das hat Mec ja im Prinzip auch geschrieben. ^^ -MfG, Kenaz-Hagalaz Disku 19:35, 12. Feb. 2020 (CET)
Hö, nein, ich will die mit jeder Kategorie versehen in der sie vorkommt. Alle Spielkürzel in die Namen zu machen und die Redirects wegwerfen dürfte etliche Vorlagen im Wiki um einiges komplexer machen und jede Menge Wartung bedeuten; insbesondere da wir dann auch andauernd Sachen verschieben wenn sie in einem neuen Spiel wiederverwendet werden. --Datei:Sugimori 672.pngMecanno-manMäh 19:57, 12. Feb. 2020 (CET)
Ohje, ich sollte keine Disku-Beiträge schreiben, wenn ich nicht ganz fit bin ^^" -MfG, Kenaz-Hagalaz Disku 20:09, 12. Feb. 2020 (CET)
Gibt es dazu noch weitere Meinungen? Sonst würde ich das bei den nächsten Datei-WLs (brauche einige für Trainer, darum habe ich hier gefragt) so machen, wie Mec das vorgeschlagen hat. Sprich die Zieldatei zusätzlich kategorisieren. Und vielleicht gibt es irgendwann eine Wartung, bei der das dann einheitlich für alle Datei-WLs so umgesetzt wird. -- Cliffichen 11:52, 16. Feb. 2020 (CET)

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