Wikipedia Diskussion:Lua/Modul/Wikidata

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 730 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

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

ODER-Verknüpfung für Qualifikatoren

Ich brauche eure Zustimmung für ein Feature, von dem die Infobox Software profitieren würde. Die Infobox bezieht die aktuelle Versionsnummer einer Software aus Wikidata mithilfe {{#invoke:Wikidata|claim|P348}}. Dabei werden leider auch Beta-Versionen zurückgegeben. Dies könnte man verhindern, indem man eine Qualifikatorbedingung ergänzt: {{#invoke:Wikidata|claim|P348|P548|Q2804309}}. Allerdings sind viele stabile Versionen nicht mit dem Qualifikator P548=Q2804309 versehen. Ich wünsche mir daher, {{#invoke:Wikidata|claim|P348|P548|Q2804309 or NO_QUALIFIER}} schreiben zu können.

Um das Feature zu implementieren, müssen lediglich vier Zeilen Code ergänzt werden:

Patch für das vorgeschlagene Feature

---

-local function qualifierhasvalue(claim, property, value)
-   -- TODO: not yet documented!
-   if not claim.qualifiers then return false end
-   if not claim.qualifiers[property] then return false end
+local function qualifierhasvalue(claim, property, values)
+   if not claim.qualifiers then return values["NO_QUALIFIER"] end
+   if not claim.qualifiers[property] then return values["NO_QUALIFIER"] end
    for key, snak in pairs(claim.qualifiers[property]) do
        if snak.snaktype == "value" then
            if snak.datavalue.type == "wikibase-entityid" then
-               if snak.datavalue.value.id == value then
+               if values[snak.datavalue.value.id] then
                    return true
                end
            --TODO: elseif other types
			end
		end
	end
	return false
 end

@@ -594,14 +593,16 @@ function filterClaims(frame, claims)    
    -- use additional unnamed parameters as qualifier conditions (in pairs)
-   -- not yet documented!
-   -- TODO: not sure if this is good approach. Maybe use named parameter that has pairs split by semicolon
    for key, val in pairs(frame.args) do
        if type(key) == "number" and key > 2 and key % 2 == 1 then
            -- key = 3, 5, 7 and so on
            local newclaims = {}
+           local values = {} -- set of allowed values for the qualifier
+           for _, v in pairs(mw.text.split(frame.args[key], '%sor%s')) do
+               values[mw.text.trim(v)] = true
+           end
            for i, claim in pairs(claims) do
-               if qualifierhasvalue(claim, frame.args[key - 1], frame.args[key]) then
+               if qualifierhasvalue(claim, frame.args[key - 1], values) then
                    table.insert(newclaims, claim)
                end
            end

Gruß —Dexxor (Diskussion) 17:18, 26. Mär. 2022 (CET)

Hallo Dexxor, der Patch scheint mir technisch sinnvoll zu sein, bleibt die Frage nach dieser Erweiterung an sich. Ist das wirklich ein Szenario, das allgemein von Interesse wäre? (Ich halte das für sehr speziell: Du möchtest einen konkreten Qualifikator (Entwicklungsstadium (Software) (P548)) mit einem konkreten Wert (stabile Version (Q2804309)) verlangen, aber auch Werte durchlassen, die gar keinen Qualifikator aufweisen. Ist das wirklich ein Anwendungsszenario über den konkreten Anwedungsfall hinausgehend?) Wenn nein, wäre es vielleicht ein besserer Ansatz, das in einem Modul:Vorlage:Infobox Software zu implementieren, analog wie das beispielsweise in Modul:Vorlage:Infobox Fußballspieler realisieret wurde, oder?

Mehrere zugelassene Werte über eine or-Verknüpfung zuzulassen, klingt allerdings sinnvoll und allgemein anwendbar.

Wir sollten das nur alles mal vernünftig dokumentieren, damit mehr Leute dieses Modul produktiv nutzen können. Viele Grüße --Yellowcard (D.) 21:53, 27. Mär. 2022 (CEST)

@Yellowcard: Das Szenario ist vermutlich recht speziell. Mir ist aber ein Weg eingefallen, meinen Anwendungsfall ohne NO_QUAILFIER zu lösen. Dafür müsste es nur möglich sein, nach Qualifikatoren zu filtern, die einen bestimmten Wert nicht enthalten. Ich möchte schreiben können: {{#invoke:Wikidata|claim|P348|P548|!Q3295609|P548|!Q51930650}}. Das ließe sich mit nur wenigen Änderungen realisieren: (Das Ungleichzeichen in negated ~= qualifierhasvalue() kannst du dir als XOR vorstellen: Der rechte Teil wird nur invertiert, wenn negated==true)

    for key, val in pairs(frame.args) do
        if type(key) == "number" and key > 2 and key % 2 == 1 then
            -- key = 3, 5, 7 and so on
            local newclaims = {}
+           local value = frame.args[key]
+           local negated = string.sub(value, 1, 1) == "!"
+           if negated then value = string.sub(value, 2) end
            for i, claim in pairs(claims) do
-               if qualifierhasvalue(claim, frame.args[key - 1], frame.args[key]) then
+               if negated ~= qualifierhasvalue(claim, frame.args[key - 1], value) then
                    table.insert(newclaims, claim)
                end
            end

Wir sollten außerdem dokumentieren, dass die unbenannten Parameter keine Leerzeichen enthalten dürfen. Alternativ können wir mw.text.trim() benutzen, damit Weißraum hinten und vorne ignoriert wird. —Dexxor (Diskussion) 10:22, 28. Mär. 2022 (CEST)

@Dexxor: Gefällt mir gut. Das Trimmen der unbenannten Parameter ist ebenfalls ein sinnvoller Vorschlag; ich wüsste gerade gar nicht, ob das nicht durch MediaWiki ohnehin passiert, wenn der Aufruf über #invoke geschieht, aber ein zusätzliches Trimmen im Modul hat keine Nachteile, die mir einfallen würden.

Auf die Funktionalität des Schlüsselworts "or" würdest Du dann verzichten zugunsten der doppelten Angabe der Eigenschaft (also in deinem konkreten Beispiel zweimal P548, jeweils mit unterschiedlichem Wert)? Fände ich auch sinnvoll, dann bräuchten wir die "or"-Konstruktion gar nicht mehr, richtig? Grüße --Yellowcard (D.) 11:28, 28. Mär. 2022 (CEST)

@Yellowcard: Mit #invoke ist es wie bei Vorlagen: Benannte Argumente werden getrimmt, unbenannte nicht. Auf das Schlüsselwort "or" kann ich verzichten. Durch das Angeben von zwei P548-Bedingungen werden diese übrigens mit UND verknüpft. --Dexxor (Diskussion) 11:41, 28. Mär. 2022 (CEST)

@Dexxor: Stimmt (zu beidem). Von dem her wäre es doch interessant, Deinen am 26.03. vorgeschlagenen Patch hinsichtlich des or-Schlüsselwortes ebenfalls mit aufzunehmen, dann hätten wir da eine recht große Bandbreite an Anwendungsszenarien abgedeckt, oder? (Also or-Verknüpfung und und-Verknüpfung mit beliebig vielen Werten zu einer Eigenschaft, dabei jeder Wert beliebig ein- und ausschließbar.) --Yellowcard (D.) 12:21, 28. Mär. 2022 (CEST)

@Yellowcard Ich habe beide Funktionen dem Testmodul hinzugefügt und das Interface etwas geändert, da es nicht sinnvoll ist, wenn man ODER und Ausrufezeichen beliebig verknüpfen kann; zum Beispiel akzeptiert !Q12 bereits jeden Wert außer Q12, der rechte Teil in !Q12 or Q23 wäre also unnötig. Es gibt jetzt zwei Arten, eine Liste von erlaubten Qualifikatoren anzugeben:

Q12,Q23,Q45

Wert des Qualifikators ist entweder Q12, Q23 oder Q45.

!Q12,Q23,Q45

Wert des Qualifikators ist weder Q12, Q23 noch Q45. --Dexxor (Diskussion) 08:27, 29. Mär. 2022 (CEST)

Hallo Dexxor, das finde ich super, vielen Dank. Hinsichtlich der und-Verknüpfung bleibt es dann bei {{#invoke:Wikidata|claim|P348|P548|!Q3295609|P548|!Q51930650}}, also der doppelten Angabe der Eigenschaft, korrekt? Viele Grüße, Yellowcard (D.) 09:17, 29. Mär. 2022 (CEST)

@Yellowcard In dem Beispiel werden die Aussagen zuerst nach P548≠Q3295609 gefiltert. Die gefilterte Liste wird dann nach P548≠Q51930650 gefiltert, was einer UND-Verknüpfung beider Bedingungen entspricht. Das Beispiel ließe sich jetzt aber auch kürzer schreiben mit P548|!Q3295609,Q51930650. --Dexxor (Diskussion) 12:45, 29. Mär. 2022 (CEST)

@Dexxor: Spricht etwas dagegen, den von Dir vorgeschlagenen Patch ins Produktivmodul zu übernehmen? Gruß --Yellowcard (D.) 09:09, 7. Apr. 2022 (CEST)

@Yellowcard Von mir spricht nichts dagegen. Ich werde die Änderung am Produktivmodul um 16 Uhr vornehmen. --Dexxor (Diskussion) 10:42, 7. Apr. 2022 (CEST)

Ich habe hier mal die "nicht archvieren"-Vorlage reingesetzt, bis wir diese doch sehr gute Funktionalität zumindest einigermaßen dokumentiert haben. Ich hoffe, ich komme zeitnah dazu. Yellowcard (D.) 13:46, 5. Mai 2022 (CEST)

@Yellowcard Reicht das, was ich mit dieser Bearbeitung hinzugefügt habe, nicht aus als Dokumentation? --Dexxor (Diskussion) 07:36, 6. Mai 2022 (CEST)

@Dexxor, das hatte ich völlig übersehen. Das sollte - im Rahmen der ohnehin nicht ganz idealen Doku umseitig - erstmal reichen. Danke Dir, das ist wirklich eine praktische Erweiterung des Moduls. Viele Grüße, Yellowcard (D.) 08:00, 6. Mai 2022 (CEST)

Probleme mit Speicher / Performance

Siehe Wikipedia_Diskussion:WikiProjekt_Wikidata_in_Wikipedia#Regionalcode_für_Koordinaten. Kann es sein, dass die Verwendung von {{#property:…}} immer deutlich performanter als {{#invoke:Wikidata|claim}} ist? --Sinuhe20 (Diskussion) 08:35, 24. Mai 2022 (CEST)

Edit-Request

Mit dem derzeitigen Wikidata-Modul kann man keine Listenseparatoren vor den Fußnoten angeben (z.B. Komma oder Semikolon); dadurch kann die typografische Einheitlichkeit nicht bewahrt werden. Natürlich habe ich vergeblich versucht, dies ohne Änderungen am Modul zu bewerkstelligen; dies ist mir aber nicht gelungen. Daher schlage ich vor, folgendes Testmodul zu übernehmen: Modul:Wikidata/Test (Demonstration: Benutzer:CyberOne25/Test)

Ich wäre sehr dankbar. --CyberOne25 (Diskussion) 13:10, 27. Apr. 2023 (CEST)

Unnötig, da dies auch anders geht: Spezial:Diff/233207463. Im übrigen bist du in der Verantwortungm, deine Ergänzungen ausgiebig zu testen. --darkking3 ^Թ 15:51, 27. Apr. 2023 (CEST)

Ja, so war es ja vorher. Das sieht aber beschissen aus, da normalerweise die Fußnoten nach den Satzzeichen stehen (außer beim Bindestrich).

Ja, ich hab glaub ich Zwangsstörungen. --CyberOne25 (Diskussion) 16:28, 27. Apr. 2023 (CEST)

Hier nochmal, da anscheinend manche meinen ersten Kommentar nicht lesen können:

Mit dem derzeitigen Wikidata-Modul kann man keine Listenseparatoren vor den Fußnoten angeben (z.B. Komma oder Semikolon); dadurch kann die typografische Einheitlichkeit nicht bewahrt werden. Natürlich habe ich vergeblich versucht, dies ohne Änderungen am Modul zu bewerkstelligen; dies ist mir aber nicht gelungen. Daher schlage ich vor, folgendes Testmodul zu übernehmen: Modul:Wikidata/Test (Demonstration: Benutzer:CyberOne25/Test) --CyberOne25 (Diskussion) 14:16, 5. Jun. 2023 (CEST)

Ok hat sich erledigt; diese Funktion brauchen wir doch nicht. --CyberOne25 (Diskussion) 23:27, 5. Jun. 2023 (CEST)

Sitelink zu bestimmten Projekt

Hallo zusammen, kann ich mir mit diesem Module den Sitelink zu einem bestimmten Projekt holen (z. B. dewikisource)? Wenn ja, wie genau? Ausprobiert hatte ich {{#invoke:Wikidata|sitelinkOf|Q92545}}. Das liefert aber nur den Sitelink zu dewiki. Im Gegensatz dazu liefert {{#invoke:Wikidata|sitelinkCount|dewikisource|Q92545}} nur eine Zahl. --Arnd 🇺🇦 (Diskussion) 17:52, 24. Okt. 2023 (CEST)

Mein Vorschlag wäre eine Variante von sitelinkOf:

function p.certainSitelinkOf(frame)
	local filter = frame.args[1]
	local id = frame.args[2]

	local entity = mw.wikibase.getEntity(id)
	if entity and entity.sitelinks then
		for project, sitelink in pairs(entity.sitelinks) do
			if project == filter then
				return sitelink.title
			end
		end
	end
	return ""
end

Testen kann man das leicht, z. B. so {{#invoke:Wikidata|certainSitelinkOf|dewikisource|Q798194}}. Da es sich um eine additive Änderung handelt, besteht keine Gefahr, dass vorhandene Funktionen beeinflusst werden. Könntet das mal jemand einbauen? Gruß, --Arnd 🇺🇦 (Diskussion) 10:42, 17. Mär. 2024 (CET)

Explizit deutschsprachige Beschreibung abfragen (leer oder nichtleer?)

Siehe auch Vorlage Diskussion:Wikidata-Registrierung:

Wie kann man feststellen, ob eine deutschsprachige Beschreibung vorhanden ist oder nicht?

Die aktuelle Version

function p.descriptionIn(frame) [...] -- return description of a Wikidata entity in the given language or the default language of this Wikipedia site.''

dürfte auf die englischsprachige Beschreibung als Fallback zurückgegreifen, falls keine deutschsprachige Beschreibung defniert ist. --M2k~dewiki (Diskussion) 17:12, 21. Feb. 2024 (CET)