Wikipedia Diskussion:Lua/Modul/Wikidata/Archiv/2017

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Anzahl beschränken

Letzter Kommentar: vor 7 Jahren10 Kommentare2 Personen sind an der Diskussion beteiligt

Könnte man für claim noch einen Parameter für die auszugebende Anzahl der Listenelemente implementieren, z.B. für das Beispiel, gib mir die Einwohner der letzten 10 Jahre in Berlin? –Queryzo ?! 18:34, 12. Mär. 2017 (CET)

@Queryzo: Kannst Du das mal an einem Beispiel verdeutlichen? Yellowcard (D.) 12:35, 11. Apr. 2017 (CEST) (ping wegen Tippfehler: Queryzo). Yellowcard (D.) 12:36, 11. Apr. 2017 (CEST)
Um das Beispiel von der Doku zu nehmen, {{#invoke:Wikidata|claim|P6|id=Q64}} liefert Kai Wegner, also den amtierenden Bürgermeister von Berlin. Mit list= kann ich mir auch alle regierenden Bürgermeister ausgeben lassen, nicht jedoch die letzten 10. Dieses Beispiel ist nur konstruiert, speziell geht es um Darstellerlisten bei Filmen. –Queryzo ?! 15:25, 11. Apr. 2017 (CEST)
Die Anzahl zu begrenzen, wäre sehr einfach. Das Problem könnte eher „die letzten 10“ sein: Du möchtest also ggf. erst sortieren (mit sort oder sortInItem?) und dann die Anzahl begrenzen, richtig? Yellowcard (D.) 15:48, 11. Apr. 2017 (CEST)
ohne sortieren würde erstmal reichen. –Queryzo ?! 16:38, 11. Apr. 2017 (CEST)
@Queryzo: Im Testmodul sollte es jetzt gehen, auch mit Sortierung: {{#invoke:Wikidata/Test|claim|P6|id=Q64|list=, |sort=P580|listMaxItems=3}} liefert die ersten drei Bürgermeister. Ich weiß gerade nicht, ob das Modul auch schon die Sortierreihenfolge umkehren kann; das wäre für die letzten drei dann noch notwendig. Bitte mal testen, dann können wir das ins produktive Modul übernehmen. Grüße, Yellowcard (D.) 16:43, 11. Apr. 2017 (CEST)
Sortierreihenfolge umkehren geht mit dem Parameter inverse. Wer denkt sich solche Parameternamen aus? :( Die letzten drei Bürgermeister also mit {{#invoke:Wikidata/Test|claim|P6|id=Q64|list=, |sort=P580|inverse=yes|listMaxItems=3}} Yellowcard (D.) 16:48, 11. Apr. 2017 (CEST)
siehe Portal:Film/Im Kino, es scheint ein Problem zu geben, wenn weniger Statements vorhanden sind als in listMaxItems angegeben. –Queryzo ?! 16:50, 11. Apr. 2017 (CEST)
Mit diesem Fix scheint es zu gehen. –Queryzo ?! 18:01, 11. Apr. 2017 (CEST)
Guter Einwand, danke! Habe das jetzt ins Hauptmodul übernommen. Yellowcard (D.) 18:50, 11. Apr. 2017 (CEST)

references=ja

Letzter Kommentar: vor 7 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt

Ich fände es sinnvoller, bei references=ja nur die Referenz zurückzugeben, ohne den eigentlichen Wert. Das würde die Funktion deutlich handhabbarer machen (z.B. wären Zahlen vorher formatierbar, man könnte mit ihnen rechnen etc.). Gibt es da Einwände? Wird der Parameter schon irgendwo produktiv genutzt, sodass eine Änderung hier etwas zerschießen würde? (Falls ja, würde ich für die Einführung eines weiteren Parameters plädieren, z.B. onlyreferences=ja, was dann zum beschriebenen Verhalten führt.) MichaelSchoenitzer, hast Du hierzu eine Meinung? Grüße, Yellowcard (D.) 01:24, 9. Apr. 2017 (CEST)

Klingt nach ner sinnvollen Erweiterung, aber warum das bestehende Verhalten ändern & warum so eine Komplizierte Ausweichsyntax? Warum nicht references=only (oder besser ein deutsches Äquivalent, mir fällt nur auf die Schnelle kein schönes ein.)? -- Michi
Ich kann den Vorschlag, vielleicht eher in der Version von Michi (d.h. zusätzlich zur Option "ja" eine Option "only" bzw. "nur"), nur unterstützen. Ohne Umrechnung (z.B. Dollar zu Millionen Dollar) sind die Daten oft nicht verwendbar. 123 (Diskussion) 01:48, 11. Apr. 2017 (CEST)
Geht jetzt im Testmodul, bitte mal testen: {{#invoke:Wikidata/Test|claim|P991|id=Q22909554|references=only}} sollte nur den Einzelnachweis zurückgeben. Die Performance kann man ggf. noch verbessern (derzeit wird auch der Wert geladen, aber dann einfach nicht mit ausgegeben – das Laden könnte man sich also komplett sparen, um etwas Ressourcen einzusparen). Yellowcard (D.) 16:46, 11. Apr. 2017 (CEST)
Hab's einige Male ausprobiert und kein Problem entdeckt. Danke! 123 (Diskussion) 00:37, 12. Apr. 2017 (CEST)

Probleme der Ausgabe von Quellen (references)

Letzter Kommentar: vor 7 Jahren14 Kommentare2 Personen sind an der Diskussion beteiligt

Wer war der erfolgreiche Kandidat der Wahl des UN-Generalsekretärs 2016? Mit Quelle bitte:

António Guterres[1]

Ich sehe hier drei Problem bei der Quellenangabe:

  • Der Titel ist auf wikidata als englischer "monolingualer Text" angegeben. So wie wikidata selbst sollte deshalb die Quellenangabe allein schon deshalb die Angabe "Englisch" nach dem Titel ausgeben. Also etwa: "António Guterres appointed next UN Secretary-General by acclamation. (Englisch)" als Titelangabe. (Aber ich denke, das ist keine Priorität!)
  • Der wikidata Eintrag enthält m.E. redundanter- und fälschlicherweise auch den Eintrag "language of work or name" (P407). Das wird, was das Layout angeht, irgendwie stöhrend an den Eintrag Verlag angefügt. Es wäre schon wichtiger, so was verhindern zu können. Idealerweise würde das Modul deshalb erlauben, auszuwählen, welche Elemente einer Quellenangabe (reference) angegeben werden. (Aber als Alternative könnte man auch den redundanten Eintrag auf wikidate löschen.)
  • Mein Hauptproblem ist die Angabe "Verlag". Die Vereinten Nationen sind kein Verlag. Und wenn man Einträge für "publisher" bei Quellenangaben auf wikidata durchschaut[1], stellt man fest, daß sich praktisch keiner auf einen Verlag bezieht: Rostock District, BBC, Statistics Belgium, Adobe Systems, Aargau, Department of Defense, Microsoft, World Health Organization, Bochum, oronto, International Astronomical Union, Bad Doberan, erbo-Croatian, Facebook, Wikimedia Foundation ... alles keine Verlage.

Ich habe dieses Problem auf wikidata angesprochen, aber es scheint, daß von daher keine Lösung kommen wird. 123 (Diskussion) 03:05, 11. Apr. 2017 (CEST)

@123: Das größte Problem scheint mir die Inkosistenz der Übersetzungen deutsch <-> englisch bei den Properties Herausgeber (P98) und Verlag (P123) zu sein. Bei uns ist ein Verlag halt soetwas wie ein Verlagshaus, übersetzt ist das aber mit „Publisher“. Ein „Publisher“ im englischsprachigen Raum ohne Kontext ist eher ein „Herausgeber“. Die englische Übersetzung in Herausgeber (P98) wiederum ist „editor“, was man durchaus aus als „Herausgeber“ bezeichnen kann, aber in einem anderen Kontext. Dieses Problem muss man auf Wikidata lösen, es ist kein Fehler des Moduls, und ich bin gerade ratlos, wie man das am besten trennt, zumal die Properties ja beide nicht gerade selten genutzt werden. Hast Du hier irgendeine Idee? Yellowcard (D.) 12:34, 11. Apr. 2017 (CEST)
Was bis zur Lösung des Problems aus Wikidata helfen sollte: Angesichts des Ist-Zustands könnten wir Verlag (P123) für den Parameter hrsg= der {{Internetquelle}} verwenden, wenn Herausgeber (P98) in der Fundstelle nicht gesetzt ist. Das würde die ganzen Angaben von Verlag (P123) sauber in die Vorlage unterbringen – auch dann, wenn es sich tatsächlich um einen Verlag handelt. Mir scheint es, als würden diese beiden Eigenschaften in den Fundstellen ohne System parallel genutzt und wild vermischt ... Yellowcard (D.) 14:18, 11. Apr. 2017 (CEST)
Gut, von 52155 Einträgen mit in der Quellenangabe P123 sind nur bei 61 die angegebenen items Instanzen von publisher (in 7 Fällen davon sind das keine Verlage und in 4 Fällen ist sowohl ein Herausgeber wie ein publisher angegeben). Es wäre also zu verkraften, wenn in den wenigen Fällen, wo nur und tatsächlich ein Verlag angeben wurde, vor dem Verlag "Herausgeber:" stünde, bis das tieferliegende Problem auf wikidata gelöst ist. (Das wäre das Ergebniss Deines Vorschlags, oder?) Besser jedenfalls, als wenn bei über 50000 Fällen "Verlag:" vor einer Organisation steht, die keiner ist. Alternativ könnte man sich auch an der Formatierung entsprechend "cite web" orientieren, dann würde einfach nichts davor stehen und man kann aus dem Kontext erschließen, um was es sich handelt.)
Wäre mein zweites Problem (die Angabe "Sprache des Werks oder des Namens: Englisch" klebt an "Vereinte Nationen" dran und sollte irgendwie - z.B. Komma und Leerzeichen - abgesetzt werden) auch lösbar? 123 (Diskussion) 18:20, 11. Apr. 2017 (CEST)
Das ist bei der Vorlage {{Internetquelle}} doch gar nicht der Fall, siehe Vorlage:Internetquelle#Normale_Internetquellen, drittes und viertes Beispiel. Ich versuche das mal, umzusetzen. Das zweite Problem sollte sehr leicht zu lösen sein. Yellowcard (D.) 18:57, 11. Apr. 2017 (CEST)

@123: {{#invoke:Wikidata/Test|claim|P991|id=Q22909554|references=ja}} ergibt: António Guterres[1]. Ich habe Verlag (P123) als zusätzliches Argument für hrsg= (wird von Herausgeber (P98) überschrieben, wenn beide vorhanden) sowie Sprache des Werks, Namens oder Begriffes (P407) als zukünftiges Argument für sprache= (wird von Originalsprache (P364) überschrieben, falls vorhanden) hinzugefügt. Wenn mehrere unbekannte Eigenschaften auftreten, die zusammen ins Kommentarfeld geschrieben werden, werden diese durch Komma und Leerzeichen voneinander getrennt. Bitte gerne ausgiebig testen, ob wir das ins Modul:Wikidata übernehmen können. Danke, Yellowcard (D.) 19:20, 11. Apr. 2017 (CEST)

Danke! Habe einiges ausprobiert und keine neuen Probleme mit Wikidata/Test entdeckt. Allerdings löst Wikidata/Test das Problem nur dann, wenn es sich um a) eine Internetquelle handelt und b) ein Titel angegeben ist. Das läßt doch noch eine ganze Reihe von Fällen durch, wo etwas als Verlag bezeichnet wird, was keiner ist. Weder die Weltgesundheitsorganisation, noch der Kanton Aargau, noch auch Blitz sind Verlage. (Blitz ist eine Tageszeitung, die bei Ringier erscheint.)
Außerdem sind mir noch eine Reihe von weiteren Problemen mit Referenzen aufgefallen, die nicht nicht direkt mit der Frage Verlag/nicht Verlag zusammenhängen und schon im Hauptmodul auftreten:
  • Die Reihenfolge der Angaben bei gedruckten Quellen ist doch eher gewöhnungsbedürftig. Wäre es möglich auch bei solchen Quellen auf eine Zitierweise überzugehen, die der Vorlage:Literatur entspricht? Ein besonders unschönes Beispiel: Ost-Berlin[6]
  • In einigen Fällen gibt's ein unnötiges Komma: 3. September 1968[7] oder Madrid[8]
  • Aus irgend einem Grund gibt folgendes gar keine Quellen an: New York City, Rom
  • Wenn die Quelle als item existiert und als solches angegeben wurde, gibt es nur einen Verweis auf die für normale Nutzer nichtssagenden Item-ID: 1357326[9]

@123: Ja, klar, allumfassend ist dieses Modul nicht und ich denke, das wird es auch nicht sein können, denn dafür ist die Komplexität etwas zu groß. Das könnte man höchstens in einem separaten Modul lösen, könnte ich mir vorstellen. Jedenfalls kann die {{Internetquelle}} ja nur verwendet werden, wenn ein Titel vorhanden ist. Wir können gern noch weitere Properties ausmachen, die als Titel verwendet werden können, wenn Titel (P1476) nicht gesetzt ist, aber grundsätzlich benötigen wir irgendeinen Titel, um die Vorlage zu verwenden. Wenn die Vorlage nicht verwendet wird (und auch {{Literatur}} nicht, s.u.), bleibt auch nicht viel übrig, als die Parameter hintereinander einfach darzustellen, sonst nimmt man dem Modul die Flexibilität. Und da wiederum werden die Eigenschaften dann eben entsprechend der Label auf Wikidata benannt. Das heißt, um dieses Problem zu lösen, muss Verlag (P123) umbenannt oder in den Fundstellen Herausgeber (P98) verwendet werden. Dass die Weltgesundheitsorganisation als Verlag bezeichnet wird, ist ein Fehler auf Wikidata, den wir hier nur begrenzt lösen können. Was man hier aber noch tun kann (gem. Dein zweites und drittes Beispiel), wäre die Reihenfolge der Eigenschaften zu verändern. Das ist aber ggf. nicht ganz so trivial und sollte man sich vorher überlegen, aber URL der Fundstelle und Titel sollten wohl immer zuerst genannt werden, dann den Rest.

Die Vorlage {{Literatur}} kann man auch verwenden, ist aber noch nicht umgesetzt. Die Funktionsweise kann ähnlich zur Internetquelle ablaufen und der Grundstein dafür ist auch gelegt. Ich schau mir das bei Gelegenheit mal an, aber vorher sollten wir sehen, dass die Internetquelle einigermaßen rundläuft.

Die doppelten Kommata kann ich gerade nicht nachvollziehen, da müsste man mal genauer in den Code schauen. Was mir hier auffällt, ist, dass die Internetquelle-Vorlage nicht verwendet wird, weil das Abrufdatum fehlt. Das finde ich nicht sinnvoll, das Abrufdatum sollte nicht obligatorisch sein. Das lässt sich aber im Modul nicht sofort lösen, da die Vorlagenprogrammierung der Vorlage:Internetquelle diesen Parameter als obligatorisch einstuft und sogar eine Fehlermeldung zurückgibt, wenn er fehlt. Das muss also in der Vorlage geändert werden, dann können wir das Modul leicht nachziehen. Habe es zur Diskussion gestellt: Vorlage_Diskussion:Internetquelle#Abrufdatum_optional. Das Problem mit den Kommata sollte davon unabhängig aber behoben werden. (nachträgliche Ergänzung: Das Problem mit den doppelten Kommata sollte hiermit gelöst sein. Yellowcard (D.) 15:18, 12. Apr. 2017 (CEST))

Zum vorletzten Beispiel: Wenn importiert aus Wikimedia-Projekt (P143) in der Fundstelle gesetzt ist, wird keine Quellenangabe zurückgegeben (bewusst ausgefiltert, Kommentar im Quellcode: „-- "imported from"-references are mostly useless, skip them“, hier so realisiert von MichaelSchoenitzer). Ob man das so belassen möchte, kann man sicherlich diskutieren, aus technischer Sicht ist das aber dementsprechend nachvollziehbar. Ich finde es auch inhaltlich gut, die „importiert von“-Einzelnachweise dürften zu fast 100% als Einzelnachweis im ANR unbrauchbar sein.

Zum letzten Beispiel: Nein, eigentlich wird das deutsche Label dafür ausgegeben. Hier ist bloß keines gesetzt. Als Fallback dient m.W. das englische Label, was aber hier ebenfalls nicht gesetzt ist. In dem Fall kann das Modul nichts machen, das ist ein Problem auf Seiten Wikidata. Yellowcard (D.) 15:12, 12. Apr. 2017 (CEST)

Nochmals Danke: Für die Lösung des Kommaproblems, die Initiative mit der Vorlage:Internetquelle, die Erklärungen und ingesamt für das tolle Engagement. Zu einigen der Punkte: Falls bei einer Internetquelle der Titel fehlt, kann man dann nicht einfach die URL als Titel nehmen? Schön ist das nicht, aber schöner als die Ausgabe ohne Vorlage allemal. Was die Reihenfolge angeht: Kann man sich da nicht einfach an die DIN 1505-2 und die Vorlage:Literatur anlehnen, falls sie geändert wird? (Autor bzw. Herausgeber, Titel, etc.) Dass "imported from" nicht verwendet wird, scheint mir sinnvoll. Was das letzte Beispiel angeht: Wahrscheinlich ist das unmöglich, oder nur mit einem unverhältnismäßigen Aufwand zu machen, aber wenn man mal träumt, so wäre es eigentlich wünschenswert, dass die Angaben aus dem entsprechenden Datensatz bezogen werden oder dass wenigstens ein Link auf den Datensatz gesetzt wird (ob nun ein Label vorhanden ist oder nicht): Ich habe für den zitierten Fall jetzt ein Label gesetzt (es gibt auch eine englische Version des Reports), aber damit fehlen ja noch immer eine Menge Angaben, die man findet, wenn man das Item auf Wikidata besucht. 123 (Diskussion) 18:20, 12. Apr. 2017 (CEST)
@123: Ich habe das Testmodul vorhin komplett umgearbeitet, jetzt wird das ziemlich mächtige Modul:Zitation zur Formatierung verwendet. Das sollte die meisten Anwendungsfälle abdecken. Was hälst Du jetzt von der Gestalt der Einzelnachweise? Bleibt noch das Problem der fehlenden Titel. Ich habe jetzt pauschal immer „Titel nicht angegeben“ gesetzt, wenn Titel (P1476) nicht auf Wikidata gesetzt ist. Das ist nicht optimal. Vielleicht sollten wir hier ein paar Regeln aufstellen, welche Property als Titel verwendet werden kann, wenn Titel (P1476) nicht gesetzt ist. Yellowcard (D.) 03:45, 13. Apr. 2017 (CEST)
Habe jetzt die URL als Titel verwendet, wenn kein Titel angegeben wird. Wenn weder Titel noch URL angegeben sind (letztes Beispiel), wird halt nichts ausgegeben. Ich finde, die Einzelnachweise sehen jetzt alle ziemlich gut aus. Was meinst Du? Yellowcard (D.) 03:52, 13. Apr. 2017 (CEST)

Toll! Ich finde auch, das kann sich jetzt sehen lassen. Natürlich sind immer Verbesserungen möglich ;-) Insbesondere frage ich mich ob das "In:" bei "stated in" wirklich sinnvoll ist, oder ob man es nicht besser wegläßt. (Normaler weise würde man nach dem "In:" ja die Angabe einer Zeitschrift, eines Sammelbandes o.ä. erwarten.) Außerdem denke ich immer noch, dass ein Link in diesen Fällen auf die Beschreibung der Quelle in Wikidata sinnvoll wäre. (Zu kompliziert?) In dem Beispiel "Population of Municipalities - 1 January 2016" würde man da dann eben weitere Angaben und ein Link zur eigentlichen Quelle finden. Ich füge noch drei Beispiele dazu, die die "In:-Problematik" illustrieren:

17. April 1854[10][11] (Die zweite Angabe sähe ohne das "In:" perfekt aus. Gäbe es ein Problem, wenn die vorausgehende URL in die zweite Referenz intergriert wäre?)

Bad Doberan[12][13] (Interessant, weil es so aussieht, als würde die zweite Referenz Angaben von der ersten übernehmen.)

Vizepräsident der Europäischen Kommission[14][15] and Außenminister[16].

@123: Beispiele #3, #4 und #11 sehen nochmal etwas freundlicher aus (nur die Grund-URL wird angezeigt, einmal mehr Dank an PerfektesChaos). Was das „In:“ angeht, könntest Du mal auf Wikipedia:Lua/Modul/Zitation/Datenmodell#Neutraler Datenkatalog schauen, ob Du einen Wert findest, auf den veröffentlicht in (P1433) und/oder nachgewiesen in (P248) besser gemappt werden könnten als auf „Werk“ (ggf. auch unter bestimmten Bedingungen, z.B. wenn bestimmte andere Eigenschaften nicht vorhanden sind); die Angabe von „Werk“ erzeugt nämlich das „In:“. Das könnte man sicherlich umsetzen. Was den Link auf die Quelle in Wikidata angeht: Das sollte wirklich nicht zu kompliziert sein. Auch hier wäre es eine große Hilfe, wenn Du die Bedingung formulieren könntest, wann ein solcher Link angezeigt wird. Schön, dass sich jemand so intensiv mit dem Modul beschäftigt :) Grüße, Yellowcard (D.) 01:41, 14. Apr. 2017 (CEST)
Ich weiß nicht, ob ich in den nächsten Tagen Zeit haben werde, mir die Bedingungen näher anzuschauen. Aber soviel schon mal jetzt: Die Verbesserung mit der Anzeige der Grund-URL ist ein Meilenstein! Danke und bis bald. 123 (Diskussion) 02:04, 14. Apr. 2017 (CEST)
Hier ein Versuch einer Antwort: veröffentlicht in (P1433) sollte ganz klar auf "Werk" gemappt werden. ("published in" ... "larger work that a given work was published in" entspricht genau dem Sinn von "In:" oder "in:" in bibligraphischen Angaben und dem Eintrag "Werk" in der Vorlage. Und anders als im Fall "publisher - Verlag" habe ich keinen extrem falschen Eintrag in wikidata gefunden.)
Für nachgewiesen in (P248) gibt es keinen Wert, der wirklich passt. (Es gibt keinen Eintrag für das Modul/Zitation der eine Fundstelle für bibliographische Angaben unterstützt.) Man muss also zu einer Notlösung greifen. Aufgrund der Beschreibung der Eigenschaft ist ein "In:" eigentlich aber jedenfalls falsch. (Da eben direkt eine Fundstelle angeben wird und nicht ein größeres Werk, in dem sich diese befindet.) Das nächste Problem ist, dass "stated in" faktisch für (mindestens vier) ganz verschiedene Fälle verwendet wird: Aufgrund von timeouts von https://query.wikidata.org/ kann ich leider die Häufigkeit nicht genau bestimmen. Aber mein Eindruck ist der, dass die faktische Verwendung folgende Notlösung zulässt:
Wenn weder ein Eintrag "Titel" noch eine URL (direkt oder archiviert) existieren, dann nehme P248 (d.h. im Idealfall das Label, aber wenn das fehlt halt die Item-Nummer) als Titel. Wenn es weder eine reference URL noch eine archivierte URL gibt und P248 nicht als Titel verwendet wurde, verwende P248 als URL. (Diese beiden Fälle entsprechen der Beschreibung der Eigenschaft.) Falls es Titel oder URL gibt und P1433 fehlt, verwende P248 als Werk. (Das entspricht nicht der Beschreibung. Da aber sehr häufig P248 zur Angabe von Datenbanken verwendet wird, kann man davon ausgehen, dass häufig genug das "In:" sinnvoll erscheint.) In allen anderen Fällen verwende P248 gar nicht. (Da P1433 faktisch eher selten verwendet wird, wird das nicht allzu häufig der Fall sein.) Wenn immer P248 verwendet wird und als Link angegeben ist, setze auch ein Link.
Für die Beispielfälle 10 u. 12 würde damit (falls das Modul so funktioniert, wie ich mir das einbilde) das unnötige "In:" verschwinden und ein Link im Titel gesetzt. Für Beispielfall 14 ebenfalls. Allerdings gibt es hier noch das Problem, dass Informationen aus der ersten Referenz (13) für diese zweite Quelle übernommen werden, die nicht passen. (Die zweite Quelle ist neuer als der 27. Februar 2014 und auf sie wurde später zugegriffen.) Es scheint so, als würde das Modul Angaben aus verschiedenen Referenzen mischen.
Auch 15-17 leiden unter dem Problem der Vermischung von Quellen:
Die Angabe "In: europa.eu" passt in 16 irgendwie, wird dann aber auch in 17 verwendet, wo sie nichts zu suchen hat. Ich habe den "stated in" Eintrag in 16 kurzzeitig entfernt, aber das hat die katastrophale Konsequenz, dass dann "Artikel 18 des Vertrags über die Europäische Union" in allen drei Quellenangaben als Werk angegeben wird. Es scheint also, dass das Modul (u.a.?) "stated in" benutzt, um die Quellenangaben zu unterscheiden.
Mit der vorgeschlagenen Zuordnung sollte das "In:" in 15 verschwinden, aber kein Link gesetzt werden.
Sorry, dass ich schon wieder ein neues Problem aufbringe ... 123 (Diskussion) 02:57, 18. Apr. 2017 (CEST)

Einzelnachweise zum Test

  1. ↑ a b António Guterres appointed next UN Secretary-General by acclamation. Vereinte Nationen, 13. Oktober 2016 (englisch, abgerufen am 13. Oktober 2016).
  2. ↑ www.who.int. Weltgesundheitsorganisation (abgerufen am 30. Juli 2016).
  3. ↑ Ständige Wohnbevölkerung nach Staatsangehörigkeitskategorie Geschlecht und Gemeinde; Provisorische Jahresergebnisse; 2018. Bundesamt für Statistik, 9. April 2019 (abgerufen am 11. April 2019).
  4. ↑ Paul Sahner: Merci, Udo!. Verlag Herder, 2015, Biographisch Notizen.
  5. ↑ Giovanni di Lorenzo: Das Glück ist ein flüchtiger Vogel. Blick, 28. Dezember 2014, S. m20.
  6. ↑ Jan Knopf (Hrsg.): Brecht-Handbuch. J.B. Metzler, S. 130.
  7. ↑ Thomas Ostermeier. Munzinger-Archiv.
  8. ↑ Francisco Díez de Velasco Abellán (Hrsg.): Las iglesias ortodoxas en España. Akal, Tres Cantos 2015.
  9. ↑ In: Population in municipalities – 1 January 2023.
  10. ↑ janus.lib.cam.ac.uk.
  11. ↑ In: John Venn (Hrsg.): Alumni Cantabrigienses. Cambridge University Press, 2011, S. 35.
  12. ↑ Denkmalliste für den Bereich des Altkreises Bad Doberan. Landkreis Rostock, 27. Februar 2014 (abgerufen am 16. Oktober 2016).
  13. ↑ In: Denkmalliste des Landkreises Rostock A - Z, 21.06.2016.
  14. ↑ In: Artikel 18 des Vertrags über die Europäische Union.
  15. ↑ High Representative/Vice President. In: europa.eu. Europäischer Auswärtiger Dienst, 14. Juni 2016 (englisch, abgerufen am 9. Dezember 2016).
  16. ↑ Eckart Stratenschulte: Hohe Vertreterin für Außen- und Sicherheitspolitik. Bundeszentrale für politische Bildung, 1. November 2014 (abgerufen am 9. Dezember 2016).

Lua-Fehler bei fehlendem Label ohne Rückfallebene

Letzter Kommentar: vor 7 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt

Unter BD:Jobu0101 wurde ein Lua-Fehler deutlich, wenn sowohl das deLabel als auch die Rückfallebene (enLabel) nicht angegeben sind. Ist es wirklich notwendig, das als Lua-Fehler auszugeben oder reicht auch ein Leerstring? –Queryzo ?! 14:37, 13. Apr. 2017 (CEST)

@Queryzo: Kannst Du mal ein Beispiel direkt mit dem Modul erstellen? Das würde es einfacher machen, den Fehler zu beheben. Ein Lua-Fehler ist jedenfalls unschön, Leerstring wäre zielführender. Grüße, Yellowcard (D.) 18:24, 14. Apr. 2017 (CEST)
Yasamak Güzel Sey müsste einen Fehler erzeugen. –Queryzo ?! 22:17, 14. Apr. 2017 (CEST)
Yasamak Güzel Sey (Yaşamak Güzel Şey, Regie: Müfit Can Saçıntı, TUR 2017) –Queryzo ?! 22:19, 14. Apr. 2017 (CEST)
Dein Beispiel erzeugt bei mir keinen Fehler. Bei Dir? Yellowcard (D.) 00:39, 15. Apr. 2017 (CEST)
Der Fehler scheint doch in der Vorlage zu liegen, siehe [2]. Wenn man ein Label einträgt, verschwindet er, daher dachte ich, der Fehler liegt im Wikidata-Modul selbst. –Queryzo ?! 11:57, 15. Apr. 2017 (CEST)

Function claim: Filtern nach beliebig vielen Qualifier-Value-Paaren

Letzter Kommentar: vor 6 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt

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: (erwarteter Wert: 7.5)
Durchschnittliche Tiefe des Müggelsees: (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 ?! 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)

Undokumentierte Änderungen im Modul führen zu Scriptfehlern – bitte sofort beheben.

Letzter Kommentar: vor 6 Jahren12 Kommentare7 Personen sind an der Diskussion beteiligt

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 ?! 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 ?! 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 ?! 11:01, 29. Aug. 2017 (CEST)

Editier-Maßstäbe

Letzter Kommentar: vor 6 Jahren7 Kommentare6 Personen sind an der Diskussion beteiligt

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)

Aufteilung des Moduls

Letzter Kommentar: vor 6 Jahren8 Kommentare2 Personen sind an der Diskussion beteiligt

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)

Wert eines Qualifiers für ein bestimmtes Statement auslesen

Letzter Kommentar: vor 6 Jahren11 Kommentare2 Personen sind an der Diskussion beteiligt

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. ein lächelnder Smiley  –Queryzo ?! 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 ?! 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)

@Jmkeil: An anderer Stelle bin ich nun wieder darauf gestoßen; deine Funktion hätte einen erheblichen Nutzen für verschiedenste Fragestellungen! Siehst du einen Weg, deine Funktion wieder zu implementieren? Die Unklarheiten bzgl. der Rückgabewerte sollten ja mittlerweile ausgeräumt sein. –Queryzo ?! 13:24, 9. Dez. 2017 (CET)

@Tkarcher: Ich die Funktion testweise wieder eingestellt. Es darf nun getestet werden. Hier geht’s zur Anleitung. –Queryzo ?! 09:35, 13. Dez. 2017 (CET)
@Queryzo: Super, danke! Ich war leider ein paar Wochen ungeplant weg aus der Wikipedia, werde mir das in den kommenden Tagen aber gerne mal anschauen! LG, Tkarcher (Diskussion) 17:25, 5. Jan. 2018 (CET)
@Queryzo: Ok, ich hab's getestet, aber entweder verstehe ich die Syntax noch nicht, oder es funktioniert nicht wie geplant: Kannst du mir sagen, warum meine Query mit neuer Syntax auf der Spielwiese nicht funktioniert? --Tkarcher (Diskussion) 12:55, 6. Jan. 2018 (CET)
Damit scheint es nicht zu funktionieren, ich bin mir aber nicht sicher, ob das in Wikidata so clever modelliert ist. Einrichtung = Bett mit Qualifier Anzahl ist nicht wirklich sinnvoll, eher Anzahl der Schlafmöglichkeiten (müsste ggf. angelegt werden) = 127 mit Qualifier = Bett, dann würde es gehen. –Queryzo ?! 08:41, 7. Jan. 2018 (CET)
Das Datenmodell entstand aus einer längeren Diskussion im Wikidata-Forum und wird mittlerweile bei über 900 Hütten so verwendet. Und in der englischen WP funktioniert der Abruf auch problemlos mit {{#invoke:WikidataIB |getQualifierValue |P912 |qid=Q901903| pval=Q1628935 |qual=P1114 |fetchwikidata=ALL }}. Vielleicht könnte der Code von dort sinngemäß hierher übernommen werden? --Tkarcher (Diskussion) 09:11, 7. Jan. 2018 (CET)

Fehler im Modul

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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

Werte von Properties des Types Mathematical expression als Math ausgeben

Letzter Kommentar: vor 6 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Lua/Modul/Wikidata/Archiv/2017&oldid=210793565“