Zum Inhalt springen

Gespräch:Erstellung MediaWIki:Gadget-Descriptions für Wikibase Vorschau

aus AufEinWort, der freien Forschung

Über diese Seite Gespräch

Vorschauproblem in Wikibase
Ausarbeitung
ChatGPT Sophos GPT-5 Thinking
2. Dezember 2025 n. Chr. erst.  
18:33 Uhr Ausgabe 02
Ausgabe 02
unüberarbeitet ungeprüft

Hallo Sophos,

Ich bekomme beim hoover über Links in WIkibase folgende Meldung:  Es gibt ein Problem beim Anzeigen der Vorschau

Bei Links innerhalb von MediaWiki funktionieren die pop-ups der Vorschau.

Die Wikibase Namespaces sind als Content gesetzt:

$wgContentNamespaces = [ 120, 122, 146 ];

An sich ging das mal, jedoch Q's, P's und L's zeigen untereinander keine Vorschau, jedoch die SiteLinks der Q's.

Was könnte die Ursache sein?

ChatGPT:

Aktivität ·1m 30s

Denke nach…

Durchsuchen des Webs nach MediaWiki Popups Fehlern

Durchsuchen des Webs nach Popups und Wikibase-Problemen

Untersuchen von Popups-Abhängigkeiten und möglichen Problemen

Explaining Popups API limitations with Wikibase

Die Popups-Erweiterung ist für Wikitext optimiert und benötigt bei der Nutzung von Wikibase oder anderen Content-Handlern eine eigene API. Standardmäßig unterstützt Popups keine Wikibase-Entität-Seiten. Um zusammengefasste Daten für Q/P/L-Seiten zu erhalten, müsste eine benutzerdefinierte API eingerichtet oder auf ein anderes Popup-System zurückgegriffen werden.

Proposing a minimal solution for Q/P/L previews

Wenn Popups in den Q/P/L-Namensräumen Fehler zeigt, könnte es helfen, die Seitenvorschau für

Analyzing Popups-Kompatibilität mit Wikibase und Lösungen

Clarifying Popups issues with Wikibase

Es gibt anscheinend keine "Seitenzusammenfassung" für Wikibase-Elemente, was erklärt, warum Popups auf diesen Seiten nicht funktionieren. Die Popups-Erweiterung versucht, Textauszüge anzufordern, aber erhält keine Daten. Eine Lösung wäre, entweder Textauszüge bereitzustellen oder auf ein anderes Gadget, wie "NavigationPopups", zurückzugreifen.

Diagnose für Popups und Wikibase-Unterstützung

Popups funktioniert bei normalen MediaWiki-Seiten mit Wikitext-Extrakten, um eine Vorschau zu bieten. Bei Wikibase-Entitäten (Q/P/L) ist das Seitenmodell wikibase-(item|property|lexeme), aber Popups verwendet standardmäßig TextExtracts/PageImages, die mit diesem Modell nicht kompatibel sind, weshalb eine Fehl

Offering solutions for Popups limitations with Q/P/L

Es gibt zwei Optionen:

  1. Wenn man die Einschränkung akzeptiert, kann man die Popups für Q/P/L-Namespaces deaktivieren, indem man sie aus $wgContentNamespaces entfernt. Eine andere Möglichkeit wäre, die Vorschauen via CSS auszublenden.
  2. Man könnte eine eigene API bereitstellen, die die Zusammenfassung für Popups liefert und den wgPopupsGateway anpasst.

Nachgedacht für 1m 30s

Fertig

Quellen·71

(1. Dez. 2025, 18:08)

Hallo Nikolaos,

kurz und nüchtern: Das ist kein Defekt in Wikibase, sondern eine Grenze der „Page Previews“ (Extension:Popups).

Kurzdiagnose

  • Popups holt den Vorschautext standardmäßig über TextExtracts (und ein Bild über PageImages). Das funktioniert für Wikitext-Seiten. Für Wikibase-Entitäten (Q/P/L; Content-Model wikibase-*) gibt es keinen passende „Summary“-Endpunkt out-of-the-box. Ergebnis: „Es gibt ein Problem beim Anzeigen der Vorschau“. mediawiki.org
  • Die Erweiterung ist „für Wikipedia-ähnliche Inhalte (Wikitext) optimiert“. Für andere ContentHandler (z. B. Wikibase) muss eine eigene API bereitgestellt werden, die das Summary-Schema liefert; erst dann können Previews dort erscheinen. mediawiki.org
  • Popups zeigt Previews nur für Links in Content-Namespaces. Du hast 120/122/146 bereits als Content gesetzt – dadurch versucht Popups jetzt Previews für Q/P/L und scheitert mit der genannten Meldung. (Vorher wurden dort schlicht keine Popups versucht.) mediawiki.org
  • Die konkrete Meldung erscheint u. a., wenn TextExtracts keinen Einleitungstext findet – was bei Entitäten ohne Wikitext naturgemäß zutrifft. mediawiki.org

Zwei schnelle Gegenchecks (ohne Rateversuch)

  1. Abhängigkeiten geladen? Special:Version → „TextExtracts“, „PageImages“, „Popups“ müssen alle aktiv sein. (Nur zur Vollständigkeit.) mediawiki.org
  2. Beweis am API-Call:
    • api.php?action=query&prop=extracts&titles=Item:Q123 → für Entitäten kommt kein sinnvoller Extract zurück.
    • rest.php/page/summary/Item:Q123 → auf Drittwikis i. d. R. kein implementierter Summary-Endpunkt → 404/Fehler. (Popups’ Default-Gateway erwartet aber genau so einen Summary-Endpunkt.) mediawiki.org

Optionen (pragmatisch → nachhaltig)

A) Ruhe reinbringen:

Popups für Q/P/L unterdrücken, damit die Fehlblase verschwindet. Rein serverseitig gibt’s dafür keinen Schalter pro Namespace; am einfachsten via kleines Gadget/JS, das Popups auf Links zu Item:, Property:, Lexeme: nicht initialisiert. (Nebeneffektfrei; deine Content-Einstufung bleibt bestehen.) mediawiki.org

B) Richtig lösen:

Einen Mini-Summary-Endpunkt für Wikibase bereitstellen (z. B. Label + Beschreibung + optional 1–2 Kernaussagen) und Popups auf diesen Endpunkt zeigen lassen:

$wgPopupsGateway = 'restbasePlain';
$wgPopupsRestGatewayEndpoint = '/dein-endpunkt/summary/'; // muss das Summary-Schema 1.2.0 liefern

Die Spezifikation, die Popups erwartet, ist dokumentiert („Specs/Summary/1.2.0“). Sobald der Endpunkt existiert, funktionieren Previews auch für Q/P/L. mediawiki.org

C) Alternative Oberfläche:

Falls du in Q/P/L eher „Fakten-Tooltips“ willst, ist das Navigation popups-Gadget (Wiki-Gadget, nicht die Extension „Popups“) eine Option – unabhängig von TextExtracts. (Popups und Navigation-Popups schließen sich für denselben Benutzer gegenseitig aus.) mediawiki.org

Fazit (Fakt vs. Mutmaßung):

Fakt: Popups liefert ohne eigenen Summary-Endpunkt keine brauchbaren Previews für Wikibase-Entitäten. Mutmaßung (hoch): Dass es „früher ging“, ist entweder Erinnerung an das Navigation-Popups-Gadget oder daran, dass Q/P/L damals nicht als Content-Namespace markiert waren – dann wurden dort schlicht keine Popups versucht.

Wenn du magst, skizziere ich dir im nächsten Schritt Variante B minimal: Felder des Response (title, extract[], thumbnail, url, languageCode, pageId) und ein schlanker Handler, der wbgetentities/REST (/w/rest.php/wikibase/v0/...) anzapft und auf das Summary-Schema mappt.

Du:

Zur Kurzdiagnose:

1. es hatte bereits funktioniert (vielleicht habe ich es verwechselt),

2. es funktioniert auf Wikidata.

Ich habe dir gesagt, das es sich um einen Fehler handelt – er ist nach meinem Eindruck erst kürzlich aufgetreten.

In Wikidata gibt es Gadget „PopupsFix“ und "Navigation popups", beide sind nicht in Einstellungen aktiviert.

Ich selbst hatte in meinem MediaWiki für Wikibase nie ein derartiges Gadget und Vorschau funktioniert dennoch für mich in Wikidata.

In Wikidata "MediaWiki:Gadgets-definition" gibt es "popups[ResourceLoader|type=general]|popups.js|popups.css" aber das ist nur CSS.

In meinem MediaWiki funktionieren die popups und Vorschau, eine Überprüfung von Popups, TextExtracts, PageImages erübrigt sich daher. Wenn es grundlegend funktioniert brauchen wir keine grundlegenden Einstellungen wie $wgPopupsGateway vornehmen – oder?

In Wikidata hat das Popupfenster eine andere CSS als die Vorschau mittels Extension:popups, woraus ich schließe, das das Popup-Fenster auf andere Artweise bewirkt wird, zumal enthält es die Beschreibung des jeweiligen Q's, P's oder L's, welche nicht als einfacher Wikitext in der jeweiligen Seite ausgelesen werden kann.

Ich brauche die Vorschau (an sich Popup-Fenster der Beschreibung) bei hoover zu deren Unterscheidung, da vergleichsweise auch in Wikidata mehrere gleichlautende oder ähnliche Q's, P's und L's unterschiedlicher ID's gibt und in statements nur deren Benennung, jedoch nicht deren Beschreibung angezeigt wird.

Dafür gibt es offenbar ein neues Gadget, das MediaWiki:Gadget-Descriptions

MEdiaWiki: Gadgets-definition:

Descriptions[ResourceLoader|dependencies=mediawiki.api,wikibase.api.RepoApi|namespaces=0,120,146|actions=view]|Descriptions.js

Recherchiere bitte genauestens und gebe mir zutreffende Angaben!

ChatGPT:

Aktivität ·1m 49s

Denke nach…

Recherche zu Gadgets auf Wikidata

Ich muss sicherstellen, dass ich die genaue Funktionsweise der Gadgets auf Wikidata verstehe, insbesondere in Bezug auf Popups, Navigation-Popups und Beschreibungsgadgets. Da der Benutzer aktuelle Informationen möchte, werde ich eine Suche durchführen, um sicherzustellen, dass ich die neuesten und präzisesten Daten zu diesen Funktionen habe.

Searching gadgets and hover descriptions on Wikidata

Bestätigen der Popups-Optimierung

Gut! Die Quelle bestätigt meine frühere

Überprüfung von Phab T163205 und Popups

Überprüfung von Popups auf Wikidata

Es scheint, dass die Popups von Wikidata entfernt wurden (T163205) und auch das PopupsFix-Gadget entfernt wurde. Ich werde mir T163205 genauer ansehen, um sicherzustellen, dass ich alle relevanten Informationen dazu habe, warum und wie die Änderungen vorgenommen wurden.

Öffnen der T163205-Fehlerbehebung und Popups-Entfernung

Untersuchung des Descriptions-Gadgets auf Wikidata

Es wurde bestätigt, dass Popups (Seitenvorschauen) seit 2017 von Wikidata entfernt wurden und nun durch Gadgets wie "Descriptions" bereitgestellt werden. Der Benutzer hat funktionierende Vorschauen gesehen, ohne Gadgets in den Einstellungen zu aktivieren. Einige Gadgets könnten standardmäßig für alle aktiviert sein. Ich werde nach dem "Descriptions"-Gadget suchen.

Searching for Wikidata gadget Descriptions definitions

Erneute Suche nach Gadget-Descriptions.js

Ich konnte den Inhalt von MediaWiki:Gadget-Descriptions.js bisher nicht finden. Es scheint, dass eine erneute Suche notwendig ist, um die genauen Details zu diesem Gadget zu finden. Ich werde meine Recherche fortsetzen und sicherstellen, dass ich alles Relevante aufspüre.

Durchsuchen des Webs nach Gadget-Beschreibungen

Überprüfung der Standardaktivierung von Descriptions-Gadget

Die Popups-Erweiterung ist auf Wikidata

Suche nach der Gadget-Definition auf Wikidata

Es scheint, dass wir laut den Tool-Beschränkungen auf eine vorherige Referenz zugreifen müssen. Da wir die direkte Verbindung nicht finden konnten, werde ich nun nach der Seite "MediaWiki:Gadgets-definition" auf Wikidata suchen, um weitere Details zu erhalten. Ich hoffe, das bringt uns weiter.

Suche nach MediaWiki-Gadgets auf Wikidata

Untersuchung der Funktionsweise des Descriptions-Gadgets

Obwohl wir nicht direkt auf die "Descriptions.js"-Seite zugreifen konnten, gibt es mehrere Hinweise: Die Nutzungsberichte sagen, dass das Gadget "Descriptions" beim Hover die Beschreibung von Objekten und Eigenschaften anzeigt. Es könnte sein, dass das Gadget standardmäßig für alle Benutzer aktiviert ist. Ich werde prüfen, ob es als Standardaktualisierung für alle Nutzer eingetragen ist.

Überprüfung von "Descriptions"-Gadget und seiner Standardeinstellungen

Wir konnten die Definitionsseite für das "Descriptions"-Gadget nicht öffnen, aber es gibt Hinweise, dass es UI-Effekte verursacht. In den Nutzungstatistiken zeigt es, dass es in den Einstellungen ein- und ausgeschaltet werden kann, was darauf hindeutet, dass es nicht standardmäßig aktiviert ist. Eine andere Möglichkeit ist, dass Wikidata für bestimmte Seiten andere Hover-Hinweise verwendet.

Überprüfen der Standardaktivierung des "Descriptions"-Gadgets

Bestätigung des "Descriptions"-Gadgets und seiner Abhängigkeiten

Ich habe genug Hinweise, dass das "Descriptions"-Gadget auf Wikidata Hover-Tooltips mit Label/Beschreibung anzeigt, ohne die Popups-Erweiterung. Der Benutzer nannte auch "MediaWiki:Gadget-Descriptions" mit Abhängigkeiten zu "mediawiki.api" und "wikibase.api.RepoApi". Ich werde jetzt nach diesen Abhäng

Durchsuchen des Webs nach Descriptions.js Gadget

Zusammenfassung und Lösung des Problems mit Popups

Die Benutzerbeobachtung ist korrekt: Auf Wikidata funktioniert es aufgrund der deaktivierten Popups-Erweiterung. Das "Descriptions"-Gadget bietet Hover-Beschreibungen. "PopupsFix" ist entfernt und nicht mehr aktiv. Auf dem eigenen Wiki verursacht die Erweiterung Popups einen Fehler bei der Vorschau, vermutlich weil kürzlich Namensräume als „Content“ markiert wurden.

Searching for MediaWiki Popups namespace configuration settings

Fehlerursache und Lösungsvorschläge für Popups

Das Problem tritt auf, weil Popups für Wikibase-Seiten den "Page Previews API"-Ansatz verwenden, welcher für Wikibase-Inhalte nicht funktioniert, da sie keine Wikitext-Inhalte sind. Auf Wikimedia wurde Popups deaktiviert, und der "Descriptions"-Gadget bietet Tooltips. Lösung: Popups in Wikibase deaktivieren oder Konfiguration anpassen.

Searching MediaWiki Popups blacklist and configurations

Diagnose des Problems mit Popups und Wikibase

Die Popups-Erweiterung unterstützt nur Wikitext-Inhalte, während Wikibase-Entitätsseiten ein JSON-basiertes Inhaltsmodell verwenden. Popups kann daraus keine Zusammenfassung extrahieren. Das führt zum Fehler "Es gibt ein Problem beim Anzeigen der Vorschau". Lösung: Popups in Wikibase deaktivieren oder anpassen.

Diagnosing Popups-Fehler bei Wikibase-Inhalten

Vorschläge zur Umgehung des Popups-Problems

Die Popups-Erweiterung funktioniert optimiert für Wikipedia-Inhalte, während Wikibase für seine eigene API-Konfiguration der Inhalte benötigt. Ein möglicher Vorschlag: Die Implementierung der "Beschreibung"-Gadget-Funktion lokal nach Vorbild von Wikidata. Dies klingt sinnvoll und könnte durch die Phabricator-Referenz sowie die Nutzungsstatistik gestützt werden.

Forschungsergebnisse und Lösungsvorschlag für das Gadget

Auf Wikidata zeigt das Descriptions-Gadget die Beschreibung bei Hover. Um dies zu replizieren, erstellen Sie MediaWiki:Gadget-Descriptions.js und definieren es in MediaWiki:Gadgets-definition mit den Abhängigkeiten mediawiki.api und wikibase.api.RepoApi, sowie den Namensräumen 0, 120 und 146. Präsentieren Sie eine minimalistische Codeprobe zur Umsetzung der Funktion.

Überlegungen zur Bereitstellung von Code

Da der Auftrag komplex ist, kann eine teilweise Lösung hilfreich sein. Wir könnten die Definition für das Gadget bereitstellen, aber dir auch ein einfaches Skript anbieten, das an Links mit data-entity-id gebunden ist. Auf Wikibase-Artikel-Seiten verwendet der Link-Markup data-entity-id, und auf Wikidata-Seiten könnte .wb-entity-link verwendet werden.

Überlegungen zur Codebereitstellung und besseren Lösung

Anstatt unsicherer Codebeispiele zu geben, schlage ich vor, die einfache Variante zu benutzen: "Importiere das 'Descriptions' Gadget von Wikidata", eine minimal replizierbare Lösung. Alternativ, erstellen wir es gern nach einer Überprüfung der Selektoren auf deinem Skin. Außerdem ist der "Navigation popups"-Gadget mit der Popups-Erweiterung inkompatibel.

Präzisierung der Lösung und Hinweise

Anstatt unsicherer Codebeispiele zu geben, schlage ich vor, das „Descriptions“-Gadget von Wikidata zu importieren – eine minimale und replizierbare Lösung. Oder erstellen wir es neu, nachdem wir die Selektoren auf deinem Skin überprüft haben. Zusätzlich: "Navigation popups"-Gadget ist mit der Popups-Erweiterung inkompatibel und der Fehlertext kann bei Wikibase leer sein.

Lösungsvorschläge und Empfehlungen

Empfohlene Sofortmaßnahme: (a) Entferne diese Namensräume aus dem Inhalt; (b) Behalte sie bei, aber füge sie zu $wgPopupsPageDisabled hinzu (nicht ideal). Alternativ Pop

Vorschläge für Popups-Optionen

Wir können dreierlei Optionen für die Popups-Konfiguration in den betreffenden Namensräumen anbieten:

  1. Wiederherstellung des bisherigen Verhaltens: Popups ignorieren Q/P/L, schnellste Lösung, aber mit Nachteil für die Suchrankings und Analytics.
  2. Behalte den Inhalt, unterdrücke jedoch Popups nur für bestimmte Namensräume, gegebenenfalls durch ein kleines JS-Snippet für wgNamespaceNumber.

Lösung mit CSS für Popups

Wir könnten die .mwe-popups-Überschicht per CSS in den betreffenden Namensräumen ausblenden:

Nachgedacht für 1m 49s

Fertig

Quellen·129

(1. Dez. 2025, 18:18)

Kurzer Befund (Fakt):

  • Die MediaWiki-Extension Popups (Page/Reference Previews) ist für Wikipedia-ähnliche Inhalte (Wikitext) optimiert. Für andere Content-Handler – z. B. Wikibase-Entities – liefert Popups keine Vorschau, es braucht dafür eine eigene API nach dem Summary-Spec. Ohne diese endet der Hover mit der Fehlbox „Es gibt ein Problem beim Anzeigen der Vorschau“. MediaWiki
  • Popups zeigt Vorschauen standardmäßig nur in Content-Namespaces. Wenn du 120/122/146 in $wgContentNamespaces aufgenommen hast, versucht Popups dort nun Previews zu ziehen – scheitert bei Wikibase-Seiten aber am fehlenden passenden API-Endpoint. MediaWiki
  • Auf Wikidata sind die Popups-Previews der Extension seit 2017 deaktiviert worden („undeployed“). Wikidata nutzt stattdessen Gadgets für Tooltips/Previews (z. B. Descriptions), nicht die Popups-Extension. phabricator.wikimedia.org+1
  • Das Gadget Descriptions zeigt beim Hover über Q/P/L die Beschreibung; es ist ein normales RL-Gadget (nutzt mediawiki.api/wikibase.api.RepoApi). Es wird explizit als „Show the description of items and properties when hovering them“ geführt. Wikidata+1
Warum es bei dir jetzt fehlschlägt (Mutmaßung, aber naheliegend):
  • Früher waren die Wikibase-Namespaces nicht in $wgContentNamespaces; Popups hat dort gar nicht angesetzt und du hast das nicht bemerkt. Mit der Umstellung greift Popups nun auch auf Q/P/L-Links – und scheitert erwartungsgemäß am Content-Handler → Fehlbox. (Das passt exakt zum dokumentierten Verhalten der Extension.) MediaWiki+1
Was auf Wikidata tatsächlich „funktioniert“:
  • Nicht die Extension-Previews, sondern ein Gadget. Der Descriptions-Gadget zeigt Label/Beschreibung auf Hover; er ist separat von „Navigation popups“. (Die Extension erkennt „Navigation popups“ sogar als konfliktträchtig und schaltet sich dann ab.) Wikidata+1

Lösungen (geordnet von „sofort“ bis „robust“)

  1. Fehlbox abstellen, Verhalten wie „früher“
    • Entferne 120/122/146 wieder aus $wgContentNamespaces oder unterdrücke Popups dort per CSS (keine Logik-Eingriffe): body.ns-120 .mwe-popups, body.ns-122 .mwe-popups, body.ns-146 .mwe-popups { display: none !important; } Wirkung: keine Popups-Versuche mehr bei Q/P/L → keine Fehlbox. (Trade-off: Wenn du die Namespaces aus $wgContentNamespaces nimmst, ändert das auch Gewichtungen/„Contentness“ für andere Features. CSS blendet nur die Box aus.) MediaWiki
  2. Wikidata-Erlebnis nachbauen (empfohlen für die Arbeit an Entities)
    • Lege lokal das Gadget Descriptions an (wie auf Wikidata): MediaWiki:Gadgets-definition: Descriptions[ResourceLoader|dependencies=mediawiki.api,wikibase.api.RepoApi|namespaces=0,120,146|actions=view]|Descriptions.js MediaWiki:Gadget-Descriptions.js: Code, der beim Hover die Beschreibung des verlinkten Q/P/L via Wikibase-API lädt und als Tooltip zeigt. Wirkung: Du bekommst für Q/P/L aussagekräftige Kurzinfos wie auf Wikidata, unabhängig von der Popups-Extension. (Nachweis, dass genau dieses Gadget dafür genutzt wird: Gadget-Statistik/Tickets.) Wikidata+1
  3. „Echte“ Popups für Wikibase bauen (aufwendig, aber sauber)
    • Implementiere einen eigenen Summary-Endpoint für Wikibase-Entities (Label, Beschreibung, evtl. Bild) gemäß Page Content Service Summary 1.2.0 und setze $wgPopupsGateway = 'restbasePlain'; + $wgPopupsRestGatewayEndpoint = '/dein/endpoint/'. Wirkung: Einheitliche Previews (auch für Entities) über die Extension selbst. Aufwand: eigenständiger kleiner Dienst oder RL-Plugin, der das Spec bedient. MediaWiki

Antworten auf deine Punkte

  • „PopupsFix“/„Navigation popups“ in Wikidata-Einstellungen: Diese sind Gadgets (JS/CSS), keine Extension-Konfiguration. Popups-Extension ist dort abgeschaltet; das passt zu den Phabricator-Einträgen. phabricator.wikimedia.org+1
  • „Das Popupfenster auf Wikidata sieht anders aus“ – korrekt, weil es Gadget-UI ist, nicht die Extension-UI. Wikidata
  • „$wgPopupsGateway ändern?“ – Das hilft nur, wenn ein kompatibler Endpoint existiert. Ohne eigenen Summary-Endpoint für Wikibase bleibt die Fehlbox. MediaWiki

Pragmatiker-Pfad (konkret)

  • Kurzfristig: Descriptions-Gadget einrichten (2) und die Fehlbox in 120/122/146 via CSS ausblenden (1).
  • Mittelfristig: entscheiden, ob die Wikibase-Namespaces wirklich als „Content“ gebraucht werden.
  • Langfristig: eigener Summary-Endpoint für Popups (3), falls du einheitliche Previews willst.

Wenn du möchtest, skizziere ich dir im nächsten Schritt die genaue Gadget-JS-Struktur (selektor-sicher für Vector-2022) oder entwerfe das Endpoint-Schema (Feldliste, i18n, Fallback-Logik).

Du:

Danke für die Hinweise und Erklärungen.

Ich habe MediaWiki:Gadget-Descriptions.js und MediaWiki:Gadget-Descriptions von Wikidata in mein MediaWiki übernommen und das Gadget in MediaWiki:Gadget-definition eingetragen und diesen Helfer unter persönliche Einstellungen aktiviert, sowie die 120, 122 und 146 als wgContentNamespaces deaktiviert.

Wenn ich nun über einen Wikibase-Link hoover erscheint als Popup nur das einfache popup-Fenster, welches mit "Namensraumname:ID", Vergleichsweise "Lexeme:L1" anzeigt. Es fehlt also noch etwas, daß es funktionieren kann.

Anbei das Coding von MediaWiki:Gadget-Descriptions.js – kannst du aus dem Coding erkennen, was da gegebenenfalls noch fehlt?

ChatGPT:

Aktivität ·57s

Denke nach…

Dokumente werden gelesen

Dokumente werden gelesen

Überprüfen von fehlenden Modulen und deren Auswirkungen

Bei der bereitgestellten Gadget-Code scheint das Modul „jquery.wikibase.wbtooltip“ zu fehlen, das in Wikidata verwendet wird, um Tooltips anzuzeigen. Es könnte in der lokalen MediaWiki-Installation fehlen oder anders benannt worden sein. Fehlt das Modul, wird das Standard-Browser-Tooltip verwendet.

Untersuchen von fehlenden Plugins und Fallbacks

Wenn das 'wbtooltip'-Plugin nicht geladen ist, führt der Aufruf von $tooltip.wbtooltip(...) zu einem Fehler oder hat keinen Effekt. Der Benutzer sieht möglicherweise nur die einfache Popup-Anzeige "Namespace:ID," was auf den Standard-Fallback der Popups-Erweiterung hinweist. Möglicherweise sind die Änderungen an den Namensräumen noch nicht wirksam.

Fehlende Übereinstimmung bei den Selektoren und Tooltips

Das angezeigte "Lexeme:L1" ist kein Popup, sondern das Standard-Browser-Tooltip. Das deutet darauf hin, dass das Gadget die Links nicht korrekt erkennt oder anhängt. Die verwendeten Selektoren passen wahrscheinlich nicht zum lokalen Setup, da der Pfad '/wiki/' in diesem Fall nicht vorhanden ist.

Überprüfung der Einschränkungen und RegExp-Anpassung

Das Gadget ist auf Entitätsseiten (Wikibase Repo) beschränkt, dank einer Überprüfung auf 'wbEntityId', die nur dort existiert. Außerdem verwendet es RegExp, um Q- und P-Nummern zu extrahieren. Der lokale Wiki-Pfad könnte '/Q123' oder '/Item:Q123' lauten, was eine Anpassung der RegExp erforderlich macht.

Untersuchen fehlende Abhängigkeiten und Fehlerursachen im Gadget

Probleme mit Regex und fehlenden Abhängigkeiten

Die Regex erfasst 'Item:Q123', aber der Pfad '/wiki/' passt nicht. Der 'href' sollte entsprechend angepasst werden, um den lokalen Pfad korrekt zu erfassen. Außerdem fehlt die Abhängigkeit 'jquery.wikibase.wbtooltip' in der Gadget-Definition, was zu einem Fehler führt, wenn der Tooltip nicht korrekt geladen wird.

Suchen nach Quellen zu Wikidata-Tooltip-Diensten

Vorschläge zur Verbesserung der Gadget-Definition und Fehlerbehebung

Wir sollten die Gadget-Definition aktualisieren, um 'mediawiki.api', 'wikibase.api.RepoApi' und 'jquery.wikibase.wbtooltip' als Abhängigkeiten hinzuzufügen. Auch der Selektor 'a[href^="/wiki/"]' muss angepasst werden, um die korrekten Artikelpfade zu berücksichtigen. Schließlich muss der Code erweitert werden, damit auch Lexeme-IDs ('L\d+') unterstützt werden.

Überprüfung der Namespace- und Selektionslogik im Gadget-Code

Der Code erfasst auch Links in Lexeme-Formen, aber verarbeitet bisher nur Q/P-IDs. Die Konfiguration 'mw.config.exists("wbEntityId")' sorgt dafür, dass das Gadget nur auf Entity-Seiten läuft, was in Ordnung ist. Allerdings fehlt der Property-Namespace 122 in der Gadget-Definition, was eventuell ein Fehler sein könnte.

Überprüfung der Funktionalität der Gadget-Implementierung

Das Gadget funktioniert auf Item-Seiten, aber um Tooltips auf Property-Seiten anzuzeigen, müsste der Property-Namespace 122 eingeschlossen werden. Es verwendet wbgetentities über mw.Api, jedoch ohne direkte Nutzung von wikibase.api.RepoApi. Die Tooltip-Funktionalität hängt vom $tooltip.wbtooltip Plugin ab.

Vorschlag für angepasste Descriptions.js

Wir sollten eine angepasste Version von Descriptions.js vorschlagen, die den href-Selektor korrigiert, L-Unterstützung hinzufügt und die Abhängigkeit zu jquery.wikibase.wbtooltip integriert. Falls der Plugin fehlt, könnte ein Fallback zur Titel-Attributnutzung eingebaut werden. URLs, die nicht mit '/wiki/' beginnen, werden ebenfalls unterstützt, und die robuste Erkennung erfolgt mit mw.util.getUrl() oder durch das Verwenden des wgArticlePath Prefix.

Vorschlag für selektorenanpassung und Patch

Um die Selektoren zu erweitern, sollte der Code von href^="/wiki/" auf a[href^="' + mw.util.getUrl('') + '"] umgeschaltet werden. Für eine genauere Erkennung könnten wir auch Links wie a[href*="Item:Q"] oder a[href*="Property:P"] verwenden. Für Robustheit sollten sowohl Anchor-Links mit als auch ohne “/wiki/” berücksichtigt werden.

Zusammenfassung der nächsten Schritte und Hinweise

Wir sollten in die Antwort sowohl Zitate als auch Referenzen integrieren, beispielsweise zur wbtooltip-Abhängigkeit, z.B. dass diese erforderlich ist. Auch die Anpassungen in Descriptions.js sollten klargestellt werden. Ich bestätige auch, dass der Timestamp nur zu Beginn eines neuen Chats erforderlich ist – hier nicht notwendig.

Korrektur der Selector-Probleme und Langsame Fehlerbehebung

Es scheint, dass der aktuelle Selector für '/wiki/' zu eng ist. Außerdem wird Lexeme-Support für L* nicht implementiert. Ich werde den minimalen Patch schreiben und auch sicherstellen, dass beim Fehlen des wbtooltip-Moduls ein Fallback (z. B. Title-Attribut oder mw.notify) verwendet wird.

Bereitstellung des korrigierten Codes und des Minimal-Patches

Der vorgeschlagene Patch aktualisiert den JS-Code, um die unterschiedlichen Selektoren für Wikibase-Elemente zu unterstützen und den Tooltip korrekt anzuzeigen. Eine Funktion wird definiert, um die Initialisierung einmal auszuführen. Ein minimaler Patch wird als Ersatzdatei angeboten, um den Code zu ersetzen.

Nachgedacht für 58s

Fertig

Quellen·46

Danke – das hilft beim Eingrenzen. Ich sehe drei konkrete Ursachen im übernommenen Skript und in der Gadget-Definition:

  1. Falscher Link-Selektor (/wiki/ fest verdrahtet). Dein Wiki nutzt $wgArticlePath = "/$1", nicht /wiki/$1. Im Code werden nur a[href^="/wiki/"] abgegriffen – dadurch findet das Gadget bei dir schlicht keine Q/P/L-Links. Gadget-Descriptions
  2. Abhängigkeit auf jquery.wikibase.wbtooltip fehlt. Das Skript ruft .$wbtooltip(...) auf, lädt das Modul aber nicht als Dependency. Auf Wikidata ist das Modul global verfügbar; lokal muss es als RL-Abhängigkeit deklariert werden. (Das Modul existiert in Wikibase; vgl. die Referenzen zu jquery.wikibase.wbtooltip in Upstream-Änderungen.) MediaWiki+2MediaWiki+2
  3. Lexeme (L…) werden nicht berücksichtigt. IDs werden nur als Q\d+ oder Property:P\d+ extrahiert – kein L\d+. Ergebnis: Bei Lexeme-Links bleibt es bei der Standard-Titel-Tooltip („Lexeme:L1“). Gadget-Descriptions

Korrektur – minimal & robust

A) Gadget-Definition anpassen

Ersetze deine Zeile in MediaWiki:Gadgets-definition durch diese (Property-NS 122 ergänzt, Tooltip-Modul als Dependency hinzugefügt):

Descriptions[ResourceLoader|dependencies=mediawiki.api,jquery.wikibase.wbtooltip|namespaces=0,120,122,146|actions=view]|Descriptions.js

Hinweis: wikibase.api.RepoApi brauchst du für dieses Gadget nicht; es nutzt mw.Api().get( action=wbgetentities ).

B) JS: Selektoren + Lexeme + Loading fixen

Ersetze den Inhalt von MediaWiki:Gadget-Descriptions.js durch diese drop-in-Version (funktional gleich, aber portabel):

// required modules: mediawiki.api, jquery.wikibase.wbtooltip
( function ( mw, $, wb ) {
	// nur auf Repo-Entityseiten; verhindert unnötiges Laden
	if ( !mw.config.exists( 'wbEntityId' ) ) {
		return;
	}

	function init() {
		var api = new mw.Api( { userAgent: 'Gadget-Descriptions/local-2025-12-02' } ),
			userLang = mw.config.get( 'wgUserLanguage' ),
			ids = [],
			anchors = {},
			$tooltip = $( '<span>' ).appendTo( 'body' );

		// Artikelpfad-Basis ermitteln ("/" oder "/wiki/")
		var base = mw.config.get( 'wgArticlePath' ).replace( '$1', '' );
		var server = mw.config.get( 'wgServer' ) || '';

		// Selektoren so wählen, dass sowohl "/$1" als auch "/wiki/$1" & absolute URLs funktionieren
		var selectors = [
			// relative Links
			'a[href^="' + base + 'Item:Q"]',
			'a[href^="' + base + 'Property:P"]',
			'a[href^="' + base + 'Lexeme:L"]',
			// absolute Links
			'a[href^="' + server + base + 'Item:Q"]',
			'a[href^="' + server + base + 'Property:P"]',
			'a[href^="' + server + base + 'Lexeme:L"]',
			// „kurze“ Formen (z. B. /Q123 auf Wikidata)
			'a[href^="/Q"]',
			'a[href^="/Property:P"]',
			'a[href^="/L"]'
		].join( ', ' );

		// nur in typischen Wikibase-Bereichen scopen (optional; kann man weglassen)
		var $scope = $( document );

		$scope.find( selectors ).each( function () {
			var $a = $( this ), href = $a.attr( 'href' ) || '';
			// Q / P / L extrahieren
			var m = href.match( /(?:^|[/:])(Q\d+|P\d+|L\d+)(?:[^\d]|$)/ );
			if ( !m ) { return; }
			var id = m[ 1 ];

			if ( ids.indexOf( id ) === -1 ) { ids.push( id ); }
			( anchors[ id ] || ( anchors[ id ] = [] ) ).push( $a );
		} );

		function attach( id, text ) {
			( anchors[ id ] || [] ).forEach( function ( $a ) {
				$a.on( 'mouseenter.Descriptions', function () {
					var tip = $tooltip.wbtooltip( {
						content: $( '<span>' ).text( text ),
						permanent: true,
						gravity: 'nw',
						$anchor: $a
					} ).data( 'wbtooltip' );
					if ( tip ) { tip.show(); }
				} ).on( 'mouseleave.Descriptions', function () {
					var tip = $tooltip.data( 'wbtooltip' );
					if ( tip ) { tip.hide(); }
				} );
			} );
		}

		// batched wbgetentities
		while ( ids.length ) {
			var batch = ids.splice( 0, 50 );
			api.get( {
				action: 'wbgetentities',
				ids: batch.join( '|' ),
				props: 'descriptions',
				languages: userLang,
				languagefallback: 1
			} ).then( function ( data ) {
				$.each( data.entities || {}, function ( id, entity ) {
					var desc = entity.descriptions && entity.descriptions[ userLang ] && entity.descriptions[ userLang ].value;
					if ( desc ) { attach( id, desc ); }
				} );
			} );
		}
	}

	// Lade-Reihenfolge sicherstellen
	mw.loader.using( [ 'mediawiki.api', 'jquery.wikibase.wbtooltip' ] ).then( function () {
		// initial
		$( init );
		// nach (Re-)Rendern der Entity-Ansicht
		mw.hook( 'wikibase.entityPage.entityView.rendered' ).add( init );
	} );

}( mediaWiki, jQuery, wikibase ) );

Was ist konkret geändert?

  • Selektor nicht mehr fest auf /wiki/, sondern dynamisch aus wgArticlePath/wgServer gebaut → funktioniert mit "/$1" und "/wiki/$1". Gadget-Descriptions
  • Lexeme (L\d+) werden mit erfasst (Parsing + Selektoren). Gadget-Descriptions
  • Modul-Ladung via mw.loader.using( 'jquery.wikibase.wbtooltip' ) → garantiert, dass .$wbtooltip()existiert. (Upstream belegt die RL-Modulbezeichnung.) MediaWiki+1

Prüf-Checkliste (30 Sek.)

  1. Cache leeren: Strg/⌘-F5 auf einer Q-Seite; einmal ?action=purge.
  2. Konsole prüfen: Kein ...wbtooltip is not a function → Dependency sitzt.
  3. Hover-Test: In einer Item-Seite über Q/P/L-Links hovern – es sollte die Beschreibungs-Tooltip erscheinen (kein „Lexeme:L1“ mehr).
  4. Optional: Wenn du das Verhalten auch auf Property-Seiten willst, ist namespaces=122 bereits in der Definition enthalten.

Warum dieser Weg?

  • Wikidata setzt für diese „Beschreibung beim Hover“ kein Popups-Summary ein, sondern JS-Gadgets (u. a. jquery.wikibase.wbtooltip-basiert). Entsprechend ist das Nachbauen via Gadget der schnellste Weg – und unabhängig von der Popups-Extension. Wikimedia Phabricator

Wenn du willst, gebe ich dir noch eine CSS-Klasse für dunkles Theme (Vector-2022) mit, die den Tooltip-Kontrast an deine AufEinWort-Farben anpasst.

Du:

Ich habe das Coding ersetzt – am Verhalten hat sich nichts geändert.

Bei Wikidata habe ich folgende Einstellung gefunden:

'wgPopupsGateway' => [
	// mwApiPlain should never be used in a production setting as it is not cached.
	'default' => 'restbaseHTML',
],

Könnte dies und Weiteres dazu bedingt sein?

ChatGPT:

Aktivität ·30s

Denke nach…

Prüfung der richtigen Implementierung von Timestamps und weiteren Anfragen

Die Anfrage des Nutzers zu Timestamps im Kontext bleibt ähnlich. Es scheint keine Notwendigkeit, den bereits gezeigten Timestamp erneut hinzuzufügen. Der Nutzer hat ein Problem mit simplen Popups und einer bestimmten Wikidata-Einstellung. Ich muss weiter nach einer Lösung suchen und gegebenenfalls aktuelle Informationen prüfen.

Fehlerbehebung bei Gadget und Popups

Der Nutzer hat ein Gadget-Problem, bei dem während des Hoverns über Links nur ein einfacher Popup angezeigt wird. Möglicherweise ist der Code des Gadgets nur auf EntityPage-Kontexte ausgerichtet. Der Popup könnte ein Standard-Browser-Tooltip sein oder von OOUI stammen. Außerdem wurden Inhalte von Namespaces deaktiviert, was die typische Vorschau verhindert.

Behebung des Problems mit dem Gadget auf Nicht-Entity-Seiten

Das Gadget nutzt wbtooltip zum Anzeigen von Beschreibungen bei Hover, aber der Code läuft nur auf Entity-Seiten, wenn die Konfiguration „wbEntityId“ existiert. Auf normalen Wiki-Seiten wird das Gadget daher nicht ausgeführt. Die Links könnten auch in kürzeren URL-Formaten angezeigt werden, was die Selektoren durcheinanderbringt.

Mögliche Ursachen unklar

Es gibt mehrere mögliche Ursachen, warum das Gadget nicht wie erwartet funktioniert. Ein möglicher Grund könnte die Verwendung des dynamischen Basis-Pfads wgArticlePath und einer abweichenden Canonical-Server-Konfiguration sein. Auch unterschiedliche Modulnamen in ihrem Wikibase-System könnten eine Rolle spielen. Die Prüfung der Ladezustände im Entwicklertool könnte helfen.

Anpassen des Gadgets für alle Seiten

Es scheint, dass das Gadget aufgrund des Früh-Abbruchs beim Fehlen von 'wbEntityId' auf Nicht-Entity-Seiten nicht funktioniert. Wir sollten diese Schutzvorkehrung entfernen und den Hook 'wikipage.content' verwenden, damit das Gadget auch auf normalen Seiten funktioniert. Außerdem müssen wir sicherstellen, dass der Event-Listener nur einmal pro Link angehängt wird.

Durchsuchen von Web-Dokumentationen und Modulen

Debugging-Vorschläge für das Gadget

Um das Problem zu untersuchen, sollten wir sicherstellen, dass das Gadget geladen wurde und die richtigen Module (wie 'jquery.wikibase.wbtooltip') aktiv sind. Es ist auch wichtig zu überprüfen, ob CSS oder native Browser-Tooltips das Gadget stören. Möglicherweise gibt es auch ein Problem mit Cross-Origin-Beschränkungen, wenn die API-Pfade nicht zugelassen sind.

Überarbeitung der Gadget-Logik

Auf der lokalen Wiki könnte die 'wbgetentities'-API 'origin=*' benötigen. Um sicherzustellen, dass der Popup funktioniert, entfernen wir den 'wbEntityId'-Check, um überall zu laden, auch außerhalb von Entitätsseiten. Wir passen den Code an, damit er auf allen Inhalten läuft und Links über das gesamte Dokument hinweg durchsucht.

Klärung und Anpassungen

Der aktuelle Computationswert für 'wgArticlePath' scheint korrekt. Wir sollten sicherstellen, dass Anchor-Event-Handler nicht durch andere UI-Frameworks unterdrückt werden. Auch, obwohl auf Wikidata der Popups-Extension deaktiviert ist, stellt sich heraus, dass 'wikibase.api.RepoApi' möglicherweise doch notwendig sein könnte. Aber lokal ist mw.Api ausreichend.

Erklärung zur Popups-Gateway-Konfiguration

Die Popups-Extension ist auf Wikidata für Artikel deaktiviert, sodass die restbaseHTML-Einstellung eher für andere Seiten wie Projektseiten relevant ist. Der 'Descriptions'-Gadget funktioniert jedoch weiterhin. Da der Benutzer Popups für normale Seiten bereits aktiviert hat, ist es nicht erforderlich, diese für Artikel zu aktivieren. Die

Nachgedacht für 30s

Fertig

Quellen·50

Alles klar — zwei Punkte vorweg:

  1. Das Wikidata-Setting wgPopupsGateway = 'restbaseHTML' erklärt deine Q/P/L-Hover-Beschreibungen nicht.Das ist eine Einstellung der Extension:Popups (Page Previews). Die Wikidata-„Beschreibung beim Hover“ kommt aus dem Gadget „Descriptions“, das via API wbgetentities Beschreibungen lädt und als Tooltip einblendet. Das Gateway beeinflusst nur die Popups-Extension (Page/Reference Previews) und ist für das Gadget irrelevant. Wikimedia Phabricator+4MediaWiki+4MediaWiki+4
  2. Warum dein Gadget weiterhin nur „Lexeme:L1“ etc. zeigt: In der von mir vorgeschlagenen Fassung war noch eine Hürde drin (mein Fehler): Ich hatte das Gadget auf Entity-Seiten gekappt (wbEntityId-Guard) und auf den Hook der Entity-Ansicht gehängt. Dann läuft es z. B. auf normalen Wiki-Seiten oder Spezialseiten nicht, und es bleibt beim Standard-Tooltip. Außerdem ist es robuster, auf den core-Hook wikipage.content zu hören. doc.wikimedia.org

Korrigierte, robuste Version

1) Gadget-Definition (einmalig anpassen)

Setze in MediaWiki:Gadgets-definition (breit einsetzbar, ohne Namespace-Filter):

Descriptions[ResourceLoader|dependencies=mediawiki.api,jquery.wikibase.wbtooltip|actions=view]|Descriptions.js
  • jquery.wikibase.wbtooltip ist das Tooltip-Modul aus Wikibase; als Dep. zwingend laden (auf Wikidata ist es global verfügbar, lokal nicht). MediaWiki+1
2) Gadget-Script (ersetzt den kompletten Inhalt von MediaWiki:Gadget-Descriptions.js)

Die Version unten

  • entfernt den wbEntityId-Guard,
  • hängt sich an wikipage.content (läuft überall, auch nach Ajax-Reflows),
  • erkennt Q/P/L in relativen und absoluten Links, egal ob "/$1" oder "/wiki/$1".
    /* Gadget: Descriptions – zeigt Wikibase-Beschreibungen beim Hover über Q/P/L-Links
 * Abhängigkeiten: mediawiki.api, jquery.wikibase.wbtooltip
 */
( function ( mw, $ ) {

	function scanAndBind( $root ) {
		var api = new mw.Api( { userAgent: 'Gadget-Descriptions/local-2025-12-02' } );
		var userLang = mw.config.get( 'wgUserLanguage' );

		// Basis für Linkerkennung ermitteln ("/" oder "/wiki/")
		var base = ( mw.config.get( 'wgArticlePath' ) || '/$1' ).replace( '$1', '' );
		var server = mw.config.get( 'wgServer' ) || '';

		// Selektoren: relativ + absolut + kurze Formen
		var selectors = [
			'a[href^="' + base + 'Item:Q"]',
			'a[href^="' + base + 'Property:P"]',
			'a[href^="' + base + 'Lexeme:L"]',
			'a[href^="' + server + base + 'Item:Q"]',
			'a[href^="' + server + base + 'Property:P"]',
			'a[href^="' + server + base + 'Lexeme:L"]',
			// kurze Formen (falls vorhanden)
			'a[href^="/Q"]',
			'a[href^="/Property:P"]',
			'a[href^="/L"]'
		].join( ', ' );

		var ids = [];
		var nodesById = Object.create( null );

		$root.find( selectors ).each( function () {
			var $a = $( this );

			// Doppelt-Binden vermeiden
			if ( $a.data( 'aewDescBound' ) ) {
				return;
			}

			var href = $a.attr( 'href' ) || '';
			var m = href.match( /(?:^|[/:])(Q\d+|P\d+|L\d+)(?:[^\d]|$)/ );
			if ( !m ) { return; }
			var id = m[ 1 ];

			$a.data( 'aewDescBound', true );

			if ( ids.indexOf( id ) === -1 ) {
				ids.push( id );
			}
			( nodesById[ id ] || ( nodesById[ id ] = [] ) ).push( $a );
		} );

		if ( !ids.length ) {
			return;
		}

		// In Batches abfragen
		function attach( id, text ) {
			( nodesById[ id ] || [] ).forEach( function ( $a ) {
				$a.on( 'mouseenter.aewDesc', function () {
					var tip = $( '<span>' ).wbtooltip( {
						content: $( '<span>' ).text( text ),
						permanent: true,
						gravity: 'nw',
						$anchor: $a
					} ).data( 'wbtooltip' );
					if ( tip ) { tip.show(); }
				} ).on( 'mouseleave.aewDesc', function () {
					var tip = $( 'span' ).data( 'wbtooltip' );
					if ( tip ) { tip.hide(); }
				} );
			} );
		}

		while ( ids.length ) {
			var batch = ids.splice( 0, 50 );
			api.get( {
				action: 'wbgetentities',
				ids: batch.join( '|' ),
				props: 'descriptions',
				languages: userLang,
				languagefallback: 1
			} ).then( function ( data ) {
				var ents = data && data.entities || {};
				Object.keys( ents ).forEach( function ( id ) {
					var e = ents[ id ];
					var d = e.descriptions && e.descriptions[ userLang ];
					if ( d && d.value ) {
						attach( id, d.value );
					}
				} );
			} );
		}
	}

	// Module laden und auf allen Seiten aktivieren
	mw.loader.using( [ 'mediawiki.api', 'jquery.wikibase.wbtooltip' ] ).then( function () {
		// initial
		$( function () { scanAndBind( $( document ) ); } );
		// bei Content-Wechseln
		mw.hook( 'wikipage.content' ).add( function ( $content ) {
			scanAndBind( $content );
		} );
	} );

}( mediaWiki, jQuery ) );

Prüfen (1 Minute)

  1. Modulzustände: In der Browser-Konsole:
    • mw.loader.getState('ext.gadget.Descriptions') → ready
    • mw.loader.getState('jquery.wikibase.wbtooltip') → ready (Andernfalls stimmt die Definition/Abhängigkeit nicht.) MediaWiki
  2. Selektor-Treffer:
    • $$('a[href*="Item:Q"]')[0] (oder 'Property:P', 'Lexeme:L') → sollte ein Link-Element liefern.
    • Wenn du kein /wiki/ nutzt, kontrolliere mw.config.get('wgArticlePath') → bei dir "/$1". Der Code oben nutzt genau das.
  3. API-Antwort:
    • In den Dev-Tools → „Netzwerk“ → beim ersten Hover siehst du action=wbgetentities&ids=Q… → 200 OK mit descriptions.
    • Falls es in deiner Benutzersprache keine Beschreibung gibt, greift languagefallback=1. Ohne Treffer erscheint kein Tooltip (intended).

Zu wgPopupsGateway (Antwort auf deine Frage)

  • Das Setting schaltet die Quelle für Page-Previews um (mwApiPlain vs. restbasePlain/restbaseHTML). Das betrifft die Extension:Popups, nicht unser Gadget.
  • „restbaseHTML“ ist eine gängige Prod-Konfig, weil der REST-Summary-Endpoint (Specs/Summary/1.2.0) serverseitig gecacht ist. Für dein Ziel (Wikibase-Beschreibungen beim Hover) bringt das keinen Effekt, solange die Popups-Extension nicht auch Wikibase-Entities mit einem passenden Summary-Endpoint versorgt. MediaWiki+1

Wenn es dennoch „nichts“ tut

  • Kein wbtooltip-Modul vorhanden: Sehr alte/nicht standardkonforme Wikibase-Builds? Prüfe auf Special:Version → Wikibase-Version. Seit 1.35-wmf.41 ist das Modul von Repo/Client entkoppelt und als RL-Modul verfügbar. MediaWiki
  • Links weichen vom Muster ab: Schick mir 1–2 konkrete Link-HREFs (oder ich passe den RegEx noch großzügiger an).
  • Keine Beschreibungen gepflegt: Teste eine Q/P/L mit sicher vorhandener Beschreibung.

Wenn du möchtest,

gebe ich dir noch eine Mini-CSS für das Tooltip (Kontrast in Vector-2022 Dark) und eine Option, zuerst Label und darunter kleiner die Beschreibung zu zeigen.

Du:

Coding und Defintion habe ich ersetzt.

Ergebnis Modulzustände: In der Browser-Konsole:

mw.loader.getState('ext.gadget.Descriptions') → ready
mw.loader.getState('jquery.wikibase.wbtooltip') → ready

Selector-Treffer auch in dr Konsole ausführen?

Api-Antwort: bei hoover zeigen auch die anderen popups keinen neuen Eintrag bei Hoover, also es geschieht unter Netzwerk der DevTools allgemein nichst, wenn ich einen hoover ausführe und ein Popup-Fenster aufgeht.

ChatGPT:

Denke nach…

Fehlerbehebung bei Gadget-Auslöser

Es gibt ein Problem, bei dem das Gadget nicht ausgelöst wird, obwohl das Modul bereit ist. Es scheint, dass beim Hover keine Netzwerkanfragen kommen, und stattdessen werden andere Popups angezeigt. Wir müssen testen, ob der Selektor korrekt funktioniert und dem Benutzer raten, die querySelectorAll-Anzahl zu prüfen.

Überprüfung der Code-Ausführung und Netzwerkaufrufe

Wir sollten den Entwickler bitten, Konsolenbefehle auszuführen, um die Erkennung von Ankern und die Extraktion der ID zu überprüfen sowie sicherzustellen, dass $a.data('aewDescBound') gesetzt ist. Wenn beim Hover keine Netzwerkaufrufe erscheinen, könnte es an fehlenden Selektoren liegen. Wir sollten sie bitten, den Code nach Seitenaufruf zu überprüfen.

Anpassung des Codes und Konsole-Snippet

Ich sollte ein Konsolen-Snippet bereitstellen, um die Anzahl der Übereinstimmungen und einige Beispiele anzuzeigen. Möglicherweise müssen wir die Selektoren anpassen, um Fragmente oder Abfragen zu berücksichtigen. Ein weiteres Problem könnte sein, dass Anker von Vue-Komponenten dynamisch erzeugt werden. Wir fügen daher den 'wikibase.entityPage.entityView.rendered'-Hook hinzu.

Überprüfung von Hooks und Selektoren

Es könnte sein, dass die Anker dynamisch durch Vue-Komponenten erzeugt werden. Wir haben den wikipage.content-Hook hinzugefügt, aber es könnte auch der wikibase.entityPage.entityView.rendered-Hook nötig sein. Wir sollten auch die Möglichkeit eines Blockierens von Events durch CSS prüfen. Ein Konsolentest zur Evaluierung der Selektoren ist sinnvoll, ebenso wie die Prüfung der Regex-Extraktion.

Durchführen von Debugging-Tests für Gadget-Auslöser

Debugging bei fehlenden Selektoren und Links

Wir fanden zwar nicht den genauen Code für das Gadget, aber hatten Zugriff auf Dokumentation zu Wikibase-Hooks. Zur Fehlerbehebung sollten wir den Benutzer anweisen, ein Konsolenskript zur Überprüfung der Selektoren auszuführen. Außerdem müssen wir die '/entity/'-Pfad-Optionen in unsere Selektoren aufnehmen, um alle relevanten Links zu erfassen.

Optimizing selector patterns and tooltip handling

Wir schlagen vor, die Selektoren zu erweitern, um auch Formen wie 'href*="Item:Q"' und '/entity/Q' abzudecken. Zusätzlich sollten wir den Tooltip direkt am Anker verwenden, anstatt ein neues Span zu erzeugen, um Duplikate zu vermeiden. Auch die 'title'-Attribute beim Hover könnten unser Tooltip überdecken, aber wir können es dennoch korrekt anzeigen.

Updating code and implementing hover behavior with caching

Der Benutzer erwähnt, dass Popups auch beim Hover angezeigt werden, aber wir haben die Content-Namensräume entfernt, daher sollten sie für Q/P/L nicht erscheinen. Allerdings könnte es für Site-Links (Hauptnamensraum) immer noch auftauchen. Ich werde den Code aktualisieren, um Hover-Ereignisse mit einem MutationObserver zu behandeln und den ersten API-Aufruf zu machen, wenn der Benutzer darüber fährt.

Nachgedacht für 30s

Fertig

(2. Dez. 2025, 18:00)

Danke für die schnelle Rückmeldung. Befund: Module sind „ready“, aber es gibt keine API-Anfragen – das deutet darauf, dass das Gadget keine passenden Links findet (oder erst gar nicht bindet). Auf vielen Wikibase-Instanzen verlinken UI-Bestandteile nicht nur auf Item:Q…/Property:P…/Lexeme:L…, sondern auch auf /entity/... oder Special:EntityPage/.... Mein vorheriger Selektor hat das noch nicht abgedeckt.

Minimaler Debug-Check (Konsole)

Ja, bitte kurz den Selektor prüfen – das klärt sofort, ob wir ins Leere greifen:

(function(){
  var base=(mw.config.get('wgArticlePath')||'/$1').replace('$1','');
  var server=mw.config.get('wgServer')||'';
  var sel=[
    'a[href*="Item:Q"]','a[href*="Property:P"]','a[href*="Lexeme:L"]',
    'a[href*="/entity/Q"]','a[href*="/entity/P"]','a[href*="/entity/L"]',
    'a[href*="Special:EntityPage/Q"]','a[href*="Special:EntityPage/P"]','a[href*="Special:EntityPage/L"]'
  ].join(', ');
  console.log('found', document.querySelectorAll(sel).length, 'links');
  console.log('sample', Array.from(document.querySelectorAll(sel)).slice(0,5).map(a=>a.getAttribute('href')));
})();
  • found = 0 ⇒ Selektoren passen noch nicht → untere Code-Version nutzen (erweitert).
  • found > 0 ⇒ dann sollte das Gadget binden; wenn trotzdem kein Netzcall: Binding/Timing anpassen (siehe unten).

Robuste Gadget-Version (enthält /entity/ + Special:EntityPage/, lädt beim ersten Hover)

Bitte MediaWiki:Gadget-Descriptions.js komplett ersetzen und die Definition so lassen wie zuletzt (dependencies=mediawiki.api,jquery.wikibase.wbtooltip).

/* Gadget: Descriptions – zeigt Wikibase-Beschreibungen (Q/P/L) beim Hover.
 * Lädt on-demand beim ersten Hover; robust für /$1, /wiki/$1, /entity/, Special:EntityPage/.
 * Abhängigkeiten: mediawiki.api, jquery.wikibase.wbtooltip
 */
( function ( mw, $ ) {
	'use strict';

	var cache = Object.create( null ); // id -> { text: string|false, pending: Promise|null }

	function buildSelector() {
		var parts = [
			'a[href*="Item:Q"]','a[href*="Property:P"]','a[href*="Lexeme:L"]',
			'a[href*="/entity/Q"]','a[href*="/entity/P"]','a[href*="/entity/L"]',
			'a[href*="Special:EntityPage/Q"]','a[href*="Special:EntityPage/P"]','a[href*="Special:EntityPage/L"]'
		];
		return parts.join(', ');
	}

	function extractId( href ) {
		// greift für .../Q123, .../P12, .../L7 (egal ob Item:, /entity/, Special:EntityPage/)
		var m = ( href || '' ).match( /(?:^|[/:])(Q\d+|P\d+|L\d+)(?:[^\d]|$)/ );
		return m ? m[1] : null;
	}

	function bindHover( $a, id ) {
		if ( $a.data( 'aewDescBound' ) ) { return; }
		$a.data( 'aewDescBound', true );

		$a.on( 'mouseenter.aewDesc', function () {
			// schon im Cache?
			if ( cache[id] && cache[id].text ) {
				showTooltip( $a, cache[id].text );
				return;
			}
			// schon angefragt?
			if ( cache[id] && cache[id].pending ) {
				cache[id].pending.then( function (text) {
					if ( text ) { showTooltip( $a, text ); }
				} );
				return;
			}
			// jetzt laden (on-demand)
			var api = new mw.Api( { userAgent: 'Gadget-Descriptions/local-2025-12-02' } );
			cache[id] = { text: '', pending: api.get( {
				action: 'wbgetentities',
				ids: id,
				props: 'descriptions',
				languages: mw.config.get( 'wgUserLanguage' ),
				languagefallback: 1
			} ).then( function ( data ) {
				var ents = data && data.entities || {};
				var e = ents[id];
				var lang = mw.config.get( 'wgUserLanguage' );
				var desc = e && e.descriptions && ( e.descriptions[lang] || Object.values( e.descriptions )[0] );
				var text = desc && desc.value || '';
				cache[id].text = text || false;
				cache[id].pending = null;
				if ( text ) { showTooltip( $a, text ); }
				return text;
			} ).catch( function () {
				cache[id].text = false;
				cache[id].pending = null;
				return '';
			} ) };
		} ).on( 'mouseleave.aewDesc', function () {
			hideTooltip( $a );
		} );
	}

	function showTooltip( $anchor, text ) {
		$anchor.wbtooltip( {
			content: $( '<span>' ).text( text ),
			permanent: true,
			gravity: 'nw'
		} );
		var tip = $anchor.data( 'wbtooltip' );
		if ( tip ) { tip.show(); }
	}

	function hideTooltip( $anchor ) {
		var tip = $anchor.data( 'wbtooltip' );
		if ( tip ) { tip.hide(); }
	}

	function scan( $root ) {
		var sel = buildSelector();
		$root.find( sel ).each( function () {
			var $a = $( this );
			var id = extractId( $a.attr( 'href' ) );
			if ( id ) { bindHover( $a, id ); }
		} );
	}

	// Erst laden, dann binden – inklusive dynamischer Re-Renders
	mw.loader.using( [ 'mediawiki.api', 'jquery.wikibase.wbtooltip' ] ).then( function () {
		$( function () { scan( $( document ) ); } );
		mw.hook( 'wikipage.content' ).add( scan );
		// Zusätzlich: spezifische Wikibase-Hooks für Entity-UI
		if ( mw.hook && mw.hook( 'wikibase.entityPage.entityView.rendered' ) ) {
			mw.hook( 'wikibase.entityPage.entityView.rendered' ).add( function () { scan( $( document ) ); } );
		}
	} );

}( mediaWiki, jQuery ) );

Wesentliche Änderungen ggü. vorher:

  • Selektoren jetzt breit (*=) und inkl. /entity/ + Special:EntityPage/.
  • On-demand-Laden beim ersten Hover ⇒ Du siehst die wbgetentities-Anfrage im „Netzwerk“-Tab genau dann.
  • Tooltip direkt am Anchor ($a.wbtooltip(...)) – stabiler als ein externes span.

Erwartetes Verhalten

  1. Seite neu laden → noch kein Netz-Call.
  2. Über einen Q/P/L-Link hovern → 1 API-Call action=wbgetentities&ids=... (Status 200).
  3. Tooltip zeigt Beschreibung (falls vorhanden; mit languagefallback=1).
  4. Beim zweiten Hover derselben ID kommt kein Netz-Call mehr (Cache).

Zu wgPopupsGateway

Unabhängig davon (nur der Vollständigkeit halber): Das wgPopupsGateway ist nur für die Extension:Popups relevant (Page/Reference Previews; REST-Summary). Unser Gadget nutzt die Wikibase-API und wird davon nicht beeinflusst. Es ist also keine Voraussetzung, das zu ändern.

Wenn es danach immer noch keinen Netz-Call gibt,

gerne 1–2 konkrete HREFs (aus dem DOM kopiert) schicken. Dann passe ich den Matcher gezielt auf deine HTML-Ausgabe an.

Du:

Testergebnis aus Konsole: 

[Log] found – 1 – "links"
[Log] sample – ["https://wiki.aewi.de/entity/Q33"] (1)
< undefined

Auch das neue Coding ist ohne Änderung des Verhalten bei hoover.

ChatGPT:

Denke nach…

Überlegungen zur API und Content Security Policy

Es könnte sein, dass die Content Security Policy API-Aufrufe blockiert. Falls im Console-Log keine Netzwerkversuche angezeigt werden, könnte ein Minimalcode helfen, einen Abruf für den Link Q33 zu erzwingen und einen Tooltip bei Klick anzuzeigen. Zudem sollten wir auf Asynchronität achten, da Inhalte nachgeladen werden könnten.

Überlegungen zu Mouseenter und Event-Bindung

Es könnte sein, dass der 'mouseenter' Event nicht wie erwartet auslöst, weil er nicht von Kind-Elementen des Links weitergegeben wird. Auch wenn der Event an den Link gebunden ist, wird er möglicherweise an einem überlagerten Kind-Element ausgelöst. Zudem wird 'mouseenter' immer noch ausgelöst, wenn der Mauszeiger über den Linkbereich geht, unabhängig von den Kindern.

Überlegungen zur Popups-Erweiterung und Event-Registrierung

Es könnte sein, dass die Popups-Erweiterung den 'mouseenter' Event abfängt und andere Handler blockiert. Obwohl 'mouseenter' nicht gecancelt werden kann, könnten Konflikte bei der Ereignisregistrierung auftreten. Allerdings haben wir einen Guard mit $a.data('aewDescBound') hinzugefügt, was hilfreich ist. Aber es scheint nicht sehr wahrscheinlich, dass Konflikte auftreten.

Überlegungen zur Eventbindung und Tooltip-Plugins

Wir haben den Guard $a.data('aewDescBound') hinzugefügt. Vielleicht hat der Link bereits ein 'title'-Attribut, was den nativen Tooltip verzögert anzeigt. Unser Tooltip erscheint jedoch sofort bei 'mouseenter'. Ich schlage vor, Logging für Event-Bindings und das Auslösen von Events hinzuzufügen. Eventuell wechseln wir zu 'mouseover' als Fallback. Außerdem könnte die 'wbtooltip'-Plugin-Nutzung in Wikibase anders sein als erwartet, aber unsere Umsetzung könnte trotzdem in Ordnung sein.

Überlegungen zum event delegation und Tooltips

Wir haben 'permanent: true' verwendet und rufen den Tooltip über data('wbtooltip') ab, aber vielleicht sollten wir ein anderes Muster verwenden, um den Event-Handler für 'mouseenter' zu binden und den Tooltip anzuzeigen. Falls der Event-Handler nicht funktioniert, schlage ich vor, 'mouseover' zu verwenden. Außerdem füge ich Event-Delegation hinzu, um die Bindung zu sichern.

Überlegungen zur Fehlerbehebung und Codebereitstellung

Gemäß den Anweisungen sollen wir nur bei Bedarf nach Klarstellungen fragen. Hier können wir jedoch einen Debug-Snippet bereitstellen, den der Benutzer testen kann. Der Zeitstempel sollte nur einmal in der ersten Nachricht erscheinen, daher überspringen wir ihn hier. Ich werde dem Benutzer das notwendige Beispiel und die Schritte zur Fehlerbehebung liefern.

Überlegungen zur Fehlerbehebung und Codeverfeinerung

Es scheint, dass das Popups-Extension-Overlay (wie ‘Reference Preview’) die Zeigerposition blockiert, aber 'mouseover' triggert weiterhin am Anker. Die Eventdelegation sollte funktional bleiben, ohne mehrfaches Binden. Wir werden den Eventhandler so anpassen, dass er API-Aufrufe nur einmal ausführt und den Tooltip anzeigt, sobald die Antwort empfangen wird.

Optimizing tooltip display and debugging

We’ll call showTooltip only after the promise resolves for the hovered anchor, with other tooltips triggering later. Using mouseover ensures event bubbling. Caching the text with pending promises is needed. I’ll include a debug log toggle, enabling testing without too much spam. Additionally, we’ll suggest verifying event triggers by pasting a small console snippet and checking gadget activation in preferences. Consider popups and event propagation potential issues too.

Nachgedacht für 43s

Fertig

Danke für das klare Testergebnis — wir finden den Link (/entity/Q33), aber beim Hover passiert kein API-Call. Das heißt: unser Handler feuert nicht. Ursache sehr wahrscheinlich: ein anderes Skript (z. B. Popups) fängt das mouseover/mouseenter-Ereignis ab (Capture-Phase + stopPropagation). Lösung: event-delegiert im Capture-Moduslauschen und so vor anderen Listenern drankommen.

Hier ist eine robuste Drop-in-Version, die:

  • ohne Vorab-Scan arbeitet (Event-Delegation),
  • im Capture-Modus lauscht (kann nicht „weggestoppt“ werden),
  • /Item:Q…, /Property:P…, /Lexeme:L…, /entity/... und Special:EntityPage/... erkennt,
  • erst beim ersten Hover lädt (dann siehst du den wbgetentities-Call),
  • jquery.wikibase.wbtooltip nutzt.

Lass die Gadget-Definition unverändert, also Descriptions[ResourceLoader|dependencies=mediawiki.api,jquery.wikibase.wbtooltip|actions=view]|Descriptions.js

Ersetze den Inhalt von MediaWiki:Gadget-Descriptions.js vollständig durch:

/* Gadget: Descriptions – Wikibase-Beschreibung beim Hover (Q/P/L)
 * Abhängigkeiten: mediawiki.api, jquery.wikibase.wbtooltip
 * Arbeitet event-delegiert im Capture-Modus, damit kein anderes Skript (Popups etc.)
 * unsere Events „wegstoppen“ kann.
 */
( function ( mw, $ ) {
	'use strict';

	var cache = Object.create( null ); // id -> { text: string|false, pending: Promise|null }
	var userLang = mw.config.get( 'wgUserLanguage' );

	function extractId( href ) {
		var m = ( href || '' ).match( /(?:^|[/:])(Q\d+|P\d+|L\d+)(?:[^\d]|$)/ );
		return m ? m[ 1 ] : null;
	}

	function isEntityLink( a ) {
		if ( !a || a.nodeName !== 'A' ) { return false; }
		var h = a.getAttribute( 'href' ) || '';
		// schnelle Negativ-Filter
		if ( h.indexOf( '#' ) === 0 || h.indexOf( 'mailto:' ) === 0 || h.indexOf( 'javascript:' ) === 0 ) {
			return false;
		}
		// positiv: Item:/Property:/Lexeme:, /entity/, Special:EntityPage/
		return (
			/Item:(?:Q\d+)/.test( h ) ||
			/Property:(?:P\d+)/.test( h ) ||
			/Lexeme:(?:L\d+)/.test( h ) ||
			/\/entity\/[QPL]\d+/.test( h ) ||
			/Special:(?:EntityPage)\/[QPL]\d+/.test( h )
		);
	}

	function ensureDescription( id ) {
		if ( cache[ id ] ) {
			return cache[ id ].pending || Promise.resolve( cache[ id ].text || '' );
		}
		var api = new mw.Api( { userAgent: 'Gadget-Descriptions/local-2025-12-02' } );
		cache[ id ] = { text: '', pending: null };
		cache[ id ].pending = api.get( {
			action: 'wbgetentities',
			ids: id,
			props: 'descriptions',
			languages: userLang,
			languagefallback: 1
		} ).then( function ( data ) {
			var ents = ( data && data.entities ) || {};
			var e = ents[ id ];
			var d = e && e.descriptions && ( e.descriptions[ userLang ] || Object.values( e.descriptions )[ 0 ] );
			var text = d && d.value || '';
			cache[ id ].text = text || false;
			cache[ id ].pending = null;
			return text;
		}, function () {
			cache[ id ].text = false;
			cache[ id ].pending = null;
			return '';
		} );
		return cache[ id ].pending;
	}

	function showTooltip( a, text ) {
		var $a = $( a );
		$a.wbtooltip( {
			content: $( '<span>' ).text( text ),
			permanent: true,
			gravity: 'nw'
		} );
		var tip = $a.data( 'wbtooltip' );
		if ( tip ) { tip.show(); }
	}

	function hideTooltip( a ) {
		var tip = $( a ).data( 'wbtooltip' );
		if ( tip ) { tip.hide(); }
	}

	// --- Event Delegation im Capture-Modus ---
	// mouseover -> laden/anzeigen; mouseout -> verstecken
	document.addEventListener( 'mouseover', function ( ev ) {
		var a = ev.target && ( ev.target.closest ? ev.target.closest( 'a' ) : null );
		if ( !isEntityLink( a ) ) { return; }
		var id = extractId( a.getAttribute( 'href' ) );
		if ( !id ) { return; }

		// bereits im Cache?
		if ( cache[ id ] && cache[ id ].text ) {
			showTooltip( a, cache[ id ].text );
			return;
		}

		// ggf. laufende Anfrage wiederverwenden
		( cache[ id ] && cache[ id ].pending ? cache[ id ].pending : ensureDescription( id ) )
			.then( function ( text ) { if ( text ) { showTooltip( a, text ); } } );
	}, true ); // <-- capture

	document.addEventListener( 'mouseout', function ( ev ) {
		var a = ev.target && ( ev.target.closest ? ev.target.closest( 'a' ) : null );
		if ( !isEntityLink( a ) ) { return; }
		hideTooltip( a );
	}, true ); // <-- capture

}( mediaWiki, jQuery ) );

Kurzer Testplan (60 Sek.)

  1. Seite neu laden (Cache hart neu laden).
  2. In DevTools → Netzwerk offen lassen.
  3. Über deinen Link https://wiki.aewi.de/entity/Q33 hovern.
    • Erwartet: ein Call action=wbgetentities&ids=Q33 (200 OK).
    • Danach: Tooltip zeigt die Beschreibung (falls vorhanden; Fallbacks aktiv).
  4. Zweiter Hover auf Q33: kein weiterer Netz-Call (Cache).

Falls immer noch kein Netz-Call kommt

  • Kopiere bitte den genauen href eines betroffenen Links (Rechtsklick → Link-Adresse kopieren) und schicke ihn mir. Dann passe ich den Matcher exakt an dein DOM.
  • Prüfe in der Konsole:
    document.addEventListener('mouseover', e => {
  const a = e.target.closest && e.target.closest('a');
  if (a) { console.log('hovered:', a.getAttribute('href')); }
}, true);
    Wenn gar nichts geloggt wird, blockiert etwas das Event global (ungewöhnlich). Wenn geloggt wird, aber nur bei anderen Links, dann verpasst unser isEntityLink den Fall → ich erweitere ihn.

Hinweis zu wgPopupsGateway

Deine Beobachtung ist korrekt, aber nicht ursächlich für dieses Gadget. Das Gateway steuert die Extension:Popups(REST-Summary), nicht dieses Hover-Descriptions-Gadget. Wir umgehen Popups hier vollständig.

Melde dich kurz mit dem Ergebnis (Netzwerk-Call ja/nein und ob die Beschreibung erscheint). Dann mache ich bei Bedarf die RegEx/Erkennung noch schärfer oder ergänze Label-vor-Beschreibung + Dark-Theme-CSS.

Du:

Linkadresse vergleichsweise :https://wiki.aewi.de/Qwasi:Q32

Kann es sein, daß das Coding an der Benennung der Namensräume scheitert?

Ich würde ein allgemeineres auf NS Nummern gründendes Coding bevorzugen, da das Gadet dann für ein beliebiges Wikibase-System gültig bleibt, also auch Änderungen der Benennungen der Namensräume übersteht, Es ist ein Helper für Config einzufügen, in dem die Nummern der Namensräume anstelle deren Namen einzutragen sind – oder?

Wikibase hat Q 0, P 120 und L 146, ich habe Q 120, P 122 und L 146 eingestellt.

Prüfung in der Konsole: undefined

Weitere Prüfung in der Konsole :

new mw.Api().get({

  action:'wbgetentities', ids:'Q32', props:'descriptions|labels',

  languages: mw.config.get('wgUserLanguage'), languagefallback:1

}).then(resp => console.log('wbgetentities OK:', !!resp.entities && !!resp.entities.Q32, resp));

Ergebnis letzterer Prüfung in dr Konsole lautet:

< {state: function, always: function, catch: function, pipe: function, then: function, …}

[Log] wbgetentities OK: – true – {entities: Object, success: 1, debuginfo: Object}

{entities: Object, success: 1, debuginfo: Object}Object

ChatGPT:

Aktivität ·53s Denke nach…

Anpassung an Benutzeranweisung ohne Timestamp

Da es sich um einen fortlaufenden Chat handelt und die Anweisung nur für den ersten Chat gilt, werde ich auf den Timestamp verzichten. Die Links des Benutzers haben das Präfix "Qwasi" für eigene Namensräume, was darauf hinweist, dass sie auf eine angepasste Wikibase-Struktur hinweisen, in der die IDs verändert wurden.

Anpassung an benutzerdefinierte Wikibase-Struktur

Auf Wikidata befinden sich Items normalerweise nicht im Namensraum „main“, sondern eher unter "/entity/Q...". Die benutzerdefinierte Wikibase-Struktur des Benutzers verwendet Ns wie Q=120 (genannt "Qwasi") und P=122. Der Benutzer bevorzugt eine generische Lösung basierend auf Nummern statt Namen, aber das Parsing der URLs bleibt eine Herausforderung.

Überprüfung der neuen Parsing-Methode für Links

Ich denke, ich könnte die Parsing-Methode durch mw.Title optimieren und damit den Namespace aus dem Titel extrahieren. Für benutzerdefinierte Links wie „Qwasi:Q32“ kann ich mw.Title.newFromText verwenden, um den Namespace zu ermitteln. Eine bessere Lösung könnte jedoch die Verwendung von Datenattributen direkt beim Hovern über den Link sein.

Überprüfung der Namespace-Erkennung und API-Nutzung

Um den Namensraum zu ermitteln, kann ich mw.Title.newFromText verwenden und dann die Namespace-ID über die Methode getNamespaceId() abrufen. Es gibt eine Variante in der alten Version von MediaWiki, aber zur Sicherheit könnte ich auf das Attribut "namespace" zugreifen. Es ist sinnvoll, eine benutzerdefinierte Konfiguration hinzuzufügen.

Integration von benutzerdefinierten Variablen im Gadget

Ich plane, Variablen wie die Namensräume für Items, Properties und Lexeme in einer Konfigurationsdatei festzulegen und sie bei Bedarf über mw.config zu lesen. Dabei werde ich auf Standardwerte zurückgreifen, falls keine spezifischen Namen wie „Qwasi“ definiert sind, um Robustheit zu gewährleisten.

Vereinfachung der Verlinkungslogik

Um eine robustere Lösung zu entwickeln, werde ich ein Href auf ein Entity im gewünschten Format wie 'Qwasi:Q32' überprüfen. Ich setze eine regelmäßige Expression ein, um diese Muster als gültige Entitäten zu erkennen, und achte darauf, dass die Überprüfung auf das Namespace bzw. ID-Muster abgestimmt wird.

Analyzing popup issue and namespace matching

The user mentioned the popups aren't working as expected. Our event seems to not trigger the network call because mouseover didn't activate. I'll adjust isEntityLink to match namespaces like Qwasi:Q32. We'll define allowed namespaces in a configurable JSON on the site for easy editing.

Simplifying namespace matching

For this, I'll use a window variable to manage configuration in 'MediaWiki:Gadget-Descriptions.js'. The user can create a MediaWiki:Gadget-Descriptions-Config.js to map namespace IDs and pass them into the gadget. I’ll implement logic to parse titles and matches both for article paths and /entity/ links, using mw.Title. For unknown formats, I’ll map them using wgNamespaceIds.

Handling entity link detection and debugging

The isEntityLink function will check if the href matches entity patterns (like /entity/[QPL]\d+ or Special:EntityPage/[QPL]\d+). For internal links, we’ll extract IDs using regex and check if the namespace ID matches the user-configured ones (like Q=120, P=122, L=146). I'll add a debug flag and improve event handling, logging on match and hover actions.

Providing code and advising configuration details

I will provide the necessary code snippet without extra blocks. We need to advise the user to add a configuration file (MediaWiki:Gadget-Descriptions-config.js) to define namespaces, including nsItem, nsProperty, and nsLexeme. We'll also recommend adding mediawiki.Title as a dependency and explain configuring the DescriptionsDebug flag for troubleshooting. I'll provide instructions on event delegation and show the minimal testing commands for debugging in the console.

Nachgedacht für 53s

Fertig

Danke, das hilft. Deine Links wie https://wiki.aewi.de/Qwasi:Q32 verraten die Ursache: unsere bisherigen Selektoren waren (trotz Updates) noch namenbasiert und greifen an deinem umbenannten Item-Namensraum vorbei. Außerdem willst du es nummernbasiert (stabil bei Namensänderungen). Machen wir.

Ziel

  • Erkennen von Entity-Links (Q/P/L) unabhängig vom Namensraum-Namen.
  • Prüfung gegen Namensraum-Nummern (konfigurierbar).
  • Event-Delegation im Capture-Modus, damit uns keine anderen Skripte dazwischenfunken.
  • Laden der Beschreibung on-demand beim ersten Hover (dann siehst du den wbgetentities-Call im Netzwerk-Tab).

1) Gadget-Definition anpassen

In MediaWiki:Gadgets-definition die Gadget-Zeile ersetzen durch:

Descriptions[ResourceLoader|dependencies=mediawiki.api,jquery.wikibase.wbtooltip|actions=view]|Descriptions-config.js|Descriptions.js

Neu: Descriptions-config.js als eigene kleine Konfigurationsdatei.

2) Konfiguration nach Nummern

MediaWiki:Gadget-Descriptions-config.js (neu anlegen):

// Stelle hier die *Nummern* deiner Wikibase-Namespaces ein:
window.DescriptionsConfig = {
  nsItem: 120,     // dein Q-Namespace (z. B. "Qwasi")
  nsProperty: 122, // P
  nsLexeme: 146    // L
};
// Optional: Debug-Logs aktivieren
window.DescriptionsDebug = false;

Wenn du später Namen änderst, bleiben die Nummern stabil – das Gadget läuft weiter.

3) Gadget-Script (nummernbasiert + robust)

MediaWiki:Gadget-Descriptions.js komplett ersetzen:

/* Gadget: Descriptions – Wikibase-Beschreibung beim Hover (Q/P/L) – nummernbasiert
 * Abhängigkeiten: mediawiki.api, jquery.wikibase.wbtooltip
 * Delegiert Events im Capture-Modus; erkennt Links via ID (Q/P/L) + Namensraum-Nummern.
 */
( function ( mw, $ ) {
	'use strict';

	var CFG = window.DescriptionsConfig || { nsItem: 120, nsProperty: 122, nsLexeme: 146 };
	var DBG = !!window.DescriptionsDebug;
	var cache = Object.create( null ); // id -> { text: string|false, pending: Promise|null }
	var userLang = mw.config.get( 'wgUserLanguage' );
	var nsIds = mw.config.get( 'wgNamespaceIds' ) || {}; // { 'qwasi':120, 'property':122, ... }

	function log() { if ( DBG && window.console ) { console.log.apply( console, arguments ); } }

	function extractId( href ) {
		// …/Q123, …/P12, …/L7 – robust für /entity/, Special:EntityPage, und <NS>:Q123
		var m = ( href || '' ).match( /(?:^|[/:])(Q\d+|P\d+|L\d+)(?:[^\d]|$)/ );
		return m ? m[ 1 ] : null;
	}

	function titleFromHref( href ) {
		// Versuche, den *Seitentitel* aus einem internen Link zu gewinnen, um NS zu bestimmen
		try {
			var a = document.createElement( 'a' );
			a.href = href;
			// Externe Links ignorieren
			if ( a.host && a.host !== location.host ) { return null; }

			// 1) ?title=... (script path)
			var params = new URLSearchParams( a.search || '' );
			if ( params.has( 'title' ) ) {
				return decodeURIComponent( params.get( 'title' ) );
			}

			// 2) ArticlePath (/ $1 oder /wiki/$1)
			var base = ( mw.config.get( 'wgArticlePath' ) || '/$1' ).replace( '$1', '' );
			var path = a.pathname || '';
			if ( base && path.indexOf( base ) === 0 ) {
				return decodeURIComponent( path.slice( base.length ) );
			}

			// 3) Fallback: nichts
			return null;
		} catch ( e ) { return null; }
	}

	function nsIdFromTitle( titleText ) {
		// Nimmt den Teil vor dem ersten ":" und schlägt in wgNamespaceIds nach (nummernbasiert)
		if ( !titleText || titleText.indexOf( ':' ) < 0 ) { return 0; }
		var nsName = titleText.split( ':', 1 )[ 0 ].trim().toLowerCase().replace( / /g, '_' );
		return typeof nsIds[ nsName ] === 'number' ? nsIds[ nsName ] : null;
	}

	function isAllowedEntityLink( a ) {
		if ( !a || a.nodeName !== 'A' ) { return false; }
		var href = a.getAttribute( 'href' ) || '';
		// Schnelle Negativfilter
		if ( href.indexOf( '#' ) === 0 || /^mailto:|^javascript:/i.test( href ) ) {
			return false;
		}
		var id = extractId( href );
		if ( !id ) { return false; }

		// Wenn wir den Titel erkennen, prüfen wir *nummernbasiert* den NS
		var t = titleFromHref( href );
		if ( t ) {
			var ns = nsIdFromTitle( t );
			if ( ns === CFG.nsItem || ns === CFG.nsProperty || ns === CFG.nsLexeme ) {
				return { ok: true, id: id };
			}
			// Titel erkannt, aber NS nicht passend -> kein Entity-Link für uns
			return false;
		}

		// Kein Titel ermittelbar (z. B. /entity/Q123, Special:EntityPage/Q123):
		// Dann verlassen wir uns auf die ID – das ist in der Praxis korrekt für Wikibase-UI-Links.
		return { ok: true, id: id };
	}

	function ensureDescription( id ) {
		if ( cache[ id ] ) {
			return cache[ id ].pending || Promise.resolve( cache[ id ].text || '' );
		}
		var api = new mw.Api( { userAgent: 'Gadget-Descriptions/local-2025-12-02' } );
		cache[ id ] = { text: '', pending: null };
		cache[ id ].pending = api.get( {
			action: 'wbgetentities',
			ids: id,
			props: 'descriptions',
			languages: userLang,
			languagefallback: 1
		} ).then( function ( data ) {
			var ents = ( data && data.entities ) || {};
			var e = ents[ id ];
			var d = e && e.descriptions && ( e.descriptions[ userLang ] || Object.values( e.descriptions )[ 0 ] );
			var text = d && d.value || '';
			cache[ id ].text = text || false;
			cache[ id ].pending = null;
			log( '[Descriptions] loaded', id, '→', text );
			return text;
		}, function ( err ) {
			cache[ id ].text = false;
			cache[ id ].pending = null;
			log( '[Descriptions] api error', id, err );
			return '';
		} );
		return cache[ id ].pending;
	}

	function showTooltip( a, text ) {
		var $a = $( a );
		$a.wbtooltip( {
			content: $( '<span>' ).text( text ),
			permanent: true,
			gravity: 'nw'
		} );
		var tip = $a.data( 'wbtooltip' );
		if ( tip ) { tip.show(); }
	}

	function hideTooltip( a ) {
		var tip = $( a ).data( 'wbtooltip' );
		if ( tip ) { tip.hide(); }
	}

	// Event-Delegation in der *Capture*-Phase, damit andere Skripte uns nicht blockieren
	function handleOver( ev ) {
		var a = ev.target && ev.target.closest ? ev.target.closest( 'a' ) : null;
		var res = isAllowedEntityLink( a );
		if ( !res || !res.ok ) { return; }
		var id = res.id;

		// Cache direkt nutzen
		if ( cache[ id ] && cache[ id ].text ) {
			showTooltip( a, cache[ id ].text );
			return;
		}
		// ggf. laufende Anfrage anhängen, sonst neu anfordern
		( cache[ id ] && cache[ id ].pending ? cache[ id ].pending : ensureDescription( id ) )
			.then( function ( text ) { if ( text ) { showTooltip( a, text ); } } );
	}

	function handleOut( ev ) {
		var a = ev.target && ev.target.closest ? ev.target.closest( 'a' ) : null;
		if ( !a ) { return; }
		hideTooltip( a );
	}

	// Registrieren (mouseover/mouseout & pointerover/pointerout als Fallbacks)
	document.addEventListener( 'mouseover', handleOver, true );
	document.addEventListener( 'mouseout', handleOut, true );
	document.addEventListener( 'pointerover', handleOver, true );
	document.addEventListener( 'pointerout', handleOut, true );

	if ( DBG ) { log( '[Descriptions] ready. NS:', CFG ); }

}( mediaWiki, jQuery ) );
Wesentliches:
  • Nummernbasiert: Descriptions-config.js hält nsItem/nsProperty/nsLexeme.
  • Namensauflösung: Falls der Titel aus dem HREF extrahiert werden kann, ermitteln wir die NS-Nummer über wgNamespaceIds (damit funktionieren beliebige Namen wie Qwasi:).
  • Fallback: Wenn kein Titel ermittelbar ist (z. B. /entity/Q33), akzeptieren wir auf Basis der ID, weil das in der Praxis ein Wikibase-Entity-Link ist.
  • Capture-Modus + Delegation: Unser Listener feuert immer, selbst wenn andere Popups Listener registriert haben.

4) Test (kurz)

  1. Cache hart neu laden (⌘/Ctrl-Shift-R).
  2. DevTools Netzwerk offen.
  3. Über Qwasi:Q32 (oder /entity/Q33) hovern → Es sollte 1 Call action=wbgetentities&ids=Q… erscheinen.
  4. Tooltip zeigt die Beschreibung (falls vorhanden; Fallback via languagefallback=1).
  5. Zweiter Hover auf dieselbe ID → kein weiterer Netz-Call (Cache).
Debug optional

Setze temporär window.DescriptionsDebug = true; in der Konsole und lade neu – dann loggt das Gadget Treffer und API-Ladevorgänge.

Einordnung zu deiner Konsole

  • Dein manueller Test new mw.Api().get({ action:'wbgetentities', ids:'Q32', … }) ist OK → API-Seite funktioniert.
  • Dass bei Hover bislang kein Netz-Call kam, lag daran, dass unser Handler an deinem umbenannten NSvorbeischaute bzw. andere Listener zuerst griffen. Beides fangen wir jetzt ab.

Wenn danach noch kein Netz-Call auftaucht, poste mir bitte den exakten href eines betroffenen Links (so wie du ihn kopiert hast) und den Inhalt von mw.config.get('wgNamespaceIds') (Konsolen-Snippet: mw.config.get('wgNamespaceIds')). Dann passe ich die Titel-Erkennung exakt auf deine Map an.

Du:

Hurra!! – es funktioniert – hoover zeigt Beschreibung – in solchen Sachen bist du echt ein Coding-Genie.

Label wird ja im Feld angezeigt, wo ich hoover ausführe, Beschreibung erscheint, jedoch ohne ID – cool wäre nun noch zur Beschreibung vornan die jeweilige ID das P,Q oder L – oder?

ChatGPT:

Aktivität ·12s Denke nach…

Überlegen von Anpassungen für Tooltip-Text

Der Benutzer möchte, dass wir das ID-Präfix vor der Beschreibung im Tooltip anzeigen. Ich werde einen minimalen Code-Patch hinzufügen, der das Präfix (z. B. „Q123“) vor die Beschreibung setzt. Außerdem werde ich die Möglichkeit einbauen, entweder die ID oder den gesamten Text, einschließlich einer optionalen Bezeichnung, anzuzeigen.

Anpassungen für Tooltip-Anzeige und Beschreibung

Ich muss die Funktion "ensureDescription" so anpassen, dass sie ein Objekt mit ID und Text zurückgibt oder nur die ID an "showTooltip" übergibt, um sie voranzustellen. Das einfachste wäre, die Signatur von "showTooltip" zu ändern und den Code entsprechend anzupassen. Ich werde auch eine optionale Konfiguration einbauen.

Anpassen des Feature-Requests für den Tooltip

Der Benutzer hat nach einer Änderung gefragt, bei der die ID vor der Beschreibung angezeigt wird. Ich werde zwei Varianten vorschlagen: Option A, bei der die ID und die Beschreibung durch ein Non-Breaking Space verbunden sind, und Option B, bei der die ID in fetter Schrift auf der ersten Zeile steht. Beachte die minimalistische, präzise Umsetzung.

Implementierung der Tooltip-Anpassung

Ich werde den showTooltip-Code so anpassen, dass er auch die ID entgegennimmt und sie korrekt anzeigt. Dabei wird die ID immer angezeigt, selbst wenn keine Beschreibung vorhanden ist, was bedeutet, dass der Tooltip ohne Text, aber mit der ID angezeigt wird. Ich ändere die Bedingungen, um dies zu gewährleisten.

Nachgedacht für 12s

Fertig

herrlich! 🥳 Freut mich.

Hier ist die kleinste saubere Änderung, damit im Tooltip immer die ID (Q/P/L) vor der Beschreibung steht — und zwar auch dann, wenn mal keine Beschreibung vorhanden ist.

1) showTooltip erweitern (ID + Beschreibung)

In MediaWiki:Gadget-Descriptions.js diese Funktion ersetzen:

function showTooltip( a, id, text ) {
	var $a = $( a );
	var $content = $( '<span>' );
	$( '<strong>' ).text( id ).appendTo( $content );
	if ( text ) {
		$content.append( document.createTextNode( ' — ' + text ) );
	}
	$a.wbtooltip( {
		content: $content,
		permanent: true,
		gravity: 'nw'
	} );
	var tip = $a.data( 'wbtooltip' );
	if ( tip ) { tip.show(); }
}

(vorher hatte showTooltip nur (a, text) bekommen)

2) Aufrufe anpassen (ID mitgeben)

In demselben File, zwei Stellen im mouseover-Handler ändern:

  • Cache-Treffer:
    // alt: showTooltip( a, cache[id].text );
showTooltip( a, id, cache[id].text );
  • Nach dem API-Call:
    // alt: .then( function ( text ) { if ( text ) { showTooltip( a, text ); } } );
.then( function ( text ) { showTooltip( a, id, text || '' ); } );

Damit erscheint mindestens die ID; wenn eine Beschreibung existiert, folgt sie mit „ — Beschreibung“.

3) Optional: kleines CSS (bessere Lesbarkeit)

Falls du magst, lege MediaWiki:Gadget-Descriptions.css an und hänge es in der Gadget-Definition an (…|Descriptions-config.js|Descriptions.js|Descriptions.css). Inhalt z. B.:

/* ID etwas hervorheben */
.mw-wbtooltip-content strong { font-weight: 600; }

(Klasse kann je nach Wikibase-Version leicht variieren; notfalls .mw-wbtooltip im DOM inspizieren.)

Kurztest

  1. Seite hart neu laden.
  2. Über einen Link hovern → Netzwerktab zeigt wbgetentities&ids=… beim ersten Hover.
  3. Tooltip: Q… / P… / L… — Beschreibung (oder nur ID, wenn keine Beschreibung gepflegt ist).

Wenn du zusätzlich Label (erste Zeile) + ID — Beschreibung (zweite Zeile, kleiner) willst, sag kurz Bescheid — dafür gebe ich dir eine zweite, dezent formatierte Variante.

Du:

Funktioniert – nun habe ich mittels css eine bold ID der Bescchreibung vorangestellt.

Das erspart mir echt Arbeit in der Unterscheidung und Zuordnung von Q's, P's und L's.

Damit ist dieses Gadget deutlich besser, als das von Wikidata.

ChatGPT:

Aktivität ·11s Denke nach…

Abschließen und Optionen bieten

Die Nachricht des Nutzers ist positiv und zeigt, dass es funktioniert. Der Ton sollte ehrlich und präzise bleiben, ohne zu viel Zusatzkomplexität. Ich kann optional einige Verbesserungen vorschlagen, wie Sprachunterstützung oder per-Viewport-Link-Vorerwärmung. Ich werde keine Tools oder externe Abfragen verwenden.

Vorschläge zur Konfiguration und Verbesserung

Ich könnte vorschlagen, die Konfigurationsnummern an einem zentralen Ort zu speichern, was wir bereits getan haben. Vielleicht könnten wir ein Fallback für Deutsch hinzufügen, obwohl das bereits eingestellt ist. Optional könnten wir dann kleine Code-Änderungen vorschlagen, wie aria-labels für Barrierefreiheit oder eine bessere CSS-Klassenstruktur für Tooltips.

Optimierung der Tooltips und Popups

Wir könnten vorschlagen, unser Inhalt als <span> hinzuzufügen und CSS mit einem einzigartigen Attribut wie [data-desc-tooltip] oder einer speziellen Klasse zu setzen. Eine weitere Option ist, Aliase anzuzeigen, falls diese vorhanden sind. Ich sollte auch eine Liste mit optionalen Weiterentwicklungen beifügen und das Thema Popups im Auge behalten.

Nachgedacht für 11s

Fertig

großartig – freut mich, dass es sitzt und dir sofort Arbeit spart! 🎯

Wenn du magst, hier drei kleine Optionen für die Feinarbeit (alles unabhängig voneinander):

1) (Optional) Label zusätzlich anzeigen

Oben ID + Label, darunter die Beschreibung. Minimal-Patch:

  • In ensureDescription zusätzlich Labels holen:
    // alt: props: 'descriptions',
props: 'labels|descriptions',
  • ensureDescription am Ende statt return text;:
  • var lbl = e && e.labels && ( e.labels[userLang] || Object.values(e.labels)[0] );
return { id: id, label: (lbl && lbl.value) || '', desc: text };
    showTooltip auf ein Objekt umstellen:
    function showTooltip(a, payload) {
  var $a = $(a), $wrap = $('<span class="aew-desc-tip">');
  var line1 = (payload.id ? payload.id + (payload.label ? ' — ' + payload.label : '') : '');
  if (line1) $('<strong>').text(line1).appendTo($wrap);
  if (payload.desc) $('<div>').text(payload.desc).appendTo($wrap);
  $a.wbtooltip({ content: $wrap, permanent: true, gravity: 'nw' });
  var tip = $a.data('wbtooltip'); if (tip) tip.show();
}
  • Aufrufe anpassen:
    // Cache-Treffer:
showTooltip(a, { id: id, label: '', desc: cache[id].text || '' });

// Nach API:
.then(function (data) {
  // data jetzt {id,label,desc}
  showTooltip(a, data);
});

(Wenn du auch Aliase zeigen willst: props: 'labels|descriptions|aliases' und einen Alias in payload.aliasergänzen.)

2) (Optional) Tastatur-Zugänglichkeit

Auch per Tab/Enter usable: zusätzlich zu mouseover/-out die Focus-Events delegieren:

document.addEventListener('focusin', handleOver, true);
document.addEventListener('focusout', handleOut, true);

3) (Optional) sanftes Vorladen (nur Top-Links)

Erste 15–20 Entitäten im Viewport vorwärmen, damit der erste Hover sofort ist:

(function prefetchOnIdle(){
  if (!('requestIdleCallback' in window)) return;
  requestIdleCallback(function(){
    var seen = Object.create(null), ids = [];
    document.querySelectorAll('a[href]').forEach(function(a){
      var m = (a.getAttribute('href')||'').match(/(?:^|[/:])(Q\d+|P\d+|L\d+)(?:[^\d]|$)/);
      if (!m) return; var id = m[1];
      if (!seen[id]) { seen[id]=1; ids.push(id); }
    });
    ids.slice(0,20).forEach(function(id){ ensureDescription(id); });
  }, { timeout: 1500 });
})();

Wenn du noch eine kleine Dark-Mode-CSS für die Tooltip-Lesbarkeit willst,

sag kurz an; ich gebe dir 3–4 Zeilen, die zu deinem Vector-2022-Theme passen.

Du:

Dark-mode CSS wäre als erstes hilfreich, die weiteren Änderungen muß ich erst erwägen, ob wirklich nützlich und gebraucht?

Bitte wenn nur standard Vector kompatible CSS, Defults nutzen, keine CSS-Hook-Klasse in js, keine aewi klasse.

Es soll auch für andere Wikibase installationen funktionieren!

ChatGPT:

Denke nach…

Überlegungen zur CSS-Implementierung für Tooltips

Ich muss sicherstellen, dass ich das richtige CSS für die Tooltips von jquery.wikibase.wbtooltip bereitstelle, ohne benutzerdefinierte Klassen oder Änderungen am JS vorzunehmen. Ich erinnere mich, dass die Klassen möglicherweise 'wb-tooltip' oder 'wikibase-tooltip' sind, aber ich sollte sicherstellen, dass ich nicht zu viel rate und stattdessen sichere Selektoren verwende.

Durchsuchen des Webs nach wbtooltip DOM-Klassen

Nachforschen nach der wbtooltip-Klasse

Die Suche hat nicht direkt die Klassen angezeigt. Vielleicht hilft es, den Quellcode von jquery.wikibase.wbtooltip zu betrachten. Es wäre sinnvoll, nach dem Begriff "wbtooltip" im Wikibase-Code zu suchen, um zu sehen, wie die Klassen strukturiert sind.

Durchsuchen von Wikibase nach "wbtooltip"

Überlegungen zur CSS-Kompatibilität und Token-Integration

Die Suche hat keine Details zu den genauen Klassen ergeben. Aber viele Wikibase-Tooltips nutzen die generischen Klassen ‚wb-tooltip‘ oder ‚wbtooltip‘. Ich könnte CSS mit mehreren Selektoren wie div.wbtooltip, .wb-tooltip, .mw-wbtooltip schreiben, um die Kompatibilität zu erhöhen. Ich muss sicherstellen, dass ich dabei die richtigen Design-Token nach Vector-Standards verwende.

Verwendung von CSS-Variablen für Dark Mode

Ich sollte CSS-Variablen aus Vector-2022 wie --background-color-base, --color-base, --border-color-base verwenden und @media (prefers-color-scheme: dark) einbauen, um Dark Mode zu unterstützen. Der Nutzer bevorzugt minimal spezifische CSS-Variablen, ohne benutzerdefinierte Klassen. Ich muss den Tooltip-Container und den inneren Inhalt mit Variablen und Fallbacks für Dark Mode stylen.

CSS-Anpassungen für Tooltips und Klassen

Ich werde die Standard-Token verwenden, um den Tooltip zu stylen, z.B. Farben, Ränder und Schatten. Es scheint, dass der jQuery-Plugin-Tooltip wahrscheinlich mit den Klassen ‚wbtooltip‘ und ‚wbtooltip-content‘ erstellt wird. Um auf Nummer sicher zu gehen, kann ich auch den Attributselektor wie [class*="wbtooltip"] verwenden, um den Tooltip robuster zu stylen.

CSS-Vorschlag für Tooltips und Dunkelmodus

Ich schlage vor, den Tooltip-Container mit [class*="wbtooltip"] anzusprechen, um eine zu breite Auswahl zu vermeiden. Bei der Anpassung an den Dunkelmodus könnte ich --background-color-base für den Hintergrund und --color-base für den Text verwenden. Für eine sichere Wahl wäre jedoch --background-color-neutral-subtle als Hintergrund am besten geeignet.

CSS für Tooltip-Kompatibilität und Moduswechselfeatures

Ich schlage

Nachgedacht für 35s

Fertig

yes! freut mich. Hier ist eine kleine, Vector-kompatible Dark-/Light-CSS für das Tooltip der jquery.wikibase.wbtooltip – nur Standard-Tokens, keine Sonderklassen:

MediaWiki:Gadget-Descriptions.css

/* Basis: greift auf die gängigen wbtooltip-Container, ohne JS-Hooks */
.wbtooltip,
.wb-tooltip,
.mw-wbtooltip,
[class*="wbtooltip"] {
  /* Token-basierte Defaults mit Fallbacks für nicht-Codex-Skins */
  --_bg:     var(--background-color-base, #fff);
  --_fg:     var(--color-base, #202122);
  --_border: var(--border-color-base, #a2a9b1);
  --_shadow: var(--box-shadow-drop-medium, 0 2px 8px rgba(0,0,0,.15));
  --_radius: var(--border-radius-base, 4px);

  background-color: var(--_bg);
  color:            var(--_fg);
  border:           1px solid var(--_border);
  border-radius:    var(--_radius);
  box-shadow:       var(--_shadow);

  padding: 8px 10px;
  font-size: 0.875rem;     /* 14px */
  line-height: 1.45;
  max-width: 56ch;
  overflow-wrap: anywhere;
  z-index: 1100;           /* über Content, unter Modals */
}

/* Textakzent für die vorangestellte ID (dezent, token-basiert) */
.wbtooltip strong,
.wb-tooltip strong,
.mw-wbtooltip strong,
[class*="wbtooltip"] strong {
  color: var(--color-base--emphasized, inherit);
  font-weight: 600;
}

/* Dark Mode via prefers-color-scheme – nutzt weiterhin die Skin-Tokens */
@media (prefers-color-scheme: dark) {
  .wbtooltip,
  .wb-tooltip,
  .mw-wbtooltip,
  [class*="wbtooltip"] {
    --_bg:     var(--background-color-base, #202122);
    --_fg:     var(--color-base, #eaecf0);
    --_border: var(--border-color-base, #54595d);
    --_shadow: 0 6px 24px rgba(0,0,0,.6);
  }
}

Hinweise

  • Du hast die ID bereits fett – die Regel oben verstärkt nur die Lesbarkeit und bleibt token-konform.
  • Falls du die CSS noch nicht in der Gadget-Definition drin hast, hänge sie an: Descriptions[...|actions=view]|Descriptions-config.js|Descriptions.js|Descriptions.css
  • Keine Abhängigkeit zu AufEinWort-Klassen, funktioniert allgemein auf Wikibase-Repos mit Vector (hell/dunkel).

Du:

Schrift und Farbe des Hintergrund schalten nicht um, sind immer schwarze schrift auf weißem Hintergrund

ChatGPT:

Denke nach…

Untersuchung des Dark-Mode-Problems auf Vector-2022

Nikolaos hat erwähnt, dass die Dunkelmodus-Ansicht nicht funktioniert und der Text immer schwarz auf weiß bleibt. Das liegt möglicherweise daran, dass die CSS-Klassen oder Variablen von Vector-2022 nicht verwendet werden. Statt der prefers-color-scheme: dark-Methode könnten wir die skin-theme-clientpref-night-Klasse ansprechen, die von MediaWiki verwendet wird.

Untersuchen von Tooltip-Problemen im Dunkelmodus

Der Tooltip könnte weiße Farben behalten, weil die Fallback-Werte wie #fff gesetzt wurden und nicht von den CSS-Variablen überschrieben werden. Vielleicht liegt es daran, dass der Tooltip in einer separaten Schicht nicht von den globalen Variablen erbt. Ich denke, wir können die Farben durch Überprüfung der Body-Klasse überschreiben.

Anpassen der CSS für Tooltip im Dunkelmodus

Die Änderungen, die sie an der ID-Stilregel vorgenommen haben, funktionieren, aber der Hintergrund bleibt weiß. Das deutet darauf hin, dass die CSS-Variablen nicht definiert wurden. Ich sollte also explizite dunkle Farben einfügen, die an die skin-theme-clientpref-night-Klasse gebunden sind, um sicherzustellen, dass diese nicht durch andere Popup-CSS überschrieben werden.

Vorschlag für CSS-Anpassungen im Dunkelmodus

Die CSS-Regel könnte so angepasst werden, dass sowohl die @media (prefers-color-scheme: dark)-Abfrage als auch die .skin-theme-clientpref-night-Klasse genutzt werden. Ich schlage vor, .skin-theme-clientpref-night .wbtooltip zu verwenden und Notwendigkeit für !important-Markierungen bei Hintergrund- und Textfarben zu prüfen, um Popups zu überschreiben.

Vorschlag für aktualisierte CSS-Anpassungen

Um das Tooltip-Problem zu beheben, sollte die Verwendung von skin-theme-clientpref-night zusammen mit der @media (prefers-color-scheme: dark)-Regel den gewünschten Effekt haben. Wir müssen spezifische Farben und Stile für den Dunkelmodus definieren, Klasse für Klasse, und Notwendigkeit für !important-Markierungen prüfen. Ansonsten scheint keine zusätzliche Anpassung nötig.

Nachgedacht für 19s

Fertig

top! Dann schalten wir Dark/Light zuverlässig – ohne JS-Hooks, rein mit Standard-Vector-Selektoren. Der Punkt bei dir: Die Token-Variablen sind offenbar nicht gesetzt, daher greifen die Fallbacks (#fff/#202122). Wir gehen deshalb zweigleisig: Light als Basis, Dark explizit für Vectors Night-Klasse und für „OS folgt Dark“.

Ersetze den Inhalt deiner MediaWiki:Gadget-Descriptions.css durch:

/* —————————————————————
   Basis (Light) – gilt immer
   ————————————————————— */
.wbtooltip,
.wb-tooltip,
.mw-wbtooltip,
[class*="wbtooltip"] {
  background-color: #fff;
  color: #202122;
  border: 1px solid #a2a9b1;
  border-radius: 4px;
  box-shadow: 0 2px 8px rgba(0,0,0,.15);
  padding: 8px 10px;
  font-size: 0.875rem; /* ~14px */
  line-height: 1.45;
  max-width: 56ch;
  overflow-wrap: anywhere;
  z-index: 1100;
}

/* ID/Label dezent hervorheben */
.wbtooltip strong,
.wb-tooltip strong,
.mw-wbtooltip strong,
[class*="wbtooltip"] strong {
  font-weight: 600;
}

/* —————————————————————
   Dark Mode – Vector-Nachtpräferenz
   (setzt die Klasse am <html>-Element)
   ————————————————————— */
.skin-theme-clientpref-night .wbtooltip,
.skin-theme-clientpref-night .wb-tooltip,
.skin-theme-clientpref-night .mw-wbtooltip,
.skin-theme-clientpref-night [class*="wbtooltip"] {
  background-color: #202122 !important;
  color: #eaecf0 !important;
  border-color: #54595d !important;
  box-shadow: 0 6px 24px rgba(0,0,0,.6) !important;
}

/* Links im Tooltip (falls vorhanden) */
.skin-theme-clientpref-night .wbtooltip a,
.skin-theme-clientpref-night .wb-tooltip a,
.skin-theme-clientpref-night .mw-wbtooltip a,
.skin-theme-clientpref-night [class*="wbtooltip"] a {
  color: #a0d1ff !important;
}

/* —————————————————————
   Dark über OS-Einstellung („Benutze Systempräferenz“)
   (Vector setzt dann .skin-theme-clientpref-os – wir koppeln an prefers-color-scheme)
   ————————————————————— */
@media (prefers-color-scheme: dark) {
  .skin-theme-clientpref-os .wbtooltip,
  .skin-theme-clientpref-os .wb-tooltip,
  .skin-theme-clientpref-os .mw-wbtooltip,
  .skin-theme-clientpref-os [class*="wbtooltip"] {
    background-color: #202122 !important;
    color: #eaecf0 !important;
    border-color: #54595d !important;
    box-shadow: 0 6px 24px rgba(0,0,0,.6) !important;
  }
  .skin-theme-clientpref-os .wbtooltip a,
  .skin-theme-clientpref-os .wb-tooltip a,
  .skin-theme-clientpref-os .mw-wbtooltip a,
  .skin-theme-clientpref-os [class*="wbtooltip"] a {
    color: #a0d1ff !important;
  }
}

Kurz prüfen:

  1. Gadget-CSS ist in der Definition angehängt: …|Descriptions-config.js|Descriptions.js|Descriptions.css
  2. Seite hart neu laden.
  3. Wenn du in Vector „Dunkel“ oder „System (dunkel)“ aktiv hast, sollte der Tooltip sofort von weiß auf dunkelumspringen.

Wenn’s bei dir noch nicht reagiert, sag mir kurz, ob am <html> die Klasse skin-theme-clientpref-night bzw. skin-theme-clientpref-os steht – dann passe ich die Selektoren auf deine Skin-Version an.

Du:

funktioniert auch nicht siehe die aktiven Elementefunktioniert auch nicht siehe die aktiven Elemente - siehe Anhang.

ChatGPT:

Denke nach…

Erstellen eines robusten CSS für Tooltipps

Ich schlage vor, eine solide Basis für das CSS zu entwickeln, um die Stilgestaltung für .wikibase-wbtooltip-tip .tipsy-inner mit Hintergrund und Farbe sowie die Pfeil-Stile zu definieren. Das Inline-Styling betrifft lediglich Position und Sichtbarkeit – die Farbwerte sollten von unserem CSS übernommen werden, mit bevorzugter Spezifität.

Vereinfachte CSS für Tipsy-Pfeilrichtungen

Ich werde die Hintergrund- und Randfarben von .wikibase-wbtooltip-tip .tipsy-inner setzen und für die Pfeile die border-top-color von .wikibase-wbtooltip-tip .tipsy-arrow entsprechend anpassen. Ich berücksichtige auch die acht möglichen Ausrichtungen und füge ein Tag für den Tages-/Nachtmodus hinzu, wobei der Standard auf Tagesmodus eingestellt ist. Kein Token, nur Klassennamen.

Finales CSS für Tooltipps und Pfeile

Ich werde das CSS für .wikibase-wbtooltip-tip .tipsy-inner festlegen, mit einem weißen Hintergrund, einer definierten Randfarbe und zusätzlichen Stileigenschaften wie Box-Schatten und Polsterung. Die Pfeilfarben werden durch direkte Hex-Codes gesetzt, ohne Token zu verwenden. Zusätzliche Anpassungen für unterschiedliche Ausrichtungen der Pfeile werden ebenfalls berücksichtigt.

Finales CSS für Pfeil- und Hintergrundanpassungen

Wir können sowohl Borderrand- als auch Hintergrundfarben anpassen und mit !important sicherstellen, dass sie stärker als die Standardeinstellungen wirken. Für den Pfeil verwenden wir .tipsy-arrow:after zur Füllung, aber auch die filter: drop-shadow-Methode ist eine Alternative. Wir geben präzise CSS-Codes sowie einfache Verifikationstipps, wie das Überprü

Nachgedacht für 21s

Fertig

(2. Dez. 2025, 18:33)

Guter Fund: Dein Tooltip-DOM ist div.tipsy-nw.wikibase-wbtooltip-tip > .tipsy-arrow + .tipsy-inner. Unsere bisherigen Selektoren griffen deshalb nicht. Nimm diese Vector-kompatible CSS—ohne Projekthooks, nur die realen Klassen von jquery.wikibase.wbtooltip und Vector-Dark-Schaltern:

MediaWiki:Gadget-Descriptions.css

Prüfcheck

  1. Gadget-Definition enthält nun auch die CSS:
    /* Basis (hell) */
.wikibase-wbtooltip-tip .tipsy-inner {
  background: #fff !important;
  color: #202122 !important;
  border: 1px solid #a2a9b1 !important;
  border-radius: 4px !important;
  box-shadow: 0 2px 8px rgba(0,0,0,.15) !important;
  padding: 8px 10px !important;
  max-width: 56ch;
  line-height: 1.45;
  font-size: 0.875rem; /* ~14px */
}
.wikibase-wbtooltip-tip { z-index: 1100 !important; }
.wikibase-wbtooltip-tip .tipsy-inner strong { font-weight: 600; }

/* Pfeil (hell) – alle Lagen abdecken */
.wikibase-wbtooltip-tip.tipsy-n  .tipsy-arrow,
.wikibase-wbtooltip-tip.tipsy-ne .tipsy-arrow,
.wikibase-wbtooltip-tip.tipsy-nw .tipsy-arrow { border-top-color: #a2a9b1 !important; }
.wikibase-wbtooltip-tip.tipsy-s  .tipsy-arrow,
.wikibase-wbtooltip-tip.tipsy-se .tipsy-arrow,
.wikibase-wbtooltip-tip.tipsy-sw .tipsy-arrow { border-bottom-color: #a2a9b1 !important; }
.wikibase-wbtooltip-tip.tipsy-e  .tipsy-arrow { border-right-color: #a2a9b1 !important; }
.wikibase-wbtooltip-tip.tipsy-w  .tipsy-arrow { border-left-color:  #a2a9b1 !important; }

/* Dark: Vector-Schalter per Klasse */
.skin-theme-clientpref-night .wikibase-wbtooltip-tip .tipsy-inner {
  background: #202122 !important;
  color: #eaecf0 !important;
  border-color: #54595d !important;
  box-shadow: 0 6px 24px rgba(0,0,0,.6) !important;
}
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-n  .tipsy-arrow,
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-ne .tipsy-arrow,
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-nw .tipsy-arrow { border-top-color: #54595d !important; }
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-s  .tipsy-arrow,
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-se .tipsy-arrow,
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-sw .tipsy-arrow { border-bottom-color: #54595d !important; }
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-e  .tipsy-arrow { border-right-color: #54595d !important; }
.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-w  .tipsy-arrow { border-left-color:  #54595d !important; }

/* Dark über Systempräferenz (wenn Vector auf „System“ steht) */
@media (prefers-color-scheme: dark) {
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip .tipsy-inner {
    background: #202122 !important;
    color: #eaecf0 !important;
    border-color: #54595d !important;
    box-shadow: 0 6px 24px rgba(0,0,0,.6) !important;
  }
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-n  .tipsy-arrow,
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-ne .tipsy-arrow,
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-nw .tipsy-arrow { border-top-color: #54595d !important; }
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-s  .tipsy-arrow,
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-se .tipsy-arrow,
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-sw .tipsy-arrow { border-bottom-color: #54595d !important; }
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-e  .tipsy-arrow { border-right-color: #54595d !important; }
  .skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-w  .tipsy-arrow { border-left-color:  #54595d !important; }
}
    …|Descriptions-config.js|Descriptions.js|Descriptions.css
  2. Seite hart neu laden (Cache umgehen).
  3. In Dark-Mode schalten (Vector: „Dunkel“ oder „System“ auf dunkel).
  4. Im DOM auf dem Tooltip .wikibase-wbtooltip-tip .tipsy-inner → „Computed Styles“ sollten die dunklen Farben zeigen.

Wenn Vector bei dir andere Dark-Klassen setzt, sag kurz, welche Klassen html trägt (z. B. skin-theme-clientpref-night / skin-theme-clientpref-os). Dann passe ich die Selektoren genau daran an.

Du:

Error: Expected LBRACE at line 51, col 1.

Du versucht die Farbanpassung durch !important zu erzwingen – muß das sein?

ChatGPT:

stimmt – der Fehler kommt von der CSS (bei dir fehlte effektiv eine Block-Klammer) und nein, !important ist hier nicht nötig. Nimm diese Version – sie zielt exakt auf das real erzeugte Markup

div.tipsy-*/div.wikibase-wbtooltip-tip > .tipsy-inner und schaltet per Vector-Dark-Klassen um, ohne!important.

MediaWiki:Gadget-Descriptions.css (ersetzen)

/* Basis (hell) */
.skin-vector .wikibase-wbtooltip-tip .tipsy-inner {
  background: #fff;
  color: #202122;
  border: 1px solid #a2a9b1;
  border-radius: 4px;
  box-shadow: 0 2px 8px rgba(0,0,0,.15);
  padding: 8px 10px;
  font-size: 0.875rem; /* ~14px */
  line-height: 1.45;
  max-width: 56ch;
  overflow-wrap: anywhere;
}
.skin-vector .wikibase-wbtooltip-tip { z-index: 1100; }
.skin-vector .wikibase-wbtooltip-tip .tipsy-inner strong { font-weight: 600; }

/* Pfeil (hell) */
.skin-vector .wikibase-wbtooltip-tip.tipsy-n  .tipsy-arrow,
.skin-vector .wikibase-wbtooltip-tip.tipsy-ne .tipsy-arrow,
.skin-vector .wikibase-wbtooltip-tip.tipsy-nw .tipsy-arrow { border-top-color: #a2a9b1; }
.skin-vector .wikibase-wbtooltip-tip.tipsy-s  .tipsy-arrow,
.skin-vector .wikibase-wbtooltip-tip.tipsy-se .tipsy-arrow,
.skin-vector .wikibase-wbtooltip-tip.tipsy-sw .tipsy-arrow { border-bottom-color: #a2a9b1; }
.skin-vector .wikibase-wbtooltip-tip.tipsy-e  .tipsy-arrow { border-right-color: #a2a9b1; }
.skin-vector .wikibase-wbtooltip-tip.tipsy-w  .tipsy-arrow { border-left-color:  #a2a9b1; }

/* Dark: explizit per Vector-Nachtklasse am <html> */
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip .tipsy-inner {
  background: #202122;
  color: #eaecf0;
  border-color: #54595d;
  box-shadow: 0 6px 24px rgba(0,0,0,.6);
}
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-n  .tipsy-arrow,
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-ne .tipsy-arrow,
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-nw .tipsy-arrow { border-top-color: #54595d; }
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-s  .tipsy-arrow,
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-se .tipsy-arrow,
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-sw .tipsy-arrow { border-bottom-color: #54595d; }
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-e  .tipsy-arrow { border-right-color: #54595d; }
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip.tipsy-w  .tipsy-arrow { border-left-color:  #54595d; }

/* Dark über Systempräferenz (Vector: „System“) */
@media (prefers-color-scheme: dark) {
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip .tipsy-inner {
    background: #202122;
    color: #eaecf0;
    border-color: #54595d;
    box-shadow: 0 6px 24px rgba(0,0,0,.6);
  }
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-n  .tipsy-arrow,
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-ne .tipsy-arrow,
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-nw .tipsy-arrow { border-top-color: #54595d; }
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-s  .tipsy-arrow,
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-se .tipsy-arrow,
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-sw .tipsy-arrow { border-bottom-color: #54595d; }
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-e  .tipsy-arrow { border-right-color: #54595d; }
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip.tipsy-w  .tipsy-arrow { border-left-color:  #54595d; }
}

Warum jetzt ohne !important?

  • Wir erhöhen nur die Spezifität (.skin-vector .wikibase-wbtooltip-tip … und html.skin-theme-clientpref-* …), dadurch überstimmen wir die Standard-Tipsy/Wikibase-Regeln sauber in der Cascade.
  • Deine Inline-Styles betreffen nur Position/Visibility/Opacity, nicht Farben – also kein Konflikt.

Kurz checken

  1. Gadget-Definition enthält die CSS-Datei am Ende: …|Descriptions-config.js|Descriptions.js|Descriptions.css
  2. Seite hart neu laden.
  3. In Dark-Mode (Vector: „Dunkel“ oder „System“+OS dunkel) sollte der Tooltip umschalten. Falls nicht: schau am <html> nach, ob skin-theme-clientpref-night bzw. skin-theme-clientpref-os gesetzt ist. Wenn dein Vector eine andere Klasse nutzt, sag kurz welche – dann passe ich die Selektoren an.

Du:

ein riesen Aufwand an CSS für diese an sich kleinen Änderungen – oder? Wie dem auch sei – die neue CSS funktioniert für beide Modi und ist besser – die CSS von zuvor hatte sich auf die gesamte Wikiseite ausgewirkt.

ChatGPT:

Denke nach…

Überlegungen zu CSS und Vereinfachung

Ich denke, es ist wichtig, den Erfolg anzuerkennen und zu erklären, warum CSS manchmal lang wird. Eine Möglichkeit, das zu vereinfachen, ist die Reduzierung von Wiederholungen durch Gruppierung von Selektoren oder die Verwendung von CSS-Variablen für Farbschemata. Die neuen Funktionen wie 'color-scheme' oder 'light-dark()' könnten helfen, aber die Unterstützung ist noch nicht auf allen Browsern vorhanden.

Vereinfachung von CSS und Vorschläge

Ich könnte einen Ansatz empfehlen, bei dem nur "@media (prefers-color-scheme: dark)" verwendet wird, um sich auf den dunklen Modus zu konzentrieren, ohne die Vector-Klassen zu verwenden. Zudem könnten CSS-Variablen innerhalb von Bereichen helfen, Wiederholungen zu vermeiden. Eine klare, kompakte Version könnte mit :is() realisiert werden, um Selektoren zu vereinheitlichen.

CSS-Variant und Erläuterung

Da wir uns im gleichen Chat befinden, ist kein Timestamp notwendig. In Bezug auf das CSS: Wir haben eine minimalistische Version erstellt und erkläre, dass die Verwendung von !important entfernt wurde. Ein früheres Problem mit der Verwendung eines generischen Klassennamens [class*="wbtooltip"] wurde behoben, indem wir auf .wikibase-wbtooltip-tip eingedampft haben, um globale Effekte zu verhindern.

Minimalistische CSS-Version

Um den CSS-Code zu optimieren, kann man zunächst für die .skin-vector .wikibase-wbtooltip-tip .tipsy-inner-Klasse Farbvariablen definieren, die dann je nach Farbmodus angepasst werden. Das sorgt für Flexibilität und Reduzierung von Wiederholungen. Die Pfeilfarbe kann ebenfalls durch border-color gesteuert werden, wobei Transparenz als Standardwert verwendet wird.

Nachgedacht für 16s

Fertig

stimmt – der Block war lang, weil wir alle Tipsy-/Vector-Sonderfälle explizit abgesichert haben. Jetzt, wo klar ist, welche Klassen dein Tooltip wirklich hat, können wir’s kompakt halten und sauber kapseln (ohne Seiteneffekt auf den Rest der Seite).

Hier ist eine kurze, robuste Version mit CSS-Variablen und ohne !important. Sie wirkt nur auf das Tooltip-Markup von jquery.wikibase.wbtooltip:

MediaWiki:Gadget-Descriptions.css (kompakt)

/* Basis-Variablen nur für Wikibase-Tooltip kapseln */
.skin-vector .wikibase-wbtooltip-tip {
  --tt-bg: #fff;
  --tt-fg: #202122;
  --tt-bd: #a2a9b1;
  --tt-shadow: 0 2px 8px rgba(0,0,0,.15);
}

/* Tooltip-Kästchen */
.skin-vector .wikibase-wbtooltip-tip .tipsy-inner {
  background: var(--tt-bg);
  color: var(--tt-fg);
  border: 1px solid var(--tt-bd);
  border-radius: 4px;
  box-shadow: var(--tt-shadow);
  padding: 8px 10px;
  font-size: 0.875rem;
  line-height: 1.45;
  max-width: 56ch;
  overflow-wrap: anywhere;
}
.skin-vector .wikibase-wbtooltip-tip .tipsy-inner strong { font-weight: 600; }
.skin-vector .wikibase-wbtooltip-tip { z-index: 1100; }

/* Pfeil färben (Tipsy nutzt jeweils nur eine Seite) */
.skin-vector .wikibase-wbtooltip-tip .tipsy-arrow {
  border-top-color:    var(--tt-bd);
  border-right-color:  var(--tt-bd);
  border-bottom-color: var(--tt-bd);
  border-left-color:   var(--tt-bd);
}

/* Vector: Nutzer hat explizit „Dunkel“ gewählt */
html.skin-theme-clientpref-night .wikibase-wbtooltip-tip {
  --tt-bg: #202122;
  --tt-fg: #eaecf0;
  --tt-bd: #54595d;
  --tt-shadow: 0 6px 24px rgba(0,0,0,.6);
}

/* Vector: „System“ + OS dunkel */
@media (prefers-color-scheme: dark) {
  html.skin-theme-clientpref-os .wikibase-wbtooltip-tip {
    --tt-bg: #202122;
    --tt-fg: #eaecf0;
    --tt-bd: #54595d;
    --tt-shadow: 0 6px 24px rgba(0,0,0,.6);
  }
}

Warum das kurz bleibt & keine Seiteneffekte erzeugt:

  • Scope nur auf .wikibase-wbtooltip-tip …, also ausschließlich das Tooltip.
  • Umschalten per Vector-Klassen am <html>; prefers-color-scheme deckt den „System“-Fall ab.
  • Variablen vermeiden Dopplungen; keine !important nötig.

Schnelltest: hart neu laden → Hover → Farbe passt. Schalte in Vector auf „Dunkel“/„System“ um → Tooltip wechselt mit.

Wenn du später noch Label (oben) + ID — Beschreibung (unten) möchtest, sag Bescheid; das lässt sich mit 2–3 Codezeilen sauber ergänzen.

Du:

Gebe mir bitte eine Kurzbeschreibung der Änderungen des Gadget von Wikidata zu dem neuen Coding von dir. Was ist der Unterschied von alt zu neu?

ChatGPT:

Denke nach…

Zusammenfassung der Änderungen im Wikidata-Tool

Die wesentlichen Änderungen umfassen nun die Erkennung von Links basierend auf Namespace-Nummern, URL-Mustererkennung und Ereignisverarbeitung zur Vermeidung von Störungen. Es gibt auch Lazy Fetching beim ersten Hover-Ereignis, Cache pro ID und explizite Ressourcenabhängigkeiten. Die Robustheit hinsichtlich Artikelpfade sowie Sprachunterstützung und barrierefreies Design zum Erweitern werden ebenfalls berücksichtigt.

Zusätzliche CSS-Verbesserungen und Funktionen

Es gab CSS-Optimierungen: Der Tooltip-Themenbereich wurde auf den Tooltip-Bereich selbst beschränkt, und Dark Mode wird in Vector unterstützt, ohne dass globale Seiteneffekte auftreten. Es gibt jetzt eine optionale Konfigurationsdatei für Namespace-IDs und Portabilität. Außerdem wurde die Unterstützung für Lexem (L) explizit hinzugefügt, und das Tooltip zeigt nun sowohl ID als auch Beschreibung an.

Erklärungen zu Änderungen und Verbesserungen

Es gibt nun eine On-Demand-API-Aufruf pro Hover, der die Seiten-Caching verbessert, im Gegensatz zur vorherigen Batch-Vorabladung pro Seite. Dies reduzierte den Hintergrundverkehr und macht Netzwerkaufrufe sichtbarer. Die neue Lösung unterstützt flexible Link-Formate, eine

Nachgedacht für 10s

Fertig

klar und knapp – Unterschiede Wikidata-Gadget (alt) → dein neues Gadget (neu):

  1. Erkennung der Links
  • Alt: Namensbasiert (z. B. Item:Q…, Property:P…, meist mit /wiki/); Sonderfälle wie /entity/Q…, Special:EntityPage/Q…, absolute URLs oder umbenannte Namespaces oft nicht erfasst.
  • Neu: ID-basiert + pfad-robust: erkennt Q/P/L in allen üblichen Formen (…Item:Q…, …/entity/Q…, …Special:EntityPage/Q…, relativ/absolut, /wiki/$1 und /$1).
  1. Portabilität über Namespace-NUMMERN
  • Alt: Kopplung an Namen der Wikibase-Namespaces (bricht bei umbenannten NS wie „Qwasi:“).
  • Neu: Descriptions-config.js mit nsItem/nsProperty/nsLexeme (Zahlen). Damit bleibt es stabil, wenn die Namen geändert werden.
  1. Ereignisbehandlung
  • Alt: Klassischer jQuery-Scan + Hover-Binding; kann von anderen Hover-Skripten (z. B. Popups) „überfahren“ werden.
  • Neu: Event-Delegation im Capture-Modus (mouseover/mouseout, optional pointerover/-out). Dadurch greifen wir zuverlässig, auch wenn andere Skripte stopPropagation einsetzen.
  1. Ladeverhalten & Netzwerk
  • Alt: Teilweise Vorab-Scan/Batching; abhängig vom Codepfad.
  • Neu: On-Demand: Erst beim ersten Hover wird wbgetentities für die konkrete ID geholt; anschließend Seiten-Cache pro ID → keine doppelten Calls.
  1. Abhängigkeiten (RL)
  • Alt: Verließ sich auf globale Verfügbarkeit; jquery.wikibase.wbtooltip nicht immer explizit geladen.
  • Neu: Explizite ResourceLoader-Dependencies: mediawiki.api und jquery.wikibase.wbtooltip.
  1. Inhalt des Tooltips
  • Alt: Primär Beschreibung (je nach Variante/Code-Stand).
  • Neu: ID voran (Q/P/L-Nummer) + Beschreibung; Format leicht anpassbar (Label optional möglich).
  1. Sprache/Fallback
  • Alt: je nach Implementierung.
  • Neu: languages = wgUserLanguage + languagefallback=1 (zeigt sinnvolle Beschreibung, wenn die Benutzer-Sprache fehlt).
  1. CSS / Dark-Mode
  • Alt: Styles abhängig von Umgebung; teilweise kein Dark-Switch.
  • Neu: Scope nur auf Tooltip-DOM (.wikibase-wbtooltip-tip …), Vector-kompatible Dark/Light-Umschaltung über skin-theme-clientpref-night/…-os; kompakt, ohne Seiteneffekt auf restliche Seite.
  1. Artikelpfad-Unabhängigkeit
  • Alt: häufig auf /wiki/ fixiert.
  • Neu: funktioniert mit /$1 und /wiki/$1 sowie Script-Pfad-Links (?title=…).

Kurzfazit: Das neue Gadget ist namen-unabhängig, nummern-konfigurierbar, ereignis-robust, pfad-agnostisch und zeigt ID + Beschreibung; Netzlast nur bei Bedarf. Wenn du später Label/Zeilenlayout willst, bauen wir das gezielt drauf.

Du:

Super – ich habe dies so bei Wikidata der Diskussionsseite zum Gadget hinzugefügt. Ich habe keine Edit-Rechte für die bearbeitung deren Gadget's – vielleicht nimmt jemand dies an und verbessert deren Gadget. Keine weiteren Hinweise oder Anregungen hierzu – wir wenden uns nun einem anderen Thema zu. Danke für deine Unterstützung in dieser Sache.

ChatGPT:

Sehr gut, freut mich. 👍

Verstanden: keine weiteren Hinweise zu diesem Gadget.

Womit machen wir weiter — welches Thema willst du als Nächstes angehen?

Du:

Das erfährst du im nächsten Chat ;-)

ChatGPT:

Alles klar 😊

Dann bis gleich im nächsten Chat. Ich bin startklar.

Abgerufen von „https://aufeinwort.info/w/index.php?title=Gespräch:Erstellung_MediaWIki:Gadget-Descriptions_für_Wikibase_Vorschau&oldid=150526“