Wikipedia:Lua/Werkstatt/Archiv/2013

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia:Lua/Werkstatt/Archiv/2013#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Lua/Werkstatt/Archiv/2013#Thema_1

Vorlage:Benutzer

• Spezial:Permalink/117376551?title=Vorlagen/Werkstatt #Vorlage:Benutzer Anpassung
• Es sollen möglicherweise unterschiedliche Anfragen/Links gestaltet werden je nach IP-Typ v4/v6.
• Insbesondere soll aber ein altes Problem gelöst werden: Benutzernamen, die nur aus Ziffern bestehen oder sonst einer IP formal ähnlich sehen, sollen als registrierte Benutzer behandelt werden.
  • Zurzeit wird wohl geprüft, ob der Benutzername in Kleinschreibung gleich ist mit dem in Großschreibung, und in diesem Fall IP angenommen.
  • Beginnt der Benutzername nicht mit einem (europäischen) Buchstaben, kann das immer der Fall sein.
• Modul (geplant): URLutil

--PerfektesChaos 11:33, 11. Apr. 2013 (CEST)

→ Wikipedia:Lua/Werkstatt/Archiv/Modul/URLutil

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 00:03, 15. Apr. 2013 (CEST)

Wikipedia Diskussion:DÜP#Vorlage:Information mit nicht vorhandenen Parametern

Ist das etwas, wofür man Lua verwenden kann und es sinnvoll wäre? --Leyo 14:44, 24. Apr. 2013 (CEST)

• Siehe erstes Thema auf dieser Seite.
• Allmählich gewöhne ich mich an diese Babysprache.
• Ich denke noch über eine geschickte Syntax für Bezeichner aus mehreren Wörtern nach.
  • Wie oben whitespace separated list geht nicht.
  • Aber Gleichheitszeichen können nicht in Bezeichnern vorkommen, und machen ansonsten keinen syntaktischen Ärger.
    • arg2=NAME=BILD = BESCHREIBUNG=HÖHE DES LEUCHTTURMS=POSITION
• Wiedervorlage im Mai.

LG --PerfektesChaos 21:58, 24. Apr. 2013 (CEST)

Sieht nicht gut aus; siehe oben --PerfektesChaos 21:02, 25. Apr. 2013 (CEST)

OK, schade. Dann bleibt wohl nur eine switch-Lösung mit allen verdächtigen Parameternamen… --Leyo 08:54, 26. Apr. 2013 (CEST)

→ TemplatePar

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 16:59, 28. Apr. 2013 (CEST)

Vorlage:Str find

Siehe Wikipedia:WikiProjekt Vorlagen/Werkstatt#Vorlage:Str find --Mps、かみまみた^Disk. 12:17, 9. Mai 2013 (CEST)

Umgesetzt. Damit erledigt. ÅñŧóñŜûŝî (Ð) 23:41, 9. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 23:41, 9. Mai 2013 (CEST)

Modul:Str, Funktion right

Die Funktion right im Modul:Str (benutzt in {{Str right}}) ist fehlerhaft implementiert:

Eingabe	Ist	Soll
{{Str right| lorem ipsum dolor sit amet | 10 }}	sum dolor sit amet	m dolor sit amet
{{Str right| lorem ipsum dolor sit amet | 1 }}	lorem ipsum dolor sit amet	orem ipsum dolor sit amet
{{Str right| lorem ipsum dolor sit amet | 0 }}	lorem ipsum dolor sit amet	lorem ipsum dolor sit amet

Der aktuelle Code

function Str.right(frame)
  return mw.ustring.sub(frame.args[1],-1 * frame.args[2],-1)
end

muss geändert werden zu

function Str.right(frame)
  return mw.ustring.sub(frame.args[1], frame.args[2] + 1, -1)
end

--Mps、かみまみた^Disk. 12:32, 9. Mai 2013 (CEST)

Die Modulfunktion ist aber nicht mit der Funktion der Vorlage identisch. Die Vorlage soll "alles rechts von "N" zurückgeben, die Modulfunktion aber "N Zeichen von rechts". Das ist ein Unterschied, den ich auch so wollte. ÅñŧóñŜûŝî (Ð) 17:39, 9. Mai 2013 (CEST)

Die Vorlage:Str right ist aus der englischen Wikipedia importiert worden, hat denselben Namen und hatte bis vorgestern auch dasselbe Verhalten und ich wünsche, dass es beim ursprünglichen Verhalten bleibt. Das bisherige Verhalten ist: {{Str right|String|n}} gibt „String“ ohne die ersten n Zeichen aus (oder den leeren String, falls n > Länge von „String“), also genau das, was in der vorstehenden Tabelle als „Soll“ eingetragen ist.

Es gibt keinen Grund, daran irgendetwas zu verändern. Übrigens hat Antonsusi (mutmaßlich als „Hotfix“ für die kaputte Vorlage – einen nachvollziehbaren Grund hat er nicht benannt) gerade massenhaft {{Str right|String|n}} durch {{Str sub|String|n|999}} ersetzt. Gerade dieses Verhalten sollte die Vorlage:Str right zeigen, aber natürlich ohne die unsinnige Schranke 999. --Entlinkt (Diskussion) 18:42, 9. Mai 2013 (CEST)

Nun mach mal etwas langsamer. Die Vorlage Str_right war schon immer eingeschränkt. Die alte Vorlage ging nur bis ca. 100 und war ein "Switch-Monster". Da ist 999 schon viel besser. Eine fehlende Schranke wäre eine Neuerung. Ich werde das schreiben, testen und dann das Modul anpassen. Bitte nicht drängeln, du willst doch, dass es funktioniert, oder ? ;-) ÅñŧóñŜûŝî (Ð) 19:58, 9. Mai 2013 (CEST)

Nachtrag. Jetzt läuft es abwärtskompatibel. Damit ist das wohl erledigt. ÅñŧóñŜûŝî (Ð) 23:41, 9. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 23:41, 9. Mai 2013 (CEST)

Abfragen der tatsächlichen Parameter der umgebenden Vorlage

• Wikipedia:WikiProjekt Vorlagen/Werkstatt #commons:Commons:Forum.23Template:De: Fehlerliste
• würde nicht gehen? – TMg schrieb: „hurra, es funktioniert“.
  • test2wiki:Module:Template parameters
  • test2wiki:User:TMg/sandbox

Sowas wäre jedoch wünschenswert für eine Standardfunktion in Utilities:

• arg1= (optional) Template name, for message, category and backtracing
  • : – if n/a
• arg2= (optional) whitespace separated list of mandatory parameter names
• arg3= (optional) whitespace separated list of optional parameter names
  • und was weder arg2 noch arg3 ist, ist unerwartet.
  • Was in arg2 fehlt, gibt auch Zoff. Unbenannte als 1, 2, ...??
  • Both arg2 and arg3 may be empty.
• arg4= (optional) Return error message within <span class="error">
  • : – default message
  • Return empty string if not provided.
• arg5= (optional) Name of a maintenance category; $1 will be replaced by arg1 if not arg1==:
  • : – default maintenance category

Either arg4 or arg5 should be provided, otherwise silent death.

--PerfektesChaos 09:47, 16. Mär. 2013 (CET) erg 14:15, 21. Mär. 2013 (CET)

Bezüglich meiner Entfernung: Da liegt ein Missverständnis vor. Die Argumente der umgebenden Vorlage könnten so tatsächlich abfragbar sein (nicht getestet). Nur hat das nichts mit der "Elternumgebung" im Sinne von Lua zu tun. Deshalb ist das dort falsch. --Entzücklopädie 10:35, 16. Mär. 2013 (CET)

Dann sollte der Unterschied zwischen „Elternumgebung“ und „Parent“ auf der Hilfeseite ggf. klargestellt und ausdifferenziert werden, kein Problem.

Ich verstehe ja, dass alles losrennt, sobald es ein neues Spielzeug gibt. Aber wir sollten uns ein paar Wochen Zeit lassen. Ich selbst kam bislang nur zu einigen Dreizeilern und zum Querlesen der Doku. Details und Tücken ergeben sich erfahrungsgemäß beim praktischen Umgang, und da können noch kleine allgemeine organisatorische Justierungen nach den ersten Erfahrungen folgen. Erst über Ostern werde ich Zeit haben, intensiver in Lua selbst zu programmieren.

Schönes Wochenende --PerfektesChaos 11:42, 16. Mär. 2013 (CET)

Nachtrag für den Fall, dass es doch irgendwie gehen würde:

Gleichheitszeichen können nicht in Bezeichnern vorkommen, und machen ansonsten keinen syntaktischen Ärger.

• arg2=NAME=BILD = BESCHREIBUNG=HÖHE DES LEUCHTTURMS=POSITION

Irrtümer entfernt. Ich hatte mich in meiner Scheinwelt aus Dummy-Seiten, Vorlagen und Untervorlagen verheddert. VG --PerfektesChaos 21:02, 25. Apr. 2013 (CEST) // PerfektesChaos 09:47, 27. Apr. 2013 (CEST)

→ TemplatePar --PerfektesChaos 16:59, 28. Apr. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:11, 15. Mai 2013 (CEST)

Vorlageneinbindung in Lua

Hallo, gibt es eigentlich eine Möglichkeit einen Teil der Ausgabe eines Lua-Skiptes normal mit der Wiki-Syntax auszugeben? Beispiel: Mein Lua-Skipt gibt „XYZ ... {{DOI|10.1007/10681604_36}}.“ aus. Kann diese Zeichenkette dann nochmal durch den Wiki-Parser gejagt werden so dass die Vorlage:DOI ausgeführt wird? Das ist sicher im nicht die angestrebt Lösung, aber um schnell bestimmte Sachen zu testen, wäre es praktisch. --Cepheiden (Diskussion) 16:16, 10. Apr. 2013 (CEST)

• Das hätte nichts mit irgendwelchen Hacks und Behelfslösungen zu tun, sondern ist eine ganz reguläre und so vorgesehene Methodik.
• Im Zusammenhang beschrieben ist es kurz unter Hilfe:Lua #Aufruf / Einbindung.
• Konkret suchst du mw:Extension:Scribunto/Lua_reference_manual #frame:expandTemplate.

Liebe Grüße --PerfektesChaos 20:23, 10. Apr. 2013 (CEST)

ahh danke, dass hilft mir etwas weiter. --Cepheiden (Diskussion) 00:16, 11. Apr. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:11, 15. Mai 2013 (CEST)

Lua-Arbeiten zum Zitation-Modul

Hallo PerfektesChaos, hallo Zusammen, ausgehend von der Diskussion unter Vorlage_Diskussion:Literatur#Koordination_der_Lua-Arbeiten möchte an dieser Stelle die Lua-Arbeiten zum Zitation-Modul koordinieren. Das Modul soll irgendwann alle Lua-Umsetzungen der Vorlagen {{Literatur}}, {{Internetquelle}}, {{Cite book}}, {{Cite web}}, {{Cite journal}} sowie {{Patent}} usw. umfassen. Günstig wäre es eine Art Universalvorlage zu schaffen, wie es auch die englische Wikipedia macht (allerdings in de-Wiki nach Vorgaben aus Wikipedia:Literatur usw.). Die Fragen sind nun, wie sollte man das neue Modul (mein Vorschlag Modul:Zitation) organisieren und ist es eurer Meinung hier die Funktionen analog zu englischen Wikipedia anzulegen oder eigene Strukturen zu schaffen? --Cepheiden (Diskussion) 10:48, 9. Mai 2013 (CEST)

Ich habe zur Entlastung dieser Seite und der Beos mal angelegt: /Zitation

Bis gleich dort. --PerfektesChaos 22:19, 9. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:11, 15. Mai 2013 (CEST)

Gleichheitszeichen übergeben

Hallo, ich habe mit Modul:AdressenSort ein Problem, das auch für andere Module von Bedeutung sein dürfte. Es ist nicht möglich, einen String mit Gleichheitszeichen zu übergeben:

Bachstrasse 00004

Auch Anführungszeichen etc. helfen nicht. Ist das eine generelle Unmöglichkeit oder gibt es einen Workaround?--Cirdan ± 22:23, 25. Mär. 2013 (CET)

Es greift der identische Trick, der auch für unsere klassische Vorlagensyntax gilt:

• Heißt: Parameternamen mit Gleichheitszeichen voranstellen, wenn unbekannter Text folgt.
• Ansonsten wird alles vor dem ersten Gleichheitszeichen als Parametername interpretiert.
• Unsere Vorlagensyntax ist wohl recht geduldig, wenn komische Parameternamen auftauchen.
• Lua möchte aber keinen Namen Bachstraße 4 (=
• Oben steht unter #Abfragen der tatsächlichen Parameter der umgebenden Vorlage das Gegenstück zu diesem Problem: Wenn in einer Vorlage ein Parameter auftaucht Bachstraße 4 ( – dann würde das innerhalb der Vorlage nicht bemerkt werden können.

VG --PerfektesChaos 22:44, 25. Mär. 2013 (CET)

Vielen Dank für die schnelle Beantwortung der Frage!--Cirdan ± 22:57, 25. Mär. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 22:43, 21. Mai 2013 (CEST)

Kandidat für Vorlage:LuaModuleDoc

Moinsen, ein Referenzkandidat für Vorlage:LuaModuleDoc bietet sich mit 28 Sprachversionen für en:Template:Div col an. S. AnfrageWikipedia:WikiProjekt_Vorlagen/Werkstatt#en:Template:Div_col in der Vorlagenwerkstatt. --2.206.0.4 11:22, 13. Mai 2013 (CEST)

Hallo. Klär mich mal bitte auf, was die genannten Vorlagen miteinander zu tun haben? --Tlustulimu (Diskussion) 15:18, 14. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 22:45, 21. Mai 2013 (CEST)

Wie lassen sich Module kategorisieren?

Hallo. Wie können Module kategorisiert werden? Ich versuche es bei eo:Modulo:BaseConvert mit Hilfe der ersten Kodezeile in eo:Ŝablono:Modula navigado. Aber es klappt leider nicht. Bei der vorigen Version von eo:Ŝablono:Modula navigado wurde zwar kategorisiert, aber leider auch in der Dokumentation. Es soll aber nur das Modul in der Kategorie erscheinen. Was muß also an dem {{#ifeq:-Kram am Anfang von eo:Ŝablono:Modula navigado geändert werden? Ich habe schon gesucht, aber leider nichts passendes gefunden. Können die Doku-Unterseiten überhaupt vom zugehörigen Modul mit Hilfe von Wikivariablen unterschieden werden? Oder ist der Unterseitenkram dort vielleicht unvollständig implementiert worden? Gruß --Tlustulimu (Diskussion) 11:04, 8. Mai 2013 (CEST)

Kara amiko,

schön, dass du hier aufschlägst. Ich hatte mich sowieso schon bei dir melden wollen.

Ich hatte gesehen, das du mal en:Module:IPAddress nach eo:Modulo:IPAdreso geholt hattest. So hatte ich auch mal angefangen, bin aber inzwischen beim wesentlich hilfreicheren Modul:URLutil angelangt, das mittlerweile Produktionsreife erlangte. Ich empfehle eo:, dies zu importieren und uns im Gegenzug eine eo-Doku zu liefern, damit ich mal ein Beispiel für eine dreisprachige Doku habe.

Zur Beantwortung deiner Frage: Ich empfehle eo:, kurz und einfach Wikipedia:Lua/Seitenorganisation und Dokumentation zu übernehmen; in diesem Zusammenhang auch Vorlage:LuaModuleDoc. Diese ist für vielsprachige Doku ausgelegt, und eo wird öfters in die Situation kommen, aus allerlei anderen alliterierenden Sprachen Module mit dortiger Doku zu importieren.

Das beantwortet dann hoffentlich auch deine Frage; Kategorie:Wikipedia:Lua/Modul wird so automatisch angelegt. Unterseiten (Tests) und Sprachversionen müsste man gelegentlich gesondert kategorisieren; da hatte ich aber noch keine Meinung zu.

Wikipedia:Lua/Modul/Vorlage:LuaModuleDoc/local wäre auf eo umzumünzen.

Was heißt „Tschüß“ nochmal in eo? --PerfektesChaos 11:51, 8. Mai 2013 (CEST)

Saluton, PerfektesChaos :-). Danke für deine ausführliche Antwort. Da ich mich zur Zeit in der Esperantowikipedia alleine mit Lua befasse, kann ich ja eigentliche deinen Vorschlag aufgreifen. Ist es denn möglich die Linkliste in der Dokumentation so anzupassen, daß dort denn drei Sprachenlinks erscheinen, nämlich für Esperanto, Englisch und Deutsch?

Die Idee zu Modul:URLutil finde ich gut. Aber die Ergänzung der Dokumentation wird denn aber wohl ein bißchen dauern. Außerdem muß sie ja bei Übernahme des hiesigen Mechanismus sowieso verschoben werden.

„Tschüß“ ist ja schon im Deutschen ein eigentlich umgangssprachliches Wort, so daß es da nahe liegt im Esperanto ebenso ein Wort zu haben. Und es ist dort auch so. Es lautet "Ĝis". Das ist die Kurzform von "Ĝis revido", also "Auf Wiedersehen". Der Buchstabe Ĝ wird wie Dsch in Dschungel ausgesprochen. Gruß --Tlustulimu (Diskussion) 17:21, 8. Mai 2013 (CEST)

Klaro! Im Inneren von Ŝablono:LuaModuleDoc einfach setzen:

langsDefault=eo en de

• Mehr Doku dazu.

Auf Wikipedia:Lua/Modul/Vorlage:LuaModuleDoc/en #Exporting habe ich einen Einkaufszettel geschrieben. Wikipedia:IU wäre stilecht; ansonsten kann auch eo:Uzanto:PerfektesChaos die benötigten Seiten anlegen, womit sich alle Fragen nach URV erledigen.

Weil es dich als ersten treffen wird, hier noch ein Literaturtipp.

eo-Übersetzug einer Doku hat nicht die geringste Eile; wäre nur spaßig.

Ĝis --PerfektesChaos 21:28, 8. Mai 2013 (CEST)

Hallo, PerfektesChaos. Ich habe gerade eine weitere Dokumentation auf das neue Schema umgestellt. Leider funktioniert die Anlaufseite für eins der Module nicht richtig. Hast du eine Ahnung warum? Gruß --Tlustulimu (Diskussion) 09:48, 9. Mai 2013 (CEST)

Ich habe den Fehler gefunden. In der lokalisierten Unterseite fehlte einfach <onlyinclude>, sodaß {{LuaModuleDoc}} doppelt eingebunden worden wäre, was aber nicht geht.

Komisch ist nur, daß trotzdem noch die Meldung "Alidirektilo de la diskutopaĝo mankas" ("Redirect der Diskussionsseite fehlt") auf der bisherigen Dokumentationsseite erscheint, obwohl der Redirect existiert. Woran könnte das liegen? --Tlustulimu (Diskussion) 09:57, 9. Mai 2013 (CEST)

Das hat seine Richtigkkeit.

• Auf eo:Modulo:Listigo/dokumentado eo:Vikipedio:Lua/Moduloj/Listigo/eo gibt es oben im Portal ein redlink Diskuto.
• Dorthin gehört ein

  #ALIDIREKTU [[Vikipedia diskuto:Lua/Moduloj/Listigo]]

• Grund: Zwar steht in der Linkbox schon unter Diskutoj ein blaues Link Vikipedia diskuto:Lua/Moduloj/Listigo, aber das ist nur Insidern in Fleisch und Blut übergegangen. Wer unbeleckt daherkommt und sich äußern möchte, klickt wie gewohnt oben hin, legt eine neue Diskuseite an und schreibt drauflos. Diese Seite wird aber nicht von allen beobachtet, und es sammeln sich überall diverse Brösel. Deshalb soll jedes Disku-Link auf die zentrale Disku weiterleiten; und damit du dran denkst, wird dir das Manko (von manquer) nochmal bewusst gemacht.

Bonan vespero --PerfektesChaos 22:05, 9. Mai 2013 (CEST)

Hallo, PerfektesChaos. Ich habe den Fehler behoben, obwohl das Script eo:MediaWiki:Common.js/documentation_tab.js das Ganze erschwert. Leider verändert dieses auch im Modulenamensraum bei Seiten wie Modulo:Listigo/dokumentado den Link für die Diskussionseite, so daß dieser denn Modulo-Diskuto:Listigo heißt statt Modulo-Diskuto:Listigo/dokumentado. Wie müßte das Script geändert werden, damit die Kürzung im Modulenamensraum unterbleibt, während sie bei Vorlagen ja nicht stört? Du kannst ja auf der Seite eo:MediaWiki-Diskuto:Common.js/documentation tab.js antworten, auch wenn ich dort gerade in Esperanto nachgefragt habe. Du darfst also in Deutsch dort antworten. :-)

Es heißt nicht "Bonan vespero", sondern richtig "Bonan vesperon", also beide Wörter bekommen die Akkusativendung. Gruß --Tlustulimu (Diskussion) 00:23, 10. Mai 2013 (CEST)

• Ich hatte oben ein falsches link angegeben; gemeint hinsichtlich fehlender WL ist eo:Vikipedio:Lua/Moduloj/Listigo/eo.
• Ungefähr dieser Revert sollte den Tab entfernen.
  • Tipp: Statt wgCanonicalNamespace und else if geht es effizienter mit switch ( mw.config.get("wgNamespaceNumber") ) { wie in Benutzer:Flominator/common.js.
• Die Seite Modulo:Listigo/dokumentado ist nur für Wartungszwecke (einmalig beim Einrichten) und wird nie mehr angefasst oder direkt gelesen. Verlinkt ist sie in der Linkbox unter Subpaĝoj, wenn man doch noch mal ranmuss.
• Ansonsten sieht mir aber doch alles okay aus?

Ĝis --PerfektesChaos 10:54, 10. Mai 2013 (CEST)

Hallo, PerfektesChaos. Es ist nun fast alles richtig. Wir waren aber ganz von der Kategorisierung abgekommen. Die Seite Wikipedia:Lua/Modul/URLutil wird ja in eine Kategorie eingeordnet. Ich verstehe nicht, warum denn nun die Esperantoversion keine Kategorie bekommt. Wo wird diese denn definiert? Gruß --Tlustulimu (Diskussion) 12:26, 10. Mai 2013 (CEST)

(+) Der Tab per eo:MediaWiki-Diskuto:Common.js/documentation tab.js soll ja gerade nicht entfernt werden, denn sonst hätte ich ja nicht das Skript ergänzt.

Du hattest auf Wikipedia:Lua/Modul/Vorlage:LuaModuleDoc/en mal etwas über das Importieren von Vorlagen und Modulen geschrieben. Leider ist die Importfunktion in der Esperantowipedia komplett deaktiviert. --Tlustulimu (Diskussion) 12:46, 10. Mai 2013 (CEST)

Hallo. Die Kategorisierung mit der Entsprechung von {{LuaModuleDoc}} hat sich wohl fast erledigt, nachdem ich die Entsprechung von Kategorie:Wikipedia:Lua/Modul angelegt habe, nämlich eo:Kategorio:Vikipedio:Lua/Moduloj. Allerdings ist es seltsam, daß dort nur 4 Seiten gelistet sind. Muß ich dort noch irgendwo purgen? Gruß --Tlustulimu (Diskussion) 17:58, 16. Mai 2013 (CEST)

Modul Listigo (listify)

Ich teile mal auf, damit es nicht noch länger wird. --Tlustulimu (Diskussion) 23:06, 16. Mai 2013 (CEST)

• Purgen klingt gut.
  • Grad sah ich 6?
• Das Modul produziert keine redlinks und erwartet eine Kategoriebeschreibung.
• Wenn zum Zeitpunkt des Einfügens der Vorlage keine Kategorie unter dem angegebenen Titel sichtbar ist, wird in die nicht existierende Kategorie nichts einsortiert.
• Wenn nachträglich die Kategoriebeschreibung angelegt wird, können die vorhandenen Seiten davon nichts wissen, und werden erst durch Purge/Edit aktualisiert.
• Die Doku-Seiten habe ich soeben in diesem Sinn präzisiert.
• In den letzten Tagen hatte ich eo besucht, nach der Kat geschaut und auch Einträge darin gefunden und hielt die Angelegenheit für erledigt.
• Zu listigo: Ich habe nicht so ganz verstanden, was das Ziel ist, aber es klingt so, als ob du etwas suchst wie

 s = v:match( "%[%[[^|%]]*| *([^%]]+) *%]%]" )
 if not s then
     s = v:match( "%[%[%s*([^%]]+)%s*%]%]" )
 end
 if not s then
     s = v
 end

• Die erste Klammer heißt übersetzt: Setze s, wenn etwas gefunden wird, das
  • "[["
  • + allerlei, das weder | noch ] ist
  • + Pipe
  • + potentielle Leerzeichen
  • + MERKEN→s: allerlei, das keine ] ist
  • + potentielle Leerzeichen
  • + "]]"
• Es gibt en:Module:WikiLink, wo vielleicht etwas Fertiges bei ist. Wobei das vermutlich geeignete dewiki eine Frechheit ist.

LG --PerfektesChaos 20:42, 16. Mai 2013 (CEST)

Hallo, PerfektesChaos. Wie kann denn der Code

 s = v:match( "%[%[[^|%]]*| *([^%]]+) *%]%]" )
 if not s then
     s = v:match( "%[%[%s*([^%]]+)%s*%]%]" )
 end
 if not s then
     s = v
 end

verwendet werden? Muß daraus eine Funktion werden? Wenn ja, kannst du mir das mal auf der dortigen Modulspielwiese zeigen? Gruß --Tlustulimu (Diskussion) 21:29, 16. Mai 2013 (CEST)

Um sinnvoll antworten zu können, müsste ich die Aufgabenstellung verstehen.

Ich habe es aus listigo entnommen an der Stelle, wo trim(v) steht.

Das v ist also das momentane aus k,v und s ist die gesuchte Zeichenkette.

Für jede der folgenden Eingabedaten v kommt (freihändig ungetestet) willhaben heraus:

1. [[Linkziel|willhaben]]
2. [[willhaben]]
3. willhaben

Zum Schluss kann sicherheitshalber s=trim(s) gesetzt werden.

VG --PerfektesChaos 21:53, 16. Mai 2013 (CEST)

Aus dem von dir oben vorgeschlagenen Code soll eine neue Funktion werden, die dann dort eingebunden werden soll, wo jetzt mw.text.trim(v) steht. Geht das? Der Code mw.text.trim(v) soll aber nur in der Funktion "category" durch die neue Funktion ausgetauscht werden. --Tlustulimu (Diskussion) 22:22, 16. Mai 2013 (CEST)

Inzwischen habe ich mir dein Werk nochmal genauer durchgelesen.

local s
for k,v in pairs(strings) do
    s = v:match( "%[%[[^|%]]*| *([^%]]+) *%]%]" )
    if not s then
        s = v:match( "%[%[%s*([^%]]+)%s*%]%]" )
    end
    if not s then
        s = v
    end
    output[k] = '[[Kategorio:' .. cat .. ' ' .. mw.text.trim(s)
    if key and key ~= "" then
        output[k] = output[k] .. '|' .. key
    end
    output[k] = output[k] .. ']]'
end

Du kannst das also direkt in die Schleife schreiben; oder du machst für das Schleifeninnere eine Funktion, die das übersichtlicher erledigt. Das ist Geschmacks- und Stilfrage, wobei ich immer noch nicht verstanden habe, was das eigentlich tut.

local function f(v, cat, key)
    local s
    s = v:match( "%[%[[^|%]]*| *([^%]]+) *%]%]" )
    if not s then
        s = v:match( "%[%[%s*([^%]]+)%s*%]%]" )
    end
    if not s then
        s = v
    end
    s = '[[Kategorio:' .. cat .. ' ' .. mw.text.trim(s)
    if key and key ~= "" then
        s = s .. '|' .. key
    end
    return s .. ']]'
end 

for k,v in pairs(strings) do
    output[k] = f(v, cat, key)
end

LG --PerfektesChaos 22:43, 16. Mai 2013 (CEST)

Schau dir jetzt mal eo:Modulo:Provejo an und probiere die letzten Beispiele aus der Doku von eo:Modulo:Listigo/provejo auf Vorlage expandieren. Also:

{{#invoke:Provejo|category|,|[[kato]], [[hundo]], [[muso]], [[ĉevalo]]}}

{{#invoke:Provejo|category|,|[[Kato|kato]], [[Hundo|hundo]], [[Muso|muso]], [[Ĉevalo|ĉevalo]]}}

Dort erscheinen dann unter "Rezulto" die Kategorien ohne störende geschachtelte Links.

[[Kategorio: kato]][[Kategorio: hundo]][[Kategorio: muso]][[Kategorio: ĉevalo]]

[[Kategorio: kato]][[Kategorio: hundo]][[Kategorio: muso]][[Kategorio: ĉevalo]]

Also genau das, was ich gesucht habe. :-) --Tlustulimu (Diskussion) 22:51, 16. Mai 2013 (CEST)

Die Entlinkung wird später für die Vorlage eo:Ŝablono:Informkesto libro/provejo gebraucht, denn dort habe ich einen neuen Parameter aŭtoroj (Autoren) eingebaut. In ihm sollen die Autoren des Buches alle in einer durch Kommas gegliederten Liste aufgeführt werden. Allerdings soll es auch möglich sein, dort gleich die Namen der Autoren einzeln zu verlinken: der dritte Test (dort Tri testo) hier macht hoffentlich klarer worum es geht. --Tlustulimu (Diskussion) 23:06, 16. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Tlustulimu (Diskussion) 15:59, 12. Jun. 2013 (CEST)

Seitenorganisation und Dokumentation

Bei einem Modul, welches nur für eine bestimmte Vorlage gedacht ist, ist eine derartige Organisation total übertrieben. Immerhin gibt es dadurch mind. zehn Seiten:

1. Modul:Vorlage:XYZ
2. Modul:Vorlage:XYZ/Doku
3. Vorlage:XYZ
4. Vorlage:XYZ/Doku
5. Wikipedia:Lua/Modul/Vorlage:XYZ
6. Wikipedia:Lua/Modul/Vorlage:XYZ/de
7. Modul Diskussion:Vorlage:XYZ
8. Vorlage Diskussion:XYZ
9. Wikipedia Diskussion:Lua/Modul/Vorlage:XYZ
10. Wikipedia Diskussion:Lua/Modul/Vorlage:XYZ/de

Das ist in so einem Fall total übertrieben. Hier würde ausreichen:

1. Modul:Vorlage:XYZ
2. Modul:Vorlage:XYZ/Doku
3. Vorlage:XYZ
4. Vorlage:XYZ/Doku
5. Modul Diskussion:Vorlage:XYZ
6. Vorlage Diskussion:XYZ

Doku- oder eigene Diskussionsseiten im WP-Namensraum sind hier nicht erforderlich. Ebenso Übersetzungen in Englisch (oder Chinesisch). Wer Fragen hat, kann sich ja auch an die Vorlagen- oder Lua-Werkstatt wenden. ÅñŧóñŜûŝî (Ð) 21:39, 12. Mai 2013 (CEST)

Wenn hier keine Sachargumente dagegen vorgebracht werden, dann werde ich in derartigen Fällen die verkürzte Version anwenden. ÅñŧóñŜûŝî (Ð) 13:41, 14. Mai 2013 (CEST)

Kannste haben.

1. Es ist für Menschen wie für Maschinen sehr viel leichter und weniger verwirrend, ein Schema enheitlich anzuwenden, als es unter unvorhersagbaren Umständen mal so, mal so zu handhaben.
2. Eine englischsprachige Version ist nicht zwingend; siehe Modul:Zitation.
3. Bei deinem Vorschlag gibt es keinerlei Platz für eine Lua-Testseite.
   • Insbesondere kann man nachträglich keine Seiten einfügen, ohne dafür alles auf die Standardstruktur verschieben zu müssen.
4. Die von dir beanstandeten Seiten enthalten gerade mal eine Zeile; eine Weiterleitung oder die 16–19 Zeichen der Vorlage.
5. Verglichen mit dem Gesamtaufwand für die Erstellung eines guten Moduls ist der Aufwand geringfügig; der Nutzen groß.
6. Die Mitarbeiter der Vorlagen- oder Lua-Werkstatt schauen zur Beantwortung der Fragen in die Dokumentation. Die ursprünglichen Autoren waren vielleicht Jahre zuvor aktiv gewesen. Die Dokumentation muss also Zweck und Schnittstelle nach außen hinreichend genau erklären; sowie etwaige Besonderheiten. Ein Hinweis darauf, dass auf WP:Lua oder in der Lua-Werkstatt schon irgendjemand erklären würde, wie es funktioniert, ist nicht ausreichend.

Eile mit Weile --PerfektesChaos 14:19, 14. Mai 2013 (CEST)

Ok, das überzeugt mich. Das Ganze sollte aber noch "aufgepäppelt" werden:

1. Die Beschreibung der Vorgehensweise sollte besser und übersichtlicher formuliert werden.
2. Eine praktische Unterstützung zum Anlegen der Seiten, ähnlich wie bei der Wikivorlage Dokumentation, wäre sinnvoll.
3. Die Rekursion (s.u.) sollte auch ohne onlyinclude oder noinclude verschwinden.

Gruß von ÅñŧóñŜûŝî (Ð) 14:31, 14. Mai 2013 (CEST)

Schön, dass man argumentativ durchdringt.

Selbstverständlich sollen auch mehr Seiten aufgebaut und über den elementaren technischen Abriss hinaus für Einsteiger verständlicher werden.

Ich bin selbst noch im Lernprozess und dokumentiere meine abgeschlossenen Lernschritte in Form von H- und WP-Seiten. Gerade heute habe ich wieder was gelernt.

Mehrere weitere Seiten habe ich als Rohtext auf der Festplatte.

Eine Rekursion, wie von dir gewünscht, ist grundsätzlich nicht möglich. Das würde bedeuten, dass eine Vorlage (Vorlage:LuaModuleDoc) sich selbst (Vorlage:LuaModuleDoc) auf einer anderen Seite wieder einbindet. Dies war noch nie möglich und ist auch mit Lua wegen Endlosschleife untersagt.

• Was ich tun kann, ist eine Warnung (Fehlermeldung), wenn die Einbindung weder vor onlyinclude noch in noinclude steht. Dies habe ich bereits programmiert; jedoch steht das Testen noch aus.
• Ansonsten gehen die meisten Leute so vor, dass sie ihr letztes Werk mit C&P auf die neue Seite holen oder die angebotene Kopiervorlage nutzen. Ich persönlich tippe ungern Quellcode von Null auf.

Beste Grüße --PerfektesChaos 14:47, 14. Mai 2013 (CEST)

??? Ich wünsche keine Rekursion, sondern deren Beseitigung. Die Endlosschleife existiert ohne onlyinclude oder noinclude bereits. Du hast doch beim Modul:Vorlage:Personenleiste schon mal "was probiert". Wenn das Modul von LuaModuleDoc vor der Einbindung von Wikipedia:Lua/Modul/XYZ/de in Wikipedia:Lua/Modul/XYZ den String {{LuaModuleDoc}} aus dem gelesenen Quelltext von Wikipedia:Lua/Modul/XYZ/de entfernt, dann müsste die Rekursion doch weg sein, oder? ÅñŧóñŜûŝî (Ð) 15:09, 14. Mai 2013 (CEST)

Nennen wir es das Thema „Rekursion“. Der Versuch brachte nur einen Teilerfolg. Dabei gelangte ich zu der Erkenntnis, die ich oben dargelegt hatte. VG --PerfektesChaos 15:30, 14. Mai 2013 (CEST)

Nachtrag: Das führt deshalb nicht zum Ziel, weil dann im Quelltext die vorhandenen noinclude oder onlyinclude nicht ausgewertet werden würden. Diese fallen nur weg, wenn der Server durch den transclude-Prozess geht, und das macht er nicht, wenn die gleiche Vorlage im Seitenaufbau bereits einmal eingebunden war.

C&P einer Musterseite, und schon geht’s. VG --PerfektesChaos 15:34, 14. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 12:22, 7. Jul. 2013 (CEST)

Rekursion in Modul:Vorlage:LuaModuleDoc

Ohne ein passendes <onlyinclude> oder <noinclude> auf Wikipedia:Lua/Modul/XYZ/de kommt es bei der Einbindundung von {{LuaModuleDoc|noHint=1}} auf Wikipedia:Lua/Modul/XYZ zu einer rekursiven Einbindung der Vorlage. Das sollte im Modul geändert werden. Gruß von ÅñŧóñŜûŝî (Ð) 13:14, 13. Mai 2013 (CEST)

Hallo, Antonsusi. Die Meldung kommt auch, wenn man nur {{LuaModuleDoc}} schreibt, also ohne irgendwelche Parameter. Das ist mir mit der portierten Version in der Esperantowikipedia aufgefallen. Gruß --Tlustulimu (Diskussion) 15:17, 14. Mai 2013 (CEST)

Siehe eins drüber.

Ich komme demnächst nach eo und spiele als Autor allerlei neue Versionen auf. Damit sind dann alle URV-Vorstellungen aus der Welt.

• Du kannst mir ja schon mal eine Übersetzung aufschreiben:
• „Vorlage LuaModuleDoc mit fehlerhafter include-Struktur (onlyinclude/noinclude)“

Ĝis --PerfektesChaos 15:38, 14. Mai 2013 (CEST)

Hallo, PerfektesChaos. Die Übersetzung von „Vorlage LuaModuleDoc mit fehlerhafter include-Struktur (onlyinclude/noinclude)“ lautet „Ŝablono LuaModuleDoc kun erara include-strukturo (onlyinclude/noinclude)“. Ich weiß jetzt nicht, ob es sinnvoll wäre auch das Wort „include“ zu übersetzten. Wenn ja, denn hieße es „Ŝablono LuaModuleDoc kun erara inkluda strukturo (onlyinclude/noinclude)“.

Welche Versionen möchtest du denn in der Esperantowikipeda aufspielen? Gruß --Tlustulimu (Diskussion) 15:42, 14. Mai 2013 (CEST)

Funktionale Änderungen gab es in:

• Wikipedia:Lua/Modul-Navigation
• Wikipedia:Lua/Modul-Navigationsfehler
• Modul:LuaWiki
• Modul:Vorlage:LuaModuleDoc

Außerdem einige Doku.

Aber erstmal lassen wir die hier in unseren paar Dutzend Einbindungen köcheln. --PerfektesChaos 15:57, 14. Mai 2013 (CEST)

Ich habe mal kontrolliert, ob die beiden Module auf der Esperantowikipedia geschützt sind. Sie sind für angemeldete Benutzer editierbar, aber nur für Admins verschiebbar. Gibst du mir auf meiner dortigen Diskussionsseite Bescheid, wenn du etwas änderst? Denn kann ich das gleich in die Esperanto-Dokumentationen übernehmen. --Tlustulimu (Diskussion) 17:53, 14. Mai 2013 (CEST)

Ich hätte dich sowieso vorher kontaktiert und erforderlichenfalls um temporäre Entsperrung gebeten. Es kann sich aber noch ein paar Wochen hinziehen. Momentan werde ich leider hier vor Ort ziemlich auf Trab gehalten; jeden Tag ein neues Drama. Deshalb komme ich kaum noch zu einem ruhigen Entwicklungsprozess. So vergaß ich auch bei meiner spontanen Aufzählung, dass sich durch Gerrit:63406 auch URLutil ändern wird; ggf. auch etwas vorfristig. Bonan vesperon --PerfektesChaos 18:34, 14. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 12:22, 7. Jul. 2013 (CEST)

Nebenfrage

Sorry mal eine Nebenfrage: Hier[1] sieht man das es noch nicht so viele "Modul-Dinger" gibt. Kann man irgendwo näheres zur Einführung der Module und von Namespace 828 lesen? --2.206.0.61 18:11, 13. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 12:22, 7. Jul. 2013 (CEST)

isIPv4 in URLutil

Hallo. Ich habe mal mich hier geäußert. Gruß --Tlustulimu (Diskussion) 22:19, 14. Jun. 2013 (CEST)

Ja, danke; jene habe ich auch auf der Beo.

Jetzt grad bin ich müd, aber im Lauf des Wochenendes komme ich als Uzanto vorbei und verteile Updates zu folgenden Seiten:

Wikipedia:Lua/Modul-Navigationsfehler      + BadInclude
                 Ŝablono LuaModuleDoc kun erara inkluda strukturo
                 (onlyinclude/noinclude)
                  pagina:

Modul:Vorlage:LuaModuleDoc                 + Testseiten
Modul:LuaWiki                              FIX
Wikipedia:Lua/Modul-Navigation             + Test Formatierung
                                             ekzameno
Template:LuaModuleDoc                      |subTest = Test
Modul:URLutil        Gerrit:63406  + 3 Funktionen
Wikipedia:Lua/Modul/Ŝablono:LuaModuleDoc/en
Wikipedia:Lua/Modul/Ŝablono:LuaModuleDoc/de
Wikipedia:Lua/Modul/LuaModuleDoc
Wikipedia:Lua/Modul/URLutil/de
Wikipedia:Lua/Modul/URLutil/en

Bis dann --PerfektesChaos 23:31, 14. Jun. 2013 (CEST)

Hallo, PerfektesChaos. Statt Wikipedia:Lua/Modul-Navigation heißt es dort eo:Vikipedio:Lua/Modula navigado und statt Wikipedia:Lua/Modul-Navigationsfehler dann eo:Vikipedio:Lua/Eraro ĉe modula navigado. Das Wort "pagina" gibt es nicht, denn Seite heißt auf Esperanto "paĝo", falls es sich um eine Seite eines Buches, einer Zeitschrift, eines Heftes oder Kalenders usw. oder eine einzelne Seite einer Internetseite handelt.

Die Idee mit dem Link auf Testseiten finde ich gut. Es sollte denn dort aber statt "ekzameno" doch eher "testoj" heißen. Dieses Wort wird schon für Vorlagentests verwendet. Außerdem bezieht sich ja "ekzameno" auf Prüfungen an Schulen, Berufsschulen und Universitäten, paßt also nicht. Gruß --Tlustulimu (Diskussion) 09:15, 15. Jun. 2013 (CEST)

• Danke für die Direktlinks, aber über die eingebundenen Seiten ist es kinderleicht, mit zwei Klicks zu den eo-Versionen zu finden.
• Ich hätte dir sowieso erstmal en oder la hineingeschrieben und dir im Kommentar hinterlassen, wo noch etwas in richtiges eo zu übersetzen wäre. Über die diffpage dann mit Leichtigkeit zu orten.
  • „Test“ gibt es mit zwei Bedeutungen:
    1. Als bloßer Linktitel, was völlig beliebig ist.
    2. Als einheitlicher fester Name der gesuchten Unterseiten (Groß-/Kleinschreibung des ersten Buchstabens egal). Hier wäre in Ruhe die Systementscheidung zu treffen, ob eher international /Test oder ein eo-Wort benutzt werden soll.
• Den Rest bekommst du mit entsprechendem BK im Lauf der Nacht von mir; jetzt grad ist das Wetter zu schön, und die online-Zeit ist rationiert gegen Sonnenstunden.

Saluton --PerfektesChaos 11:29, 15. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 12:26, 7. Jul. 2013 (CEST)

Flagged revs and Lua modules

Flagged revs and Lua modules, Meet Wikipedia, the Encyclopedia Anyone Can Code. --Atlasowa (Diskussion) 23:27, 20. Mär. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Modul:Vorlage:String

Wer arbeitet zurzeit daran ? ÅñŧóñŜûŝî (Ð) 12:22, 10. Mai 2013 (CEST)

• Es gibt weder eine Vorlage:String noch gibt es irgendeine Gruppe von Vorlagen, deren Titel mit String beginnen würde. Insofern wüsste ich nicht, was ein solches Modul bewirken und wozu es gehören solle.
• Falls du hingegen Modul:String meinen solltest, dann steht die Antwort auf deine Frage doch dran: Import aus enwiki. Und zwar in der spätestmöglichen Version mit den meisten Funktionen in der ausgereiftesten Fassung, sobald ein wirklicher Bedarf in der Vorlagenprogrammierung besteht. Dann reicht eine Notiz auf Wikipedia:IU, und binnen weniger Stunden ist das Ding einsatzfähig.

--PerfektesChaos 14:14, 10. Mai 2013 (CEST)

Welchen Vorteil soll es haben, ein derartiges Modul unverändert zu übernehmen? Kompatiblität mit blind abkopierten Vorlagen von En-WP? Mit dem Effekt, dass auch alle Vorlagenparameter Englisch sind und User, welche Englisch nicht beherrschen, aus der dt. WP ausschließen ? Das ist kein Vorteil. ÅñŧóñŜûŝî (Ð) 17:28, 10. Mai 2013 (CEST)

• Das Rad nicht neu zu erfinden
• Vorlagenparameter kann man auf Deutsch in der Doku schreiben und erklären, so wie den ganzen Rest auch (oder man setzt deutsche Kommentare rein)
• Englische Programmiertexte fallen mir wesentlich leichter zu lesen, da u.a. Worte eine "feststehende" Bedeutung haben und man auch nicht die Sprache wechseln muss. Zudem sind die Schnittstellen zu MW/Lua ja in Englisch. Z.B. habe ich mich gefragt, warum Modul:Str#hex2dez nicht hex2dec heißt, Unnötige Fehlerquelle (Wenn dann schon hexZuDez ;)).

--se4598 / ? 18:26, 10. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Vorlage:Lua-Hinweis

Hallo. Ich habe mir mal die Vorlage {{Lua-Hinweis}} angeschaut. Der dortige Text paßt aber jetzt nur zu Vorlagen, die mehr oder wenig vollständig über Lua laufen. Wäre da nicht eine etwas andere Formulierung besser, falls nur einige Parameter über Lua umgesetzt werden, wie beispielsweise diese hier?

• Diese Vorlage verwendet Lua für die Parameter Bild, Breitengrad, Längengrad.

Allerdings müßte sie denn einen Parameter bekommen, über den die betreffenden Parameter aufgeführt werden können. Wie so etwas aussehen kann, habe ich mal in der Esperantowikipedia umgesetzt. Der dortigen Quelltext nutzt allerdings bereits ein Lua-Modul, welches hier noch fehlt. Gruß --Tlustulimu (Diskussion) 20:02, 14. Mai 2013 (CEST)

In den mit der genannten Vorlage per Interwiki verlinkten Vorlagen wird sogar automatisch kategorisiert. Was haltet ihr davon? --Tlustulimu (Diskussion) 20:20, 14. Mai 2013 (CEST)

In den Baustein soll eigentlich nicht so viel hinein. Genaueres gehört ggf. zur Doku. ÅñŧóñŜûŝî (Ð) 22:20, 14. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

charAt(0).toLower

Hi! Verzeiht mir die evtl. redundante Frage, ich beschäftige mich jetzt zum ersten Mal mit diesem neumodischen Schnickschnack. ;o)

Ich hätte gerne von einem String (genauer: vom Seitennamen) den ersten Buchstaben, und zwar klein. Ich habe weiter oben von der Existenz von en:Module:String gelesen, aber das ist in de-WP ja noch nicht benutzbar, wenn ich das richtig verstanden habe. Gibt es also eine Realisierungsmöglichkeit für mein Anliegen?

Viele Grüße, --Nirakka ^Disk. Bew. 10:46, 17. Mai 2013 (CEST)

Realisierbar ist das in jedem Fall.

Ab jetzt soll in den Vorlagen nicht mehr mit lauter Einzel-Zeichenketten gewirtschaftet werden. Wenn du noch mehr mit der Zeichenkette programmieren möchtest, dann schildere bitte das ganze Problem samt Beispiel-Vorlage; vielleicht tun sich ungeahnte Möglichketen auf.

Ansonsten klingt deine Frage so, als ob dir mit altmodischer Vorlagensyntax zu helfen wäre (ungetestet, freihändig):

{{lc:{{padleft:|1|{{PAGENAME}}}}}}

Liebe Grüße --PerfektesChaos 11:08, 17. Mai 2013 (CEST)

Hey, lc kling gut; wusste gar nicht, dass wir dafür eine Variable haben. padleft schneidet aber nichts weg, sondern füllt nur auf. Habe jetzt nochmal bei den Variablen geguckt und spontan keine Präfixfunktion gefunden, aber vermutlich stelle ich mich nur wieder zu doof an. Gruß, --Nirakka ^Disk. Bew. 11:31, 17. Mai 2013 (CEST)

Was ich dir geschrieben habe, stimmt schon. Mit „padleft schneidet aber nichts weg, sondern füllt nur auf“ hast du leider den Witz nicht verstanden.

1. Der erste Parameter von padleft: ist die Zeichenkette. Die habe ich hier mit „nichts“ angegeben.
2. Der zweite Parameter von padleft: ist die resultierende Gesamtlänge. Die habe ich hier mit 1 angegeben.
3. Der dritte Parameter von padleft: ist das, womit zum Erreichen der Gesamtlänge aufgefüllt werden soll – wie du richtig anmerktest. Hier habe ich {{PAGENAME}} angegeben. Das heißt: Fülle die leere Zeichenkette so lange mit den Zeichen von {{PAGENAME}} auf, bis das Resultat die Länge 1 hat. Und das ist das, wonach du suchtest.

HGZH --PerfektesChaos 11:51, 17. Mai 2013 (CEST)

Ah, natürlich, schick. Das habe ich falsch interpretiert. Sorry und vielen Dank, --Nirakka ^Disk. Bew. 12:02, 17. Mai 2013 (CEST)

So, ich mache dann hier nochmal auf und stelle wie gewünscht das gesamte Problem zur Schau. Es geht um die inzwischen frisch erstellt Vorlage:DBLP. Mit Konrad Zuse klappt es, bei Richard M. Stallman gibt es Probleme: Das Leerzeichen müsste durch _ und der Punkt durch = ersetzt werden. Wie lässt sich das Ersetzen realisieren? Gruß, --Nirakka ^Disk. Bew. 12:56, 17. Mai 2013 (CEST)

Schau mal auf

• {{urlencode:Parameter|WIKI}}
• {{urlencode:Parameter|PATH}}
• {{urlencode:Parameter|QUERY}}

WIKI macht einen _ und der Punkt ist doch eigentlich kein Problem oder geht so in der URL?

Wenn das nicht hilft, wäre es günstiger, du würdest diese Aktion mal für einen Monat auf Eis legen; dann wissen wir alle wieder etwas mehr.

VG --PerfektesChaos 13:31, 17. Mai 2013 (CEST)

Bindestriche, Apostrophe und vermutlich noch andere müssten ebenfalls durch "=" ersetzt werden, siehe http://www.informatik.uni-trier.de/~ley/pers/hd/b/Berners=Lee:Tim.html und http://www.informatik.uni-trier.de/~ley/pers/hd/o/O=Hara:Kieron.html, sowie an das lateinische Alphabet angelehnte Zeichen durch ihre benannte HTML-Entitäten, wie http://www.informatik.uni-trier.de/~ley/pers/hd/z/Zdr=aacute=hal:Zdenek.html. Da sollte man vorher genau überprüfen, welche Fälle vorkommen und ob sich das überhaupt automatisieren lässt.

Davon abgesehen, gehen solche Ersetzungen nicht mit Vorlagensyntax, sondern bedürften einer öffentlichen Lua-Methode, die Zeichenersetzungen durchführt, z.B. in Modul:Str eine Methode replace(Eingabestring, zu ersetzende(s) Zeichen, Ersetzungszeichen) bereitzustellen. --Mps、かみまみた^Disk. 14:28, 17. Mai 2013 (CEST)

Natürlich kann ich warten, ist ja weder eilig noch überhaupt wichtig. Aber eine replace-Methode für Strings klingt doch nützlich … was spricht dafür, was dagegen, und wo wird so etwas überhaupt diskutiert? Gruß, --Nirakka ^Disk. Bew. 23:25, 21. Mai 2013 (CEST)

Ich halte überhaupt nichts davon, in alter Vorlagensyntax mit lauter Puzzle-Teilen von String-Funktionen zu hantieren.

• Vielmehr ist, wenn die URL durchgehend oder mit seltenen Ausnahmen so gebildet werden können, die ganze Vorlage am Stück zu ersetzen: Hilfe:Lua/Modul für eine bestimmte Vorlage
• Zu der Ersetzerei siehe Hilfe:Lua/Zeichenketten #Pattern.

Das sind jetzt zwei deeplinks mit hartem Tobak. Von da aus kannst du luftschnappend an die Oberfläche gehen und mit den Grundlagen beginnen. Lua ist etwas gewöhnungsbedürftig, aber erlernbar: Modul:Hello.

Gute Nacht --PerfektesChaos 23:52, 21. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Konsole: Mischung benannter und unbenannter Argumente

Wie lässt sich so eine Mischung in der Fehlerbereinigungskonsole testen? In Modul:DemoArgs ergibt, was mir einfällt, Fehler,
mit z.B. =p.Obstkorb({args={[1]=Karli,Bananen=2,Kirschen=5}}) hat frame.args[1] den Wert nil --Thoken (Diskussion) 10:49, 24. Mai 2013 (CEST)

• Was das Modul:DemoArgs angeht, so müsstest du dessen Autor fragen.
• Soweit ersichtlich, ist das Modul:DemoArgs jedoch ausschließlich für den Aufruf aus einer Vorlage heraus geschrieben worden und unterhält keine Lua-Schnittstelle.
• Für den Aufruf aus der Konsole heraus ist jedoch zwingend eine Test-Schnittstelle erforderlich, da frame hier nicht bekannt ist und Modul:DemoArgs dieses zur Auswertung voraussetzt.
• Ein Beispiel zur Gestaltung eines kombinierten Moduls findest du unter Hilfe:Lua/Modul für eine bestimmte Vorlage #Muster.
  • Nach geeigneter Umsetzung in einer Form für mehrere Funktionen sollte in der Konsole funktionieren:

    =p.test( "Obstkorb", { "Karli", Bananen=2, Kirschen=5 } )

Hoffe geholfen zu haben --PerfektesChaos 11:20, 24. Mai 2013 (CEST)

Danke, half, die zulässige Schreibweise zu finden: Unbenannte (schlüsselllose) Argumente müssen Zahlen oder quotiert sein, runde Klammern sind außerdem überflüssig, z.B. (Konsole) =p.Obstkorb{args={"Karli",Bananen=2,Kirschen=5}} ist ok in Modul:DemoArgs.

Im Modul bekommt frame dabei schon einen Wert ab, die globale Variable frame, die frame:getParent() ermöglicht, wird anscheinend mit dem Argument des Aufrufs der Funktion p.Obstkorb aus der Konsole überschrieben, frame:getParent ist nil während dieser Funktionsausführung. --Thoken (Diskussion) 12:32, 24. Mai 2013 (CEST)

GULP.

frame ist nicht bekannt und wird auch nicht durch die Konsole simuliert.

• attempt to index global 'frame' (a nil value)

Das funktioniert hier nur deshalb, weil der einzige Zugriff auf frame das Auslesen der .args ist. Statt des erwarteten frame-Objekt übergibst du ein irgendwas. Weil dieses irgendwas-table eine Komponente .args hat, können diese verwendet werden.

Wäre auch noch auf eine Objekt-Funktion zugegriffen worden, hätte dieses irgendwas das nicht bieten können und wäre abgeschmiert. So auch frame:getParent().

Deshalb der Zugang über eine spezifische test() -Methode, wobei die Argumente vom frame-Objekt abgetrennt werden, und das frame-Objekt separat zugeliefert wird.

Ich selbst arbeite nur selten und nur für Trivial- und statische Syntax-Tests mit dem Konsolen-Dings.

Amüsier dich --PerfektesChaos 22:12, 24. Mai 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Modul für Vorlage:Maß und Vorlage:Mass

Aus gegebenen Gründen ein Hinweis: Ich arbeite gerade an einem Modul für diese Vorlagen. Momentan unter Benutzer:Antonsusi/Spielwiese/Modul:Measure zu finden. Bei dieser Gelegenheit möchte ich die Funktionalität etwas erweitern, indem Vorlage Maß als ersten Parameter auch einen Expr-Ausdruck verarbeiten kann und eine Messunsicherheit bei Anforderung auch in Klammern steht. Ein paar Testaufrufe haben funktioniert. Wer Lust hat, kann aber gerne selber mittesten... ÅñŧóñŜûŝî (Ð) 02:10, 13. Jun. 2013 (CEST)

• Ich weiß von niemand, der gerade an dieser Aufgabe arbeiten würde.
• Ich möchte gern, dass Standardaufgaben wie diese eine Lua-Schnittstelle erhalten, so dass das Modul auch unmittelbar durch andere Module benutzt werden kann.
• Zum Thema Runden und Erhalt der Nachkommastellen haben wir bereits das Modul FormatNum. Leider hat es im Moment noch keine Lua-Schnittstelle (es war das erste produktive Modul der deWP); diese kann aber leicht nachgerüstet werden.

Viel Erfolg --PerfektesChaos 11:39, 13. Jun. 2013 (CEST)

Im Moment läuft es "um die Ecke", also per Vorlagenexpandierung. Das Tema Schnittstelle muss ich mir erst nochmal genauer anschauen, denn das war - zumindest bis zu meinem letzten Besuch der Hilfeseiten - extrem schlecht erklärt. Besonders Beispiele würden da sehr helfen.

Das Modul findet sich jetzt auch unter Test2. ÅñŧóñŜûŝî (Ð) 12:00, 13. Jun. 2013 (CEST)

Beispiele kannst du haben: Hilfe:Lua/Modul im Wiki#Funktionen für Vorlagen und zusätzlich Lua-Zugriff und dieses angewendet in Wikipedia:Lua/Modul/URLutil/de#Lua oder Wikipedia:Lua/Modul/TemplatePar/de#Lua. --PerfektesChaos 13:37, 13. Jun. 2013 (CEST)

Auf der Hilfeseite fehlt ein Beispiel für das andere Modul, welches auf "DiesesBeispiel" zugreift. Das könnte man noch ergänzen. Das andere schaue ich mir mal an. ÅñŧóñŜûŝî (Ð) 13:41, 13. Jun. 2013 (CEST)

Es fehlt nicht; das Gegenstück steht bereits davor: Hilfe:Lua/Modul im Wiki #Einbindung. Eine praktische Anwendung unter Wikipedia:Lua/Modul/Vorlage:Phab. --PerfektesChaos 14:30, 13. Jun. 2013 (CEST)

Das habe ich inzwischen gesehen, aber die Zuordnung der Variablennamen war mir zunächst nicht klar. Inzwischen habe ich es herausgefunden. Ich würde das Beispiel gerne etwas konkreter gestalten, also mit tatsächlichen Zeilen statt Platzhaltern. Dazu erstelle ich sobald ich Zeit habe mal einen Entwurf. ÅñŧóñŜûŝî (Ð) 20:18, 13. Jun. 2013 (CEST)

Das Modul ist jetzt unter Modul:Measure zu finden (es dürfte für eine größere Zahl Vorlagen nutzbar sein).

und

{{#invoke:Maß|Mass}} (für Vorlage:Mass)

Wer will, kann jetzt beim Testen mitmachen. ÅñŧóñŜûŝî (Ð) 17:05, 14. Jun. 2013 (CEST)

• FormatNum wurde aktualisiert.
• Ich empfehle eine Testseite.
• @Antonsusi: Bitte die als Kurzreferenz gedachten Hilfeseiten nicht mit endlosen Programmbeispielen fluten. Ich hatte dir bereits einmal angeboten, solche ausgedehnten Darstellungen unter Hilfe:Lua/Tutorial zu schreiben. Im Einleitungsabschnitt von Hilfe:Lua/Programmierung ist bereits ein Listenpunkt für „Tutorial“ vorgesehen.

--PerfektesChaos 10:40, 17. Jun. 2013 (CEST)

Kann das Modul auch genutzt werden, um bei schweizbezogenen Artikel das Tausendertrennzeichen anders zu formatieren? Siehe dazu etwa Vorlage Diskussion:Infobox See#Tausendertrennzeichen. --Leyo 13:55, 17. Jun. 2013 (CEST)

Das Modul greift zurzeit auf Vorlage:FormatNum (später wohl auf das Modul:FormatNum) zu. Es gibt auch zwei Vorlagen für verschiedene Maßzahlen: Vorlage:Mass für CH+LI, Vorlage:Maß für den Rest. Es ist also Aufgabe der Infobox-Vorlage, bei Schweizbezogenen Seiten die andere Vorlage zu nehmen. ÅñŧóñŜûŝî (Ð) 14:09, 17. Jun. 2013 (CEST)

Parameter wie REGION-ISO oder HÖHE-BEZUG können als „Switch“ verwendet werden. --Leyo 14:12, 17. Jun. 2013 (CEST)

Das wäre eine Möglichkeit. ÅñŧóñŜûŝî (Ð) 20:39, 19. Jun. 2013 (CEST)

Nachdem ich das Modul schrittweise mit diversen Infoboxen und mit jeder Menge Testaufrufe getestet habe, ist es jetzt aktiv in Vorlage:Maß eingebaut. ÅñŧóñŜûŝî (Ð) 20:39, 19. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 22:07, 15. Aug. 2013 (CEST)

Parameterwerte trimmen

Aufgrund von dieser Anfrage habe ich ein Leerzeichen getilgt. Diese sollte das Modul allerdings selbst können (siehe auch den entsprechenden Hilfetext). Dies sollte für alle Module überprüft werden, darum auch hier die Mitteilung. (In Modul:Vorlage:FormatDate fehlt es, aber ich komm heut nicht mehr dazu. Wenn wer will, bitte sehr)

Gruß --Steef ³⁸⁹ 20:31, 17. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Namensraum abfragen

Hallo. Wie kann ich den Namensraum abfragen, in dem die einbindende Seite eines Skriptes liegt? Ich möchte in einem Modul die Kategorien nur erscheinen lassen, wenn es im Artikelnamensraum eingebunden wird. Sonst landen auch Projektseiten in Wartungskategorien, was ja eventuell nicht so sinnvoll ist. Oder? Gruß --Tlustulimu (Diskussion) 13:35, 4. Jul. 2013 (CEST)

Wenn du damit die alleroberste, dargestellte, in der URL erscheinende Seite meinst: Hilfe:Lua/Links #mw.title in Verbindung mit Hilfe:Lua/Umgebung #Namensraum-Element

Anwendungsbeispiel: eo:Modulo:Ŝablono:LuaModuleDoc Zeile 319 (Funktion navigation ab currentTitle [global]).

Mahlzeit --PerfektesChaos 14:03, 4. Jul. 2013 (CEST)

Danke für den Hinweis. Ich hatte mir das Modul sogar schon angeschaut, aber irgendwie nicht ganz kapiert, daß dort der gesuchte Code drinsteht. Jetzt klappt es mit der selektiven Kategorisierung in eo:Modulo:Coordinates2/provejo. Gruß --Tlustulimu (Diskussion) 14:24, 4. Jul. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Implementierung der Schulze-Methode für Abstimmungen und Wahlen

(Von Wikipedia Diskussion:Lua/Modul hierher verschoben. --TMg 12:17, 7. Jul. 2013 (CEST))

Nachdem ich auf Wikipedia Diskussion:Helferlein#Auswertung von Abstimmungen nach der Schulze-Methode auf bereits vorhandenen Lua-Code hingewiesen wurde (Danke an ThE cRaCkEr) frag ich mal hier:

• Ist jemandem eine bereits fertige Implementierung in der Wikipedia bekannt?
• Kann/mag die jemand auf der Basis des Codes unter http://www.public-software-group.org/preftools leisten? (Nicht schimpfen, ich weiß: Der Teil der Frage gehört in die Werkstatt.)

Meiner Meinung nach müsste für den konkreten Fall die Implementierung von schulze-simple sinnvoll sein. Anka ☺☻Wau! 00:04, 7. Jul. 2013 (CEST)

Es ist zwar richtig, dass es unter http://www.public-software-group.org/preftools etwas gibt, in dem ein kleines Programm steckt, das in Lua geschrieben wurde.

• Dieses ist allerdings dazu gedacht, auf einem Linux-Rechner interaktiv ausgeführt zu werden.
• Es erwartet formatierte Dateien auf dem Rechner.
• Sowas haben wir alles in einer Wiki-Seite nicht.
• Bei uns ist das Lua etwas wie eine Vorlage, und ich wüsste erstmal nicht, wie du die Eingabedaten dort hineinbringen möchtest. Ich will es nicht ausschließen, dass du irgendwas als Vorlagenparameter in eine umgeschriebene Variante dieses Lua-Programms hineinpraktiziert bekommst, und die zeilenweisen Inhalte der Dateien mit irgendwelchen Trennzeichen gliederst (es wird etwas mit Kommata und Semikolon zwischen Zahlen erwartet) und das Ergebnis dieser Vorlage ist irgendwas; aber viel Vertrauen hätte ich erstmal nicht dazu.
• Bei den von dir genannten Vergleichsfällen hatte wohl irgendjemand mit irgendwas auf seinem PC irgendwas ausgerechnet und danach das Endergebnis in die Wiki-Seite hineingeschrieben. Deine Anfrage hier impliziert, dass sich die Berechnung vollständig innerhalb der Wiki-Seite abspielen würde.

Schönen Sonntag --PerfektesChaos 12:12, 7. Jul. 2013 (CEST)

(Nach BK:) Ich bin ebenfalls verwundert, warum das ein Lua-Modul sein soll? Und wie das in einem Meinungsbild funktionieren soll? Falls ein so undurchsichtiger Auswertungsmodus gewünscht ist (was ich mir nicht vorstellen kann), dann kann es durchaus sinnvoll sein, den Abstimmenden eine Vorlage in die Hand zu geben, die sie ausfüllen sollen und die sofort prüft, ob die Eingabe valide ist. Aber das hat nichts mit Lua zu tun, dazu genügt eine schlichte Vorlage. Die Auswertung noch einmal neu zu implementieren, halte ich für unsinnig, wenn es bereits fertige Implementierungen gibt, die man dafür nutzen kann. --TMg 12:17, 7. Jul. 2013 (CEST)

Meine Idee war tatsächlich, die formatierten Dateien durch eine Wikipedia-Seite zu ersetzen. Die Strings aus der eigentlichen Abstimmung könnten aufbereitet und auf eine (oder zwei) Seite geschrieben werden, die dann als Input für die Auswertung dient. Damit ist der Vorgang transparent. Wenn dann auch noch das Auswertungsscript in der WP liegt, so dass jeder es für eine beliebige Seite aufrufen kann und damit sehen kann, was es tut, sollte die Akzeptanz höher sein als bei einem Offlineverfahren. Sicher sind aber auch Auswertungen denkbar, die an irgendjemanden delegiert werden, wobei das verwendete Programm (wie auch jetzt ja schon) offengelegt ist. Aber dann ist die Auswertung nur für technisch versierte Benutzer nachvollziehbar. Anka ☺☻Wau! 12:32, 7. Jul. 2013 (CEST)

Aha.

Prinzipiell ist es technisch möglich, auf einer Wiki-Seite ein Lua-Modul mit den Eingabedaten zu füttern und gleichzeitig das Ergebnis anzuzeigen.

Wenn du jemand findest, der das machen möchte – nur zu. VG --PerfektesChaos 12:41, 7. Jul. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Zahlenproblem

Hallo. Wie kann man mit Lua feststellen, ob eine gegebene Zahl eine natürliche Zahl ist oder ob sie eine reelle Zahl mit zwei Nachkommastellen ist? Ich habe zwar schon etwas gesucht, aber nichts passendes gefunden. :-( Gruß --Tlustulimu (Diskussion) 21:16, 16. Jul. 2013 (CEST)

(BK) Du meinst wohl den Unterschied zwischen "123" und "123.00"? Mathem. gar nicht. Du kannst nur einen noch als String (also vor einem tonumber()) vorhanden Parameter mit Stringfunktion vergleichen:

  local sx ="123.00" -- Fall A
  -- local sx ="123" -- Fall B
  local ix = tonumber(sx)
  if ( ix == math.floor(ix) then
    -- Ganze Zahl
    if string.len(sx) ~= string.len(tostring(ix)) then
      -- hier liegt "123,00" vor (Fall A)
    else
      -- hier liegt "123" vor (Fall B)
    end
  else
    -- keine ganze Zahl
  end

(Angabe ohne Gewähr) ÅñŧóñŜûŝî (Ð) 21:39, 16. Jul. 2013 (CEST)

Mit local numstr = tostring(<Zahl>) in eine Zeichenkette umwandeln und mit local startPos, _ = string.find(numstr, ".") schauen, ob startpos ungleich nil (d.h. ein Dezimalzeichen vorhanden und damit eine reelle Zahl) und dann mit string.len(numstr) - startPos die Anzahl der Nachkommastellen ermitteln. Das ist ungetestet, sollte aber so funktionieren. --Mps、かみまみた^Disk. 21:35, 16. Jul. 2013 (CEST) PS: Mit Antonsusis Code kann man nicht ermitteln, ob es genau zwei Nachkommastellen sind.

Richtig. Mir ging es nur um das Grundprinzip "string" versus "number". Der genaue Code hängt vom Einzelfall ab. ÅñŧóñŜûŝî (Ð) 21:56, 16. Jul. 2013 (CEST)

Alternativ: Mustererkennung (match), weil Vorlagenparameter bereits als Zeichenketten vorliegen. Nach Umwandlung wäre Kommanullnull identisch Ganzzahl.

Siehe Wikipedia:Lua/Modul/TemplatePar #Parameterformat für weitere Beispiele; auch mit Leerzeichen davor und dahinter möglich.

• "^[1-9][0-9]*$"
• "^[1-9][0-9]*%.[0-9][0-9]$"

LG --PerfektesChaos 21:42, 16. Jul. 2013 (CEST)

Danke für eure vielen Tipps. Ich benutze für ganze Zahlen folgenden Code:

pop = pop .. 1 -- adding of a number. if there is a decimal point with following zeros, 
-- it causes, that the script doesn't accept it
local poptest = tonumber(pop)
if poptest >= 0 and (poptest == math.floor (poptest))

und es funktioniert. Für reelle Zahlen mit zwei Nachkommastellen benutze ich dagegen:

elevationtest = tonumber (elevation)
length1 = string.len(elevation)
length2 = string.len(tostring(math.floor(elevationtest)))                 
if length1 - length2 == 3

Ich muß bei der Differenz 3 nehmen, weil der Punkt ja mitgezählt wird. Der vollständige Code steht im Modul eo:Modulo:Coordinates2/provejo, und zwar unterhalb der Kommentare.

-- pop has to be defined only, if type has one of the following values
-- elevation has to be defined only, if type has the following value

Gruß --Tlustulimu (Diskussion) 10:26, 18. Jul. 2013 (CEST)

Betreffend deiner auch gerade eben erfolgten Korrektur:

• Du machst es dir unnötig kompliziert und unübersichtlich und fehleranfällig (Kommanullnull identisch Ganzzahl).
• Das Nachstehende gibt sofort Auskunft für eine Zeichenkette s, die auch von Leerzeichen umgeben sein kann und nur vorzeichenlos auftritt:
  • if s:match( "^[%s]*[0-9]+[%s]*$" ) then
  • if s:match( "^[%s]*[0-9]+%.[0-9][0-9][%s]*$" ) then

LG --PerfektesChaos 10:48, 18. Jul. 2013 (CEST)

Danke für den Code, PerfektesChaos. Allerdings muß

• if s:match( "^[%s]*[0-9]+%.[0-9][0-9][%s]*$" ) then

noch geändert werden, da ja auch negative Höhen denkbar sind, z.B. bei Gebirgen im Meer oder Ozean. Wie muß der reguläre Ausdruck denn aussehen? Gruß --Tlustulimu (Diskussion) 11:17, 18. Jul. 2013 (CEST)

if s:match( "^[%s]*-?[0-9]+%.[0-9][0-9][%s]*$" ) then

Erkennt auch optionales ASCII-Minuszeichen.

Wenn es aus einem benannten Parameter stammt, kann es keine umgebenden Leerzeichen geben; dann können die [%s]* weg.

Vollprofis schreiben statt [0-9] auch %d, was aber intuitiv weniger verständlich ist.

Wenn man den Benutzern noch mehr Freiräume einräumen will, kann man alternativ auch Komma statt Punkt erlauben und Unicode-Minus zusätzlich zum ASCII-Minuszeichen; sollten diese vorkommen, wäre der string zu standardisieren.

LG --PerfektesChaos 11:34, 18. Jul. 2013 (CEST)

Danke für die kleine Ergänzung.

Die Anwendung mit Komma alternativ statt Punkt ist aber problematisch, da die Werte an den "Geohack" weitergereicht werden. Dieser "versteht" aber wohl nur Englisch und damit muß es denn der Punkt bleiben. Würde denn ein match mit Punkt so

• if elevation:match( "^[%s]*-?[0-9]+%,[0-9][0-9][%s]*$" )

aussehen? Gruß --Tlustulimu (Diskussion) 11:51, 18. Jul. 2013 (CEST)

Genau deswegen schrieb ich ja „sollten diese vorkommen, wäre der string zu standardisieren“.

local cMin = mw.ustring.char(8722)   -- Unicode-Minus
local scan = "^[%s]*([%-" .. cMin .. "]?)[0-9]+([,%.])[0-9][0-9][%s]*$"
local sign, sep = mw.ustring.match(s, scan)
if sep then
    if sep == "," then
        s = mw.ustring.gsub(s, ",", ".", 1)
    end
    if sign == cMin then
        s = mw.ustring.gsub(s, cMin, "-", 1)
    end
    -- s ist jetzt im maschinenlesbaren Format
    n = tonumber(s)
end

Ungetestet freihändig.

mw.ustring.char(8722) statt c&p, weil im monospace-Quellcode nicht vom ASCII-Minus unterscheidbar und leicht mal verlorengeht, wenn man auf der Festplatte speichert.

Sonnigen Tag --PerfektesChaos 12:32, 18. Jul. 2013 (CEST) erg 12:40, 18. Jul. 2013 (CEST)

Danke für den Code. Er ist mit einer Änderung jetzt in eo:Modulo:Coordinates2/provejo. Die Zeile

    n = tonumber(s)

habe ich denn durch

    type = type .. '(' .. s .. ')'

ersetzt. Die Tests auf eo:Uanto:Tlustulimu/lua#pop kaj elevation funktionieren richtig. Falls dir nicht noch eine weitere mögliche Variante von elevation einfällt, kannst du die Diskussion auf "erledigt" setzen. :-) Gruß --Tlustulimu (Diskussion) 13:35, 18. Jul. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:50, 15. Aug. 2013 (CEST)

Vorlage:Information & Lua

Von meiner Benutzerdiskussionsseite (Permalink) hierher verschoben. --Leyo 00:44, 12. Jul. 2013 (CEST)
Inzwischen habe ich mich weiter in Lua-Möglichkeiten und die für die deWP sinnvolle Modulstruktur eingearbeitet. Dabei habe ich folgende Schlussfolgerung gezogen:

• Zu der Vorlage:Information soll es ein eigenständiges Modul geben; es wird heißen: Modul:Vorlage:Information.
• Dieses Modul kennt auch den Quelltext der Dateibeschreibungsseite, in die es eingebunden ist. Damit sind folgende Zusatzaufgaben lösbar:
  • Ist die Vorlage mehrfach in dieselbe Dateibeschreibungsseite eingebunden? Analoger Fall auf BKS
  • Gibt es Interlanguage-Links? Dann sollte automatisch kategorisiert werden; oder das Vorhandensein solcher Kats gecheckt werden. Ich verstehe Interlanguage so, dass es sich um Medien handelt, die nicht auf Commons sollen oder dürfen, und deshalb von mehreren Wikipedien lokal gehalten werden.
  • Gibt es weitere Widersprüche, die sich aus den unterschiedlichen Vorlagen in einer Seite ergeben? Wenn VorlageX drinsteht, darf VorlageY nicht vorhanden sein.
• Wenn überhaupt, dann würde das Modul aber auch gleich die komplette Programmierung der Vorlage:Information übernehmen; von der bliebe nur ein Modul-Aufruf wie in Modul:Vorlage:Phab.

Sonnigen Sommer und immer mit der Ruhe --PerfektesChaos 12:51, 7. Jul. 2013 (CEST)

Wenn jede Vorlage jetzt in eine Modul-Seite umgewandelt wird, stellt sich mir die Frage, wo der Modul-Gedanke ist. Für mich ist ein Modul ein kleines Skript, welches mir eine Spezialaufgabe abnimmt, wie zum Beispiel das überprüfen der Parameter.

Das Zusammenbauen der Wiki-Tabelle sollte aus meiner Sicht aber weiterhin in der Vorlage bleiben, ist vermutlich einfacher und übersichtlicher als zwischen den Lua-Befehlen. Zusätzlich ist dann auch eine größere Gruppe an Benutzer in der Lage das zu verstehen/anzupassen/zu warten. Es gibt sicher einige Benutzer, die die jetzige Vorlagensyntax so langsam verstanden haben/damit umgehen können, aber jetzt nicht noch mehr, nämlich Lua, lernen wollen. Der Umherirrende 17:45, 9. Jul. 2013 (CEST)

Es ist überhaupt nicht die Rede davon, „jede Vorlage“ als Modul umzuwandeln.

Es geht um folgende Konstellationen:

• Promi-Vorlage mit Einbindungszahlen im sechsstelligen Bereich. Hier soll auch durch Kapselung eine Abhängigkeit von den Bibliotheksmodulen reduziert werden, da diese sonst in den Bereich von einer halben oder einer Million Einbindungen kommen würden. Hingegen ist ein unabhängiges und stabiles Modul besser zu handhaben, zumal sich bei diesen paar Monstern nicht alle naselang etwas ändert.
  • Zitation
  • Vorlage:Begriffsklärung
  • Defekte Weblinks
  • Normdaten
• Konstrukte, die mit Vorlagensyntax nicht oder nur mit endlosem und unübersichtlichem veraltetem Gefummel realisierbar sind:
  • Farbtabelle (dazu hatte es mal drei Untervorlagen mit 20 kB Vorlagensyntax gegeben; nur für eine von heutzutage zwei Tabellen – ich weiß nicht, wo das alles hingekommen ist, mal TMg fragen)
  • Phab
  • Vorlage:Begriffsklärung
  • LuaModuleDoc

Bei den letzteren kannst du mir mal vormachen, wie du das nur mit Vorlagensyntax hinbekommen willst.

Für kleine Vorlagen, die wie eine Navileiste nur gelegentlich eine einzelne Funktion benötigen, stehen die allgemeinen Bibliotheksmodule zur Verfügung. Von ein paar Tausend Einbindungen ist auch nicht die Rede; also etwa

• Vorlage:Benutzer
• Vorlage:Toter Link

Sobald hingegen komplexe Verschachtelungen mit mehreren Zeichenketten und numerischen Werten und Datum anstehen, Schleifen über Iteratoren oder eine unbegrenzte Anzahl von Parametern, wird ein Lua-Modul einfacher, sicherer oder überhaupt der einzige Weg. Sobald zwei oder drei #invoke in einem Pfad vorkämen, ist schon zur Performance-Steigerung über ein Modul nachzudenken.

Bei dem in diesem Thread diskutierten Fall ist davon die Rede, jede Dateibeschreibungsseite daraufhin zu untersuchen, ob etwa die Vorlage:Information mehrfach eingebunden sei oder ob es sonst irgendwelche Konflikte zwischen Syntaxelementen und/oder Vorlagen geben würde; oder ob eine lokale Datei mit Interlanguage eine Kategorisierung auslösen sollte. Wie machst du denn das mit Vorlagensyntax?

Von den Monstern mit Hunderttausenden an Einbindungen haben Programmier-Anfänger ohnehin die Pfoten zu lassen; um banale Allerwelts-Minivorlagen geht es ja gar nicht.

VG --PerfektesChaos 22:57, 9. Jul. 2013 (CEST)

Das wären ja jeweils Spezialaufgaben, die man gerne über Lua machen kann, aber wie gesagt, man muss nicht die Erzeugung der Tabelle auslagern, weil dies mit der Überprüfung von Parametern und doppelter Verwendung nichts zu tuen hat.

Erst per #invoke das Modul aufrufen und darin per .transclude einen vorgefertigen Kopf einbinden, klingt jetzt auch nicht performanter als den Kopf in der Vorlage zu lassen und dahinter das eine Vorlagen-Modul zur Überprüfung der Sachen aufzurufen oder halt jeweils das kleine Modul zur Überprüfung der Pflicht-/Optionalparameter, doppelte Verwendung etc. Ist halt Geschmackssache, ob man das über #invoke aus der Vorlage jeweils einzeln aufruft oder im Modul die Submodule aufruft. Code-Dopplung der Bibliotheksfunktionen wird auch keine Lösung sein und mehr Arbeit verursachen als millionenfach eingebundene Module. Der Umherirrende 16:50, 10. Jul. 2013 (CEST)

---

Das Hauptanliegen von Wikipedia:DÜP ist IMO Seiten mit ungültigen Parameternamen in eine Wartungskategorie einzusortieren. Zusätzliche Features wie das oben erwähnte Feststellen einer mehrfach eingebundenen Vorlage:Information in einer Seite fände ich auch sinnvoll und nützlich. Eure weitere Diskussion ist mir zu technisch, um da wirklich mitzureden… --Leyo 00:44, 12. Jul. 2013 (CEST) PS. Ggf. von Interesse: commons:Template talk:Information#Adding TemplateData information

Modul:TemplatePar passt hier nicht ganz. Die Vorlage generiert bereits selber einen Kategorieeintrag unterhalb von Kategorie:Wikipedia:Dateiüberprüfung/Informationsmängel wenn ein Pflichtparameter nicht gesetzt wird. Wenn man jetzt das Modul nutzt und eine Kategorie vorgibt, dann gibt es noch ein Eintrag, was es etwas unübersichtlich ist. Das hilft nicht. Der Umherirrende 14:48, 26. Jul. 2013 (CEST)

Modul:TemplatePar und seine Methodik passt hier sehr wohl. Es findet auch unbekannte Parameternamen, also solche mit Tippfehlern, falscher Groß- und Kleinschreibung, englischen oder französischen Parameternamen. Das mag bei über Hunderttausend Dateibeschreibungsseiten, die zwischen Wikis kopiert und abkopiert werden, durchaus vorkommen. Hier ist der gewünschte Parameterwert vom Benutzer eingefügt, bloß unter falschem Namen. Genau dies war der Anlass zur Entwicklung des Moduls, und die Vorlage:Information und eine Anfrage von Leyo dazu der konkrete Anlass für die Erforschung der Methodik. VG --PerfektesChaos 15:10, 26. Jul. 2013 (CEST)

Ja, das ist richtig, aber eine fehlende Beschreibung würde auch in einer solchen Kategorie landen und diese dann überfrachten. Eine Lösung wäre, alle Parameter als optional anzugeben, damit die unbekannten als Fehler angezeigt werden.

Gibt es eigentlich auch die Möglichkeit, auf das vorhanden sein von leeren Parameter zu prüfen? Weiß nicht, ob es hier sinnvoll ist, aber es gibt Vorlagen, wo auch leere Parameter im Quelltext angegeben sein soll, das könnte man auch prüfen. Der Umherirrende 15:23, 26. Jul. 2013 (CEST)

• Der Wunsch geht auf die Datei-Leute zurück; und wenn in einer ersten Aufräumphase der aufgestaute Schrott „in einer solchen Kategorie landen und diese dann überfrachten“ wird, dann ist das deren Problem. Nach einer Grundbereinigung gibt es dann halt zwei Fälle am Tag in der Wartungskat. Die anderen beiden 100.000er Promis PD und ND hatten mit dem toolserver über SK und APPER und Skripten von Schnark und mir ihre Einbindungen standardisiert.
• Von den 7 Parametern der Vorlage:Information sind vermutlich 3 oder 4 optional, und nur 4 oder 3 Pflichtparameter. Allerdings ist die Doku mangelhaft, die absoluten Pflichtparameter gehen nicht klar daraus hervor. Unter den optionalen können sich genügend viele unentdeckte Irrläufer verbergen.
• Lua kann anders als die Vorlagensyntax auch Parameter mit leerem Wert von nicht angegebenen Parametern unterscheiden. Bei Kopiervorlagen für optionale Parameter ist das meist egal, aber unerwartete unbenannte weisen auf eine Pipe zuviel hin und damit auf eine mögliche Falscheingabe.

Gute Nacht --PerfektesChaos 23:38, 26. Jul. 2013 (CEST)

Da habe ich mich wohl nicht ganz gut ausgedrückt. Der Parameter Beschreibung erhält bereits bei leerem Parameter eine Wartungskategorie Kategorie:Datei:Beschreibung fehlt, wenn man jetzt Beschreibung als Pflichtparameter an TemplatePar übergibt, dann gibt es zusätzlich noch die Wartungskategorie Kategorie:Wikipedia:Dateiüberprüfung/Informationsmängel, was bedeutet, das auf der Dateiseite zwei Kategorien für den gleichen Fehler stehen und auch das in der Kategorie Kategorie:Wikipedia:Dateiüberprüfung/Informationsmängel alle Seiten drin stehen, die auch bereits in einer Unterkategorie stehen. Ich habe daher für den Anfang die Prüfung so eingebaut, das alle Parameter optional sind, weil die nicht-optionalen Parameter bereits eine Wartungskategorie haben. So lassen sich die nicht bekannten Parameter finden. Der Umherirrende 00:24, 27. Jul. 2013 (CEST)

Schaut gut aus, danke! Die Kategorie:Wikipedia:Dateiüberprüfung/Informationsmängel füllt sich ziemlich schnell… Bisher habe ich nur eine Art Fehler gesehen: Parameter 1. Hier könnten wohl die überflüssigen Pipes automatisiert entfernt werden. --Leyo 00:32, 27. Jul. 2013 (CEST)

Ja, die JobQueue hat hier gut gearbeitet. Ich habe gestern bereits einige Seiten berarbeitet, wo der Parameter 1 gefüllt war. Die restlichen 309 Seiten haben alle leere Parameter zuviel. Stellt sich die Frage, ob ein Bot lohnt oder man das von Hand macht und vielleicht nach anderen Dingen Ausschau hält, die fehlerhaft sein könnten. Der Umherirrende 09:29, 27. Jul. 2013 (CEST)

Ich würde gerne unter commons:Template talk:Information etwas Analoges für die dortige Vorlage vorschlagen. Allerdings scheint das Modul:TemplatePar dort (noch) nicht zu existieren. Da ich dort tausende von Treffern (und eine entsprechend lange und aufwändige Korrekturphase) erwarte, würde ggf. eine feinere Kategorisierung nach Art des Fehlers (leere oder falsche Parameter) und ein Verstecken der Fehlermeldungen vor dem (nicht eingeloggten) Leser Sinn machen. --Leyo 23:57, 27. Jul. 2013 (CEST)

• Modul importieren; einschließlich der neuesten Version der nicht ohne Grund englischsprachigen Doku. Oder noch schlauer: Für die aktuelle Doku auf dewiki verlinken; spart regelmäßige Anpassungen.
• Normdaten verwenden die Klasse .metadata zum Verstecken von Fehlermeldungen vor unbedarften Lesern und IP, die sie nicht beheben könnten.

LG --PerfektesChaos 11:43, 28. Jul. 2013 (CEST)

Ich hab's importiert, erhielt aber eine Fehlermeldung: Import fehlgeschlagen: Can't save non-default content model with $wgContentHandlerUseDB disabled: model is wikitext , default for Module:Modul:TemplatePar is Scribunto

Das Modul ist nun unter commons:Module:TemplatePar, aber ich weiss nicht, ob es aufgrund des obigen Fehlers funktioniert oder nicht. --Leyo 00:00, 3. Aug. 2013 (CEST)

Das passt schon. Vermutlich exportiert das XML noch nicht das ContentModel (wenn ungleich wikitext), und beim Importieren in einen Namensraum mit ContentModel ungleich wikitext klemmt es dann. Auf die Funktionalität der Seite hinterher hat das keinen Einfluss. Gute Nacht --PerfektesChaos 00:48, 3. Aug. 2013 (CEST)

Danke für die Antwort! Ich habe unter commons:Template talk:Information#Maintenance category for pages using nonexistent parameters einen entsprechenden Vorschlag gemacht. --Leyo 23:53, 4. Aug. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 12:21, 14. Sep. 2013 (CEST)

Modul:TemplatePar: Parameterstatistik

Ist es möglich, die undefinierten Parameter irgendwie abzufragen? Beispielsweise für commons:Category:Pages using Information template with incorrect parameter wäre eine Übersicht über die falsch verwendeten Parameter sehr nützlich. Häufige Fälle könnten dann halbautomatisch korrigiert werden. --Leyo 00:42, 9. Okt. 2013 (CEST)

Am einfachsten wäre es wohl, Parameter 1 gesondert abzufragen um „reine“ Syntaxfehler zu finden. Mittels {{#if: {{{1|}}} kriegt man aber wohl Fälle wie eine doppelte Pipe nicht. --Leyo 15:06, 10. Okt. 2013 (CEST)

Wenn du vorrangig diejenigen von den 3000 haben willst, die nicht bloß die dämlichen || auswerfen, dann müsstest du deine Million Einbindungen über eine Untervorlagen-Konstruktion ansprechen:

{{Information/maintenance|1={{{1|}}}|2={{#invoke:TemplatePar| ...

Und in der Unterseite kannst du dann gleichzeitig

1. Die Meldung anzeigen wie bisher mittels offenem
   • {{{2|}}}
2. Deine Statistik machen per Wartungskat
   • {{#if:{{{2|}}}|{{#if:{{{1|}}}|empty 1|other than 1}}}}

Damit sparst du dem Server den zweiten teuren Aufruf (und kannst in das {{#if:{{{2|}}} sogar die Anzeige der Fehlermeldung integrieren:

{{#if:{{{2|}}}|{{{2}}}[[Category:{{#if:{{{1|}}}|empty 1|other than 1}}]]}}

Andere Lösung, wenig elegant:

• Zweiter Aufruf, in dem 1 als zulässiger optionaler Parameter gilt.
• Wobei aber 1= nicht nur durch eine verdoppelte Pipe entstehen kann, sondern ein inhaltliches Problem bedeuten mag, wenn es nicht nur ein leeres |1=| ist; dieser Fall wird oben durch empty1 ignoriert. Ohne Unterseite müsste das dann durch eine konventionelle Abfrage detektiert werden.

LG --PerfektesChaos 21:56, 10. Okt. 2013 (CEST)

Vielen Dank für deine ausführliche Antwort!

Ich habe mich wohl etwas unklar ausgedrückt: Die Statistik aller undefinierter Parameter kann nicht über Kategorien gemacht werden, sondern via API. Gibt es da einen Anknüpfungspunkt?

Bezüglich Unterseite gebe ich dir Recht. Eine solche sollte vermieden werden. Daher: Lösung 2.

Die Idee dahinter, die Parameter-1-Fälle abzutrennen, war, die Hauptkategorie deutlich schrumpfen zu lassen, so dass notfalls auf eine Statistik verzichtet werden kann. Fälle mit Doppelpipe sollen auch in die entsprechende Unterkategorie kommen. Vage erinnere ich mich, dass man einen Vergleich machen muss, um auch leere Parameter zu erwischen. Ich glaube, der Code stammte von Umherirrender. --Leyo 00:52, 11. Okt. 2013 (CEST)

Was willst du denn mit einer Statistik erreichen? Wem nutzt das?

• Ziel ist es, die Seiten syntaktisch sauber zu halten.
• Dazu wäre herauszufinden, auf welchen Seiten genau es schwerwiegende Fälle gibt, die über die Doppelpipe hinausgehen und menschlich analysiert und berichtigt werden müssen.
• Der Rest mit Doppelpipe sollte ohne besondere Eile aus syntaxhygienischen Gründen mal von einem Bot grundbereinigt werden (Templatetiger usw.). 3000 Doppelpipes in zehn Jahren sind nicht so dramatisch.
• Zukünftig laufen dann nur noch Einzelfälle auf. Was neu hinzukommt, kann sofort manuell nachbearbeitet werden; falls es eine systematische Ursache hat wie ein unkorrektes Formatierungsmuster oder ein unsauberes Skript, kann die Quelle aufgespürt und beseitigt werden.
• Man kann auch keck einen Bot über alle 3000 beanstandeten Seiten schicken und auf Verdacht alle Doppelpipes beseitigen. Das sollte möglichst keine andere Vorlage in ihrer Wirkung beeinträchtigen, und wenn, dann ist die nicht auf einer der 3000 Seiten eingebunden; und der RegExp kann konservativ so geschrieben werden, dass er Doppelpipes nur reduziert, wenn keine geschweifte Klammer steht zwischen {{Information und der Doppelpipe. Wenn dann von den 3000 nur noch 100 übrig sind, haben sich die Trivialfälle erledigt.

In der Statistik hat erst kurzfristig und dann auch langfristig eine Null zu stehen. Die Zahlen helfen niemandem.

Im Übrigen hatte ich mich oben für die Untervorlagen-Konstruktion ausgesprochen, weil sie zwei getrennte Wartungskat mit einem Lua-Aufruf auswirft.

VG --PerfektesChaos 09:41, 11. Okt. 2013 (CEST)

Zur ersten Frage: Es sind durch mich (v.a. mittels VisualFileChange) und zwei weitere Benutzer >> 10000 Fälle abgearbeitet worden. Die verbleibenden Fälle sind jedoch meist weniger trivial (halb)automatisch zu fixen. Daher wäre eine Statistik zu Fehler auslösenden Parametern nützlich, damit die Korrektur bei einem mehrfach auftretenden Fehler (halb) automatisch erfolgen könnte. Das Ziel ist es, die Wartungskategorie zu leeren, um künftig Neufälle ohne grosse Verzögerung korrigieren zu können.

Die von mir gewünschte Statistik kann demnach auch statisch, also eine Einmalaktion, sein. --Leyo 11:54, 11. Okt. 2013 (CEST)

Aber dafür brauchst du doch keine Statistik. Du hattest doch Seiten editiert, und schon einen Eindruck. Von den 3000 kannst du ja ein, zwei Dutzend zufällig ausgewählte aufmachen und ggf. gleich fixen. Und wenn auf das Dutzend zehn Doppelpipes kommen, dann lohnt sich ein Bot-Lauf für dieses Spezialproblem; und wenn der Bot auf einer Seite nichts zu tun bekam, dann nimmt er halt die nächste. Wenn auf ein Dutzend Seiten zehn verschiedene Fehlersituatonen kommen, dann ist es halt nicht automatisierbar, egal ob mit oder ohne Statistik.

VG --PerfektesChaos 13:42, 11. Okt. 2013 (CEST)

Es geht nicht speziell um Doppelpipes, sondern um häufig (gleich) falsch geschriebene oder sonst falsch verwendete Parameter. Von daher möchte ich nicht auf eine Statistik verzichten. Aber ich frage wohl besser unter commons:COM:BWR. --Leyo 14:11, 11. Okt. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 14:11, 11. Okt. 2013 (CEST)

Modul:Vorlage:Flagicon

Kopiert nach Wikipedia Diskussion:Lua/Werkstatt/Flagicons. --PerfektesChaos 20:31, 16. Okt. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:31, 16. Okt. 2013 (CEST)

Adressen-SortKey-Generierung

Kopiert von Vorlagenwerkstatt. --PerfektesChaos 21:27, 23. Mär. 2013 (CET)

Hallo Vorlagenwerkstatt,

ich habe in der letzten Stunde ein kleines Lua-Modul zusammengebaut, das automatisch SortKeys generiert: Modul:AdressenSort.

Es funktioniert soweit und zickt auch bei großen Tabellen nicht (wird im Moment nur für hessische Denkmallisten eingesetzt), aber es hat sicherlich noch einiges an Potenzial in Sachen Ausführungsgeschwindigkeit. Vielleicht kann man einige find-Läufe einsparen? Oder gibt es eine andere, elegantere Vorgehensweise?

Es wäre zudem sinnvoll, wenn Sonderzeichen ersetzt werden könnten (also Umlaute und ß sowie alle Satz- und Trennzeichen), aber bis auf die Möglichkeit, für jedes Sonderzeichen einen replace-Lauf zu starten, konnte ich ind er Dokumentation keine geeignete Lösung finden.

Falls jemand drüberschauen könnte, wäre ich sehr dankbar!--Cirdan ± 20:48, 23. Mär. 2013 (CET)

Zur Ersetzung von Sonderzeichen wäre der effizienteste mir bislang untergekommene Algorithmus derjenige als .sortChar() in meiner stringLib geschriebene.

VG --PerfektesChaos 21:50, 23. Mär. 2013 (CET)

Ganz doofe Frage: Wie greife ich auf die StringLib zu?--Cirdan ± 12:21, 24. Mär. 2013 (CET)

• Ganz schlichte Antwort: Überhaupt nicht. Sie ist in JavaScript geschrieben und wäre hier nur auszubeuten.
• Du musst dir um Sortierungs-Optimierung keine Sorgen machen. Irgendwann wird es ein Universal-Modul:Sort geben, das dies als Bibliotheksfunktion bereitstellt und dir über require("Modul:Sort") verfügbar sein wird.
• Unter JS wäre der obige Hinweis mit die effizienteste Form, weil der Compiler den Zugriff regelt und es klar und übersichtlich hingeschrieben werden kann.
  • Weil es bei Lua aber kein switch gibt, sondern nur if, elseif, elseif, else, sollte man eine Datentabelle anlegen und diese algorithmisch flöhen.
  • Weil es bei Lua nur ein table gibt, das primär kein sequenzielles Array ist, wäre die hier effizienteste Lösung eine Tabelle, die jedem buchstabenartigen Zeichencode >=160 den ASCII-Wert zuweist; vermutlich effizienter erstmal numerisch und ein Treffer (non-nil) hinterher in Zeichenkette per mw.ustring.char(k) / geht sogar mit string.char(k).
  • Wenn man die von mir oben verlinkte stringLib::sortChar() mit brutaler Gewalt einmal von 160 bis 9000 durchlaufen lässt, kann man JavaScript dazu bringen, den Lua-Quellcode initial zu generieren.
  • Es würde sich anbieten, diese table mit mw.loadData("Modul:Sort/Data") zu externalisieren.
• Man beachte, dass die Sortierung einer Tabelle erst in der dargestellten HTML-Seite durch JavaScript erfolgt. Alle Betrachtungen hinsichtlich der PHP-seitigen Sortierung von Seitennamen auf dem Server greifen hier nicht.

Insgesamt würde ich empfehlen, es hier ein paar Wochen gemütlich angehen zu lassen, bis sich die Basis-Strukturen aufgebaut haben.

Schönen Sonntag --PerfektesChaos 13:04, 24. Mär. 2013 (CET)

OK, dann lasse ich das einfach erstmal. Die Vorlage erfüllt ja weitestgehend ihren Zweck. Aber warum wurde eigentlich Lua ausgewählt? Die Programmierung ist im Vergleich zu anderen Sprachen ein echter Krampf und sehr umständlich.--Cirdan ± 13:08, 24. Mär. 2013 (CET)

• Man suchte wohl konkret schon seit 2009, und das war das Optimum und wurde 2011 ausgewählt.
• Die Sprache mag gewöhnungsbedürftig und in ihren syntaktischen Möglichkeiten begrenzt sein. Gegenüber Vorlagensyntax jedoch ein deutlicher Fortschritt.
• Maßgeblich für die Entscheidung ist, wie das effizient auf unseren Server laufen mag und sich in unsere sonstigen Strukturen einfügt. Ohnehin kommt nur OpenSource in Frage, damit das Aussehen der Projektseiten nicht mittelbar von fremden Rechten abhängen kann. Vermutlich war Lua klein und schnell und robust.

Deine Hausnummerei könnte eine passende Funktion in einem Modul:Sort werden und anderen Vorlagen ebenfalls zur Verfügung stehen. Bis dann --PerfektesChaos 13:24, 24. Mär. 2013 (CET)

Durch Wikipedia:Lua/Modul/Sort mittlerweile vefügbar. Hier erledigt. --PerfektesChaos 20:32, 26. Okt. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 20:32, 26. Okt. 2013 (CEST)

Parameter muss eine natürliche Zahl sein

Ich möchte Modul:TemplatePar in Vorlage:HLS einbauen. Dabei soll zusätzlich geprüft werden, dass Parameter 1 eine natürliche Zahl ist. In der Tabelle habe ich diesen Fall nicht gefunden. --Leyo 19:39, 5. Sep. 2013 (CEST)

• Der Vorlagendoku nach kannst du nur 1 meinen.
• Das scheint ein Pflichtparameter zu sein. Auch wenn es nicht klar dokumentiert ist, ergäbe dies sonst keinen Sinn.
• Dafür sieht die Tabelle N>0 vor; käme noch drauf an, ob führende Nullen möglich oder ausgeschlossen sein sollen.

VG --PerfektesChaos 20:58, 5. Sep. 2013 (CEST)

Als Pflichtparameter habe ich Parameter 1 gesetzt. Wie die Prüfung auf eine natürliche Zahl (es scheinen keine führenden Nullen vorzukommen) habe ich noch nicht verstanden.

Dafür ist mir aufgefallen, dass der Vorlagenname mit [[]] umschlossen werden kann, was die Wartung für Dritte erleichtern dürfte. --Leyo 21:51, 5. Sep. 2013 (CEST)

1. Die Prüfung ergibt sich aus folgendem Code:

   {{#invoke:TemplatePar|valid|1|N>0}}

   • Das Ergebnis ist zunächst mal eine rote Fehlermeldung, oder nix.
   • Kann auch ergänzt werden durch cat= und löst im Fehlerfall die Wartungskat aus; diese hat nichts mit der Sichtbarkeit zu tun.
2. editoronly gefällt mir nicht; siehe MediaWiki Diskussion:Common.css‎ #‎Parameterfehlermeldungen per Default ausblenden
3. Das display:none sollte mit Produktionsreife zentral auf MediaWiki:Common.css‎ passieren, während genau dieses danach durch die Gruppenzugehörigkeit wieder aufgehoben wird.
   • Somit stünde dann nur noch in der Vorlage:

     <span class="wp_editoronly">{{#invoke:TemplatePar|

4. Nicht verstanden habe ich, was gemeint ist mit: Dafür ist mir aufgefallen, dass der Vorlagenname mit [[]] umschlossen werden kann, was die Wartung für Dritte erleichtern dürfte.
   • Die Doku schreibt zum Parameter template: „Ein Wikilink ist darin ebenfalls möglich; etwa auf eine bestimmte Doku-, Hilfe- oder Projektseite.“
5. „HLS“ gefällt mir auch nicht so ganz, selbst bei 10200 Einbindungen; Vorlage:HistLexBay und Vorlage:HistOrtsLexÖ sind da sprechendere Namen. Drei oder gar nur zwei Buchstaben für eng umgrenzte Spezialgebiete sind schwer verständlich und sollten eher Flagicons sein. ADB und NDB werden wenigstens projektweit benutzt.

Schönen Abend noch --PerfektesChaos 23:03, 5. Sep. 2013 (CEST)

Lässt sich alles in einer Einbindung machen – etwa so:

{{#invoke:TemplatePar|valid|1|N>0
|check
|all= 1=
|opt= 2= Autor=
|cat= Wikipedia:Vorlagen-Parameterfehler
|template= [[Vorlage:HLS]]
}}

oder muss dein obiger Code eigenständig eingebunden werden?

Bezüglich display:none sollte die Diskussion wohl am besten unter MediaWiki Diskussion:Common.css‎ stattfinden. --Leyo 00:03, 6. Sep. 2013 (CEST)

Nein; es sind zwei grundverschedene Funktionen; check und valid.

• Von check kann es nur einen für die ganze Vorlage geben; odersollte nur einen geben.
• Die valid kann es beliebig oft geben; für jeden Parameter einen mit einer spezifischen Regel und ggf. auch eine spezifische Wartungskat.

Wenn du übrigens 1 auf nicht-leere Zahl abfragst, solltest du es in check von |all= nach |opt= verschieben; sonst gibt es beim Fehlen des Parameters zwei Fehlermeldungen: Eine, dass es keine gültige Zahl ist, und eine, dass der Parameter fehlt.

Gute Nacht --PerfektesChaos 00:17, 6. Sep. 2013 (CEST)

Hm, mit {{#invoke:TemplatePar|valid|1|N>0}} von oben kriege ich in der Vorschau, beispielsweise bei Jean-Marie Ellenberger, die Fehlermeldung „#invoke:TemplatePar Parameter nicht angegeben“. Das sollte wohl nicht so (kryptisch) sein, oder? --Leyo 00:55, 6. Sep. 2013 (CEST)

Irgendwas spinnt da bei unbenannten Parametern.

• Unbenannte werden mit numerischem Zugriff 1 verwaltet, was sich unterscheidet vom Zugriff über die Zeichenkette "1" oder "Autor" – taucht leider bisher nicht in den Testfällen auf.
• Mit benannten geht es.

Muss ich am nahen Wochenende mal auseinanderklamüsern und eine weitere Testvorlage für unbenannten Parameter erschaffen.

Bis dann --PerfektesChaos 10:25, 6. Sep. 2013 (CEST)

Es ist so wie vorstehend vermutet.

Fix ist auf beta-wiki live.

Bevor ich das hier aufspiele, muss ich aber noch die Testseite ergänzen, und mir die Änderungen der letzten zwei Monate durchgucken; und vorsorglich über zusätzliche Pattern sinnieren.

Bei 192011 Einbindungen ist mir der Flurschaden zu heikel.

Eher Sonntag.

Wenn fertig, wäre es Zeit für einen sysop-Vollschutz.

Schönes Wochenende --PerfektesChaos 23:11, 6. Sep. 2013 (CEST)

Danke. Der dieser hohen Zahl an Einbindungen lohnt sich ein sorgfältiges Testen. --Leyo 00:24, 7. Sep. 2013 (CEST)

Update ist seit 24 Stunden scharf; ohne Fehlerkat oder aufgelaufene Beschwerden.

• Vollschutz wäre dann fällig; die Programmierung ist ja relativ robust, wie die vergangenen zwei Monate bis vorgestern zeigten.
• Das Lexikon sollte einen ähnlichen Hinweis {{Lua-Vorlage}} bekommen wie bei Vorlage:Phab.
• Mit min= und max= kannst du den Gültigkeitsbereich weiter einschränken, etwa auf 5- bis 8-stellige Zahlen.

VG --PerfektesChaos 23:54, 8. Sep. 2013 (CEST)

Vielen Dank! Vollschutz ist aktiv.

Betreffend Hinweis: Kommt dieser analog zu Vorlage:Phab/Meta auf Vorlage:HLS/Meta?

Die min. und max. Stellen ist mir nicht bekannt. Von daher lasse ich es lieber. --Leyo 00:07, 9. Sep. 2013 (CEST)

• Das

{{Lua-Vorlage|TemplatePar}}

kann auch ganz am Schluss von /Doku in <includeonly> eingeschlossen werden. Es sollte möglichst weit hinten stehen, weil für den Anwender der Vorlage völlig unwichtig: Hilfe:Vorlagendokumentation #Lua.

• Gemäß Hilfe:Vorlagendokumentation #Meta-Daten kann das /Meta auch allmählich aufgelöst werden, wenn du sowieso schon dran bist und selbst löschen kannst. Es ist nicht mehr erforderlich und verkompliziert die Angelegenheiten nur noch unnötig.

Grüsse --PerfektesChaos 10:07, 9. Sep. 2013 (CEST)

Ich hab's in der Vorlage und der Doku eingebaut. Kategorie:Wikipedia:Vorlagen-Parameterfehler ist nun wieder gut gefüllt… --Leyo 15:40, 9. Sep. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:22, 30. Jan. 2014 (CET)

Defekte Vorlageneinbindungen finden

Wäre es mit Lua möglich, inkorrekte Vorlageneinbindungen festzustellen? Wohl etliche Informationsvorlagen auf Commons sind aufgrund von Syntaxfehlern nicht als Vorlage eingebunden. Stattdessen ist {{Information usw. sichtbar (Beispiel). --Leyo 04:55, 18. Sep. 2013 (CEST)

• Kurz gesagt: nein.
  • Es muss auf einer Seite zumindest eine funktionierende Vorlageneinbindung vorhanden sein, die dann mit Lua den Quelltext der Seite untersuchen kann.
• Es muss turnusmäßig ein Bot über alle Dateibeschreibungsseiten laufen, der für alle in der letzten Zeit veränderten Dateibeschreibungsseiten prüft, ob mindestens eine Informationsvorlage syntaktisch korrekt eingebunden wurde.
  • Weil es für einen Bot eine komplexe Syntaxanalyse mit vielen Untervorlagen darstellen würde, den Wikitext zu lesen, würde ein Bot schlicht die Liste der von dieser Seite eingebundenen Vorlagen angucken; da muss sie draufstehen, wenn sie funktioniert.
  • Das kann auch jedes Benutzerskript per API.
  • Diese Methode findet sowohl die Direkteinbindung wie auch die vermutlich unerwünschte Einbindung über Untervorlage, ohne dies unterscheiden zu können.
  • Lua kann hingegen eine Dateibeschreibungsseite untersuchen, ob die Informationsvorlageneinbindung in einem erwarteten Format und nur ein einziges Mal vorkommt, und für die seltenen Ausnahmefälle eine Wartungskat auslösen.
• Für ein lokales Wiki sähe der Bot-Lauf übrigens komplizierter aus:
  1. Für alle Dateibeschreibungsseiten: Prüfe, ob eine von
     1. {{Information}}
     2. Vorlage:Verwaiste Dateibeschreibungsdiskussionsseite
  2. Für alle Dateibeschreibungsdiskussionsseiten: Prüfe, ob eins von
     1. Dateibeschreibungsseite existiert
     2. Vorlage:Verwaiste Dateibeschreibungsdiskussionsseite eingebunden

Schönen Tag --PerfektesChaos 09:53, 18. Sep. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:23, 30. Jan. 2014 (CET)

Looking for Lua mentors and tasks for Google Code-in

(Sorry for posting in English, if possible please reply at mw:Talk:Google Code-in) Hi, I'm one of the Wikimedia org admins at mw:Google Code-in. We are looking for Lua related tasks that can be completed by students e.g. rewrite a wikitext template in Lua or fix/extend current templates. We also need mentors for these tasks. You can start simple with one mentor proposing one task, or you can use this program to organize a taskforce of mentors with the objective of getting dozens of templates rewritten/fixed. You can check the current Wikimedia tasks here. The program started today, but there is still time to jump in. Give Google Code-in students a chance!--Qgil (Diskussion) 02:18, 19. Nov. 2013 (CET)

English is fine here.

We will keep your ad until end of year.

BTW, interesting to learn about a MediaWiki activity at Google Code-in.

Greetings --PerfektesChaos 23:29, 19. Nov. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --PerfektesChaos 20:24, 30. Jan. 2014 (CET)

Modul:InfoboxImage

Hallo. Besteht hier Interesse an einer Portierung des Moduls eo:Modulo:InfoboxImage. Ich habe sie aus der englischen Version en:Module:InfoboxImage abgeleitet. Der einzige Unterschied ist, daß die Esperantoversion übersetzte Namensräume für Bilder unterstützt und nicht nur die englischen. Dort also Dosiero: und in englisch eben nur File: und Image:. Oder sollten wir vielleicht noch ein bißchen die Weiterentwicklung des englischen Moduls abwarten?

Das Modul soll ja die Fehlertoleranz bei Infoboxen bei der Einbindung von Bildern erhöhen. Gruß --Tlustulimu (Diskussion) 21:32, 27. Mär. 2013 (CET)

Kara amiko!

• Zur Import-Frage: Danke; aber ich würde damit gern abwarten, bis das in einer Vorlage hier tatsächlich produktiv benötigt wird. Ohne dir zu nahe treten zu wollen, würde ich mich dann lieber an das en-Original in der letztmöglichen Fassung halten wollen.
  • Auf Wikipedia:Lua/Werkstatt/Archiv/enwiki habe ich einige Kandidaten gesammelt.
• Zur Sprachanpassung:
  • Die Herrschaften auf enWP schreiben bereits in der einzigen Weltsprache und haben es in der Regel nicht nötig, in ihrem Zeugs irgendwelche sonstigen Spezialitäten vorzusehen.
  • Wenn man eine geschlossene Software-Einheit wie diese Module auf Anpassungen vorbereitet (die „Internationalisierung“), dann geht man wie folgt vor:
    • Alle konfigurationsspezifischen Angaben werden am Anfang in einem geschlossenen Block gesammelt. Das betrifft Meldungstexte, Schlüsselnummern, URL, Dateinamen usw.
    • Im Verlauf des Programms wird ausschließlich auf diesen Block zugegriffen und nichts direkt angefasst („hard-coded“).
    • Wer anpasst („lokalisiert“), ändert dann nur übersichtlich und nachvollziehbar in diesem Block und muss nicht tief in den Innereien herumwurschteln und Fehler verursachen, oder irgendwas übersehen.
    • Selbst-anpassende vielsprachige Module können eine Fallunterscheidung vornehmen mittels: mw.language.getContentLanguage()
    • Im konkreten Fall:

local l10n = {}
   l10n.nsFiles  = "|file|image|datei|bild|dosiero|fichier|"  -- ASCII
   l10n.patSpace = "^(%a+:)"  -- ASCII, single word
   l10n.maintCat = "Kategorio:Paĝoj uzantaj informkestojn kun etaj bildoj"
-- l10n.noFile   = "File not found"
   l10n.noFile   = "Datei nicht gefunden"

und später müsste es (ungetestet freihändig) etwa so gehen:

function stripNamespaceFilePrefix( access )
   -- access -- file name
   -- Returns file name without any leading namespace prefix
   local strip = access
   local space = mw.ustring.match( access, l10n.patSpace )
   if space then
      if mw.ustring.find( "|" .. mw.ustring.lower( space ) .. "|", l10n.nsFiles ) then
         strip = mw.ustring.sub( access, mw.ustring.len( space ) )
      end
   end
   return strip
end   -- stripNamespaceprefix()

Frohe Ostern --PerfektesChaos 10:56, 28. Mär. 2013 (CET)

Hallo, PerfektesChaos. Das Modul in der englischen Wikipedia ist inzwischen so angepaßt worden, daß es selbst die Aliase für den Dateinamensraum ermittelt. Es wäre daher wohl keine Änderung für die deutsche Wikipedia mehr nötig. Ich habe inzwischen die betreffenden Änderung in die Esperantoversion übernommen und bisher keine Nebenwirkungen festgestellt. Gruß --Tlustulimu (Diskussion) 11:25, 30. Jan. 2014 (CET)

Danke. Kann das jetzt erstmal archiviert werden? Ich habe nicht den Eindruck, dass hier in der Werkstatt noch irgendwas damit passiert. LG --PerfektesChaos 20:19, 30. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:32, 8. Feb. 2014 (CET)

Modul für Datum und Zeit

Ich schlage vor, ein umfassendes Modul für Datums- und Zeitfunktionen zu erstellen. Ein paar Vorüberlegungen habe ich mir bereits gemacht, ohne allerdings tief einzusteigen. Sollte jemand bereits an sowas arbeiten, dann wäre es sinnvoll, das hier baldmöglichst mitzuteilen, denn nich habe keine Lust auf unnötige Doppelarbeit. Als Modulname schlage ich "DateTime" vor. Gruß von ÅñŧóñŜûŝî (Ð) 14:31, 12. Jun. 2013 (CEST)

Notwendig ist dies allemal; siehe Wikipedia:Lua/Modul #Basis-Datentypen (Zeichenkette, Zahl, Zeit)

Weiter oben ist bereits eine Baustelle als redlink vermerkt: /Datum und Uhrzeit.

• Den Text habe ich halbfertig auf der Festplatte in Warteschleife; beim nächsten Regenguss kann ich ihn zu Ende bauen.
• Vorab soviel: Allgemeine Bibliothek mit Basisfunktionen; alle sowohl von Vorlage=#invoke wie auch von anderem Lua-Modul aus nutzbar; alle zweifelsfreien Datumsformate für den deutsch- und englischsprachigen Raum bei der Eingabe zu unterstützen: 15. Februar 2013; 15.2.2013; 15.02.13; 14.8.98; 2013-06-12; 3. Jänner 2012; 5 Mar 2011; December 9, 2010; 1. Apr. 2012. Ausgabe in einigen wesentlichen deutschsprachigen Standardformen + ISO. Mit Uhrzeit ähnlich, aber weniger Varianten möglich. Fehlerbehandlung für Wartungskats.
• Auf der Baustelle wäre über die Liste der Funktionen zu diskutieren.

Geschrieben habe ich dazu bislang nicht eine Zeile in Lua.

Bis demnächst --PerfektesChaos 15:28, 12. Jun. 2013 (CEST)

• Ich würde da noch ein paar Features, welche hier in WP dauerhaft genutzt werden, ergänzen. Insbesondere ein paar Funktionen für das in der Astronomie genutzte Julianische Datum.
• Wichtig ist auch die Festlegung, wie fehlertolerant wir das Modul gestalten. Je penibler wir Fehlermeldungen platzieren, umso schlechter kann man später Erweiterungen vornehmen, denn viele Aufrufe nehmen keinen eigenen Paratest vor und "verlassen" sich später (mittels #iferror) auf die Fehlermeldung.
• Bei englischen Eingabeformaten habe ich bedenken. Es ist nicht unterscheidbar, ob z.B. das Datum des Attentats auf das World Trade Center als "11.9.2001" (dt.) oder "9.11.2001" (en) übergeben wurde. Außerdem fördert das die blinde Abkopiererei von En-WP.

ÅñŧóñŜûŝî (Ð) 16:29, 12. Jun. 2013 (CEST)

Es gibt kein englisches Format "11.9.2001" (dt.) oder "9.11.2001" (en); es gibt keine Punkte im Englischen, sondern Schrägstrich oder Bindestrich. Alle europäischen Sprachen mit Punkt verwenden Tag.Monat.Jahr. Was es gibt, ist 09/11/2001 oder 09-11-2001 (US) und 11/09/2001 (sehr selten 11-09-2001) in UK; see en:Date and time notation in the United States. Eindeutig ist hingegen ISO: 2001-09-11. Punkte sind in vielen Tabellen und Vorlagen der deWP üblich.

Appetithäppchen von meiner Festplatte zum Selberformatieren; jul ist inklusive:

=== Daten ===
==== Eingabe ====
Abfangen aller   \U+00A0 "  " "" bei der Eingabe. Interpretieren jedes eindeutigen Formats.
20220531220106 {{REVISIONTIMESTAMP}}
==== Neutrales Datenformat ====
table
year, month (1–12), dom, week (ISO), hour, min, sec, msec, zone, jul, bc, leap
==== spec ====
"T. Monat JJJJ", "dewiki", nil, false || 12. Juni 2013
"T. Monat JJJJ Z"                     || 12. Juni 2013 (CEST)
"T. Mon JJJJ"                         || 12. Jun. 2013
"T.Mon JJJJ"                          || 12. Jun. 2013
"TT.MM.JJJJ"                          || 12.06.2013
"T.M.JJJJ"                            || 12.6.2013
"ISO"                                 || 2013-06-12
"timestamp"                           || 20130612165733
usw. usw. mit Uhrzeit
=== Funktionen ===
Alle Lua-zugänglich. Jede story und spec ignoriert Whitespace drumrum, story ist die Zeichenkette mit zu interpretierender Eingabe.
; factory( story, lethal )
: Nur Lua-intern; insbesondere Eigenbedarf
: Liefert neutrale table, oder string mit Fehlermeldung
: throws error if lethal
; form( t, spec )
: Nur Lua-intern; insbesondere Eigenbedarf
: t ist neutrale table
; format( story, spec )
: auch für Vorlagen
: Rufe factory() auf und mit deren Ergebnis form()
; isValid( story, light )
: auch für Vorlagen
: light: erlaube leeren Wert
: Rufe factory() auf; true wenn diese eine table liefert
; isPretty( story, spec, light )
: auch für Vorlagen
: light: erlaube leeren Wert
: Rufe format() auf; true wenn dies identisch story liefert
Hilfsfunktionen; Ersatz/Service Julgreg-Vorlage

Rest später mal auf der Baustelle --PerfektesChaos 16:59, 12. Jun. 2013 (CEST)

Übrigens: Warum sieht das hier plötzlich so komisch überlappend aus? --PerfektesChaos 17:14, 12. Jun. 2013 (CEST)

Das überlappt sich, weil die Schrift, und damit auch die Zeilenhöhe im Span-Tag 150% hat und außerhalb des Span-Tags normale Zeilenhöhe (100%) gilt. Beides befindet sich aber in der gleichen Fließtextzeile. Darüber hinaus gibt es ein padding von 1em. Wenn du einen Rand definierst, dann fällt das auf, denn ein Browser berücksichtigt bei border das padding, ein Absatz entsteht aber nur bei einer Leerzeile im Quelltext und dessen Abstand hängt auch von den Grundeinstellungen ab. M.E. fehlt ein rahmenloses umhüllendes Div-Tag mit gegebener relativer Breite. Ich hab das mal umgesetzt. ÅñŧóñŜûŝî (Ð) 20:45, 12. Jun. 2013 (CEST)

• Mit „Überlappen“ hatte ich eigentlich diese Version gemeint. Warum ist die Schrift jetzt eigentlich nicht mehr grün? Und warum klemmt das jetzt so eingezwängt zwischen Inhaltsverzeichnis und folgender Box?
• Back to reality: /Datum und Uhrzeit

--PerfektesChaos 11:36, 13. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:32, 8. Feb. 2014 (CET)

Wikipedia:Lua/Werkstatt/Geo

Es gibt ganz offensichtlich kein wesentliches Interesse an einer Lua-Umsetzung des GeoHacks. Es hat sich jedenfalls niemand sonst gemeldet. Offensichtlich ist die Gemeinschaft mit der bisherigen Monstervorlage Vorlage:Coordinate zufrieden. Das diese mit mehr als 300.000 Einbindungen und ihren vielen Untervorlagen den Parser extrem belasten dürfte, ist offensichtlich nicht von Interesse.

Demgegenüber ist eine Umstellung u.A. aus folgenden Gründen viel Arbeit:

• Die Vorlage ist extrem unübersichtlich. Kaum einer dürfte da zurzeit voll durchsteigen.
• Es gibt zahlreiche Untervorlagen, welche schlecht dokumentiert sind, und welche wohl erheblich redundant sind.
• Zahltreiche nachträgliche Erweiterungen ohne genaue Beschreibung.
• Wichtige Autoren sind längst inaktiv
• Es fehlt an einer Möglichkeit, die Baumstruktur der Vorlage darzustellen.
• Zum Teil schlechte unübersichtliche Wikisyntax bei der bisherigen Codierung.

Es kostet also viel Arbeit, das Ganze zu analysieren und dann ein Modul zu schreiben. Aus der bisherigen Erfahrung folgt weiterhin, dass von einer Umsetzung die sofortige fehlerfreie Funktion erwartet wird. Wenn nicht, dann gibt es verbale Prügel. Eine sofort perfekte Umsetzung ist jedoch aus den o.g. Gründen kaum möglich.

Da ich absolut keine Lust habe, hier für viel Arbeit nur Gemotze und Pöbelei zu kassieren, habe ich daher beschlossen, das Thema nicht weiter zu verfolgen. Wer eine Umstellung auf Lua haben will, der soll meinetwegen von Enwiki abkopieren und versuchen, die spezifischen Änderungen (z.B. schweizer Landeskoordinaten) darin einzubauen. Eine Neuentwicklung steht ebenfalls jedem frei. ÅñŧóñŜûŝî (Ð) 15:51, 22. Jun. 2013 (CEST)

Hallo, Antonsusi. Schade, daß du dich durch die Kritisierer hast entmutigen lassen.

Ich habe am 27. Juni angefangen ein Modul dafür in der Esperantowikipedia zu erstellen: eo:Modulo:Coordinates. Es basiert auf der französischen und der spanischen Fassung des Moduls. Von der französischen Version stammt die Unterstützung für die Trennung der Parameter durch /. Von der spanischen Version stammt die Unterstützung für das Dezimalkomma, wobei der im Englischen übliche Dezimalpunkt ebenfalls unterstützt wird.

Allerdings ist mir beim Testen aufgefallen, daß alle Versionen einige Bugs haben. Diese sind in der Esperantoversion behoben.

• Sie geben nichts zurück, wenn bei den Paramtern format und/oder display unsinnige Werte angegeben werden. Ich lasse das Esperantomodul einfach auf die jeweilige Defaultwerte zurückfallen, obwohl ja auch der Einbau einer Wartungskategorie denkbar ist.
• Die Funktion dms2dec läuft nicht richtig, denn sie unterscheidet nicht zwischen Nord und Süd bzw. Ost und West. Sie gibt also immer negative Werte zurück. (In der englischen Version ebenfalls behoben, und zwar nach meinem Hinweis.)

Gruß --Tlustulimu (Diskussion) 11:21, 30. Jun. 2013 (CEST)

Die extreme "Zerfledderung", der teilweise grottenschlechte Code (bei dem jedes Leerzeichen stört), die vielen nicht dokumentierten Erweiterungen und das Fehlen wichtiger ehem. Autoren macht es m.E. unmöglich, hier zuverlässig eine exakte 1:1-Kopie hinzubekommen. Außerdem ist es auch nicht unbedingt sinnvoll. Es gibt garantiert redundanten Code und die Vorlage müsste dringend gestrafft werden. Es ist einfach zuviel hineingepackt worden. Zusammen mit dem Zoff, der hier schon wegen zwei Stunden fehlender Funktion in Artikeln gemacht wurde, ist es nur konsequent, das Thema zu lassen. Der von (teilweise besserwisserischen und unverschämten) Usern erhobene Anspruch, direkt eine perfekte Umstellung zu aktivieren, ist nicht zu erfüllen, denn diese Vorlage kann ohne "online zu gehen" nur zum Teil getestet werden. Dafür sind es zu viele Zweige und z. B. auch zu viele Einbindungen, welche sich auf Fehlermeldungen verlassen. Ich wünsche dir viel Glück. ÅñŧóñŜûŝî (Ð) 11:36, 30. Jun. 2013 (CEST)

Hallo, Antonsusi. Heute habe ich mich an die Vorlage Coordinates in der Esperantowikipedia getraut. Allerdings bearbeite ich sie nicht direkt, sondern habe erst mal eine Testversion erstellt: eo:Ŝablono:Koordinato/provejo. Dort funktioniert bereits ein Teil der Koordinatenfunktionen (NS, EW, teilweise auch text, type, region, name, dim). Ich muß noch Überprüfungen auf sinnvolle Werte und den Kartenteil mit Lua ausstatten. Das dürfte sicher noch komplizierter sein als die Koordinaten. Ich habe für den Koordinatenkram der Vorlage ein neues Lua-Modul eo:Modulo:Coordinates2/provejo erstellt, damit in dem bereits länger vorhandenen Modul der Überblick nicht so schnell verloren geht. Einen Teil des Codes habe ich in der spanischen Wikipedia entdeckt, denn ich kann mir nicht alles alleine ausdenken.

Außerdem muß ich mir noch etwas einfallen lassen, wie ich die Fehlermeldung in eo:Ŝablono:Koordinato/provejo so anpassen kann, daß sie wie bei der bisherigen Vorlage aussieht. Gruß --Tlustulimu (Diskussion) 20:59, 3. Jul. 2013 (CEST)

Hallo, Antonsusi. Die Entwicklung macht Fortschritte. Der erzeugte HTML-Code vom genannten Modul sieht schon ziemlich so aus wie der von der bisherigen Vorlage (eo:Ŝablono:Koordinato/+. Die eo:Ŝablono:Koordinato lokalisiert nur die Parameter.), wobei sogar die Mikroformate funktionieren. Das Verstecken der Nichtstandardausgabe (also "geo-nondefault") habe ich entsorgt, weil damit unnötig der Server beschäftigt wird und der Quelltext unnötig verkompliziert wurde. Jetzt fehlen noch einige Dinge:

• Mehrere Ausgabeformate bei "text" und "article" sind noch nicht implementiert.
• CH1903 fehlt auch noch. Dafür bräuchte das Modul nämlich zwei Funktionen, und zwar dec2ch1903 und dms2ch1903. Wofür steht label in der Funktion "WGS84toCH1903" auf deiner Testseite Benutzer:Antonsusi/Spielwiese/Modul:Coordinate?
• Die Kartenfunktionalität fehlt im Modul noch völlig. Keine Ahnung, ob ich die einzelnen Hilfsvorlagen von eo:Ŝablono:Situo sur mapo (entspricht der hiesigen {{Positionskarte}}) damit ausstatte oder gleich die Vorlage, die die Koordinaten berechnet. Das wäre dann eo:Ŝablono:Situo sur mapo/~ (hier {{Positionskarte~}})

Gruß --Tlustulimu (Diskussion) 21:05, 9. Jul. 2013 (CEST)

Hallo, Antonsusi. Ich habe gerade deine Funktion"WGS84toCH1903" von deiner Testseite Benutzer:Antonsusi/Spielwiese/Modul:Coordinate für die Schweizer Landeskoordinaten in eo:Modulo:Coordinates/provejo eingebaut, allerdings umbenannt in convert_dec2ch1903 und etwas angepaßt. Die ersten Tests liefen nämlich nicht. Aktuelle Ergebnisse sind auf meiner Benutzerunterseite für Lua zu sehen. Ich habe noch ein Problem mit dem Parameter prec, der der Funktion übergeben wird. Welche Werte kann er haben? Wie könnte ein Skript für die Umwandlung von dms in ch1903 aussehen? Gruß --Tlustulimu (Diskussion) 21:39, 10. Jul. 2013 (CEST)

Du kannst sowas nicht leicht herausfinden. Großflächige Objekte wie z.B. Kanton Glarus haben zwar gerundete Gradwerte, aber keine gröber gerundete Angaben in CH1903. Bisher habe ich auch nur ganze Zahlen gesehen und keine stark gerundeten. Nimm einfach eine feste Rundung auf Einer vor. Wenn's nicht gefällt gibt's von den Besserwissern hier in der WP die oben erwähnte verbale Prügel. Man verlangt genaugenommen, dass man sowas mit großem Aufwand ermittelt. Über die ganze Aufgabe hochgerechnet sind das etliche Stunden. Das ist genau einer der Gründe, warum ich das nicht mehr weitermachen will. Ich empfehle dir folgendes:

• Versuche durchzusetzen, dass nach der Umstellung zumindest anfangs nicht die exakte Funktionalität 100%ig gleich sein muss und du die diversen Extrafeatures nach und nach einbauen darfst. Wenn das auf Missfallen stößt, dann lass das ganze Thema.
• Wenn du es umsetzt, dann organisiere ein System für Fehlerrückmeldungen, damit du der Sache nachgehen kannst.
• Als Drittes kannst du Sachfragen klären. Du kannst auch versuchern, von Benutzer:Cactus26 das Leseskript für Vorlagenparameter zu bekommen. Dann kannst du dir die Aufrufe als Tabelle zeigen lassen. Die Vorlagen findest du übrigens hier.

Gruß von ÅñŧóñŜûŝî (Ð) 18:36, 11. Jul. 2013 (CEST)

Hallo, Antonsusi. Danke für deine Hinweise.

Ist es möglich auch die Formeln aus Vorlage:Coordinate/to UTM in Lua zu "übersetzen", und zwar so ähnlich wie beim CH1903-Format? Gruß --Tlustulimu (Diskussion) 19:34, 7. Aug. 2013 (CEST)

Hallo. Sogar die Vorlage {{Coordinate/to UTM}} ist in Lua portierbar. Ich habe den nötigen Code dafür heute in einem Testmodul der Esperantowikipedia entwickelt. Ein Anwendungsbeispiel steht auf meiner Benutzerunterseite über Lua. Ich muß nur noch das Ganze so einbinden, daß es auch als Ausgabeformat nutzbar wird. --Tlustulimu (Diskussion) 19:23, 9. Aug. 2013 (CEST)

Hallo. Das UTM-Format ist jetzt ins Modul Coordinates in der Esperantowikipedia eingebaut. Mal sehen, was ich so als nächstes ergänze. --Tlustulimu (Diskussion) 20:00, 10. Aug. 2013 (CEST)

Januar 2014

Hallo. Zwar funktioniert jetzt {{#coordinates: im dortigen Testmodul eo:Modulo:Coordinates/provejo in der Funktion coord. Aber aus mir nicht ersichtlichen Gründen klappt es damit in der Funktion coord2 leider nicht richtig. D.h. auf der Testseite erscheint {{#coordinates: als normaler Text. Auf der Testseite sind also keine Koordinaten zu sehen, obwohl es ja auf einer anderen Testseite klappt. Ich hatte es wie in coord mit globalFrame:preprocess versucht. Aber dann erscheint sogar die nichts sagende Fehlermeldung Skripteraro. Ich hatte auch schon

globalFrame = frame.args.gf 

durch

globalFrame = frame 

in coord2 ersetzt. Dann verschwand zwar die Fehlermeldung wegen nil in globalFrame, aber statt dessen gab es eine andere wegen preprocess. Warum klappt es mal und mal nicht? Das ist mir völlig unverständlich. --Tlustulimu (Diskussion) 18:02, 16. Jan. 2014 (CET)

Es sieht mir fast nach einer unvollständigen Korrektur eines Bugs aus. Siehe [2]. Dort geht es um eine PHP-Fehlermeldung unter mir unklaren Bedingungen. Solche Meldung erschien bei mir nie, sondern eine Lua-Meldung attempt to call method 'preprocess' (a nil value). Aber die Bedingungen, wann das geschieht sind mir rätselhaft. Ich weiß nicht einmal, ob der Fehler direkt von Lua kommt, oder von Scribunto.

Wenn ich aus eo:Ŝablono:Koordinato/testoj {{#coordinates:44.11200|-4.45889|primary|type:city}} in Vorlage expandieren kopiere, wird dieses normal gepartst, d. h. dort erscheint unter Rezulto gar nichts. Warum geht es dort und per Lua-Modul nicht? Seltsam ist, daß

text = text ..  globalFrame:preprocess(formatTest(args) )

in der Funktion coord ja funktioniert, aber in coord2 nicht. Dort mußte ich, damit die Funktion überhaupt noch den Koordinatenlink in die Titelzeile packt, dann

text = text ..  formatTest(args)  

schreiben, weil ja sämtliche Versuche den Bug zu umgehen nicht funktioniert haben:

• Änderung von globalFrame:preprocess in frame:preprocess
• neue Funktionen

Oder ist dem preprocess einfach die Funktion specPrinter2 zu komplex? Gruß --Tlustulimu (Diskussion) 06:33, 18. Jan. 2014 (CET)

Frohes Neues.

Damit du überhaupt eine Antwort bekommst, stottere ich mal was zusammen.

• frame
  • Habe ich nicht restlos verstanden, was du mir sagen möchtest.
  • Probier mal:
    local frame2 = frame:getParent()
return type( frame.args ) .. type( frame2 )
    sowie local frame3 = mw.getCurrentFrame()
• #coordinates:
  • Habe ich noch nie im Einsatz gesehen.
  • Ich habe mich auch noch nie mit Koordinaten beschäftigt und auch keinerlei Ressourcen, mich dort einzuarbeiten.
• preprocess
  • Was passiert beim Austausch von frame:preprocess() gegen:

    frame:callParserFunction( name, args )

• Im praktischen Einsatz mit immer komplexeren Lua-Vorlagen-Anwendungen zeigen sich Herausforderungen, zu denen das ursprüngliche reine Vorlagensystem an einigen Stellen weiterentwickelt werden muss, damit es Vorlagen, die Lua aufrufen, die Vorlagen einbinden, die Lua aufrufen … immer noch wie beabsichtigt handhaben kann.
  • Verbot des rekursiven Aufrufs
  • Korrekte Substituierung
  • Vorgeparste Elemente
• Bette deine Aufrufe in pcall() ein, dann werden die Fehlermeldungen intelligenter.
• Nutze die Hilfe:Lua/Quellcode und Vorschau #Konsole

Soviel als Hilfe zur Selbsthilfe, Grüße --PerfektesChaos 09:21, 18. Jan. 2014 (CET)

@PerfektesChaos: Danke für deine ausführliche Antwort. Ich habe es gerade mit

local frame = mw.getCurrentFrame()
text = text .. frame:preprocess(formatTest(args))

versucht und die Fehlermeldungen sind verschwunden. :-) Ich habe die Kombination in Module:Navbox, in der Funktion renderTrackingCategories(builder) gefunden. Jetzt funktioniert auch die Testseite wieder, sogar über die API für {{#coordinates:: [3].

Schuld an dem Problem war wohl, daß die Funktion ihre Parameter aus einem anderen Modul und der dortigen Hauptfunktion bekommt. Mit deinen Zeilen local frame2 = frame:getParent() und return type( frame.args ) .. type( frame2 ) klappte es nämlich nicht. Gruß --Tlustulimu (Diskussion) 19:09, 18. Jan. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:32, 8. Feb. 2014 (CET)

Wikipedia:Lua/Werkstatt/Datum_und_Uhrzeit

Wie sieht es mitt der Umsetzung der Datums- und Zeitfunktionen aus? Es gibt zahlreiche Seiten und ein Gemenge diverser Vorlagen, welche ein schlüssiges Gesamtkonzept benötigen. Wenn P.C. nicht dazu kommt, daran zu arbeiten, weil er nicht soviel Zeit hat, wie er für alle von ihm angefangenen Projekte benötigt, dann kann er dieses ja an mich abgeben. Setzt allerdings voraus, dass meine Lösung hinterher auch akzeptiert wird... ÅñŧóñŜûŝî (Ð) 00:04, 14. Okt. 2013 (CEST)

• Die Akzeptanz hängt nicht davon ab, wer etwas programmiert hatte, sondern ob es weitgehend fehlerfrei, intensiv getestet, konzeptionell in die Lua-Zukunft weisend und dokumentiert ist. Insofern kann es im Voraus keinerlei Zusagen geben, dass eine Lösung durch dich „akzeptiert“ werden würde, egal wie sie aussähe. Die Erfahrungen der letzten Monate im Lua-Vorlagen-Gebiet geben mir da wenig Anlass zur Hoffnung. Bevor die erste Zeile Programmcode geschrieben wird, würde ich gern erstmal deine Konzeption sehen, so dass alle Betroffenen ausreichend Gelegenheit zu Einwänden haben.
• Vorlagen haben den Zweck, die Artikelarbeit zu unterstützen, nicht sie zu behindern. Zweck des Projekts ist die Erstellung enzyklopädischer Artikel und nicht die Vorlagenprogrammierung. Wenn es anschließend zu etlichen Rückfragen durch die Artikelautoren und korrigierende Nacharbeit durch mehrere Leute kommt, wie das bei dir regelmäßig zu beobachten ist, dann war der Eingriff in ein funktionierendes System nicht sinnvoll.
• Beim Thema Datum+Zeit ist keinerlei Dringlichkeit zu erkennen. Einstweilen flutschen die Vorlagen; akute Probleme sind mir nicht bekannt. Nur um eine Programmierungstechnik durch eine andere zu ersetzen – und dabei im Fehlerfall Tausende von Artikeln zu beeinträchtigen – das ist keine sinnvolle Strategie und kein Plan. Eine konzeptionelle Integration kann langfristig sinnvoll sein; die Ausarbeitung unter /Datum und Uhrzeit schließt die Berechnung von Zeitspannen und eine universelle Behandlung aller Ein- und Ausgabeformate ein. Kurzfristig sollte man die Finger davon lassen.
• Die Reihenfolge der Abarbeitung zahlloser Aufgabenfelder erfolgt nach Dringlichkeit. Wenn es einen akuten Bedarf gibt, wird eine Implementierung vorgezogen.
• Vorsorglich weise ich Unterstellungen zurück, nur weil ich angeblich etwas gegen deine Person hätte, würde ich dich am Arbeiten hindern. Deine Vorgehensweise wird auch von anderen Benutzern nicht akzeptiert. Zu deinen Gunsten ist festzustellen, dass du vorher mit dem vorstehenden Beitrag ein Signal gegeben hattest; ich hoffe, die Antwort ist angekommen.

--PerfektesChaos 10:39, 15. Okt. 2013 (CEST)

Ja, ist sie. Zur Sache: Es geht nicht nur darum, die Problemfälle zu lösen, sondern auch darum, dass eine gute Umsetzung die Serverlast reduzieren kann (aber nicht muss). Die bisherige "Patchworkdecke" an teilweise redundanten, teilweise auch überladenen vorlagen lässt die Hoffnung zu, dass eine Entlastung des Servers möglich ist. Darüber hinaus ist die Umstellung eine gute Möglichkeit, ein abgestimmtes System zu erstellen (Konsolidierung). Gerade in der Übernahme von Aufgaben, welche nicht so sehr unter den Nägeln brennen, sehe ich für mich Möglichkeiten, das Thema Lua / Serverentlastung / Vorlagenkonsolidierung voranzubringen. Einen Entwurf für ein Konzept kann ich ja mal erstellen, wenn daran Interesse besteht. ÅñŧóñŜûŝî (Ð) 17:03, 15. Okt. 2013 (CEST)

• Mach doch lieber da etwas, wo wirklich ein Problem zu lösen ist; siehe oben.
  • Du könntest besser per Regexp die Spalten in Artikeln zu Wikipedia:WVW#Zwingender Optimierungsbedarf bei Vorlage:nts auf feste Tausenderpunkte ohne irgendwelche Funktionen und Vorlagen umstellen, so dass auch Autoren die Tausenderpunkte als Hilfestellung beim Bearbeiten haben und die Seite wieder darstellbar ist.
  • Das wäre eine wirkliche Lösung eines realen Problems mit Serverlast.
• Wikipedia:Sorge dich nicht um die Server
  • Ansonsten kann uns die Serverlast egal sein, solange die Seiten nicht alle viere von sich strecken, wie a.a.O.
  • Es ist übrigens nicht bewiesen, dass eine Umstellung auf Lua per se irgendwas beschleunigen würde. Jedes #invoke kostet zunächst reichlichen Aufwand, der durch Einsparungen gegenüber den sehr viel preiswerteren Parserfunktionen erstmal wieder reingeholt werden muss. Die Parserfunktionen für das Datum kosten deutlich weniger Serverlast als Lua; es muss schon eine zusätzliche Funktionalität hinzukommen, um das zu rechtfertigen. Siehe dazu auch die obigen Performance-Auswertungen.
• Zum Thema Datum+Zeit als Lua-Modul gibt es bereits eine implementierungsreife Konzeption; s.o. Ob es eine gute Idee ist, das noch toppen zu wollen?

--PerfektesChaos 09:24, 16. Okt. 2013 (CEST)

Wikipedia:Sorge dich nicht um die Server ist angesichts der heutigen Probleme m.E. Schnee von gestern. Da Serverleistung teuer ist und die WMF dafür kein Geld (übrig?) hat, ist das längst auch ein Thema. Aus deinen Angaben ergibt sich, dass dies besonders auch für Lua zu betrachten ist. Es käme also auf den konkreten Fall an, ob ein Vorteil besteht. Nicht nur zusätzliche Funktionalität, sondern auch ein neues vernünftiges übersichtliches Konzept rund um das Thema Datum und Uhrzeit ist ein Grund für die Umstellung.

Das von dir erwähnte Thema schaue ich mir mal an.

ÅñŧóñŜûŝî (Ð) 10:50, 16. Okt. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:32, 8. Feb. 2014 (CET)

Mehrzeilige Lua-Kommentare

Hallo. Auf den Seiten Hilfe:Lua/Modul im Wiki und eo:Modulo:Listigo/provejo (Besonders der letzte, denn dort wird plötzlich alles rot.) sehen die mehrzeiligen Kommentare irgendwie komisch aus. Ist das ein bisher nicht gemeldeter Fehler? Gruß --Tlustulimu (Diskussion) 23:51, 16. Mai 2013 (CEST)

Das ist syntaktisch okay, bloß ein Darstellungsproblem. Der Syntaxhighlighter erwartet deine Wikilink-Klammern nicht. Tatsächlich ist es so, dass auch das Innere eines mehrzeiligen Kommentars noch als Lua-Syntax gilt; zumindest was die Suche nach schließenden Klammern angeht. Und die muss auch der Syntaxhighlighter finden. Vielleicht verbessert das mal jemand; wir sind nicht die ersten und ich habe keine Lust.

Hilfe:Lua/Modul im Wiki: Wo genau dort? Ich seh nix, außer dem Üblichen halt.

VG --PerfektesChaos 12:10, 17. Mai 2013 (CEST)

Hallo, PerfektesChaos. Eine eigentlich falsche Darstellung findest du unter Funktionen nur für Vorlagen, sowie innere Hilfsfunktionen, gleich am Anfang.

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

Richtig sieht es nämlich erst ohne = aus, also alles in Hellgrau und kursiv:

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

Weißt du jetzt, wie ich es meine? Gruß --Tlustulimu (Diskussion) 22:27, 17. Mai 2013 (CEST)

• Es ist mir schon durchaus klar, was du meinst. Ich guck seit Januar den enWP-Kollegen beim Entwickeln zu, und da ist das laufend so.
• Es sollte also schon seit einem halben Jahr den Zuständigen aufgefallen sein. Weil das GeSHi des syntaxhighlight ein externes Produkt ist, kann es eine Weile dauern, bis jemand Lust hat, das nach oben zu melden und danach richtig auf MediaWiki zu aktualisieren.
• Die fehlerhafte Definition steht hier –

    'COMMENT_MULTI' => array('--[[' => ']]'),
    'COMMENT_REGEXP' => array(2 => '/\[(=*)\[.*?\]\1\]/s'),

• Es muss also bei COMMENT_MULTI die gleiche Paaruung (=*) und \1 stehen. Weil das ein Paar von Ausdrücken im array ist, braucht man möglicherweise für jede Anzahl von Gleichheitszeichen einen eigenen Ausdruck. Vielleicht geht aber in GeSHi nur einer.
• Da ich keinen Bugzilla-Account habe, habe ich auch keine Lust, dem hinterherzurennen. Irgendwann schleicht sich das ganz von selbst ein.

Gute Nacht --PerfektesChaos 00:12, 18. Mai 2013 (CEST)

Hallo, PerfektesChaos. Das Problem ist sogar größer als oben von mir beschrieben. Wenn man sich ein Lua-Modul unangemeldet anschaut, wird das Sytaxhighlighting sogar teilweise total verhauen. Es ist also wohl doch ein richtiger Bug. Aber warum wird die Darstellung unangemeldet sogar eher verstümmelt als angemeldet? Das ist doch irgendwie seltsam. Wo meldet man so etwas am besten, damit es doch noch dieses Jahr behoben wird? Seltsam ist aber, daß en:Module:Listify/sandbox und en:Module:Age in der englischen Wikipedia unangemeldet nicht falsch dargestellt werden. Das gleiche passiert bei fr:Module:Hello in der französischen Wikipedia. Vielleicht ist es ja doch irgend eine seltsame Nebenwirkung von Modul:Vorlage:LuaModuleDoc und Vorlage:LuaModuleDoc oder irgendwelchen Formaten im MediaWiki-Namensraum. Soll ich mal nachschauen? Gruß --Tlustulimu (Diskussion) 23:36, 19. Mai 2013 (CEST)

An en:Module:Listify/sandbox und en:Module:Age und fr:Module:Hello sehe ich weder angemeldet noch unangemeldet etwas Böses.

Bei uns ist irgendwas im Gange, was irgendwie auf das Sytaxhighlighting Einfluss hat. Ich sehe die Modulseiten nie unangemeldet.

Vorlage:LuaModuleDoc kann nichts tun, was außerhalb der Box irgendeine Auswirkung hat. Wenn das jemand zaubert, hätte er so einiges geknackt. Siehe Modul:AdressenSort zum Vergleich.

MediaWiki:Common.css und MediaWiki:Common.js sehen beide gut aus. Sie haben einen Einleitungssatz.

Was ganz offensichtlich fehlt, ist die Einbindung von /Doku, wie sich beim Vergleich der beiden Varianten von Modul:AdressenSort sehen lässt. Damit wird dann auch der Quellcode nicht richtig in den Highlighter geschoben, und er erkennt erste und letzte Zeile schon mal gar nicht.

Mit dem oben eröffnenden Mehrzeilige-Kommentare-Problem hat das hier nichts zu tun.

Schöen Feiertag --PerfektesChaos 00:09, 20. Mai 2013 (CEST)

1. →Wikipedia:Technik/Werkstatt#Lokales Wiki und etwas PHP-RegExp-Spielerei benötigt
2. Hast du inzwischen diskutiert bei BD:Raymond #Geshi funktioniert unangemeldet nicht im Modulnamensraum.

Saluton --PerfektesChaos 22:49, 21. Mai 2013 (CEST)

Heute aufgefallen: Der Fix hat sich nach upstream und wieder zu uns zurück rumgesprochen.

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 22:41, 1. Dez. 2014 (CET)

Modul:TemplatePar

In Vorlage:Infobox Fußballklub wurde heute oben genanntes Modul in fehlerhafter Weise eingebaut, so dass nun in allen knapp 5000 einbindenden Artikeln ein kleines rotes Quadrat unter der Infobox erscheint (siehe exemplarisch Hamburger SV).

Das Problem ist folgendes: Es war wohl gewünscht, die Ausgabe des Moduls, die ein <span> mit roter Schrift ist, in eine rot umrahmte Box zu packen; dies darf aber natürlich nur geschehen, wenn die Ausgabe nicht leer ist. Dies könnte man durch eine Abfrage erreichen, dafür müsste man das Modul aber zweimal aufrufen.

Ich wollte deshalb mal fragen, ob es nicht evtl. sinnvoll wäre, eine rot umrahmte Box (formatiert durch <div class="errorbox"> oder ähnliches) durch das Modul selbst zu erzeugen. Oder gibt es weitere Ideen, wie man das Modul anders einbinden/umgestalten kann, so dass in allen Fällen sinnvolles HTML und CSS erzeugt wird? --Entlinkt (Diskussion) 23:14, 18. Okt. 2013 (CEST)

Was die Benutzer nicht alles für Formatierungswünsche haben.

Mein Vorgehen für solche Fälle wäre wie folgt:

• Es wird für alle Funktionen ein weiterer optionaler Parameter format= eingeführt, der einen Platzhalter $1 enthalten sollte.
• Das Standardverhalten (keine Angabe) wäre:

  <span class="error">$1</span>

• Wer den nackten Rohtext haben möchte, kann format=$1 angeben.
• Das momentane Angebot noError=1 würde mittelfristig wegfallen. Vielmehr wäre dann ein format=0 bzw. format= zu setzen; da es auch kein $1 enthält und mit Sonderbedeutung interpretiert wird. Ansonsten sind auch Texte ohne $1 möglich, die die Situation dann nicht präzisieren können.
• Dekoration mit einfühlsamem Freitext ist dann ebenfalls möglich. Insbesondere können Anwender jede beliebige Formatierung und Gestaltung der spezifischen Fehlermeldung erreichen; ohne sich in der universellen Modul-Programmierung über den Standardfall hinaus auf Details festlegen zu müssen.

Bislang lässt sich das gewünschte Verhalten auch mit einer einzigen Modul-Ausführung erreichen, die das Resultat als Parameter {{{1|}}}} einer Unter-Vorlage nach Belieben auswertet.

In meiner Prioritätenliste einsortiert hinter TemplateData und Abschluss der anhängigen Normdaten.

LG --PerfektesChaos 11:08, 19. Okt. 2013 (CEST)

Der Rahmen ist erstmal wieder weg. Könnte man nicht zwei weitere Strings übergeben, einen für vor und einen für hinter das Span-Tag, welche nur bei nichtleerem Ergebnis auftauchen? ÅñŧóñŜûŝî (Ð) 17:18, 19. Okt. 2013 (CEST)

Nein.

Dann hätten wir schon drei Parameter nur zur Formatierung der Fehlermeldung; hinzu käme dann noch ein vierter, wenn jemand den span aber grad nicht in rot haben möchte.

Durch diesen Wust würde niemand mehr durchsteigen.

So gibt es genau einen Parameter, und in dem kann man sich durch mehrfache $1 die Fehlermeldung gleich mehrfach basteln, wer das nun wieder mit unterschiedlichen CSS-Klassen mag.

Der vorgenannte Format-Parameter deckt sämtliche Varianten in einem ab.

--PerfektesChaos 23:14, 19. Okt. 2013 (CEST)

Info: Im Moment kann man den Status nicht mit "#iferror:" abfragen, da dein Modul class='error' und nicht class="error" widergibt. Könntest du das noch ändern? Es funktioniert zwar - wegen des leeren Strings - auch mit einfachem "#if:", aber iferror erlaubt auch eine Abfrage, wenn die Rückgabe des Moduls bereits mit Wikiprogrammierung verändert und deshalb ggf. nicht mehr leer ist. ÅñŧóñŜûŝî (Ð) 00:45, 20. Okt. 2013 (CEST)

Aha. Mir war nicht bekannt gewesen, dass irgendjemand einen Unterschied macht zwischen class='error' und class="error", aber ich nehme das selbstverständlich auf; danke für den Hinweis.

Ich ahne dann, wie #iferror: funktioniert, und werde Hilfeseiten entsprechend ergänzen.

Den Quellcode aller weiteren Module habe ich ebenfalls instruiert (sie laufen nach und nach zu); es war schlicht einfacher, "<span class='error'>" statt etwa "<span class=\"error\">" zu schreiben.

TemplatePar hat damit eine genügend lange Liste kleinerer Upgrades, so dass ich mich bei nächster Gelegenheit an eine neue Version machen werde; zunächst auf Beta.

VG --PerfektesChaos 10:48, 20. Okt. 2013 (CEST)

Das geht wohl über den String class="error" Einfach mal testen:

Code	Wirkung
<span class="error"></span>	funktioniert
<span class="error "></span>	funktioniert
<span class=" error"></span>	funktioniert
<div class="error" ></div>	funktioniert
<span class="error" ></span>	funktioniert
<span class= "error"></span>	funktioniert nicht
<span class ="error"></span>	funktioniert nicht
<span class='error'></span>	funktioniert nicht

Leerzeichen rund ums "=" mag der Parser auch nicht ... ÅñŧóñŜûŝî (Ð) 12:45, 20. Okt. 2013 (CEST)

Was es nicht alles gibt; die hatte ich nicht auf dem Kompass. Soeben noch ergänzt.

VG --PerfektesChaos 13:44, 20. Okt. 2013 (CEST)

Evtl. ist diese Funktion ja so sensibel, um besonders wenig code zu haben und schnell zu sein. Ich gehe davon aus, dass die compilierten Parserfunktionen auf Geschwindigkeit beim Parsen und Ausführen getrimmt sind. Deinen Tipp mit der Unterseite habe ich übrigens umgesetzt. Da hätte ich eigentlich auch draufkommen können... ÅñŧóñŜûŝî (Ð) 14:32, 20. Okt. 2013 (CEST)

Noch etwas: Gerade ist eine Wartungskat von 250 auf 251 gewachsen, aber ich kann natürlich nicht herausfinden, welche Seite neu dazugekommen ist. Das bringt mich auf die Idee, bei der Umsetzung des o.g. Format-Parameters auch eine Möglichkeit einzubauen, einen Sortierschlüssel für die Kat anzugeben. Da könnte man bei Bedarf (nicht dauerhaft) entweder zwischen PAGENAME (Standard), "REVISIONTIMESTAMP" oder evtl. auch einem freien Schlüssel sortieren lassen. Was hältst du davon? ÅñŧóñŜûŝî (Ð) 14:40, 20. Okt. 2013 (CEST)

1. Es war ursprünglich sicher nur für die selbst generierten Fehlermeldungen gedacht gewesen. Ein RegExp muss aus verschiedenen Gründen ohnehin im Spiel sein (bin zu faul, das PHP rauszusuchen, aber es sind mehrere Klassen gleichzeitig und spezifische Tags möglich), und den könnte man ohne signifikanten Mehraufwand auf wahlweise Apostroph-Begrenzung anpassen.
2. REVISIONTIMESTAMP kommt mir wenig haltbar vor, und für alle anderen Bearbeiter ziemlich verwirrend. Da es nur eine einzige Sortierung für die gesamte Wartungskat gibt, sollte das durchschaubar bleiben. Jede spätere Veränderung an irgendeiner Stelle der Seite, die gar nichts mit der fraglichen Vorlage zu tun haben muss, führt wieder zu einer anderen Reihenfolge. Das erinnert mich an die sogenannten „Tageskategorien“ bei den defekten Weblinks, mit denen man vor einem Jahr einmal die alphabetische Reihenfolge der Artikelnamen abbilden wollte. Heute steht da sonstwas drin, weil jeder Edit eines Artikels eine andere Struktur bewirkt.

VG --PerfektesChaos 22:39, 20. Okt. 2013 (CEST)

Ok. ÅñŧóñŜûŝî (Ð) 22:29, 26. Okt. 2013 (CEST)

Wäre es möglich, das Modul so zu gestalten, dass gleichzeitig sowohl unbekannte Parameter als auch fehlende Pflichtparameter aufgezeigt werden? Das hätte den Vorteil, das User nach dem Entfernen unbekannter Fehler nicht auf "speichern" (statt auf "Vorschau") klicken, um dann zu sehen, dass noch weitere Fehler drin sind. ÅñŧóñŜûŝî (Ð) 14:58, 27. Okt. 2013 (CET)

Lua selbst kann daran nur wenig machen, und verhält sich auch nicht anders als Vorlagensyntax. Und man sollte es auch besser nicht mit Vorlagensyntax versuchen, weil dies bei unterschiedlicher Sichtbarkeit der REVISIONID Chaos im Cache verursachen kann.

• Eine Unsichtbarkeit wird durch die umschließende Vorlage geregelt, gegen die das Modul von innen nichts ausrichten kann.
• Ich habe allerdings eine entsprechende Konzeption im Hinterkopf; genauso wie das Thema „systematische Wartungskategorien“ steckt das aber momentan in einer Sackgasse.
• Grundsätzlich gibt es eine class="action-edit", die dann und nur dann existiert, wenn eine Seite bearbeitet wird (also bin ich gerade in der Vorschau) und sonst nicht.
  • Das und Weiteres könnte man ausnutzen, um eine intelligente projektspezifische Fehlerklasse bzw. variablen CSS-Stil zu generieren:
    • Bedingungslos Fehlermeldungen immer anzeigen, wenn Seitenvorschau.
    • Fehlermeldungen nicht anzeigen, wenn Seite nur angeguckt wird von nicht (oder noch nicht lange) angemeldeten Benutzern.
    • Fehlermeldungen bei der Seitenansicht nicht oder immer anzeigen, wenn bestimmte Benutzer dies ausdrücklich aktiviert oder deaktiviert haben.
  • Diese Thematik habe ich jedoch zurückgestellt, da ich dabei momentan recht allein unterwegs bin.

Modul:TemplatePar schreitet in diesen Tagen auf beta voran; dort ist bereits die frei konfigurierbare Anzeige der Fehlermeldungen eingebaut sowie mehrfache Wartungskategorien und Eignung von Parametern als Datei-Link. Letzteres muss noch vervollständigt werden, und es kommt noch der Parametertest für Sprachspezifikation hinzu. Erst nachdem dies gründlich erprobt ist, wird es vorsichtig in die 200.000 Eiinbindungen hier übernommen.

Schönen Sonntag --PerfektesChaos 15:34, 27. Okt. 2013 (CET)

⇐⇐⇐ Ich habe das bisher zweimal eingesetzt und Vorlagensyntax reicht dabei auch aus. Was ich zuletzt fragen wollte: Bisher gibt es, wenn sowohl unbekannte P. als auch leere Pflichtparameter existieren, nur eine Meldung über die unbekannten Parameter. Erst wenn die entfernt wurden und man dann die Vorschau nutzt, gibt es eine neue Meldung über fehlende oder leere Pflichtparameter. Ich würde mir wünschen, dass direkt beide Meldungen kommen. Außerdem könnte man bei der Gelegenheit die Meldung kürzen, indem die Doppelung ("Fehler in Vorlage" und "Vorlage:<Vorlagenname>" wegfällt. Beispielsweise:

Das wäre eine Erleichterung für die Korrektur und wohl unabhängig von einer größeren Umstellung sinnvoll. Gruß von ÅñŧóñŜûŝî (Ð) 15:53, 27. Okt. 2013 (CET)

Das erfolgt bewusst nicht und steht da eigentlich auch irgendwo mit bei: Unbekannte P. sind sehr oft schlicht Schreibfehler des gewünschten Pflichtparameters. Man hätte also nur einen einzigen Fehler, aber verwirrenderweise zwei Fehlermeldungen hintereinander dafür. Aus diesem Grund: Unbekannten Parameternamen richtig schreiben oder ganz rauswerfen, dann Vorschau angucken.

Die Wortwahl dient der Orientierung. Wer Profi ist, weiß, was Literatur oder Infobox Galaxie ist; wer nicht damit auskennt, braucht aber den vollständigen Namen mit Namensraum. Und weil es viele unterschiedliche Quellen von Fehlern gibt, kann man auch die Einleitung „Fehler bei Vorlage“ nicht rauswerfen; zumindest nicht für die weniger erfahrenen Bearbeiter. Zumal der Text dieses Meldungsbestandteils ansonsten auch frei konfigurierbar ist und es dein Bier ist, wie du das formulierst. Umgekehrt kann des Rätels Lösung aber auf einer Projektseite stehen wie Wikipedia:Textbausteine/Formatierungshilfen oder auf einer Hilfeseite. Es ist also überhaupt nicht gesichert, dass eine Vorlage als Ursache benannt wird.

VG --PerfektesChaos 16:32, 27. Okt. 2013 (CET)

Wurde mit Parameter format in Spezial:Diff/137040515 frei konfigurierbar gestaltet; damit hier erledigt.

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 21:12, 23. Dez. 2014 (CET)

Einmischung, eine Anregung

Eigentlich wollte ich mich heute abend noch ein Stündchen um etwas anderes kümmern, aber ...

Durch die diversen Vorkommnisse aus jüngster Zeit kann hier ratz-fatz jegliches Vertrauen der Community in die Wörter Modul und Lua verspielt werden. Das würde ich sehr bedauern, nicht zuletzt, weil wir selbst z.Zt. selbst an einem wichtigen Modul arbeiten. Das verlorene Vertrauen müsste dann erst mühsam durch seriöse Arbeit wieder aufgebaut werden.

Ich möchte daher anregen, dass als Sofortmaßnahme ein verpflichtender 4-(6..8..)-Augen-Review für jedes neue Modul vereinbart wird und dass neue Module nicht durch den oder die Entwickler, sondern vorläufig nur durch einen Admin (nach Anfrage auf Wikipedia:AA) in Produktion genommen werden. Dem Admin wäre dabei die Beteiligung von 2 (3..4..) Personen nachzuweisen. Genauere Prozeduren kann man ja dann immer noch erarbeiten.

Wenn hier eine solche Absprache getroffen werden sollte, kann diese den Admins ja auch ausdrücklich bekanntgemacht werden. --Martin Taschenbier _{[Das Narrenschiff - nie war es so aktuell wie heute]} 22:30, 2. Jun. 2013 (CEST)

Absprachen sind gewiss sinnvoll. Haupthindernis dabei ist meines Erachtens aber, dass PerfektesChaos, der gewiss gute Programmierkenntnisse hat, grundsätzlich mal alles ablehnt, was nicht aus seiner Feder stammt. Seine Ausdrucksweise kommt noch dazu. Ein Modul hier quasi "sichten" zu lassen, bedeutet deshalb nicht, dass nur Fehler korrigiert werden und optimiert wird, sondern dass grundsätzlich alles durch seine Vorstellungen von einer Lösung ersetzt wird. Damit gehen auch die funktionierenden Lösungen anderer Programmierer verloren. Du musst also damit rechnen, dass von deiner Arbeit, auch wenn sie gut ist und funktioniert, nicht mehr viel übrig bleibt, wenn du sie hier vorstellst (Es sei denn, er macht eine Ausnahme, um meine Äußerungen hier nicht zu bestätigen). So hat er bereits angedeutet, dass er Offline an einem Ersatz für Modul:Str arbeitet und das damit begründet, es sei "keine richtige Lua-Programmierung". Angesichts der Tatsache, dass das Modul funktioniert, eindeutig Überheblichkeit. Es bedarf auch keines Admins, hier einen Konsens zu finden. Es bedarf der Bereitschaft zum Dialog und dem Unterlassen überheblicher und herablassender Äußerungen, (siehe eins drüber) weil man selber eine andere Lösung wählen würde. Das gilt auch für den Fall, dass es eine bessere Lösung ist. ÅñŧóñŜûŝî (Ð) 21:38, 8. Jun. 2013 (CEST)

Ich weiß ja nicht auf welchen Seiten du deine Meinung bildest, allerdings geht es nicht darum, dass ein Nutzer alle Module schreiben soll oder nicht, sondern darum, dass deine Module meist schlecht getestet und überhastet eingeführt werden. Wenn der bereits erwähnte Nutzer ein Modul erstellt, wird dies genauso kritisch betrachtet, allerdings sind seine Werke meist deutlich besser getestet als deine. Insbesondere gibt es dann auch eine Testseite und eine vernünftige Doku. Das Haupthindernis ist also wohl eher deine Uneinsichtigkeit. Und wenn ein von dir erstelltes Modul durch andere Nutzer (eventuell erfahrener) überarbeitet wird, dann sieh dir die Änderungen an und lerne daraus (das wird dir im Leben da draußen öfters passieren). --Steef ³⁸⁹ 22:04, 8. Jun. 2013 (CEST)

Ich habe nie behauptet, dass ich stets mit ausreichend Sorgfalt gearbeitet habe. Die ersten, von mir geschriebenen Module waren gewiss zu schnell umgesetzt. So habe ich bei einem Modul nach dem Testen nochmal editiert und dabei einen Fehler eingefügt und ein anderes mal habe ich beim Wikitext einen Fehler eingebaut (zwei } zu wenig). Ein weiteres Thema ist der Test auf Unsinnseinbindungen und exakte Replikation des Zustands davor (Ursache für das Thema eins drüber). Offensichtlich kommt hier aber nicht rüber, worum es mir geht:

1. Bessere (!) Lösungen habe ich bisher immer akzeptiert. So z.B. die Maximumfunktion im Modul:Expr als Ersatz für meine vorherige Lösung.
2. Fehlende Toleranz: Funktionierende (!) Lösungen anderer User sind nicht "nur deshalb Sch....", weil sie nicht von einem selbst stammen. Es gibt auch keinen Grund, sie nur deshalb durch maximal gleichwertige andere zu ersetzen.
3. Sherif-Stil (siehe eins drüber) und herablassende Äußerungen über die Fähigkeiten anderer Benutzer sind absolut ungeeignet, den Dialog zu fördern. Wer will schon mit jemandem zusammenarbeiten, der in jedem dritten Edit eine Äußerung nach dem Prinzip "Ich klug, du dumm" von sich gibt?

ÅñŧóñŜûŝî (Ð) 22:35, 8. Jun. 2013 (CEST)

Bei dir erkenne ich nur weiter Ad-personam-Diskussionen. PC ist hier nunmal aufgrund seiner Präsens, Erfahrung und mangels gleichwertiger Mitspieler der erfahrenste und umsichtigste Benutzer auf dieser Seite. Andere Lösungen können (im Hinblick auf ihre Weiterentwicklung) für alle aufgrund einfacherer Wartung für alle förderlich sein. Den "Sherif-Stil" in Form von "Ich will kein viertes Mal mehr sehen." ist als deutlicher Hinweis zu sehen, auch da ich keine Einsicht und Konsensfindungsversuche in der Sache sehe, sondern nur weiter Kommentare ("... eindeutig Überheblichkeit.", aber gleichzeitig "Es bedarf der Bereitschaft zum Dialog und dem Unterlassen überheblicher und herablassender Äußerungen") gegen die Ausdrucksweise anstatt mal auf die Sache wie von dir gewünscht hinzuarbeiten. Also konkret zur Sache: Warum bist du für oder gegen ein Mehr-Augen-Prinzip? (Thema dieses Abschnitts)--se4598 / ? 22:54, 8. Jun. 2013 (CEST)

Ich habe doch geschrieben, dass ich bei der Umsetzung der erten Module zu schnell war. Das habe ich doch nie bestritten Wo ist da die "fehlende Einsicht"?

Ich bin grundsätzlich für ein Mehr-Augen-Prinzip!

Damit das Mehr-Augen-Prinzip funktioniert, sind bestimmte Regeln nötig:

1. Ausreichend Toleranz, d.h., Die Autorenschaft ist für die Einstufung, ob eine Modul gut oder schlecht ist, zu vernachlässigen.
2. Anständiger Umgang. Keine Äußerung im Stil "Deine Ideen sind Schrott!" sondern (stattdessen) "Dieses und Jenes könnte man noch ändern."
3. Gerechte Bewertung: Jede Lösung, welche eine Aufgabe im notwendigen Umfang erledigt, ist zunächst gleichwertig. Eine andere Lösung ist nur dann besser, wenn objektive Kriterien wie mehr Features, Beseitigung einer Einschränkung o.Ä. dafür sprechen. Ein Totalaustausch zwischen gleichwertigen Versionen ist zu unterlassen.
4. Ein Schema muss erstellt und gut erklärt werden. Die Reihenfolge der Entwicklungsschritte, die Art der Tests u.A. muss vereinbart werden.
5. Alle Offline-Arbeiten an fundamentalen Modulen für die WP sind zu erwähnen. Ein "Aus-dem-Hut-zaubern" ist zu vermeiden. (gilt auch für mich... )

ÅñŧóñŜûŝî (Ð) 23:19, 8. Jun. 2013 (CEST)

Gute Punkte! In Bezug zu obigen Regeln:

1. Sollte überall eine Selbstverständlichkeit sein.
2. Sollte auch eine Selbstverständlichkeit sein, wobei natürlich auch eine Meinung zu einem grundsätzlich falschem/problematischen Aufbau konstruktive Kritik sein kann bzw. so formuliert werden sollte.
3. Bietet der Anstand. (Ansonsten/Für eine Ankündigung) sei die Diskussionsseite zu benutzen und die Gründe darzulegen, wie an anderen Orten sonst auch.
4. Versteh ich nicht ganz, wie du das meinst. Eine Doku sollte vorhanden sein bzw. im Zuge des Reviews erstellt werden. Siehe auch eins drunter
5. Offline-Arbeiten können/sollten im Sinne einer Zusammenarbeit und Vermeidung von doppelter Arbeit angekündigt werden (praktisch wäre das geplante Konzept/Schema). Die Möglichkeit des Online-Stellens/Entwickelns in einem der Testwikis sollte bedacht werden. Grundsätzlich ist es aber egal, ob sowas vorher erwähnt wird/woher es kommt, es muss ja diskutiert werden.

--se4598 / ? 00:04, 9. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:29, 5. Mai 2018 (CEST)

Liste der Biografien

Kopiert aus Wikipedia:WikiProjekt Vorlagen/Werkstatt#Liste der Biografien:

Hallo. Es gibt ja die Liste der Biografien mit sehr vielen Unterseiten, siehe z.B. Liste der Biografien/Muli. Dort gibt es im oberen und unteren Bereich Navigationsblöcke, die jeweils aus mehreren Vorlagen bestehen. Nun kam zunächst die Idee auf, die Navigation einklappbar zu machen und in diesem Zusammenhang wäre es ganz schön, wenn statt mehrerer Vorlageneinbindungen, dies mit einer zu machen wären, in der Form {{Navigation LdB|Muli}}. Die spannende Frage ist, ob es mittels Lua möglich ist, automatisch nur die Seiten anzuzeigen, die vorhanden sind. Also für "Muli" müsste folgendes gemacht werden: 1. Buchstaben "M", also in der ersten Zeile alle Seiten auflisten, die die Form "M[a-z]" haben (oder besser: "M."). In der zweiten Zeile dann alle der Form "Mu." und in der dritten diejenigen der Form "Mul.". Natürlich nur diejenigen Seiten, die existieren. Erschwerend kommt hinzu, dass neben "Mu." auch "Mu.-Mu." berücksichtigt werden sollte, siehe z.B. Liste der Biografien/Mea–Mee.

Ist das technisch mittels Lua möglich? Kann das Vorhandensein von Seiten abgefragt werden? Es wäre halt schön, auf die ganzen Vorlagen verzichten zu können. --APPER\^☺☹ 14:10, 22. Jun. 2013 (CEST)

1. Ich werde dich nach gegenseitiger Kenntnisnahme und Einverständnis hier herausoperieren und in die Wikipedia:Lua/Werkstatt verschieben.
2. Vorab meine ersten Gedanken. Den Rest gibt es nach Sonnenuntergang, wenn mein Frischluftbedürfnis gestillt wurde und die Nachtkühle mir wieder einen klaren Kopf beschert.
   • Lua kann anders als Vorlagensyntax elegant mit unbegrenzten Mengen unbenannter Parameter hantieren.
   • Die Frage nach der Existenz einer Seite ist mit Lua genauso teuer und Server-belastend wie ein #ifexist in Vorlagensyntax.
     • Ich würde diesen Weg lieber vermeiden wollen.
   • Wer das aber sehr gut wissen wird, ist dein Bot bzw. die dahinter stehende Datenbank.
     • Ich hätte es lieber so, dass der Bot von diesem Wissen beim Generieren der Seite Gebrauch macht.
   • Lua kann anders als Vorlagensyntax Zeichenketten splitten; das heißt statt unterschiedliche Parameter über Pipe zu trennen, können sie genauso mit Leerzeichen, Komma, Schrägstrich oder was immer separiert werden.
   • Dies zusammengefasst würde ich mir lieber folgenden generierten Seitenkopf vom Bot wünschen (Daten fiktiv):

        {{Index Biografien
         |1=M
         |2=Ma Me Mi Ml Mo Mr Mu My
         |3=Mub Muc Mud Mue Muf Mug Muh Muk Mul Mum Mun
        }}

Beachte das angenommene Fehlen von Mua, Mui, Muj.

Der Bot weiß beim Durchpflügen deiner Datenbank sowieso, wann er einen neuen Unterbuchstaben auf welchem Level öffnet, und kann bis dahin den Vorlagen-Stub auf dem Level darunter weiter benutzen.

Sonniges Wochenende --PerfektesChaos 15:42, 22. Jun. 2013 (CEST)

Das sieht ja ganz gut aus. Aber ist #ifexist wirklich so aufwändig? Steak 23:09, 22. Jun. 2013 (CEST)

• Der Bot müsste aus den ihm bekannten Informationen die folgende Vorlageneinbindung generieren; Daten teils fiktiv:

        {{Unterseiten-Index-Staffelung
         |ABCDEFGHIJKLMNOPQRSTUVWXYZ+
         |aceiloruy
         |bcdefghklmn
         |abcdefghijklmnorstuvyz
         |h='''[[Biografie]]n:'''  
        }}

• Beachte beim letzten abc-Wert: Die Buchstaben pqwx fehlen, weil es ausweislich Präfixindex keine solchen Namen gibt: Liste der Biografien/Mulp * Liste der Biografien/Mulq * Liste der Biografien/Mulw * Liste der Biografien/Mulx
• Unabhängig davon, wovon etwas Unterseite sein soll (sieht Lua am Namen der dargestellten Seite; bzw. würde mit ../ voll-relativ gehandhabt werden) werden auf den vier Leveln die Index-Listen generiert.
  • Universell einsetzbar für alle analogen Fälle.
• Ein Pluszeichen gefällt mir besser als das Fragezeichen; bei dem würde ich eine Hilfeseite erwarten. Die Plus-Seite müsste dann bei der mir vorschwebenden Programmierung eine Weiterleitung auf /Diverse sein.
• Aus der obigen Vorlageneinbindung kann mit Lua ungefähr folgendes Design generiert werden (Details und Dekoration nach Belieben):

Biografien:   A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  +

• Ma · Mc · Me · Mi · Ml · Mo · Mr · Mu · My
  • Mub · Muc · Mud · Mue · Muf · Mug · Muh · Muk · Mul · Mum · Mun · … … …
    • Mula · Mulb · Mulc · Muld · Mule · Mulf · Mulg · Mulh · Muli · Mulj · Mulk · Mull · Mulm · Muln · Mulo · Mulr · Muls · Mult · Mulu · Mulv · Muly · Mulz

• @Steak: Es sind 75 teure Datenbankabfragen erforderlich; weil unten wiederholt 150 pro Seite. Das ist merkbar in CPU-Sekunden und Rendering-Zeit. Das absolute Limit, bei dem die Seite nicht weiter gerendert wird, liegt bei 500 teuren Funktionsaufrufen.

Schönen Sonntag --PerfektesChaos 11:20, 23. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:29, 5. Mai 2018 (CEST)

Breitere Anwendung von Modul:TemplatePar

Spricht etwas gegen die breitere Anwendung von Modul:TemplatePar, um beispielsweise bei Infoboxen analog nicht existierende Parameter aufzuspüren?
Im Gegensatz zur Vorlage:Information soll IMO im ANR die Fehlermeldung

Fehler bei Vorlage * Parametername unbekannt (Vorlage:Abc): 'Xyz'

nur für eingeloggte Benutzer zu sehen sein. --Leyo 17:41, 7. Aug. 2013 (CEST)

Zur Sichtbarkeit:

• Dazu wäre wohl eine Klasse erforderlich, die am besten WMF ausliefern müsste?
  • Ich kenne grad keine.
• Es ist zwar möglich, hier über JS abzufragen, ob angemeldet, und dann dynamisch eine Klasse nachzureichen; aber das wäre eher unverhältnismäßig.
• In anderen Vorlagen wird mit der class="metadata" gearbeitet; die ist von Experten aktiviert.
  • Wir haben aber keinen Modus „angemeldeter fortgeschrittener Autor“.
• Es gibt wohl nur eine class="client-nojs" und Pendant, mit der man je nach aktiviertem JS ein- und ausblenden kann.
• Das Ergebnis von Lua ist immer für alle gleich und über Wochen identisch; egal wer es sich anguckt.

Komplett unsichtbar wäre die Variante Wartungskat; bei Verwendung einer Untervorlage effizient mit Wartungskat + metadata für die Putzkolonne.

VG --PerfektesChaos 22:41, 7. Aug. 2013 (CEST)

Am besten fände ich, wenn nur Benutzer, die Zeige Wartungskategorien ausgewählt haben, die Fehlermeldung (und die Wartungskategorie) sehen. Alternativ wäre auch eine Abhängigkeit von Benutzerrechten möglich, etwa Editor. Was davon ist technisch möglich? --Leyo 23:21, 7. Aug. 2013 (CEST)

Technisch möglich ja; aber begrenzt verhältnismäßig.

• Wir können hier per JS die Benutzereinstellung „Wartungskat“ abfragen (oder die Gruppe testen, oder das Sternzeichen des Anmeldezeitpunkts) und nachträglich eine CSS-Klasse definieren, die eine standardmäßige Ausblendung mit gleicher Spezifizität überschreibt. Für jeden Leser. Ruckelt wahrscheinlich im Erfolgsfall etwas.
• Besser wäre diese Veranstaltung auf dem Server untergebracht und würde gleich mit ausgeliefert; etwas wie hidden-maintenance mit Standardwert display:none oder so. Allerdings fällt mir außerhalb der Gadgets kein Präzedenzfall ein, wo es einen einstellungsabhängigen CSS-Block geben würde. Realisiert ist sowas wohl eher in den einzelnen Skin-Programmierungen.

Liebe Grüße --PerfektesChaos 10:51, 12. Aug. 2013 (CEST)

Zur Gruppe fällt mir grad noch ein: MediaWiki:Group-sysop.css. LG --PerfektesChaos 10:54, 12. Aug. 2013 (CEST)

Mir wäre noch nie zu Ohren gekommen, dass es auf Seiten, wo Vorlagen mit Nicht-Admin-Ausblendungen eingebunden sind, zu einem Ruckeln kommen würde. Oder meinst du, dass MediaWiki:Group-shown-maintenance.css oder ähnlich angelegt werden müsste? --Leyo 07:12, 16. Aug. 2013 (CEST)

1. „Ruckeln“ bezieht sich auf JavaScript. Hier wird parallel oder nachträglich CSS generiert und dem Modell hinzugefügt. Wenn aber schon die Seite aufgebaut war, muss diese neu gerendert werden.
2. Eine Vorlage mit Nicht-Admin-Ausblendungen bezieht ihr Wissen aus MediaWiki:Group-sysop.css.
3. Meine oben nur noch angerissene Idee war ein anscheinend wirksames MediaWiki:Group-editor.css.
4. Dieses gruppenspezifische CSS ist Bestandteil des vom Server ausgelieferten HEAD und damit schon präsent, wenn das DOM aufgebaut und anschließend gerendert wird. Deshalb kann es nicht ruckeln.

Schönen Tag --PerfektesChaos 10:11, 16. Aug. 2013 (CEST)

Verstehe ich dich richtig, dass etwas wie MediaWiki:Group-editor.css für Sichter nicht auch für „Wartungskategorie-Aktivierte“ möglich ist (weil es sich nicht um eine Benutzergruppe handelt)? --Leyo 13:57, 23. Aug. 2013 (CEST)

Ja; nur über die Benutzergruppe gäbe es eine simple Lösung.

• Man könnte sich auch an das Metadaten-Gadget dranhängen und darin eine weitere Klasse spezifizieren; oder ein weiteres Gadget analog zu diesem in die Welt setzen.
• Alles andere bedarf tieferer Programmierung; am besten serverseitig mit weltweiter Wirkung.

LG --PerfektesChaos 22:19, 23. Aug. 2013 (CEST)

Dein Vorschlag bezüglich Metadaten-Gadget hört sich sinnvoll an. 2010 scheint es allerdings sehr wenige Nutzer gegeben zu haben. Heute sind's wohl etwas mehr.

Auf irgendetwas müssen wir uns mal festlegen. Ändern kann man es ja dann später immer noch. --Leyo 00:47, 26. Aug. 2013 (CEST)

In dem Metadaten-Gadget kann etwas angefügt werden wie

div.wp_Versteckte-Wartung,
div.wp_hidden-maintenance {
   display: block;
}
span.wp_Versteckte-Wartung,
span.wp_hidden-maintenance {
   display: inline;
}

Groß-Klein-Deutsch-Englisch nach Belieben

Wenn man sch eines Tages entschließt, das über ein separates Gadget zu steuern oder andere Kriterien vom Himmel fallen, etwa über Benutzergruppe editor, dann können alle Vorlagenprogrammierungen unverändert bleiben und der Sichtbarmacher kommt halt irgendwo anders hin.

Diskussionsplattform für deinen Wunsch ist ansonsten MediaWiki:Common.css, wo das display:none gleicher Spezifität eingefügt werden muss.

LG --PerfektesChaos 21:29, 26. Aug. 2013 (CEST)

Funktioniert sowas in diesem Fall nicht? --Leyo 23:31, 26. Aug. 2013 (CEST)

Ich verstehe den Sinn deiner Frage nicht; beim „sowas“ liegt eine etwas andere Situation vor.

• Dort gibt es eine Vorlage, in der style="display:none" steht; auf Element-Ebene.
• Dieses style= wird dann vom Gadget wieder aufgehoben über !important.

Wir waren hier allerdings bei einer Klasse, die ohne Vorlage drumrum direkt den Elementen zugewiesen wird.

Vorlage geht natürlich auch: {{Meldung die nur angezeigt wird wenn|1=Meldungstext}}

Oder jede Meldung wird umgeben von

<span class="wp_Versteckte-Wartung" style="display:none">Meldungstext</span>

• Dann musst du aber jedesmal dran denken, dass das style="display:none" mit dazugeschrieben wird; sonst funktioniert es nicht.

VG --PerfektesChaos 23:58, 26. Aug. 2013 (CEST)

Hm, ich tue mich grad schwer damit, abzuschätzen, welches die sinnvollste Variante wäre. Es sollte am besten ein nicht allzu langer und einigermassen allgemeinverständlicher Code in die Infoboxen eingebaut werden. Eine Vorlage hört sich daher nicht schlecht an, würde allerdings zu mehr Vorlageneinbindungen führen. --Leyo 00:09, 27. Aug. 2013 (CEST)

Der Anwendungsfall einer erkannten Fehlersituation mit Meldung aber dann doch nicht so wichtig kann nur innerhalb der Vorlagenprogrammierung vorkommen.

• Wer mit sowas Vorlagenprogrammierung betreibt und eine neue Fehlererkennung schreibt, sollte auch mit <span class="wp_Versteckte-Wartung">Meldung</span> klarkommen, oder besser die Finger davon lassen.

Jede wirksam werdende Vorlage mehr erhöht nicht nur die Serverlast, sondern auch den in einigen Bereichen bereits angestrengten Ressourcencount (etwa Seiten mit vielen Koordinaten).

Für die Lua-Programmierung (in deren Werkstatt du dich befindest) sind Vorlagen nicht akzeptabel; dort schreibt man Klartext, weil man sonst in komplexeren Lua-Programmen erst mühsam das frame-Objekt herbeischaffen muss und die Internationalisierung behindert wird.

Gute Nacht --PerfektesChaos 00:51, 27. Aug. 2013 (CEST)

Ich habe Modul:TemplatePar nun testweise in Vorlage:GESTIS eingefügt. Irgendwie klappt's aber nur teilweise: Natriumvinylsulfonat und Natriumisethionat werden korrekterweise erkannt, Stärke und Bleihydrogenarsenat fälschlicherweise aber nicht. Den Grund habe ich nicht ermitteln können. --Leyo 21:10, 2. Sep. 2013 (CEST)

Das hing im Zweig "ohne ZVG", habe das mal korrigiert. Der Umherirrende 21:17, 2. Sep. 2013 (CEST)

<handandiestirnschlag> Vielen Dank! --Leyo 21:24, 2. Sep. 2013 (CEST)

Betreffend Wartungskategorien habe ich unter Wikipedia Diskussion:WPK#Unterkategorien von Kategorie:Wikipedia:Vorlagen-Parameterfehler eine Diskussion angefangen. --Leyo 15:49, 3. Sep. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:29, 5. Mai 2018 (CEST)

Modul:Wikidata notwendig?

Mag sich jemand den unteren Teil von d:Wikidata:Forum#Kadernavigationsleisten anschauen und die Frage, ob es Modul:Wikidata auch hier braucht, beantworten? --Leyo 22:44, 30. Aug. 2013 (CEST)

Das Teil hatte ich schon vor Monaten vorgemerkt; als Import zum spätestmöglichen Zeitpunkt, unmittelbar bevor es jemand wirklich benötigt, in der dann letztausgereiftesten Verson.

Faszinierend finde ich, dass es keine weltweit einheitliche Mutterversion gibt, d:Module:Wikidata ist leer. Welches ist nun die aktuellste Variante? Q12069631 müsste auch auf Wikidata vorhanden sein; jedes Wiki hält nur aus verwaltungstechnischen Gründen eine lokale Kopie und aktualisiert sich mit der Mutterversion. Schon konzeptioneller Bruch. Die Programmierung auf enWP ist nicht d:-registriert. Sie sei irgendwie modifiziert. Es fehlt ihr eine Lua-Schnittstelle. Nicht ausgereift, unkoordiniert, nicht vertrauenerweckend.

VG --PerfektesChaos 23:28, 30. Aug. 2013 (CEST)

Inhaltlich kann ich die en-Version nicht beurteilen, aber die Dokumentation macht immerhin einen guten Eindruck. --Leyo 23:42, 30. Aug. 2013 (CEST)

Es ist brav als alpha gerated: may be used on a few pages to see if problems arise.

• Es fehlt im Minimum die Lua-Schnittstelle, um als Vorbild dienen zu können.
• Ob alle erforderlichen Funktionen enthalten sind, kann ich nicht beurteilen.
• Die Version strebt noch nicht den Status als Vorbild an.

Bei einem Modul, dessen Quellcode als weltweite Kopiervorlage dient und über einen Item verlinkt wird, muss eine definierte Schnittstelle realisiert werden:

• Alle Funktionen sind mindestens über einen definierten Namen aufrufbar und haben dann gleiche Wirkung.
• Alle Parameter dieser Funktionen sind mindestens über einen definierten Namen verwendbar, und gleiche Werte haben gleiche Wirkung.
• Es mag lokal unterschiedliche Implementierungen hinter der Schnittstelle geben:
  • Effizientere Programmierung
  • Lokalisierung von Funktions- und Parameternamen und -werten zuätzlich zum Standard.
  • Zusätzliche Funktionen enthalten.

Es gibt zurzeit keine definierte Schnittstelle und keine Mutterversion.

VG --PerfektesChaos 22:13, 4. Sep. 2013 (CEST)

Danke für deine Analyse und ausführliche Antwort! --Leyo 00:25, 7. Sep. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:29, 5. Mai 2018 (CEST)

Doppelte Parameter

Mir ist aufgefallen, dass in Vorlage:Information momentan nicht auf mehrfach vorhandene Parameter geprüft wird. Beispielsweise wird bei

|Urheber  = Benutzer A
|Urheber  = Benutzer B

der obere ignoriert, ohne dass die entsprechende Dateibeschreibungsseite in eine Wartungskategorie kommen würde. Soll das nicht ergänzt werden? Wäre es zudem sinnvoll, auf eine mehrfache Einbindung der Vorlage zu prüfen? Falls ja, was wäre der entsprechende Code? --Leyo 11:48, 15. Okt. 2013 (CEST)

Das ist nicht aus normaler Programmierung ermittelbar.

• Weder die Vorlagenprogrammierung noch Lua bekommen etwas davon mit. Der zweite Parameter überschreibt die erste Zuweisung; es kann durch Parameteranalyse nur festgestellt werden, dass der Parameter zugewiesen wurde, und dass der Wert B ist. Sowohl in Vorlagenprogrammierung wie Lua.
• Es geht nur, den Quelltext der Dateibeschreibungsseite in Lua einzulesen und dann über Mustererkennung zu analysieren:
  • Kommt die Vorlageneinbindung mehr als einmal vor?
  • Gibt es mehrere für die Vorlage:Information charakteristische Parameterzuweisungen? Wobei diese, wenn sie nicht sehr spezifische Namen tragen, aber auch von anderen Vorlagen benutzt werden könnten.
    • Weil es verschachtelte Aufrufe mit anderen Vorlagen derartiger Parameternamen geben kann, ist das nur ein Hinweis, nicht aber eine gesicherte Fehleinbindung.
    • Wegen der verschachtelten Aufrufe ist auch ein Parsen mit öffnenden und schließenden Klammerpaaren nicht trivial; in WSTM mache ich das, und ich weiß noch gut, dass es zwei Monate gedauert hatte, bis ich das robust und sicher analysiert hatte (ohne den ursprünglichen Wikitext zu demolieren). Gleichwohl kann man hier erst die Kommentare aus dem Analysetext löschen; danach alle Paarungen von öffnenden und schließenden Klammerpaaren, so dass nur der Rumpf der zu untersuchenden Vorlage übrig bliebe; mit reduzierten Wertzuweisungen. In diesem Rumpf können nur noch die Zuweisungen Parametername=Wert stehen, und hier darf jeder Parametername nur genau einmal vorkommen.

Ich hatte vor einiger Zeit schon mal angekündigt, dass es ein spezielles und abgekoppeltes Modul nur für die Vorlage:Information im Namensraum 6 geben müsse; dagegen hatte der Umherirrende jedoch heftig protestiert.

LG --PerfektesChaos 09:38, 16. Okt. 2013 (CEST)

Danke für deine ausführliche Antwort! Ich hätte nicht gedacht, dass es sooo komplex ist. Vielleicht will der Umherirrende noch Stellung beziehen. --Leyo 12:12, 16. Okt. 2013 (CEST)

Ich hatte nur die Notwendigkeit nicht gesehen, wenn es um die Überprüfung der Parameter geht. Wenn jetzt eine neue Funktionalität kommt, kann gerne ein weiteres Modul aufgerufen werden, wenn eine Kombination der Modul notwendig ist, kann das auch gerne erfolgen. Ich streube mich nur dagegen, für jede Vorlage ein Modul zu machen, was dann den Prüfcode für die unnötigen Parameter enthält, das wäre für mich redundant/unnötig. Der Umherirrende 17:40, 16. Okt. 2013 (CEST)

Und ich hatte damals schon klargestellt:

• Es geht nicht darum, jede Vorlage mit einem eigenen Modul auszustatten, sondern um eine Handvoll Großkunden mit Einbindungszahlen im sechsstelligen Bereich.
• Bei diesen Großkunden ist die Abkopplung vom Mutter-Modul durch eine Kopie des ausgetesteten und robusten Codes auch durchaus sinnvoll:
  • Eine Veränderung der Standard-Bibliothek ist für mich wie für die Server umso belastender, je mehr Seiten von der Änderung betroffen sind.
  • Eine Änderung und Erweiterung an Code-Funktionalität in der Standard-Bibliothek, die hier etwa die Dateibeschreibungsseiten gar nicht mehr betrifft, soll sie auch nicht beeinflussen.
  • Für die Performance spielt es ebenfalls eine Rolle, wenn auch hier die ziemlich winzigen Dateibeschreibungsseiten nicht an Beschränkungen stoßen: Jedes #invoke und jedes require() eines weiteren Moduls geht spürbar in die Ressourcen.
  • Aus diesen Gründen denke ich mir sehr wohl etwas dabei, wenn ich das unabhängige Vorlagen-Modul mit einer Kopie derjenigen wirklich benötigten ausgetesteten und fertigen und kaum noch zu verändernden Funktionen auszustatten beabsichtige.
  • Eine Funktionalität für die effiziente und auch gegen unkonventionelle Formatierungen weniger empfindliche Absicherung gegen irrtümliche Mehrfacheinbindung habe ich seit längerer Zeit auf der Festplatte. Sie wird benötigt für die Vorlagen Begriffsklärung, Information, Normdaten und TemplateData; die vorgenannten Effizienzgründe gelten auch hier.
• Die Erkennung einer irrtümlichen Mehrfacheinbindung war auch bei der letzten Diskussion dieser Art bereits Thema gewesen und auslösende Anfrage durch Leyo. Insofern ist das hier überhaupt nichts Neues, nur inzwischen kilobyteweise zu Tode gequatscht. Ich habe die Angelegenheit Modul:Vorlage:Information deshalb sehr weit zurückgestellt zugunsten dringlicherer Fragen; den fertigen Code auf meiner Festplatte eingemottet.

VG --PerfektesChaos 20:35, 16. Okt. 2013 (CEST)

Meiner Meinung nach wurden Methoden, Funktionen oder auch Module unteranderem dafür geschaffen, um Wiederholungen in der Programmierung zu reduzieren, daher finde ich das nicht den richtigen Ansatz. Eine {{!}} wird man auch nicht für "Großkunden" duplizieren, um einer Veränderung vorzubeugen (Die Einfachheit der Vorlage ist natürlich vernachlässigt, aber das lässt sich vom Grundsatz auf alle Vorlagen übertragen) oder einen Performancevorteil zu erhalten. Man würde sogar den gegenteiligen Effekt haben, weil die Vorlage:! aufgrund der häufigen Nutzung eine sehr hohe Verweildauer im Cache haben wird und es den Server dadurch leicht fällt, sie aufzulösen. Ich weiß nicht, wie die Anbindung von Lua in MediaWiki im einzelnen funktioniert, kann mir aber vorstellen, dass die Binaries auch im Cache liegen und ein häufig genutztes Modul dadurch einen Vorteil beim Einbinden haben wird.

Auch wenn der Änderungsbedarf bei Standard-Bibliotheken gering ist, kann es sein, das in Zukunft das Interface von Lua oder von mw.frame sich ändert und dadurch Änderungsbedarf besteht, dann müsste in mehreren Modulen geändert werden. Je nach Verbreitung der Kopien kann dies auch einen hohen Aufwand bedeuten. Keiner kann sagen, wie viele Großkunden es geben wird.

Der Overhead bei einer Änderung von Modulen und auch Vorlagen ist hoch, sollte uns aber niemals davon abhalten, einen (aus meiner Sicht) einfachen Weg zu gehen. Die Server und auch der Serverload sind für mich vernachlässigbar, sofern eine Seite noch anzeigbar ist. Es gibt so viele Dinge auf der WMF-Seite, das man die Server wohl sehr schwierig "down" bekommt. Vorlagen und Module müssen nur bei einem Reparse einer Seite durchlaufen werden, dies passiert aufgrund einer Bearbeitung der Seite selber, einem purge durch den Benutzer (oder durch WikiData) und durch Bearbeitung von Vorlagen und Modulen, die auf der Seite verwendet werden. Das ist in Relation zu den pageviews sehr vernachlässigbar. Falls eine Seite doch mal Schwierigkeiten macht, dann werden die Serveradmins sich melden, häufigen Anlass hatten sie dafür noch nicht.

Ich möchte mich dem auch nicht in den Weg stellen, wenn du für deinen Ansatz einen/mehrere Fürsprecher hast, kannst du den Ansatz auch gerne umsetzen. Der Umherirrende 21:13, 16. Okt. 2013 (CEST)

• Zum Cache kann ich dir eines mitteilen: Zumindest wenn das auch wie geplant auf den Servern umgesetzt wurde, wird jeder abgespeicherte Lua-Quellcode (Modul-Seite) sofort und einmalig in einen Bytecode kompiliert und dieser auf dem Server bereitgehalen; also ähnlich wie bei der Generierung von PNG aus den SVG. Es liegt also immer im Cache.
• Das Problem ist ein anderes, wie ich nun schon mehrfach bei Performance-Analysen herausgebracht habe: Die Funktionen #invoke und require() kosten jedesmal, wenn sie an irgendeiner Stelle aufgerufen werden, zimlich viel CPU-Zeit. Das ist völlig unabhängig davon, wie oft sie zuvor schon in derselben Seite vorkamen. Insbesondere #invoke ist ziemlich langwierig, weil erst ein frame aufgebaut wird. Das ist nicht zu vergleichen mit den üblichen Parserfunktionen. Nur mw.loaddata() werden einmalig pro dargestellter Seite geladen und können wiederverwendet werden, können aber keine Funktion enthalten.
• In der Vorlagenprogrammierung gibt es keine in das Modul eingebetteten Funktionen; deshalb trifft der Vergleich nicht zu.
• Ein robuster Satz an Funktionen sollte bei hunderttausendfach eingebundenen Modulen eingekapselt und vollgeschützt werden, und dann sollte das nur noch geändert werden, wenn es einen zwingenden Grund dafür gibt. Was irgendwo anders im Projekt passiert und zu Änderungen führt, hat dann keine Auswirkung mehr auf diesen Großkunden.
• Es handelt sich nur um Kopien der benötigten Funktionen des Standard-Moduls. Sollte es tatsächlich einmal erforderlich sein, eine erprobte Funktion des Standard-Moduls zu ändern, wäre das bei der Handvoll betroffener Spezial-Module auch mit simplem C&P zu propagieren.

VG --PerfektesChaos 21:49, 16. Okt. 2013 (CEST)

Jede {{ oder {{{ erzeugt auf Preprocessor-Seite ein neuen Frame, nur das ein #invoke auch eine Lua-Engine braucht, diese muss einmal pro Seite erzeugt werden und anschließend das Frame in ein Lua-Frame umgewandelt werden. Das ist overhead, daher kannn ich verstehen, das pro Seite das nur einmal gemacht werden soll, aber ist dann immer die Frage, ob die Sache dadurch übersichtlicher wird, aber das ist wohl eher eine Philosophie-Frage. Ich würde den Aufruf eines Sub-Modules immer mit dem Aufruf einer weiteren Vorlage sehen, wo auch häufig die Möglichkeit genutzt wurde, Formatierungen oder Berechnungen oder anders zu zentralisieren. Lua (oder Scribunto) scheint wohl ein require_once zu benötigen, was es bei php auch beispielsweise gibt, um zu vermeiden, das php-Files während eines Requests zweimal geladen werden. Der Umherirrende 19:32, 18. Okt. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:29, 5. Mai 2018 (CEST)