Wikipedia Diskussion:Lua/Modul/Wikidata

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 90 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte. Die Archivübersicht befindet sich unter Archiv.
Vorlagenprogrammierung Diskussionen Lua Test Unterseiten
Modul Deutsch Modul: Dokumentation

FYI, Schweden[Quelltext bearbeiten]

Was mich daran interessiert, ist das Auslösen einer Wartungskategorie. Bei den ganzen Wikidata-Vorlagen hierzuwiki, die nach dem Schema verfahren "Daten werden von Wikidata bezogen, wenn keine lokale Angabe vorhanden ist", da hätte ich gerne eine Kategorie der wikidata-beziehenden Artikel. Soll heißen: In welchen dewiki-Artikeln wird live wikidata eingebunden? Kategorie? Hat dewiki über 150.000 Wikidata-Einbindungen (siehe Benutzer:Mabschaaf/WD-Nutzung_in_deWP) oder nur ein paar hundert? Benutzer_Diskussion:Mabschaaf/WD-Nutzung_in_deWP#insource Suchen? --Atlasowa (Diskussion) 23:16, 18. Dez. 2015 (CET)

Featurewunsch Tree/Typsuche[Quelltext bearbeiten]

Hi, wir arbeiten derzeit an dem Aufbau der Verwaltungshierachie für das eine oder andere Bundesland (siehe Niedersachsen). Die Diskussion der passenden Taxonomie scheint erfolgreich beendet (siehe d:Wikidata:WikiProject_Municipalities_of_Germany. Dabei enstehen jetzt P150-Trees die ich gern für die Navileisten der Gemeinde nutzen würde. Beispiel: Vorlage:Navigationsleiste Orte der Gemeinde Neu Wulmstorf

Tree

  • In den hiesigen Navileisten der Gemeinden werden aktuell alle untergeordneten Verwaltungseinheiten (Ortschaften/Ortsteile) flach in einer Liste dargestellt. Das finde ich auch okay, da die ja eher ein horizontales Layout haben und ich mir schwer vorstellen kann, wie darin eine Verwaltungshierachie (z.B. 5 Ortschaften mit je 3 Ortsteilen) verständliche dargestellt werden könnte. Flachgeklopfte Liste ist dann Alphabetisch sortiert.
Hierfür müsste ich sowas nutzen, wie es das Tree-Template auf Wikidata z.B. macht. Es erlaubt mir eine Property (P150) (und eine Rekursionstiefe) zu wählen die dann traversiert wird. (Beispiel Neu Wulmstorf).
Beispielsweise könnte claim um "recursion" erweitert werden. Bei einem default von 0 würde es sich wie list verhalten, ansonsten entsprechend die gefundenen Entities als Liste aufsammeln.
 ...claim|P150|recursion=2|list= | |id=Q508054|sortInItem=P734|parameter=link...
Hiermit wären wir schon in der Lage sowas wie Vorlage:Navigationsleiste Kader des FC Valenciennes auch Hierachien zu nutzen (wenn eine flache Liste ausreicht). Aber ich müsste je Gemeinde eine feste Vorlage anlegen. Ist trotzdem ein kleiner Fortschritt, da ich die Verwaltungshierachie in Wikidata nutzen kann, Redundanzen vermeide und wie im Kader fehlende Lemmas aufzeige. Das würde ich dann auch sofort in ndswiki nutzen wollen, wo wir zu wenige sind um solche Navileisten zu pflegen.

Typsuche

  • Um zu verhindern, dass wir wie bei den Kadern, für jede Gemeinde eine eigente Vorlage brauchen, würde ich es aber noch generischer machen wollten. So eine generische Form würde z.B. in einem Ortsteil (Ebene 2 oder 1), einer Ortschaft (Ebene 1) und Gemeinde (Ebene 0) aufgerufen werden. Sie müsste jetzt die Gemeinde suchen um Namen, Link und Wappen zur Gemeinde zu bekommen. In einem Fall ist es die Entity selbst, in den meisten Fällen aber ein oder zwei ebenen höher. Dazu würde ich einen Tree (hier P131) nach einem Typ (P31) durchsuchen (z.B. q:Q22338052) durchsuchen. Dort könnte ich dann Wappen, Namen und Link via Invoke abgreifen.
Hier wäre es dann sowas wie
 ...claim|P131|recursion=2|findType=Q22338052...
Zusätzlich wäre diese Entity dann auch die, die ich für den ersten Aufruf einsetzen müsste um den Einstieg in die Gemeinde zu bekommen, wenn ich z.B. gerade die Ortschaft betrachte.

Am Ende könnte man eine generische Vorlage für Gemeinde Navis bauen. Einziges Paramter wären dann nur die zu betrachtende Verwaltungsebene (hier Einheitsgemeinde). Damit vermeide ich dann die Anlage von Vorlagen je Gemeinde, sondern könnte eine generische überall nutzen.

Wo ich mir unsicher bin ist, ob die Umsetzung als Vorlage so sinnvoll ist, da ich ja für Namen, Wappen, Link und Liste den Aufruf via findType einsetzen muss, da ich ja keine zwischenspeichernden Variablen in der Vorlage habe. Irre ich und es gibt Variablen oder ist da Caching vorhanden, was das Problem eleminiert? Oder sollte man das in Lua machen? Könnte ich da dieses Wikidata Modul aufrufen, oder muss ich dies alles duplizieren? --Aeroid (Diskussion) 09:56, 4. Feb. 2016 (CET)

Problem mit dem Parameter "language"[Quelltext bearbeiten]

Hallo. Ich habe mal folgendes probiert:

* {{#invoke:Wikidata|claim|P18|id=Q181276|qualifier=P2096}}
* {{#invoke:Wikidata|claim|P18|id=Q181276|qualifier=P2096|language=eo}}

Das Ergebnis ist leider nicht zu gebrauchen, denn beide Male erscheint der ungarische Text, obwohl ja beim zweiten der Esperantotext erscheinen sollte:

  • Szolnok látképe a Zagyva torkolatánál
  • Szolnok látképe a Zagyva torkolatánál

Woran könnte das liegen? Andere Texte sind dort zur Zeit nicht definiert, so daß Deutsch noch nicht getestet werden kann. --Tlustulimu (Diskussion) 23:26, 5. Feb. 2016 (CET)

Tabelle aus Mitgliederzahl bzw. Vorsitzende aus Wikidata erzeugen?[Quelltext bearbeiten]

Hallo, für den Deutschen Schwimm-Verband https://www.wikidata.org/wiki/Q1205300 habe ich die Präsidenten und die Mitgliederzahlen recherchiert und inkl. des Datums eingetragen. Nun möchte ich gerne jeweils eine Tabelle der Präsidenten (P488) und der Mitgliederzahlen (P2124) generieren.

Bei der Präsidenten-Tabelle sollen folgende Spalten genutzt werden: Name (inkl. Link, falls vorhanden) | Startdatum | Endedatum | Quelle.

Für die Mitgliederzahlenübersicht folgende Spalten: Jahr | Anzahl | Quelle

Ist das möglich oder muss ich die Daten doch per Hand in Wikipedia übertragen?

--Chlorjunkie (Diskussion) 17:18, 30. Jul. 2016 (CEST)

Fehler im Modul[Quelltext bearbeiten]

Hier wird auf einen möglichen Fehler im Modul hingewiesen, könnte das jemand ggf. reparieren? –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 11:54, 4. Aug. 2017 (CEST)

Function claim: Filtern nach beliebig vielen Qualifier-Value-Paaren[Quelltext bearbeiten]

Hallo, ich habe gerade im Testmodul zur Funktion claim einen Filter für Qualifier-Werte hinzugefügt. Dazu werden die unbenannten Parameter ab Nummer 2 abwechselnd als Qualifier und als Qualifier-Value interpretiert. Verwendungsbeispiel:

Syntax:

Maximale Tiefe des Müggelsees: {{#invoke:Wikidata/Test|claim|P2610|P459|Q10578722|id=Q694789}} (erwarteter Wert: 7.5)

Durchschnittliche Tiefe des Müggelsees: {{#invoke:Wikidata/Test|claim|P2610|P459|Q19033|id=Q694789}} (erwarteter Wert: 4.8)

Ausgabe:

Maximale Tiefe des Müggelsees: 7.5 (erwarteter Wert: 7.5)
Durchschnittliche Tiefe des Müggelsees: 4.8 (erwarteter Wert: 4.8)

Mehrere solcher Filter sollten prinzipiell auch funktionieren. Ich hab bloß gerade kein Beispiel parat. Wenn diese Erweiterung von der Sache her auf Zustimmung stößt, würde ich sie gerne in das Modul einbauen. Bitte habt Nachsicht, falls das nicht der hochwertigste Code ist. Das sind meine ersten Zeilen in Lua. Aber ich lerne gerne dazu. --jmkeil (Diskussion) 20:52, 24. Aug. 2017 (CEST)

Großartig, bei der Vorlage Rezension Film habe ich mir für sowas die Finger verrenkt. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 22:54, 24. Aug. 2017 (CEST)
Ok. Ich hab es dann mal eingebaut. Ich habe mir außerdem Erlaubt, eine Schnelltestseite anzulegen. –jmkeil (Diskussion) 23:42, 25. Aug. 2017 (CEST)
Warum sind die Parameter nicht benannt? So wird das Modul bei weiterem Ausbau immer schlechter nutzbar und auch die Verwendung weniger verständlich. Bei nicht benannten Parametern kann dies sehr bald auch zu Konflikten bzw. Kollisionen führen. Davon abgesehen ist diese Implementierung natürlich sehr sinnvoll, danke dafür. Yellowcard (D.) 16:11, 27. Aug. 2017 (CEST)
Die Parameter sind nicht benannt, um eine beliebige Anzahl zu ermöglichen. Hier ein Beispiel mit mehr Parametern:
{{#invoke:Wikidata|claim|P1411|P805|Q753167|P2453|Q131285|id=Q694789}}
Ich verstehe die Bedenken wegen der unbenannten Parameter. Ein Alternativvorschlag: Statt die unbenannte Parameter immer abwechselnd als Quantifier und Quantifier-Wert zu interpretieren, könnte man alle Argumente durchsuchen und alle, deren Parameter-Name eine Property-ID ist, als Filter interpretieren. Damit würde der vorherige Aufruf folgendermaßen aussehen:
{{#invoke:Wikidata|claim|P1411|P805=Q753167|P2453=Q131285|id=Q694789}}
Wäre das besser? – jmkeil (Diskussion) 17:14, 27. Aug. 2017 (CEST)
Nachtrag: Wäre ein zusätzliches Prefix vor dem Qualifier-Namen sinnvoll? Sowas wie:
{{#invoke:Wikidata|claim|P1411|Qualifier:P805=Q753167|Qualifier:P2453=Q131285|id=Q694789}}
(Ist der ":" dort erlaubt? Wenn nicht ein anderes lesbares Trennzeichen.)
Langfristig gedacht sollte sich in dieser Variante auch !=, <= und >= realisieren lassen. – jmkeil (Diskussion) 18:24, 27. Aug. 2017 (CEST)
Bis zur Klärung der offenen Fragen habe ich die Änderung nochmal zurückgenommen. – jmkeil (Diskussion) 08:29, 29. Aug. 2017 (CEST)

Werte von Properties des Types Mathematical expression als Math ausgeben[Quelltext bearbeiten]

Noch eine kleine Anpassung im das Test-Modul: Werte von Properties des Typs Mathematical expression werden in einer Math-Umgebung ausgegeben. Ein Anschauungsbeispiel findet sich in Wikipedia:Lua/Modul/Wikidata/test. Bei Zustimmung würde ich auch diese Änderung auch gerne einbauen. –jmkeil (Diskussion) 23:52, 25. Aug. 2017 (CEST)

Undokumentierte Änderungen im Modul führen zu Scriptfehlern – bitte sofort beheben.[Quelltext bearbeiten]

Insbesondere an Antonsusi: Dies ist ein produktives Modul. Hier werden keine Tests durchgeführt, dafür gibt es ein Testmodul, das genutzt werden kann. Diese Versionsgeschichte ist unbrauchbar, die Änderungen sind undokumentiert und offenbar ungetestet. Kyle Fisher erzeugt mittlerweile zwei Scriptfehler; weder Modul:Vorlage:Infobox Fußballspieler noch die Vorlage {{Navigationsleiste Kader von Montreal Impact}} funktionieren. Insbesondere letztere verwendet lediglich eine gültige normale Wikidata-Abfrage. Das ist ein untragbarer Zustand mit destruktiver Wirkung auf den Artikelnamensraum. Bitte die Änderungen zurückdrehen, ordentlich im Testmodul testen und dann, nach Diskussion, live schalten. Insbesondere die Änderung von Rückgabewerten ohne Ankündigung und Dokumentation ist ein No-Go. Hier muss sehr sehr sorgfältig vorgegangen werden. @Queryzo: Bitte ebenfalls beachten, auch Du hast Rückgabewertetypen geändert, offenbar ebenfalls mit negativen Auswirkungen. Wenn das nicht kurzfristig geradegedreht werden kann, werde ich das Modul auf den Zustand von Juni zurückdrehen und lediglich die saubere Änderung von Jmkeil übernehmen. Danke. Yellowcard (D.) 16:08, 27. Aug. 2017 (CEST)

Meine Änderung betraf deine Funktion isSubclass(), über deren Rückgabewert wir bereits vor Liveschaltung intensiv diskutiert hatten (vgl. Diskussion auf der Rückseite). Der Rückgabewert nil verursachte offenbar Skriptfehler bei einigen Artikeln, ich habe "meine" Vorlagen nachfolgend umgestellt (#ifeq: = 1 statt #if: = wahr), wahrscheinlich musst du deine Fußballvorlagen ebenfalls anpassen. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 17:22, 27. Aug. 2017 (CEST)
Dieses Modul verursacht seit es besteht permanent Einträge in die Kategorie:Wikipedia:Seite mit Skriptfehlern. Und vor einigen wochen ist sie wieder einmal vollgelaufen. Ursache ist die generell schlechte (m. E. schlampige) Programmierung wichtiger Teile des Moduls. Beispielsweise:
  1. Von WD erhaltene Werte werden nicht auf Gültigkeit getestet.
  2. An den Wikiparser wird für den boolschen Wert "falsch" statt eines leeren Strings der Lua-Wert false zurückgegeben, was in den String "false" ( und damit in den Wert "wahr" nach Wiki-Syntax) umgewandelt wird.
  3. Es wird oft genug nil zurückgegeben, was ein undefiniertes Ergebnis ist.
  4. Es werden Funktionen als "function call by statement" aufgerufen und dann wird versucht, mit einem Rückgabewert weiterzurechnen, obwohl es gar keinen gibt. Da hat wohl jemand "function call by statement" nicht verstanden.
  5. Das liese sich noch eine Weile fortsetzen.
Die Dokumentation des Moduls war meiner pers. Meinung nach schon immer schlecht. So ein zusammengeschustertes, fehlertriefendes Modul ist für Dritte ganz einfach nicht zu durchschauen, auch nicht für Profis.

Da sich die Autoren (wohl keine Profis) leider nicht dazu durchringen konnten, das Problem (Programmierung) zu beheben, ist mir also gar nichts anderes übrig geblieben, als hier am offenen Herzen zu operieren, um einige Fehler evtl. zu beheben, auch wenn ich nicht zu den großen Experten gehöre.

Die von mir vorgenommenen Änderungen sind - soweit erfolglos - von mir selbst weitgehend revertiert worden. Übriggeblieben sind nur kleine Änderungen, welche eindeutig funktionierende Fehlerkorrekturen darstellen. Zu den Besonderheiten dieses Moduls gehört auch, dass Skriptfehler wie aus dem Nichts auftauchen und wieder verschwinden, je nachdem, ob der Wikidata-Wert gerade zufällig gültiges Format hat. Er taucht z. B. auf, wenn jemand in WD eine Zahl mit (falschem) Dezimal- oder Tausendertrenner eingibt, denn das Modul prüft sowas ja wie oben erwähnt, gar nicht. Wenn also hier ein Wert mit nil verglichen wird, dann liegt das an einer der o.g. Macken des Moduls. ÅñŧóñŜûŝî (Ð) 18:35, 27. Aug. 2017 (CEST)

Also, um mal in Kurzfassung etwas festzuhalten (was sich ausführlich auf Kategorie Diskussion:Wikipedia:Seite mit Skriptfehlern findet) – es gilt:

  • Funktionen in Lua haben zwei Typen:
    1. Für ein anderes Lua-Modul bestimmt.
    2. Für die Vorlagenprogrammierung bestimmt, Aufruf per #invoke.
  • Wenn 2.) für Vorlagenprogrammierung, und eine boolesche ja/nein-Funktion, die isIrgendwas() heißt, dann gilt immer:
    • Leerer String "" bedeutet „falsch“.
    • String mit irgendwas nicht-leerem (bevorzugt "1") bedeutet „wahr“.
  • Richtig ist, dass dieses Modul seit einem halben oder ganzen Jahr ziemlich buggy ist.
  • Warum gibt es überhaupt eine spezielle dewiki-Implementierung, wo doch eigentlich alle Funktionen Wiki-unabhängige Basisfunktionen sind?

VG --PerfektesChaos 18:48, 27. Aug. 2017 (CEST)

Das ist eine gute Frage. Ich halte es in dem Sinne für überladen, dass man zu viele Features eingebaut hat. Das von dir gepflegte Modul:Zitation ist ja schließlich auch separat. ÅñŧóñŜûŝî (Ð) 19:45, 27. Aug. 2017 (CEST)
Sagen wir mal so: Ich hätte ein weltweit gepflegtes Modul mit Wiki-unabhängigen Basisfunktionen erwartet, und dazu im Sinne von Modul:DateTime/local lokale Erweiterungen oder „Überschreibungen“ und Konfigurationen.
Modul:Zitation ist kein sinnvoller Vergleich, weil es nichts weltweit unterstützt, sondern dewiki-spezifische WP:ZR.
VG --PerfektesChaos 20:32, 27. Aug. 2017 (CEST)
Ich wundere mich auch schon lange warum wir diese Dinge x-fach parallel entwickel. Immerhin laut dem und dem scheinen sich inzwischen 3/4 Versionen herauszukristalisieren, welche von anderen Wikis übernommen werden!? Wäre es ggf. eine Option unsere eigendentwicklung durch eine dieser zu ersetzen? -- Michi 22:42, 27. Aug. 2017 (CEST)
+1 (siehe dazu WD:Wikidata#Module in anderen WP-Sprachversionen) --Leyo 22:51, 27. Aug. 2017 (CEST)
+1 wenn wir es schon nicht hinkriegen, valide Skripte zu bauen, wie geht es dann erst kleineren Sprachversionen? Gerade das Thema Infoboxen drängt, enwiki geht hier per Lua bereits den richtigen Weg, während hierzulande keine Notwendigkeit gesehen wird (siehe Vorlage Diskussion:Infobox). Wenn hierbei keine einheitl. Standards geschaffen werden (Wartbarkeit, zeitgemäße Darstellung, Wikidatakompatibilität), bastelt jeder weiter für sich, das ist ineffizient und wenig anwenderunfreundlich. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 23:41, 27. Aug. 2017 (CEST)
Eine weltweit einheitliche Variante wäre natürlich deutlich wünchenswerter. Auch eine Modularisierung in Funktionen für andere Module und Funktionen für Vorlagen (die dann ersteres verwenden) wäre glaube ich sinnvoll. Da aber dieses Modul existiert und verwendet wird, müssen wir damit erst einmal klar kommen. Ich schlage folgenden Aktionsplan vor:
  1. Beheben aller akut auftretenden Fehler, damit der dewiki-Betrieb nicht weiter gestört wird.
  2. Schreiben von Tests für alle vorhandenen Features, damit alle weiteren Schritte ohne Beeinträchtigung von dewiki durchgeführt werden können.
  3. Features einteilen nach folgenden Kriterien:
  1. enwiki oder Lokalisierung für dewiki
  2. interne Funktion oder Vorlagenfunktion
  1. Modularisieren in die sich ergebenden vier Kategorien.
  2. Funktionalität/Module, die aus enwiki kommen sollten, dorthin auslagern.
  3. Umstellen vorhandener Verwendungen auf den möglicherweise anders lautenden einheitlichen Standard.
Gruß. -- jmkeil (Diskussion) 09:00, 29. Aug. 2017 (CEST)

Jmkeil – klingt sinnvoll, besser mit folgender Reihenfolge im Fahrplan:

  1. Hotfixe zur Behebung aktueller Funktionsstörungen
  2. Dokumentation aller Funktionen (=Soll-Zustand)
    • Typ „Vorlage“ oder Typ „Lua“
      • Siehe dazu Wikipedia:Lua/Modul/URLutil/de mit Unterteilung nach Vorlagen (oben und Wikipedia:Lua/Modul/URLutil) versus „Lua-Funktionen“ (unten)
      • Beachte den Hinweis Der Rückgabewert ist eine leere Zeichenkette („nichts“), wenn der Parameterwert die Erwartung nicht erfüllt. Wenn ein Ergebnis vorhanden oder die Abfragebedingung wahr ist, resultiert mindestens ein Zeichen. (oben) und (unten) die URLutil.is*() den Wert true (sofern nicht anders angegeben); bei Misserfolg jeweils false.
    • Weltweite Standard-Basisfunktion, oder dewiki-Sonderfall, oder veraltend und mittelfristig Ersatz durch weltweite Standardfunktion.
  3. Diskussion und Konsens über die Dokumentation
  4. Aufbau einer Testumgebung auf BETA für alle Funktionen; dort sind irgendwie auch Dummy-Zugriffe auf ein Dummy-Wikidata konfigurierbar.
    • Beispiel: Wikipedia:Lua/Modul/URLutil/Test und analog auch auf BETA
    • Wenn es kein fertiges Test-Umfeld gibt, kann man eine einzelne Änderung auch nicht vorher testen. Insofern war es etwas unfair gegenüber Antonsusi, den fehlenden BETA-Test zu bemängeln, da dort offenbar bei Null begonnen werden muss.
  5. Konvertierung bisherige auf neue Programmierung.
    • Wenn der Parameter- oder Rückgabewert einer Funktion angepasst wird, dann müssen auch in allen Vorlagen die #invoke zu dieser Funktion gesucht und angeglichen werden.
  6. Härten vorhandener Programmierung gegen Ausnahmesituationen oder bislang nicht erwartete Sonderfälle.
  7. Neue Features.

Allgemeiner Hinweis:

  • Da oben steht was von: #ifeq: ... | 1 statt #ifeq: ... | wahr.
  • Eine Funktion für die Vorlagenprogrammierung, die nur eine ja-/nein-Antwort liefern soll, wird nie mit #ifeq: auf konkrete Rückgabewerte wie 1 oder wahr oder true oder nicht nil getestet.
  • Vielmehr: {{#if: {{isIrgendwas}} | wahr-Aktion | falsch-Aktion}}

VG --PerfektesChaos 10:27, 29. Aug. 2017 (CEST)

Ist intuitiv und macht absolut Sinn, danke für dein Machtwort hinsichtlich der Rückgabewerte. Nun sollte das Modul dahingehend vereinheitlicht werden, in der Skriptfehler-Kategorie sollte dann erstmal Ruhe sein. Antonsusi hatte bereits begonnen, war sich dann aber auch unsicher. Also: intern true/false, für extern, d.h. im Wikiparser verwendbare Funktionen, 1/"". LG –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 11:01, 29. Aug. 2017 (CEST)

Editier-Maßstäbe[Quelltext bearbeiten]

Beim MediaWiki:Common.css werden nur ganz selten Änderungen gemacht, und wenn, dann nur wenn sie hieb- und stichfest sind und hinreichend diskutiert. Hier dagegen, bei einem Modul was hundertausenfach verwendet wird, kann jeder Depp herumpfuschen - sogar IPs! Kann es sein, dass die Maßstäbe nicht ganz stimmen? Für das Editieren in diesem Modul sollten die gleichen Richtlinien gelten wie für die Common.css - inklusive Vollsperrung. 129.13.72.197 11:07, 29. Aug. 2017 (CEST)

Ganz so extrem sehe ich das nicht. Einerseits betrifft Common.css alle Seiten, wärend dieses Modul noch "relativ wenige" Seiten betrifft, andererseits ist Common.css in gewissem Sinner weitestgehend "fertig", wärend dies hier eine große Baustelle ist, wo Hilfe grundsätzlich wichtig und wünschenswert ist. Vollsperrung halte ich daher im Moment für kontraproduktiv. -- Michi 12:36, 29. Aug. 2017 (CEST)
"Relativ wenige"? 458.802 sind nicht "relativ wenige", sondern mehr als ein Viertel des Artikelbestandes. 129.13.72.197 16:53, 29. Aug. 2017 (CEST)
Die Zählung möchte ich anzweifeln. Würde mich zwar freuen, aber das kann ich mir ehrlichgesagt schwer vorstellen. Warum da was falsch gezählt wird weiss ich allerdings auch nicht. Anyways, stimme Michi zu. --Aeroid (Diskussion) 19:12, 29. Aug. 2017 (CEST)
Die Zählung ist wohl schon korrekt, wenn man beachtet, dass Vorlage:Begriffsklärung (245.000 Einbindungen) und Vorlage:IMDb (126.000 Einbdungen) das Modul verwenden. --Pasleim (Diskussion) 19:53, 29. Aug. 2017 (CEST)
Es ist immer einfach, irgendwas in Zweifel zu ziehen, ohne dafür Gründe zu nennen. Die Zählung ist korrekt und 480.000 Einbindungen sind sehr vier Holz. Normale Vorlagen werden schon bei weniger Einbindungen vollgesperrt (z. B. Vorlage:Begriffsklärung mit den genannten "nur" 245.432 Einbindungen). 92.75.222.32 22:53, 29. Aug. 2017 (CEST)

Hab's 3/4 gesperrt, erscheint mir sinnvoll. lg --Herzi Pinki (Diskussion) 17:52, 17. Sep. 2017 (CEST)

Wert eines Qualifiers für ein bestimmtes Statement auslesen[Quelltext bearbeiten]

Hallo zusammen, ich würde gerne für die Vorlage:Infobox Schutzhütte die Anzahl an Betten, Matratzenlagern etc. aus WikiData auslesen. Dort sind die Werte schon drin (in der hier diskutierten Struktur). Meine Frage ist nur: Wie komme ich da jetzt am besten dran? Meine einzige Lösung bisher ist diese hier:


Anzahl an Matratzenlagern in [[:d:Q901903]]:
{{#switch: Matratzenlager
| {{str_split|1|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|hasqualifier=P1114}}|;}} =
    {{str_split|1|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|qualifier=P1114}}|;}}
| {{str_split|2|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|hasqualifier=P1114}}|;}} =
    {{str_split|2|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|qualifier=P1114}}|;}}
| {{str_split|3|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|hasqualifier=P1114}}|;}} =
    {{str_split|3|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|qualifier=P1114}}|;}}
| {{str_split|4|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|hasqualifier=P1114}}|;}} =
    {{str_split|4|{{#invoke:Wikidata|claim|P912|id=Q901903|list=;|qualifier=P1114}}|;}}
| #default = 0
}}

Teste es für d:Q901903


Das funktioniert zwar (solange Matratzenlager als eine der ersten vier Einrichtungen angegeben ist), sieht aber furchtbar aus. Geht das nicht auch irgendwie einfacher?! --Tkarcher (Diskussion) 15:39, 26. Sep. 2017 (CEST)

siehe oben die neue Funktionalität in claim von jmkeil, derzeit ist sie aber wieder deaktiviert wegen Unklarheiten bei den Rückgabewerten. Ich warte auch bereits sehnsüchtig darauf. :-) Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 22:42, 26. Sep. 2017 (CEST)
Sicher? Zumindest bei dem gezeigten Müggelsee-Beispiel geht es ja darum, ein Qualifier-Paar ("Bestimmungsmethode: Maximum") zu übergeben und ein Statement (7,5) als Ergebnis zu erhalten, oder? Und ich brauche es ja genau umgekehrt, also: Statement ("Matratzenlager") und Qualifier-Key ("Anzahl") übergeben, und Qualifier-Wert (127) als Ergebnis erhalten. --Tkarcher (Diskussion) 23:14, 26. Sep. 2017 (CEST)
Ja, du könntest dann einfach die Bettenanzahl abfragen mit {{#invoke:Wikidata|claim|id=Q901903|P912|Q42177|P1114}} usw. –Queryzo ?! Red-WikiPill.png Blue-WikiPill.png 07:12, 27. Sep. 2017 (CEST)
Das wäre wirklich ideal. Dann warte ich mal genauso sehnsüchtig wie du... (oder kann ich als Nicht-Programmierer irgendwas tun, um die Wartezeit zu verkürzen?) --Tkarcher (Diskussion) 09:00, 27. Sep. 2017 (CEST)

Aufteilung des Moduls[Quelltext bearbeiten]

Hallo. Ich schlage vor, das Modul in zwei Teile zu teilen. Ein Modul, welches ausschließlich Funktionen für den Aufruf durch andere Module oder Lua-Funktionen enthält, und ein Modul, welches nur die Funktionen enthält, welche mit invoke aufgerufen werden. Ich bin der Auffassung, dass so eine klarere Trennung erfolgt und die Gefahr, dass z. B. die falsche boolesche Syntax verwendet wird (false versus Leerstring für falsch) verringert wird. Das zweite Modul müsste dann das erste einbinden und das erste wäre ggf. international zu gestalten. Es kann dann auch bereits existierende richtig funktionierende Funktionen anderer Wikis übernehmen. ÅñŧóñŜûŝî (Ð) 17:37, 1. Okt. 2017 (CEST)

Aufteilung ja, aber nicht in dieser Manier.
  • Es gibt überhaupt keinerlei Problem, in demselben Modul parallel die gleiche Funktionalität sowohl für Vorlagen wie auch für Lua-Aufrufe anzubieten; sogar unter gleichen Namen.
  • Modul:URIutil Modul:URLutil Modul:WLink und ein Dutzend weitere machen das ohne die geringsten Schwierigkeiten.
  • Es kann auch keinerlei Problem bei sachgerechter Konstruktion geben, weil per #invoke: ausschließlich die für Vorlagen geeigneten Funktionen aufrufbar sind und keinerlei Verwechslung möglich ist.
  • Alle für #invoke: angebotenen Funktionen müssen auch konsequent immer die Vorlagenvariante (also Zeichenkette) zurückgeben.
  • Vielmehr ist es sinnvoll, in ein und demselben Modul gleichartige Funktionalitäten beienander zu halten, statt die gleiche Funktion an unterschiedlichen Stellen pflegen zu müssen, was über kurz oder lang inkonsistent wird.
Wenn Aufteilung, dann einerseits
  • nach international standardisierten Funktionalitäten
  • nach lokalen spontan und unbürokratisch realisierbaren Funktionen.
  • Die Schnittstelle für Vorlagen bietet nur ein einziges Modul an, zusammen für die lokalen und weltweiten Aufgaben.
  • Im Hintergrund und für keinen Anwender wahrnehmbar werden weltweit einheitliche Aufgaben delegiert, an ein weltweit synchronisiertes Modul mit Basisfunktionen durchgereicht, das dann die komplexere Programmierung möglichst weitgehend übernehmen sollte. Das aber nur intern und ohne dass irgendein Anwender davon etwas herausfinden könnte.
VG --PerfektesChaos 20:02, 1. Okt. 2017 (CEST)
Ich versuche mal, meine Überlegungen so in Worte zu fassen, dass es verständlich ist:
Ich habe bei dem Chaos mit dem hiesigen Modul den Eindruck, dass nicht immer jedem klar ist, welche Funktionen für den Aufruf durch Vorlagen per #invoke: vorgesehen sind und welche nicht. Es sieht sehr danach aus, dass Quellcode von lua-internen Funktionen, welche sowohl von anderen, lua-internen Funktionen, als auch von den per Invoke aufrufbaren Funktionen aufgerufen werden, nicht von beiden Seiten wie reiner Luacode "behandelt" werden oder sonstwie verschiedene Rückgaben erwarten. Eine gute Kapselung, welche wichtige Programmteile davor schützt, beim Versuch, neue Features eintuführen, beschädigt zu werden, ist da wohl sinnvoll.
Und nicht zuletzt, da sind wir uns vermutlich einig: Eine konsequente Überprüfung von Daten auf Gültigkeit ist hier dringend durchzuführen, und zwar direkt nach dem "Einlesen von Wikidata" und auch am Beginn einer Funktion die erhaltenen Parameterwerte.
Ich hoffe, es war verständlich. Evtl. mache ich eine Skizze. ÅñŧóñŜûŝî (Ð) 22:01, 1. Okt. 2017 (CEST)
Ich habe das schon verstanden; aber der Weg, um das zu lösen ist in den genannten Modulen nachzulesen.
Um es mal ganz simpel zu sagen:
  • In allen unseren Modulen gibt es ganz hinten einen mit Kommentar „Export“ gekennzeichneten Block.
  • Dort wird eine Variable p als Rückgabewert definiertt; und das weltweit durchgehend.
  • Alle Funktionen dort, mit p, sind (von seltenen Ausnahmen abgesehen) immer für Vorlagen/#invoke: vorgesehen und liefern dann immer eine Zeichenkette.
  • Alle anderen Funktionen sind für Lua↔Lua, können sonstwas liefern, und sind mangels Export für Vorlagen unerreichbar.
  • Das ist bei allen Modulen so.
  • Wenn das auch durchgehend so eingehalten wird, kann man auch nichts falsch anwenden.
Dein Vorschlag läuft darauf hinaus, ein einsames Unikat zu bauen, das es nirgendwo sonst gibt, und die gleiche Funktionalität grundlos in zwei Module zu verstreuen, und zweimal auf zwei verschiedenen Dookumentationen die gleichen Funktionen zu erläutern.
  • Das ist ja noch verwirrender, und weder zu warten noch zu durchschauen.
  • Von mangelhafter Performance mal ganz abgesehen.
Ich habe weiter oben schon mal den Weg beschrieben: Was hier fehlt, ist zuallererst einen saubere Dokumentation des Sollzustands.
VG --PerfektesChaos 23:09, 1. Okt. 2017 (CEST)
Mir ist der Unterschied schon klar, ich habe ja selber bereits kleinere Module geschrieben, aber es gab wohl Verwirrung, zumindest bei sowohl internen, als auch bei externen Parametern und Rückgabewerten.
Das du irgendwo eine Doppelung siehst, zeigt aber, dass du mich nicht völlig verstanden hast, denn ich sehe bei dem, was ich meine, keine Doppelung. worin genau siehst du die Doppelung? ÅñŧóñŜûŝî (Ð) 11:12, 3. Okt. 2017 (CEST)
Schlicht in der Überschrift dieses Threads: „Aufteilung des Moduls“.
Sofern nicht auf künftig weltweit gepflegte Basisprogrammierung zurückgegriffen wird, soll die gesamte Programmierung zu einer Funktionalität auch nur in einem Modul beisammenbleiben und nicht grundlos zersplittert werden.
Im Übrigen wäre Dokumentationsarbeit momentan vorrangig.
VG --PerfektesChaos 11:17, 3. Okt. 2017 (CEST)
⇐ Vom Zerlegen in kleine Minimodule halte ich auch nichts, aber eine Aufteilung in ein Modul mit Kernfunktionen, das man nur selten editieren muss und deshalb ggf. Vollsperre bekommt, und einem für diverse Vorlagenprogrammierer, also mit exportierten Funktionen, wäre gut. Aber was soll's. Wer die bestehenden Funktionen versteht, der könnte sie ja mal dokumentieren... ÅñŧóñŜûŝî (Ð) 21:04, 3. Okt. 2017 (CEST)

Und noch einmal:

  • Die Aufteilung von Programmcode auf unterschiedliche Module ist ein schwerwiegender Eingriff, der mit erheblichen Nachteilen verbunden ist.
    • Die gleiche Funktionalität aus zwei Modulen zu beziehen ist verwirrend und fehlerträchtig; außerdem unübersichtlich zu dokumentieren.
    • Die Pflege der gleichen Funktionalität in zwei Modulen ist umständlich, und es kann leicht zu Inkonsistenzen kommen.
    • Jede Verwendung des Zweitmoduls bedarf eines require(), was den Code-Ablauf komplizierter und weniger performant macht.
  • Eine Verteilung in unterschiedliche Module ist nur gerechtfertigt, wenn dem ein erheblicher Vorteil gegenübersteht.
    • Nutzung in mehreren Wikis:
      1. ein Programm-Teil für alle Wikis einheitlich, und hierfür weltweit einheitlich aktualisiert und weiterentwickelt
      2. ein Konfigurations-Teil nur für das lokale Wiki
    • Datenmodul ohne Funktionen, das pro Seite nur einmal eingebunden wäre.
    • Verwendung von Bibliotheksfunktionen aus einem völlig anderen Themenbereich.
      • Liegt hier nicht vor, weil beide vorgeschlagenen Module dasselbe Wikidata-Feld beackern.
  • Interessant ist, dass du nunmehr die Begründung komplett gewechselt hast; was bedeutet, dass es gar keine wirkliche Begründung gibt:
    1. Die Funktionen müssten zwischen Vorlagen-#invoke und Lua-internem Aufruf aufgeteilt werden, weil Anwender sie miteinander verwechseln könnten (was Nonsens ist, wie gezeigt wurde).
    2. Nunmehr sollen die einen vollgeschützt werden, die anderen nicht.
      • Es sind keinerlei inhaltliche Gründe erkennbar, warum der eine Realisierungsteil der Funktionalität schützbar und der andere veränderbar sein soll; wenn man etwas verändert, müssen in der Regel beide Teile konsistent geändert werden, und zwar in demselben Edit.
      • Das Zeug ist so wacklig und noch meilenweit von einer stabilen Version entfernt, dass ein Vollschutz sich noch auf Jahre hinaus verbieten würde; egal für was.
      • Es gibt auch keine „Kernfunktionen“ und „andere“. Es ist die gleiche Funktionalität, nur aus zweierlei Software-Kontext zugegriffen.

Zusammengefasst:

  • Nur die Mitbenutzung eines weltweit gepflegten Bibliotheksmoduls rechtfertigt eine Auslagerung von Code.
  • Auch in diesem Fall bleiben sämtliche Aufrufe durch Anwendungen im lokalen Modul; und der Rückgriff auf weltweite Funktionen erfolgt intern und ohne von außen erkennbar zu sein.
  • Der Vorschlag ist so absurd, unbegründet und wäre in seinen Auswirkungen so schädlich, dass sich jede weitere Diskussion darüber erübrigt; außerdem schon mehr als genug Zeit und Nerven verpulvert hat, die an anderer Stelle fehlen.

VG --PerfektesChaos 09:11, 4. Okt. 2017 (CEST)