Wikiup Diskussion:Lua/Modul/Expr

Vorlagenprogrammierung	Diskussionen	Lua			Test	Unterseiten
		Modul	Deutsch	English		Modul:	Dokumentation

Retrieve localized message string in content language

besser in ein Extra-Modul? Oder ist das problematisch, weil man dann eine Abhängigkeit hat? -- RE rillke fragen? 11:20, 8. Aug. 2013 (CEST)

• Nein; es versteht im Prinzip auch heute schon translatewiki-Messages.
  • local messagePrefix = "lua-module-Expr-"
  • Implementiert ist bereits: {{int:lua-module-Expr-ErrorExpr}}
  • Die l10nDef sind nur die Rückfallposition; in de auch nur vorläufig, bis wir hier mehr geübte Lua-Programmierer und einen Lua-Admin hätten; und solche Lokalisierungen planmäßig unterstützen würden.
• Das Modul als Ganzes war eine notfallmäßige Sturzgeburt; es stehen noch 12 weitere Funktionen und eine von mir erbetene Scribunto-Bibliothek aus.
• Von daher habe ich die Angelegenheit auf „rennt nicht weg“ gelegt.
• Siehe auch: Hilfe:Lua/Internationalisierung.

Danke der Nachfrage --PerfektesChaos 11:56, 8. Aug. 2013 (CEST)

Wie das funktioniert, habe ich verstanden. Was ich wissen wollte, ist, warum man die Logik nicht in ein Mini-Modul verschiebt. (z.B. falls man eines Tages doch noch eine bessere Möglichkeit zur Lokalisierung entdeckt; oder wenn ein anderes Projekt eine andere Lösung für dieses Problem nutzen möchte) MediaWiki messages sind für mich auf Commons der Horror: >300 Übersetzugnen im besten Fall für 1 Message; da bekomme ich schon Gänsehaut, wenn ich nur an die ersten 20 edit requests denke)

Danke für den Tipp mit Hilfe:Lua/Internationalisierung. Auf Commons haben wir gar keinen, der sich so richtig um LUA kümmert :-( -- RE rillke fragen? 12:08, 8. Aug. 2013 (CEST)

Überflutung des Modul-Namensraums mit Mini-Teilen aus einem halben Dutzend Zeilen, die alle zu dokumentieren, zu pflegen und zuzuordnen wären. Wenn man tatsächlich beginnt, das auf andere Projekte zu verteilen, dann muss man auch noch ein weiteres Modul übermitteln und pflegen und dependencies deklarieren und in jedem Projekt aktualisieren. Dann lieber in der upstream-Version alle bekanntwerdenden Übersetzungen sammeln, und alternativ dem Empfänger die Messages zum vorrangigen Überschreiben überlassen, wem es nicht passt. Wenn sich der Aufwand zu lohnen beginnt, gibt es die beschleunigte Funktion mw.loadData(). Problem ist gegenüber den Messages, dass alle Seiten neu aufgebaut werden müssen, auch wenn sich in einer anderen Sprache etwas ändert; und man müsste sicherheitshalber bei jeder Verbesserung in einer anderen Sprache die aktuelle Sprachversion zur Konsistenz an alle Sprachen verteilen, weil sich auch eine ID geändert haben könnte und das L10N-Modul immer zum Berechnungsmodul passen muss. Für eine Meldung in zwei Sprachen lohnt sich das hier nicht. Das translatewiki ist dagegen eine eingefahrene Infrastruktur mit zentralem Zugriff, da dem Server alle Messages bekannt sind. Grüße --PerfektesChaos 12:51, 8. Aug. 2013 (CEST)