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.

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.

Hallo zusammen, wie bekommt man aus einer Vorlage Zugriff auf die verbundene QID? Es gibt ja mw.wikibase.getEntityIdForCurrentPage(), aber wie ruft man das im Template auf? --Arnd 🇺🇦 (Diskussion) 23:18, 19. Okt. 2024 (CEST)Beantworten

Wikipedia:Lua/Modul/Wikidata#pageId. Gruß, -- hgzh 12:54, 28. Aug. 2025 (CEST)Beantworten

Hallo zusammen, mit #invoke:Wikidata|claim|P921|QID kann man sich die Werte eines Claims einer QID liefern lassen. Allerdings liefert das das Label und nicht die QID. Gibt es eine Möglichkeit den Wert als QID liefern zu lassen? Gruß, --Arnd 🇺🇦 (Diskussion) 23:39, 19. Okt. 2024 (CEST)Beantworten

parameter=numeric-id kann gesetzt werden. Gruß, -- hgzh 12:55, 28. Aug. 2025 (CEST)Beantworten

Beispiel:

• 1 (hat aber 2)
• Gewalt (sollte Gewalt, Schimpfwörter ergeben)

--Matthias 15:11, 25. Okt. 2024 (CEST)Beantworten

Hallo zusammen, ich habe die letzten Monate einige Wartungsarbeit in das Modul gesteckt, insbesondere dabei den Code aufgeräumt, dokumentiert, teils vereinfacht, aktualisiert, einige Funktionen weniger anfällig für Fehler gemacht sowie Testfälle ergänzt. Das Ganze ist noch nicht abgeschlossen, vor allem rund um die wohl zentralste claim-Funktion fehlt noch einiges. In einem weiteren Schritt plane ich dann auch, das Modul um weitere Funktionen zu erweitern. Ich möchte die ganzen Überarbeitungen aber nicht einfach unkommentiert lassen, deshalb skizziere ich hier kurz, was ich vorhabe:

• Trennung von Vorlagen- und Modulfunktionen inkl. sauberer Definition, welche Funktion welche Rückgabewerte hat (string, nil/boolean), damit das Modul einfacher in anderen Modulen weitergenutzt werden kann.
• Umstellung aller Vorlagenfunktionen auf benannte Parameter, um Funktionserweiterungen einfacher einführen zu können.
• Einführung einer zentralen Fehlerbehandlung, um Fehlerausgaben für alle Funktionen konfigurieren und im Bedarfsfall auch unterdrücken zu können. In diesem Zusammenhang Ablösung der speziellen Fehlerbehandlung für die claim-Funktion.
• Ablösung der labelOf-Funktion, die im Wesentlichen redundant zur labelIn-Funktion ist.

Wenn diese Umstellungen erfolgt sind, plane ich folgende Funktionserweiterungen:

• pageId: Abfrage von ID auf Basis von Seitentiteln, auch anderssprachiger Projekte
• labelIn/descriptionIn: Abfrage von Label/Description auf Basis von Seitentiteln, auch anderssprachiger Projekte
• claim: countValues/list auf Qualifikatorenebene (s. #claim/getValue ignoriert Mehrfacheinträge)
• claim: list mit Übergabe der Werte an eine Vorlage als Vorlagenparameter

Gruß, -- hgzh 18:33, 8. Nov. 2025 (CET)Beantworten

Hi,

• {{#invoke:Wikidata|claim|P6|id=Q486450}} liefert Stefan Szirucsek
• {{#invoke:Wikidata|claim|P6|id=Q486450|atdate}} liefert Stefan Szirucsek
• {{#invoke:Wikidata|claim|P6|id=Q486450|atdate=2023}} liefert Stefan Szirucsek
• {{#invoke:Wikidata|claim|P6|id=Q486450|atdate=2026}} liefert Carmen Jeitler-Cincelli

Die ersten beiden Ergebnisse Stefan Szirucsek sind mE falsch. Sortiere ich die ersten beiden Einträge in P6 um, dann liefern auch die beiden ersten Aufrufe die Frau Carmen Jeitler-Cincelli - wie es sein soll. (Stefan Szirucsek war bis 2025 BM, ab 2025 dann Carmen Jeitler-Cincelli) Das ist nur ein Bsp., es geht um d:Q486450#P6.

Die Reihenfolge der Mehrfacheinträge in einer Property ist zufällig und nur über zusätzliche Gadgets beeinflussbar, sie sollte daher keine Auswirkung auf das Ergebnis haben. {{#invoke:Wikidata|claim|P6|id=Q486450}} sollte immer das idente Ergebnis wie {{#invoke:Wikidata|claim|P6|id=Q486450|atdate=now}} (now als metanotation) liefern. In der Spec heißt es: Bei keiner Datumsangabe wird das heutige Datum verwendet. Stimmt ihr mir zu und kann man das bitte fixen? lg --Herzi Pinki (Diskussion) 00:55, 10. Jun. 2026 (CEST)Beantworten

@Hgzh: zur Sicherheit. --Herzi Pinki (Diskussion) 00:58, 10. Jun. 2026 (CEST)Beantworten

Ich finde das Verhalten wie vorgefunden korrekt. Ohne Angabe des atdate-Parameters wird nicht nach Zeitpunkt eingeschränkt, sondern nach Rang und dann nach Reihenfolge. Das halte ich für sinnvoll so.

Dein zweiter Anstrich funktioniert nur nicht, weil du das Gleichheitszeichen hinter dem Parameternamen vergessen hast und atdate somit als Wert des zweiten numerischen Parameters interpretiert wird. {{#invoke:Wikidata|claim|P6|id=Q486450|atdate=}} liefert korrekt Carmen Jeitler-Cincelli. Gruß, -- hgzh 07:44, 10. Jun. 2026 (CEST)Beantworten

@Hgzh: sorry für das vergessene =. Primär geht es mir eh um den allerersten Aufruf ohne atdate. Mir fällt es schwer, das Verhalten einfach für ein Feature zu halten. Der Beschreibungssatz Bei keiner Datumsangabe wird das heutige Datum verwendet. kann auch anders gelesen werden, von Reihenfolge lese ich nichts auf der Doku. Die Reihenfolge ist zufällig und schwer beeinflussbar, was dazu führt, dass preferredRank gesetzt, gefordert und in der Auswertung vorausgesetzt wird. Mir würde folgende Auswertelogik plausibler erscheinen:

• es werden die Treffer mit dem höchsten Rang zurückgeliefert
• gibt es mehrere gleichrangige Treffer, werden die dem aktuellen Datum / die dem in atdate übergebenen Datum entsprechenden zurückgeliefert. Dabei ist es egal, ob das explizit mit leerem atdate- oder ohne atdate-Parameter erfolgt.
• gibt es bei Angabe von atdate keinen Treffer im preferredRank, wohl aber im normalen Rang, wäre das noch zu definieren, mir erschiene jedoch die Bevorzugung von atdate gegenüber preferred an dieser Stelle für nachvollziehbar.
• gibt es dann immer noch mehrere Treffer, wird einer willkürlich ausgewählt (kein Bezug auf die volatile Reihenfolge) Das kann auch zutreffen, wenn zu einem Zeitpunkt mehrere gültige Einträge existieren. Alternative wäre, diesen Fall auf Fehler laufen zu lassen, würde aber an vielen Stellen den Kontrakt zum Caller brechen.

Hintergrund: Was ich vermeiden will, ist dass trotz einer durchgängigen Historisierung (z.B. bei EW-Zahlen, BM-Menschen, etc.) mittels P580/P582 es dennoch aus der Auswertelogik heraus notwendig ist, einen der Werte als preferred zu markieren (das konkrete Vorgehen auf WD diesbezüglich ist ungeklärt). Auf den ersten Blick ist das nicht die große Sache, aber es gehört gewartet. Jedesmal, wenn ein neuer Wert eingetragen und als preferred ausgezeichnet wird, muss beim alten Wert der Rang wieder zurückgesetzt werden. Es sind also 3 Einzelaktionen für das Eintragen eines neuen Werts notwendig, eine davon nichtlokal. Es ist mir schon schwer beizubringen, ... PS.: ich kann hierzuwiki ganz gut mit atdate= leben. lg --Herzi Pinki (Diskussion) 12:59, 10. Jun. 2026 (CEST)Beantworten

Na ja, als zufällig würde ich die Ausgabereihenfolge nicht ansehen. Es ist bei jeder Abfrage die gleiche. Vielmehr ist es eine Limitierung der standardmäßigen Wikidata-Oberfläche, dass die Reiehnfolge nicht einfach geändert werden kann.

Jedenfalls würde ich ungern weitere Abhängigkeiten in der Claim-Funktion einführen; jeder Aufruf müsste immer auf Zeiträume abfragen, auch wenn überhaupt keine angegeben sind. Wenn man das weiterdenkt, dann müsste man eigentlich auch primär nach Ordnungszahlen sortieren und vielleicht noch nach mehr. Diese Vorsortiererei ist ineffizient.

Zusätzlich atdate anzugeben, ist doch eigentlich kein Problem. Gruß, -- hgzh 19:39, 10. Jun. 2026 (CEST)Beantworten

Wie gesagt, ich kann damit leben. Hab mir denn auch gedacht, dass das Performanceimplikationen haben könnte. An die Ordnungszahlen habe ich dann auch noch gedacht. Die Docu könnte noch einen Satz verlieren, aus Sicht des Aufrufers ist die Reihenfolge zufällig (nicht aus Sicht der Implementierung, aber muss die sich da binden?), und für mich zumindest ist eine Liste von Werten unsortiert. Drum gibt es ja die Ordnungszahlen. Dass ich mit d:Q486450#P6 gleich so ein Glück habe, war ja eher ein Zufall. Ich habe nach BM gesucht, die nicht über preferred, sondern nur über das Datum sortiert sind. lg --Herzi Pinki (Diskussion) 15:20, 11. Jun. 2026 (CEST)Beantworten