Gespräch:Transklusion Ausschluß im Sucheergebnis

Über diese Seite Gespräch

Transkludierte Inhalte ausblenden
Ausarbeitung
ChatGPT Sophos GPT-5 Thinking
3. Dezember 2025 n. Chr. erst.
18:50 Uhr Ausgabe 03
Ausgabe 03
unüberarbeitet ungeprüft
↓ Umgestaltung Modul:Bereichfenster und Modul:Seitenfenster zu Modul:Schaufenster

Hallo Sophos,

wenn ich in MediaWiki vergleichsweise mittels {{:Seitenname}} den Inhalt einer seite in eine andere Seite transkludiere, so werden bei Suche nach einem Inhalt der Quellenseite auch derselbe Inhalt der Transklusionsseite im Suchergebnis angezeigt. Manche Inhalte werden in vielen Seiten auf diese Artweise transkludiert, so daß je Transklusion ein Suchergebnis angezeigt wird, wo es an sich nur eine Quelle gibt – das bauscht das Suchergebnis unnötig auf.

Wie erreiche ich, dass der Inhalt eine Transklussionsseite nicht in der Suche erscheint?

ChatGPT:

Hallo Nikolaos — (3. Dez. 2025, 18:50)

kurz auf den Punkt: Mit CirrusSearch kannst du transkludierten Inhalt gezielt vom Suchindex ausschließen (oder zumindest abwerten), sodass er auf den transkludierenden Seiten nicht mehr als Treffer zählt.

Variante A: Hart ausschließen (empfohlen)

Wickle die Transklusion auf der Zielseite in ein Element mit class="navigation-not-searchable":

<div class="navigation-not-searchable">
{{:Seitenname}}
</div>

CirrusSearch ignoriert den umschlossenen Text beim Indexieren vollständig. MediaWiki

Variante B: Als „Nebentext“ abwerten (statt komplett ignorieren)

Wenn du den Text nicht ganz ausschließen, aber weniger gewichten willst:

<div class="searchaux">
{{:Seitenname}}
</div>

Der Inhalt wandert in das auxiliary-Feld und hat deutlich geringere Relevanz. MediaWiki

Praktisch umsetzen

Wrapper-Vorlage anlegen (sauber und wiederverwendbar):

<!-- Vorlage:TranskludiertOhneSuche -->
<div class="navigation-not-searchable">
{{{1|}}}
</div>

Verwendung:

Nur beim Transkludieren ausschließen (Quelle soll normal indexiert bleiben):
```
{{TranskludiertOhneSuche|{{:Seitenname}}}}
```
Setze auf der Quellseite die Wrapper-Tags nur im Transklusionsfall: So bleibt die Quellseite selbst vollständig durchsuchbar; nur die Einbindungen werden ignoriert. (Mechanik: <includeonly> wirkt nur in Transklusionen.) MediaWiki

Verifizieren

Ruf auf einer betroffenen Zielseite ?action=cirrusdump auf.

Bei Ausschluss fehlt der Text in source_text.
Bei Abwertung findest du ihn in auxiliary_text. MediaWiki+1

Hinweise

Diese Klassen werden von CirrusSearch ausgewertet. Mit der alten Core-Suche ohne Cirrus greifen sie nicht. (Dein System nutzt Cirrus, daher passt das.) MediaWiki
Titel-/Namensübereinstimmungen können weiterhin Treffer erzeugen (z. B. wenn der Seitentitel selbst den Suchbegriff enthält). Das betrifft nur den Textindex, nicht die Seitennamen. MediaWiki

Wenn du magst, skizziere ich dir noch eine Mini-Migrationsstrategie (Vorlage anlegen, ReplaceText-Läufe, stichprobenartige cirrusdump-Checks) – dann hast du das in 2–3 klaren Schritten wikiweit konsistent.

Du:

Mittels Vorlage "Nur beim Transkludieren ausschließen" ist für mich die brauchbarste Artweise die Suchergebnisse zur Quellseite zu leiten, da nur dort gegebenenfalls Änderungen zu machen sind, die sich propagieren.

Dies führt zur Frage, wie man die Seiten sich anzeigen lassen kann, in die Inhalte einer Quellseite transkludiert wurden – geht das?

ChatGPT:

Denke nach…

Überlegen, wie timestamp im fortlaufenden Chat behandelt wird
Ich denke, im aktuellen Chat ist kein neuer Timestamp notwendig, da der Benutzer dies nicht bei jeder Antwort verlangt. Der Assistenz war dabei, einen Freeze-Zeitpunkt einzufügen. Ich bleibe bei einer Antwort ohne extra Zeitstempel. Zum Thema: MediaWiki bietet die Funktion "Was verlinkt hierher", wo man Transklusionen finden kann.
Klärung der Transklusionen in MediaWiki
In MediaWiki kann man Seiten finden, die anderen Seiten eingebunden haben, indem man "Spezial:Linkliste/Seitenname" verwendet. Für Transklusionen speziell sollte "Spezial:WasVerlinktHier" Filter wie „Einbindungen“ nutzen. Alternativ kann die API „embeddedin“ verwendet werden. Template-Verwendungen zeigt „Spezial:WasVerlinktHier/Template:XYZ“.
Erklären der Medienwiki-Transklusionen
Um Seiten zu finden, die eine bestimmte Quelle transkludieren, benutzt man "Spezial:Linkliste" bzw. „Special:WhatLinksHere” und filtert nach „Einbindungen“ für Transklusionen. In der UI kann man „Einbindungen verbergen“ umschalten oder Parameter wie show=transclusion verwenden. CirrusSearch könnte zusätzlich verwendet werden, wenn die Transklusionen in Suchergebnissen berücksichtigt werden sollen.
Vorschlag zur Anzeige von Transklusionen
Um Seiten zu finden, die einen bestimmten Inhalt transkludieren, kann man "Spezial:Linkliste" nutzen und nach „Einbindungen“ filtern. Eine API-Methode wäre auch sinnvoll, z. B. action=query&list=embeddedin. Wenn eine Wrapper-Vorlage verwendet wird, können auch Semantic MediaWiki oder Cargo-Abfragen helfen, um die verwandten Seiten zu finden.
Überprüfung der Transklusion-Methoden
Die Benutzerfrage bezieht sich auf den Wrapper „Nur beim Transkludieren ausschließen“, der Transklusionen ohne separate Wrapper-Vorlage vornimmt, indem er Tags wie <includeonly> verwendet. Um die Zielseiten zu finden, kann „WhatLinksHere“ direkt verwendet werden, da verschachtelte Transklusionen auch dort nachvollziehbar sind.
Anleitung zur Suche nach Transkludierungen und Verwendung von Wrapping-Templates
Um Seiten zu finden, die ein bestimmtes Wrapper-Template verwenden, kann „Spezial:Linkliste“ genutzt werden, um nach Transklusionen in „Einbindungen“ zu filtern. Die Verwendung von „Spezial:WhatLinksHere/Template:TranskludiertOhneSuche“ hilft, aber gibt nur die Wrapper-Seiten zurück. Ich werde darauf hinweisen, wie man mit spezifischen Abfragen arbeitet und von Caching und Purge-Prozeduren berichten.
Nachgedacht für 54s
Fertig

Klar. Du hast zwei robuste Wege:

1) Direkt im Wiki (ohne API)

Öffne: [[Spezial:Linkliste/Seitenname]] (Alias von Special:WhatLinksHere).
Filter setzen: Verlinkungen ausblenden ✅, Einbindungen anzeigen ✅ (URL-Parameter: ?hidelinks=1&hidetrans=0; optional &namespace=0|120|122 zum Eingrenzen).
Ergebnis: Alle Seiten, die diese Quelle transkludieren.

Tipp: Auf die Quellseite unten einen Fix-Link legen:

2) Per API (skriptfähig)

embeddedin liefert genau die Seiten, die die Quelle einbinden (Transklusionen).
einamespace nach Bedarf anpassen.

Wichtige Hinweise

Deine „Nur beim Transkludieren ausschließen“-Variante (mit <includeonly>…</includeonly>) beeinflusst nur den Such-Index – nicht die Backlink-Erfassung. Spezial:Linkliste und embeddedin funktionieren also weiterhin korrekt.
Falls frisch angelegte Transklusionen nicht sofort auftauchen: Quell- oder Zielseite purgen (?action=purge) oder maintenance/refreshLinks.php für die Quelle laufen lassen; die Jobs (Backlinks) werden dann sauber aktualisiert.

Wenn du willst, baue ich dir eine kleine Spezialseite/Linkbox-Vorlage („EinbindungenDerAktuellenSeite“) mit Namespace-Filter, damit du das überall einheitlich nutzen kannst.

Du:

Ich habe es nun wir folgt gelöst:

<includeonly><onlyinclude><div class="navigation-not-searchable">
{{#if: {{{Seitenname|}}}|[[{{{Seitenname}}}|▷]] {{:{{{Seitenname}}}}}| }}
</div>
</onlyinclude></includeonly>

<templatedata>
{
	"params": {
		"Seitenname": {
			"label": "Seitenname",
			"description": "Seitenname mit oder ohne Namenraum als Prefix",
			"example": "Seitenname oder Nemenraum:Seitenname",
			"type": "wiki-page-name",
			"required": true
		}
	},
	"description": "Führt die Transklusion gemäß des Seitennamen ohne einbindung in Suchergebnisse aus. Suche liefert nur Ergebnisse der Quellenseite, nicht die Inhalte auf Seiten deren Transklusion",
	"format": "inline"
}
</templatedata>

Verwendung:

{{TransklusionSucheAus|Seitenname=Name der Seite}}

Dadurch habe ich auch gleich automatisch einen Link zur Quellenseite.

TEst ergab, daß die Seiten mit Transklusion mittel der Vorlage in der Suche nicht mher erscheinen und die Links unter "links auf diese Seite" als Vorlageneinbindung gelistet sind.

ChatGPT:

Denke nach…

Unklarheiten bei "includeonly" und "onlyinclude"
Es geht hier um die Verwendung von onlyinclude in includeonly. Ich frage mich, ob das syntaktisch gültig ist. Beide Tags haben unterschiedliche Bedeutungen, aber wenn man sie kombiniert, könnte es doppelte Semantik verursachen—obwohl es vielleicht harmlos ist. Die Frage, ob das eine gängige Vorgehensweise ist, bleibt schwer zu beantworten.
Verwendung von "includeonly" und "onlyinclude" in Vorlagen
Es scheint, dass die Vorlage „TransklusionSucheAus“ die Tags includeonly und onlyinclude verwendet, um zu steuern, was gezeigt wird, wenn sie transkludiert wird. Beim Aufruf der Vorlage auf einer Seite wird nur der Inhalt von onlyinclude angezeigt, aber includeonly wird auf der Vorlagenseite nicht angezeigt. Doch warum würde man onlyinclude innerhalb von includeonly verwenden?
Überprüfung von "onlyinclude" und "includeonly" in Vorlagen
Es scheint, dass sowohl onlyinclude als auch includeonly nur bei der Transklusion anzeigen, aber das Verwenden beider Tags zusammen ist redundant. Die Vorlage gibt einen div mit der Klasse „navigation-not-searchable“ zurück, der optional einen Link und eine Roh-Transklusion von Inhalt enthält. Die Verwendung von #if stellt sicher, dass der Parameter „Seitenname“ nicht leer ist.
Kantenfälle bei der Vorlage und Transklusion
Es gibt einige Kantenfälle, wie etwa den Leerraum zwischen Link und Transklusion, was jedoch unproblematisch ist. Die Verwendung von <onlyinclude> in Vorlagen könnte zu Problemen führen, wenn die Vorlage in einer anderen Vorlage genutzt wird. Auch bei der Kategoriesuche sollte beachtet werden, dass Kategorien aus der transkludierten Seite zum Ziel führen.
Kantenfälle bei der Vorlagen-Transklusion
Es gibt einige Kantenfälle zu beachten. Der Leerraum zwischen Link und Transklusion ist okay. Die Verwendung von <onlyinclude> in Vorlagen könnte Probleme verursachen, wenn sie in einer weiteren Vorlage verwendet wird. Auch die Kategoriepropagation sollte beachtet werden, da sie unerwünscht sein kann. Möglicherweise sollte man die Magie-Option __NOINDEX__ verwenden, um dies zu unterdrücken.
Kategorie-Suppressions-Techniken und NOINDEX
Das NOINDEX-Tag verhindert die Indizierung durch externe Suchmaschinen, nicht durch MediaWiki. Für die Kategoriedämpfung kann man Kategorien auf der Quellseite mit <noinclude> umschließen. Wenn Kategorien nur auf der Quellseite erscheinen sollen, müssen sie in <noinclude> platziert werden. Die „navigation-not-searchable“-Klasse beeinflusst diese Indizierung jedoch nicht.
Suchergebnisse und Vorlagenoptimierung
Die Anfrage bezieht sich auf Suchergebnisse, aber es gibt einige Nebeneffekte. Zum Beispiel zeigt "WasLinksHier" (Links auf diese Seite) die Vorlageneinbindung. Eine mögliche Verbesserung wäre, Standardparameter für die Transklusion von Abschnitten zu unterstützen. Es wäre auch nützlich, das Vorhandensein von Seiten mit einer Parserfunktion zu überprüfen und optionale Anpassungen vorzusehen.
Verbesserungen und Anpassungen für Vorlagen
Es gibt einige Verbesserungen, wie das Hinzufügen eines Alias '1' für Parameter und die Möglichkeit, 'Seitenname' zu vereinfachen. Die 'navigation-not-searchable' und 'searchaux' Klassen können auch berücksichtigt werden. Ein wichtiger Hinweis ist, das TemplateData zu verfeinern und kleine Korrekturen bei Schreibfehlern vorzunehmen.
Vorschläge für Template-Verbesserungen
Ich empfehle, eine Schutzmaßnahme gegen Transklusions-Schleifen einzuführen, um die Gefahr von Endlosschleifen zu vermeiden. Dies könnte durch die Verwendung von Bedingungen wie #ifeq erfolgen. Es gibt kleinere Anpassungen wie die Option, einen Link anzuzeigen oder die VisualEditor-Kompatibilität zu gewährleisten. Eine regelmäßige Aktualisierung des Indexes wäre ebenfalls sinnvoll.
Vorschläge zur Vereinfachung der Transklusion
Die Verwendung von 'onlyinclude' alleine reicht aus, ohne 'includeonly' als Wrapper. Dies sorgt dafür, dass Inhalte nur beim Transkludieren sichtbar sind, nicht jedoch beim bearbeiten oder Anzeigen der Vorlage. Es sollte beachtet werden, dass 'navigation-not-searchable' nur für CirrusSearch funktioniert, was hier korrekt ist.
Vereinfachung und Empfehlungen
Die Verwendung von 'onlyinclude' und 'includeonly' dient unterschiedlichen Zwecken: 'onlyinclude' macht Teile der Vorlage sichtbar, wenn sie transkludiert wird, während 'includeonly' den Inhalt nur bei der Transklusion zeigt. Die Codesemantik scheint korrekt, aber es gibt Duplikation. Ein paar zusätzliche Maßnahmen sind sinnvoll, wie eine Parameterüberprüfung oder Links zu "Was Links Hier?" zur Fehlerbehandlung. Bezüglich Performance ist eine vorsichtige Nutzungsrate wichtig – der Einsatz von #ifexist z. B. bringt Performance-Nachteile.
Nachgedacht für 55s
Fertig

stark gelöst. Das erfüllt exakt „Quelle indexieren, Einbindungen ignorieren“ und gibt gleich den Sprunglink zur Quelle. Ein paar kleine Feinschliffe/Optionen, falls du’s noch robuster machen willst:

1) Tags vereinfachen (optional)

<onlyinclude> ist hier redundant, weil du ohnehin alles in <includeonly> kapselst. Funktional identisch – aber schlanker:

<includeonly><div class="navigation-not-searchable">
{{#if: {{{Seitenname|}}}|[[{{{Seitenname}}}|▷]] {{:{{{Seitenname}}}}}| }}
</div></includeonly>

(Beide Varianten sind korrekt; wähle die, die du bevorzugst.)

2) Selbst-Transklusion abfangen (optional)

Falls jemand versehentlich die aktuelle Seite als Seitenname übergibt, verhinderst du Loops/Fehler:

<includeonly><div class="navigation-not-searchable">
{{#if: {{{Seitenname|}}} |
  {{#ifeq: {{lc:{{{Seitenname}}}}} | {{lc:{{FULLPAGENAME}}}} 
    | <!-- Selbst-Transklusion: nichts ausgeben -->
    | [[{{{Seitenname}}}|▷]] {{:{{{Seitenname}}}}}
  }}
| }}
</div></includeonly>

(Hinweis: lc: gleicht Groß/Kleinschreibung an; reicht i. d. R. aus.)

3) Existenzprüfung – mit Augenmaß

Wenn der Link nie als Rotlink erscheinen soll:

{{#ifexist: {{{Seitenname|}}} | [[{{{Seitenname}}}|▷]] {{:{{{Seitenname}}}}} | }}

Beachte: #ifexist ist „teuer“. Bei tausenden Verwendungen lieber weglassen oder sparsam einsetzen.

4) TemplateData kleine Korrekturen + Komfort

Tippfehler: „Nemenraum“ → „Namensraum“, „einbindung“ → „Einbindung“.
Alias für Positionsparameter „1“ hinzufügen → kürzere Nutzung {{TransklusionSucheAus|Seite}}.

Beispiel TemplateData:

{
  "description": "Transkludiert eine Quellseite so, dass der Text in ein navigation-not-searchable-Element wandert. Damit zählt der Inhalt auf Zielseiten nicht für die Volltextsuche; Treffer führen zur Quellseite.",
  "format": "inline",
  "params": {
    "Seitenname": {
      "label": "Seitenname",
      "description": "Seitenname mit oder ohne Namensraumpräfix",
      "example": "Seitenname oder Namensraum:Seitenname",
      "type": "wiki-page-name",
      "required": true,
      "aliases": ["1"]
    }
  }
}

5) Kategorien & Metadaten (nur wenn relevant)

Dein Wrapper beeinflusst nur den Suchindex. Falls die Kategorien der Quellseite nicht auf Zielseiten landen sollen, setze deren Kategorien in der Quelle in <noinclude>…</noinclude> oder halte Kategorien bewusst separat.

6) Kontrolle/Verifizierung

?action=cirrusdump auf einer Zielseite: Der transkludierte Text sollte nicht in source_text auftauchen.
Spezial:Linkliste/Quellseite mit ?hidelinks=1&hidetrans=0: zeigt dir weiterhin sauber alle Einbindungen.

Wenn du willst, baue ich dir noch eine Mini-Hilfsvorlage:

[[Spezial:Linkliste/{{{1|{{FULLPAGENAME}}}}}?hidelinks=1&hidetrans=0|Einbindungen anzeigen]]

…die du unter den Quellseiten platzierst, um die Transklusionsziele im Blick zu behalten.

Du:

1) - 4) und 6) brauche ich nicht. 1) ist wegen der Dokumentationsseite so und die anderen braucht man nicht, weil ein Fehler sofort auffällt.

5) das Kategorien von der Transklusion nicht allgemein ausgeschlossen sind, war schon immer ärgerlich, es ist immer ein Gefummel mit den Kategorien. Ich brauche da eine eigene Vorlage, mittels derer ich Kategorien erfasse, da man immer bei jeder neu hinzugefügten Kategorie darauf achten muß, sie innerhalb der Tags zu halten.

Wir haben mal die Vorlage Bereichsfenster entworfen, mittels der man nur den Text bis zur ersten Überschrift mit einem Filter für Kategorien entwickelt.

Wielleicht gibt es ja etwas Ähnliches für Seiteninhalte wie für Zitate. Wikipedia nutzt da etwas um Abschnitte von langen Seiten zu trankludieren, weiß aber nicht mehr ob dies Tag oder ein Gadget war.

Was tut Erweiterung:Labeled Section Transclusion?

ChatGPT:

Denke nach…

Planen der Antwort für Nikolaos
Für Nikolaos müssen wir präzise und knapp antworten, ohne Marketingfloskeln oder Entschuldigungen. Er bevorzugt eine lösungsorientierte Antwort auf dessen Frage zur Extension:Labeled Section Transclusion (LST) mit Fokus auf Filtertricks für Kategorien. Ich werde die neuesten Informationen aus offiziellen Quellen einholen und auf die Anleitung von MediaWiki zurückgreifen.
Verständnis von LST und Transklusion
Die Labeled Section Transclusion (LST)-Erweiterung verwendet die Tags <section begin="..."/> und <section end="..."/> im Wikitext, um Bereiche zu kennzeichnen. Um diese Bereiche einzufügen, nutzt man {{#lst:Page|SectionName}} oder {{#lsth:Page|SectionName}} – mit "h" für den Header. Es gibt auch eine Funktion {{#lstx:}} für mehrere Abschnitte.
Durchsuchen der Webdokumentation zu Labeled Section Transclusion
Abrufen der Details zu den Parserfunktionen von LST
LST ermöglicht es, Abschnitte mit <section begin/end> zu kennzeichnen, und bietet Parserfunktionen. Ich sollte die spezifischen Details zu diesen Funktionen auf der entsprechenden Erweiterungs-Seite nachlesen. Es wäre sinnvoll, die Seite zu öffnen und zu prüfen, was genau dort beschrieben wird.
Öffnen der Erweiterungsseite für Parser-Funktionen
Überprüfung der Kategorie-Richtlinien für LST
Die Seite beschreibt nützliche Details, wie {{#lsth:pagename}} für die Transklusion vor der ersten Überschrift verwendet wird, und erwähnt Funktionen wie #lst, #lstx und #lsth. LST behandelt
Überlegungen zum Umgang mit Kategorien bei Transklusion
Kein Hinweis auf Kategorien auf der Seite. In der „Limitations“-Sektion könnte es Einschränkungen bei verschachtelten Transklusionen oder der Notwendigkeit, Markierungen im Text zu haben, geben. Um Nikolaos’ Anforderungen zu erfüllen, könnten wir eine Vorlage erstellen, die Kategorien beim Transkludieren ignoriert, aber normal anzeigt.
Lösungen zur Kategorientransklusion
Zur Erkennung von Transklusionen gibt es Magische Wörter wie {{PAGENAME}} und {{SUBPAGENAME}}, aber {{REVISIONID}} ist nicht ideal. Um Kategorien für Transklusion zu steuern, könnte man sie im Quelltext abdecken, indem man <noinclude> nutzt, sodass sie nicht in die Zielseite gelangen. Wenn Kategorien dynamisch hinzugefügt werden müssen, könnte ein Template helfen.
Steuerung der Kategorientransklusion
Es gibt Magische Wörter wie {{REVISIONID}}, aber sie helfen nicht, die Transklusion zu erkennen. Eine Lösung könnte sein, <includeonly> für Template-Inhalte zu verwenden, die bei der Transklusion angezeigt werden, während <noinclude> nur auf der Vorlage-Seite erscheint. Um Nikolaos’ Anforderungen zu erfüllen, könnten Kategorien nur auf der Quellseite angewendet werden.
Kategorien außerhalb von <includeonly> setzen
Die Kategorien sollten entweder außerhalb von <includeonly> oder in <noinclude> gesetzt werden, damit sie nur auf der Quellseite erscheinen. Auf normalen Seiten bleibt das Verhalten der Tags wie erwartet – <onlyinclude> wählt aus, was gezeigt wird, und <noinclude> sorgt dafür, dass bestimmte Teile nicht übertragen werden. Der Wunsch ist, diese Kategorien in <noinclude> zu erhalten.
Kategorien auf der Quellseite anwenden
Wenn Kategorien in einem Template via <noinclude> gesetzt sind, verhindern sie, dass diese auf der Zielseite erscheinen, wenn nur Teile der Seite transkludiert werden. Eine Lösung könnte sein, ein Template zu erstellen, das Kategorien nur auf der Quellseite einfügt, aber nicht auf der Template-Seite selbst. Aber das ist noch nicht ganz klar.
Kategorisierung auf der Quellseite sichern
Was er braucht, ist ein Template, das Kategorien auf der Quellseite hinzugefügt werden, aber nicht auf transkludierten Seiten. Beispielsweise wird mit einem Template wie {{Kats|A|B}} innerhalb von <noinclude> nur die Quellseite kategorisiert. So werden Kategorien geschützt und erscheinen nur dort, nicht auf transkludierten Seiten.
Verhalten von `<noinclude>` und Kategorisierung
Wenn das Kats-Template Kategorien in <noinclude> einfügt, wird auf der Quellseite keine Kategorisierung vorgenommen, aber auf der Template-Seite selbst werden die Kategorien angezeigt. Bei der Transklusion auf einer anderen Seite werden diese Kategorien supprimiert, was jedoch die Template-Seite anstatt der Quellseite betrifft – was nicht gewünscht ist.
Kategorien und transklusionseffekte verstehen
Die Kategorien sollten direkt auf der Quellseite innerhalb von <noinclude> platziert werden, damit sie nur auf der Quellseite gelten und bei der Transklusion nicht übernommen werden. Um dies zu standardisieren, könnten Benutzer angewiesen werden, den Aufruf in <noinclude>{{Kats|...}}</noinclude> einzufügen, um Transklusion zu verhindern. Doch er möchte das automatisch ohne manuelles Eingreifen erreichen.
Sicherstellen, dass Kategorien nicht in Transklusionen erscheinen
Auf einer normalen Seite sorgt <onlyinclude> nur dafür, dass Inhalt beim Transkludieren sichtbar wird. Kategorien innerhalb von <onlyinclude> erscheinen jedoch ebenfalls und werden auch in Transklusionen übernommen, was nicht gewollt ist. Eine gute Lösung wäre daher, die Seite mithilfe von Labeled Section Transclusion zu strukturieren und Kategorien außen zu platzieren.
Erklärung der Labeled Section Transclusion und Kategoriefilter
Mit {{#lst:Seitenname|extract}} stellen wir sicher, dass nur der Text und nicht die Kategorien transkludiert werden. Bei Labeled Section Transclusion (LST) werden Kategorien nicht weitergegeben, wenn sie außerhalb des markierten Bereichs bleiben. Ein zusätzliches Hilfe-Template könnte Kategorien nur auf der Quellseite anzeigen, indem es <noinclude> verwendet.
Zusammenfassung von Lösungen für Kategorientransklusion
Labeled Section Transclusion (LST) ist eine effiziente Methode, um Teile einer Seite zu transkludieren. Kategorien müssen bewusst außerhalb des markierten Bereichs liegen, um eine ungewollte Transklusion zu vermeiden. Eine maßgeschneiderte Lösung könnte darin bestehen, Kategorien auf der Quellseite mit <noinclude> zu verwenden, um ihre Ausbreitung zu verhindern, während LST die effiziente Handhabung des Inhalts ohne diese Kategorien ermöglicht.
Nachgedacht für 1m 23s
Fertig
Quellen·35

Kurzfassung: Labeled Section Transclusion (LST) erlaubt dir, Teilbereiche einer Seite gezielt zu transkludieren – u. a. „nur Einleitung (vor der ersten Überschrift)“, „nur Abschnitt X“, „alles außer Abschnitt Y“. Technisch markierst du Bereiche mit <section begin="…"/>…<section end="…"/> und holst sie mit Parserfunktionen wie #lst, #lsth und #lstx. MediaWiki

Was bringt dir LST hier konkret?

„Bis zur ersten Überschrift“ ziehen (ersetzt euer „Bereichsfenster“): {{#lsth:Seitenname}} holt die Einleitung (Text vor der ersten „==Überschrift==“). MediaWiki
Gezielt nur markierte Blöcke transkludieren (z. B. Zitate/Abschnitte): Quellseite:
```
<section begin="ZitatA" />
… Text des Zitats …
<section end="ZitatA" />
```
Zielseite: {{#lst:Seitenname|ZitatA}} Alternativ ein Überschrifts-Abschnitt: {{#lsth:Seitenname|Abschnittstitel}}. MediaWiki
Etwas bewusst ausschließen (z. B. „Anmerkungen“): {{#lstx:Seitenname|Anmerkungen}} transkludiert die Seite ohne den markierten Block (optional mit Ersatztext als 3. Parameter). MediaWiki

Kategorien sauber entkoppeln (kein „Gefummel“ beim Transkludieren)

LST ändert das Kategorien-Verhalten nicht: Kategorien, die im transkludierten Teil stehen, kategorisieren die Zielseite. Daher zwei bewährte Muster:

Kategorien außerhalb des LST-Bereichs halten (empfohlen): Quellseite:

<section begin="Inhalt" />
… kompletter transkludierbarer Inhalt ohne Kategorien …
<section end="Inhalt" />

<noinclude>
[[Kategorie:A]] [[Kategorie:B]] {{!-- oder über deine Kat-Vorlage --}}
</noinclude>

Zielseite: {{#lst:Seitenname|Inhalt}}

→ Kategorien greifen nur auf der Quelle; Zielseiten bleiben sauber. (Mechanik von <noinclude>/Transklusion) MediaWiki

Ungewollte Teile beim Vollzugriff ausschneiden Wenn du ausnahmsweise die ganze Seite ziehen willst, aber „Kat-Block“ ausblenden: Quellseite den Kat-Block labeln:
```
<section begin="KATS"/>{{Kats|…}}<section end="KATS"/>
```

Zielseite: {{#lstx:Seitenname|KATS}} (optional mit Platzhaltertext). MediaWiki

Hinweise/Details

LST ist auf allen Wikimedia-Wikis aktiv und bietet genau diese Teil-Transklusionsfunktionen (inkl. „vor erster Überschrift“). MediaWiki+1
Für schnelle Markierung auf Langtext-Seiten gibt es bei Wikisource sogar ein kleines Gadget („Easy LST“), das ## label ## in <section …/> umsetzt – nützlich, falls du viel labelst. MediaWiki

Wenn du willst, entwerfe ich dir eine kleine „Quote/LST“-Vorlage (mit Link-zur-Quelle und deiner navigation-not-searchable-Kapsel), damit du Zitate/Abschnitte einheitlich und suchneutral transkludierst.

Du:

Es endet so oder so immer in einem Gefummel im Quelltext.

Die Vorlage Bereichsfenster führt die Transklusion mittels Lua-Modul aus und rendert den Text für die Empfangsseite so, daß alles in der Quellseite vorhandenen Vorlagen und Kategorien nicht übernommen wird – so unbraucbar ist diese Vorlage also nicht – deine Anregeungen vermögen diese so nicht zu ersetzen.

Deine Vorschläge bedürfen auch der Überarbeitung, so auch dem Ausschluß aus den Suchergebnissen, daß sie so nicht haben – oder?

ChatGPT:

Aktivität

·23s
Denke nach…
Anerkennen der Lösung von Nikolaos und Bedenken
Ich sollte Nikolaos' Lua-basierte "Bereichsfenster"-Lösung anerkennen, die Quelleninhalt überträgt und Vorlagen sowie Kategorien entfernt. Es ist ein robuster Ansatz, um Transklusion zu steuern und Suchergebnisse zu vermeiden. Meine Aufgabe ist es, zu zeigen, wie man navigation-not-searchable integriert und diese Lösung mit klaren Wikitext/Lua-Anpassungen effektiver macht.
Überlegungen zur Erkennung von Transklusion in Lua
In Lua lässt sich nicht leicht feststellen, ob es sich um eine Transklusion handelt, obwohl es Parser-Funktionen gibt. Die Funktion frame:getParent() hilft, den Ursprung der Transklusion zu erkennen. Ich denke, wir sollten sicherstellen, dass die Ausgabe auf der Quellseite korrekt behandelt wird, vor allem bei der Verwendung von "Bereichsfenster".
Vorschlag für minimalen Patch zur Transklusion
Das Lua-Modul führt die Transklusion aus und stellt sicher, dass keine Vorlagen oder Kategorien der Quellseite in die Empfängerseite übernommen werden. Ein Wrapper für das "Bereichsfenster"-Template sollte einfach hinzuzufügen sein. Ich schlage vor, einen minimalen Patch mit „includeonly“-Wrapper plus Transklusionsausgabe vorzuschlagen.
Sicherstellung der Suchexklusion und sanitärer HTML-Code
Im Modul sollten wir beide Anforderungen gleichzeitig erfüllen: sanitäreren HTML zurückgeben und sicherstellen, dass die Suchergebnisse ausgeschlossen werden. Der Codebeispiel für das Template zeigt, wie man die navigation-not-searchable-Klasse hinzufügt. Wir sollten auch bestätigen, dass die Ausschlussfunktion mit CirrusSearch läuft und sicherstellen, dass alle relevanten Klassen korrekt zugeordnet sind.
Modulcode für sanitären HTML und Suchparameter
Im Modul sollten wir sicherstellen, dass sowohl sanitärer HTML-Code zurückgegeben als auch die Suchergebnisse ausgeschlossen werden. Das Beispiel zeigt, wie wir den navigation-not-searchable-Wrapper verwenden können. Wir müssen auch sicherstellen, dass diese Funktion mit CirrusSearch funktioniert, und bestätigen, dass die richtigen Klassen anerkannt werden.
Code-Änderungen und Suchausschluss bestätigen
Wir müssen sowohl für das Template als auch für das Modul Änderungen vornehmen. Die Option searchaux könnte hilfreich sein. Beim Sanieren von Kategorien und Vorlagen müssen wir robuste Patterns hinzufügen. Für den Ausschluss aus der Suche sollten wir unbedingt den navigation-not-searchable-Wrapper verwenden, um zu verhindern, dass transkludierter Inhalt in die Indexierung der Zielseite aufgenommen wird.
Proposing integration of search exclusion and sanitization
Lösungsansatz für Transklusion und Suchausschluss
Die aktuelle Herangehensweise ist gültig. Wichtig ist, sicherzustellen, dass der Wrapper navigation-not-searchable das bereinigte Ergebnis auf Zielseiten einfasst, um den Suchausschluss zu garantieren. Wir schlagen vor, den Minimalpatch für das Template zu liefern, ohne das Modul zu ändern. Alternativ wird die automatische Klassenzuweisung durch das Modul zur Sicherstellung des Suchausschlusses empfohlen.
Nachgedacht für 23s
Fertig
Quellen·27

Verstanden: Dein Bereichsfenster (Lua-gestützt, „sanitizer“) ist genau der richtige Ansatz, um Transklusions-Inhalte kontrolliert auszugeben (ohne Vorlagen/Kategorien). Für das Such-Thema fehlt dort nur noch der gezielte Cirrus-Hinweis.

Minimal-Patch: Suchausschluss direkt im Bereichsfenster

Pack den vom Modul gerenderten Output in der Vorlage (nicht im Quelltext der Inhalte) in den Cirrus-Wrapper. So bleibt alles zentral und transklusionssicher.

<!-- Vorlage:Bereichsfenster -->
<includeonly><div class="navigation-not-searchable">
{{#invoke:Bereichsfenster|render
 | seite={{{Seitenname|}}}
 | abschnitt={{{Abschnitt|}}}
 | ohneKat=1
 | ohneVorlagen=1
}}
</div></includeonly><noinclude>Dokumentation …</noinclude>

class="navigation-not-searchable" sorgt dafür, dass Transklusions-Text auf der Zielseite nicht indexiertwird; die Quelle bleibt normal durchsuchbar. MediaWiki
Falls du statt hartem Ausschluss nur Abwertung willst, nimm class="searchaux" (geringere Gewichtung, bleibt aber indiziert). MediaWiki

Optional: Umschaltbar machen (ignorieren ↔ abwerten)

Dann musst du die Vorlage nie mehr anfassen, nur Parameter setzen.

<includeonly><div class="{{#switch:{{lc:{{{modus|ignorieren}}}}}
 | abwerten = searchaux
 | #default = navigation-not-searchable }}">
{{#invoke:Bereichsfenster|render
 | seite={{{Seitenname|}}}
 | abschnitt={{{Abschnitt|}}}
 | ohneKat=1
 | ohneVorlagen=1
}}
</div></includeonly>

Verwendung:

{{Bereichsfenster|Seitenname=…}}              <!-- ignorieren (Default) -->
{{Bereichsfenster|Seitenname=…|modus=abwerten}}

Warum LST das nicht ersetzt

Labeled Section Transclusion löst sauber das „welcher Teil wird gezogen“–Problem (Einleitung/Abschnitt/Labels), ändert aber nicht das Suchverhalten. Ohne Wrapper würden die Zielseiten wieder mit-indiziert. Dein Bereichsfenster + Wrapper bleibt daher die richtige Kombination. MediaWiki+1

Wenn du willst, ergänze ich dir noch einen kleinen Selbstschutz im Modul

(z. B. leere Ausgabe bei Selbst-Transklusion) – aber funktional reicht der Wrapper völlig.

Du:

Die Vorlage Bereichfenster ist nicht in Verwendung, weil sie je nach Umstände Mängel aufweist, die wir noch nicht behoben und wir aufgrund anderer wichtigerere Aufgabenstellungen nicht zu Ende entwickelt haben.

Ich strebe eine Arbeitsweise an, die weitestgehend mit der Verwendung des VisualEditor auskommt und nur im Fall von noch nicht mittels Vorlagen und Modulen lösbaren Aufgabenstellungen den Quelltext direkt bearbeiten muß.

Die Verwendung von Tags wie vergleichsweise "<section begin="Inhalt" />" und "<section end="Inhalt" />" bedingen zum einen die Bearbeitung mittels Quelltext und zum anderen Programnmierkenntnisse, zumal darf man sich in deren Syntax keine Fhler erlauben. Man kann diese Tags auch nicht in zwei entsprechende Vorlagen packen und so mittels VisualEditor einbinden – oder?

ChatGPT:

Denke nach…

Beantworten der Benutzeranfrage zur Verwendung von VisualEditor und Vorlagen
Ich werde die Antwort auf die Benutzeranfrage in einem formellen, freundlichen und präzisen Ton verfassen. Sie möchten eine Methode zur Unterstützung von Transklusion ohne Suchindexierung und Kategorienweitergabe, die mit VisualEditor kompatibel ist. Ebenso möchten sie wissen, ob Tags im VisualEditor verwendet werden können.
Erforschen der VisualEditor-Kompatibilität mit LST und Transklusion
LST verwendet ParserFunctions und Tags wie <section begin/end /> – keine Vorlagen, sondern Marker. VisualEditor (VE) unterstützt Transklusionen und viele Erweiterungstags. Es scheint, dass VE ein Widget zur Sektionstransklusion bietet und es ermöglicht, eine Seite oder Vorlage einzufügen, wobei das Parameter "Nur eine Sektion" möglicherweise genutzt wird.
Überprüfung der VisualEditor-Unterstützung für LabeledSectionTransclusion
Bei Unsicherheit bezüglich aktueller Funktionen oder Details ist eine Websuche nötig, besonders bei komplexen Themen wie der Unterstützung von LabeledSectionTransclusion im VisualEditor. Auch wenn das Produkt stabil ist, können sich Details ändern, und eine erneute Überprüfung der verfügbaren Dokumentation ist ratsam.
Vorschlag für eine VE-freundliche Lösung zur Seiten-Transklusion
Wir sollten eine Vorlage entwickeln, die Seiten-Transklusion unterstützt und gleichzeitig die Option bietet, Kategorien und Vorlagen zu entfernen. Dazu könnte TemplateData und der VE-Dialog verwendet werden, um Parameter hinzuzufügen. Beim Abrufen von Seiteninhalten könnte Scribunto verwendet werden, jedoch sind darin einige Begrenzungen zu beachten.
Proposing VisualEditor-friendly solution for page transclusion
Wir sollten eine Vorlage entwickeln, die die Seiten-Transklusion unterstützt und dabei 'navigation-not-searchable' sowie optional Lua zur Entfernung von Kategorien und Vorlagen nutzt. Um VisualEditor zu unterstützen, könnten Tags wie <onlyinclude>, <noinclude> und <includeonly> verwendet werden, um Kategorien zu kontrollieren, ohne den Quellcode zu beeinträchtigen.
Proposing a VisualEditor-friendly template for category suppression
Um Kategorien zu vermeiden, können wir Vorlage:Transkludieren entwerfen, das Seitenname, Abschnitt und modus akzeptiert, mit einem optionalen ohne_kats-Schalter. Diese Vorlage kann LST für die Transklusion verwenden und Kategorien unterdrücken, indem nur Abschnitte ohne Kategorielinks transkludiert werden.
Finding solutions for category exclusion in VisualEditor
Um Kategorien zu vermeiden, wenn die ganze Seite benötigt wird, könnten wir Lua verwenden, um Kategorie-Links zu entfernen, bevor der Inhalt verarbeitet wird. Als VE-freundliche Lösung könnte man Vorlagen nutzen, die Lua-Funktionen verpacken und die Tags verwalten, ohne manuell tags hinzuzufügen.
Searching VisualEditor support for Labeled Section Transclusion
Verifying templating for section tags in VisualEditor
Es scheint, dass wir mit VE keine Tags in zwei verschiedenen Vorlagen verwenden können. Aber es sollte möglich sein, den Beginn und das Ende von Abschnitten mit Vorlagen darzustellen, die dann die entsprechenden Tags einfügen. Ich werde das weiter überprüfen, indem ich nach „Template section begin LST“ suche.
Searching for MediaWiki LST template section support
Zusammenfassung der Diskussion über LST-Tags und Templates
Die Beweise für das Hinzufügen von LST-Tags über Vorlagen sind nicht eindeutig. Es gibt jedoch eine Diskussion, dass das Transkludieren von Abschnittstags möglich ist. Wir können vorschlagen, auf Marker zu verzichten und #lsth für die Einleitung sowie #lsth:Seite|Abschnitt für Abschnitts-Transklusionen zu nutzen.
Vorschlag für eine Lösung zur Transklusion und Kategoriewahrung
Wir können einen VE-freundlichen Wrapper-Template entwickeln:

Vorlage:Abschnitt-Transklusion nutzt LST-Funktionen, um den Abschnitt oder die Einleitung transzukludieren und dabei Cirrus auszuschließen. Mit Parametern wie verlinken=1 für Quellverlinkung und anzeige=teaser|voll zur Steuerung der Absätze.

Für Kategoriewahrung könnte Lua genutzt werden, um Kategorien aus dem Wikitext zu entfernen.

LST umsetzen ohne manuelle Tags
Die Idee ist, eine Lua-Funktion zu erstellen, die Kategorien entfernt, indem sie sowohl die standardisierte "Category"-Bezeichnung als auch lokalisiertere Synonyme berücksichtigt. Zudem könnte die Funktion interwiki-Sprachlinks entfernen. Zum Problem der Tags: Ja, wir können #lsth verwenden, um die Notwendigkeit manueller Tags zu vermeiden, solange es sich um Abs
Lösungsansatz für VE-Markierungen und Template-Substitution
Das Talk-Page-Update weist darauf hin, dass Markierungen nur in rohem Wikitext funktionieren, Templates zur Tag-Erstellung ohne Substitution nicht geeignet sind. VE unterstützt subst:, aber das bleibt fragil. Wir schlagen vor, für VE-freundliche Workflows #lsth zu verwenden und Templates zur Auswahl der Seite oder Sektion zu erstellen. Die "Vorlage TransklusionSucheAus" ist weiterhin gut.
Vorschläge für Templates und Anpassungen
Ich schlage vor, eine Alternative zu ihrem bestehenden "ganzen Seite aber ohne Suche" Template zu bieten. Eine weitere Möglichkeit ist ein "VE-freundliches labeled section marker"-System, aber dafür bräuchten wir ein benutzerdefiniertes Tag-Extension, was etwas aufwendiger ist. Stattdessen könnten wir TemplateData zur Vorab-Ladung von Skeletons verwenden.
Verfahren zur Zitat-Transklusion mit VE-Unterstützung
Ich denke, eine gute Option wäre, ein „Inline-Template“ wie {{Zitat|id=...|Text=...}} zu verwenden, um Zitate zu strukturieren und zu formatieren. Diese könnten dann in dedizierten Unterseiten gespeichert werden, um sie später VE-freundlich durch {{:Seite/QuoteID}} zu transkludieren.
Empfohlene Vorgehensweise zur Transklusion
Für die Einführung oder nach Überschrift: Verwende LST #lsth in einem Wrapper-Template mit TemplateData für VE-Unterstützung. Für beliebige Fragmente: Ohne manuelle Marker oder Code ist der einzige robuste VE-first-Ansatz, das Fragment in eine eigene Seite oder Vorlage zu verschieben und diese zu transkludieren.
Vorschlag für Fragmentseiten und Workflow
Empfohlenes System: Verwende "Baustein"-Namespace für Fragmentseiten. Um eine Konvertierung zu ermöglichen, nutze "ReplaceText", um bei Bedarf Unterseiten für Fragments zu erstellen. Dies erleichtert die Bearbeitung per VE und hält Kategorien auf der Quellseite. Zur Suchexklusion weiterhin navigation-not-searchable verwenden. Kategorien sollten auf den Containerseiten bleiben, nicht auf den Fragmentseiten.
Antwortentwurf zur Nutzung von LST-Markern und VE
Zuerst anerkenne ich das Ziel des Nutzers. LST-Markierungen über Templates sind nicht sicher, außer mit subst, da LST die Markierungen vor
Nachgedacht für 58s
Fertig
Quellen·49

Ja — dein Eindruck ist richtig: Die LST-Marker müssen im Roh-Wikitext der Quellseite stehen. Sie per Vorlage ausgeben und so „indirekt“ setzen funktioniert nicht (außer über subst:-Workarounds), weil LST die Marker vor der Vorlagenexpansion sucht. Daher ist „zwei Vorlagen für begin/end und per VE einfügen“ keine verlässliche Lösung. MediaWiki

Damit du weitgehend im VisualEditor bleiben kannst, ohne „Gefummel“:

Lösungsvorschlag (VE-tauglich)

1. Abschnitte ohne Marker transkludieren (Lead/Überschrift)

Nutze LSTs heading-Variante: #lsth holt

ohne zweiten Parameter: den Text vor der ersten Überschrift (Einleitung),
mit Abschnittstitel: genau diesen Abschnitt. Das erfordert keine <section …/>-Marker in der Quelle. Wikipedia

Kombiniere das in einer kleinen Wrapper-Vorlage (VE-Dialog mit TemplateData), die auch gleich die Suche ausschließt:

<!-- Vorlage:AbschnittTransklusion -->
<includeonly><div class="{{#switch:{{lc:{{{modus|ignorieren}}}}}
 | abwerten = searchaux
 | #default = navigation-not-searchable }}">
{{#if:{{{Abschnitt|}}}
  | {{#lsth:{{{Seite|{{{Seitenname|}}}}}}|{{{Abschnitt}}}}}
  | {{#lsth:{{{Seite|{{{Seitenname|}}}}}}}}
}}
{{#if:{{{link|1}}}|<div>[[{{{Seite|{{{Seitenname|}}}}}}|▷ Quelle]]</div>|}}
</div></includeonly><noinclude>Doc …</noinclude>

navigation-not-searchable → Transklusionstext wird auf Zielseiten nicht indiziert (Quelle bleibt normal suchbar). Alternative: searchaux zum Abwerten statt Ausschließen. MediaWiki+1
Im VE fügst du einfach die Vorlage ein; Parameter Seite, optional Abschnitt, Schalter modus (= ignorieren/abwerten), link.

2. Beliebige Textausschnitte (feiner als Überschriften)

Ohne Marker bleibt als VE-freundlicher Weg: Fragmente auslagern (Subseiten oder „Baustein“-Namensraum) und diese transkludieren. Vorteile:

vollständig VE-editierbar,
Kategorien bleiben auf der Quell-/Containerseite; Fragmente enthalten keine,
mit dem gleichen Wrapper (oben) bleibt die Suche sauber. Praxispattern:
- Werk:XY/Frag/Zitat-001 (nur Text, keine Kategorien),
- auf Zielseiten: {{AbschnittTransklusion|Seite=Werk:XY/Frag/Zitat-001}}.

3. „Bereichsfenster“ später reaktivieren (optional)

Wenn ihr wieder Kapazität habt: Euer Lua-Sanitizer ist ideal, um Kategorien/Vorlagen vor dem Expandieren zu strippen und dann den bereinigten Wikitext via frame:preprocess auszugeben — eingebettet in navigation-not-searchable. Das bleibt VE-tauglich, weil Autor:innen nur die Vorlage einfügen.

Warum nicht „Marker per Vorlage“?

LST durchsucht beim Transkludieren die Rohfassung der Quellseite nach <section begin="…"/>…<section end="…"/>(oder {{#tag:section|…}}) bevor Vorlagen expandiert werden; Marker, die erst durch eine Vorlage entstehen, werden nicht erkannt (Ausnahme: subst: — aber das ist wieder Quelltext-Arbeit und fragil). MediaWiki

Wenn du willst, gebe ich dir die TemplateData für `AbschnittTransklusion`

fertig (mit Alias 1=Seite, Dropdown für modus) und eine kurze Migrationsliste (ReplaceText-Jobs, zwei Stichproben mit ?action=cirrusdump).

weiter siehe: Gespräch:Umgestaltung Modul:Bereichvenster und Modul:Seitenfenster zu Modul:Schaufenster

ChatGPT:

Variante A: Hart ausschließen (empfohlen)

Variante B: Als „Nebentext“ abwerten (statt komplett ignorieren)

Praktisch umsetzen

Verifizieren

Hinweise

Du:

ChatGPT:

1) Direkt im Wiki (ohne API)

2) Per API (skriptfähig)

Wichtige Hinweise

Du:

ChatGPT:

1) Tags vereinfachen (optional)

2) Selbst-Transklusion abfangen (optional)

3) Existenzprüfung – mit Augenmaß

4) TemplateData kleine Korrekturen + Komfort

5) Kategorien & Metadaten (nur wenn relevant)

6) Kontrolle/Verifizierung

Du:

ChatGPT:

Was bringt dir LST hier konkret?

Kategorien sauber entkoppeln (kein „Gefummel“ beim Transkludieren)

Hinweise/Details

Du:

ChatGPT:

Minimal-Patch: Suchausschluss direkt im Bereichsfenster

Optional: Umschaltbar machen (ignorieren ↔ abwerten)

Warum LST das nicht ersetzt

Wenn du willst, ergänze ich dir noch einen kleinen Selbstschutz im Modul

Du:

ChatGPT:

Lösungsvorschlag (VE-tauglich)

1. Abschnitte ohne Marker transkludieren (Lead/Überschrift)

2. Beliebige Textausschnitte (feiner als Überschriften)

3. „Bereichsfenster“ später reaktivieren (optional)

Warum nicht „Marker per Vorlage“?

Wenn du willst, gebe ich dir die TemplateData für AbschnittTransklusion

Wenn du willst, gebe ich dir die TemplateData für `AbschnittTransklusion`