Hilfe:Lua/*

Einstieg

• 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.

Vorlagenprogrammierung

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/***).

Begrenzungen

• 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.

Modul-Namensraum

return require [[Module:NeuerName]]

Erprobung

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.

Programmieren in Lua

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
• Konzept der Trennung von Programm und Daten
• Internationalisierung

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

Darstellung von Quellcode

• 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}}

Quelltext und Seiten

• Alle Seiten im Namensraum Modul: (828) sind grundsätzlich der Quellcode zu je einem Lua-Modul. Dies wird nicht als Wikitext interpretiert. Das Content Model ist Scribunto.
• Nur Seiten, deren Name das Schema für Dokumentationen erfüllt, in der deutschsprachigen Wikipedia also auf /Doku endet, können Wikitext enthalten.
• Darüber hinaus gibt es die Möglichkeit, in bestimmten Unterseiten der Benutzer-Spielwiese im Rahmen der Vorlagenspielwiese Lua-Module wirksam werden zu lassen.
• Seiten anderer Namensräume können mit #invoke schon deshalb nicht genutzt werden, weil der Namensraum dieser Anweisung intern vorangestellt wird. Auch ein require() ist nur auf Seiten möglich, deren Inhalt als Lua-Quellcode gespeichert ist („Content Model“).
• Sonstige Unterseiten im Namensraum Modul: sollten nur nicht-selbstständigen Lua-Code enthalten:
  • Keine Vorlage oder ein anderes Modul sollte unaufgefordert derartige Seiten verwenden; ausgenommen durch mw.loadData() genutzte Datenmengen oder wenn eine solche Schnittstelle dokumentiert ist.
  • In der Regel ist es aus dem selbstständigen Modul ausgegliederter Code, wofür es unterschiedliche gute Gründe geben kann.
  • Es könnte auch ein unter dem Namen /test ausgegliederter unit test sein.

Kapselung

Die Module sind bewusst so gestaltet, dass keinerlei Zugriff von einer Einbindung mit #invoke auf eine andere oder den Inhalt der umgebenden Seite möglich ist. Einige trickreiche Versuche, dies zu unterlaufen, wurden nach kurzer Zeit unterbunden.^[1]

Ein Modul kann selbst keinerlei Veränderung an der Welt hervorrufen (sieht man davon ab, dass bei den „Links auf diese Seite“ durch Einbindung anderer Seiten ein Eintrag hinzukommen kann; oder dass es die Kategorie der Seiten mit Skriptfehlern bereichert). Es kann sich ausschließlich durch seinen Rückgabewert äußern, der letztlich in irgendeiner Weise auf eine Vorlagen-Einbindung oder sonstigen Seitentext wirken müsste.

Das Modul kann die Parameter der Vorlagen-Einbindung (oder einer sonstigen Seite, in der das #invoke vorkommt) auslesen. Ihm ist außerdem bekannt, wie die Gesamt-Seite heißt, die dem Benutzer dargestellt wird. Mehr kann das Modul über seine Umgebung (Elternumgebung) nicht herausfinden. Wie die Vorlage heißt, in der #invoke steht, lässt sich mit frame:getParent():getTitle() auch noch ermitteln (siehe unten). seinen eigenen Namen kann das Modul seit Anfang 2014 ermitteln.

Rückgabewert des Moduls

Die letzte Zeile eines Moduls muss eine return-Anweisung mit einem Rückgabewert sein. Fehlt dies, wäre der Wert immer nil.

Der Datentyp dieses Rückgabewerts ist im Prinzip beliebig. Verbreitet wäre table, aber auch eine function wäre vorstellbar; letztlich auch eine zwangsläufig kaum variierbare Zeichenkette oder Zahl.

Der Rückgabewert ist in drei Fällen auszuwerten:

1. Als Wert des Aufrufs von require().
2. Als Wert von mw.loadData().
3. Wenn es eine table ist, macht sie für #invoke die verfügbaren Funktionen zugreifbar.

Schnittstelle zur Vorlagenprogrammierung

In die einbindende Seite wird mittels der Parserfunktion {{#invoke:M|fun|params}} eingebettet.

fun ist der Name einer Funktion, die Komponente in dem als table deklarierten Rückgabewert des Moduls M ist. Sie erhält als Parameter das Objekt frame des #invoke.

Die Parameterliste entspricht derjenigen bei Vorlagen. Verirrte Gleichheitszeichen im Wert eines unbenannten Parameters können Syntaxfehler auslösen. Bei von außen kommenden Werten sollte immer mittels vorangestellter laufender Nummer eine sichere Zuweisung erfolgen: |1={{{Text|}}}

{{#invoke:M|f|1=ABC|FGH| LMN |benanntA=PQR|benanntB= TUV | HÖHE ÜBER NN= 32 | Leergut= }}

return r or ""

Objekt frame

→ Scribunto-Dokumentation (englisch)

Das Objekt frame gibt die Umgebung wieder. Grundsätzlich gibt es zwei Instanzen:

1. Aufruf des #invoke (Normalfall; standardmäßig immer mit frame bezeichnet)
2. Aufruf der einbindenden Seite (meist Vorlage).
   • Erhältlich mittels frame:getParent()
   • Einziger nutzbarer Unterschied sind die Argumente frame.args der Vorlageneinbindung; alle Funktionen führen zum gleichen Ergebnis; erneutes frame:getParent() hilft nicht.

Wenn über #invoke eine Funktion für die Vorlage genutzt wird, ist der Funktion gemäß Schnittstelle zur Vorlagenprogrammierung auch das Objekt frame dazu bekannt. Falls dies (als Bibliotheksfunktion) nicht übergeben wurde oder in tieferen Ebenen nicht durchgereicht wurde, kann es überall gebildet werden mit:

frame = mw.getCurrentFrame()

Substituierung

Mittels der Funktion mw.isSubsting() lässt sich herausfinden (boolean), ob die momentane Aktivität darauf hinauslaufen wird, dass das Ergebnis substituiert wird (mit {{subst: eingebunden wurde).

Anfang 2014 wird jedoch nur erkannt, ob die Parserfunktion #invoke unmittelbar Gegenstand einer Substituierung {{subst:#invoke:m|f}} ist; nicht aber, ob etwa eine Vorlage, in der dieses #invoke vorkäme, gerade substituiert wird.

Dadurch lassen sich Wartungskategorien in das Ergebnis einfügen, die bei einer unerwünschten Substituierung protestieren; oder umgekehrt bei fehlender Substituierung eine Einbindung bemängeln.

Ein frame-Objekt wird bei der Substituierung von #invoke nicht übergeben; über mw.getCurrentFrame() lässt es sich aber jederzeit beschaffen.

Mehrere Module

local lucky, WillHaben = pcall( require, "Modul:WillHaben" )
if type( WillHaben ) == "table" then
    r = WillHaben.WillHaben()
else
    r = "<span class=\"error\">" .. WillHaben .. "</span>"
    --  auto: "package.lua:80: module 'Modul:WillHaben' not found"
    --  "Fehler * Modul:WillHaben nicht gefunden"
end

return require( "Modul:NeuerName" )

Einfaches Modul für Vorlagen

Das Modul:Hello gibt einen ersten Einstieg:

local p = {} 
function p.hello(frame)
    local name = frame.args[1]
    if not name then 
        name = 'Welt' 
    end
    return  'Hallo, ' .. name .. '! Dies ist Lua!' 
end 
return p

Der Aufruf würde erfolgen mittels

• {{#invoke:Hello|hello}} (ergibt Hallo, Welt! Dies ist Lua!)

oder

• {{#invoke:Hello|hello|hier bin ich}} (ergibt Hallo, hier bin ich! Dies ist Lua!)

Strukturierung eines komplexeren Moduls

Ein Modul mit zwei oder drei Funktionen nur für Vorlagen ist eher trivial.

Bei komplexeren Aufgaben ist etwas Strukturierung und Übersicht erforderlich.

• An Beginn sollte auch ein Datum vermerkt sein.
  • Weil Versionen des Quellcodes nicht ausschließlich über die produktive Seite generiert werden, ist die normale Versionsgeschichte einer Seite nicht hinreichend für die Verfolgung der Varianten. Vielmehr werden Versionen auch aus einem Testwiki oder von einer gesonderten Erprobungsseite oder aus einem fremden Wiki-Projekt mit der Mutterversion einkopiert; und wieder dorthin zurück.
• Es empfiehlt sich eine Ultrakurzbeschreibung der Funktionalität.
• Am Schluss stehen die Funktionen, die für den Export bestimmt sind.
• p ist der Rückgabewert des gesamten Moduls. Dieser Name hat sich eingebürgert, und er stellt eine table dar.

--[=[ DiesesBeispiel 2013-05-07
Dieser und jener Zweck
* service
]=]

-- Module globals
local messagePrefix = "lua-module-DiesesBeispiel-"
-- ...
-- ...

local function x( a )
    -- ...
    return r
end -- x()

-- ...
-- ...


-- Provide template access
local p = {}

p.service( frame )
    -- ...
    return x( u ) or ""
end -- .service()

return p

--[=[ DiesesBeispiel 2013-05-07
Dieser und jener Zweck
* service
* DiesesBeispiel()
]=]

-- Module globals
local messagePrefix = "lua-module-DiesesBeispiel-"
local DiesesBeispiel = { }
-- ...
-- ...

local function x( a )
    -- ...
    return r
end -- x()


DiesesBeispiel.service = function ( a )
    -- ...
    return x( u )
end -- DiesesBeispiel.service()


-- ...
-- ...

-- Provide external access
local p = {}

p.service( frame )
    -- ...
    return DiesesBeispiel.service( u ) or ""
end -- .service()

function p.DiesesBeispiel()
    -- Retrieve function access for modules
    -- Postcondition:
    --     Return table with functions
    return DiesesBeispiel
end -- .DiesesBeispiel()

return p

--[=[ DiesesBeispiel 2013-05-07
Dieser und jener Zweck
* DiesesBeispiel.service()
]=]

-- Module globals
local messagePrefix = "lua-module-DiesesBeispiel-"
local DiesesBeispiel = { }
-- ...
-- ...

local function x( a )
    -- ...
    return r
end -- x()


DiesesBeispiel.service = function ( a )
    -- ...
    return x( u )
end -- DiesesBeispiel.service()


-- ...
-- ...

-- Provide external access

return DiesesBeispiel

Elternumgebung

Versuche, die programmtechnisch im Prinzip vorhandene Elternumgebung zu ergründen, werden von Scribunto mit dem Ziel der Kapselung systematisch unterbunden. Darin unterscheidet sich „Lua im Wiki“ von allgemeinen Lua-Anwendungen.

Der einzig sinnvoll mögliche Zugriff ist auf die Parameter der unmittelbar einbindenden Seite möglich:
frame:getParent().args

Innerhalb der unmittelbar umgebenden Seite (Vorlage) erfolgen die einzelnen Aufrufe von #invoke sequentiell und unter Verwendung der gleichen Umgebung.

• Verschiedene Einbindungen der Vorlage selbst (z. B. in einem Artikel) werden dagegen parallel abgearbeitet und teilen auch keine Elternumgebung.

Modul für eine bestimmte Vorlage

Startpunkt, wie sich ein Modul schreiben lässt, das genau eine Vorlage unterstützen soll. Das Gegenstück wären Bibliotheksmodule, die von beliebig vielen unterschiedlichen Vorlagen aufgerufen werden können.

--[=[ 2013-05-19
Unterstützung für {{Vorlagen-Titel}}
f() test()
]=]


--
--


local function x( u )
    local r
    --
    return  r
end -- x()


local function main( a )
    local r
    --
    r = x( u )
    --
    return  r or ""
end -- main()



-- Export
local p = {}

function p.test( a )
    local lucky, r = pcall( main, a )
    return r
end

function p.f( frame )
    local lucky, r = pcall( main, frame:getParent().args )
    return r
end

return p

Mehrere Vorlagen

Wenn es eine eng umgrenzte Gruppe von Vorlagen gibt (etwa Vorlage:Str*), bei denen sich der Aufwand für Einzelmodule nicht lohnen würde, können sie in einem gemeinsamen Modul untergebracht werden.

Beispiel anhand der Vorlage:Str len:

{{#invoke:Vorlage:Str|f|f=len}}

mit einem einzigen Modul:Vorlage:Str für alle.

Die Funktion f ist dann wie folgt zu modifizieren:

function p.f( frame )
    local a = frame:getParent().args
    a.f = frame.args.f
    local lucky, r = pcall( main, a )
    return r
end

Während alle anderen Parameter der umgebenden Vorlage entstammen, wird f den Argumenten des #invoke entnommen.

Die Funktion test muss sich den Vorlagen-Namen in ihrer Simulation entsprechend vorgeben.

Programmierung

Die nachfolgenden Abschnitte stellen für Lua-Programmierer einige Besonderheiten der Sprache zusammen, die im Scribunto-Tutorial nicht oder nur verborgen dargestellt sind.

Außerdem gibt es eigene Hilfeseiten zu Sonderthemen:

• Modul im Wiki – Integration des Lua-Codes in den Wiki-Kontext
  • frame-Objekt – Schnittstelle zur Vorlagenprogrammierung
• Modul für eine bestimmte Vorlage – Einzelne Vorlage unterstützen
• Zeichenketten – String-Funktionen, Pattern (regulärer Ausdruck) und Text-Elemente
• mw – Objekt mw und Hilfsbibliotheken
• Links
  • mw.title – Seiten im Wiki
  • mw.uri – Vorrangig URL
• Umgebung – aktueller Wiki-Server und seine Ausstattung
• Internationalisierung
• Tutorial

Bibliotheken

• Bestandteil der Sprache Lua sind einige Standardbibliotheken. Soweit sie im Kontext der Wiki-Seiten sinnvoll sind, werden sie unterstützt.
• Außerdem bieten Scribunto als Objekt mw (für MediaWiki) einige Wiki-spezifische Bibliotheken an, die auch gut mit der sonstigen Architektur eines Wiki-Servers kooperieren.

Lua-Basissprache

debug

• debug.traceback

math – Mathematische Funktionen → Scribunto

os

package – Laden von Modulen → Scribunto

• require()

string – Zeichenketten

table → Scribunto

mw (für „MediaWiki“) – Scribunto-Bibliotheken

• mw.addWarning()
• mw.allToString()
• mw.clone()
• mw.getCurrentFrame()
• mw.incrementExpensiveFunctionCount()
• mw.isSubsting()
• mw.loadData()
• mw.log()
• mw.logObject()

frame-Objekt – Schnittstelle zur Vorlagenprogrammierung

mw.html – HTML-Element

mw.language – Formatieren in der aktuellen menschlichen Sprache

mw.message – Systemnachrichten

mw.site – aktuelles Wiki-Projekt

mw.text – Zeichenketten

mw.title – Wiki-Seiten

mw.uri – URL

mw.ustring – Zeichenketten in Unicode

mw.wikibase → mw:Extension:Wikibase Client/Lua

Ladbare Bibliotheken

Eher seltener erforderlich → Scribunto

bit32

libraryUtil

luabit

ustring

Fehlermeldungen

Es gibt vier Ursachen für Skriptfehler:

1. Syntaxfehler
2. Programmierfehler zur Einbindung
3. Fehlende Seite
4. Anwenderfehler bei Einbindung

Von sich aus gab Lua dabei bis zum Herbst 2014 immer nur eine einzige Fehlermeldung von sich: „Skriptfehler“. Das war langweilig und half niemandem bei der Beseitigung. Inzwischen wird der Name des Moduls, die Zeilennummer und eine konkrete Situationsanalyse in jeder einbindenden Seite angezeigt. Die Fehlermeldung ist verlinkt mit einer Popup-Box, die die Aufruffolge mit einzelnen Modulnamen und Zeilennummer wiedergibt.

Außerdem wird die Kategorie:Wikipedia:Seite mit Skriptfehlern mit allen einbindenden Seiten gefüllt – das sollte vermieden werden, sondern Laufzeitfehler sollten abgefangen und in Modul-spezifische Wartungskategorien geleitet werden.

Leere Werte

Anders als bei anderen Programmiersprachen gilt:

• Sowohl die Zahl 0 wie auch die leere Zeichenkette "" sind „etwas“.
• Nur nil und false sind „nichts“.
• Eine leere table {} ist gleichbedeutend mit nil.

Das ist vor allem für if-Abfragen wichtig.

Table und Objekt

Auf Werte und Funktionen als Komponenten einer table wird mit einem . als t.k zugegriffen, neben der Notation t["k+"] auch für Namen von Komponenten, die nicht rein alphanumerisch sind.

Die Elemente einer Tabelle können mit verschiedenen Iteratoren erfasst werden. Typisch sind folgende Universaliteratoren:

local Beispieltabelle = {"eins", "zwei", 3, "Quattro stagioni"}
for meinIndex, meinWert in ipairs(Beispieltabelle) do
    ...
end

iteriert durch die unbenannten Elemente einer Tabelle, während

local Beispieltabelle = {erster="eins", zweiter="zwei", dritter=3, vierter="Quattro stagioni"}
for meinSchlüssel, meinWert in pairs(Beispieltabelle) do
    ...
end

durch die benannten Werte der Tabelle iteriert.

Bei einem Objekt (einer Instanz, durch eine von Lua oder Scribunto angeboten Bibliothek) wird auf Eigenschaften ebenfalls mit einem . zugegriffen. Für Funktionen (Methoden) ist hingegen ein : zu verwenden. Beispiele siehe String-Funktionen.

Die Notation mit Doppelpunkt gilt nicht nur für Lua- und Scribunto-Objekte, sondern auch für benutzerdefinierte Objekte. Dabei erhält die Methode implizit einen zusätzlichen Parameter self, auf den innerhalb der Methode zugegrffen werden kann. Dieser repräsentiert die Instanz des Objekt-table, während die table einer „Klasse“ entspräche. Die beiden Anweisungen

function meinObjekt:f ( params ) body end

und

meinObjekt.f = function ( self, params ) body end

sind äquivalent.

Bei Funktionen in Objekten (Methoden) gibt es außerdem die Möglichkeit, benannte Argumente zu verwenden. Statt runder Klammern sind dann geschweifte Klammern {} zu benutzen. Dieses Format ist meist eine zusätzliche Option; in manchen Fällen wie bei frame:expandTemplate{} aber der einzige unterstützte Zugriff.

or: Von links nach rechts

Die Vorlagenprogrammierung wird dadurch unterstützt, dass der or-Operator den links stehenden Disjunktionsausdruck zurückgibt, wenn dieser weder nil noch false ist, und sonst den Ausdruck auf der rechten Seite.

Damit lassen sich auch Datentypen bei fehlenden Angaben sichern:

saveString = frame.args.optional or ""
saveTable  = getTable() or {}

Wenn der Wert leer und/oder dabei vom falschen Datentyp ist, wird mit dem richtigen Datentyp initialisiert.

Weil oft Bibliotheksfunktionen in bestimmten Situationen nil oder false zurückgeben, diese Zeichenketten aber nicht als Ergebnis der Vorlageneinbindung auftreten sollen, kann man etwa einen wirklich „leeren“ Wert mit der folgenden Anweisung sicherstellen:

return fun(x) or ""

Gibt fun(x) einen echten Wert zurück, wird dieser an das #invoke zurückgegeben; ist das nichts, greift das "".

Analog kann man den Wert 1 bei „nichts“ oder „etwas“ sicherstellen:

return fun(x) and "1" or ""

Weil diese Notation nicht sehr übersichtlich ist, sollte man es aber bei diesem Kniff bewenden lassen.

Reihenfolge lokaler Funktionen

Die Reihenfolge lokaler Funktionen ist signifikant. Eine lokale Funktion muss in der physischen Abfolge der Definitionen definiert gewesen sein, bevor sie verwendet werden darf.

Zählschleife

Bei einer Zählschleife

for v = e1, e2 do

werden die Argumente nur einmal zu Beginn ausgewertet; danach in interne Variablen überführt.

Es ist nicht möglich, innerhalb der Schleife die Endbedingung auszulösen, etwa durch e1=e2. Vielmehr ist eine break-Anweisung auszuführen.

Zeichenketten-Parameter trimmen

Unbenannte Zeichenketten-Parameter sollten stets getrimmt werden, wenn sie aus Vorlagen stammen und Leerzeichen nicht signifikant wären. In der Vorlagenprogrammierung war dies nur mit Tricks möglich gewesen:

{{#if:trim|{{{1}}}}}

In Lua wäre der Weg eine Bibliotheksfunktion, wenn gesichert ist, dass s eine Zeichenkette ist:

s = mw.text.trim( s )

Strikte Syntax

Insbesondere während der Entwicklungsphase kann mit dem folgenden Statement möglichst früh in den ausführbaren Zeilen eine verschärfte Syntaxkontrolle angefordert werden.

require( "strict" )

Zurzeit bewirkt dies lediglich, dass gesichert wird, dass alle Variablenbezeichner auch explizit als local deklariert sein müssen.

• Damit können sie nicht mit Zuweisungen in anderen Modulen oder Gültigkeitsbereichen kollidieren und unerklärliche Nebeneffekte bewirken.
• Variablenbezeichner müssen entweder auf Ebene des Moduls oder einer Funktion oder in einem Block als local vereinbart sein (ausgenommen automatische lokale Variablen in Schleifen).

Weil dies im produktiven Stadium Performance und Ressourcen kostet, sollte es in fertigen Versionen nicht mehr aktiv vorhanden sein.

Benutzerdefinierte Objekte

Es wäre vermessen, Lua als objektorientierte Sprache anzusehen. Gleichwohl lassen sich über eine metatable einer table einige objektartige Eigenschaften geben.

Damit lassen sich spezifische Methoden definieren für:

• Zugriff auf Element, neues Element, Vereinigung, Länge, Vergleich, arithmetische Operationen.

Weil die table ohnehin Funktionen als Elemente enthalten kann, lassen sich nach Art eines selbstdefinierbaren Objekts Methoden und Eigenschaften darstellen und über eine Generierungsfunktion auch allen Instanzen einer „Klasse“ zuweisen; diese sogar geeignet vererben und überschreiben. Das traut man der schlichten Sprache auf den ersten Blick nicht zu.

Fehlermeldungen im Kopf der Seitenvorschau

Mittels der Funktion mw.addWarning( wikitext ) können im Kopfbereich der Seitenvorschau Warnungen angezeigt werden.

• wikitext wird dabei noch geparset.
• Mehrfache (identische?) Meldungen werden nur einmal gezeigt. Überhaupt wurde bis August 2025 immer nur eine einzige Meldung dargestellt.
• Problem: Zunächst besteht kein Zusammenhang zwischen der Warnmeldung im Seitenkopf und der aufrufenden Stelle in der Seite, wo das Problem auftritt. Bei sehr langen Seiten – und wenn dann auch noch keine Fehlermeldung in der Seitenvorschau sichtbar ist – wird die Meldung sinnfrei, weil die Autoren sie nicht der Ursache zuordnen können.
• Mit dem Zufallszahlengenerator math.random() ließe sich ein temporärer Fragmentbezeichner wie error-54381975 generieren, der im Seitenkopf verlinkt und an der Einbindung verankert wird.
• Die unterschiedlichen Einbindungen in der Seite haben keine Kenntnis voneinander.

mw-Objekt

Das Objekt mw (für MediaWiki) ist immer verfügbar. Es stellt zahlreiche nützliche Funktionen bereit.

Die Komponenten sind analog der Funktionen und Datenstrukturen auf dem Wiki-Server (in PHP) sowie dem Objekt mw in JavaScript gebildet, wo sich gleiche Aufgaben finden. Sofern möglich, stimmen Namen und Parameter überein.

Alle Komponenten

Einige Funktionen sind direkt als Komponenten angebunden, bei anderen ist die Komponente eine Bibliothek, die die einzelnen Funktionen enthält.

Unmittelbare Funktionen

• mw.addWarning()
• mw.allToString()
• mw.clone()
• mw.dumpObject()
• mw.getCurrentFrame()
• mw.incrementExpensiveFunctionCount()
• mw.isSubsting()
• mw.loadData()
• mw.loadJsonData()
• mw.log()
• mw.logObject()

Funktionssammlungen

• mw.ext – Erweiterungen
• mw.html – HTML-Element
• mw.language – Formatieren in der aktuellen menschlichen Sprache
• mw.message – Systemnachrichten
• mw.site – aktuelles Wiki-Projekt
• mw.text – Zeichenketten
• mw.title – Wiki-Seiten
• mw.uri – URL
• mw.ustring – Zeichenketten in Unicode
• mw.wikibase → mw:Extension:Wikibase Client/Lua

mw.ext

mw.html

→ Scribunto (englisch)

Quellcode

Diese Methoden sind gut geeignet zur Synthese von HTML-Elementen.

Die Methodik ähnelt derjenigen, die in jQuery verwendet wird.

Ein neues html-Objekt lässt sich bilden mit

mw.html.create( art, args )

• art – Name des gewünschten Elements; etwa div.
  • art kann auch eine leere Zeichenkette sein; dann wird ein leeres Objekt zurückgegeben.
• args – optionale table mit folgenden Feldern:
  • args.selfClosing – Erzwingen eines unary Tag, auch wenn das für dieses Element nicht zu erwarten ist.
  • args.parent – Verweis auf ein möglicherweise bekanntes Eltern-html-Objekt (nur für interne Zwecke vorgesehen)

local el = mw.html.create( "div" )

local div = mw.html.create( "div" )
div:attr( "id", "testdiv" )
   :css( "width", "100%" )
   :wikitext( "Some text" )
   :tag( "hr" )
return tostring( div )

<div id="testdiv" style="width:100%;">Some text<hr /></div>

Weblinks und Wikilinks

Die nachfolgenden Abschnitte stellen die Unterstützung bei Weblinks und Wikilinks durch Scribunto-Standardbibliotheken dar.

Es sind

• mw.title für Wikilinks und Analyse von Seiten
• mw.uri für syntaktisch korrekte URL

Wie bei Wikisyntax können Wiki-Seiten sowohl über URL wie auch über den Seitenbezeichner adressiert werden.

mw.title

Das title-Objekt repräsentiert einen Seitennamen, vor allem aber die Eigenschaften der entsprechenden Wiki-Seite.

Es sind etliche Informationen über die aktuelle (oberste) Seite und auch jede andere im Projekt verfügbar: Titel, Namensraum, Existenz, bis zum Inhalt.

• MediaWiki: Scribunto (englisch)
• Quellcode

mw.uri

Diese Methoden sind gut geeignet zur Synthese von URL und zur Analyse formal korrekter URL.

Bei unbekannt im Wikitext vorgefundenen Zeichenketten, die eine URL sein sollen, empfiehlt sich vorher eine vorsichtige Analyse auf formale Zulässigkeit mit URLutil, oder andere Mechanismen zum Abfangen von Fehlersituationen.

• MediaWiki: Scribunto (englisch)
• Quellcode

mw.uri.encode( s, enctype )

Encoding der Zeichenkette s (Prozent).

Der optionale enctype (Vorgabe: "QUERY") kann folgende Werte haben:

• "QUERY" – Leerzeichen als + für query-Komponenten.
• "PATH" – Leerzeichen als %20
• "WIKI" – Leerzeichen als _ (dies ist nicht vollständig umkehrbar, weil auch vorhandene _ ununterscheidbar werden)

mw.uri.decode( s, enctype )

Prozent-Dekodierung von s

Der optionale enctype (Vorgabe: "QUERY") kann folgende Werte haben:

• "QUERY" – ersetze + durch Leerzeichen
• "PATH" – Keine besondere Behandlung potentieller Leerzeichen.
• "WIKI" – ersetze _ durch Leerzeichen

mw.uri.anchorEncode( s )

Encoding von s, so dass dieser als Fragment in einer Wiki-URL benutzt werden kann (Punkt statt Prozent).

mw.uri.buildQueryString( table )

Wandle den Inhalt einer table in eine Folge von Zuweisungen k=v und verkette durch & zu einer Zeichenkette.

Die k in table sollen Zeichenketten sein.

Die v in table können sein: string, number, sequence table für mehrfaches Auftreten, false für „leer“.

mw.uri.parseQueryString( s )

Wandle eine Zeichenkette s um in eine table und löse die &k=v in Elemente der table.

• Leere Zuweisungen &k= erhalten den Wert false.
• Wiederholte Zuweisungen mit gleichem k werden als sequence table abgelegt.
• Alle anderen v werden Zeichenketten.

mw.uri.localUrl( page, query )

uri-Objekt für die lokale URL (bezogen auf die Domain) einer Wiki-Seite page oder einfache Zeichenkette.

• Optional mit query als fertige Zeichenkette oder table mit Spezifikationen k=v.

mw.uri.fullUrl( page, query )

uri-Objekt für die vollständige URL (aber ohne Protokoll) einer Wiki-Seite page oder einfache Zeichenkette.

• Optional mit query als fertige Zeichenkette oder table mit Spezifikationen k=v.

mw.uri.canonicalUrl( page, query )

uri-Objekt für die kanonische URL (mit aktuellem Protokoll) einer Wiki-Seite page oder einfache Zeichenkette.

• Optional mit query als fertige Zeichenkette oder table mit Spezifikationen k=v.

mw.uri.new( s )

mw.uri.new( table )

uri-Objekt bilden durch Parsen einer Zeichenkette s oder Befüllen der Felder in table.

mw.uri.validate( s )

mw.uri.validate( table )

Überprüfe die Verwendbarkeit einer Zeichenkette s oder der Felder in table für mw.uri.new().

boolean für Verwendbarkeit, Zeichenkette mit Fehlermeldung sonst.

Anwendungsbeispiel

Die nachstehende Funktion versucht ein Link auf die Versionsgeschichte zurückzugeben, wobei die Seite über die Seitenkennnummer curid definiert ist. Programmierfehler und ungültige Zahlenwerte werden erkannt. Beide auf dieser Seite dargestellten Bibliotheken/Objekte werden verwendet.

function versionen( curid )
    local r
    if type( curid ) == "number" and curid > 0 then
        local page = mw.title.new( curid )
        if page then
            local uri = mw.uri.fullUrl( page.prefixedText, 
                                        { action = "history" } )
            r = string.format( "[%s Versionen]", tostring( uri ) )
        else
            r = string.format( "Seite %d fehlt", curid )
        end
    else
        r = "*BAD curid*"
    end
    return r
end

1. [1]

   Gerrit:58897
2. [2]

   Namensraum-Nummer .id oder einer der Namen; zurzeit aber nicht die table selbst.
3. [3]

   Maximal 500 Abfragen pro Gesamt-Seite.

Umgebung

Die nachfolgenden Abschnitte stellen die Unterstützung in der momentanen Projekt-Umgebung durch Scribunto-Standardbibliotheken dar.

Es sind

• mw.site – für allgemeine Informationen über das Wiki-Projekt
• mw.language – für menschliche Sprachen, ihre Namen und Codes
• mw.message – für Systemnachrichten
• os – Lua-Bibliothek für Betriebssystem-Zugriffe

Siehe dazu auch Hilfe:Lua/Internationalisierung.

mw.site

→ Scribunto (englisch)

Quellcode

Abfrage allgemeiner Informationen über das Wiki-Projekt und einige statistische Angaben.

mw.site.currentVersion

Aktuelle Version von MediaWiki: 1.46.0-wmf.19 (b0f5a6a) – {{CURRENTVERSION}}

mw.site.scriptPath

Pfad zum Server-Skript: /w – {{SCRIPTPATH}}

mw.site.server

Domain des Servers: //de.wikipedia.org – {{SERVER}}

mw.site.siteName

Art des Servers: Wikipedia – {{SITENAME}}

mw.site.wikiId

Datenbankname des Wikis: dewiki

mw.site.stylePath

Pfad zu den Server-Stilen: /w/skins – {{STYLEPATH}}

mw.site.namespaces

Angaben zu allen Namensräumen.

table mit einem Eintrag pro Namensraum. Jedes Element hat die unten beschriebenen Eigenschaften.

Der Zugriff kann über die Nummer oder irgendeinen Alias erfolgen.

• mw.site.namespaces.module.name ist Modul
• mw.site.namespaces[12].name ist Hilfe
• mw.site.namespaces.wp.id ist 4

mw.site.contentNamespaces

table wie mw.site.namespaces, aber nur Inhaltsnamensräume.

mw.site.subjectNamespaces

table wie mw.site.namespaces, aber nur „Vorderseiten“.

mw.site.talkNamespaces

table wie mw.site.namespaces, aber nur Diskussionsnamensräume.

mw.site.interwikiMap( select )

Interwiki-Tabelle.

• select == "!local" nur nicht-lokale Interwikis. Für die deutschsprachige Wikipedia sind „lokale“ Ziele alle anderen Wikipedien, nicht aber Wikisource.

mw.site.stats

Statistische Angaben; alle Details vom Typ number.

table mit Elementen:

• .pages
• .articles
• .files
• .edits
• .views
• .users
• .activeUsers
• .admins

mw.site.stats.pagesInCategory( category, which )

Statistik der Kategorie mit dem Titel category.

Wenn optionales which fehlt, nil oder "*" ist, wird eine table mit den folgenden Elementen zurückgegeben; ansonsten das Schlüsselwort erwartet.

• all – Gesamtzahl der Seiten, Dateien und Unterkategorien.
• pages
• files
• subcats

Diese Funktion ist „teuer“.^[1]

mw.site.stats.pagesInNamespace( nsn )

nsn ist die Nummer.

mw.site.stats.usersInGroup( group )

Anzahl der Benutzer in Gruppe group.

mw.language

→ Scribunto (englisch)

Quellcode

Schwerpunkt ist die Analyse der momentanen Projektsprache getContentLanguage() sowie von Wiki-Projekten unterstützter menschlicher Sprachen.

Mit mw.language.new() lässt sich ein neues language-Objekt bilden.

mw.language.fetchLanguageName( code, inLanguage )

Name der Sprache, die durch code beschrieben wird.

In der jeweils eigenen Sprache selbst („English“); bei optionalem Code inLanguage in dieser.

Ist keine Übersetzung in inLanguage definiert, wird die momentane Projektsprache benutzt, sonst Englisch, sonst die Sprache selbst.

Ist code unbekannt, dann ist der Rückgabewert code selbst.

mw.language.fetchLanguageNames( inLanguage, include )

Auflistung aller bekannten Sprachen

In der jeweiligen eigenen Sprache; bei optionalem Code inLanguage in dieser.

include (optional):

• mw (Vorgabe) – nur wenn die Sprache definiert in MediaWiki oder wgExtraLanguageNames ist
• all – alle bekannten Sprachen
• mwfile – nur wenn die Sprache mw erfüllt und ein message file hat.

Ergibt table mit Zuweisungen code→Name (die Codes sind in Kleinbuchstaben notiert).

Ist für einzelne code keine Übersetzung definiert, wird analog zu fetchLanguageName() verfahren; ist inLanguage unbekannt, wird Englisch benutzt.

mw.language.getContentLanguage()

language-Objekt für Inhaltssprache des Projekts: de

mw.language.getFallbacksFor( code )

Ergibt sequence table, zumindest mit en als letztem Element.

Beispiel: "hsb" → { "dsb", "de", "en" }

mw.language.isKnownLanguageTag( code )

true – wenn code MediaWiki als IETF-Code bekannt ist.

mw.language.isSupportedLanguage( code )

true – wenn für code in MediaWiki eine Lokalisierung vorhanden ist.

mw.language.isValidBuiltInCode( code )

true – wenn code formal geeignet wäre, eine interne Sonder-Lokalisierung zu definieren. Dabei muss code zu keiner bekannten Sprache gehören.

mw.language.isValidCode( code )

true – wenn code formal korrekt ist; unabhängig davon, ob dies existiert. Dabei muss code zu keiner bekannten Sprache gehören.

mw.language.new( code )

Bilde ein neues language-Objekt für code.

local lang = mw.language.new( code )

mw.message

→ Scribunto (englisch)

Quellcode

Systemnachrichten aus dem translatewiki: oder dem MediaWiki-Namensraum.

mw.message.new( key )

Schaffe ein neues message-Objekt.

• key ist der Bezeichner der Systemnachricht.

mw.message.newFallbackSequence( key, keyFallback1, keyFallback2, … )

Wie mw.message.new( key ), aber mit Ersatzlösungen. Die erste existierende Nachricht wird verwendet.

mw.message.newRawMessage( s, params, … )

Schaffe ein neues, aber leeres message-Objekt basierend auf der Zeichenkette s statt einer Systemnachricht.

Die optionalen params werden an msg.params() weitergegeben.

mw.message.rawParam( value )

mw.message.numParam( value )

mw.message.getDefaultLanguage()

language-Objekt für die Standard-Sprache.

Im normalen Wiki identisch mit mw.language.getContentLanguage().

Einige Funktionen wurden im Februar 2014 entfernt (gerrit:110983).

local msg = mw.message.new( key )

os

→ Scribunto (englisch)

Eine Standardbibliothek in Lua ist os (operating system). Damit würden Zugriffe auf das Betriebssystem möglich. Auf den Wiki-Servern ist dies weitgehend unterbunden. Zu produktiven Zwecken ist das auch kaum sinnvoll praktisch nutzbar.

Die einzige Funktion, die bei der Entwicklung Anhaltspunkte liefern kann, ist os.clock(). Damit lassen sich Abschätzungen über den Zeitbedarf des Moduls treffen; siehe Lua #Begrenzungen.

Die Umrechnung in Sekunden (wohl seit 1. Januar 1970 00:00) ist für eine Wiki-Seite eher seltener von Interesse.

os.clock()

Ungefähre Anzahl der CPU-Sekunden, die das Programm verbrauchte.

Dargestellte Genauigkeit/Diskretisierung: 10⁻⁹ Sekunden.

os.date( format, time )

Datum und Uhrzeit.

Besser über lang:formatDate() zu erreichen und ortsüblich zu formatieren.

os.difftime( t2, t1 )

Anzahl der Sekunden von t1 bis t2.

os.time( table )

Uhrzeit auf dem Server als number in Sekunden.

Bei optionaler table diese auswerten.

1. [1]

   Sie wird dem expensiveCount hinzugezählt. Dieser ist auf 500 pro dargestellte Gesamt-Seite begrenzt.
2. [2]

   Gilt für übliche Inhalts-Wikis.

Zeichenketten

Die nachfolgenden Abschnitte geben

für Lua-Programmierer eine Kurzreferenz zum Umgang mit Zeichenketten in der Lua-Programmierung.

ASCII und Unicode

Die Wiki-Projekte sind in vollem Unicode geschrieben, Lua arbeitet jedoch nur mit 8-bit-Code (ISO 8859-1).

• Wenn das Suchmuster sich auf ASCII beschränkt, kann etwas effizienter mit den ASCII-Funktionen und entsprechenden Pattern gearbeitet werden, weil die Umwandlung von UTF-8 entfällt. Der 8-bit-Anteil jenseits von ASCII ist nicht sinnvoll nutzbar, weil hier die UTF-8-Kodierungen liegen.
• Allgemeine, beliebige Zeichenketten des Wikitextes müssen mit den ustring-Funktionen für Unicode verarbeitet werden.

String-Funktionen (Kurzreferenz)

siehe Scribunto (englisch):

• ASCII string
• mw.ustring

Angegeben sind jeweils die Funktionen für ASCII und Unicode; letztere mit mw.ustring.*().

mw.text

siehe Scribunto (englisch)

Eine weitere Hilfsbibliothek durch Scribunto, um kleine Manipulationen an Zeichenketten vornehmen zu können.

Unter „Zeichen“ wird hier Unicode verstanden.

mw.text.decode( s, decodeNamedEntities )

HTML-Entites durch Zeichencodes ersetzen

• Standard: Nur lt, gt, amp, quot, nbsp sowie alle numerischen.
• Optionales decodeNamedEntities bedeutet: Definition gemäß HTML5 verwenden. Über die in HTML4/XHTML hinaus bekannten sind das etliche mehr.

mw.text.encode( s, charset )

Escape für HTML: Zeichencodes durch HTML-Entites ersetzen.

• Standard: '<', '>', '&', '"' und das geschützte Leerzeichen werden ersetzt durch die benannten lt, gt, amp, quot, nbsp. Mögliche weitere Entities sind numerisch.
• Optionales charset ist ein Satz, der geeignet wäre, bei einem pattern in eckigen Klammern zu stehen.
  Vorgabe ist "<>&\"' " mit geschütztem Leerzeichen am Ende.

Siehe auch mw.text.nowiki()

mw.text.jsonDecode( s, flags )

Aus einer Zeichenkette gemäß JSON eine table oder sonstigen Wert generieren.

s ist die Zeichenkette.

flags ist eine optionale number; wenn ungleich 0, dann durch Addition von Konstanten kombiniert:

• mw.text.JSON_PRESERVE_KEYS – Vermeiden, dass die zero-based Arrays in JSON auf Lua sequence tables abgebildet werden: Indizes beibehalten, Zählung bei 0 statt Lua-üblich 1 beginnen.
• mw.text.JSON_TRY_FIXING – Nicht empfohlen: Syntaxbeschränkungen ignorieren; etwa redundantes schließendes Komma in Array oder object.

Beschränkungen durch Lua-Sprachkonzept:

• Wenn ein JSON Array einen Wert null enthält, kann es in Lua keine sequence table werden.
• Werte null in einem JSON object erscheinen nicht.
• Es ist nicht möglich, aus Lua zu entscheiden, ob in JSON ein Array oder object vorgelegen hatte, falls die Elemente durchgängig mit Integer-Schlüsseln bezeichnet wurden.

mw.text.jsonEncode( value, flags )

Zeichenkette gemäß JSON generieren.

value ist ein Wert beliebigen Typs.

flags ist eine optionale number; wenn ungleich 0, dann durch Addition von Konstanten kombiniert:

• mw.text.JSON_PRESERVE_KEYS – Vermeiden, dass die sequence tables in Lua auf zero-based Arrays in JSON abgebildet werden: Indizes beibehalten, Zählung bei 1 statt JS-üblich 0 beginnen.
• mw.text.JSON_PRETTY – pretty printing (formatierte mehrzeilige Darstellung statt kompakter Abfolge).

Beschränkungen durch Lua-Sprachkonzept:

• Eine leere table wird als leeres Array [] und nicht als leeres object {} generiert.
• Um eine sequence table als JSON object abzubilden, muss ein Dummy-Element hinzugefügt werden.
• Eine sequence table mit Schlüsseln ab 0 wird genauso wie eine ab 1 als JSON Array generiert; es sei denn, dass mw.text.JSON_PRESERVE_KEYS angegeben wurde.
• Wenn sowohl numerische Indizes wie auch gleiche Werte als string-Darstellung auftreten, ist das Verhalten nicht vorhersagbar.
• Um ein Array oder object mit einem Wert von nil zu erreichen, ist die metamethod __pairs erforderlich.

mw.text.listToText( list, separator, conjunction )

Alle Elemente einer table aneinanderfügen, ähnlich table.concat().

list ist eine table.

Vorgaben für die optonalen weiteren Parameter sind:

• separator über MediaWiki:comma-separator als Komma und Leerzeichen: »⧼MediaWiki:comma-separator⧽«
• conjuction über MediaWiki:and verbunden mit MediaWiki:word-separator als: »⧼MediaWiki:comma-separator⧽⧼MediaWiki:word-separator⧽«

mw.text.nowiki( s )

Escape für Wikitext: Zeichencodes durch HTML-Entites ersetzen.

• Alle Vorkommen: '"', '&', "'", '<', '=', '>', '[', ']', '{', '|', '}'
• Beginn von s oder unmittelbar nach einem Zeilenumbruch: '#', '*', ':', ';'
• Die „Magischen Wörter“

Siehe auch mw.text.encode()

mw.text.split( s, pattern, plain )

Generiere Tabelle (sequence) aus Zeichenkette s durch Segmentierung (Tokenizer).

pattern ist der Ausdruck, der die Elemente voneinander trennt.

• Bei leerer Zeichenkette für pattern wird jedes Zeichen einzeln in die Tabelle geschrieben.

Optionales plain bewirkt die buchstäbliche Suche nach pattern, nicht über die besondere Syntax.

mw.text.gsplit( s, pattern, plain )

Iterator-Funktion für for analog zu mw.text.split()

mw.text.tag( name, attrs, content )

Generiere ein HTML-Tag mit dem Bezeichner name.

• Das optionale, aber oft sinnvolle attrs ist eine table mit den Zuweisungen k=v.
• Wenn das optionale content als Zeichenkette (oder number) angegeben wird, wird das Element auch mit einem end-tag nach content versehen; sonst ist es nur ein start-tag.
• Encoding erfolgt nicht automatisch; sofern wünschenswert und erforderlich, muss es mittels mw.text.encode() geeignet veranlasst werden.
• Bei content =false wird ein unary tag generiert.

Diese Funktion gilt nur für HTML-Tags als bloße Zeichenketten. Ein Tag einer Wiki-Erweiterung wie <ref> muss mit frame:extensionTag() generiert werden; andernfalls würde es nicht wirksam.

Zu einer später entstandenen, umfassenderen Funktionalität siehe mw.html – diese Bibliothek ist im Zweifelsfall votzuziehen und einheitlich darauf umzustellen.

mw.text.trim( s, charset )

Leerzeichen und Zeilenumbruch an Beginn und Ende von s entfernen.

Das optionale charset ist eine Zeichenkette, die zwischen den eckigen Klammern eines pattern als [set] stehen kann.

• Die Vorgabe ist: "\t\r\n\f "

mw.text.truncate( text, length, ellipsis, adjustLength )

Abschneiden der Zeichenkette s auf die Länge length.

Dabei wird an eine abgeschnittene Zeichenkette die Auslassungsmarkierung ellipsis angehängt.

• Wenn length negativ ist, wird der Betrag genommen und der Beginn von s abgeschnitten; sonst das Ende.
• Wenn die optionale ellipsis nicht angegeben ist, wird MediaWiki:ellipsis (also »…«) benutzt. Um nichts anzuhängen, muss explizit eine leere Zeichenkette angegeben werden.

Wenn das optionale adjustLength mit true verwendet wird, ist der Betrag von length die Gesamtlänge einschließlich ellipsis.

mw.text.unstrip( s )

Entfernt die MediaWiki-internen strip markers.

Diese Funktion sollte in der normalen Lua-Programmierung nicht benutzt werden, da mit Bruch zu rechnen ist.

mw.text.unstripNoWiki( s )

mw.text.killMarkers( s )

mw.dumpObject()

mw.dumpObject( table )

Das Objekt table wird in einer menschenfreundlichen Form in eine mehrzeilige Zeichenkette überführt und diese zurückgegeben.

mw.logObject() verwendet dieses Format.

Anmerkungen

1. [1]

   Ein mw.ustring.reverse() ist nicht definiert

Daten und Programmierung trennen

Die nachfolgenden Abschnitte stellen Möglichkeiten dar, bei der Programmierung von Lua-Modulen das Basis-Konzept einer Trennung von Programm und Daten umzusetzen.

Allgemeines

Die Trennung von Programm und Daten gehört zum Stoff des ersten Semesters eines Informatikstudiums.

Vorteile:

• Wartbarkeit verbessert,
• Übersichtlichkeit erhöht,
• Robustheit gesteigert,
• Portabilität ermöglicht,
• Flexibilität unterstützt.

Grundsätzlich werden Parameter mit konstanten Werten, welche eine zukünftig möglicherweise veränderliche Konfiguration abbilden, sowie sämtliche veränderlichen Textbausteine, die auch von menschlichen Sprachen abhängen, in der Strukturierung getrennt von den prozeduralen, algorithmischen Beziehungen.

• Dadurch können die Konfigurationsdaten an einer zentralen und übersichtlich zugänglichen Stelle gesammelt und auch dokumentiert werden. Wären sie hard-coded überall in den Instruktionen verteilt, wären viel schwieriger alle Vorkommen aufzufinden und bei entstehendem Bedarf anzupassen. Nach einigen Jahren und durch die Nachfolgenden würde das zur Herausforderung.
• Zahlen oder Kennbuchstaben erhalten sprechende Bezeichner. Dadurch wird die Bedeutung der Anweisungen verständlicher. Irrtümer werden vermieden, Fehler treten offenkundig hervor.
• Standardwerte können als Vorgaben definiert werden; bei abweichendem besonderen Bedarf kann die Wirkung der Software von außen durch individuell zugewiesene Parameter beeinflusst werden, ohne dass die Programmierung verändert werden müsste.
• Weil der funktionale Teil ggf. auch auf eigenen Seiten gekapselt ist, während Konfigurationsdaten auf anderen Seiten im Wiki liegen, kann eine aktualisierte Programmierung global verteilt werden, ohne dass sie in jedem einzelnen Projekt mit jeder neuen Version angepasst werden müsste. Siehe dazu Internationalisierung.

Techniken in Lua und Wikis

Internationalisierung

Die nachfolgenden Abschnitte stellen Möglichkeiten dar, bei der Programmierung von Lua-Modulen andere Sprachen und Projekt-Konstellationen zu berücksichtigen.

Ein Nebeneffekt ist, dass durch bessere Strukturierung auch die Wartung und Pflege im eigenen Projekt einfacher und sicherer wird.

Einige grundsätzliche Möglichkeiten werden dargestellt und verglichen.

Grundsätzlich: Parametrisierung

Textteile (in menschlicher Sprache) und potentiell veränderliche Konfigurationen (etwa die Namen von Seiten) sollen nie im Inneren des Codes versteckt werden.

• Sie sind dort schwer zu finden, und ein späterer Eingriff durch Unbeteiligte führt oft zu Kollateralschäden.
• Ein Überblick über alle anzupassenden Elemente ist nicht zu erhalten; der aktuelle Konfigurationsstatus ist nicht zu überschauen.
• Wenn sich auch Funktionalitäten verändern, etwa erweitert werden, wird der Transfer und die erneute Anpassung zum Drama; muss wieder von vorn begonnen werden.

Systemvariablen nutzen

Die momentane Konfiguration und Umgebung kann ausgelesen werden. So sind die Namen und Nummern zu den Namensräumen bekannt.

ns = mw.site.namespaces.Module.id
sT = mw.site.namespaces.Template.name

Die vorstehende Anweisung liest die momentane Nummer des Modul-Namensraums (828) und den deutschsprachigen Bezeichner des Vorlagen-Namensraums aus.

Siehe dazu allgemein: Hilfe:Lua/Umgebung.

Auch alle dort nicht angebotenen Parserfunktionen sind nach diesem Prinzip verfügbar, dann über frame:preprocess{} (siehe LuaWiki.getVariable()).

Minimallösung

Alle möglicherweise anzupassenden Texte oder Zahlen werden in Variablen geschrieben. Die Wertzuweisung erfolgt in einem geschlossenen Block am Beginn des Moduls.

• Die anschließenden Funktionen greifen nur noch auf die Variablen zu und können en bloc durch eine neuere Version ausgetauscht werden.
• Zur Anpassung an eine neue Umgebung müssen nur alle Werte im Block geeignet ersetzt werden.

Vorteile

• Einfache Programmierung bei der ersten Erstellung

Nachteile

• Aktualisierung veränderter Funktionalität bedarf einer Neukomposition des Quellcodes in jedem Projekt.
• Bei allen einbindenden Seiten wird eine Aktualisierung ausgelöst.

Automatische Anpassung

Für alle Sprachen, die unterstützt werden sollen, wird eine Tabelle angelegt. Es wird automatisch festgestellt, welche Sprache oder Projekt gerade aktiv ist, und das entsprechende Profil ausgewählt.

local l10nDef = { }
l10nDef[ "en" ] = {
    msgA = "Message 'A'",
    msgB = "Message 'B'"
}
l10nDef[ "de" ] = {
    msgA = "Nachricht 'A'",
    msgB = "Nachricht 'B'"
}
l10nDef[ "als" ] = l10nDef[ "de" ]
local l10n = l10nDef[ mw.language.getContentLanguage():getCode() ]
if not l10n then
    l10n = l10nDef.en
end
say = l10n.msgA

Die Sprache des Inhalts getContentLanguage() ist für die Darstellung in den Seiten passend; nicht die Spracheinstellung der momentanen Bearbeiter.

Analog zur Sprachkonfiguration kann auch auf die Projekt-URL Bezug genommen werden:

local l10nDef = { }
l10nDef[ "//de.wikipedia.org" ] = {
    nsDoc    = 4,    -- WPNR
    warnTalk = "Diskussionsseite fehlt"
}
local l10n = l10nDef[ mw.site.server ]
if not l10n then
    l10n = l10nDef[ "*" ]   -- defaults; fallback
end
ns = l10n.nsDoc

Vorteile

• Alle befreundeten Projekte können den funktional aktualisierten Code ohne Nacharbeit einspielen.

Nachteile

• Alle Übersetzungen und Anpassungen für jedes Projekt müssen bekannt sein und sind zentral einzupflegen.
• Bei allen einbindenden Seiten wird eine Aktualisierung ausgelöst; auch auf dem pflegenden Projekt.

Globale Tabellen

Auf Commons sind mittlerweile Tabellen verfügbar bzw. können angelegt werden, die aus jedem Wiki ausgelesen werden können und Übersetzungslisten zu Schlüsselwörtern enthalten. tabData@Multilingual unterstützt dabei.

Systemnachrichten

Die Textstücke können im MediaWiki-Namensraum abgelegt werden.

c = mw.language.getContentLanguage():getCode()
m = mw.message.new( "lua-module-MeinModul-" .. stored )
m:inLanguage( c )
say = m:plain()

Vorteile

• Alle befreundeten Projekte können den funktional aktualisierten Code ohne Nacharbeit einspielen.
• Für einbindende Seiten wird bei Textänderungen keine Aktualisierung ausgelöst.
• Die Seiten im MediaWiki-Namensraum sind nur durch Administratoren veränderbar und deshalb vor Vandalismus sicher.

Nachteile

• Einbindende Seiten werden bei Textänderungen nicht aktualisiert.
  • Wenn es sich nur um besser formulierte Fehlermeldungen handelt, beträfe das nur die Seiten, in denen der Text sichtbar ist; übergangsweise wäre noch die vorherige Formulierung zu sehen.
  • Durch ein purge auf einbindende Vorlagen lässt sich eine wichtige Textänderung durchsetzen.
• Die Seiten im MediaWiki-Namensraum sind nur durch Administratoren veränderbar und brauchen zusätzliche Anfragen.

Umhüllende Vorlage

Nur sinnvoll, wenn das #invoke lediglich in genau einer Vorlage vorkommt; das Modul also zur Unterstützung einer einzelnen Vorlage dient. Dann können die Textbausteine in die Parameterliste des #invoke eingeschlossen werden. Die Vorlage bleibt unter einem lokalen Namen für die allgemeine Benutzung mit einfacher Syntax verfügbar; #invoke und die angepassten Textstücke werden vor den Benutzern verborgen.

• Beispiel: {{LuaModuleDoc}}

Vorteile

• Alle befreundeten Projekte können den funktional aktualisierten Lua-Code ohne Nacharbeit einspielen.

Nachteile

• Bei allen einbindenden Seiten wird eine Aktualisierung ausgelöst.
• Begrenzt auf die Nutzung durch eine einzige Vorlage.

Unter-Vorlage

Die Textbausteine können auf eine beliebige Seite geschrieben werden, die unter Angabe des Schlüsselworts als Parameter eingebunden wird. Das ist mit der Funktion frame:expandTemplate{} möglich.

• Beispiel: Wikipedia:Lua/Modul-Navigationsfehler

Vorteile

• Alle befreundeten Projekte können den funktional aktualisierten Lua-Code ohne Nacharbeit einspielen.
• Alle Anwendungen können auf die Textsammlung zugreifen.
• Die Untervorlage ist leicht zu pflegen.

Nachteile

• Bei allen einbindenden Seiten wird eine Aktualisierung ausgelöst.
• Der Seitenname der Unter-Vorlage könnte eine zusätzliche Konfiguration erfordern; das lässt sich aber vermeiden, indem er aus dem Modulnamen gebildet und im Vorlagen-Namensraum untergebracht wird.

Unter-Modul

Ein geeignetes Unter-Modul für jede Sprache kann die Anpassung übernehmen, indem die zurückgegebene Tabelle die spezifischen Zeichenketten usw. enthält. Sie ist mit require() verfügbar, und die Namensgebung ist in eigener Hand. Auch mw.loadData() käme zur Effizienzsteigerung in Frage, falls die Tabelle keine Funktionen zurückgeben soll (die aber zur Generierung des Rückgabewerts benutzt werden können).

Vorteile

• Alle befreundeten Projekte können den funktional aktualisierten Lua-Code ohne Nacharbeit einspielen.
• Das Unter-Modul ist von Lua-Programmierern leicht zu pflegen; die einfache Umformulierung einer Zeichenkette auch nicht besonders schwer.

Nachteile

• Bei allen einbindenden Seiten wird eine Aktualisierung ausgelöst.
• Jedes empfangende Projekt muss eigene Lua-Programmierer haben, die auch Änderungen in der Nachrichtenstruktur und den Identifizierern umsetzen können. Das ist nicht schwierig; aber die Veränderung eines Moduls bringt erstmal eine Hemmschwelle und kann zu selbst nicht behebbaren Syntaxfehlern führen, wenn keine Lua-Programmierer für die lokale Modul-Variante verfügbar sind.

JSON

Weitgehend identisch mit einem Unter-Modul wäre eine Umsetzung als JSON.

• Einbindung mittels mw.loadJsonData() bei gleichen Nebenwirkungen.
• Die Struktur wird ggf. attraktiver dargestellt: Modul:JSTOR/config.json
• Daten können ggf. auch einfach mittels JavaScript durch Werkzeuge ausgelesen werden. Extern steht mehr Software zur Generierung oder Weiternutzung zur Verfügung.
• Beispiel: Modul:JSTOR/config.json

Rückfallposition

Es muss immer damit gerechnet werden, dass externe Vereinbarungen oder die lokale Sprache nicht verfügbar sind.

• Es muss immer eine Zeichenkette zurückgegeben werden.
• Im Idealfall wird auf die englischsprachigen Texte zurückgegriffen.
• Mindestens muss der Bezeichner des Textbausteins, eingefasst in mehrere Klammern, zur Identifizierung des Problems dargestellt werden.
• Eine fehlende Seite darf keinen unspezifizierten Skriptfehler auslösen.

Quellcode und Vorschau

In den nachfolgenden Abschnitten

wird beschrieben, wie sich in der Wiki-Umgebung Lua-Quellcode eingeben und testen lässt.

Code-Editor

Bei den dafür vorgesehenen Seiten des Modul-Namensraums schaltet sich bei der Bearbeitung der Seite immer automatisch der CodeEditor zu.

• wikEd usw. müssen abgeschaltet sein.
• Der VisualEditor sollte sich seit Mitte 2013 selbst abschalten.

Seitenvorschau und Testseite

Ähnlich wie bei Vorlagen gibt es (statt) der normalen Seitenvorschau zwischen Speichern und Änderungen zeigen im Feld darunter zusätzlich Vorschau zeigen zur Darstellung einer spezifizierten Seite, bei der der im Bearbeitungsfeld vorhandene Code so behandelt wird, als wäre das zugehörige Modul bereits gespeichert.

Das bietet sich insbesondere für die Testseite an:

• Zu jedem produktiven Modul sollte eine Testseite in Wikisyntax vorhanden sein. Sie erlaubt einen routinemäßigen Schnelltest, ob das Modul noch prinzipiell in ordnungsgemäßem Zustand ist.
• Es sind nach Funktionen gegliedert die typischen Vorlageneinbindungen und dafür das erwartete Ergebnis und das momentane Resultat aus dem Lua-Modul gegenüberzustellen, so dass sie unmittelbar und übersichtlich verglichen werden können.
• Gleichzeitig kann die Testseite als Bestandteil der Dokumentation alle diese Beispielfälle zur Veranschaulichung nutzen.

Beispiele: URLutil und TemplatePar.

Damit kann der Lua-Quellcode auch nach und nach in der Seitenvorschau entwickelt werden, ohne jede einzelne Version speichern zu müssen.

Konsole

Wenn man ein Modul mit existierendem Quellcode im Bearbeitungsfeld zum Bearbeiten geöffnet hat, erhält man im Fußbereich der Seite eine Fehlerbereinigungskonsole.

• Dies gilt also nicht bei einer neu erstellten Seite beim ersten Öffnen mit action=edit; auch hier jedoch nach der ersten Seitenvorschau als action=submit.

Suche nach Syntaxfehlern

Mit der Maus in das grau unterlegten Eingabefeld der „Fehlerbereinigungskonsole“ gehen, ein Gleichheitszeichen = eingeben und die Taste Enter drücken.

• Wirkung: Der Quellcode im Bearbeitungsfeld wird per API zum Server geschickt, ausgewertet und einige Momente später dargestellt.
• Es wurde jedoch keine Funktion aufgerufen; also wird es kaum ein Resultat des Quellcodes geben.
• Dafür erhält man eine englischsprachige Fehlermeldung mit Angabe der Zeilennummer. Bei aktiviertem Code-Editor wird die Zeilennummer auch im Bearbeitungsfeld dargestellt.

Statische Ausdrücke

Statische Ausdrücke ohne Bezug zum Bearbeitungsfeld können berechnet werden, indem ein Gleichheitszeichen vorangestellt und Enter gedrückt wird.

Modulwert p

Die Variable p steht im Konsolenfenster für den Rückgabewert des Moduls – völlig egal, welchen Namen diese lokale Variable im Modul trägt.

In das Konsolfeld wird eine Komponente des Modul-Rückgabewerts p (Variable oder Funktionsaufruf) eingetragen, ein Gleichheitszeichen vorangestellt und Enter gedrückt.

mw.log()

Anweisungen der Art mw.log(text) bleiben scheinbar wirkungslos; ausgenommen:

1. in der Konsole,
2. bei der Seitenvorschau im Parser Profiling Report.
   • Dieser ist für Normalbenutzer unsichtbar; Lua-Programmierer werden ihn sichtbar gemacht haben und auswerten.
   • Dort unter der Überschrift „Lua-Logbücher“ und kann dann ausgeklappt werden.

Es sind beliebig viele Argumente beliebigen Datentyps möglich, die fomatiert mit etwas Abstand hintereinander gezeigt werden.

Damit können während einer Testphase noch Meldungen in die Programmierung des Moduls eingestreut werden, ohne das Gesamtergebnis der Auswertung zu stören.

In einer produktiven Version sollte es jedoch nicht mehr auftreten.

mw.logObject( object, prefix )

Genauso wie mw.log(), jedoch mit einer table als erstes Argument object. Die Komponenten werden optisch gegliedert dargestellt.

Ein optionales zweites Argument prefix kann eine Zeichenkette sein, die den angezeigten Namen des object benennt.

print()

Diese Funktion ist ein Alias für mw.log() und für ein Wiki nur innerhalb der Konsole möglich. Es ist gleichzeitig ein Alias für das Gleichheitszeichen.

Wie dort sind in der Konsole lokale Informationen des Moduls nicht verfügbar.

Bedienung:

• Die bislang erzielten Ergebnisse der Konsole bleiben sichtbar, bis Leeren gedrückt oder die Seite neu aufgebaut wird.
• ↑ gibt Zugriff auf vorige Eingaben.

Für die Gesamtwirkung der Modul-Ergebnisse ist die Vorschau-Funktion wichtiger, insbesondere mit der im vorigen Abschnitt dargestellten Testseite.

Debugging-Meldungen

Während bei der Seitenvorschau der Modul-Einbindung die von mw.log() ausgeworfenen Meldungen in der Konsole sichtbar sind, erscheinen sie seit Juli 2014 in der normalen Seitenvorschau/Ansicht im Parser-Report. Dieser ist in der deutschsprachigen Wikipedia allerdings standardmäßig ausgeblendet.

Benutzer-Spielwiese

In der Vorlagenspielwiese können Module analog zum Modul-Namensraum entwickelt werden.