PokéWiki:Allgemeine Diskussionsseite/Zentrale Hinterlegung von Daten

Aus PokéWiki
Zur Navigation springen Zur Suche springen

Zentrale Hinterlegung von Trainerdaten

Hab mir vor kurzem überlegt das es eigentlich unsinnig ist sowohl Vorlage:Team/Kopf als auch Vorlage:Orte Trainer/Kopf zu haben, da beide schlussendlich in etwa dasselbe machen. Bei der Idee, einfach im Charaker-Projekt die Orte-Vorlage zu nutzen ist mir dann aufgefallen, das es mehr Sinn machen würde, die Daten einfach in einem Artikel zu hinterlegen und dann daraus in die anderen zu ziehen. Ich würde deshalb vorschlagen, die ganzen Daten in den Orten und bei Charakteren aus den Trainer-Unterseiten zu ziehen, und da in nem includeonly ne Vorlage drum zu bauen, das man über nen Parameter auswählen kann welchen Trainer man haben möchte. Die tatsächliche technische Umstrukturierung würde ich aber vorschlagen nur Stück für Stück zu machen, da das nicht wirklich iwas is, was all zu wichtig ist. Wollte demnach nur mal fragen ob hier jemand grundsätzlich dagegen ist, insbesondere @GoPika, Cliffichen, Ryuichi und SortyBuzz, sowie RobbiRobb, an dem das ganze wahrscheinlich hängen bleiben wird... --Mecanno-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. --Mecanno-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 ~ PL ~ 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? --Mecanno-manMäh 23:53, 29. Feb. 2020 (CET)
Die WMF-Extension LabeledSectionTransclusion könnte für so ein Unterfangen vermutlich hilfreich sein, und ist auch nicht allzu komplex. Das ermöglicht es, innerhalb einer Seite mehrere "benannte Onlyinclude" zu erstellen und per Parserfunktion einzubinden. Dadurch dürfte das Gesamtkonstrukt auch weniger fehleranfällig sein.
Eine umfangreiche Datenbanklösung neu aufzubauen (Zum Beispiel mit Wikibase, vermutlich alternativ mit Semantic MediaWiki oder Cargo) halte ich mit unseren personellen und technischen Ressourcen für unrealistisch, und wäre wenn ein Projekt, bei dem man sich mit Bulba kurzschließen sollte. Das Thema haben wir ja vor etwa 4 Jahren schon mal diskutiert.
-- Skelabra2509 (Diskussion | Beiträge) 17:44, 8. Mär. 2020 (CET)

LabeledSectionTransclusion

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

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


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

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

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

Cargo

Wie aus der vorangegangenen Diskussion ersichtlich ist hat die Extension LabeledSectionTransclusion nicht den Nutzen gezeigt den wir brauchen. Bzw. sind die Möglichkeiten unzureichend und ich habe daher in letzter Zeit und auch im Sinne der Neuen Orte-Strukturen überlegt wie man das ganze gestalten könnte und die Informationen Doppeln könnte und Ihre Fehleranfälligkeit zu minimieren. Bei meiner Suche bin ich auf Cargo gestoßen. So wie ich das Verstehe ist es über diese Extension möglich das wir eine Art Datenbank anlegen die auch außerhalb der Bürokraten beeinflusst werden kann. Ich denke mit einer solchen Option könnten wir sogar über er die Trainer hinaus eine Datenbank Projektübergreifend schaffen und auf diese Zugreifen? Dies soll allerdings erstmal noch garnicht Thema sein sondern eher ein wie wir die Daten Zentral lagern. Vielleicht verstehe ich auch die Anwendung da etwas falsch bin da nicht so 100 % firm. Hat sich damit schonmal jemand auseinander gesetzt oder kennt diese Extension? Daher mache mal einen Ping an unsere Ganzen Techniks und Hauptakteure der Diskussion, Vielleicht ist Cargo ja eine Lösung ka.gif (Ping @Mec, Robbi Jones, Buo und Skel). Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 21:41, 3. Nov. 2021 (CET)

Ich habe mir Cargo jetzt noch nicht angegucken (ich probier am WE da mal zuzukommen) aber wenn ich die bisherige Diskussion mir durchlese setz ich mal ganz blöd die Idee in den Raum ne eigene Extension zu schreiben wenns sonst nichts gibt. Die wäre zwar dann evtl Trainer spezifisch aber der Datenumfang ist bekannt => Mini-DB designen in der die Daten liegen, Extension bietet Parserfunktionen um die abzurufen + ne Spezialseite um die zu erstellen. Sollte demnach ne sehr schmallspurlösung sein. Ist nur ggf halt unflexibler, müsste bei größeren Änderungen in zukünftigen Spielen überarbeitet werden und erstmal geschrieben werden und daher eher als Notlösung betrachtet werden. Jones Albtraum? 22:05, 3. Nov. 2021 (CET)
Cargo ist ein interessantes Konzept, wenn es auf den ersten Blick auch sehr kompliziert aussieht - was das ganze möglicherweise aber auch sehr mächtig machen könnte. Sofern sich ein Weg findet, mit dem es möglich ist, dass neue Benutzer ohne wahnsinnig viel Erfahrung (=sie können Text an einer vorgegeben Stelle eingeben) diese erweitern können, wäre das ein Versuch wert. Das ist nämlich der Grund, warum mir die Idee von Jones nicht gefällt - das klingt mir nämlich schon wieder nach etwas, was entweder kompliziert für Einsteiger wird oder sogar gar nicht für Einsteiger verfügbar wäre, was natürlich um so problematischer wäre, denn die Erfahrung hat gezeigt, dass es doch vor allem neue Benutzer sind, die die Daten erweitern. Diese also davon auszusperren wäre kontraproduktiv. Ein Konzept, bei dem also nur ein Artikel bearbeitet werden muss, könnte demnach also ein guter Ansatz sein, wie wir uns das ja bereits von LabeledSectionTransclusion erhofft hatten. -- RobbiRobb 00:25, 4. Nov. 2021 (CET)
Naja, wie Einsteigerfreundlich das ist läge ja dann in unseren Händen. Mit ner passenden Spezialseite über die die Daten per UI bearbeitet werden können ist vermutlich sogar einfacher als sich mit der Syntax von Cargo auseinanderzusetzen. Der große Nachteil läge aber eben darin, dass es eine spezielle Lösung würde, während Cargo sich zB auch eignen würde um die Verkaufszahlen zu hinterlegen oder ähnliches.
Bei Cargo sollte man aber auf jeden Fall sich im Detail mit beschäftigen, ich habe etwas die Befürchtung, dass die Erweiterung nur bedingt in unserem Kontext nutzbar ist, soweit ich das jetzt sehe bietet Cargo unterm Strich nen SQL-Interface an - ergo braucht es immer wenn mit SQL-Kentnissen um zumindest einige Grundsachen zu erledigen. Gleichzeitig stellt sich mir etwas die Frage wo die nötigen Tabellen definiert werden, wenns da jedesmal Buo braucht um Tabellen oder Spalten anzulegen ist das auch schon wieder nichts. Ganz abgesehen von dem Sicherheitsthema (dafür müsste man mal an die Extension gucken ob die nur SELECTs zulässt oder ob man darüber im Zweifel sogar nen "DROP DATABASE;" loslassen kann). Aber mächtig wäre Cargo mit Sicherheit. Jones Albtraum? 14:33, 7. Nov. 2021 (CET)
Ich würde aufgrund des Mangels von Flexibilität und Bürokratenunabhängigkeit davon abraten, hier eine eigene Extension einzusetzen. Ich persönlich habe noch keine Erfahrungen mit Cargo gesammelt, habe aber keinen Grund, von einer Verwendung abzuraten. Die Extension hat einen aktiven und kompetenten Maintainer und wirkt sauber konzipiert. Ich vermute, dass die Verwendung durchaus eine technische Hürde darstellt, halte das Konzept aber prinzipiell auf den ersten Blick für recht eingängig. Insbesondere kommt der Nicht-Vorlagenbearbeitende Benutzer wohl nie mit den Komplexitäten des Ganzen in Berührung. Vorlagen können gewissermaßen Tabellen sein, und ihre Parameter die Spalten. Extension:Cargo/Quick start guide stellt das ganz gut dar und zeigt die gewünschte Deduplizierung schon auf.
In Zukunft sehe ich hier insbesondere bezügliche Attacken noch erhebliches Potential, doch man sollte erst einmal klein anfangen.
Ich gehe davon aus, dass die Extension keine offensichtlichen Exploits hat. (Sicher sein kann man sich da aber nie – eine Zeit lang hatte Bulba via Widgets einen exploit, der allen eingeloggten Nutzern shell access gegeben hat, worauf ich Archaic diskret hingewiesen habe.) Ich würde allerdings anraten, Cargo dennoch eine eigene Datenbank verwenden zu lassen – dadurch dürften auch eventuelle Exploits höchstens den Cargo-Cache beschädigen können.
Für eine kompetentere und ausführlichere Einschätzung müsste ich mehr Zeit investieren. Ich ließe mich aber wahrscheinlich breitschlagen, mich in den nächsten Monaten an einer Arbeitsgruppe zu beteiligen, die sich genauer mit Cargo beschäftigt und eine Anwedung vorbereitet, wenn die Ampeln sich in Richtung grün bewegen sollten. -- Skelabra2509 (Diskussion | Beiträge) 23:56, 10. Nov. 2021 (CET)
Also ich bin nicht so der Extension experte, allerdings so wie ich das ganze verstehe würde es bedeuten man müsste das ganze beispielhaft so in der Vorlage definieren:
<noinclude>
{{#cargo_declare:_table=Trainer/Zeile
|Tr-Nr=Die Nummer sollte i.wo im Wiki frei zugänglich ersichtlich sein
|Trainerklasse= Woher er es sich zieht
|id1= usw. siehe oben
....
}}</noinclude><includeonly>{{#cargo_store:_table=Trainer/Zeile
|Tr-Nr={{{Tr-Nr|}}} Hier bin ich mir allerdings unsicher ob sowas mit in Store gehört

|Trainerklasse={{{Trainerklasse|}}}
|id1={{{id1|}}}
....
}}
Und ab hier dann das Vorlagenkonstrukt nach dem Motto {{#if:{{{Trainerklasse|}}}|{{{Trainerklasse|}}}|{{{Tr-Nr|}}}-{{{Trainerklasse|}}}}} bla bla bla das Vorlagenkontrukt halt ansonsten sehe ich die Probleme das sich die Daten nicht korrekt gezogen werden könnten (gerade bei mehrfacher Nutzung der Vorlage) oder? Final würde es dann reichen z.b. {{Trainer/Zeile|Tr-Nr=001}} einzubinden. Die Grundvoraussetzung ist natürlich das wir eine Entsprechende Datenbank dahinter haben aus der sich die Daten gezogen werden. Dies bedeutet das Buo sie anlegen müsste. Und jeder Benutzer könnte Fehler in der Vorlage korrigieren durch manuelle Angabe des entsprechenden Wertes z.B. {{Trainer/Zeile|Tr-Nr=001|Trainerklasse=Knirps}} was überall dann die Auswirkungen erzeugen würde, so zumindest verstehe ich das? Wenn man eine manuelle Parametersetzung mit einer Kategorie versieht könnte man in regelmäßigen Abständen das ganze in der Datenbank aktualisieren. So würden wir auf jeden Fall eine Datenbank erzeugen die auch immer aktuell gehalten werden würde und User könnten dennoch Fehler wie gewohnt beheben. Das mal zu meinen Vorstellungen wie ich das ganze Verstanden habe. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:42, 11. Nov. 2021 (CET)
Ich verstehe das im wesentlichen genauso. In #cargo_store sind die entsprechenden Direktiven optional, wenn das Schema in #cargo_declare zu den Parametern der Vorlage passt. Da #cargo_query auch join-Direktiven unterstützt, kann ich mir eigentlich nicht vorstellen, dass das für uns nicht mächtig genug sein könnte. Auch mehrere Verwendungen einer Vorlage auf einer Seite sollten kein Problem sein. Verwende doch <pre> anstatt solcher Code-Blöcke… ^^
Die Datenbank anzulegen ist aus Bürokratensicht wahrscheinlich nahezu trivial, einfach ein Zusatzschritt bei der Installation der Extension, der dann im weiteren Verlauf keiner zusätzlichen Arbeit mehr Bedarf.
Den Teil mit der "manuelle[n] Parametersetzung mit einer Kategorie" verstehe ich nicht. Die Datenbank, durch die über die Vorlageneinbindungen Datensätze eingetragen werden, wird im Hintergrund automatisch aktualisiert. Das wird auch auf [1] beschrieben. Wirkt doch alles in allem wie eine sehr schöne Extension. -- Skelabra2509 (Diskussion | Beiträge) 03:30, 12. Nov. 2021 (CET)
Das mit der automatischen Aktualisierung habe ich wohl i.wie überlesen. Wollen wir das ganze einfach mal im Testwiki installieren und testen wenn Buo einverstanden ist? Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 08:56, 12. Nov. 2021 (CET)
Klingt gut. Die Standardinstallation nach [2] sollte zu Testzwecken passen. Hat weiterhin nur Buo Zugriff auf den Server des Testwikis, oder inzwischen auch einige andere Admins? Deine Aussage lässt ein wenig letzteres vermuten. -- Skelabra2509 (Diskussion | Beiträge) 22:58, 14. Nov. 2021 (CET)
Ach ja, man will dann noch die Rechte recreatecargodata und deletecargodata an trusted oder so vergeben, zumindest fürs TestWiki erstmal, damit man da auch ordentlich testen kann. -- Skelabra2509 (Diskussion | Beiträge) 23:34, 14. Nov. 2021 (CET)
@Buo das ganze steht und fällt mit dir. Folglich wäre deine Meinung hier noch wichtig und auch ob du es installieren würdest? Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 08:53, 15. Nov. 2021 (CET)
Wäre einen Versuch wert, aber ich muss mir die Extension erst einmal genauer anschauen und auch genannte Sicherheitsbedenken prüfen. Die LabeledSectionTransclusion-Extension ist inzwischen entfernt. - 418.gif Buoysel 13:12, 18. Nov. 2021 (CET)
@Buo kannst du bereits abschätzen ab wann oder ob überhaupt Cargo als mögliche Option getestet werrden kann? Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 14:52, 3. Jan. 2022 (CET)

JsonHandler

So, Zeit hier mal wieder etwas Leben einzuhauchen. Buo war so freundlich und hat heute im TestWiki Cargo und die Extension, die ich vor einiger Zeit geschrieben hatte, um als Alternative für Cargo zu dienen, falls dieses nicht unseren Ansprüchen gerecht werden würde, installiert - nur um Cargo dann wieder zu deaktivieren, weils leider Probleme gemacht hat (Edits ließen sich nicht mehr speichern). Dennoch ist zumindest mein Ansatz jetzt aber im TestWiki zu finden, es gibt eine Daten-Seite im JSON-Format und eine Seite, die diese Daten verwendet. Geladen werden die Daten mit einer ParserFunction, die es erlaubt, JSON-Daten von einer anderen Seite zu laden und zu parsen. Vergleichbar ist das ganze damit also mit einem verschachtelten Switch oder Dictionary, ohne die Nachteile von beiden. Das ist aber eher ein schöner Nebeneffekt. Wichtig ist vor allem, dass man damit die Möglichkeit hätte, Daten im Wiki auf einer Seite zu speichern, sodass jeder sie bearbeiten kann und diese dann von einer anderen Seite wieder geladen werden können. Ein schneller Überschlag lässt mich vermuten, dass wir damit problemlos 1000 Trainerdaten pro Spiel speichern können, bei kleineren Datensätzen auch mehr. Speicherung sollte also eher kein Problem sein, ebenso das Laden, was mit konstanter Knotenlast durchgeführt wird (in der Realität natürlich nicht, aber es ist immer schön, dem Parser vorzugaukeln, dass etwas effizienter ist, als es wirklich ist). Zumindest in dieser Hinsicht ist das ganze also extrem praktisch. Zu dem Beispiel sei noch gesagt, dass bitte nicht zu sehr in die Struktur des Datensatzes gelesen werden sollte, das wäre natürlich etwas, was man sich genauer überlegen würde, wenn man das ganze ernsthaft umsetzen würde. Wichtig wären mir hier vor allem Meinungen zu dem Gedanken, hier JSON zur Speicherung von Daten zu verwenden. Außerdem steht noch die Idee im Raum, dafür einen eigenen Namensraum einzuführn, in dem dann alle Daten hinterlegt werden, da bin ich allerdings nicht ganz sicher, weil man sich damit die Möglichkeit blocken würde, das ganze frei zu verwenden. Andererseits kann es praktisch sein, alles an einem Ort gesammelt zu haben. Da man hier zumindest für die Trainerdaten aber sowieso eine einheitliche Benennungsstruktur wählen würde, halte ich den Vorteil für vernachlässigbar und da es vermutlich eh keinen Schutz auf das ganze geben soll, bräuchte man das auch nicht für Zugriffsbeschränkungen. So viel aber zu meinen Gedanken dazu. Wenns Fragen zu der Extension gibt, immer her damit. Ansonsten immer her mit Meinungen zu dem Ansatz und auch gerne zu der Frage bezüglich Namensraum. -- RobbiRobb 20:02, 25. Feb. 2022 (CET)
Hmmm... die ganze Vorlage in einem json-Call einzubinden ist wahrscheinlich nicht möglich schätze ich? Weil wenn wir alle Sachen immer noch getrennt von einander in die Vorlage eintragen erfüllt das mein Ziel eigentlich nur halb. Wenn jetzt jemand bei nem Ort was einträgt wo vorher gar nichts war dann erscheint das noch nicht automatisch im Charakter-Artikel und umgekehrt, weil dann dort die json-Referenz ganz fehlt. Oder könnte man damit herumbasteln, zu prüfen ob n gewisser Key gesetzt ist und dann nur dann ziehen, wenn das der Fall ist - sprich das die verwendeten Vorlagen dann alles automatisch machen? Ansonsten gefällt mir der Proof of Concept aber zumindest schonmal. Die Darstellung auf der json-Seite lässt noch leicht zu wünschen über, ich schätze aber mal das ist MediaWiki, oder? --Mecanno-manMäh 17:23, 26. Feb. 2022 (CET)
Ja genau das war ungefähr das Ziel, man würde halt die Vorlage so anpassen, dass sie eine Edition und eine ID erhält und dann einfach die Daten für das Spiel zu dem Trainer mit der ID automatisch zieht und ausgibt. Dafür muss aber halt groß die Orte Trainer/Zeile angepasst werden, was ich an dieser Stelle für das einfache Vorzeigen jetzt nicht machen wollte, weils entsprechend viel Arbeit ist. Daher ja auch von mir eingangs der Hinweis, dass nicht zu sehr in die Struktur der JSON-Daten gelesen werden sollte, weil ich das recht fließend mit der Vorlage gestalten würde, wenn wir die tatsächlich umbauen würden.
Die Darstellung auf der JSON-Seite kommt aus MediaWiki, da haben wir keinen Einfluss drauf. Und da können wir abgesehen von vielleicht etwas CSS auch nix dran machen, weil die Extension ja einfach den Inhalt der Seite zieht und als JSON interpretiert - und wenn das nicht geparsed werden kann, gibts ne Fehlermeldung. Irgendwas schönes drum herum ist also nicht. -- RobbiRobb 18:35, 26. Feb. 2022 (CET)

Ich finde den Ansatz mit JSON hier eingentlich wunderbar. Durch Mecs Nachfrage wurde mir klar, dass man das per Vorlage ja automatisieren kann, wodurch sich ja erst die enormen Vorteile ergeben. Von daher kann ich mich hier nur für diesen Vorgang aussprechen.

Bei der Idee mit dem Namensraum muss ich einmal für mich nachhaken. Es soll quasi ein Namensraum XY erstellt werden, in dem dann nur die JSON-Seiten landen, also bei dem Beispiel aus dem Testwiki wäre das Trainerdaten/SoMo.json? Wenn dem so ist, dann finde ich den Vorschlag eigentlich gar nicht verkehrt. Für den ein oder anderen mag es keinen Unterschied machen, aber ich würde den Namensraum bevorzugen, denn die JSON-Seiten irgendwo rumfliegen zu haben fände ich nicht so toll. Dann habe ich doch lieber sowas wie XY:USUM/Tali.json anstatt nur USUM/Tali.json. Ich bitte um Korrektur, wenn ich das jetzt falsch verstanden habe, aber so wäre mein Gedankengang dazu. ^^ -- ~~ feblue 14:27, 28. Feb. 2022 (CET)

Dann kommt hier die Korrektur: Es wird nur eine Datei pro Spiel geben. Da die Wahl nicht so riesig groß ist, wird sie entweder im PokéWiki-Namensraum zu finden sein (PokéWiki:Trainerdaten/SoMo.json) oder in einem eigenen Namensraum (JsonData:Trainerdaten/SoMo.json). Der Unterschied für diese Vorlage hier ist irrelevant, ich sehe in der Extension aber auch für andere Bereiche einen Vorteil, wo sie ebenfalls zum Einsatz kommen könnte. Und dann wird es interessant, ob das ganze in einem eigenen Namensraum ist. Weil dann ist es bspw. nicht mehr möglich, dass sich Leute einfach auf ihrer Benutzerunterseite eine JSON-Seite erstellen und diese mit der Extension laden. Ebenso kann dann nicht mehr der Vorlagen-Namensraum genutzt werden, um einen automatischen niedrigen Schutz zu haben. Es ist dann zwangsläufig erforderlich, jede damit in Verbindung stehende Seite manuell zu schützen. Denn wenn wir einen Namensraum einführen, dann wäre dieser auch verpflichtend für alles, was in Verbindung mit der Extension steht, andernfalls ist das sinnfrei und erzeugt nur Chaos. -- RobbiRobb 15:11, 28. Feb. 2022 (CET)
Das ist schonmal ein wenig klarer. Aber wo ist dann der Vorteil beim PokéWiki-Namensraum? Beim Schutz und der Möglichkeit, die Extension anderweitig verwenden zu können? -- ~~ feblue 11:32, 1. Mär. 2022 (CET)
Vor allem letzteres. Die Daten für die Trainer müssen logischerweise außerhalb des Vorlagen-Namensraums liegen, damit sie von jedem Benutzer bearbeitet werden können. Andererseits gibt es aber auch Vorlagen, die von der Extension profitieren könnten, wo es nicht sinnvoll wäre, wenn die Inhalte von jedem bearbeitet werden könnten. Da würde sich dann etwa der Vorlagen-Namensraum eher anbieten, zumal die Daten dann auch direkt an die Vorlage gebunden werden könnten, etwa in Form einer Unterseite. Das wäre nicht möglich, wenn du die Daten alle in einem separaten Namensraum lagern würdest. -- RobbiRobb 17:11, 1. Mär. 2022 (CET)

Alle Trainerdaten auf eine Seite? Kurze Zwischenfrage meinerseits dazu: Sprengt das nicht womöglich irgendwelche Limits/Ist relativ ineffizient wegen der Grösse, die da übertragen wird? Ich schätze irgendeine Art das aufzuteilen wäre sinnvoll. --Mecanno-manMäh 19:34, 1. Mär. 2022 (CET)

Nein und nein. Die Last bleibt Serverseitig und es wird nur das übertragen, was auch tatsächlich angefordert wird. Mengenmäßig ist das kein Problem, wie ich eingangs erwähnt hatte passen locker tausend Trainer auf eine Seite, vermutlich sogar mehr, wenn die Teams nicht alle sechs Pokémon enthalten. Mache mir da keine Sorgen, dass das irgendwelche Probleme bereiten wird. -- RobbiRobb 19:46, 1. Mär. 2022 (CET)
Also mal so gesagt wie man hier (Test2) vs. hier (Test3) sieht, schafft man mit der derzeitigen Konfiguration mindestens 50 Trainer auf einer Seite einzubinden.
Mit folgenden Ergebnissen:
Einbindung json Einbindung wie bisher
Genutzte CPU-Zeit 6,288 Sekunden Genutzte CPU-Zeit 6,033 Sekunden
Genutzte Zeit 6,497 Sekunden Genutzte Zeit 6,335 Sekunden
Vom Präprozessor besuchte Knoten 733.274/1.000.000 Vom Präprozessor besuchte Knoten 735.724/1.000.000
Einbindungsgröße nach dem Expandieren 2.481.570/3.145.728 Bytes Einbindungsgröße nach dem Expandieren 2.554.170/3.145.728 Bytes
Vorlagenargumentgröße 276.263/3.145.728 Bytes Vorlagenargumentgröße 297.693/3.145.728 Bytes
Höchste Expansionstiefe 15/40 Höchste Expansionstiefe 16/40
Anhand dessen sieht man das die Hauptproblematik egal wie in Knoten und Einbindungsgröße liegt. Wenn sich die Vorlage die Daten allerdings zentral zieht dann können viele Prüfungen aus der Vorlage entfernt werden, genauso CSS Auslagerung. Durch diese "Entschlackung" kann also durchaus einiges bewirkt werden. Zusätzlich haben wir dann eine Zentrale Stelle von wo wir nach überall die Identischen Daten ziehen können was die Fehleranfälligkeit reduziert. Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:21, 2. Mär. 2022 (CET)
So interessant der Vergleich auch ist, um ehrlich zu sein ist er ziemlich nichtssagend. Die Vorlage wird sich ja groß verändern müssen, damit man eben nicht genau das macht, was ich hier gemacht habe, nämlich einfach nur die Daten manuell einbinden. Im selben Zug wird man dann auch das CSS auslagern können und eigentlich einfach die ganze Vorlage neu schreiben, damit das alles passt - erst dann lohnt sich ein solcher Vergleich wieder. Im Übrigen passen deine Daten nicht, du vergleichst nicht das gleiche. Dir ist nämlich der Hinweis verloren gegangen, weshalb die JSON-Variante effizienter ist - was von vorne herein nicht sein konnte, wenn du einfach nur ein mal mit und ein mal ohne vergleichst. Aber naja, macht auch keinen Unterschied, da der Vergleich keine Aussagekraft hat. -- RobbiRobb 15:40, 2. Mär. 2022 (CET)

Normalerweise gehe ich davon aus, dass Einrückungen einem gewissen Threading folgen, sodass man thematisch spezifisch antworten kann… Na ja. Irgendwo ist mir dabei auch selbst was durcheinandergeraten.
Was mich an Robbis Aussage bezüglich der freien Bearbeitbarkeit irritiert: Denkst du, Neulinge schaffen es tatsächlich, ein JSON korrekt zu bearbeiten? Nicht nur, dass ich daran große Zweifel habe; es sollte außerdem Vandalismus extrem vereinfachen. Es sei denn, der Quelltext der JSON-Seite wird beim Abspeichern nicht nur syntaktisch, sondern auch gegen ein JSON-Schema validiert. Das wäre recht elegant und sollte machbar sein.
Bei der Knotenlast muss man aufpassen, dass man sich Sachen nicht zu effizient rechnet und dadurch den Server übeerlastet – schließlich kommt es auf die tatsächliche Last an, und nicht auf dei Anzeige unten. Bei der jetzigen Umsetzung würde ich aber vermuten (!), dass man da nicht auf Probleme stößt.
Das Angebot steht, mir das in der Praxis mal anzusehen, derzeit mangelt es mir allerdings an Möglichkeiten, da das TestWiki nur für Stimmberechtigte Benutzer einsehbar ist. Daher auch die vielleicht stellenweise doofen Fragen. -- Skelabra2509 (Diskussion | Beiträge) 01:13, 9. Mär. 2022 (CET)

Soweit ich weiß, hat MediaWiki einen internen check gegen ein JSON-Schema drin, zumindest hindert es mich regelmäßig daran, falsches abzuspeichern. Daher mache ich mir da nicht zu große Sorgen - ob Neulinge das verstehen ist aber schon eine schwierigere Frage. Und natürlich schützt der Schema-Check auch nicht gegen Vandalismus, nur gegen sinnfreien Vandalismus. Wenn sich jemand die Mühe macht, einen bestimmten Teil gemäß Schema zu streichen, wird er damit natürlich durchkommen, aber dann kann er auch einfach die Vorlage aus dem Artikel entfernen.
Bezüglich Effizienz kann ich immerhin schon mal sagen, dass ich versucht habe, das soweit möglich zu optimieren. Insbesondere Zugriffe auf eine JSON-Seite, die ja das Laden einer anderen Seite erfordern, sollten für diese eine Seite 'gecached' werden, damit nicht für jeden einzelnen Aufruf der Extension die Seite neu geladen werden muss. Damit dürfte schon mal die größte Last wegfallen. -- RobbiRobb 01:28, 9. Mär. 2022 (CET)

Abstimmung: Eigener Namensraum für (Json-)Datensätze

Die Abstimmung endete mir 3 Pro-Stimmen zu 3 Contra-Stimmen. Die Administratoren werden eine Entscheidung treffen.

Semantic Mediawiki

Hey, eventuell bin ich anderthalb Jahre zu spät, aber falls da noch Interesse an dem Problem besteht: ich glaube, ihr wollt Semantic Mediawiki haben. Es wird erfolgreich in einem der Wikis, wo ich aktiv bin, eingesetzt, um Daten zu Items und sonstigen Objekten eines Spiels zu speichern. Siehe zum Beispiel hier: https://fallenlondon.wiki/wiki/Special:Browse/:Soul Da ist hinterlegt, welche Art Spielobjekt das ist, welches Bild es verwendet usw. Ich könnte nun wiederum hingehen und per Parser-Befehl diese Infos abrufen. Es erlaubt außerdem, verkettete Anfragen zu erstellen, wie zB, wenn ich zum einen gespeichert hätte, was das Team eines Trainers ist, und zum anderen die Typen zu jedem Pokémon, könnte ich eine Anfrage schreiben, die mir automatisch als Liste die Frage beantwortet "welche Trainer haben Käfer-Pokémon in ihrem Team". Und natürlich ist das ganze mit Vorlagen kombinierbar. Mehr Details auf https://fallenlondon.wiki/wiki/Fallen_London_Wiki:Semantic_Mediawiki. -- Afrael Diskussion 18:16, 8. Mai 2023 (CEST)

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