Wikipedia:WikiProjekt Vorlagen/Werkstatt

Hallo, mir ist bei meinen Vorlagendokumentation und Testseiten öfters aufgefallen, dass sich Eingabe und Anzeige immer wieder mal unterscheiden durch Copy Paste Fehler meinerseits. Ich wollte eine Option haben, das zu beseitigen und Eingabe und Ergebnis mit einem Input abzubilden. Ich konnte dafür nun eine funktionelle Vorlage bauen. Momentan setzt die Vorlage auf das Prefix mm_, um Parameter spezifisch nur für die Hilfsvorlage zu kennzeichnen. Diese werden dann auch ausgefiltert bei Anzeige und Ausführung.

Edit, 2 weitere Beispiele (Knacknüsse) von Perfektes Chaos vorgeschlagen.--McBayne (Diskussion) 18:57, 7. Jul. 2026 (CEST)

Edit2, noch ein Beispiel 5, das aktuell klappt. Die Kollisionsgefahr ist sicher nicht riesig mit einem gescheiten Prefix.--McBayne (Diskussion) 19:16, 7. Jul. 2026 (CEST)

Edit3, Beispiele mit Problemen gemäss Ansatz Hgzh--McBayne (Diskussion) 16:30, 19. Jul. 2026 (CEST)

Beispiel 1 (1 Zeile pro Parameter, Ausgabe aus neuer Zeile):

{{Webarchiv
 |url=http://csis.org/files/publication/twq11summerkundnani.pdf
 |text=''Germany as a Geo-economic Power''
 |wayback=20131104194701
}}

Ergibt:

Germany as a Geo-economic Power (Memento vom 4. November 2013 im Internet Archive)

Beispiel 2 (alles in einer Zeile):

{{Webarchiv|url=http://csis.org/files/publication/twq11summerkundnani.pdf|text=''Germany as a Geo-economic Power''|wayback=20131104194701}}

Ergibt: Germany as a Geo-economic Power (Memento vom 4. November 2013 im Internet Archive)

Beispiel 3 (Ansatz Hgzh):

{{Zitat
 |Text=That’s one small step for man … one … giant leap for mankind.
 |Sprache=en
 |Autor=Neil Armstrong
 |Quelle=O-Ton
 |Übersetzung= Das ist ein kleiner Schritt für den Menschen … ein … riesiger Sprung für die Menschheit.
 |ref=<ref>am 21. Juli 1969 betrat [[Neil Armstrong]] als erster Mensch im Rahmen des [[Apollo-Programm]]s der [[NASA]] den [[Mond]] ([[:Datei:Neil Armstrong small step.wav|O-Ton]] von [http://science.ksc.nasa.gov/history/apollo/apollo-11/apollo-11-info.html science.ksc.nasa.gov])</ref>}}

Ergibt:

Beispiel 4 (Ansatz Hgzh):

{{Infobox Pokerspieler
 | Bild               = Vivek Rajkumar 2008.jpg
 | Bildunterschrift   = Vivek Rajkumar (2008)
 | Geburtsdatum       = [[1. Juni]] [[1986]]
 | Geburtsland        = {{IND}}
 | Sterbedatum        =
 | Sterbeort          =
 | Spitzname1         = Flog
 | Nickname1          = Psyduck101
 | Plattform1         = PokerStars
 | Nickname2          = DwightSchrute
 | Plattform2         = partypoker
 | Nickname3          = Psyduck
 | Plattform3         = Full Tilt Poker
 | Wohnort1           = {{USA|Ziel=Las Vegas}}
 | Höchstes Preisgeld = 3.652.345
 | Gesamtes Preisgeld = 8.080.012
 | Bracelets          = 0
 | WSOP-itm           = 14
 | WSOP-Main-Event    = 197.
 | WSOP-Jahr1         = 2013
 | WSOP-Jahr2         = 2015
 | WPT-Titel          = 1
 | WPT-itm            = 10
 | EPT-Titel          = 0
 | EPT-itm            = 1
 | PPL-Titel          =
 | PPL-itm            =
 | Stand              = 2020-02-25}}

Ergibt:

Schnelle Fakten WikiProjekt Vorlagen/Werkstatt, Personenbezogene Informationen ...

WikiProjekt Vorlagen/Werkstatt
Vivek Rajkumar (2008)
Personenbezogene Informationen
Geburtsdatum	1. Juni 1986
Geburtsland	Indien Indien
Spitzname	Flog
Nicknames	Psyduck101 PokerStars DwightSchrute partypoker Psyduck Full Tilt Poker
Wohnort	Vereinigte Staaten Las Vegas
Turnierpoker
Höchstes Live-Preisgeld	3.652.345 $
Gesamtes Live-Preisgeld	8.080.012 $
World Series of Poker
Bracelets	keine
Geldplatzierungen	14
Bestes Main Event	197. (2013, 2015)
Main Event der World Poker Tour
Titel	1
Geldplatzierungen	10
Main Event der European Poker Tour
Titel	keine
Geldplatzierungen	1
Letzte Aktualisierung: 25. Februar 2020

Schließen

Meinungen? Vielleicht gibt es das schon und ich habe es nur übersehen. Ansonsten könnte ich mir das als Untervlorage von Vorlage:Dokumentation vorstellen. Viele Grüsse--McBayne (Diskussion) 18:24, 5. Jul. 2026 (CEST)

1. [1]

   am 21. Juli 1969 betrat Neil Armstrong als erster Mensch im Rahmen des Apollo-Programms der NASA den Mond (O-Ton von science.ksc.nasa.gov)

Naja, mein allererster Eindruck war, dass wir für die Kopiervorlagen und dazu passend vorbildlich angepriesene Musterlösungen sehr viele Varianten von Leerzeichen und Anordnung von Pipes und Gleichheitszeichen haben: Wikipedia:Lua/Modul/TemplateData/Wikitext

Normalerweise lösen wir das stumpf, dumm und simpel: Der gleiche Quellcode wird untereinander geschrieben, einmal im syntaxhighlight und einmal ohne.

Ein „Ergibt“ braucht es heutzutage nicht mehr; es ist in aller Regel sonnenklar, dass syntaxhighlight der Wikitext ist, und irgendwo anders hin (einfacher Text direkt drunter, wo dein „Ergibt“ steht, aber float-Elemente ganz woanders) schreibt sich die generierte Wirkung.

Das mm_ kriegt garantiert irgendwer kaputt; muss dann schon seeehr ausgefallen sein, etwa _*_ oder so.

Insgesamt scheint mir dein System sehr viel komplizierter zu bedienen, um die garantierte Verhinderung von Klaffungen zwischen Code und Resultat mit Sicherheit auszuschließen, während wir das traditionell ohne Kenntnisse von Spezialsoftware mit dümmstem C&P für alle Menschen sofort verständlich bearbeitbar und nachvollziehbar in den Doku-Seiten hinterlassen. Die gute Absicht seh ich schon, aber alle Leute die was mit Vorlagen machen, müssen auch die Doku-Seite pflegen können, und TemplateData ist bereits Zumutung genug, geht aber nicht anders. Die vermeidet ja auch Duplizierung von unserer Darstellung mit Wikilinks und Formatierung, und absolut synchronisiert die im VE usw. dargestellte plain-text-Fassung.

Aber eine schöne Lua-Übung.

VG --PerfektesChaos 19:33, 5. Jul. 2026 (CEST)

Interessanter Gedanke grundsätzlich. In der Variante mit „abstrahierter“ Syntaxhervorhebung finde ich das auch etwas kompliziert, gegen eine Vorlage, die einen Syntaxhighlight-Block übergeben bekommt, anzeigt und diesen dann darunter expandieren lässt, hätte ich aber nichts, denn diese Copy&Paste-Fehler passieren mir auch oft genug. Gruß, -- hgzh 11:53, 6. Jul. 2026 (CEST)

„gegen eine Vorlage, die einen Syntaxhighlight-Block übergeben bekommt“

• Das wird nicht funktionieren.
• Bei einem MediaWiki-tag-Element wird sofort das Element durch einen Platzhalter ersetzt (strip, zumindest beim überkommenen Parsen), der Inhalt zur Weiterverarbeitung extra gepackt, und ganz am Ende bei der Seitenmontage wird der Platzhalter durch das Ergebnis der Auswertung ersetzt. Zwischenzeitlich sind die Inhalte nicht mehr erreichbar.
• nowiki wird zwar ggf. schon bei der Parameter-Übergabe aufgelöst, aber jeder Demo-Parameterwert müsste einzeln genowikit werden, und keiner darf absichtlich nowiki enthalten.

Ergo müsste der komplette Quelltext als Parameterwert übergeben werden.

• Da stehen erfahrungsgemäß ganz viele Pipes drin, und wirken. Die komplette Einbindung als Parameterwert wird expandiert.
• Alles an Leerzeichen und Zeilenumbrüchen wird sofort geschluckt und kann nicht rekonstruiert werden.

Wie läuft die /Doku ab?

• Zuallererst wird die Kopiervorlage oder aber TemplateData erstellt.
• Die Kopiervorlage wird wie gewünscht mit Leerzeichen und Zeilenumbrüchen formatiert.
• Danach geht es an den Beispiele​-Abschnitt. In den wird die Kopiervorlage kopiert und mit instruktiven Musterwerten ausgefüllt.
• Danach wird das, wenn es korrekt funktioniert hatte, 1:1 in den syntaxhighlight-Block kopiert. Manchmal auch umgekehrt. Und weitere Beispiele​.

Zu oben noch: In den Parameterwerten stehen immer mal wieder Vorlageneinbindungen, etwa {{DEU}} und die sollen mit Klammern als Wikitext gezeigt werden. Deine vorgeschlagene Lösung expandiert die aber sofort. Oder auch <ref>, und auch die erscheinen nicht in der Demo als Wikitext, sondern ggf. doppelt zusammen mit der Beispiel-Einbindung in der references-Sammlung, und hinterlassen in Syntaxhighlight nur ^[1] oder Syntaxschrott.

• Heißt: Man bricht sich an 87 Stellen die Finger. Und wenn drei Jahre jemand das Beispiel inhaltlich verbessern oder egänzen möchte, kommt das nach mehrstündigem Frust hier in der Werkstatt an.

Den Namen der Vorlage aus der /Doku- oder Hauptseite auslesen ginge übrigens nicht trivial, weil wir öfters den ersten Buchstaben klein schreiben, deshalb wohl "mm_Funktion".

• p.exec(frame) kennt ja frame und benötigt deshalb kein mw.getCurrentFrame(), das expandTemplate nimmt jeden.
• text = "<syntaxhighlight lang=\"wikitext\">" wäre Hilfe:Lua/Modul im Wiki #frame:extensionTag().

Testfälle:

• Vorlage:Zitat #Beispiel
• Vorlage:Infobox Pokerspieler #Beispiel

VG --PerfektesChaos 15:41, 6. Jul. 2026 (CEST)

Besten Dank für eure Rückmeldungen!

• Als erstes möchte ich festhalten, dass ich das definitiv umsetzen möchte. Es hat jedoch keine Dringlichkeit, deswegen schwebt mir ein Zeitrahmen 2026 vor, allenfalls braucht es halt ein paar Achtungs in der Hilfsvorlage, lieber natürlich ohne.
• Die Beispiele von Perfektes Chaos offenbaren gewisse Limitationen im ganzen Ansatz fürs Syntaxhighlight. Diese könnten allenfalls mit dem Vorschlag von Hgzh umgangen werden, aber ich hatte ähnliche Ansätze versucht und bin in den von Perfektes Chaos beschriebenen Fallstricken hängengeblieben.
• Ich werde mir trotzdem den Ansatz von Hgzh nochmals anschauen, evt. gibt es im Modul einen sicheren Ansatz das Syntaxhighlight wegzustrippen per String processing. Die Übergabe ans Modul muss dann aber natürlich mit dem bisherigen Ansatz klappen, der Teil hat bisher ja funktioniert. Ich schau mir dazu sicher mal die Doku etwas genauer an.
• Was ich noch weiters Rückfragen wollte: was genau in an meinem Ansatz so kompliziert? Ich finde es eigentlich schon recht einfach, man hat nur 2 zwingende Angaben: 1) Die Hilfsvorlage, 2) Der Name der gemeinten Vorlage. Alles andere wäre optionales Zeugs und die Defaultwerte sollten so gesetzt sein, dass dies für > 90% ohne Spezialconfig geht. Für das Syntaxhighlight könnte man sicher auch eine optionale Config einfügen, so dass man das direkt als zusätzlichen Parameter übergeben könnte
• Wegen dem "ergibt": Je nach Vorlage, kann die Antwort überraschend kurz sein oder auch leer. Deswegen wollte ich mit dem "ergibt" einen definierten Ort kennzeichen wo das Ergebnis auch wirklich aufzufinden ist. Ich würde das definitiv behalten wollten.
• Wenn die Limitationen geklärt sind, müsste dann noch ein geeigneter Vorlagenname gefunden werden, sowie falls noch notwendig, ein geschmeidiger Bezeichner für die Parameter der Hilfsvorlage, der kollisionsfrei ist.

Viele Grüsse, --McBayne (Diskussion) 19:12, 7. Jul. 2026 (CEST)

@ „Diese könnten allenfalls mit dem Vorschlag von Hgzh umgangen werden“

• Nein. Ganz grundsätzlich nicht. Nie.
• In dem Moment, wenn ein mw-Tag im Quelltext angetroffen wird, und noch bevor die Verarbeitung von {{ zur Expansion von Vorlagen und Parserfunktionen beginnt, wird der Bereich des tag herausgeschnitten und durch einen Platzhalter ersetzt („strip“, zumindest beim überkommenen Parsen).
• Der Bereich wird an die zuständige Extension übergeben, die das parallel weiter verarbeitet, während der Parser-Thread weiterläuft. Zum Schluss, bei der Montage des Gesamt-Inhalts, wird das Ergebnis der Extension für den Platzhalter wieder eingefügt. Im Fall von Syntaxhighlight ist das der HTML-Block mit den bunt angemalten Code-Fragmenten.
• Der Platzhalter sieht traditionell ungefähr wie folgt aus:
  "`UNIQ--syntaxhighlight-00000001-QINU`"
  • Ich hab da noch Apostrophe weggelassen, damit der Parser nicht durchdreht.
  • Die 00000001 ist eine fortlaufende Nummerierung aller syntaxhighlight in dieser Seite.
  • Die ref, nowiki usw. genauso, mit ihrem eigenen Keyword und Nummerierung.
  • Ist etwas archaisch und hacky, und könnte mit bewusst im Wikitext stehender Zeichenkette kollidieren.
  • Macht man eines Tages vielleicht eleganter, mit einem Array oder Baum geparster und bereits expandierter Textfragmente und einem gesonderten Datentyp statt einem Text-Platzhalter, aber ändert überhaupt nichts an der Reihenfolge.
• Damit kannst du dein Vorhaben grundsätzlich niemals realisieren:
  • Entweder es ist expandierbarer Wikitext, damit du die resultierende Darstellung anzeigen kannst. Dann sind im Moment der Übergabe von Parametern an Vorlagen oder Module mindestens die mw-tags bereits beiseite gepackt. Und alle Vorlageneinbindungen und Parserfunktionen wurden bereits in dem Moment expandiert gewesen, in dem sie im Parameterwert an dich übergeben werden, weil das die Grundregel der Vorbereitung von Parameterwerten ist.
  • Oder du forderst von den Anwendenden, dass sie jeden einzelnen Parameterwert gegen Verarbeitung schützen sollen. Dann ist der ganze Witz dahin, weil du mindestens jeden deiner Parameterwerte in nowiki stecken musst, und die Einfachheit kaputt ist.
    • Ggf. erscheinen die Escapes für deine Nutzung dann aber auch im Syntaxhighlight dargestellt. Dann funktioniert die Beispieldarstellung aber nicht mehr.
    • Und falls ein nowiki im Beispiel-Parameterwert vorkäme, stürzt dein System ab.
    • Wobei du dann aber ohnehin vermutlich nur die folgenden Parameterwerte zur Verarbeitung im Modul übergeben bekämst:
      • "`UNIQ--nowiki-00000007-QINU`"
      • "`UNIQ--nowiki-00000008-QINU`"
      • "`UNIQ--nowiki-00000009-QINU`"

@ „was genau in an meinem Ansatz so kompliziert?“

• Sowas findet immer nur der einfach der wo sich das ausgedacht hatte.
• Für alle anderen ist es eine massive Hürde.
• Und alle anderen müssen in den folgenden Jahren jede Vorlagendoku möglichst einfach aktualisieren und weiter ausbauen können. Das verhinderst du.
• Um die Darstellung des Beispiels zu erreichen, jeden Parameter auf einer neuen Zeile, zuerst ein Leerzeichen, dann die Pipe, danach den Namen direkt folgend, aber dann alle Gleichheitszeichen untereinander, rechts neben jedem Gleichheitszeichen ein Leerzeichen, muss man sich massiv mit deiner Technik befassen. Und man muss sich mit allen deinen Spezial-Parametern beschäftigen und sich darin einarbeiten, damit das herauskommt, was sich mit plumpem C&P des Beispiel-Wikitexts seit Jahrzehnten ohne irgendwelche Kenntnisse intuitiv hinbekommen lässt (früher mit <pre>).
• Sobald ein {{DEU}} im Parameterwert auftauchen soll, explodiert alles.

@ „dass ich das definitiv umsetzen möchte“

• Sollte ich es jemals irgendwo in einer unserer Vorlagendokus vorfände, werde ich es unverzüglich eliminieren, damit die einfache Bearbeitbarkeit unserer Vorlagendokus durch alle Menschen im Projekt erhalten bleibt.
• Schon unser TemplateData ist eine Zumutung, aber zur Vermeidung von Inkonsistenz zwischen dem VisualEditor und der formatierten Darstellung mit funktionierenden Verlinkungen usw. unvermeidlich. Und die liegen deutlich weiter auseinander und sind sehr viel unübersichtlicher als die direkt beisammen stehenden Wikitexte mit/ohne Syntaxhighlight.
• Die Beispiele werden mit intuitiv für alle Menschen verständlichem Prozedere erstellt: Kopiervorlage in den Beispiel-Abschnitt kopieren, mit instruktiven Beispielwerten ausfüllen, in der Vorschau testen, dann Wikitext zwischen die im Doku-Formular schon vorbereiteten Syntaxhighlight-Tags kopieren.
  • Falls ein Beispiel mal geändert wird, muss halt dran gedacht werden, das wieder zu kopieren. Ist machbar.
  • KISS – Keep It Simple and Stupid.

VG --PerfektesChaos 21:05, 7. Jul. 2026 (CEST)

Das geht schon, wenn man nicht syntaxhighlight verwendet (hat dieses Problem), sondern den Wikitext eingeschlossen in nowiki übergibt. Modulcode:

local p = {}

p.ExampleWithDemo = function( frame )
	local wikitext = frame.args[ "wikitext" ]
	local clean = mw.text.unstripNoWiki( wikitext )

	local hl = frame:extensionTag( "syntaxhighlight", clean, { lang = "wikitext" } )
	local exec = frame:preprocess( clean )

	return hl .. "\n\n" .. exec
end

return p

und Aufruf per

{{#invoke:ExampleDemo|ExampleWithDemo|wikitext=<nowiki>{{Achtung|1=Test}}</nowiki>}}

macht genau dies (Beispiel auf Beta). Es funktioniert nicht alles, aber für 08/15-Kram wie Vorlage:Monumentale_Eichen#Beispiele halte ich das schon für hilfreich. Für kompliziert halte ich im vorgestellten Ansatz die Erfordernis, die Formatierung der Kopiervorlage bzw. des Beispielcodes abstrakt angeben zu müssen, das einfach natürlich im Beispiel anzugeben finde ich intuitiver. -- hgzh 08:56, 8. Jul. 2026 (CEST)

Entweder, es funktioniert für mit alles, und alle Menschen können auf Jahre intuitiv jede Vorlagendoku in jeder Weise weiterentwickeln, oder wir lassen das besser bleiben und irritieren niemanden mit noch mehr Nerd-Zeugs (POLS). Die Vorlagen alleine sehen diverse Leut schon als Zumutung an.

• Ein nowiki in einem Wert schießt das schon wieder ab.

Die Methodik erfordert, dass unstripNoWiki auf Ewigkeiten die Rekonstruktion des Inhalts ermöglicht.

• Das hatte der Legacy-Parser als "`UNIQ--nowiki-00000003-QINU`" geplatzhaltert, mit Parsoid dann wohl {{#parsoidfragment:9}}.
• Ich trau dem Laden nicht, dass sie auch hier (ausnahmsweise) den gebunkerten Inhalt der Extension wieder rausrücken werden. Deshalb hacky.

VG --PerfektesChaos 11:43, 8. Jul. 2026 (CEST)

Danke für eure Rückmeldungen. Das ist echt eine üble Geschichte, dass die Inhalte von Tags nicht wirklich zugänglich sind. Verstehe die Bedenken, dass das mit dem nowiki-Tag auch eines Tages wegfallen könnte und dann ist der Kram kaputt (also der Hgzh Ansatz). Habe mir noch nicht wirklich eine Meinung gebildet wie ich das finden soll.--McBayne (Diskussion) 17:11, 11. Jul. 2026 (CEST)

Ich habe mir nochmals den Ansatz von Hgzh angesehen und kann mich mittlerweile sehr damit anfreunden. Ich verstehe jedoch auch nach wie vor die Bedenken. Mir geht es vor allem um aufwändige Dinge und ich denke, dass der einfache, bestehende Ansatz für sehr viele Anwendungsfälle ideal ist, da einfach und langzeitstabil. Aber gerade bei Vorlagen mit sehr vielen Parametern und für Testseiten von Vorlagen mit sehr vielen Testfällen (bin dort auch schon oft "verrutscht") sehe ich aber weiterhin einen Nutzen und schlage entsprechend eine Nutzung nur für solche Bereiche vor, in denen der klassische Ansatz die Fehler fördert und deswegen oftmals durch Fehler Eingabe und Ausgabe unterschiedlich sind. Der Ansatz von Hgzh scheint mir auch ziemlich viele Ausnahmen zu beherrschen, zunächst ist es am <ref>-Tag gescheitert, aber da man Zugriff auf den String hat, kann man den sehr spezifisch auch reparieren.--McBayne (Diskussion) 16:30, 19. Jul. 2026 (CEST)

Das ist nicht dauerhaft, nicht nachhaltig.

Alle Parser seit 2000, wohl fünf???, haben mit Textersetzung gearbeitet. Im Prinzip und am Anfang tatsächlich mit RegExp-Ersetzungen. Ich war im Zweifel, ob das angepriesene Parsoid immer noch so arbeitet, aber #parsoidfragment: zeigt, dass es weiterhin so läuft; grob wie folgt skizziert:

• Zuerst werden alle __ und manche Parserfunktionen gesucht, die keinen Text produzieren, und diese Attribute beiseite in eine Liste geschrieben.
• Danach wird der gesamte Text erneut durchgekaut; jetzt alle mw-Tag-Elemente durch einen Platzhalter ersetzt. Die Tag-Elemente werden an die zuständigen Extensionen zur ggf. parallelen Weiterverarbeitung übergeben und deren Eingabe wie Resultat gestapelt.
• Danach wird der gesamte Text erneut durchgekaut; jetzt alle {{ bis zum schließenden }} verschachtelt aufarbeiten.
• Danach wird der gesamte Text erneut durchgekaut; jetzt vielleicht die [[ und dann [ verarbeiten.
• Am vorläufigen Ende steht HTML-Code.
• Jetzt werden die Platzhalter durch die Resultate des Strip-Poker ersetzt.

Ein richtiger Parser würde anders arbeiten:

• Der Text wird nur ein einziges Mal durchgegangen. Bei jedem öffnenden Syntaxzeichen _{[< wird nach dem nächstfolgenden oder manchmal vorangehenden Zeichen geguckt, und dadurch ggf. ein neues Level eröffnet, bis schließende Syntaxzeichen gefunden werden. Oder weil ein Konstrukt wie <nowiki> eröffnet wurde.
• Da gibt es kein unstripNoWiki mehr.

Die Methodik würde deshalb von der Parser-Implementierung abhängen, und das darf nicht sein.

In Wikipedia:Lua/Modul/Multilingual/Test verwende ich die Methodik ja auch, zusammen mit integriertem Modultest. Aber das mute ich nicht der breiten Community für beliebige Vorlagen zu, sondern träfe nur Leute mit Lua-Skills.

VG --PerfektesChaos 19:20, 19. Jul. 2026 (CEST)

Der „klassische Ansatz“ funktioniert hier m.E. nicht, weil im Wikitext erlaubt ist, dass ein schließendes Syntaxzeichen oder ein zweiter Teil eines öffnenden Syntaxzeichens erst durch eine Expansion eingefügt wird und der Kontext damit plötzlich ein anderer ist.

Nichtsdestotrotz ist unstripNoWiki ja kein Hack, sondern eine offiziell bereitgestellte Bibliotheksfunktion für die Lua-Integration, auf deren Bereitstellung man sich schon erstmal verlassen kann. Der Inhalt zwischen nowiki geht ohnehin in einer abweichenden Parserimplementierung nie verloren. -- hgzh 14:22, 20. Jul. 2026 (CEST)

Das funktioniert mit einem 1-transition-Parser problemlos; ich hab vor 30–40 Jahren mal mehrere Parser gebaut. WSTM ist ein müder Abklatsch davon.

• In einem eröffneten nowiki-pre-syntaxhighlight-Modus gibt es keine „erst durch eine Expansion“ mehr; alles bis zum im Klartext vorgefundenen </nowiki> gehört zum finalen Text.

Wenn ich die Core-Funktion (anders als syntaxhighlight, was eine externe Extension ist) nowiki abgearbeitet habe, würde ich ein Objekt vom Typ finaler Text generieren, nur innendrin alle < durch < maskieren, erforderlichenfalls auch eckige Klammern, Pipes und Tilden, aber sofort vergessen, dass dieses Stück finaler Text mal aus nowiki entstanden war.

• Alle Objekte vom Typ finaler Text können sofort concatenated werden, weil schon finales HTML-Dokument.
• Nur auf Auflösung wartende Extensions blieben vorläufig separat.

@ „weil im Wikitext erlaubt ist, dass ein schließendes Syntaxzeichen oder ein zweiter Teil eines öffnenden Syntaxzeichens erst durch eine Expansion eingefügt wird“

• Das geht nur bei den Leveln später im Parsen, namentlich ], Tabellensyntax und HTML-Tags.
• Die Konstrukte Schalterfunktion, die ollen Magischen Wörter, }} und Vorlagenparameter sowie das End-Tag von MW-Elementen können nicht erst später „durch eine Expansion eingefügt“ generiert werden, sondern müssen auf gleicher Wikitext-Ebene vollständig sichtbar sein wie die Eröffnung.
• Demo.

Und unstripNoWiki basiert auf der antiquierten Textersetzungs-Parser-Methodik, und ist nur ein temporäres Zufallsprodukt, aber keine dauerhafte Eigenschaft der Wikisyntax. Hätte ein Implementierungsgeheimnis bleiben müssen und nie öffentlich gemacht werden dürfen.

VG --PerfektesChaos 17:52, 20. Jul. 2026 (CEST)

Könnte die Vorlage:KI-generiert um einen optionalen Parameter ergänzt werden, in dem auf einen entsprechenden Abschnitt auf Wikipedia:WikiProjekt KI und Wikipedia/Problemfälle verwiesen werden kann? Also wenn der Baustein z.B. in einem Artikel des Benutzers Ekab stünde, etwa Problemfälle=Benutzer:Ekab für diesen Abschnitt. Könnte das jemand einbauen, der beim Basteln von Vorlagen geschickter ist als ich...? Ein Ping auch an Nina. --Gestumblindi 20:17, 5. Jul. 2026 (CEST)

Auf die Seite mit Problemfällen wird ja bereits im letzten Link verwiesen. Es geht also darum, diesem Link ein optionales Abschnittsziel anzuhängen? -- hgzh 11:47, 6. Jul. 2026 (CEST)

Ja, genau, das wäre super. --Gestumblindi 12:02, 6. Jul. 2026 (CEST)

Ok, so umgesetzt -- hgzh 12:12, 6. Jul. 2026 (CEST)

Vielen Dank! --Gestumblindi 19:03, 6. Jul. 2026 (CEST)

Könnte die Vorlage bitte ebenfalls noch dahingehend angepasst werden, dass der Parameter {{{2|}}} mit Umbruch und kursiv unterhalb des statischen Textes platziert ist (so wie z. B. in {{Belege fehlen}})? In der aktuellen Version wird ein Kommentar direkt ohne Umbruch an den Anfang gestellt („Klingt wie ChatGPT Dieser Artikel oder Abschnitt ist […]“), das sieht unprofessionell aus und statischer Hinweis und Kommentar unterscheiden sich optisch nicht.

Und sollte evtl. auch {{KI-Verdacht}} an die obenstehende Änderung angepasst werden? --CommanderKefir (Diskussion) 23:18, 12. Jul. 2026 (CEST)

Hallo, in der EU-Rechtssetzung haben wir immer öfter den Fall, dass EU-Verordnungen oder EU-Richtlinien nur teilweise In Kraft treten und der entsprechende Teil der vorhergehenden Verordnung/Richtlinie ausser Kraft tritt. Oder Teile (bestimmte Artikel (§)) von Verordnungen/Richtlinien werden zeitversetzt gültig. Nach zur Diskussion gestelltem Vorschlag im Portal_Diskussion:Recht#Vorlage:Infobox Rechtsakt (EU) - Parameter "Gültig" ohne Widerspruch wäre eine Anpassung der Infobox, um eine Abbildung der rechtlichen Vorgaben zu erreichen, folgendermaßen:

 | vorschlagimprozess = !colspan="2" style="color:#ffffff; background: #000000;"{{!}} Regelung ist ein aktueller Vorschlag im Rechtsetzungsprozess.
 | inkraft = !colspan="2" class="hintergrundfarbe6"{{!}} Regelung ist in Kraft getreten, aber noch nicht anwendbar.
 | anwendbar = !colspan="2" class="hintergrundfarbe9"{{!}} Regelung ist in Kraft getreten und anwendbar.
 <s>| umgesetzt = !colspan="2" class="hintergrundfarbe9"{{!}} Regelung muss in nationales Recht umgesetzt worden sein.</s> KANN ENTFALLEN!
 | umsetzung = !colspan="2" class="hintergrundfarbe8"{{!}} Regelung muss aktuell in nationales Recht umgesetzt werden.
 | teilweiseaußerkraft = !colspan="2" class="hintergrundfarbe8"{{!}} Regelung größtenteils außer Kraft getreten.
|teilweiseinkraft = !colspan="2" class="hintergrundfarbe8"{{!}}Regelung größtenteils in Kraft getreten NEU!
 | außerkraft = !colspan="2" class="hintergrundfarbe7"{{!}} Regelung ist außer Kraft getreten.
 | nichtig = !colspan="2" style="background: #FF0000; color: #ffffff;"{{!}} Regelung wurde für nichtig erklärt.

Heißt: Die Zeile umgesetzt Regelung muss in nationales Recht umgesetzt worden sein kann entfallen, da durch vorhergehende Zeile abgedeckt. Zeile teilweiseinkraft Regelung größtenteils in Kraft getreten kommt neu hinzu.

Da @Benutzer:Bcoh der Ersteller der Vorlage ist pinge ich ihn hier mal mit an. Nach erfolgter Umsetzung bitte kurzen Ping an mich. Werde dann mal versuchen die Dokumentation und wann was zu verwenden ist zu verbessern. Danke. Gruß --Chief335 (Diskussion) 12:07, 17. Jul. 2026 (CEST)

@Chief335: Umgesetzt. Wer biegt die 105 Einbindungen von | gültig = umgesetzt um? --darkking3 ^Թ 15:30, 17. Jul. 2026 (CEST)

@Darkking3, @Bcoh wenn mir eine Liste der Artikel in denen die Infobox mit dem Parameter auf meine BenutzerDisk zur Verfügung gestellt wird, mache ich das. Danke. Gruß --Chief335 (Diskussion) 17:12, 17. Jul. 2026 (CEST)

Erledigt. Artikel mit umgesetzt zeigen derzeit sowieso den Text von teilweiseinkraft an, daher bitte melden, wenn das erledigt ist. --darkking3 ^Թ 17:31, 17. Jul. 2026 (CEST)

Hallo @darkking3. Habe den Archivieren Baustein gelöscht. Das Vorhaben scheint schwieriger zu sein, weil der durch das Wort bei Gültigkeit erzeugte Text anders ist als in der Doku zur Vorlage angegeben, und damit auch im oben angezeigten Wikitext, siehe: Benutzer:Chief335/Infobox. Werde den im Portal:Recht schon abgesegneten Vorschlag nochmals zur Diskussion stellen, da dies größere Auswirkungen in der Infobox hat (die ja dann ohne Änderungen für Jahre benutzt werden soll; viele Einbindungen). Ping an @Benutzer:Bcoh da Vorlagenersteller mWn. Danke Gruß --Chief335 (Diskussion) 15:57, 18. Jul. 2026 (CEST)

Hallo, die Überblicksgrafik der Fußball-Weltmeisterschaft 2026 wird auf dem Safari Browser nicht richtig dargestellt. Auf einem anderen Browser (Vivaldi - getrieben von einer Google engien) sieht es gut aus. Kann sich dem jemand annehmen? Problem: z.B bei den Gruppenteilnehmern E1, D3 und I1, F3 nach D3, I1 stimmt die Verbindungslinie nicht. Der obere Teil bei E1 D3 sieht gut aus, der untere Teil bei I1, F3 wo die Linie nur nach oben gehen müsste und mit der oberen zusammengeführt und nach rechts führt, geht auch nach unten. Screenshots siehe Diskussion Fußball-Weltmeisterschaft 2026. Vielleicht kann sich dem jemand bitte annehmen. Siehe auch Diskussion unter Fußball-Weltmeisterschaft 2026, Thema 'Überblick - wird auf dem Safari Browser nicht richtig dargestellt'. In der En Wikipedia, die eine ähnliche Grafik benutzt, sieht es richtig aus. Defekt evtl. in Vorlage:Turnierplan32-Platz3. Wenn ich helfen soll / kann, bescheidenen. Ich bin allerdings kein Programmierer. --GodeNehler (Diskussion) 16:30, 17. Jul. 2026 (CEST)

Siehe Antwort von Maphry. Die Darstellungsprobleme habe ich mit Safari auch.

Der Fix von en.wp lässt sich nicht mal eben umsetzen, da diese den Turnierbaum mit einem Lua-Modul erstellen. Muss man mal schauen, was da geht. Das Lua-Modul halte ich aber für völlig übertrieben mit dem ganzen damit entstehenden Syntaxmüll. --darkking3 ^Թ 17:50, 17. Jul. 2026 (CEST)

Hallo! Ich bin sicher nicht der Einzige, der mittels {{Spezial:Beiträge/Benutzername|limit=nnn}} Auflistungen der letzten nnn Edits von Benutzern erzeugt. Mir ist aufgefallen, dass diese Auflistungen jetzt Links in Form von nach oben zeigenden Pfeilen enthalten, die – zusätzlich störend – auch als Überschriften im Inhaltsverzeichnis erscheinen. Seit wann Spezial:Beiträge resp. Special:Contributions dieses merkwürdige Verhalten zeigt, kann ich nicht sagen. Beispielhaft vier Seiten, auf denen dieser Effekt beobachtet werden kann:

• die Benutzerseite von Denis Barthel
• die Gesamtliste meiner Mentees
• die Teilnehmerseite von GLAM/PKC Freudental 2024
• ein Disk.beitrag im hiesigen Archiv von 2017 ;-)

Bug oder Feature? Für mich eindeutig Ersteres... --rolf_acker (Diskussion) 10:42, 22. Jul. 2026 (CEST)

Witzig ist es irgendwie schon: unangemeldet habe ich das Problem in allen Skins, angemeldet in gar keinem. Allerdings scheint der erwähnte Pfeil sich auf eine Benutzereinstellung zu beziehen, da es diesen unangemeldet nicht gibt.

Ich habe angemeldet mit keinem Skin ein Problem. Da scheint wohl im Userbereich etwas ausgeblendet zu werden. Am besten lässt sich dies auf Wikipedia:GLAM/PKC_Freudental_2024/Teilnehmer nachvollziehen, da die Seite ein TOC hat. Unangemeldet wird ein TOC in Seiten erzeugt, die sonst keins haben (z.B. Benutzer:Rolf acker/Mentee-Gesamtliste) Es wird übrigens je Tag ein Eintrag im SeitenTOC vorgenommen und nicht je Beitrag.

In Wikipedia:Projektneuheiten scheint keine passende Änderung vermerkt. Bei Einbindungen scheint Spezial:Beiträge die beiträge neuerdings mit section-tags zu trennen, um ein TOC erzeugen zu können. Auch die Spezialseite gruppiert Edits von einem Tag seit längerem, gibt jedoch kein TOC aus. --darkking3 ^Թ 11:26, 22. Jul. 2026 (CEST)

Die Beitragsliste enthält schon länger Zwischentitel für jedes Datum. Diese Zwischentitel sind auf dem Desktop standardmäßig ausgeblendet, werden aber in der Mobilversion angezeigt. Das Problem tritt nur mit Parsoid auf. Bei den Pfeilen gehe ich davon aus, dass diese vom „Pfeil-hoch“-Helferlein kommen. -- hgzh 12:06, 22. Jul. 2026 (CEST)

die Zwischentitel werden (unangemeldet) auch auf dem Desktop angezeigt. Dass ich sie angemeldet nicht sehe, dürfte irgendwo an meinem User-Css oder den Einstellungen liegen. --darkking3 ^Թ 16:00, 22. Jul. 2026 (CEST)

Hallo WikiProjekt Voragen Werkstatt,

ich bin relativ neu bei Wikipedia, und gerade dabei, die vielen Möglichkeiten und Projekte des Wikiversums zu erforschen. Aktuell wollte ich eine Infobox-Vorlage für einen Artikel über eine Person verwenden, und habe festgestellt, dass es eine solche gar nicht gibt. Generell ist mein Eindruck, dass in der deutschen Wikipedia im Vergleich zu anderssprachlichen Wikipedias wenig mit Infoboxen gearbeitet wird, und wenn, dann mit statischen internen Links und weniger mit Wikidata-Parsern. Warum ist das so?

Hat es einfach noch niemand gemacht, oder gibt es Gründe, die dagegen sprechen? Komplexität oder Intransparenz etwa? Misstrauen gegenüber Wikidata?

Ich würde mir gern dynamische Infobox-Vorlagen für die Bereiche, zu denen ich in Wikipedia beitragen will, bauen, z.B für Künstler:innen. Gibt’s best-Practice dazu?

Dies Artikel hab ich bisher zum Thema gefunden:

• Hilfe:Wikidata/Daten aus Wikidata beziehen
• Kategorie:Vorlage:verwendet Daten aus Wikidata
• Wikipedia:WikiProjekt Wikidata in Wikipedia

p.S.: Ich habe eine IT-Abschluss und bin bereit, SPARQL zu lernen oder was sonst die geeigneten Mittel sind.

. LG Mnemoa --Mnemoa (Diskussion) 19:35, 23. Jul. 2026 (CEST)

Infoboxen, insbesondere zu Personen, sind hier in der deutschsprachigen Wikipedia sehr umstritten (unabhängig und auch schon vor dem Einsatz von Wikidata). Um das weitreichend zu ändern bedürfte es vermutlich eines Meinungsbildes. Zu einzelnen Personenkreisen wie Sportlern bestimmter Sportarten (für Fußballspieler gibt es z.B. Infoboxen) könnte womöglich eine Einigkeit innerhalb des jeweiligen Fachbereichs erzielt werden. Die Werkstatt ist aber vorher nicht zuständig. Wikidata und dessen Einbindung und Vor- wie Nachteile sind nochmal ein anderes Thema. --Mielas (Diskussion) 19:47, 23. Jul. 2026 (CEST)

Ich möchte hauptsächlich für den Kultur- und Geisteswissenschaftlichen Bereich Artikel verfassen und hab schon die dortige Redaktion angefragt, wie sie zu (dynamischen) Infoboxen stehen, siehe: Benutzer Diskussion:Conny. Ich fänd's halt eine sinnvolle Automatisierung, wenn mit Bedacht gemacht. Oder ist das ein ewiges leidiges Thema, wo sich die Mühe nicht lohnt? --Mnemoa (Diskussion) 19:56, 23. Jul. 2026 (CEST)

Wie es in einzelnen Fachbereichen dazu steht, weiß ich nicht. Für eine allgemeine Infobox Person müsstest du wie geschrieben vermutlich ein Meinungsbild anstreben. Im kleinen Rahmen wirst du das nicht nachhaltig durchgesetzt bekommen. Zudem ist das entsprechende Lemma auch schon seit langer Zeit schreibgeschützt: Vorlage:Infobox Person Für einzelne Personengruppen (insbesondere Sportler) gibt es durchaus Infoboxen: Kategorie:Vorlage:Infobox Person. Aber allgemein kann man das nicht beantworten. --Mielas (Diskussion) 20:09, 23. Jul. 2026 (CEST)

Ich habe mit der Geisteswissenschafts-Redaktion geschrieben und die wollen keine Infobosen. Ich lasse es besser mal. --Mnemoa (Diskussion) 07:58, 24. Jul. 2026 (CEST)