Gespräch:Wikibase-MediaWiki-Brücke II

Über diese Seite Gespräch

Wikibase Sitelinks Recherche
Ausarbeitung
ChatGPT Sophos GPT-5.1 Thinking
11. Dezember 2025 n. Chr. erst.
13:25 Uhr Ausgabe 02
Ausgabe 02
unüberarbeitet ungeprüft
↑ Wikibase SiteLink für P's und Q's
↓ Wikibase-MediaWiki-Semantic MediaWiki-Brücke

Du:

Mittels Wikibase-Sitelink für Q' und WikibaseLink für P's und L' s haben wir hiermit sozusagen eine fast vollständige MediaWiki-Wikibase-Bridge geschaffen – oder?

Wie muß nun eine praktische Vorlage:WikibaseLink aussehen?

Derzeit habe ich folgendes:

<!-- Vorlage:WikibaseLink -->
<includeonly>
{{#invoke:WikibaseLink
 |linkAndShortdesc
 |entity={{{1|}}}
 |mode={{{mode|auto}}}
 |shortdesc={{{shortdesc|ja}}}
 |label={{{label|}}}
}}
</includeonly>
<noinclude>
Verwendung:

* {{WikibaseLink|Q6}}              → Link zu Q6, Q-Seite: keine SHORTDESC
* {{WikibaseLink|P31}}             → Link zu P31 + SHORTDESC aus P-Beschreibung
* {{WikibaseLink|L2}}              → Link zu L2 + SHORTDESC aus Wortart des Lexems
* {{WikibaseLink|L2|shortdesc=nein}} → nur Link, keine SHORTDESC
* {{WikibaseLink|L2|mode=L}}       → explizit als Lexem behandeln
<templatedata>
{
	"params": {
		"1": {},
		"mode": {
			"label": "Mode",
			"suggestedvalues": [
				"L",
				"P",
				"Q"
			]
		},
		"shortdesc": {
			"label": "Beschreibung"
		},
		"label": {
			"label": "Benennung (Label)"
		}
	},
	"format": "inline"
}
</templatedata></noinclude>

An sich wollte ich ja mit wiki-page-name für L's, P's und Q's für deren Auswahl arbeiten. Also müßte L, P, Q jeweils einen Namespace als Prefix setzen oder ich muß die Namespacnamen Lexeme, Pass und Quasi als Prefix zur Auswahl eingeben – oder? Wie ich die Vorlage umgestaltet habe funktioniert nicht wirklich – wie muß diese nun aussehen?

ChatGPT:

(11. Dez. 2025, 19:xx)

Denke nach…

Verstehen der Vorlage und Namensraumwahl
Es scheint, dass sie über eine Brücke zwischen MediaWiki und Wikibase sprechen, die fast vollständig ist, und sie möchten über wiki-page-name-Ansätze für die Auswahl von Entitäten arbeiten. Wenn sie "Lexeme:L2", "Property:P31", "Item:Q6" als Seiten-Namen eingeben wollen, dann müssen Namespace-Präfixe verwendet werden!
Überprüfung der Vorlage und Änderung der Parameter
Es scheint, dass das Template nun Q6, P31, L2 erwartet, aber sie wollen möglicherweise {{WikibaseLink|Lexeme:L2}} verwenden, damit das ID automatisch extrahiert wird. Der shortdesc-Parameter wurde entfernt, aber das Template übergibt ihn noch, was keine Auswirkungen hat. Diese Änderungen haben das Template angepasst, aber ich muss sicherstellen, dass sie eine funktionelle Version erhalten.
Überprüfung der Template-Anpassung und Namensraumbehandlung
Das Template hat immer noch den shortdesc-Parameter, obwohl er keine Funktion mehr hat, aber das ist in Ordnung. Die größere Herausforderung: Sie möchten die Angabe durch Seitennamen ermöglichen. Ein Designvorschlag wäre, dass der Parameter 1 entweder „Q6“, „P31“, „L2“ oder „Item:Q6“, „Property:P31“, „Lexeme:L2“ erlaubt. Damit müssen wir Lua anpassen, um nach „:“ in den Parametern zu suchen, aber die Änderungen am Template müssen mit Vorsicht vorgenommen werden.
Anpassung der Vorlage für Namensräume und ID-Erfassung
Die Idee ist ja gut, aber wir sollten es einfach halten. Wenn der Benutzer sagt, dass sie den Namespace als Präfix verwenden müssen, könnten wir den TemplateData-Parameter auf „wiki-page-name“ setzen und einen vorgeschlagenen Namespace angeben. Das stellt sicher, dass beim Bearbeiten sie Seiten aus diesem Namespace erhalten – und die Umwandlung bleibt einfach.
Template-Logik und fallback-Funktion
Die Idee ist, den Parameter zu verarbeiten, je nachdem, ob ein Doppelpunkt enthalten ist. Wenn nicht, soll der ursprüngliche Wert verwendet werden. Für die visuelle Bearbeitung (VE) würde der "wiki-page-name"-Typ und eine Namensraum-Liste vorgeschlagen. Dabei sollten wir sicherstellen, dass der shortdesc-Parameter nicht mehr verwendet wird, da dieser jetzt über den #invoke-Mechanismus gesetzt wird.
Designing shortdesc functionality in Template:WikibaseLink
I need to tweak the template so that both the link label and the search subtitle (shortdesc) are handled automatically. By default, we'll show both, but the option to disable the shortdesc with a shortdesc=nein parameter will be included. This keeps things simple, allowing the user to control which part of the output they get.
Updating Template: WikibaseLink for simplicity
I propose merging Template:WikibaseLink with Template:Kurzbeschreibung. This will simplify things by removing the need for the latter. Key changes include supporting param 1 as a page name, calling #invoke:WikibaseLink|shortdesc unless shortdesc=nein, and handling namespaces in TemplateData. We’ll also clarify how to bridge items via Sitelink/DescriptionLookup and ShortDESC for P/L.
Designing simplified Template:WikibaseLink
We should avoid unnecessary module changes for now, focusing on Template:WikibaseLink. By using #titleparts, we can map param 1 to an entity ID. We also plan to set up conditionals for shortdesc behavior. If it's "nein," we'll skip shortdesc; otherwise, it will be included automatically.
Nachgedacht für 1m 30s
Fertig

Ja, so wie du es jetzt gebaut hast, hast du faktisch eine Bridge in beide Richtungen:

Q-Items: über echten Wikibase-Sitelink → Seitenbeschreibung in der Suche via DescriptionLookup / SearchResultProvideDescription.
P/L (Properties & Lexeme): über Modul:WikibaseLink + SHORTDESC → Such-Untertitel und sichtbarer Link im gewünschten Muster.

Das ist für dein Setup sehr nah an einer „MediaWiki–Wikibase-Bridge“, ohne dass du tief in Wikibase selbst patchen musst.

1. Was deine aktuelle Vorlage tut – und wo sie hakt

Deine Version:

<includeonly>
{{#invoke:WikibaseLink
 |linkAndShortdesc
 |entity={{{1|}}}
 |mode={{{mode|auto}}}
 |shortdesc={{{shortdesc|ja}}}
 |label={{{label|}}}
}}
</includeonly>

Probleme dabei:

linkAndShortdesc im Modul hat keinen Parameter shortdesc mehr – der wird ignoriert. Die Entscheidung, ob SHORTDESC gesetzt wird, triffst du derzeit gar nicht; du rufst p.shortdesc nicht auf.
{{{1}}} wird direkt als entity durchgereicht.
- Gibst du Q6, P31, L2 ein → passt.
- Gibst du Lexeme:L2 oder Property:P31 als wiki-page-name ein → passt nicht, weil das Modul IDs im Format ^[QPL]\d+$ erwartet.

Du willst aber:

in der Template-Auswahl / im VisualEditor Seiten aus den Namespaces Lexeme:, Property:, Item: o. ä. auswählen,
und intern soll trotzdem nur Q6, P31, L2 beim Modul ankommen,
außerdem soll die Vorlage automatisch SHORTDESC setzen (Such-Untertitel), sofern nicht explizit abgeschaltet.

2. ID aus wiki-page-name ziehen (mit `#titleparts`)

Typische Beispiele, die an Param 1 reinkommen könnten:

L2
Lexeme:L2
P31
Property:P31
Q6
Item:Q6 (oder wie dein Item-Namensraum heißt)

Wir wollen:

Wenn ein Doppelpunkt drin ist, nimm den Teil nach dem Doppelpunkt, sonst nimm den vollen Wert.

Mit Standard-Parserfunktionen geht das so:

{{#if:{{#titleparts:{{{1|}}}|2}}
 |{{#titleparts:{{{1|}}}|2}}  <!-- es gibt einen zweiten Teil: Namespace:Titel → nimm Titel -->
 |{{{1|}}}                   <!-- kein Doppelpunkt → nimm 1 direkt -->
}}

Das werden wir zweimal benutzen: einmal für shortdesc, einmal für linkAndShortdesc.

3. Praktische `Vorlage:WikibaseLink` (Vorschlag)

Hier eine Variante, die:

automatisch SHORTDESC setzt (über #invoke:…|shortdesc),
im sichtbaren Teil nur den Link ausgibt (über linkAndShortdesc),
als Eingabe ID oder wiki-page-name erlaubt,

shortdesc=nein erlaubt, um das Setzen der Kurzbeschreibung abzuschalten.

<!-- Vorlage:WikibaseLink -->
<includeonly>
<!-- interne Hilfskonstruktion: Entity-ID aus Param 1 ableiten -->
<!-- Wenn 1 einen Namespace enthält (Lexeme:L2), nimm Teil 2 (L2), sonst 1 -->
{{#ifeq:{{{shortdesc|ja}}}|nein|
  <!-- keine Kurzbeschreibung setzen -->
  |
  {{#invoke:WikibaseLink
    |shortdesc
    |entity={{#if:{{#titleparts:{{{1|}}}|2}}
              |{{#titleparts:{{{1|}}}|2}}
              |{{{1|}}}
             }}
    |mode={{{mode|auto}}}
  }}
}}

{{#invoke:WikibaseLink
  |linkAndShortdesc
  |entity={{#if:{{#titleparts:{{{1|}}}|2}}
            |{{#titleparts:{{{1|}}}|2}}
            |{{{1|}}}
           }}
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}
</includeonly>
<noinclude>
Verwendung (Wikitext):

* {{WikibaseLink|Q6}}
* {{WikibaseLink|P31}}
* {{WikibaseLink|L2}}
* {{WikibaseLink|Lexeme:L2}}       – ID wird automatisch zu „L2“
* {{WikibaseLink|Property:P31}}    – ID wird automatisch zu „P31“
* {{WikibaseLink|L2|shortdesc=nein}} – nur sichtbarer Link, keine Kurzbeschreibung
* {{WikibaseLink|L2|mode=L}}       – explizit Lexem-Logik (Kurzbeschreibung = Wortart)

<templatedata>
{
  "params": {
    "1": {
      "label": "Wikibase-Entität",
      "description": "Q-ID, P-ID oder L-ID (z.B. Q6, P31, L2) oder der Seitentitel in einem Wikibase-Namensraum (z.B. Lexeme:L2, Property:P31, Item:Q6).",
      "required": true
    },
    "mode": {
      "label": "Modus (Q/P/L/auto)",
      "description": "Steuert die Art der Kurzbeschreibung: auto (Standard), Q, P, L.",
      "type": "string",
      "suggestedvalues": ["auto", "Q", "P", "L"],
      "default": "auto"
    },
    "shortdesc": {
      "label": "Kurzbeschreibung (Such-Untertitel) setzen",
      "description": "Leer/ja = Kurzbeschreibung setzen; „nein“ = keine Kurzbeschreibung (nur sichtbarer Link).",
      "type": "string"
    },
    "label": {
      "label": "Benennung (Linktext)",
      "description": "Optionaler eigener Linktext. Wenn leer, werden ID/Label/Lemma aus Wikibase verwendet.",
      "type": "string"
    }
  },
  "format": "inline"
}
</templatedata>
</noinclude>

Was diese Vorlage effektiv macht

Für einen Aufruf wie:

{{WikibaseLink|Lexeme:L2}}

wird intern:

Kurzbeschreibung:
```
{{#invoke:WikibaseLink
  |shortdesc
  |entity=L2
  |mode=auto
}}
```
→ Modul ruft SHORTDESC-Parserfunktion mit „Wortewort“ auf (oder was auch immer L2 als Wortart hat) → Such-Untertitel.
Sichtbarer Link:
```
{{#invoke:WikibaseLink
  |linkAndShortdesc
  |entity=L2
  |mode=auto
}}
```
→ Modul liefert: [[Special:EntityPage/L2|L2 Dingwort (Wortewort)]].

Für {{WikibaseLink|P31}} analog mit P-Beschreibung.

Für {{WikibaseLink|Q6}}:

shortdesc produziert nichts, weil buildShortdescText für Q nil liefert,
linkAndShortdesc liefert nur das Q-Label (z. B. „Dingwort“) – die Q-Beschreibung kommt ja schon aus der Sitelink-Brücke.

4. Zu deiner Frage „wiki-page-name für L/P/Q zur Auswahl arbeiten“

Ja, genau:

In Wikitext reicht es, wenn du 1 als either L2 oder Lexeme:L2 schreiben kannst → das haben wir mit #titlepartsabgedeckt.
Im VisualEditor kannst du im TemplateData für Param 1 den Typ z. B. auf "type": "wiki-page-name" setzen und in der Oberfläche Namespaces vorschlagen (das hängt von deinem VE-Setup ab; oft reicht schon wiki-page-name, um Autocomplete von Seitennamen zu bekommen).

Du musst keine neuen Namespaces erfinden – du nutzt schlicht die, die du schon hast (Lexeme, Property, Item/Quasi/etc.) und lässt das Template die ID extrahieren.

Wenn du willst, können wir im nächsten Schritt noch eine kleine Spezial-Vorlage für Wortseiten bauen (z. B. Vorlage:Wort-Lexem), die automatisch:

das passende L (über Seitentitel oder explizit) findet,
die ShortDesc setzt,
WikibaseLink anzeigt,
und ggf. gleich noch ein paar weitere Lexem-Daten (Sprache, Formen, etc.) mit ausgibt.

Du:

Modul Wikibase Link (arbeitsfassung)

Danke für den Entwurf der Vorlage. Folgende Syntax in einer Wikiseite bringen keine Ergebnisse/Anzeige:

1) {{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}

2) {{WikibaseLink|Lexeme:L2}}

3) {{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}

Wo liegt mein Fehler – oder fehlt noch etwas in Modul:WikibaseLink?

ChatGPT

(11. Dez. 2025, 19:xx)

Denke nach…
Überprüfen des Template-Problems
Es scheint, dass der Benutzer die Vorlage noch nicht entsprechend meiner späteren Vorschläge angepasst hat. Der Parameter "shortdesc" wird übergeben, aber vom Modul "linkAndShortdesc" nicht berücksichtigt. Das sollte zwar keinen kompletten Mangel an Ausgaben verursachen, aber die vorgeschlagene Veränderung könnte den Fehler erklären. Ich werde die Vorlage erneut überprüfen.
Überprüfung der Syntax des Template-Aufrufs
Der Benutzer hat einen Syntaxfehler in der Template-Aufrufstruktur. Der Parameter labelL ist nicht korrekt (es sollte label sein), und L2 wird als unerklärter Parameter übergeben, obwohl es eine benannte Angabe braucht. Es fehlt außerdem der erste Parameter 1. Ich werde die richtige Reihenfolge und Benennung der Parameter sicherstellen, um das Problem zu beheben.
Analyzing template parameter structure
Okay, in dieser Vorlage wird der erste Parameter L2 korrekt als "1" übergeben, und "mode" sowie "shortdesc" sind ebenfalls korrekt. Nur "label" wird nicht festgelegt, da "labelL" verwendet wurde. Die Argumente scheinen richtig erfasst zu werden, mit "entity", "mode", "shortdesc" und "label".
Überprüfung der neuen Template-Version
Es scheint ein Problem mit der neuen Version der Vorlage zu geben. Der Benutzer hat sie auf der Basis meiner späteren Vorschläge geändert, wobei diese Version komplexer ist und #ifeq sowie verschachtelte #invoke verwendet. Möglicherweise funktioniert dies nicht wie erwartet, weshalb der Benutzer keine Ausgabe erhält. Ich werde die neue Vorlage genauer prüfen.
Überprüfung des neuen Template-Codes
Die neue Vorlage enthält nun komplexere Logik mit #ifeq und verschachtelten #invoke-Aufrufen. Beim ersten Test mit shortdesc = ja wird der entsprechende #invoke für shortdesc korrekt ausgeführt, jedoch liefert sie keine sichtbare Ausgabe. Es scheint, dass detectEntityId auf "nil" zurückkehrt, obwohl "L2" übergeben wird, was merkwürdig ist. Ich werde das weiter untersuchen.
Überprüfung der Shortsdesc-Funktion
Es scheint, dass das Problem darin liegt, dass das Template möglicherweise nicht aktualisiert wurde und daher noch die ursprüngliche Version verwendet wird. Aber auch die shortdesc-Funktion scheint nicht mehr zu funktionieren, vielleicht aufgrund einer falschen Verwendung des callParserFunction. Möglicherweise gibt es eine Registrierung von SHORTDESC als magisches Wort oder als Parser-Funktion, die noch nicht korrekt umgesetzt wurde. Ich werde die Dokumentation dazu überprüfen.
Debugging Template:WikibaseLink and module output issues
Untersuchen der ShortDescription-Dokumentation
Die Dokumentation zeigt, dass ShortDescription die magischen Wörter SHORTDESC und GETSHORTDESC definiert, die wie Funktionsaufrufe behandelt werden. Es könnte jedoch eine Diskrepanz zwischen den Erwartungen und der Realität geben, da der callParserFunction korrekt aufgerufen wird, aber keine Anzeige erscheint. Das scheint beabsichtigt, da der Code so konzipiert ist, dass der #invoke shortdesc keine Ausgabe liefert.
Klären der Nutzungserwartungen
Es scheint, dass der Nutzer erwartet, dass die Kurzbeschreibung gesetzt wird, auch wenn keine Anzeige sichtbar ist. Ihre Aussage über "keine Ergebnisse/Anzeige" deutet darauf hin, dass das Verhalten korrekt ist. Es scheint, als ob die Installation des Patches gemäß ihren früheren Bestätigungen funktioniert hat, aber Nutzung und Missverständnisse müssen noch geklärt werden.
Überprüfung der Template-Nutzung
Es scheint einige Unterschiede in den Parametern zu geben: Sie verwenden labelL, aber das Template erwartet label. Auch wurde die Bedeutung des Parameters shortdesc im Vergleich zur früheren Version geändert, was zu Problemen führen könnte. Ein weitere mögliche Quelle des Problems könnte sein, dass das Template nicht auf die neueste Version aktualisiert wurde.
Überprüfung der Template-Nutzung und Fehlerbehebung
Wenn das Template noch die ältere Version verwendet, müsste der erste Aufruf mit shortdesc=ja normalerweise funktionieren, obwohl labelL nicht genutzt wird. Die zweite könnte wegen der fehlenden Entität als leeres Ergebnis erscheinen. Wenn der erste Aufruf auch nichts zurückgibt, könnte es an einem Tippfehler oder Update-Fehler liegen.
Erklärung zur Verwendung von WikibaseLink und Fehlerbehebung
Die Syntax 1) und 2) sollten in der neuen Template-Version gleichermaßen funktionieren und einen sichtbaren Link anzeigen, unter der Bedingung, dass der Parameter „labelL“ durch „label“ ersetzt wird. Bei der 3) Aufruf erwarteten wir keine Anzeige, da dies beabsichtigt ist und lediglich das Setzen der Beschreibung erfolgt.
Bereitstellung der richtigen Template:WikibaseLink-Nutzung
Wir bieten ihnen die bereinigte Version von Template:WikibaseLink mit den richtigen Anweisungen. Sie können das einfügen und wir vertrauen darauf, dass 2) funktioniert. Für 1) empfehle ich eine einfachere Syntax. Wir sollten auch erklären, dass labelL im Template falsch ist und ignoriert wird.
Erklärung zu "bringt keine Anzeige"
Der Benutzer erwartet möglicherweise, dass shortdesc nicht nur die Suchbeschreibung setzt, sondern auch im Tagline (#siteSub) angezeigt wird. Das passiert normalerweise, aber es wirkt sich hauptsächlich auf die Metadaten. Wir sollten den Benutzer darauf hinweisen, dass 3) keine Anzeige im Seiteninhalt erzeugt, nur in den Metadaten.
Antwort zur MediaWiki-Wikibase-Bridge und Syntaxkorrekturen
Ja, die Verwendung von Wikibase-Sitelink und WikibaseLink ist eine solide Brücke auf Suchebene. Es sollte ein einfacheres Format wie {{WikibaseLink|L2|mode=L}} verwendet werden, um Klarheit zu schaffen. Außerdem sollten sie action=info, die Suche und API zur Verifizierung einsetzen, um zu überprüfen, ob die Verbindung funktioniert.
Nachgedacht für 2m 25s
Fertig

Wir trennen sauber:

Modul: laut aktuellem Stand im Canvas verhält sich konsistent.
Vorlage + Aufruf: da liegen die Unstimmigkeiten.
shortdesc: macht jetzt absichtlich keine sichtbare Ausgabe.

Ich gehe deine drei Fälle durch.

0. Erinnerung: Was das Modul aktuell tut

linkAndShortdesc → gibt nur einen Link aus, z. B. [[Special:EntityPage/L2|L2 Dingwort (Wortewort)]].
shortdesc → ruft nur die Parserfunktion SHORTDESC auf:
```
frame:callParserFunction('SHORTDESC', text)
```
und gibt typischerweise '' zurück. Kein sichtbarer Text, aber die ShortDescription-Extension setzt den Seitentitel-Untertitel und die Suchbeschreibung.

1) `{{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}`

Was MediaWiki daraus macht

Parameterzuordnung in der Vorlage:

mode = L
labelL = L2 ← in der Vorlage nicht definiert
1 = L2
shortdesc = ja
label = (leer)

Wenn deine Vorlage so aussieht wie mein Vorschlag mit #titleparts:

{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink|shortdesc|entity=…|mode={{{mode|auto}}}}}
}}

{{#invoke:WikibaseLink|linkAndShortdesc|entity=…|mode={{{mode|auto}}}|label={{{label|}}}}

passiert:

{{{shortdesc|ja}}} → ja ≠ nein → #invoke … shortdesc wird ausgeführt.
entity → {{{1}}} → L2.
mode → L.
shortdesc-Aufruf: setzt ShortDescription, zeigt nichts an.
linkAndShortdesc-Aufruf: entity=L2, mode=L, label leer → gibt Link L2 Dingwort (Wortewort) aus.

Ergebnis:

Wenn du gar nichts siehst, dann liegt der Fehler nicht im Modul, sondern:

entweder ist Vorlage:WikibaseLink nicht exakt so gespeichert (z. B. <includeonly>-Block anders, Tippfehler im Modulnamen, usw.),
oder du testest im Namespace Vorlage: und schaust versehentlich auf die falsche Seite.

Inhaltlich ist der Aufruf so unnötig kompliziert. Sinnvoll wäre:

{{WikibaseLink|L2|mode=L}}

oder mit Label:

{{WikibaseLink|L2|mode=L|label=Dingwort}}

labelL ist einfach nur ein Tippfehler – die Vorlage kennt nur label.

2) `{{WikibaseLink|Lexeme:L2}}`

Hier trennt sich alte von neuer Vorlagenfassung:

In deiner alten Vorlage (nur entity={{{1}}}) kommt beim Modul entity=Lexeme:L2 an.
Das Modul akzeptiert nur IDs im Muster ^[QPL]\d+$. Lexeme:L2 fällt durch → detectEntityId gibt nil → linkAndShortdesc liefert ''.

Das erklärt exakt: keine Ausgabe.

Damit Variante 2 funktioniert, muss Vorlage:WikibaseLink wirklich so aussehen (Include-Teil):

<includeonly>
{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink
    |shortdesc
    |entity={{#if:{{#titleparts:{{{1|}}}|2}}
              |{{#titleparts:{{{1|}}}|2}}
              |{{{1|}}}
             }}
    |mode={{{mode|auto}}}
  }}
}}

{{#invoke:WikibaseLink
  |linkAndShortdesc
  |entity={{#if:{{#titleparts:{{{1|}}}|2}}
            |{{#titleparts:{{{1|}}}|2}}
            |{{{1|}}}
           }}
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}
</includeonly>

Dann gilt:

{{WikibaseLink|Lexeme:L2}} → {{#titleparts:Lexeme:L2|2}} → L2 → Modul bekommt entity=L2 → Link + Kurzbeschreibung.

Wenn du diese #titleparts-Logik noch nicht drin hast, ist genau das der Grund, warum Lexeme:L2 nicht funktioniert.

3) `{{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}`

Hier ist kein Fehler:

Das Modul setzt intern SHORTDESC über frame:callParserFunction('SHORTDESC', text).
Der Rückgabewert ist in der Regel ''.
Also: keine sichtbare Ausgabe auf der Seite – genau so gedacht.

Die Wirkung siehst du hier:

&action=info auf der Seite → dort sollte unter „Kurzbeschreibung“ der Text erscheinen.
{{GETSHORTDESC:}} testweise im Wikitext → sollte „Wortewort“ liefern.
Im Suchfeld → nach kurzer Cache/Index-Verzögerung erscheint der Such-Untertitel.

Wenn du dort nichts siehst, wäre ShortDescription selbst das Thema.

Wenn du dort etwas siehst, aber im Artikelkörper nicht: alles wie geplant.

Kurzfassung „Fehler oder Modul?“

Modul: verhält sich konsistent. #invoke … shortdesc soll nichts anzeigen.
Vorlage:
- Lexeme:L2 funktioniert nur, wenn du den #titleparts-Block wirklich eingebaut hast.
- labelL ist ein Tippfehler; die Vorlage kennt label.
- Der Aufruf {{WikibaseLink|L2|mode=L}} ist der saubere Weg.

Wenn du möchtest, kannst du mir einmal den genauen Include-Teil von Vorlage:WikibaseLink schicken (oder kurz beschreiben, ob der #titleparts-Block schon drin ist). Dann kann ich dir eine minimal bereinigte Version liefern, die garantiert:

{{WikibaseLink|L2}}
{{WikibaseLink|Lexeme:L2}}
{{WikibaseLink|P31}}
{{WikibaseLink|Property:P31}}

alle korrekt auf Q/P/L abbildet und gleichzeitig die Kurzbeschreibung setzt.

Modul Wikibase Link (arbeitsfassung)

Du:

Folgendes ist der Status.

Folgende Syntax hat keine Ergebnisse:

1. {{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}

2. {{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}

3. {{WikibaseLink|L2|mode=L}}

4. {{WikibaseLink|L2|mode=L|label=Dingwort}}

5. {{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}

Nur folgende Syntax funktioniert mit dem aktuellen Coding von Modul:WikibaseLink: {{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}}

Vorlage:WikibaseLink hat folgenden Stand:

<!-- Vorlage:WikibaseLink -->
<includeonly>
{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink
    |shortdesc
    |entity={{#if:{{#titleparts:{{{1|}}}|2}}
              |{{#titleparts:{{{1|}}}|2}}
              |{{{1|}}}
             }}
    |mode={{{mode|auto}}}
  }}
}}

{{#invoke:WikibaseLink
  |linkAndShortdesc
  |entity={{#if:{{#titleparts:{{{1|}}}|2}}
            |{{#titleparts:{{{1|}}}|2}}
            |{{{1|}}}
           }}
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}
</includeonly>

<noinclude>
Verwendung (Wikitext):

* {{WikibaseLink|Q6}}
* {{WikibaseLink|P31}}
* {{WikibaseLink|L2}}
* {{WikibaseLink|Lexeme:L2}}       – ID wird automatisch zu „L2“
* {{WikibaseLink|Property:P31}}    – ID wird automatisch zu „P31“
* {{WikibaseLink|L2|shortdesc=nein}} – nur sichtbarer Link, keine Kurzbeschreibung
* {{WikibaseLink|L2|mode=L}}       – explizit Lexem-Logik (Kurzbeschreibung = Wortart)

<templatedata>
{
	"params": {
		"1": {
			"label": "Wikibase-Entität",
			"description": "Q-ID, P-ID oder L-ID (z.B. Q6, P31, L2) oder der Seitentitel in einem Wikibase-Namensraum (z.B. Lexeme:L2, Property:P31, Item:Q6).",
			"required": true,
			"type": "wiki-page-name"
		},
		"mode": {
			"label": "Modus (Q/P/L/auto)",
			"description": "Steuert die Art der Kurzbeschreibung: auto (Standard), Q, P, L.",
			"type": "string",
			"suggestedvalues": [
				"auto",
				"Q",
				"P",
				"L"
			],
			"default": "auto"
		},
		"shortdesc": {
			"label": "Kurzbeschreibung (Such-Untertitel) setzen",
			"description": "Leer/ja = Kurzbeschreibung setzen; „nein“ = keine Kurzbeschreibung (nur sichtbarer Link).",
			"type": "line",
			"suggestedvalues": [
				"ja",
				"nein"
			],
			"autovalue": "ja"
		},
		"label": {
			"label": "Benennung (Linktext)",
			"description": "Optionaler eigener Linktext. Wenn leer, werden ID/Label/Lemma aus Wikibase verwendet.",
			"type": "line"
		}
	},
	"format": "inline"
}
</templatedata>
</noinclude>

Was läuft hier warum schief?

ChatGPT:

(11. Dez. 2025, 20:xx)

Denke nach…

Erklären der Funktionsweise des Codes
Die Änderung, die dazu führte, dass p.shortdesc jetzt keine sichtbare Ausgabe produziert, wurde absichtlich vorgenommen – es setzt jedoch immer noch den shortdesc hinter den Kulissen. Die Meldung „keine Ergebnisse“ wurde ggf. missverstanden, weil nur die Anzeige angepasst wurde. Das Problem mit den fehlenden Links deutet auf eine unrichtige Parameterzuweisung im Template hin.
Prüfung des Templates und möglicher Fehlerursachen
Ich überprüfe das Template und seine Funktionsweise. Wenn shortdesc nicht explizit angegeben ist, wird der Standardwert „ja“ verwendet, und der Block mit der #invoke-Anweisung für shortdesc wird ausgeführt. Wenn der Benutzer nichts sieht, könnte es daran liegen, dass das Template auf einer falschen Seite getestet wurde, wie etwa in der Template-Namensraum-Seite.
Überprüfung der Template-Nutzung und möglicher Fehlerquellen
Es scheint, dass das Template normalerweise auf einer normalen Seite verwendet werden sollte. Wenn direkt auf der Template-Seite getestet wird, könnte das durch <includeonly> nicht angezeigt werden. Wahrscheinlich gibt es Verwirrung über den richtigen Platz für die Verwendung. Außerdem war die Parametrierung beim ersten Fehler falsch angeordnet.
Problem bei Parametern und Template-Nutzung
Die benannten Parameter im Template sind in einer anderen Reihenfolge, als es für die Positionsparameter üblich ist. Doch das funktioniert trotzdem, weil der erste Parameter als Entity-ID genutzt wird. Der zusätzliche labelL-Parameter wird ignoriert, daher sollte Verhalten 2 genauso wie 3 ausfallen.
Untersuchen der Fehlerursache bei Template-Verwendung und Parameterübergabe
Es könnte ein Problem mit der Übergabe der Parameter im Template und #invoke geben. Bei direkter Verwendung von #invoke klappt alles, doch im Template könnte durch die Art der Übergabe etwas schiefgehen. Besonders die Funktionsnamen und Parameterreihenfolge sollten bei der Bearbeitung von frame.args berücksichtigt werden.
Beispielhafte Untersuchung der #invoke-Problemursache
Es scheint, dass bei der Template-Verwendung statt der direkten #invoke-Abfrage möglicherweise eine Namensraum-Diskrepanz vorliegt. Wo in der Template-Abfrage "Module:WikibaseLink" genutzt wird, könnte auf der übersetzten deutschen Wikipedia "Modul:WikibaseLink" erforderlich sein, was die Probleme erklärt.
Überprüfung des Templates und Ausgabeprobleme
Es scheint, dass das Template korrekt die Entität 'L2' übergibt. Möglicherweise verhindert jedoch eine unerwartete Ausgabe oder ein Fehler in der if-Bedingung eine Sichtbarkeit der Ausgabe. Die Frage könnte sein, ob fehlende Parameter wie shortdesc oder Whitespace-Probleme die Ausgabe blockieren.
Überprüfung des Template-Ausgabefehlers
Es scheint, dass das Template korrekt funktioniert, aber die Ausgabe von p.shortdesc bleibt unsichtbar, was von der Designabsicht abhängt. Bei Tests auf der Template-Seite könnte der Inhalt von <includeonly> blockiert werden. Der direkte Aufruf von #invoke funktioniert jedoch weiterhin korrekt.
Überprüfung der #invoke-Aufrufe im Template
Vielleicht haben sie den direkten #invoke auf der Seiteninhaltsseite und nicht auf der Template-Seite platziert. Es könnte auch an der falschen Verwendung des Namensraums für das Template liegen (Vorlage: statt Template:). Zudem scheint der direkte Aufruf von L= korrekt zu funktionieren, während der entity=-Weg noch nicht getestet wurde.
Überprüfen der Funktionsweise des `entity=L2`-Pfades
Es scheint, dass der direkte Aufruf von {{#invoke:WikibaseLink|shortdesc|entity=L2|mode=auto}} das erwartete Ergebnis nicht liefert, weil die Ausgabe unsichtbar ist. Das funktioniert jedoch korrekt, nur die Erwartung an die Sichtbarkeit ist falsch. Wir sollten testen, ob {{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} funktioniert.
Überprüfen von Template- und #invoke-Aufrufen
Es scheint, dass die erwarteten Ergebnisse bei der Verwendung von {{#invoke:WikibaseLink|shortdesc|entity=L2|mode=auto}} wegen unsichtbarer Ausgaben nicht angezeigt werden. Der direkte Aufruf funktioniert, aber die Vorlage könnte durch zusätzliche Leerzeichen oder einen Fehler im Template-Aufruf beeinträchtigt werden. Ich schlag vor, die Template-Struktur zu vereinfachen, um das Problem zu beheben und eine funktionale Lösung zu gewährleisten.
Erklärung zur Template-Nutzung und Problemen mit der Invocation
Bei der Verwendung von shortdesc erwarten die Nutzer wahrscheinlich sichtbare Ergebnisse, was bei dieser Funktion jedoch nicht der Fall ist. Die Nutzung von Template-Parametern könnte durcheinander geraten sein, insbesondere durch die Reihenfolge der Parameter. Ich schlage vor, das Template zu vereinfachen, indem klarere Parameter wie id= statt L2 verwendet werden, um Verwirrung zu vermeiden.
Vereinfachen der Template-Nutzung und Fehlerbehebung
Ich denke, der beste Weg, die Template-Verwirrung zu umgehen, besteht darin, den Nutzer auf eine einfachere Struktur zu lenken. In diesem Fall bieten direkte Aufrufe wie {{WikibaseLink|L2|mode=L}} eine bessere Klarheit. Es scheint, dass das Problem oft durch "empty" Parameter oder Caching entsteht. Ich würde empfehlen, vorübergehend den direkten Aufruf zu nutzen, bis die Template-Fehler klarer werden.
Nachgedacht für 3m 38s
Fertig

Gut, wir sortieren das sauber. Wichtige Beobachtung: Das Modul funktioniert, weil

{{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}}

bei dir korrekt L2 Dingwort (Wortewort) liefert.

Die Probleme, die du siehst, sind zwei verschiedene Sorten:

1. Zu deinen 5 Beispielen

Ich gehe sie genau so durch, wie du sie aufgelistet hast.

1) / 5) `{{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}`

Das ist jetzt genau so gebaut, dass es nichts Sichtbares anzeigt:

function p.shortdesc(frame)
  ...
  local ok, result = pcall(function()
    return frame:callParserFunction('SHORTDESC', text)
  end)
  ...
  return result or ''
end

frame:callParserFunction('SHORTDESC', text) entspricht effektiv einem unsichtbaren {{SHORTDESC:text}}im Quelltext.
ShortDescription setzt damit die Kurzbeschreibung / den Such-Untertitel im Hintergrund, gibt aber keinen sichtbaren Text zurück.
Dein Eindruck „keine Ergebnisse/Anzeige“ im Artikelttext ist also erwartet.

Prüfen, ob es wirkt:

Auf der Seite → &action=info anschauen: dort sollte als Kurzbeschreibung die Wortart stehen.
Testweise {{GETSHORTDESC:}} in der Seite einfügen → sollte Wortewort o. ä. anzeigen.
Im Suchfeld → nach kurzer Cache-/Index-Zeit sollte der Such-Untertitel auftauchen.

Kurz: shortdesc ist bewusst „unsichtbar“ – nur Meta.

2) `{{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}`

Parameter werden so zugeordnet:

mode = L
labelL = L2 → die Vorlage kennt aber nur label, nicht labelL
1 = L2
shortdesc = ja

Die Vorlage:

{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink
    |shortdesc
    |entity=…aus {{{1}}}…
    |mode={{{mode|auto}}}
  }}
}}

{{#invoke:WikibaseLink
  |linkAndShortdesc
  |entity=…aus {{{1}}}…
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}

{{{shortdesc|ja}}} = ja → #ifeq(ja|nein) → else-Zweig, also shortdesc wird aufgerufen (unsichtbar, s.o.).
{{{1}}} = L2 → entity=L2 (über #titleparts-Logik).
label ist leer (weil du labelL statt label gesetzt hast).
linkAndShortdesc wird mit entity=L2, mode=L aufgerufen → sollte denselben Link liefern wie dein funktionierender Direktaufruf.

Fazit:

Der falsche Parametername labelL ist kosmetisch (Link-Label bleibt Standard), aber nicht der Grund für „keine Anzeige“.
Wenn du wirklich gar nichts siehst, heißt das: der zweite #invoke-Block wird entweder nicht ausgeführt (z. B. weil du auf der Vorlagenseite selbst testest, wo <includeonly> nicht angezeigt wird), oder du schaust nur nach SHORTDESC im Artikelttext, nicht nach dem Link.

3) `{{WikibaseLink|L2|mode=L}}`

Das ist der sauberste Aufruf, und aus der Logik der Vorlage folgt:

{{{1}}} = L2
shortdesc-Block:
```
{{#invoke:WikibaseLink|shortdesc|entity=L2|mode=L}}
```
→ unsichtbar, setzt nur Kurzbeschreibung (siehe oben).
Link-Block:
```
{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L|label=}}
```
→ sollte L2 Dingwort (Wortewort) zeigen (gleiche interne Logik wie dein funktionierender Direktaufruf).

Wenn du hier auf der Artikelseite gar nichts siehst, während

auf derselben Seite funktioniert, ist das kein Modulproblem, sondern:

entweder zeigt dir die Seite, auf der du testest, gar nicht den <includeonly>-Inhalt (z. B. weil du direkt Vorlage:WikibaseLink anschaust),
oder du testest versehentlich an einer anderen Stelle / mit einem anderen Modulstand.

Vom reinen Ablauf her sind die beiden Varianten:

{{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}}
{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}}

im Modul absolut gleichwertig (weil detectEntityId aus entity=L2 ebenso L2 macht wie aus L=L2).

4) `{{WikibaseLink|L2|mode=L|label=Dingwort}}`

Analog zu 3), nur dass label gesetzt ist:

shortdesc-Block: wie oben, unsichtbar.
linkAndShortdesc: entity=L2, mode=L, label=Dingwort → Linktext: L2 Dingwort (Wortewort) (ID + dein Label + Wortart).

Wenn du auch hier gar nichts siehst, gilt dieselbe Ursache wie bei 3) – rein logisch liefert das Modul einen Link.

2. Was ist wirklich „schief“?

Zusammengefasst:

Bei #invoke …shortdesc… ist „keine Anzeige“ korrekt. Der Code ruft bewusst nur die Parserfunktion SHORTDESC auf:
- im Artikelttext nichts,
- in action=info / GETSHORTDESC: / Suche → erwartete Wirkung.
Die Vorlage ist formal richtig verkabelt. Für {{WikibaseLink|L2|mode=L}} expandiert sie exakt zu:
```
{{#invoke:WikibaseLink|shortdesc|entity=L2|mode=L}}
{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}}
```
– also zwei Aufrufe, von denen der erste nichts anzeigt, der zweite aber denselben Link liefern sollte wie dein funktionierender Direktaufruf.
Dass du bei 2), 3) und 4) „keine Anzeige“ siehst, obwohl der direkte #invoke-Aufruf funktioniert, kann aus dem Code heraus nur zwei Ursachen haben:
- Du testest auf der Vorlagenseite selbst (Vorlage:WikibaseLink): Dort wird <includeonly> nicht angezeigt, nur <noinclude> (also Dokumentation). Dann siehst du die Beispiele, aber nicht die effektiven #invokes.
- Du schaust nur auf den Body, nicht auf Meta-Effekte: Bei shortdesc ist das exakt so; beim Link-Teil müsstest du eigentlich etwas sehen – wenn nicht, liegt es eher an der Testumgebung als am Modul/Template.

3. Wenn du es maximal robust und einfach haben willst

Um alle diese potenziellen Stolpersteine auszuräumen, kannst du die Vorlage auch stark vereinfachen und mit benannten Parametern arbeiten, die genau dem funktionierenden Pfad entsprechen:

<!-- Vorlage:WikibaseLink (vereinfachte, robuste Version) -->
<includeonly>
{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink
    |shortdesc
    |L={{{L|}}}
    |P={{{P|}}}
    |Q={{{Q|}}}
    |entity={{{id|}}}
    |mode={{{mode|auto}}}
  }}
}}

{{#invoke:WikibaseLink
  |linkAndShortdesc
  |L={{{L|}}}
  |P={{{P|}}}
  |Q={{{Q|}}}
  |entity={{{id|}}}
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}
</includeonly>
<noinclude>
Verwendung:

* {{WikibaseLink|Q=Q6}}
* {{WikibaseLink|P=P31}}
* {{WikibaseLink|L=L2}}
* {{WikibaseLink|L=L2|shortdesc=nein}}   – nur sichtbarer Link
* {{WikibaseLink|L=L2|mode=L}}          – explizit Lexem-Logik

Parameter:
* L  – Lexem-ID (L…)
* P  – Property-ID (P…)
* Q  – Item-ID (Q…)
* id – generischer Fallback (Q/P/L…)
</noinclude>

Damit:

für dein Lexem:

{{WikibaseLink|L=L2|mode=L}}

wird intern exakt zu dem Aufruf, von dem du weißt, dass er funktioniert:

{{#invoke:WikibaseLink|shortdesc|L=L2|mode=L}}
{{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}}

für Properties und Items analog mit P= bzw. Q=.

Wenn dir später der Komfort mit Lexeme:L2 als Seitenname wichtig ist, können wir darauf aufbauen (z. B. extra Wrapper-Vorlagen für die jeweiligen Namespaces) – aber funktional hast du damit erst mal eine stabile Arbeitsgrundlage.

Kurzantwort auf deine Frage „Was läuft hier warum schief?“

Bei shortdesc läuft nichts schief – die Funktion ist explizit so gebaut, dass sie unsichtbar bleibt und nur die Kurzbeschreibung setzt.
Die kombinierte Vorlage ist logisch korrekt; wenn sie im Artikelnamensraum keinen Link zeigt, liegt das sehr wahrscheinlich an der Testweise (Vorlagenseite vs. Artikelseite) oder daran, dass du den Meta-Effekt (Kurzbeschreibung/Suche) im Augenblick nicht mitbetrachtest.
Um alle Unklarheiten zu eliminieren, kannst du die Vorlage auf die oben vorgeschlagene, benannte Parameter-Variante umstellen – die bildet exakt den Pfad nach, von dem du bereits weißt, dass er technisch funktioniert.

Du:

Modul Wikibase Link (arbeitsfassung)

OK wenn deiner Meinung nach alles richtig ist, dann stellt sich die Frage dennoch warum

1. {{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}} ein Ergebnis liefert und

6. {{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} kein Ergebnis liefert, obwohl du sagst, daß diese dasselbe Ergebnis liefern müssen/würden. Überprüfe bitte das Coding im Canvas auf einen möglichen Fehler.

ChatGPT:

(11. Dez. 2025, 20:xx)

Denke nach…

Untersuchen der Funktionsweise von #invoke mit "L=L2" und "entity=L2"
Es scheint, dass bei #invoke mit "L=L2" funktioniert, weil die Argumente direkt in der Funktion zugewiesen werden. Der Schlüssel ist, dass keine Positionsparameter verwendet werden, sondern nur benannte wie "L" und "mode". Bei "entity=L2" wird dieser Parameter nicht erkannt, da "entity" nicht als Argument im Aufruf definiert ist.
Untersuchen des fehlenden Outputs bei "entity=L2"
Ich sehe, dass der Aufruf mit "entity=L2" korrekt benannte Argumente verwendet, aber es scheint, dass Scribunto möglicherweise "entity=L2" als positionsbasiertes Argument und nicht als benanntes Argument behandelt. Es könnte also eine Diskrepanz bei der Art und Weise geben, wie Scribunto diese Parameter auswertet, was den fehlenden Output erklärt.
Überprüfung der Ursache des Fehlens von "entity=L2"
Vielleicht liegt der Fehler darin, dass das System die Parameter anders verarbeitet. Die direkte Funktionsaufrufe mit "L=L2" funktionieren, aber bei "entity=L2" gibt es möglicherweise eine Einstellung wie das Fehlen des Modus oder bei der Entity-Erkennung. Eine andere Möglichkeit könnte sein, dass die verwendete Scribunto-Version älter ist und die Argumente nicht korrekt übergeben werden.
Überdenken der richtigen Argumentübergabe bei #invoke
Ah, ich erinnere mich, dass bei Modulen, die über Wikitext aufgerufen werden, die übliche Methode ist, frame:getParent() zu verwenden, um auf Template-Parameter zuzugreifen. Allerdings, bei direktem #invoke wird frame.args verwendet. In Nikolaos’ Fall gibt es also keine Notwendigkeit für getParent(), da nur direkte Aufrufe von #invoke verwendet werden.
Überprüfen möglicher Fehlerquellen bei "entity=L2"
Es scheint, dass der Fehler daran liegt, dass frame.args bei direkten Aufrufen anders behandelt wird. Das könnte dazu führen, dass "entity" nicht wie erwartet funktioniert. Ich habe überlegt, ob der Benutzer vielleicht versehentlich Leerzeichen um den Parameter gesetzt hat, aber in Wikitext werden diese normalerweise getrimmt. Daher könnte der Fehler tiefer liegen und mit der spezifischen Syntax zu tun haben.
Überprüfen des 'entity'-Params und der Argumente
Ich schaue mir an, wie das Modul p.linkAndShortdesc arbeitet, besonders bei getArgs(frame) und der Funktion detectEntityId. Ein möglicherweisees Problem könnte sein, dass der 'entity'-Wert zusätzliche Leerzeichen oder Zeilenumbrüche enthält, aber trim() entfernt nur Leerzeichen, nicht aber die Zeilenumbrüche. Trotzdem scheint der Main-Part zu funktionieren, weil wir frame.args verwenden.
Überprüfung von `entity` in der Argumentbehandlung
Ich schaue mir an, wie das Änderungen in der Funktionsweise von getArgs und detectEntityId auf das Verhalten der entity-Parameter auswirken. Ein möglicher Fehler könnte sein, dass der entity-Wert aufgrund der Änderungen in der Argumentverarbeitung nicht korrekt gelesen wird, speziell wenn er als args[1] interpretiert wird.
Überprüfung von `entity` in direkter Modulaufrufbehandlung
Das Template übergibt die ID aus #titleparts, aber der direkte Modulaufruf könnte aufgrund der Änderung in getArgs und der frame.args-Behandlung anders reagieren. Die Frage bleibt, warum "L=" funktioniert, aber "entity=" nicht. Möglicherweise überschattet ein internes "entity"-Attribut unseren Parameter.
Verstehen von `frame.args` und `entity`-Erkennung
Es gibt zwei Frames im Modul: der Elternframe (für Templates) und der Kinderframe (für direkte Aufrufe). In der aktuellen Implementierung werden nur frame.args verwendet, was beim direkten Modulaufruf korrekt funktioniert, aber bei Template-Aufrufen könnte es ein Problem bei der Übergabe des 'entity'-Parameters geben.
Überprüfen von `frame.args` und der Problem-Logik
Für direkte Aufrufe wird frame.args verwendet, aber bei Template-Aufrufen sind sowohl frame.args für #invoke-Argumente als auch parent.args für Template-Parameter relevant. Die "entity"-Variable könnte aufgrund der Art und Weise, wie sie in Template:WikibaseLink verwendet wird, nicht korrekt übergeben werden.
Nachgedacht für 1m 47s
Fertig

Du hast völlig zurecht nachgehakt – da steckt tatsächlich ein konkreter Bug im Modul, und damit erkläre ich auch sauber, warum

{{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}} ein Ergebnis liefert, aber
{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} nichts liefert.

Ich habe versucht, den Patch direkt im Canvas einzutragen; der automatische Editor hat die betreffende Stelle nicht gefunden, daher ist der Tool-Patch fehlgeschlagen. Ich gebe dir deshalb den Korrekturblock als Klartext, den du im Modul händisch ersetzen kannst.

1. Ursache: Kombination aus `ipairs` + `nil` → Entity wird nie erreicht

Der relevante Teil deines aktuellen Codes ist:

local function detectEntityId(args)
  -- Kandidaten aus diesem Aufruf; Reihenfolge:
  -- 1) explizite Typen (L, P, Q)
  -- 2) generische entity/id
  -- 3) Positionsparameter (1)
  local rawL = args.L or args.lexeme or args.l
  local rawP = args.P or args.p
  local rawQ = args.Q or args.q
  local rawEntity = args.entity or args.Entity
  local rawId = args.id or args.ID
  local rawPos = args[1]

  local ordered = { rawL, rawP, rawQ, rawEntity, rawId, rawPos }

  for _, v in ipairs(ordered) do
    if v ~= nil and v ~= '' then
      local s = trim(tostring(v))
      if s ~= '' and s:match('^[QPL]%d+$') then
        return s
      end
    end
  end

  -- Fallback ...
  ...
end

Problem: In Lua bricht ipairs an der ersten nil-Stelle ab.

Fall L=L2:
- rawL = "L2", rawP = nil, rawQ = nil, …
- ordered = { "L2", nil, nil, nil, nil, nil }
- ipairs startet bei Index 1 → findet "L2" → alles gut → L2 wird zurückgegeben.
Fall entity=L2:
- rawL = nil, rawP = nil, rawQ = nil, rawEntity = "L2", …
- ordered = { nil, nil, nil, "L2", nil, nil }
- ipairs startet bei Index 1 → dort ist nil → bricht sofort ab → die "L2" an Position 4 wird nie geprüft → detectEntityId gibt nil zurück → linkAndShortdesc sieht keine ID und liefert ''.

Genau das erklärt deinen Unterschied 1 vs. 6.

2. Korrektur: Liste ohne Nil-Werte aufbauen

Statt die Kandidaten direkt in ein Array mit potenziellen Nil-Löchern zu legen, bauen wir die Liste nur mit vorhandenen Werten – dann ist sie immer „kompakt“, und ipairs geht sauber alle in der gewünschten Reihenfolge durch.

Ersetze im Modul nur die Funktion detectEntityId durch diese Fassung:

local function detectEntityId(args)
  -- Kandidaten aus diesem Aufruf in fester Priorität;
  -- wir bauen die Liste ohne Nil-Werte, damit ipairs
  -- nicht durch führende Nil-Einträge vorzeitig abbricht.

  -- 1) explizite Typen (L, P, Q)
  local rawL = args.L or args.lexeme or args.l
  local rawP = args.P or args.p
  local rawQ = args.Q or args.q

  -- 2) generische entity/id
  local rawEntity = args.entity or args.Entity
  local rawId = args.id or args.ID

  -- 3) Positionsparameter (1)
  local rawPos = args[1]

  local ordered = {}
  local function push(v)
    if v ~= nil and v ~= '' then
      table.insert(ordered, v)
    end
  end

  -- Reihenfolge der Priorität
  push(rawL)
  push(rawP)
  push(rawQ)
  push(rawEntity)
  push(rawId)
  push(rawPos)

  for _, v in ipairs(ordered) do
    local s = trim(tostring(v))
    if s ~= '' and s:match('^[QPL]%d+$') then
      return s
    end
  end

  -- Fallback: Entity zur aktuellen Seite (z. B. Q bei Sitelink)
  local ok, currentId = pcall(mw.wikibase.getEntityIdForCurrentPage)
  if ok and type(currentId) == 'string' and currentId:match('^[QPL]%d+$') then
    return currentId
  end

  return nil
end

Alles andere im Modul bleibt unverändert.

3. Was danach gelten sollte

Nach dieser Änderung:

{{#invoke:WikibaseLink|linkAndShortdesc|L=L2|mode=L}} → funktioniert wie bisher (L2 wird aus rawL genommen).
{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} → jetzt ebenfalls:
- rawL ist nil,
- rawEntity = "L2" → per push(rawEntity) an Position 1
- ordered = { "L2", ... } → ipairs sieht "L2" sofort → ID wird erkannt → Ausgabe genau wie bei L=L2.
Deine Vorlage:WikibaseLink mit |entity={{#titleparts:...}} sollte damit auch den Link liefern, den du erwartest.

Die shortdesc-Aufrufe bleiben weiterhin unsichtbar im Seitentext, setzen aber Kurzbeschreibung/Such-Untertitel im Hintergrund.

Wenn du diesen Block ersetzt, Modul speicherst und einmal den Parser-Cache der Testseite leerst (?action=purge oder Null-Edit), sollten:

{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}}
{{WikibaseLink|L2|mode=L}}
{{WikibaseLink|Lexeme:L2|mode=L}}

alle dasselbe sichtbare Ergebnis liefern wie dein funktionierender Direktaufruf mit L=L2.

Du:

Modul Wikibase Link (arbeitsfassung)

Ich habe das Coding bei mir und im Canvas entsprechend deiner Vorgaben geändert.

1. {{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} liefert "L2 Dingwort (Wortewort)" aus.

2. {{WikibaseLink|L2|mode=L}} liefert "L2 Dingwort (Wortewort)" aus.

Aber mit einem unerwünschten Zeilensprung.

3. {{WikibaseLink|Lexeme:L2|mode=L}} liefert kein Ergebnis aus. Was sagt dir das?

ChtGPT:

(11. Dez. 2025, 21:xx)

Denke nach…

Verifying and fixing newline issue in template expansion
When expanding the template, extra newlines lead to unexpected paragraph breaks. Specifically, when shortdesc returns an empty string, empty newlines appear before a link. To fix it, I should compress the whitespace or rearrange the template so that the calls are on the same line, avoiding a blank line.
Investigating issue with WikibaseLink template
The template {{WikibaseLink|Lexeme:L2|mode=L}} seems to return nothing. When evaluating #titleparts, it gives the correct "L2" part, which should work. There might be issues with how the template is invoked or potential formatting problems like stray spaces or invisible characters causing the issue. I'll double-check all aspects carefully.
Reevaluating template problem and #titleparts function behavior
I was assuming #titleparts would split by the colon, but actually, it splits by slashes instead. That's why #titleparts:Lexeme:L2|2 returned empty—it only has one part, with no slash. This explains why there was no output with the Lexeme:L2 call. I need to adjust my understanding of how #titleparts works.
Fixing the entityId detection logic
It looks like we're using #titleparts incorrectly, which causes issues with how we're handling the page title. Since #titleparts splits by slashes, not colons, we should use #explode to split at the colon instead. This should let us properly detect and pass the right entity ID.
Fixing Lexeme:L2 parsing method
Instead of relying on #titleparts for parsing "Lexeme:L2," I'll use a simpler approach. I’ll utilize {{NAMESPACE:{{{1}}}}} to extract the namespace and {{PAGENAME:{{{1}}}}} for the title, ensuring correct handling of "Lexeme:L2". This avoids complications with the delimiter and is a straightforward method.
Fixing blank lines in template
To avoid extra blank lines, I’ll remove unnecessary line breaks, especially between the two #invoke calls. By restructuring the template on one line, I can eliminate unwanted newlines. Additionally, I’ll closely ensure no empty lines appear in the final output, maintaining proper MediaWiki formatting.
Fixing line breaks and whitespace
I’m making sure to structure my template without introducing unnecessary line breaks. Using {{#ifeq:}} and {{#invoke:}}, I’ll ensure no blank line is inserted between parser functions. There's still a chance for a single newline at the start, but that shouldn’t affect overall formatting.
Simplifying template structure for clean formatting
To avoid unnecessary blank lines, I'll consolidate the #ifeq statement into a single line so that internal newlines in the else branch are removed. This ensures there’s no extra paragraph breaks. I’ll also confirm that required magic words like NAMESPACE and PAGENAME are working fine by making sure the ParserFunctions extension is loaded.
Nachgedacht für 1m 2s
Fertig

Die drei Beobachtungen sagen ziemlich klar:

Modul WikibaseLink funktioniert jetzt korrekt für
- L=L2 und
- entity=L2 → das war der Bug in detectEntityId, den wir mit der neuen ordered-Liste ohne Nils behoben haben.
Der unerwünschte Zeilensprung kommt aus der Vorlage, nicht aus dem Modul.
Lexeme:L2 funktioniert nicht, weil wir an der Vorlage an einer Stelle falsch gedacht haben (falsche Parserfunktion für das Zerlegen von Lexeme:L2).

Ich geh’s der Reihe nach durch.

1. Warum `Lexeme:L2` aktuell kein Ergebnis liefert

Deine Vorlage nutzt:

entity={{#if:{{#titleparts:{{{1|}}}|2}}
          |{{#titleparts:{{{1|}}}|2}}
          |{{{1|}}}
         }}

Die Idee war:

„Wenn 1 etwas wie Lexeme:L2 ist, nimm Teil 2, sonst nimm 1.“

Der Haken:

#titleparts trennt nicht an :, sondern standardmäßig an / (Subseiten). Für Lexeme:L2 gibt es genau einen Teil, also ist {{#titleparts:Lexeme:L2|2}} leer → der #if-Test ist leer → die Vorlage gibt Lexeme:L2 an das Modul weiter → detectEntityId akzeptiert nur ^[QPL]\d+$ → "Lexeme:L2" fällt durch → entityId=nil → nix.

Daher:

{{WikibaseLink|L2|mode=L}} → entity=L2 → klappt.
{{WikibaseLink|Lexeme:L2|mode=L}} → entity=Lexeme:L2 → fällt durch.

Saubere Lösung: `NAMESPACE:` / `PAGENAME:`

Für „Seitentitel mit oder ohne Namensraum“ bieten sich die Magic Words an:

{{NAMESPACE:Lexeme:L2}} → Lexeme
{{PAGENAME:Lexeme:L2}} → L2
{{NAMESPACE:L2}} → '' (leer)
{{PAGENAME:L2}} → L2

Damit kannst du die Entität so setzen:

{{#if:{{NAMESPACE:{{{1|}}}}}
  |{{PAGENAME:{{{1|}}}}}  <!-- es gibt einen Namensraum → nimm Seitentitel ohne NS -->
  |{{{1|}}}               <!-- kein Namensraum → nimm 1 direkt -->
}}

Dann funktionieren sowohl L2 als auch Lexeme:L2.

2. Warum bei `{{WikibaseLink|L2|mode=L}}` ein Zeilensprung entsteht

Deine Vorlage:

<includeonly>
{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink
    |shortdesc
    |entity=...
    |mode={{{mode|auto}}}
  }}
}}

{{#invoke:WikibaseLink
  |linkAndShortdesc
  |entity=...
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}
</includeonly>

Was passiert:

Der #ifeq-Block wird expandiert, dabei entstehen Zeilenumbrüche und Leerzeilen.
p.shortdesc gibt leer zurück (nur Parserfunktion SHORTDESC im Hintergrund).
Übrig bleibt im Wikitext ein „leeres Paket“ aus \n…\n\n vor dem Link.
Zwei aufeinanderfolgende Newlines interpretiert MediaWiki als Absatz-Trenner → du siehst „eine leere Zeile über dem Link“.

Das ist ein klassischer „Leerzeilen durch Vorlagen-Whitespace“-Effekt.

3. Konkrete Reparatur: neue `Vorlage:WikibaseLink`

Ich lasse das Modul in Ruhe (das ist jetzt in Ordnung) und fokussiere auf die Vorlage.

3.1. Ziel

Input: {{WikibaseLink|L2|mode=L}} oder {{WikibaseLink|Lexeme:L2|mode=L}}
Output sichtbar: L2 Dingwort (Wortewort) – ohne leere Zeile davor.
Shortdesc: wird intern gesetzt (für Suche / &action=info), aber im Artikel nicht sichtbar.
Keine Sonderfälle für L/P/Q nötig – Modul erkennt den Typ.

3.2. Empfohlene Fassung

Ersetze den <includeonly>-Block deiner Vorlage 1:1 durch:

<includeonly>{{#ifeq:{{{shortdesc|ja}}}|nein|
  |
  {{#invoke:WikibaseLink|shortdesc
    |entity={{#if:{{NAMESPACE:{{{1|}}}}}
              |{{PAGENAME:{{{1|}}}}}
              |{{{1|}}}
             }}
    |mode={{{mode|auto}}}
  }}
}}{{#invoke:WikibaseLink|linkAndShortdesc
  |entity={{#if:{{NAMESPACE:{{{1|}}}}}
            |{{PAGENAME:{{{1|}}}}}
            |{{{1|}}}
           }}
  |mode={{{mode|auto}}}
  |label={{{label|}}}
}}</includeonly>

Wichtige Punkte dabei:

Kein leerer Absatz mehr:
- Der gesamte #ifeq-Block steht direkt hinter <includeonly> und direkt vor dem zweiten #invoke.
- Es gibt keine komplett leere Zeile zwischen den beiden {{…}}.
- Damit entsteht in der expandierten Seite kein doppelter Zeilenumbruch → kein extra Absatz.
IDs werden sauber aus Lexeme:L2 usw. extrahiert:
- {{NAMESPACE:{{{1}}}}} → wenn nicht leer → nimm {{PAGENAME:{{{1}}}}} als ID (also L2).
- sonst → nimm {{{1}}} direkt (z. B. L2).
shortdesc bleibt unsichtbar, wirkt aber über frame:callParserFunction('SHORTDESC', text).

3.3. Was du danach erwarten solltest

{{WikibaseLink|L2|mode=L}} → sichtbarer Text: L2 Dingwort (Wortewort) (keine Leerzeile mehr davor).
{{WikibaseLink|Lexeme:L2|mode=L}} → Template reduziert Lexeme:L2 auf L2 → Modul erhält entity=L2 → sichtbarer Text: L2 Dingwort (Wortewort).
{{WikibaseLink|L2}} (ohne mode=L) → Modul erkennt Typ L, setzt mode=auto → auto schaltet für L auf mode='l' → Wortart als Kurzbeschreibung → ebenfalls L2 Dingwort (Wortewort).
{{WikibaseLink|L2|shortdesc=nein}} → #ifeq-Block überspringt shortdesc → keine Kurzbeschreibung gesetzt → nur der Link, aber siehst du weiter L2 Dingwort (Wortewort) (je nachdem, ob buildShortdescText für L dann aktiv ist; wenn du Shortdesc komplett abschalten willst, müsstest du noch mode entsprechend beeinflussen – können wir bei Bedarf nachziehen).

4. Kurzer Abgleich mit deinen drei Beobachtungen

#invoke…entity=L2 → alles gut.

{{WikibaseLink|L2|mode=L}} → gut, aber „Zeilensprung“.

{{WikibaseLink|Lexeme:L2|mode=L}} → nichts.

Für (3) ist der Fehler eindeutig: #titleparts trennt am /, nicht am :.
Für (2) ist die Ursache eindeutig: Leerzeile durch die Struktur des <includeonly>-Blocks.

Beides löst die vorgeschlagene Vorlage.

Wenn du das so übernimmst und einmal eine Testseite mit:

{{WikibaseLink|L2|mode=L}}

{{WikibaseLink|Lexeme:L2|mode=L}}

befüllst, solltest du zwei identische Zeilen L2 Dingwort (Wortewort) ohne zusätzliche Leerzeile oben sehen.

Du:

Modul Wikibase Link (arbeitsfassung)

Mit der neuen Vorlage habe ich nun folgendes:

1. {{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} liefert "L2 Dingwort (Wortewort)" aus.

2. {{WikibaseLink|L2|mode=L}} liefert "L2 Dingwort (Wortewort)" aus. Hat aber nach der Ausgabe einen Unerwünschten Zeilensprung, wodurch man dies nicht in den fließtext ausführen kann.

3. {{WikibaseLink|Lexeme:L2|mode=L}} liefert "L2 Dingwort (Wortewort)" aus. Also bis auf den unerwünschten Zeilensprung funktioniert alles jetzt technisch – oder?

ChatGPT:

(11. Dez. 2025, 21:xx)

Aktivität

·1m 18s
Denke nach…
Untersuchen des unerwünschten Zeilenumbruchs
Nikolaos hat jetzt das Modul "WikibaseLink" behoben und berichtet, dass direkte #invoke-Aufrufe korrekt sind, templates jedoch einen unerwünschten Zeilenumbruch nach der Ausgabe erzeugen. Die Frage bleibt: Warum gibt es das Problem mit dem Zeilenumbruch? MedienWiki behandelt oft Vor- oder Nachfolgende Zeilenumbrüche bei Template-Aufrufen, was zu Absätzen führen kann.
Nachforschung zum Zeilenumbruch nach Templates
Der Benutzer sagt, dass der unerwünschte Zeilenumbruch immer "nach der Ausgabe" auftritt, was auf den Template-Inhalt hinweist. Wenn zwei #invokes hintereinander verwendet werden, könnten zeilenumbruchsinduzierte Leerzeichen dazwischen entstehen. Es könnte auch ein unsichtbarer Zeilenumbruch am Ende des Templates oder zwischen den schließenden Klammern von #invoke und </includeonly> sein.
Untersuchen des Zeilenumbruchs nach Transklusion
Wenn der Benutzer einen Zeilenumbruch bemerkt, könnte er auf ein abschließendes Leerzeichen oder einen Zeilenumbruch am Ende des Templates hinweisen. In MediaWiki wird ein Zeilenumbruch am Ende eines Templates in die Transklusionsergebnisse eingefügt. Dies könnte der Ursprung des Problems sein, nicht die direkte Trennung von Template-Inhalten.
Überprüfung des Zeilenumbruchs nach <includeonly>
Die Schließung von </includeonly> könnte mit einem nachfolgenden Zeilenumbruch versehen sein, insbesondere wenn ein »}}« vorher mit einer Newline endet. Der Benutzer hat jedoch angegeben, dass er dieses Problem bereits berücksichtigt hat. Dennoch könnten zusätzliche Leerzeichen oder Zeilenumbrüche nachträglich zu einem Blankoabschnitt führen. Immer noch schwer zu sagen, ob er das wirklich entfernt hat.
Untersuchen von Zeilenumbrüchen in Templates
Es scheint, dass der Benutzer einen "Zeilensprung" bemerkt, der möglicherweise nur ein Leerraum oder ein tatsächlicher Zeilenumbruch ist. Wenn das Template Inline-Nutzung hat, aber mit einem abschließenden Zeilenumbruch, könnte der wikitext dies als Leerzeichen behandeln. Ich schlag vor, eine minimalistische Methode auszuprobieren und den Template-Aufruf zu optimieren, um unnötige Leerzeichen zu entfernen und sicherzustellen, dass alles in einem einzigen #invoke funktioniert.
Überlegen, wie das Template vereinfacht werden kann
Ich denke darüber nach, wie wir das Template 'WikibaseLink' optimieren können. Ein optionaler Parameter für setshortdesc würde helfen, das SHORTDESC direkt zu setzen und die Handhabung von Leerzeichen und Zeilenumbrüchen zu vereinfachen. Durch diesen Ansatz könnten wir die Notwendigkeit für eine separate p.shortdesc-Funktion vermeiden und das Template vereinheitlichen.
Überlegungen zur Vereinfachung von p.linkAndShortdesc
Ich denke darüber nach, wie wir die Funktion p.linkAndShortdesc verbessern können, indem wir den setshortdesc-Parameter wiederverwenden. Dadurch können wir die Logik und Komplexität im Template reduzieren, insbesondere wenn es darum geht, redundante Aufrufe wie p.shortdesc zu vermeiden. Das vereinfacht die gesamte Struktur und entfernt unerwünschte Leerzeichen.
Plan zur Vereinfachung der Link- und Kurzbeschreibung
Ich überlege, wie ich die Funktion p.linkAndShortdesc patchen kann. Es geht darum, die Kurzbeschreibung nur einmal aufzurufen, wenn sie benötigt wird und die Parametrierung für das Template zu vereinfachen. Das reduziert unnötige Leerzeichen und sorgt dafür, dass keine neuen Zeilen eingefügt werden.
Vermeidung von zusätzlichen Leerzeilen im Template
Um unerwünschte Leerzeilen am Ende der includeonly-Konstruktion zu vermeiden, werde ich darauf achten, das schließende </includeonly> auf derselben Zeile wie den letzten Inhalt zu positionieren. Ich schlag vor, die Version in einer einzigen Zeile zu liefern, um mögliche Probleme mit Zeilenumbrüchen zu minimieren.
Nachgedacht für 1m 18s
Fertig

local p = {}

------------------------------------------------------------------
-- Modul:WikibaseLink – überarbeitete Fassung (sichtbare Ausgabe)
-- Ziel:
-- 1) Links zu Q / P / L ausgeben (Special:EntityPage/...)
-- 2) Für P und L passende Kurzbeschreibung ermitteln
--    - P: Wikibase-Beschreibung
--    - L: lexikalische Kategorie (Label)
-- 3) OPTIONAL: Kurzbeschreibung als {{SHORTDESC:...}} bereitstellen
--    (über p.shortdesc), aber NICHT mehr automatisch im sichtbaren
--    Seitentext ausgeben.
-- 4) Für P und L sichtbares Muster:
--      ID Label (Kurzbeschreibung)
--      z.B.  L2 Dingwort (Wortewort)
--
-- Nutzung (direkt per #invoke):
--   {{#invoke:WikibaseLink|link|entity=Q123}}
--   {{#invoke:WikibaseLink|link|P=P31}}
--   {{#invoke:WikibaseLink|link|L=L1}}
--   {{#invoke:WikibaseLink|shortdesc|P=P31|mode=P}}
--   {{#invoke:WikibaseLink|shortdesc|L=L1|mode=L}}
--   {{#invoke:WikibaseLink|linkAndShortdesc|L=L1|mode=L}}
--
-- Empfohlene Vorlage:WikibaseLink (Beispiel im Chat), die intern
--   {{#invoke:WikibaseLink|linkAndShortdesc|entity={{{1|}}}|mode={{{mode|auto}}}|label={{{label|}}}}}
-- aufruft.
--
-- Parameter (alle Funktionen):
--   |entity=  Q123 / P31 / L1 (allgemein)
--   |Q=       explizit Item
--   |P=       explizit Property
--   |L=       explizit Lexem
--   |mode=    'auto' (Standard) / 'Q' / 'P' / 'L'
--             steuert v. a. die Kurzbeschreibung.
--   |label=   optionaler Basis-Linktext statt Wikibase-Label/Lemma
--
-- Fallback:
--   Wenn keine Entity per Parameter angegeben ist, versucht
--   das Modul mw.wikibase.getEntityIdForCurrentPage().
------------------------------------------------------------------

-- Hilfsfunktion: Trim
local function trim(s)
  if type(s) ~= 'string' then
    return s
  end
  return (s:gsub('^%s+', ''):gsub('%s+$', ''))
end

-- Hilfsfunktion: Argumente nur aus dem aktuellen frame holen
-- (keine Parent-Args, damit Aufrufe wie L=L2 zuverlässig wirken)
local function getArgs(frame)
  local args = {}
  if not frame then
    return args
  end

  for k, v in pairs(frame.args or {}) do
    if v ~= '' and v ~= nil then
      args[k] = v
    end
  end

  return args
end

-- Entity-Typ bestimmen
local function getEntityType(id)
  if type(id) ~= 'string' then
    return nil
  end
  if id:match('^Q%d+$') then
    return 'item'    -- Q
  elseif id:match('^P%d+$') then
    return 'property' -- P
  elseif id:match('^L%d+$') then
    return 'lexeme'  -- L
  end
  return nil
end

local function detectEntityId(args)
  -- Kandidaten aus diesem Aufruf in fester Priorität;
  -- wir bauen die Liste ohne Nil-Werte, damit ipairs
  -- nicht durch führende Nil-Einträge vorzeitig abbricht.

  -- 1) explizite Typen (L, P, Q)
  local rawL = args.L or args.lexeme or args.l
  local rawP = args.P or args.p
  local rawQ = args.Q or args.q

  -- 2) generische entity/id
  local rawEntity = args.entity or args.Entity
  local rawId = args.id or args.ID

  -- 3) Positionsparameter (1)
  local rawPos = args[1]

  local ordered = {}
  local function push(v)
    if v ~= nil and v ~= '' then
      table.insert(ordered, v)
    end
  end

  -- Reihenfolge der Priorität
  push(rawL)
  push(rawP)
  push(rawQ)
  push(rawEntity)
  push(rawId)
  push(rawPos)

for _, v in ipairs(ordered) do
  local s = trim(tostring(v))
  if s ~= '' then
    -- Direkte ID (Q123 / P31 / L2)
    local id = s:match('^[QPL]%d+$')
    -- Oder mit Namensraum-Präfix (z.B. "Lexeme:L2", "Property:P31", "Item:Q6")
    if not id then
      id = s:match('^.-:([QPL]%d+)$')
    end
    if id then
      return id
    end
  end
end

-- Fallback: Entity zur aktuellen Seite (z. B. Q bei Sitelink)
local ok, currentId = pcall(mw.wikibase.getEntityIdForCurrentPage)
if ok and type(currentId) == 'string' and currentId:match('^[QPL]%d+$') then
  return currentId
end


  return nil
end

-- Label-/Lemma-Ermittlung für eine Entity (ohne Wikitext)
local function buildEntityLabel(entityId)
  if not entityId then
    return nil
  end

  local etype = getEntityType(entityId)

  -- Spezieller Fall: Lexeme → Lemma in Inhalts-Sprache
  if etype == 'lexeme' then
    local ok, entity = pcall(mw.wikibase.getEntity, entityId)
    if ok and type(entity) == 'table' and type(entity.lemmas) == 'table' then
      local contentLang = 'de'
      if mw.getContentLanguage then
        local cl = mw.getContentLanguage()
        if cl and cl.getCode then
          contentLang = cl:getCode()
        end
      end
      local lemma
      if entity.lemmas[contentLang] and entity.lemmas[contentLang].value then
        lemma = entity.lemmas[contentLang].value
      else
        -- Fallback: irgendein Lemma
        for _, obj in pairs(entity.lemmas) do
          if type(obj) == 'table' and obj.value then
            lemma = obj.value
            break
          end
        end
      end
      if lemma and lemma ~= '' then
        return lemma
      end
    end
  end

  -- Standard: Label über Wikibase
  local ok, fetched = pcall(mw.wikibase.getLabel, entityId)
  if ok and fetched and fetched ~= '' then
    return fetched
  end

  return entityId
end

-- Link auf eine Entity bauen (mit optionalem Label)
local function buildEntityLink(entityId, labelOverride)
  if not entityId then
    return ''
  end

  local label = labelOverride
  if not label or label == '' then
    label = buildEntityLabel(entityId) or entityId
  end

  return string.format('[[Special:EntityPage/%s|%s]]', entityId, label)
end


-- Kurzbeschreibung für eine Entity bestimmen
-- mode:
--   'auto' / nil ->
--       Q (item)      → Wikibase-Beschreibung
--       P (property)  → Wikibase-Beschreibung
--       L (lexeme)    → Label der lexikalischen Kategorie
--   'Q' / 'item'      → Wikibase-Beschreibung
--   'P' / 'property'  → Wikibase-Beschreibung
--   'L' / 'lexeme'    → Label der lexikalischen Kategorie
local function buildShortdescText(entityId, mode)
  if not entityId then
    return nil
  end

  local etype = getEntityType(entityId)
  if not etype then
    return nil
  end

  mode = mode and tostring(mode):lower() or 'auto'

  if mode == 'auto' then
    if etype == 'item' then
      mode = 'q'
    elseif etype == 'property' then
      mode = 'p'
    elseif etype == 'lexeme' then
      mode = 'l'
    end
  end

  -- Q und P: Wikibase-Beschreibung verwenden
  if mode == 'q' or mode == 'item'
    or mode == 'p' or mode == 'property'
  then
    local ok, desc = pcall( mw.wikibase.getDescription, entityId )
    if ok and type( desc ) == 'string' and desc ~= '' then
      return desc
    end
    return nil

  elseif mode == 'l' or mode == 'lexeme' then
    -- Lexem: lexikalische Kategorie → Label dieser Kategorie
    local ok, entity = pcall( mw.wikibase.getEntity, entityId )
    if not ok or type( entity ) ~= 'table' then
      return nil
    end

    local lc = entity.lexicalCategory
    if type( lc ) == 'table' then
      lc = lc.id or lc.value
    end

    if type( lc ) ~= 'string' or lc == '' then
      return nil
    end

    local okLabel, label = pcall( mw.wikibase.getLabel, lc )
    if okLabel and type( label ) == 'string' and label ~= '' then
      return label
    else
      return lc
    end
  end

  return nil
end

-- Gloss für einen Lexem-Sinn ermitteln (z.B. S=1, S='S1', S='L1-S1')
local function getLexemeSenseGloss(entityId, senseParam)
  if not entityId or not senseParam or senseParam == '' then
    return nil
  end

  local etype = getEntityType(entityId)
  if etype ~= 'lexeme' then
    return nil
  end

  -- Sense-ID kanonisieren
  local s = tostring(senseParam)
  local senseId

  -- Vollständige ID: L123-S4
  if s:match('^L%d+-S%d+$') then
    senseId = s
  else
    -- „S4“ oder „4“ → L123-S4
    local num = s:match('^S(%d+)$') or s:match('^(%d+)$')
    if not num then
      return nil
    end
    senseId = string.format('%s-S%s', entityId, num)
  end

  -- Lexem-Entity holen
  local ok, entity = pcall( mw.wikibase.getEntity, entityId )
  if not ok or type(entity) ~= 'table' or type(entity.senses) ~= 'table' then
    return nil
  end

  -- Ziel-Sense in entity.senses suchen
  local targetSense = nil
  for key, sense in pairs(entity.senses) do
    if type(sense) == 'table' then
      local sid = sense.id or key
      if sid == senseId then
        targetSense = sense
        break
      end
    end
  end

  if not targetSense or type(targetSense.glosses) ~= 'table' then
    return nil
  end

  -- Inhalts-Sprache bestimmen
  local contentLang = 'de'
  if mw.getContentLanguage then
    local cl = mw.getContentLanguage()
    if cl and cl.getCode then
      contentLang = cl:getCode()
    end
  end

  -- Gloss in Inhalts-Sprache bevorzugen, sonst irgendeinen
  local gloss
  local g = targetSense.glosses[contentLang]
  if g and type(g) == 'table' and g.value then
    gloss = g.value
  else
    for _, obj in pairs(targetSense.glosses) do
      if type(obj) == 'table' and obj.value then
        gloss = obj.value
        break
      end
    end
  end

  if gloss and gloss ~= '' then
    return gloss
  end

  return nil
end

-- Form (Wortform) für ein Lexem ermitteln (z.B. F=1, F='F1', F='L2-F1')
local function getLexemeFormRepresentation(entityId, formParam)
  if not entityId or not formParam or formParam == '' then
    return nil
  end

  local etype = getEntityType(entityId)
  if etype ~= 'lexeme' then
    return nil
  end

  -- Form-ID kanonisieren
  local s = tostring(formParam)
  local formId

  -- Vollständige ID: L123-F4
  if s:match('^L%d+-F%d+$') then
    formId = s
  else
    -- „F4“ oder „4“ → L123-F4
    local num = s:match('^F(%d+)$') or s:match('^(%d+)$')
    if not num then
      return nil
    end
    formId = string.format('%s-F%s', entityId, num)
  end

  -- Lexem-Entity holen
  local ok, entity = pcall( mw.wikibase.getEntity, entityId )
  if not ok or type(entity) ~= 'table' or type(entity.forms) ~= 'table' then
    return nil
  end

  -- Ziel-Form in entity.forms suchen
  local targetForm = nil
  for key, form in pairs(entity.forms) do
    if type(form) == 'table' then
      local fid = form.id or key
      if fid == formId then
        targetForm = form
        break
      end
    end
  end

  if not targetForm or type(targetForm.representations) ~= 'table' then
    return nil
  end

  -- Inhalts-Sprache bestimmen
  local contentLang = 'de'
  if mw.getContentLanguage then
    local cl = mw.getContentLanguage()
    if cl and cl.getCode then
      contentLang = cl:getCode()
    end
  end

  -- Wortform in Inhalts-Sprache bevorzugen, sonst irgendeine
  local formText
  local r = targetForm.representations[contentLang]
  if r and type(r) == 'table' and r.value then
    formText = r.value
  else
    for _, obj in pairs(targetForm.representations) do
      if type(obj) == 'table' and obj.value then
        formText = obj.value
        break
      end
    end
  end

  if formText and formText ~= '' then
    return formText
  end

  return nil
end


------------------------------------------------------------------
-- Öffentliche Funktionen
------------------------------------------------------------------

-- 1) Nur Link ausgeben (ohne sichtbaren Untertitel)
--    Q:  Label
--    P/L: ID Label
function p.link(frame)
  local args = getArgs(frame)
  local entityId = detectEntityId(args)
  if not entityId then
    return ''
  end

  local etype = getEntityType(entityId)
  local baseLabel = args.label or args.text or buildEntityLabel(entityId) or entityId

  local linkLabel
  if etype == 'item' then
    -- Q: nur das Label
    linkLabel = baseLabel
  else
    -- P/L: ID + Label
    linkLabel = string.format('%s %s', entityId, baseLabel)
  end

  -- Sicherheit: keine Zeilenumbrüche im Linktext
  linkLabel = trim(linkLabel):gsub('\n', ' ')

  return buildEntityLink(entityId, linkLabel)
end

-- 2) Nur SHORTDESC-Wikitext zurückgeben (falls sinnvoll)
--    Hinweis: Ob die ShortDescription-Extension {{SHORTDESC:...}}
--    aus Vorlagen heraus verarbeitet, hängt von der lokalen
--    Konfiguration ab.
function p.shortdesc(frame)
  local args = getArgs(frame)
  local entityId = detectEntityId(args)
  if not entityId then
    return ''
  end

  local mode = args.mode or args.typ or args.type
  local text = buildShortdescText(entityId, mode)
  if not text or text == '' then
    return ''
  end

  text = trim(text):gsub('\n', ' ')

  -- SHORTDESC als Parserfunktion aufrufen, so als stünde
  -- {{SHORTDESC:text}} im Quelltext.
  local ok, result = pcall(function()
    -- Entspricht {{SHORTDESC:text}}
    return frame:callParserFunction('SHORTDESC', text)
  end)

  if not ok then
    -- Falls die Parserfunktion nicht verfügbar ist, lieber
    -- still scheitern, damit Seiten nicht kaputtgehen.
    return ''
  end

  -- SHORTDESC gibt in der Regel nichts Sichtbares zurück.
  -- Wir geben das Ergebnis (typisch leer) zurück, so dass
  -- der #invoke-Aufruf im Seitentext nichts anzeigt.
  return result or ''
end


-- 3) Link mit Untertitel kombinieren
--    Muster:
--       Lexem ohne Sinn/Form:   [[.../L2|L2 Dingwort]] (Wortewort)
--       Lexem mit Sinn (S):     [[.../L2|L2 Dingwort]] (Wortewort)
--                                Ding benennendes Wort
--       Lexem mit Sinn + Form:  [[.../L2|L2 Dingwort]] (Wortewort)
--                                Ding benennendes Wort
--                                Ding benennende Wörter  (z.B. F1)
--       Item/Property:          [[.../Q6|Q6 Dingwort]] (…Beschreibung…)
function p.subtitle(frame)
  local args = getArgs(frame)
  local entityId = detectEntityId(args)
  if not entityId then
    return ''
  end

  local mode  = args.mode or args.typ or args.type
  local etype = getEntityType(entityId)

  -- Basislabel: explizit oder aus Wikibase/Lexem-Lemma
  local baseLabel = args.label or args.text or buildEntityLabel(entityId) or entityId

  -- Untertitel: Beschreibung (Q/P) bzw. Wortart (L)
  local desc = buildShortdescText(entityId, mode)
  if desc ~= nil then
    desc = trim(desc):gsub('\n', ' ')
  end

  ----------------------------------------------------------------
  -- Sinn (Sense) für Lexeme optional bestimmen (S=…)
  ----------------------------------------------------------------
  local senseParam = args.S or args.s or args.sense
  local senseGloss = nil
  if senseParam and etype == 'lexeme' then
    senseGloss = getLexemeSenseGloss(entityId, senseParam)
    if senseGloss ~= nil then
      senseGloss = trim(senseGloss):gsub('\n', ' ')
    end
  end

  ----------------------------------------------------------------
  -- Form (Wortform) für Lexeme optional bestimmen (F=…)
  ----------------------------------------------------------------
  local formParam = args.F or args.f or args.form or args.Form
  local formText = nil
  if formParam and etype == 'lexeme' then
    formText = getLexemeFormRepresentation(entityId, formParam)
    if formText ~= nil then
      formText = trim(formText):gsub('\n', ' ')
    end
  end

  ----------------------------------------------------------------
  -- Steuerung, ob der Untertitel im sichtbaren Text stehen soll
  -- subtitle: ja/1 (Standard) → sichtbar
  --           nein/0          → unsichtbar
  ----------------------------------------------------------------
  local subtitleParam = args.subtitle
  local showSubtitle  = true  -- Default: ja

  if subtitleParam ~= nil and subtitleParam ~= '' then
    local s = tostring(subtitleParam):lower()
    if s == 'nein' or s == '0' then
      showSubtitle = false
    elseif s == 'ja' or s == '1' then
      showSubtitle = true
    end
  end

  -- SHORTDESC als Seiteneigenschaft setzen (für Suche), falls vorhanden
  -- (weiterhin nur aus der Kurzbeschreibung, nicht aus Sinn/Form)
  if desc and desc ~= '' then
    pcall(function()
      frame:callParserFunction('SHORTDESC', desc)
    end)
  end

  -- Sichtbarer Link-Teil: für Q/P/L immer "ID Label"
  local visibleLabel = string.format('%s %s', entityId, baseLabel)
  visibleLabel = trim(visibleLabel):gsub('\n', ' ')

  -- Link nur um ID + Label
  local linkText = buildEntityLink(entityId, visibleLabel)

  -- Wenn keine sichtbaren Untertitel gewünscht → nur Link zurückgeben
  if not showSubtitle then
    return linkText
  end

  -- Spezielles Layout für Lexeme: Zeile 1 + optional Zeile 2/3
  if etype == 'lexeme' then
    local line1
    if desc and desc ~= '' then
      line1 = string.format('%s (%s)', linkText, desc)
    else
      line1 = linkText
    end

    local lines = { line1 }

    if senseGloss and senseGloss ~= '' then
      table.insert(lines, senseGloss)
    end

    if formText and formText ~= '' then
      table.insert(lines, formText)
    end

    -- Zeilen mit <br /> verbinden
    return table.concat(lines, '<br />')
  end

  -- Standardfall: Q / P → Link + (Beschreibung)
  if desc and desc ~= '' then
    return string.format('%s (%s)', linkText, desc)
  else
    return linkText
  end
end


return p

Ja, technisch sind wir jetzt da, wo du hin wolltest:

Q, P, L werden sauber erkannt (inkl. entity=L2 und Lexeme:L2 → L2).
linkAndShortdesc liefert dein Muster L2 Dingwort (Wortewort) – sowohl beim direkten #invoke als auch über die Vorlage.
ShortDescription wird unsichtbar gesetzt.

Offen ist nur noch die Wahrnehmung des „Zeilensprungs“ bei der Vorlagen-Variante.

1. Stand der Funktionalität (kurz)

Deine drei Tests:

{{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} → OK, gibt L2 Dingwort (Wortewort) aus.
{{WikibaseLink|L2|mode=L}} → OK, gibt L2 Dingwort (Wortewort) aus, aber danach siehst du einen Zeilensprung.
{{WikibaseLink|Lexeme:L2|mode=L}} → OK, gibt ebenfalls L2 Dingwort (Wortewort) aus.

Das zeigt:

Modul: verhält sich wie erwartet.
Vorlage: liefert dieselbe Expansion wie das direkte #invoke.
Der Unterschied „mit/ohne Zeilensprung“ liegt nicht mehr in der Logik von detectEntityId oder linkAndShortdesc, sondern in der Art, wie die Vorlagen-Ersetzung im Wikitext eingebettet ist.

2. Wo der „Zeilensprung“ herkommt

Im jetzigen Stand:

Das Modul gibt für alle drei Varianten nur den Link zurück, z. B.:
```
[[Special:EntityPage/L2|L2 Dingwort (Wortewort)]]
```
Weder p.linkAndShortdesc noch die Vorlage erzeugen ein <br>, eine Liste, eine Überschrift oder sonstigen Block-Markup.

Ein „Zeilensprung“ kann also nur entstehen durch:

Die Umgebung im Artikel:
- Beispiel:
```
Text vor.
{{WikibaseLink|L2|mode=L}}
Text danach.
```
  → Das sind drei Zeilen, mit Leerzeile(n) dazwischen → MediaWiki macht daraus getrennte Absätze, also sichtbare Zeilenumbrüche.
- Während du den Direkt-#invoke vielleicht so getestet hast:
```
Text vor {{#invoke:WikibaseLink|linkAndShortdesc|entity=L2|mode=L}} Text danach.
```
  → alles in einer Zeile → einer Textfluss.
Einen echten Leerabsatz durch Leerzeilen im Template-Body: Bei deiner aktuellen Vorlage:WikibaseLink sieht das <includeonly> in etwa so aus:
```
<includeonly>{{#ifeq:…}}
{{#invoke:WikibaseLink|linkAndShortdesc|…}}</includeonly>
```
Innerhalb von <includeonly> sind zwar Zeilenumbrüche, aber kein leerer Absatz (\n\n) am Ende. Die Expansion sieht dadurch im Artikel aus wie ganz normaler Inline-Wikitext. Ein echter neuer Absatz (= Zeilensprung) entsteht erst, wenn im Artikel rundherum Leerzeilen sind.

3. Was du jetzt praktisch tun kannst

Um sicherzugehen, dass die Vorlage im Fließtext wirklich inline ist, kannst du einen ganz nüchternen Test machen (auf einer Sandbox-Seite):

X{{WikibaseLink|L2|mode=L}}Y

Wenn alles stimmt, solltest du sehen:

X L2 Dingwort (Wortewort) Y

Ohne Zeilenumbruch dazwischen.
Wenn hier schon ein Zeilensprung sichtbar ist, dann steckt irgendwo im Template noch ein echter Leerabsatz – dann müssten wir uns die Vorlage 1:1 mit genauem Zeilenlayout anschauen.
Wenn hier kein Zeilensprung ist, aber in deinem eigentlichen Artikel doch, dann liegt es an den Leerzeilen / Absatztrennungen im Artikeltext, nicht an Modul/Template.

4. Noch eine Option: „Inline-sicher“ schreiben

Für Fließtext kannst du dich an folgendem Muster orientieren:

… im Sinne von {{WikibaseLink|L2|mode=L}} verstanden, wobei …

Keine Zeilenumbrüche vor oder nach der Vorlage in der Wikitextzeile, dann wird das von MediaWiki normalerweise als durchgehender Inline-Text behandelt.

5. Hinweis zum Canvas-Patch

Ich habe versucht, die Funktion linkAndShortdesc im Canvas direkt mit einer Variante zu erweitern, die die SHORTDESC-Setzung als Seiteneffekt übernimmt (so dass die Vorlage nur noch einen einzigen #invoke braucht). Der automatische Patch ist jedoch an der Mustererkennung gescheitert und wurde vom System abgebrochen.

Dein Modul-Stand im Canvas ist also weiterhin genau der, den du oben zitiert hast – und der tut für Q/P/L, was er soll.

Wenn du magst, kannst du mir im nächsten Schritt

ein kurzes Beispiel-Snippet aus einer konkreten Artikelseite schicken (3–4 Zeilen Wikitext um die Vorlage herum), in dem du den Zeilensprung siehst. Dann können wir sehr gezielt schauen, ob da ein versteckter Leerabsatz oder eine andere Formatierung greift, ohne am inzwischen funktionierenden Modul etwas zu verändern.

weiter mit Gespräch:Wikibase-MediaWiki-Semantic MediaWiki-Brücke

Du:

ChatGPT:

1. Was deine aktuelle Vorlage tut – und wo sie hakt

2. ID aus wiki-page-name ziehen (mit #titleparts)

3. Praktische Vorlage:WikibaseLink (Vorschlag)

Was diese Vorlage effektiv macht

4. Zu deiner Frage „wiki-page-name für L/P/Q zur Auswahl arbeiten“

Du:

ChatGPT

0. Erinnerung: Was das Modul aktuell tut

1) {{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}

Was MediaWiki daraus macht

2) {{WikibaseLink|Lexeme:L2}}

3) {{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}

Kurzfassung „Fehler oder Modul?“

Du:

ChatGPT:

1. Zu deinen 5 Beispielen

1) / 5) {{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}

2) {{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}

3) {{WikibaseLink|L2|mode=L}}

4) {{WikibaseLink|L2|mode=L|label=Dingwort}}

2. Was ist wirklich „schief“?

3. Wenn du es maximal robust und einfach haben willst

Du:

ChatGPT:

1. Ursache: Kombination aus ipairs + nil → Entity wird nie erreicht

2. Korrektur: Liste ohne Nil-Werte aufbauen

3. Was danach gelten sollte

Du:

ChtGPT:

1. Warum Lexeme:L2 aktuell kein Ergebnis liefert

Saubere Lösung: NAMESPACE: / PAGENAME:

2. Warum bei {{WikibaseLink|L2|mode=L}} ein Zeilensprung entsteht

3. Konkrete Reparatur: neue Vorlage:WikibaseLink

3.1. Ziel

3.2. Empfohlene Fassung

3.3. Was du danach erwarten solltest

4. Kurzer Abgleich mit deinen drei Beobachtungen

Du:

ChatGPT:

1. Stand der Funktionalität (kurz)

2. Wo der „Zeilensprung“ herkommt

3. Was du jetzt praktisch tun kannst

4. Noch eine Option: „Inline-sicher“ schreiben

5. Hinweis zum Canvas-Patch

Wenn du magst, kannst du mir im nächsten Schritt

2. ID aus wiki-page-name ziehen (mit `#titleparts`)

3. Praktische `Vorlage:WikibaseLink` (Vorschlag)

1) `{{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}`

2) `{{WikibaseLink|Lexeme:L2}}`

3) `{{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}`

1) / 5) `{{#invoke:WikibaseLink |shortdesc |entity=L2 |mode=auto }}`

2) `{{WikibaseLink|mode=L|labelL=L2|L2|shortdesc=ja}}`

3) `{{WikibaseLink|L2|mode=L}}`

4) `{{WikibaseLink|L2|mode=L|label=Dingwort}}`

1. Ursache: Kombination aus `ipairs` + `nil` → Entity wird nie erreicht

1. Warum `Lexeme:L2` aktuell kein Ergebnis liefert

Saubere Lösung: `NAMESPACE:` / `PAGENAME:`

2. Warum bei `{{WikibaseLink|L2|mode=L}}` ein Zeilensprung entsteht

3. Konkrete Reparatur: neue `Vorlage:WikibaseLink`