Hilfe:Lua/Internationalisierung

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.

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

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.

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.

Weitere Informationen

Daten – Technische Konzepte