Lua ist eine Skriptsprache, die im März 2013 in der deutschsprachigen Wikipedia verfügbar wurde.

• Die Funktionen werden über eine neue Parserfunktion ((#invoke:)) in eine umgebende klassische Vorlage eingefügt und ergänzen diese um allgemeine Hilfsfunktionen, die bislang schwer zu realisieren waren.
• Gegenüber Wikisyntax-Vorlagenprogrammierung bietet Lua vor allem bislang kaum mögliche Techniken im Zusammenhang mit Zeichenketten und größeren Mengen an numerischen Daten; nebst Analyse des Wikitextes der dargestellten Seite.
• In MediaWiki wird sie über die mw:Extension:Scribunto angebunden, die auch weitere Skriptsprachen ermöglichen würde.

Organisationsfragen der deutschsprachigen Wikipedia werden unter Wikipedia:Lua zusammengestellt.

Die Darstellung auf diesen Hilfeseiten trifft dagegen im Prinzip auf jedes beliebige Wiki zu.

Aufruf (in der Regel innerhalb einer Vorlage):
((#invoke: Modul-Titel | Funktionsname | Wert1 | Wert2 | NameX=Wert ... ))
Die Parameter können wie bei Vorlagen benannt oder unbenannt sein; es gelten prinzipiell analoge Regeln.

• Bei unbekannt von außen kommenden Inhalten sollten keine unbenannten Parameter verwendet werden, bzw. 1=Wert1 wie bei Vorlagen (verschärftes Gleichheitszeichen-Problem; kann zum Syntaxfehler führen).
• Der Rückgabewert der aufgerufenen Funktion ist eine Zeichenkette mit Wikitext, der entsprechend an dieser Stelle in den Artikel eingebettet wird.
• Beispiel: Modul:Hello – Demonstration: Hallo, Welt! Dies ist Lua!
• Zum Zeitpunkt des Funktionsaufrufes hat der Parser mehrere wichtige Schritte bereits abgeschlossen, insbesondere die Vorlagenexpansion und die Verarbeitung von Extension-Tags (<ref>, <pre>, <nowiki>, …). So würde eine direkte Ausgabe von ((Vorlage)) also nur zur Ausgabe des Textes ((Vorlage)) ohne die tatsächliche Vorlagenexpansion führen. Bei Bedarf kann das aber alles innerhalb der Modul-Programmierung erfolgen.
• Die Ausführungsumgebung wird bei jedem Aufruf von #invoke zurückgesetzt. Eine direkte Übernahme von Variablen zwischen zwei Aufrufen ist nicht möglich.
• Innerhalb der aufrufenden Vorlage erfolgen die einzelnen Aufrufe von #invoke sequentiell und unter Verwendung der gleichen (nur wenig auswertbaren) Elternumgebung.
• Verschiedene Einbindungen der Vorlage selbst (z. B. in einem Artikel) werden dagegen parallel abgearbeitet und teilen auch keine Elternumgebung.

Ein Aufruf von #invoke unmittelbar in einem enzyklopädischen Artikel oder einer allgemeinen Projektseite ist absolut unerwünscht. Diese Aufrufe sollen immer in Vorlagen verpackt sein; ausgenommen sind solche Projektseiten, die sich spezifisch mit Lua beschäftigen (WP:Lua/***).

• Schachtelungstiefe und Größe (Expansion) werden durch Lua zwangsläufig reduziert. Seiten, die bislang nicht dargestellt werden konnten, lassen sich nun ohne Sprengung der Limits anzeigen.
• Der Zeitverbrauch für die Gesamtdarstellung einer Seite mit Nutzung komplexer Vorlagenprogrammierung lässt sich auf etwa ein Drittel reduzieren, wenn die Vorlagensyntax durch gleichwertige Lua-Module ersetzt wird.
• Bei einer Seite mit vielen sehr einfachen Vorlagen könnte die Performance dagegen verschlechtert werden, falls jede einfache Vorlage durch eine Lua-Benutzung ersetzt würde: Jeder Start einer Lua-Funktion kostet ein gewisses Eintrittsgeld, das durch Ersatz einer bisher komplizierten Vorlagenprogrammierung erst einmal erwirtschaftet werden muss. Wird nur eine einfache Vorlage ersetzt, so war diese möglicherweise effizienter gewesen.
• Alle Lua-Module einer Seite sind auf eine kumulierte Prozessor-Zeit von 10 Sekunden begrenzt. Diese Zeit wird wie die Nutzung anderer Ressourcen im HTML-Quellcode als PP-Report des Präprozessors ausgewiesen. In Zeiten hoher Serverbelastung kann die Ausführungszeit bis auf das Vierfache steigen. Deshalb sollte, wenn in günstigen Zeiten eine Gesamtzeit von 2 Sekunden erreicht wird, eine Code-Optimierung (kaum signifikant zu erwarten) oder eine Aufteilung übergroßer Seiten überlegt werden.
• Ein weiterer Flaschenhals können die „teuren“ Funktionen sein. Ihre Anzahl pro dargestellter Gesamt-Seite ist auf 500 begrenzt. Dazu zählt unter anderem die Abfrage nach der Existenz von Seiten und Dateien.

Siehe auch: Hilfe:Vorlagenbeschränkungen.

Organisation der Seiten

• Die Quellcodes stehen in einem eigenen Namensraum Modul: auf Seiten, die „Modul“ genannt werden.
  • Jedes Modul enthält eine oder mehrere Funktionen in Lua.
  • Mittels #invoke, require() oder in geeigneten Fällen mw.loadData() kann eine komplette Modulseite geladen werden.
• Ausschließlich Seiten aus dem Namensraum Modul: können für die Auswertung benutzt werden.
  • Benutzer-Unterseiten sind nicht möglich; ausgenommen solche in Hierarchie der Vorlagenspielwiese.
  • Auch alle Unterseiten im Modul-Namensraum gelten als Lua-Quellcode und werden nicht als Wikitext dargestellt. Nur die Unterseiten gemäß dem vereinbarten Schema für die Dokumentation gelten als Wikitext.
  • Eine Seite mit Lua-Quellcode hat das Content Model "Scribunto".
• An jede Quellcode-Seite ist eine Dokumentationsseite angebunden, die auch genutzt werden soll. Sie bildet sich aus dem Seitennamen als Unterseite /Doku.
• Vorlagen sind im Lua-Quellcode nicht wirksam; SLA müssten auf WP:A/A gestellt werden oder mit Verweis auf die Oberseite (Modul) in der Dokumentationsseite. Eine unmittelbare Kategorisierung ist ebenfalls nicht möglich.
• Module werden verwaltet wie Vorlagen (Einbindung von Seiten). Sie erscheinen auch unter „Links auf de Seitn“, selbst wenn sie nicht mittels #invoke eingebunden sind, sondern durch require() aufgerufen werden. Werkzeuge zählen etwa die Zahl der Einbindungen.

Weiterleitungen und Verschiebungen

Weiterleitungen von einer Modulseite zu einer anderen sind nicht möglich. Eine „Weiterleitung“ würde Wikisyntax statt Lua-Quellcode erzeugen und (anders als im Fall von Vorlagen) alle Einbindungen und require() des Moduls zum Auswerfen von Syntaxfehlern bringen; deshalb könnte eine Weiterleitung noch nicht einmal ohne Weiteres abgespeichert werden.

Wenn der Name eines Moduls nicht mehr geeignet erscheint, muss die Existenz von Lua-Quellcode unter den programmierten Namen gesichert bleiben. „Normale“ Verschiebungen sind nicht möglich. Bei produktiv genutzten Modulen, die bereits von sehr vielen Seiten eingebunden sind, ist die Prozedur recht umständlich; insbesondere wenn bereits mehrere Entwickler mitgewirkt hatten.

• Zuerst ist ein neues Modul unter dem künftigen Namen anzulegen und mit dem Quellcode zu füllen.
• Wenn mehrere Benutzer an der Programmierung beteiligt waren, ist auf WP:IU Versionsimport innerhalb desselben Projekts zu beantragen.
• Dann sind alle Nutzungen auf den neuen Namen umzusetzen.
• Die Verwendung in den dargestellten Seiten einschließlich require() wird auf Spezial:Linkliste angezeigt. Diese Liste muss schließlich leer sein.
• Zuletzt ist das veraltete Modul zu löschen.

Allerdings kann bis zur Auflösung aller Nutzungen eine einheitliche Funktionalität erreicht werden, indem als einzige Zeile vorgehalten wird: return require( "Modul:NeuerName" )

Solange das Modul noch nicht produktiv genutzt wird, kann es jedoch einfach verschoben werden.

Seiten-Bearbeitung

• Bei Bearbeitung der Quellcode-Seite wird der CodeEditor zugeschaltet.
• Eine Debugging-Konsole wird angezeigt.
• Module können in einer Vorlagen-Umgebung (innerhalb einer anderen Seite) getestet werden.

Siehe dazu: Hilfe:Lua/Quellcode und Vorschau

Das Speichern von fehlerhaften Lua-Modulen ist seit Oktober 2014 nicht mehr möglich.

Syntaxhervorhebung und Zeilennummern

Bis zu einer gewissen Maximalgröße der Seite werden die Syntaxelemente in unterschiedlichen Farben dargestellt. Seit Anfang 2021 werden auf Code-Seiten auch Zeilennummern angezeigt.

• Eine Verlinkung auf eine bestimmte Zeile ist möglich mit dem Fragmentbezeichner #L-1, #L-2, #L-3 usw.
• Ein Klick auf die Zeilennummer hebt die aktuelle Zeile hervor, und in der Adresszeile des Browsers wird die geeignete Verlinkung auf diese Zeile dargestellt.
• In aktuellen Diskussionen kann auf die momentane Version verlinkt werden.
• Weil sich der vorangehende Code im Lauf der Zeit ändern kann, wäre ggf. ein PermaLink ratsam.

Die Maximalgröße von Seiten mit Syntaxhervorhebung, die eine farbige Auszeichnung bei zu großen Seiten unterbindet, verhindert dann auch die Generierung der Zeilennummern.

Spielwiese

Freies Ausprobieren kleiner Code-Fragmente auf kurze Zeit.

Für größere Entwicklungsarbeiten ermöglicht die Vorlagenspielwiese auch Quelltext-Module auf eigenen Benutzerseiten.

Hello

Demonstrationsmodul (Hallo, Welt!) – Hallo, Welt! Dies ist Lua!

Alle Benutzer

zum Beta-Testen durch mehrere Anwender mit

• Modul:Benutzerin:xxxxxxxxxxxx
• Modul:Benutzer:xyxyxyxyxyxy
• Unterseiten für Benutzer-Module sind möglich.
• Seite muss auch dort angelegt werden.

Vorlagenspielwiese

Alle Benutzer können mittels der Vorlagenspielwiese auf ihren Benutzerseiten eigene Module zum Testen verwalten. Mittels des Benutzerskriptes editorContent steht dann auch der CodeEditor zur Verfügung.

Außerdem sind testwiki:, test2wiki: (mit dem eigenen SUL-Account) und auch de.wikipedia.beta (separater Account nötig) nutzbar. In der echten dewiki sollten dann erst halbwegs ausgereifte Produktiv-Versionen auftauchen.

Siehe dazu Hilfe:Lua/Programmierung mit den Spezialthemen

• Modul im Wiki – Modul im Kontext einer Wiki-Seite
• Modul für eine bestimmte Vorlage
• Zeichenketten
• mw-Objekt – Funktionsbibliotheken
• Links – Seiten und URL
• Umgebung – aktuelles Wiki-Projekt
• Internationalisierung

Zur Sprache Lua allgemein siehe die als Weblinks angegebenen Handbücher.

• Quellcode kann in Textseiten mittels <syntaxhighlight lang="lua"> dargestellt werden.
• Der Inhalt eines ganzen Moduls kann farbig angezeigt werden mit:

  ((#tag:syntaxhighlight |((Modul:Hello))| lang=lua))

 MediaWiki: Extension:Scribunto/Lua reference manual – Freie Wikisoftware

• Ursprüngliches Lua-Handbuch; enthält Teile, die auf einem Wiki-Server nicht möglich sind:
  • Lua 5.1 Reference Manual – lua.org (englisch, portugiesisch)
  • lua.coders-online.net (deutsche Übersetzung des Handbuchs; JavaScript erforderlich)
• Coding conventions – Kodierungsstandard (englisch)
• Lua vs Javascript – Warum wurde Lua und nicht JavaScript gewählt? (englisch)
• Code-Beispiele:
  • lua-users.org (englisch)
• ELUA/* – Implementierung auf dem Wiki-Server

Vorlog:Wikipedia-Namensräume