Diese Projektseite stellt 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.

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.

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()).

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.

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.

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.

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.

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.

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.

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 enthält.

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.

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.

• Daten – Technische Konzepte