Wikipedia:Lua/Werkstatt

Diese Seite ist eine Diskussionsplattform zu zwei Themen:

• Unterstützung bei der Lua-Programmierung in einem konkreten Modul und Hilfe bei der Fehlersuche
• Wünsche für die Implementierung neuer Lua-Funktionen

Die Anforderungen an eine zielführende Fragestellung mögen sinngemäß den Intros der Schwesterwerkstätten entnommen werden: Wikipedia:WikiProjekt Vorlagen/Werkstatt Wikipedia:Technik/Werkstatt Zu allgemeinen Gepflogenheiten siehe Wikipedia:Werkstätten.

Sachdienliche Antworten können von allen gegeben werden.

{{{Text}}}

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Zum Archiv

Wie wird ein Archiv angelegt?

Längerfristige Baustellen

• BKS – Begriffsklärungsseiten
• Datum und Uhrzeit
• Defekter Weblink Bot
• Geo – Geo-Koordinaten
• Flagicons
• Zitation – Vorlagen Literatur, Internetquelle u. a.

Template:Module rating

Hallo. Brauchen wir denn eine Übersetzungen der Vorlage en:Template:Module rating? Wenn ja, wie soll die Vorlage denn heißen? --Tlustulimu (Diskussion) 19:00, 15. Mai 2013 (CEST)

Danke, sehr lieb, aber da werden wir keine agency für ausstatten können.

Mit offenem Modul (ohne Benutzer:) hat man sich erst dann von de.wikipedia.beta.wmflabs.org aus hier im Namensraum blicken zu lassen, wenn es beta erreicht hat.

Ansonsten kriegt man das auch freihändig hin: Spezial:Permalink/118063050

Einen Hinweis auf 10.000-fach eingebundenes Modul als Kriterum für eine vorwiegend einzuhaltende Vollsperrung eines ausgereiften Moduls habe ich schon in der Schublade.

Eine administrative agency, die ein Review macht und unausgereiften Schrott verhindert, bevor er produktiv eingebunden wird, sehe ich auch noch nicht patroullieren.

Besten Dank --PerfektesChaos 20:37, 15. Mai 2013 (CEST)

Module für vielgenutzte Vorlagen

Vorlage:Internetquelle hat ein Datumsproblem, vgl. Jeff Walker abgerufen am 1 v. Chr. Gruß, Siechfred Cradle of Filz 16:34, 2. Jun. 2013 (CEST)

Und wieder ein Fall, in dem eine neues Lua Modul überhastet und ungetestet eingeführt wurde... Wie währe es zur Abwechslung mal damit, andere über das Modul drüberschauen zu lassen, als es sofort zu benutzen AS?

Das Problem ist laut seiner Disk jetzt behoben.--Steef ³⁸⁹ 17:08, 2. Jun. 2013 (CEST)

Erstmal revert. --Steef ³⁸⁹ 17:11, 2. Jun. 2013 (CEST)

Danke, bei über 70.000 Einbindungen sollte man in der Tat ein wenig mehr Fingerspitzengefühl walten lassen. Gruß, Siechfred Cradle of Filz 17:13, 2. Jun. 2013 (CEST)

Du solltest mal überlegen, was du da erwartest: Bei über 100.000 Einbindungen der Vorlage:FormatDate (um deren Modul geht es hier) als Untervorlage von mehrere Hundert verschiedenen, anderen Vorlagen ist es völlig ausgeschlossen, jeden nur erdenklichen Fall zu testen, insbesondere dann nicht, wenn eine Vorlage bisher gezielt einen fehlerhaften Aufruf ausnutzt. Ohne die Umstellung der Vorlage:FormatDate auf das Modul ist das Modul ja nicht in den anderen Vorlagen - darunter auch Vorlage:Internetquelle - eingebaut und damit nicht feststellbar, ob alles funktioniert. Das geht also nur durch ausprobieren direkt in der Vorlage. ÅñŧóñŜûŝî (Ð) 18:11, 2. Jun. 2013 (CEST)

<ironie>Nein, testen ist natürlich nicht möglich, ohne das Modul einzubauen.</ironie> Wenn man eine Vorlage mit mehr als 10000 Einbindungen duch ein Modul ersetzt, so muss es möglich sein, möglichst viele Einbindungen zu überprüfen. 40 ist hier definitiv zu wenig, dann muss man sich mehr Zeit nehmen. Desweiteren könnte man das Modul auch erstmal hier erwähnen, damit sich andere Benutzer mit Lua-Kenntnissen sich das ganze anschauen. Dies würde auch endlich mal zu einer vernünftigen Doku führen! Erklär also nicht deine eigene Faulheit damit, dass das Testen nicht möglich ist. Es gibt auch die Möglichkeit des Testwikis, wenn du ohne die Vorlage zu ersetzen des Testens nicht mächtig bist. Ist ja leider nicht zum ersten mal geschehen... --Steef ³⁸⁹ 20:20, 2. Jun. 2013 (CEST)

Ergänzung: Vor allem, wenn ich dann sowas sehe, innerhalb von 8 Minuten schicken wir 4 mal ca 200000 Seiten (!) zum neu rendern. Warum auch nicht? --Steef ³⁸⁹ 20:25, 2. Jun. 2013 (CEST)

(BK)

• Ein Testwiki nützt nichts. Nur hier auf de:WP befinden sich die 500 Vorlagen, welche auf FormatDate zugreifen.
• Für die Kontrolle einer Seite braucht man 1/2 bis 1 Minute. Da wären bereits 100 Seiten eine ganze Stunde Arbeit, und das ist dann immer noch ein marginaler Teil aller Einbindungen. Es bleibt bei der Tatsache, dass nur alle Leser zusammen genug Augen haben, um zuverlässig Fehler zu finden. Dein Vorwurf der Faulheit ist deshalb schlicht eine Freschheit.
• Deinem "Ironie-Kommentar" entnehme ich, dass du entweder nicht über die notwendige Sachkompetenz verfügst zu erkennen, dass man sowas hier im Modulbereich testen muss, oder dass du schlicht die Freschheit besitzt, diesen Kommentar wider besseres Wissen zu verfassen. Ich gehe gem. WP:AGF zu deinen Gunsten von Ersterem aus.

Hier erwähnen ist etwas, dass ich machen könnte. In dem Punkt gebe ich dir Recht. Die anderen Einwände sind unberechtigt.

Zum Thema Server: Solange keine Seiten auf Kategorie:Wikipedia:Seite mit Skriptfehlern auftauchen, ist das nicht so dramatisch. Die Kat wird nur aktualisiert (wieder geleert), wenn der Server viel Zeit hat oder eine Seite editiert wird. Ansonsten fliegen die Seiten nur aus dem Cache und werden bei Lesezugriff neu gerendert, und zwar nur dann mehrmals, wenn zwischendurch (also in den 8 Minuten) schonmal zugegriffen wurde. Außerdem ist es nunmal so, dass hier kein brauchbarer (!) Debugger existiert. Das bewirkt zusätzliche Edits. Was sind denn darüber hinaus 200.000 Renderungen, wenn die Vorlage danach schneller ist und für die Zukunft weniger Serverzeit braucht? ÅñŧóñŜûŝî (Ð) 20:56, 2. Jun. 2013 (CEST)

"Ohne die Umstellung der Vorlage:FormatDate auf das Modul ist das Modul ja nicht in den anderen Vorlagen - darunter auch Vorlage:Internetquelle - eingebaut und damit nicht feststellbar, ob alles funktioniert.": Die Aussage ist falsch. Unter Wikipedia:Lua wird explizit die Vorlagenspielwiese erwähnt mit der genau so eine Überprüfung möglich ist. --Mps、かみまみた^Disk. 20:46, 2. Jun. 2013 (CEST)

Du verstehst das Problem nicht. Es ist nicht möglich, die Einbindungen einer vorhandenen Vorlage (im ANR) mit einem Modul in der eigenen Spielwiese zu testen. Das geht nur mit einer manipulierten Version dieser Vorlage selbst und dem Übertragen der Einbindungen von einzelnen Artikeln in die Vorlagenspielwiese. Allenfalls kann man noch von der umzustellenden Untervorlage (hier also FormatDate) eine Duplikat mit Moduleinbindung im Vorlagen-NR platzieren, dann die Obervorlagen einzeln( "Infobox für Infobox") auf dieses Duplikat umstellen und jedesmal in den Artikeln nachschauen, ob was negatives passiert. Das stößt aber an die gleiche Zeitgrenze wie direktes Umstellen. ÅñŧóñŜûŝî (Ð) 20:56, 2. Jun. 2013 (CEST)

Doch genau das geht. Man erstellt eine Kopie einer bereits vorhandenen Vorlage/Modul und dann kann man sich die Auswirkungen auf bestehende Artikel anzeigen lassen, so als wäre die Originalvorlage verändert worden. Es müssen dabei weder Artikel noch Obervorlagen geändert werden; es reicht die Kopie der Untervorlage. --Mps、かみまみた^Disk. 21:55, 2. Jun. 2013 (CEST)

Hallo, soweit ich das sehe ist die Lua-Version von FormatDate aktiv und die Formatierungen von Vorlage:Internetquelle sind ok. Besteht denn derzeit noch ein Problem? --Cepheiden (Diskussion) 21:35, 2. Jun. 2013 (CEST)

• (BK) [...] Ein Testwiki nützt nichts [...]: Ja, nur hier sind die Vorlagen. Diese geben aber irgendwie das Datum an Vorlage:FormatDate weiter. Dies ist durch einen Blick in den Vorlagenquelltext und die Einbindungen nachvollziehbar. Damit lassen sich fast alle übergebenen Werte feststellen, wenn man genug Seiten überprüft.
• [...] Da wären bereits 100 Seiten eine ganze Stunde Arbeit [...]: es ist mir durchaus bewusst, dass sich das nicht in 5 Minuten erledigen lässt. Dies ist allerdings bei 10000 und mehr Einbindungen durchaus angebracht. Außerdem verlangt niemand, dass es du allein machst, du kannst auf dieser Seite gerne um Hilfe bitten. Oder du machst innerhalb einer Woche jeden Tag 25 Einbindungen, brauchst dazu 15 Minuten pro Tag, hast allerdings dann schon einige Einbindungen getestet. Niemand zwingt dich, ein Modul innerhalb von einer Stunde zu entwickeln und einzubauen.
• Thema Server: Bei 200000 Seiten ist es nicht unwahrscheinlich, dass ein nicht kleiner Teil zwischen deinen Edits aufgerufen wurde.
• Kein brauchbarer Debugger: Eine lokale MediaWiki-Installation sollte hierbei gute Dienste leisten.
• Ich weiß sehr wohl, dass man im Modulbereich testen muss. Wer zwingt dich allerdings, das Modul selbst zu bearbeiten? Lege eine neues, temporäres Modul an, teste dort und entsorge es dann per SLA. Es wird sich niemand beschweren.
• Duplikat umstellen und jedesmal in den Artikeln nachschauen, ob was negatives passiert. Das stößt aber an die gleiche Zeitgrenze wie direktes Umstellen.: Der Zeitaufwand ist der selbe, ja, aber der Aufschrei von den anderen Wikipedianern wird deutlich kleiner ausfallen (es wird nämlich keinen geben).

Fazit: Module auf einer temporären Seite erstellen, nicht überhastet produktiv nutzen, auf dieser Seite vorstellen und von anderen Benutzern überprüfen und testen lassen. Eine Vorlage, die jahrelang funktioniert hat, muss nicht innerhalb von 2 Tagen ersetzt werden. Dies wurde dir allerdings schon an anderer Stelle nahegelegt. --Steef ³⁸⁹ 21:37, 2. Jun. 2013 (CEST)

Lassen wir es so stehen. Das Modul scheint ja zu laufen. ÅñŧóñŜûŝî (Ð) 21:57, 2. Jun. 2013 (CEST)

• Das ist jetzt das dritte Mal innerhalb weniger Wochen, dass du funktionierende Vorlagen ohne eine akute Notwendigkeit zerschossen hat. Ich will kein viertes Mal mehr sehen. Die Vorlagen (Str*, MinMax, FormatDate) sind auf rund 150.000, 100.000, 70.000 Seiten eingebunden. Deine Aktionen haben etliche Benutzer über Stunden beschäftigt und es jeweils bis auf die FzW und in diverse Werkstätten geschafft.
• Selbstverständlich kann man vorher testen.
  1. Kategorie:Wikipedia:Lua/Modul/Testseite
     • Eine Testseite kann alle Typen erwarteter richtiger Parameter durchspielen, die zulässigen Varianten (Leerzeichen usw.) und die typischen Anwendungsfehler. Zumindest in diesen Fällen, die 99,999 % der Einbindungen abdecken, hat es ordnungsgemäß zu funktionieren.
     • Die Testseite kann man sich in der Seitenvorschau vor dem ersten und bei jedem Abspeichern des Moduls anzeigen lassen. Da muss es immer passen.
     • Auch noch nicht umgestellte Vorlagen kann man sich als Dummies vorab zeigen lassen. Beispiel: test/Vorlage:Max für Expr/test #Vorlagenprogrammierung.
  2. β-dewiki
     • Beispiel: Test-Suite für zukünftige Vorlage:Begriffsklärung
• Es kann immer mal eine unglückliche Konstellation wirrer Einbindungsparameter auftreten, die nicht vorhersehbar war. Dann sagt auch niemand etwas, und ein Bug kann jedem mal passieren. Die hier aufgetretenen Fehler wären jedoch sämtlich durch vorheriges Testen vermeidbar gewesen und hatten auf Tausenden von Seiten Bockmist ausgelöst.
• @Zeitbedarf: Es besteht keine Notwendigkeit, hastig gut funktionierende und hinreichende Vorlagen umzuschreiben. @Serverlast: Die Schnipsel der Vorlagensyntax schlummern im Cache und machen keine Arbeit. Serverbelastung entsteht durch jede Veränderung an einer Vorlage/Modul; vermeidbar ist dies, wenn alle paar Stunden alle gerade aufgebauten Seiten erneut zusammengestellt werden müssen.

--PerfektesChaos 22:49, 2. Jun. 2013 (CEST)

Deinen arroganten herablassenden Stil ("Ich will kein viertes Mal mehr sehen") kannst du dir schenken. Du bist hier nicht der große Lehrmeister! Dir selbst fehlt doch der Mut, die WP durch Umstellen vorhandener vielbenutzter Vorlagen zu verbessern, weil du da bei einem Fehler ebenfalls verbal Prügel kassieren könntest! Deshalb weichst du lieber auf Neuentwicklungen aus, bei denen niemand motzen kann weil eine vorhandene Vorlage mal für eine Stunde auf bestimmten Seiten nicht richtig funktioniert. Von der Freschheit, hinterher immer alles besser gewusst zu haben, obwohl das nur teilweise stimmen dürfte, mal ganz abgsehen.

Unverschämt ist auch deine Übertreibung ich hätte "etliche Benutzer über Stunden beschäftigt". Es gab ein paar Meldungen und ich war online und habe darauf reagiert. Das ist alles und hat gewiss nicht etliche Userstunden gekostet.

Es wird Zeit, dass wir hier mal alle Aspekte richtig zusammenstellen, was läuft:

1. Es gibt sehr wohl einen Bedarf, solche Vorlagen umzustellen. Jede Umstellung bewirkt, wenn sie mal richtig läuft und die Seiten aktualisiert sind, eine Verbesserung der Performance. Das wird durch Korrekturen bei der Umstellung nicht verhindert. Also sind solche Module notwendig.
2. Je häufiger eine Vorlage eingebunden ist, umso mehr fällt die Verbesserung der Performance ins Gewicht. Deshalb sind diese bevorzugt umzustellen.
3. Alle Besucher der WP profitieren von schnellerem Seitenaufbau. Bei den zigtausend Zugriffen pro Tag macht jede Sekunde schnellerer Aufbau zusammen mehrere Tage (teure!) Serverzeit aus!
4. Es bleibt also die Feststellung, dass das Endergebnis aller durch mich vorgenommenen Umstellungen eine Verbesserung der WP ist.

Außer mir gibt es hier niemand, der sich an diese Vorlagen bisher herangewagt hat (@PerfektesChaos: auch du - bisher - nicht). Das hat auch einen naheliegenden Grund: Es ist zwar jeder froh, wenn die WP schneller wird, aber noch größer ist die Lust, auf Benutzer, welche sich hier die Arbeit machen und für die WP Zeit investieren, herumzuhacken, wenn es (marginale) Fehler gibt, indem man aus einer Mücke einen Elefant macht ("und es jeweils bis auf die FzW und in diverse Werkstätten geschafft" - Was für eine Katastrophe). Ein paar Minuten erkennbar fehlende Datumsangaben auf einem Teil der WP-Seiten sind im Verhältnis zur gesamten WP marginal. Es ist für einige Benutzer hier wohl einfach zu geil, auf Leute, denen man ja nicht ins Gesicht schauen muss, draufzuhauen. Die aggressiven Reaktionen hier stehen also im krassen Missverhältnis zum positiven Endergebnis meiner Arbeit.

1. Wer direkt perfekte Umstellungen haben will, der soll der WMF gewerbliche Programmierer bezahlen.
2. Wer motzt, soll es selbst besser machen.

Zu den mir gemachten Vorschlägen:

1. Alle mir hier vorgestellten Testmöglichkeiten, Wikis u.Ä. können, soweit hier dargestellt, doch nur dazu genutzt werden, den Aufruf eines Moduls zu testen (Stichwort: Aufrufkombinationen durchgehen), eine parallel erstellte Testvorlage zu prüfen und Syntax- oder Logikfehler zu finden. Das Kernproblem ist aber, dass bei 500 Obervorlagen niemand genau weiß, welche abstrusen Aufrufe es z.T. gibt. Wenn beispielsweise eine Vorlage, welche FormatDate mit Buchstaben aufruft, obwohl diese ein ISO-Datum verlangt, nach der Umstellung nicht richtig funktioniert, dann ist das in erster Linie ein Fehler in dieser Vorlage, und nicht in FormatDate. Es ist doch unsinnig, dass die Vorlage FormatDate keine erhöhte Fehlertoleranz bekommen und nicht auf die Verarbeitung weiterer Formate erweitert werden kann, weil schlecht geschriebene Vorlagen sich darauf verlassen, dass sie nicht verbessert wird. Genau dies war nämlich die Ursache für das Problem mit Vorlage:Internetquelle: Es gab bei bestimmten unsinnigen Aufrufen eine Fehlermeldung weniger.
2. @PerfektesChaos: Du könntest deine unter 1 geäußerten Vorschläge nochmal genauer erklären. Evtl. meinst du etwas anderes als ich herausgelesen habe. ÅñŧóñŜûŝî (Ð) 01:06, 3. Jun. 2013 (CEST)

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 WP: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)

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)

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 WD:WPK#Unterkategorien von Kategorie:Wikipedia:Vorlagen-Parameterfehler eine Diskussion angefangen. --Leyo 15:49, 3. Sep. 2013 (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)

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)

Nutzung von subst bei Lua-Vorlagen

Hallo, ist es möglich Vorlagen, die Lua nutzen, substituierbar zu machen? --Cepheiden (Diskussion) 15:43, 12. Jan. 2014 (CET)

Ich habe interessiert mitgelesen und weiß, worauf du abzielst.

Jede Vorlage kann substituiert werden; es spielt keine Rolle, ob da drin ein #invoke steht.

Im Unterschied zu normalen Vorlagen wüsste Lua jedoch, dass es im Moment Gegenstand einer Substituierung ist, und könnte in diesem Fall COinS unterdrücken.

Bereits heute ginge aber Substituierung per C&P: Einfach den dargestellten Artikeltext mit perfekter Formatierung markieren, in den Quelltext einfügen, Werktitel und ggf. Sammelwerk kursiv machen, Weblinks usw. ggf. neu verlinken, fertig.

Das Gemurre von einem Dutzend Unzufriedener ist nicht repräsentativ, und Alternativen im Sinne einer Totalentfernung auch nicht MB-haltbar. Der Handvoll Maulender, die sich über „ihren“ Artikel aufregen, stehen Hunderte momentan interessiert Schweigender gegenüber, die die Vorlage einsetzen und nicht missen wollen. Irgendwo kommen die 104.000 Einbindungs-Artikel ja her.

Es gibt halt welche, die die Lit-Angaben mit Vorlage übersichtlicher finden, und insbesondere Ältere, die mit Vorlagen Schwierigkeiten haben. Dass die einen den anderen vorschreiben, wie es überall in der WP zu sein hat, wird es nicht geben. Problematisch wird es nur, wenn sie im selben Artikel aufeinander treffen. Und immer schwierig ist es, wenn bei einem von unterschiedlichen Autoren bearbeiteten Artikel vorhandene Literaturangaben auf Vorlage umgestellt werden; wenn man sie selbst erstmals einfügt, hat man für diese Einfügung das Recht des „Hauptautors“ und der andere müsste es dulden (es gibt auch welche, die den Artikel zum Privatbesitz erklären und per Editwar alles ihnen fremde rausrevertieren; gleichzeitig aber nach Respekt und Toleranz für ihre Privatmeinung brüllen, die für alle die Richtschnur zu sein habe). Insgesamt aber wohl auch viel Gemecker aus einem Gefühl allgemeiner Überforderung und Unzufriedenheit heraus; dauernd soll man irgendwas dazulernen, und nichts ist mehr so schön wie damals, 2005. Lautstarke Einzelgruppe ist aber keine MB-Mehrheit. Mit cite web und cite book können die Herrschaften ja schon mal anfangen.

LG --PerfektesChaos 16:49, 12. Jan. 2014 (CET)

Hallo,

ein einfaches {{subst:Literatur|Titel=Der Titel|Jahr=2009}} funktioniert aber auch mit der Lua-Version nicht. Muss in der Vorlage noch etwas umgeschrieben werden? --Cepheiden (Diskussion) 20:46, 14. Jan. 2014 (CET)

Muss ich mir anschauen; bisher war subst von Lit noch nie Design-Thema. Wird schon gehen. LG --PerfektesChaos 21:05, 14. Jan. 2014 (CET)

Kein Parameter wurde durchgereicht; der Pflichtparameter Titel also auch nicht.

Das liegt daran, dass der umgebende frame hier nicht an der gewohnten Stelle zur Verfügung steht; gehe ich mal gucken, wie man unter subst-Bedingungen an den rankommt.

Bis dann --PerfektesChaos 20:12, 15. Jan. 2014 (CET)

Hm, sieht gerade nicht so gut aus.

Die Parameterübernahme in beliebigen Mengen funktioniert zurzeit offenbar nur bei echter Vorlageneinbindung; nicht aber beim substen.

Es funktioniert aber auch nicht die Erkennung, dass eine Vorlage dabei ist, gesubstet zu werden; das war erst kürzlich eingeführt worden. Bug?

Da muss ich weiter experimentieren; kann etwas dauern.

Irgendwann mal sollte das dann auch mit subst genauso funktionieren wie bei regulärer Einbindung; ich ahne dunkel, dass das substen bislang nicht zur Unterstützung von Lua-Parameterlisten programmiert wurde.

Demnächst wieder mehr --PerfektesChaos 22:08, 16. Jan. 2014 (CET)

Gute Nachricht: Prinzipiell ist es möglich, eine komplette Lua-Vorlageneinbindung unter Verwendung aller Parameterwerte zu substen.

• Schlechte Nachrichten:
  • Es reicht kein einfaches subst, sondern beim momentanen Stand der MediaWiki-Programmierung muss ein spezieller Aufruf mitsamt dem subst per C&P eingefügt werden.
  • Es muss voraussichtlich ein spezielles Modul geschrieben werden, das diese Situation erkennt, mehrere umhüllende Ebenen generiert oder so und entweder über die klassische Vorlageneinbindung oder einen Seiteneingang das inhaltliche Modul aufruft. Vielleicht fällt mir dazu aber noch was Besseres ein.
  • Die Vorlagen-unterstützenden Module müssen erweitert werden; sie sollten ggf. einen speziellen Lua-Seiteneingang bekommen und einen Steuerparameter zur Unterdrückung von COinS usw. durchreichen.
• Vielleicht unterstützt ja MediaWiki irgendwann auch das substen von Parameter-Vorlagen.

Schönes Wochenende --PerfektesChaos 15:53, 18. Jan. 2014 (CET)

Hallo, danke für die Recherche. Schönes WE -- Cepheiden (Diskussion) 16:59, 18. Jan. 2014 (CET)

Substituierbarkeit in diesem Fall eingebaut.

• Schöner geht es beim momentanen Stand der Software nicht. Vielleicht in der Zukunft, wenn Lua und subst offiziell voneinander wissen.
• Die Herren werden sich aber trotzdem wundern. Zwar ist im Ergebnis das COins weggelassen, wodurch es halbwegs erträglich wird; aber sie bekommen es natürlich HTML-mäßig mit Qualität formatiert. Das heißt: Entities, schmale Leerzeichen, Umbruchschutz, <cite>. Wer das dann hübscher findet als die Vorlageneinbindung, soll selbst hinterherräumen.
• Substituierung kann auch zur Folge haben, dass die übergebenen Untervorlagen substituiert werden. Ob das wirklich eine schlaue Idee ist? Ich denke, die Vorlagensyntax ist da doch übersichtlicher, und die Geschichte mit der bösen, unverständlichen Lit-Vorlage höre ich seit sieben Jahren von unverändert immer denselben Leuten, die die Syntax längst begriffen haben und nur so tun, als ob das bei fünfstelligem Editcount für sie unbegreiflich sei.

Es wird so allmählich ein Performance-Problem geben. Irgendwie ist am verabredeten Konzept und am neutralen Datenkatalog vorbei allerlei eingeschleppt worden. Allmählich wird es zu Spaghetti-Code. Bitte dringend mit Hunderten von Einbindungen erproben, statt neue Formate einzubauen.

Schönen Sonntag --PerfektesChaos 13:26, 19. Jan. 2014 (CET)

• Danke für die Mühe, ob das dann besser ist müssen die anderen Nutzer entscheiden.
• Ich weiß was du meinst, aber der Datensatz war bei der Übertragung noch ausschließlich auf Vorlage:Literatur bezogen. Ziel war es aber von Anfang an ein Modul für alle Zitiervorlagen bereitzustellen. Dies umfasst auch Archiv* usw für die Vorlage:Internetquelle. Aber sei beruhigt weitere Parameter führe ich nicht ein ;-)

--Cepheiden (Diskussion) 17:29, 19. Jan. 2014 (CET)

Wunsch:Vorlage umbauen

Hallo, ich wurde darauf gestoßen, daß der poem-Tag nicht ausreicht, wenn jemand bei einem Gedicht z. B. jede 5. Zeile numerieren möchte. Ein anschauliches Beispiel findet sich in Der Archipelagus. Mir wurde gesagt, es gibt it:Modulo:Poem. Nur sollte es eben auf die hier übliche Variante angepaßt werden, als da erstens die Zeilennummer links steht und zweitens auf der gleichen Zeile, nicht eins darunter. Ist das machbar? Derzeit wird das Problem mit tonnenweise {{0}}en (bzw. etwas gerafft durch {{0|0000}}en) gelöst. --Tommes ^✉

Ein it:Module:Poem gibt es nicht.

• Ich sehe auch in deren Namensraum nichts, was einen passenden Namen hätte.
• Grundsätzlich können wir aus anderen Wikis Module importieren, die gut und wartbar und konfigurierbar geschrieben sind und sich dadurch besonders für den internationalen cross-Wiki-Einsatz eignen würden.
• Die Quelle müsstest du aber nochmal genauer suchen.

VG --PerfektesChaos 21:56, 21. Jan. 2014 (CET)

Es geht um s:it:Modulo:Poem, aber laut Autor "not intended for use, but to explore algorithms only" (bugzilla:13644) Grüße --se4598 / ? 22:27, 21. Jan. 2014 (CET)

Sortierung in Tabellen per Modul

Anlass: Liste der ältesten Menschen - wir haben 15 lebende und ~80 tote Menschen im Altersbereich 114-116, die Reihenfolge ändert sich also fast täglich. Haben wir ein Modul, das Tabellenzeilen sortieren kann? Idealerweise mit getrenntem Sortierschlüssel, wobei einfach alphabetisch sortieren auch geht, wenn man das Alter geeignet formatiert als Kommentar im Quelltext versteckt. Das würde Monow die Arbeit ersparen immer Tabellenzeilen rumzuschieben, man müsste die Tabelle nur aktualisieren wenn jemand stirbt oder neu hinzukommt. Jede Tabellenzeile wäre dann ein (oder zwei mit Sortkey) Parameter für das Modul. --mfb (Diskussion) 17:01, 29. Nov. 2014 (CET)

Das kann so grundsätzlich nicht gehen; ein Modul kann nur vorhandenen Quelltext darstellen, nicht den Quelltext umbauen.

• Einzig und allein die Übergabe der gesamten Tabelle an ein Modul ginge; dann müssten aber alle | escaped werden. Nicht empfehlenswert. Oder alle Einzelwerte (Zellen, entsprechend gruppiert, beliebig viele).

Mittel der Wahl für den Quelltext wäre JavaScript, ist auch schon häufiger gefragt worden.

• Man müsste als Autor einen Bereich im Bearbeitungsfeld markieren, und einen Knopf drücken, und bekäme diese Textzeilen sortiert; vielleicht noch mit Trick zur Erkennung einfach strukturierter Tabellenzeilen.

LG --PerfektesChaos 17:28, 29. Nov. 2014 (CET)

Hallo zusammen, es ist (finde ich) nicht schlimm, wenn das weiterhin manuell erledigt werden muss – soviel Arbeit ist es auch wieder nicht (und nebenbei jedesmal ein Anlass, die Hauptquelle auf Neuigkeiten zu überprüfen); ich bin auch nicht der einzige, der sich darum kümmert. @mfb: Ist die Liste denn irgendwo (beispielsweise in einer Wartungskategorie) negativ aufgefallen, oder bist Du zufällig darauf gestoßen (oder hast Du Dich vielleicht daran erinnert)? Danke jedenfalls für Dein Ansinnen, mir Arbeit zu ersparen! Viele Grüße --Monow (Diskussion) 20:45, 29. Nov. 2014 (CET)

Natürlich würde man die ganze Tabelle übergeben, Zeile für Zeile. Alle || durch {{!!}} ersetzen ist kein Ding.

Die Liste ist nicht negativ aufgefallen, aber ich bin beim englischen Äquivalent gerade am Diskutieren und eine automatische Sortierung könnte in vielen Sprachversionen die Wartung vereinfachen. --mfb (Diskussion) 22:05, 29. Nov. 2014 (CET)

Wäre das Modul denn in der Lage, beim Sortieren (wie bisher von uns praktiziert) zunächst nach dem Alter in Jahren und Tagen, erst dann nach den Lebenstagen und zuletzt nach dem früheren Erreichen des Alters zu differenzieren? Hiermit Benachrichtigung an Xquenda, der sehr viel mehr Arbeit als ich in die Liste gesteckt hat. Grüße --Monow (Diskussion) 22:24, 29. Nov. 2014 (CET)

@mfb:

Für sehr einfache, rechteckige, ungefärbte Tabellen mag das angehen.

In den bislang diskutierten Fällen gab es dann allerdings einen Wust von Extrawünschen, die die Zusatzparameter zu einer Schlangengrube machten; Beispiele:

• Für jede einzelne Zeile soll hinter |- eine einheitliche Stilvereinbarung kommen.
• Die Zellen in der dritten und fünften Spalte sollen aber rechtsbündig (oder hellblau unterlegt) dargestellt werden.
• Zur Sortierung ist der Ausdruck in der vierten Spalte zu nehmen.
• Die Sortierinformation ist ein Datum, eine Zahl.
• Und dann möchten wir aber auch noch Zeilen mit Zwischenüberschriften.
• Oder auf Liste der ältesten Menschen soll die 6., 8., 19. usw. Zeile lila unterlegt werden. Wie jetzt das vereinbaren???

Hinzu kommt die Pflichtangabe, wie viele Spalten es sein sollen.

• Davor kommt eine durch diese Spaltenzahl restlos teilbare Anzahl unbenannter Parameter.

Ich wäre nicht überzeugt von dem Konzept und präferiere die Sortierung direkt im Quelltext per JavaScript, was zum einen auf beliebige Textzeilen angewendet werden kann, beim Vorhandensein von |- auch umswitchen auf Tabellenzeilen.

• Davon hat der nächste Autor auch noch was.
• Wenn eine Weile in beliebiger Reihenfolge irgendwas in den Quelltext eingefügt wurde, findet keiner mehr, wo welche Zeile steht, um etwas zu berichtigen.
• Tabellenextraformatierung ist wumpe. Nur beim Aufruf des JavaScript-Helferleins ansagen, in welcher Spalte die Sortierung stehen möge. Fertig.

@Monow:

Dazu muss irgendwo in der Zeile ein Sortierschlüssel stehen.

LG --PerfektesChaos 22:32, 29. Nov. 2014 (CET)

Du denkst da viel zu kompliziert. Die gesamte Tabellenzeile ist ein einzelner Parameter für die Vorlage. Dieser fängt mit |- <!-- 04241 --> an wobei 4241 hier das Lebensalter in Tagen ist. Dahinter kann beliebiger Code stehen, die alphabetische Sortierung gibt die richtige Reihenfolge. Nur die Nummerierung muss ggf. überdacht werden. Es wird nicht in beliebiger Reihenfolge eingefügt - ich würde sinnigerweise die Toten nach erreichtem Alter sortieren und die noch lebenden darunter oder darüber nach Geburtsdatum sortiert. --mfb (Diskussion) 23:05, 29. Nov. 2014 (CET)

• „Die gesamte Tabellenzeile ist ein einzelner Parameter“ – das heißt, es geht das elende Pipe-Escaping wieder los.
• Meine unbeantwortete Frage von oben:
  • Oder auf Liste der ältesten Menschen soll die 6., 8., 19. usw. Zeile lila unterlegt werden. Wie jetzt das vereinbaren???
• Wenn überhaupt jemals jemand sowas programmiert, dann muss das für hinreichend viele Konstellationen anwendbar sein.
• Ein gesonderter Sortierschlüssel ist in der Regel unerwünscht weil redundant; er soll direkt den Daten entnommen werden, wo möglich.

LG --PerfektesChaos 23:23, 29. Nov. 2014 (CET)

Pipe-Escaping sehe ich nicht als Problem an.

Die Unterlegung ist für noch lebende Personen und die Farbe ist hinter dem "|-", also Teil des Zeilencodes und kein Problem.

Das Modul, wie ich es vorschlage, wäre für alle Tabellen nutzbar bei denen eine automatische Sortierung erwünscht ist.

Ja, Sortierschlüssel direkt aus Daten ist im Allgemeinen wünschenswert, hier aber unpraktisch. Die Redundanz kann vermieden werden, wenn man für die Tabellenzeile eine eigene Vorlage macht, das halte ich aber nicht für nötig. Redundant wäre nur das Geburtsdatum bzw. das erreichte Lebensalter, beides ändert sich nicht. --mfb (Diskussion) 23:32, 29. Nov. 2014 (CET)

Performance

Würde es sich lohnen kleine Funktion wie ifexists (für eine bestimmte Sache) als Modul umzusetzen? Beispielsweise⁉ ↔ User: Perhelion  13:26, 8. Feb. 2015 (CET)

Nein, das kann die Parserfunktion sofort direkt schneller beantworten, als wenn sie erst noch Lua-Code ggf. byte-kompilieren, laden und ausführen müsste.

Allgemein müsste (zumindest in dewiki) die Performance-Verbesserung schon signifikant sein, oder eine klassisch nicht erreichbare Funktionalität hergestellt werden, damit Lua eingesetzt würde. Die Zahl der Leute, die Lua-Code ändern könnten, ist wesentlich kleiner als die der potentiellen Vorlagenprogrammierer. Heißt: wenn Lua, dann kommen die Normalos nicht mehr dran; und wohl fast alle Admins stünden außen vor.

LG --PerfektesChaos 13:34, 8. Feb. 2015 (CET)

Ach* danke für dein informatives Resume. Habe umseitig den Abschnitt Performance-Messungen „Gerade gesehen: en:User:Dragons flight/Lua performance mit sehr interessanten Messungen, um wieviel schneller Lua sein kann. (Raymond)“ Deine Aussage könnte/sollte man doch irgendwie auf Hilfe Lua unterbringen!? PS: Ich habe gerade den Code der verlinkten Vorlage geändert, da würde mich jetzt so eine Performance-Messung auch interessieren! Ist bestimmt aufwendig oder ist da was zum Testen bekannt? ↔ User: Perhelion  14:43, 8. Feb. 2015 (CET)

• Naja, eine allgemeine Aussage steht da ja: Hilfe:Lua #Begrenzungen.
  • Performance-Messung ist relativ: Wenn man eine komplexe Vorlagenprogrammierung mit Untervorlagen und Parserfunktionen komplett ersetzen kann, bringt es was, sonst kaum. Ist aber schwer allgemein zu fassen.
• Du müsstest 400 Einbindungen hü oder hott abarbeiten und mittels Hilfe:Vorlagenbeschränkungen vergleichen.

LG --PerfektesChaos 15:34, 8. Feb. 2015 (CET)

Vorlagenverkleinerung

Hallo liebe Lua-Experten! Gemäß Punkt vier dieser Tipps möchte ich anfragen, ob sich mittels Lua die Vorlage:Charteintrag verkleinern ließe. Offenbar habe ich es bei der kürzlich erfolgten Fertigstellung (notwendige Anpassungen, wie ich betonen möchte) geschafft, deren Größe zu verdoppeln (20kB Vorlagenlogik, die zigfach eingebunden wird, wie Benutzer:Mfb es nannte). Kann sein, dass ich die Funktionalitäten ungünstig umgesetzt habe, aber meine Programmierkenntnisse gehen gegen Null. Nun würde mich interessieren, ob mit Lua das Problem wieder gelöst werden könnte, sprich: die Verwendung der Vorlage wieder unkritisch wird. Momentan ist sie noch nicht sehr verbreitet, das wird sich allerdings langfristig ändern, weshalb natürlich eine zeitnahe und effiziente Anpassung wünschenswert wäre. Mag sich hier jemand mit der Sache befassen? Verbindlichsten Dank und beste Grüße, XanonymusX (Diskussion) 11:40, 14. Mär. 2015 (CET)

Das mag sein, dass sich das mit Lua anders lösen ließe.

• Bei einem schnellen Drübergucken sehe ich allerdings nichts, was Lua zwingend angeraten sein ließe: Keine Berechnungen, keine Analysen von Zeichenketten, einfach nur klassische Formatierung.
• Das ist mit konventioneller Vorlagenprogrammierung zu leisten. Die hat den Vorteil, dass es dazu Hunderte von Programmierern gibt, die sich weiter darum kümmern könnten; zu Lua nur eine Handvoll, von denen wohl die meisten sehr gut ausgelastet sind.
• Hundertfach eingebunden und Performance-Problem sehe ich grad nicht; die Gesamt-Tabelle gibt es offenbar nur einmal pro Artikel, und dann kommen halt Zeilen pro Jahr; mit mehreren Titeln im Jahr. Naja, das machen wir von Denkmal über Bahnstrecke bis NSG routinemäßig.
  • Nur das Arbeiten mit unbegrenzt vielen Songs innerhalb eines Jahres wäre mit Lua offener zu gestalten; geht aber auch erträglich und schrankenlos ohne Lua, jedoch weniger elegant. Es wird auch kaum eine Band 150 Platten in einem Kalenderjahr herausgebracht haben.
• Hingegen habe ich mit der Konzeption dieser Vorlage mehrere massive Bauchsmerzen:
  • Es scheint mir auf den ersten Blick der gleiche Nutzinhalt zu sein, der auch in der bereits 7854× eingebundenen Vorlage:Infobox Chartplatzierungen kompakt und übersichtlich und flexibel dargestellt wird; bloß auf der zwanzigfachen Bildschirmfläche ausgewalzt.
  • Die angestrebte Vorlage ist statisch und sklavisch an genau fünf Länder gebunden; D-A-CH + UK/US.
    • Wenn das Herkunftsland des Songs nun aber Finnland oder Island oder Italien ist, dann tauchen im Unterschied zur bisherigen Infobox die Charts im Ursprungsland nicht auf. Irgendwie habe ich die Richtlinien für Chartplatzierungen anders im Hinterkopf, aber damit wenig zu tun.
    • Wenn das Stück oder der Interpret nun aber nur im deutschsprachigen Raum aktiv war/ist, und es nie oder nur einmal einen Übersee-Erfolg wie mit Nena oder Falco gab, dann stehen dort die nie oder fast nie genutzten Spalten herum. Oder Schweizer, die außerhalb der Schweiz nur selten wahrgenommen wurden?
  • Soll die beabsichtigte neue Tabellenvorlage die Einbindung der bestehenden Vorlage:Infobox Chartplatzierungen denn ersetzen, oder sollen beide gleichzeitig im Artikel vorkommen, oder was?
• Persönlich habe ich ungeachtet technisch-konzeptioneller Auskünfte den Eindruck, dass Verkaufszahlen wenig über die Qualität eines Kunstwerks aussagen. Acht Wochen auf Platz 1 oder in den Top Ten sind sicher enzyklopädisch relevant; aber von 26 Stücken in den USA eines mal für zwei Wochen auf Platz 67? Was sagt mir das? WP ist keine Datenbank. Vielleicht eher irgendwann mal auf Wikidata zu dokumentieren, nachdem dort Vandalismusschutz und Datenpflege geklärt wurden.

VG --PerfektesChaos 12:13, 14. Mär. 2015 (CET)

Danke für deine Stellungnahme! Allerdings hast du dich zuletzt mehr inhaltlich gegen die Wikipedia:Formatvorlage Charts ausgesprochen (oder zumindest Zweifel daran geäußert), wozu aber nicht hier, sondern wenn schon in der Wikipedia:Redaktion Musik der richtige Ort wäre. Ich darf dir aber verraten, dass das schon unzählige Male durchdiskutiert wurde und der Einsatz der Charttabelle im Musikbereich eigentlich unstrittig ist (und in praktisch jeder einzelnen der Kategorie:Diskografie zum Einsatz kommt, nur eben ohne Vorlage); somit etabliert die Vorlage nicht etwa etwas Neues. Und ja, letztlich ersetzt die Charttabelle die Infobox, aber auch das war schon bislang so vorgesehen. Die Fixierung auf DACHUKUS ist im Übrigen gar nicht so streng; auch so etwas ist kein Problem; vielleicht hast du die Funktionalitäten noch nicht so genau angeschaut?

Wenn du aber technisch keine Probleme siehst, bin ich beruhigt. Vielleicht magst du dich ja in dieser Diskussion dazu äußern? Andere sind der Meinung, dass die Vorlage so nicht verwendet werden kann. Übrigens: Einmal pro Seite stimmt so nicht, in den Diskografien wird zumindest nach Singles und Alben, häufig aber auch nach Studioalben, Livealben, EPs, … unterteilt; da kommt schon was zusammen. Grüße, XanonymusX (Diskussion) 12:27, 14. Mär. 2015 (CET)

Können wir die Diskussion bitte an einer Stelle führen und nicht an fünf? --mfb (Diskussion) 18:26, 14. Mär. 2015 (CET)

Ja, klar, das war auch der Plan (wobei ich meine Diskussionsseite eigentlich nicht für den geeigneten Ort halte). @PerfektesChaos: Also weiter wie verlinkt!   --XanonymusX (Diskussion) 13:20, 15. Mär. 2015 (CET)

Problem mit mw.language.fetchLanguageNames

Hallo. Beim Aktualisieren von Vorlagen in der Esperantowikipedia ist mir beim Testen aufgefallen, daß mw.language.fetchLanguageNames teilweise unbrauchbare, teilweise sogar englische, Texte zurückgibt. Wo wird das ganze überhaupt definiert; im https://translatewiki.net/, bei Meta oder woanders? Gruß --Tlustulimu (Diskussion) 09:27, 13. Apr. 2015 (CEST)

• Wo exakt die wirksame Definition steht, müsste ich erst suchen; ist aber erstmal egal.
  • Irgendwo in MW/* – darunter languages/Names.php und irgendwo anders.
  • translatewiki kann aber daran beteiligt sein; im Sinne von Upstream – Bots spielen translatewiki-Infos in die Software ein.
  • translatewiki:CLDR ist eine der wesentlichen Quellen.
• phab:T39704 beschäftigt sich bereits mit dieser Angelegenheit.
• Es gibt eine Matrix 555×555 Zuordnungen.
  • Von denen ist der englischsprachige und der Sprachname in der eigenen Sprache selbst recht zuverlässig besetzt.
  • Der Rest kommt anscheinend teils aus ISO-Datenbanken (ISO 639 / SIL), anderen heruntergeladenen Listen und der Sachkunde irgendwelcher muttersprachelnden Programmierer, die das im vergangenen Jahrzehnt bei den zu ihrer Zeit bekannten Definitionen reingeschrieben haben.
  • Das ist also etwas Glückssache. Wo nichts anderes bekannt ist, fällt die Matrix auf englisch zurück; insbesondere bei erst in den letzten Jahren neu entstandenen Wikipedien, die dann zwangsläufig etwas exotischer sind als die alteingesessenen Wikis, und die zwischenzeitlich noch keiner eingedeutscht hatte. Wenn ein neuer Sprachname hinzugefügt wird, bekommt er zunächst nur autochthon und englisch.
• Mit mw.language.fetchLanguageNames("eo","all") bekommst du eine table und kannst das leichter durchgehen; einfach eine Testseite mit einer wikitable daraus generieren.
• Wenn du eine maschinenlesbare Wiki-Tabelle aufmachst mit insgesamt 50 oder 100 besseren Bezeichnungen in eo, dsb, hsb, de – dann wird sich auch sicher der Weg finden lassen, an welcher Stelle das in die Wiki-Programmierung eingespeist werden kann. Für immer 2 oder 3 Sprachnamen einzeln anzudackeln ist weniger aussichtsreich.
• Es könnte sein, dass deine Einspeisung dem Common Locale Data Repository zugute käme; und damit allen Internetnutzern über die Wikis hinaus.
• Der genaue Weg der Cross-Übersetzungen in das Wiki ist mir auch nicht so ganz klar.

LG --PerfektesChaos 13:36, 13. Apr. 2015 (CEST)

Nachtrag:

• Deine Mühen um bessere Übersetzungen wären jedenfalls nicht umsonst.
• Ich könnte die Bibliothek Multilingual ergänzen um eine Funktion fetchLanguageName().
  • Dann würde man statt mw.language.fetchLanguageName() aufrufen: Multilingual.fetchLanguageName().
  • Das würde auf einem noch zu erstellenden Modul:Multilingual/names beruhen.
  • Modul:Multilingual/codes gibt es bereits in gleicher Art; ist zurzeit ohne Verwendung, weil später mw.language verfügbar wurde und jenes das vermutlich abdeckt.
  • Ein Modul:Multilingual/names wäre eine Tabelle, bei der ein Rückgabewert aussehen würde wie

    tNames.eo.en = "angle"

  • In Modul:Multilingual/names würden alle Namensübersetzungen festgehalten, bei denen du besser als mw.language bist.
  • Die neue Funktion Multilingual.fetchLanguageName() würde zuerst versuchen, in einem Modul:Multilingual/names etwas Besseres zu finden; wenn das nicht gelingt, dann erst den Wert von mw.language.fetchLanguageName() zurückgeben.
  • Damit wäre man schneller als der große Dienstweg.
• Der Inhalt dieses Untermoduls kann gleichzeitig als Anregung für translatewiki, MW und CLDR aufbereitet werden; auf dass die sich bessern mögen.
  • Wenn das soweit wäre, können die von oben dazugelernten Einträge wieder entfernt werden.

Gxis --PerfektesChaos 14:18, 13. Apr. 2015 (CEST)

@PerfektesChaos: Esperanto funktioniert mit der Funktion mw.language.fetchLanguageName() ziemlich bescheiden. Guck dir mal {{#invoke:Lingvonomo|list}} auf der Seite Vorlage expandieren auf der Esperantowikipedia an. Wie kann ich die ausgegebene Tabelle eventuell sortieren? Gruß --Tlustulimu (Diskussion) 15:04, 13. Apr. 2015 (CEST)

Aus Names.php kommen nur die Eigennamen, alle anderen Namen zu den Sprachen kommen aus CLDR (über mw:Extension:cldr). Eine eigene Tabelle für die Sprachennamen würde ich nicht aufmachen, auch wenn die Aktualisierung über CLDR etwas dauern mag, das sind OpenData die auch in anderen Bereichen einfließen, beispielsweise die ToolTipps bei "In anderen Sprachen" oder sogar in Programmiersprachen wie Java oder so. mw.language.fetchLanguageName nutzt die gleichen Daten wie die #language Parser-Funktion (эсперанто). Falls du also nur einen Wert für eine Sprache an einer Stelle brauchst, braucht es dafür kein Modul, sondern es geht einfacher. Ob es eine performante stabile Sortierroutine in lua gibt, kann ich nicht sagen, ein "sortable" hilft aber erstmal für die Übersicht ;-) Der Umherirrende 20:11, 13. Apr. 2015 (CEST)

@Tlu:

• Ich glaub dir ja gern, dass dir das nicht vollständig gefällt.
  • Lower Silesian wirst du sicher mit anderem Text überschrieben haben wollen.
• Ich hatte schon im Abschnitt drüber skizziert, wie du zu Übersetzungen nach deinem Geschmack kommen kannst.
• Das lokale Erstellen von Übersetzungsvorschlägen lohnt sich durchaus:
  • Es kann Jahre dauern, bis das von CLDR bis zu uns herunterkommt.
  • Irgendwer muss denen ja auch sagen, wie es richtig geht. Wenn das in den vergangenen Jahren noch nie verfeinert wurde, dann haben die da halt keine Esperanto-Muttersprachler, und auch keine CLDR-Sorben. Da kann man noch bis 2050 drauf warten.
  • Es sind Wiki-Sprachcodes dazwischen, die es in ISO/CLDR nicht gibt, und die wir sowieso selbst übersetzen müssen.
• Für das Sortieren gibt es zwei Möglichkeiten:
  1. class="wikitable sortable" und eine Überschrift, wie schon vom Umherirrenden vorgeschlagen.
  2. languages = table.sort(languages) müsste es heißen. (Es gibt das shared-Prinzip, bei dem ein sort die als Argument übergebene Struktur umbaut; aber Lua lässt das Argument unverändert und gibt eine sortierte table als unabhängige Kopie zurück.)
• prettytable ist nebenbei veraltet und zieht hierzuwiki mittlerweile Wartungsaktivitäten auf sich.
• In makeWrapper würde ich effizienter schreiben:

  local templateArgs = frame:getParent().args

  args.color = templateArgs.koloro or args.koloro or

  args.background = templateArgs.fono or

• Übrigens hatte ich ganz übersehen, dass es mit Wikipedia:Lua/Modul/Multilingual #getName sogar schon eine Funktion gibt, die bislang allerdings nur mw.language.fetchLanguageName() aufruft.
  • Der habe ich inzwischen in ein paar Zeilen das oben Beschriebene eingebaut; heute Abend mit Muster-Lokalerweiterung über WP:BETA verfügbar.

LG --PerfektesChaos 00:43, 14. Apr. 2015 (CEST)

@PerfektesChaos: languages = table.sort(languages) hat leider gar nicht funktioniert. Ich habe es aber geschafft, den Kram zu sortieren. :-) Der Kode sieht so aus:

-- list returns all language from the function mw.language.fetchLanguageNames in a wikitable
function _list (args)
	local r = '{| class="wikitable sortable"\n'
	r = r .. "|-\n" .. "! Kodo !! Nomo\n" -- head of the table
	local languages = mw.language.fetchLanguageNames("eo","all")
	local a = {}
	for n in pairs(languages) do a[#a + 1] = n end
	table.sort(a)
	for index, code in pairs(a) do
		local name = ""
		for c, n in pairs(languages) do
			if (c == code) then 
				name = n
				break
			end
		end
		r = r .. "|-\n" .. "| " .. code .. " || " .. name .. "\n"
	end
	r = r .. "|}\n"
	return r
end

Das Ergebnis der Sortierung ist in der Moduldokumentation schön zu sehen. Gruß --Tlustulimu (Diskussion) 11:34, 14. Apr. 2015 (CEST)

• Sortierung
  • Ah, mein Fehler, das war die Sortierung einer sequence gewesen, also einem Array vergleichbar.
  • Hier geht es ja um ein Objekt, und da läuft das etwas anders:
    1. Hilfsarray = sequence aus den Schlüsseln bilden
    2. Dieses Hilfsarray wie beschrieben sortieren
    3. Anschließend die Auswertung in der Reihe des Hilfsarrays vornehmen, und über dieses auf die Objektkomponenten vornehmen.
  • Bei einem Objekt ist es (in praktisch jeder Programmiersprache) beliebig, in welcher Reihenfolge die Komponenten zurückgegeben würden, wenn man eine Schleife über alle Komponenten bildet. Das darf das Systemfrei entscheiden, und richtet sich nach der Reservierung von Speicherplatzvorrat und freien internen Prozeduren.
  • Heute Abend müsste ich auf WP:BETA ein Modul:Multilingual/maintain haben, in dem als fetchLanguageNames auch so eine Tabelle auftaucht; da kannst du ja dann mal die unterschiedlichen Lösungsvarianten vergleichen.
• Vorhandene Definitionen:
  • CldrNames/CldrNamesDe.php – 606 Namen
    • als ich früher mal geguckt hatte, gab es rund 550 Codes
  • CldrNames/CldrNamesEo.php – 174 Namen
  • eo icu-project.org = CLDR – 153 Namen
    • eo kurz
  • Beachtenswert auch:
    • LocalNames/LocalNamesEn.php
• Man kann zum CLDR beitragen, aber das sollte die WMF als Ganzes tun und eher nicht jeder User einzeln.
  • Die WMF ist bereits Unicode Consortium Liaison Member und müsste daher auch schon einen Contributor Account zum CLDR haben; ihn ansonsten mit Leichtigkeit bekommen können.
  • Wenn MW nicht willig ist, das gebündelt zu übernehmen und zuvor in den Wikis einen Review der internen Vorschläge abzuhalten, dann kann man das natürlich auch als Einzelperson machen: Anmelden

LG --PerfektesChaos 11:52, 14. Apr. 2015 (CEST)

• Ich habe inzwischen die Programmierung für ein Pflegesystem fertig, aber noch nicht eingerichtet oder erprobt.
• Auf WP:BETA gibt es schon mal zwei Sprachenauflistungen
  • de
  • eo
• Du kannst dir da meinen Ansatz zur Sortierungsfrage angucken.
• Rest heute nacht oder morgen oder so.

LG --PerfektesChaos 22:37, 14. Apr. 2015 (CEST)

@Tlustulimu: Sodele – nunmehr sind scharf:

• Wikipedia:Lua/Modul/Multilingual/Upstream
  • Prozess zur Verbesserung von MediaWiki und CLDR
• fetchLanguageNames/eo
  • Übersichtsseite der bekannten Codes und momentan weltweit wirksamer Übersetzungen
• Modul:Multilingual/names
  • Änderungswünsche.
  • Wirken sofort auf die Funktion getName.
  • Schlagen gleichzeitig im Verbesserungsprozess auf.
  • Ich habe darin Abschnitte für eo, dsb, hsb eingetragen; du hattest ja berechtigten Grund zum Meckern.

LG --PerfektesChaos 13:17, 15. Apr. 2015 (CEST)

Linkfixe:

• Alle Einzelsprachen
• Wikipedia:Technik/MediaWiki/Sprachen/Synopsis

Enjoy --PerfektesChaos 18:13, 19. Apr. 2015 (CEST)

@OT: wikitable/Wiki-Syntax, da möchte ich (als Lua-Neuling) nur nebenbei etwas einwenden: ist es nicht so, dass diese nur für den Endnutzer ist!? Also eher für sehr technische Sachen wie Vorlagen der nativere HTML-Code zu verwenden ist (davon abgesehen, dass diese bei aufwendigeren Vorlagen übersichtlicher und zuweilen auch technisch erst machbar macht)!? ↔ User: Perhelion  20:53, 19. Apr. 2015 (CEST)

Ich verstehe die Frage nicht.

Wenn du die folgenden Code-Sequenzen von oben meinen solltest:

local r = '{| class="wikitable sortable"\n'
r = r .. "|-\n" .. "! Kodo !! Nomo\n" -- head of the table

und

r = r .. "|-\n" .. "| " .. code .. " || " .. name .. "\n"

schließlich

r = r .. "|}\n"

– was stört dich denn daran, und warum soll man das in HTML schreiben müssen?

Wikisyntax ist einn vereinfachter und kurzer Zugang zu HTML, und die gleichartige Tabelle lässt sich selbstverständlich auch mit HTML-Tags generieren; bloß wird der Quellcode schon allein für die ganzen end-tags deutlich länger.

Wikisyntax verstehen schließlich alle Beteiligten, und ein Lua-Modul macht auch nichts anderes als jede Vorlage, nämlich Wikitext in die einbindende Seite einzuspeisen. Und Vorlagen programmieren wir ebenfalls in Wikisyntax und nicht in HTML.

Erstaunt --PerfektesChaos 21:09, 19. Apr. 2015 (CEST)

@PerfektesChaos/WikiSyntax: das habe ich irgendwo mal unter Optimierung gelesen, da dadurch ein Parserdurchgang gespart wird (nachprüfen kann ich dies leider auch nicht ^^). Kurzer Code hat ja nicht direkt was mit optimal zu tun (vgl. jQuery). LG ↔ User: Perhelion  21:44, 19. Apr. 2015 (CEST)

Da sehe ich grad keine Ersparnis, denn das Ergebnis der Lua-Einbindung wird ganz normal und wie jede Vorlage auch in den Wikitext der obersten Seite eingefügt, und die geht hinterher grundsätzlich und zwangsläufig durch das Parsing, für die oberste Seite halt.

Was grundsätzlich nicht mehr läuft, das ist Vorlagenexpansion, bestimmte Parserfunktionen und Extension-Tags; die waren beim Aufruf von Lua schon expandiert und ausgewertet gewesen, und in der zusammengestellten Gesamtseite würden siewie nowiki stehenbleiben.

Aber Tabellensyntax und elementares Wiki-Markup wird jetzt erst beim Verarbeiten der Gesamteite erstmals angefasst und in HTML gewandelt. Der Paser geht also sowieso drüber, und wenn er jetzt Tags findet, dann muss er sie interpretieren und nachgucken, ob sie auch brav auf der Whitelist stehen. Tabellenwiki sind hingegen keine Tags und werden jetzt in Tags umgewandelt.

LG --PerfektesChaos 22:03, 19. Apr. 2015 (CEST)

@PerfektesChaos: Hat die Metaseite meta:Names of Wikimedia languages/de irgendetwas mit mw.language.fetchLanguageNames zu tun? Gruß --Tlustulimu (Diskussion) 18:29, 5. Mai 2015 (CEST)

@Tlustulimu: Das hat offenbar vor ein paar Wochen ein gewisser Millosh mit einem pywikibot zu generieren begonnen, und seitdem wird daran manuell weitergepflegt.

Ausgangsbasis war wohl mal dieselbe Struktur auf dem Wiki-Server.

Für die oben genannte Verbesserung der Ursprungsdatenbank auf CLDR ist das nicht geeignet, aber man kann Anregungen zur Komplettierung nachlesen.

Wenn jetzt die Upstream-Datenbanken weiterentwickelt werden oder auf Wikidata mehr enzyklopädische Artikel zu bestimmten Sprachen hinzukommen, dann wird das eklig.

Ich hoffe, du kommst gelegentlich dazu, deine ersten Korrekturen für falsches eo im Modul:Multilingual/names einzupflegen.

LG --PerfektesChaos 11:19, 7. Mai 2015 (CEST)

Modul für Bevölkerungsgrafik

Wäre es möglich, das hu:Modul:Népességdiagram nach de:wp zu übernehmen? Damit lassen sich ansehnliche Diagramme auf Basis von Wikidata-Daten bauen. 85.212.13.32 01:09, 14. Jun. 2015 (CEST)

Theoretisch schon, wobei man wohl noch an den Balkenbeschriftungen arbeiten muss (siehe hu:Cádiz#Népesség), z.B. vertikal verlaufend? --Mps、かみまみた^Disk. 09:20, 14. Jun. 2015 (CEST)

• Den Grafik-generierenden Teil könnte man sich abgucken.
• Die Versorgung mit Eingabedaten ist nix.
  • Es wird nicht so ganz klar, aber es scheint ausschließlich darauf gesetzt zu werden, dass alles und nur nach Jahren granuliert auf Wikidata vorhanden sei.
  • Wir haben aber auch eigene und vandalismusgeschützte Metadaten.
  • Für die Darstellung von enzyklopädischen Informationen aus Wikidata wird ein Herkunftsnachweis gefordert; das wird hier nicht überprüft und bedenkenlos alles angezeigt, was irgendwer auf dem Planeten mal als angeblichen Zahlenwert hineingeschrieben hatte.
• Die Formatierung der Ausgabe müsste, wie Mps schon andeutete, besser konfigurierbar gemacht werden.
  • Beschriftungsformat, Gestaltung, Konfiguration gibt es nicht.
  • Es müsste schon ansatzweise an Hilfe:Zeitleisten heranreichen.
• Völlig undokumentiert; im gegenwärtigen Zustand unbrauchbar.
• Strukturell müsste zwischen Gewinnung der Anwendungsdaten, ihrer Ausgabe und der optischen Gestaltung sauberer getrennt und dies flexibler gemacht werden.

LG --PerfektesChaos 10:59, 14. Jun. 2015 (CEST)

Hmm, ok. Also meine Intention mit dem Modul wäre sowieso, nicht Einwohnerzahlen zu visualisieren, sondern Elo-Zahlen, z. B. so. Da wären einige der aufgezählten Probleme nicht vorhanden (Quellenlage, Granulierung der Intervalle). Könnte man für dieses Einsatzgebiet ein Modul bauen? 85.212.62.122 12:44, 14. Jun. 2015 (CEST)

Im Prinzip ja, aber erwarte es nicht für 2015. Vor dir stehen die Wahlergebnisse in der Schlange.

Was dir vorschwebt, steht in Kategorie:Vorlage:Zeitleiste.

• Das wäre also schon in den letzten Jahren gegangen.
• Zeitleiste ist aber ein halbtoter Gaul, in den keine Arbeit mehr investiert werden soll; sondern der irgendwann in allen Ehren zu beerdigen wäre.
• Die Aufgabe lautet jetzt, eine kluge und zukunftsfähige Struktur zu finden, die:
  • In einem Zweig Balkendiagramme als Nachfolger der Zeitleiste generiert,
  • flexibel in der Versorgung mit Eingabedaten aller Genauigkeit (Monate, Jahre, Tage, Quartale) ist
    • (ich kann mir JSON-Formate in einem Vorlagenparameter vorstellen)
    • und auch aus den gleichen Eingabedaten Teilmengen nimmt (nur eine Säule pro Jahr, nur eine Säule pro Jahrzehnt) sowie
  • flexibel in der Präsentation (Farben, Dichte, hoch/quer, Beschriftungen) ist.
    • Bei Wahlergebnissen gibt es eine Säule pro Partei mit dem aktuellen Ergebnis, aber dahinter noch eine zweite mit dem von der letzten Wahl.

Da sollte man auch international gucken, was für intelligente oder auch unbrauchbare Konzepte auf den Tisch kommen. Die ungarische Lösung war ein Gehversuch; wir selbst sind aber sehr mager mit konzeptionell fähigen Lua-Programmierern ausgestattet und brauchen noch einige Zeit. Eilt aber nicht.

LG --PerfektesChaos 13:07, 14. Jun. 2015 (CEST)

Naja, du beschreibst hier die eierlegende Wollmilchsau. Was ich brauche ist aber lediglich ein Modul, das die Einträge eines Properties in Wikidata als XY-Werte einliest und daraus ein Balken- oder Punktdiagramm generiert. 85.212.22.136 09:16, 15. Jun. 2015 (CEST)

• Es wird aber kein Modul „lediglich Elo-Zahlen“ für die Schachspieler, ein weiteres für Badminton-Spieler, ein Modul für die Geschwindigkeit von Diesellokomotiven, eines für die Länge sibirischer Flüsse und 734 weitere geben.
• Es wird für Grafiken dauerhaft nur ein einziges Modul als Bibliothek geben, wohl mit mehreren spezifischen internen Untermodulen, optimal ein einziges Paket weltweit über alle Wikis zentral gewartet und weiterentwickelt.
• Es gibt bei uns potenziell Tausend Autoren, die mit rudimentären Kenntnissen der Vorlagenprogrammierung ihre fachspezifischen Vorlagen selbst schreiben und pflegen können, und notfalls Hilfe aus der Vorlagenwerksttatt bekämen. Es gibt hier perspektivisch ein Dutzend Leutchen, vielleicht auch zwei, die Lua einigermaßen robust programmieren könnten, darunter zurzeit null Admins. Es ist ein Holzweg zu glauben, dass die Artikelinhalte verfügbar bleiben, wenn man dauernd bei fremden Leuten anklopfen muss, und eine Handvoll Benutzer dann rund um die Uhr damit beschäftigt werden, fremde Probleme zu lösen. Und das wird auch nicht dadurch zu lösen sein, dass WMDE aus der Außenwelt für ein halbes Jahr IT-Experten anheuert, die das überhaupt erstmal IT-fachlich können müssten, aber von Wikis und Community und Artikelinhalten null Ahnung haben.
• Die Schachspieler waren ja schon mit uralter klassischer Vorlagenprogrammierung für ihre Infobox überfordert und hatten kürzlich auf mich zurückgegriffen. Wenn ihr euch jetzt noch auf Lua-Module kapriziert, kommt ihr alleine überhaupt nicht mehr mit euren Artikeln zurecht.
• Dein Balkendiagramm kannst du dir selbst seit Jahren mit Zeitleisten bauen; wiewohl dies veraltet ist.
• Nebenbei bemerkt eignen sich Balkendiagramme nur für in der Regel gleichabständige Angaben, etwa pro Jahrzehnt oder bei meist regelmäßigen Wahlperioden oder ohne eine Zeitachse; bei unregelmäßigen Zeitabständen sind Punktdiagramme besser. Ein intelligent konzipiertes Modul kann mit einem winzigen Edit zwischen beiden Darstellungsarten umschalten.

VG --PerfektesChaos 10:47, 15. Jun. 2015 (CEST)

Das Balkendiagramm kann ich mir zwar mit Vorlagenprogrammierung bauen, aber damit komm ich doch nicht an Daten auf Wikdata ran, oder? Diese Daten müssten dann lokal im Artikel stehen, oder? 85.212.44.46 17:29, 15. Jun. 2015 (CEST)

Vorlagen, Artikel, Module - alle können auf die gleiche Art und Weise auf Wikidata zugreifen (spielt keine Rolle wo das geschieht). --mfb (Diskussion) 17:35, 15. Jun. 2015 (CEST)

Ui, seht mal Vorlage:Einwohnerdiagramm von Benutzer:Hgzh an :-) --Atlasowa (Diskussion) 22:19, 21. Jun. 2015 (CEST)

Die zur Anzeige dieser Grafik verwendete Erweiterung wurde dauerhaft deaktiviert. Wir arbeiten aktuell daran, diese und weitere betroffene Grafiken auf ein neues Format umzustellen. (Mehr dazu)

Einwohnerentwicklung von

@Atlasowa: Es gibt jetzt in dieser Vorlage die experimentelle Möglichkeit, Einwohnerdiagramme aus Wikidata-Einwohnerzahlen zu generieren (siehe nebenstehendes Beispiel für Zürich). Ist erst mal nur ein Versuch und noch nicht ausgereift, daher bitte nicht in Artikeln einbauen. Der Parameter ist auch bewusst noch nicht dokumentiert. -- hgzh 19:57, 23. Sep. 2015 (CEST)

@hgzh sehr sehr schick! Und ermöglicht eine schön kompakte Darstellung! Zu der grundsätzlichen wikidata/Wartungsfrage: Wäre es möglich, die Diagrammdaten in bspw. Vorlage:Einwohnerdiagramm/Daten/Dresden vorläufig mit wikidata abzugleichen? In dem Sinne dass die Einwohnerzahlen auf wikidata hochgeladen werden (aber nicht in dewiki Artikeln verwendet werden) und beobachtet werden kann, ob die Einwohnerzahlen in der Diagrammdaten-Vorlage mit diesen übereinstimmen - oder ob wikidata vandaliert wird, ob solcher wikidata-vandalismus revertiert wird, oder ob wikidata vielleicht eher noch irgendwas verbessert. Damit hätte man erstmals eine Möglichkeit, die Datenzuverlässigkeit/qualität/risiken bei wikidata einzuschätzen (was ja laut dem MB ein entscheidender Faktor ist). --Atlasowa (Diskussion) 10:55, 25. Sep. 2015 (CEST)

Vorlage:GraphChart: Flexiblere Eingabeformate für Zeiten

Übertragen von der Vorlagenwerkstatt. --mfb (Diskussion) 13:30, 1. Aug. 2015 (CEST)

---

Könnte die Vorlage so erweitert werden, dass sie als x-Werte auch Datumsangaben wie 01-04-2014 oder 01.04.2014 frisst und verdauen kann? 85.212.60.110 20:04, 30. Jun. 2015 (CEST)

• Das zweite Format: Theoretisch ja.
• Das erste ist mit 01-04-2014 kein zulässiges Format, weil auch nicht eindeutig (US-Amerikaner schreiben das gelegentlich und meinen mm-dd-yyyy und Briten schreiben es auch und meinen damit dd-mm-yyyy).
• Es gibt aber ein massives Performance-Problem, wenn erstmal für jede einzelne von Hunderten Stützstellen ein Datumsinterpretierer aufgerufen werden soll, der zu erraten versucht, welches Datum gemeint ist. Wenn schon Grafikdaten vorbereitet werden, dann sollen sie gefälligst sauber kodiert werden.

LG --PerfektesChaos 16:54, 1. Aug. 2015 (CEST)

Das steht bei mir auf der Liste: entweder werde ich das explizit als weitere zulässige Ordinalskala einbauen (wenn dann aber im alleinigen Format JJJJ-MM-TT, aus von PerfektesChaos genanntem Grund) oder implizit als Teil meines Vorhabens Nominalskalen zu unterstützen. --Mps、かみまみた^Disk. 11:58, 2. Aug. 2015 (CEST)

For-Schleifen in Lua-Vorlage

Aus der Vorlagenwerkstatt gekürzt übertragen

Hallo! Ich brauche eine for-Schleife in einer Vorlage mit Inkrement. Ich möchte mit der Vorlage nämlich variable Tabellen erstellen, variable Zeilen- (z) und Spaltenanzahl (s), z. B. sowas:

{{VarTab|z=5|s=3
|a1|a2|a3
|b1|b2|b3
|c1|c2|c3
|d1|d2|d3
|e1|e2|e3
}}

bei den Parameterangaben z=5 für 5 Zeilen und s=3 für 3 Spalten. Bei Änderungen dieser Parameter sollte sich die Tabelle ebenfalls entsprechend ändern. Ich denke, das geht am einfachsten mit zwei for-Schleifen für Spalte und Zeile. Weiß da jemand was? Danke sehr, – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 14:35, 11. Sep. 2015 (CEST)

Geht nur mit Lua. Die Vorlagensyntax kann keine For-Schleifen. Man kann zwar mit sehr vielen if und switches arbeiten, aber das wird schnell Unfug. --mfb (Diskussion) 15:01, 11. Sep. 2015 (CEST)

Dazu habe ich in der Syntax das gefunden: for Name `=´ exp `,´ exp [`,´ exp] do block end

also dann so?

var i = 1
{{{!}}
for x = 1 , {{{z}}} do
  {{{!-}}}
  for y = 1 , {{{s}}} do
    {{!!}} {{{i}}}
    var i = i + 1
  end
end
{{!}}}

Das funktioniert aber nicht. Wie kriegt man das am besten hin? Grüße und vielen Dank, – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 16:16, 11. Sep. 2015 (CEST)

Lua ist eine Programmiersprache, keine Auszeichnungssprache, wenn du irgendwelchen Text hinschreibst (wie {{{!-}}}) wird versucht das als Programmbefehl zu interpretieren. Code sieht eher aus wie hier oder (als Anwendungsbeispiel) hier. Ich habe mich mit Lua nicht näher beschäftigt, aber irgendwo sollten sich geeignete Beispiele finden lassen. --mfb (Diskussion) 16:35, 11. Sep. 2015 (CEST)

Ja okay, aber für for-Schleifen brauche ich ja nun eine Lua-Vorlage. In meinem Beispiel oben habe ich 17 Parameterwerte {{{s}}}, {{{z}}} und {{{1}}} bis {{{15}}}. Wie kann ich mit diesen Werten in der Lua-Vorlage dann arbeiten? Hier brauche ich wohl eine Schnittstelle zwischen Auszeichnungssprache und Programmiersprache, oder eine andere Möglichkeit, die Parameterwerte in das Lua-Script zu übergeben bzw. vice versa. – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 17:18, 11. Sep. 2015 (CEST)

ach ich hab's wohl gerade gesehen, ich müsste ein Modul mit den for-Schleifen schreiben und das wird dann per #invoke wiederum in eine Vorlage eingebunden, oder? Hab ich's jetzt? – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 17:32, 11. Sep. 2015 (CEST)

Ja. Du müsstest dich schon recht intensiv mit Hilfe:Lua und Hilfe:Lua/Modul im Wiki beschäftigen. LG --PerfektesChaos 17:35, 11. Sep. 2015 (CEST)

Jupp, danke für die Predigt Vorlage:Smiley/Wartung/;)  Eventuell könnte ich aber dennoch mit der einen oder anderen Frage kommen, denn einiges erschließt sich mir selbst durch Manual und Ausprobieren nicht immer. Auf dem zweiten Blick sieht mir die Syntax recht einfach und gut nachvollziehbar aus. Ich werde studieren und probieren, aber vielen Dank mal für die ersten ein zwei Schritte – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 18:53, 11. Sep. 2015 (CEST)

Text aus Listen generieren

Hallo zusammen. Ich bräuchte eine Textfunktion, die es ermöglicht, aus mehreren Listen (d.h. Strings mit einem Trennzeichen, z.B. Semikolon) einen Text nach vorgegebenem Muster zu generieren. Dabei sollte das vorgegebene Muster für jeden Satz gleichwertiger Listen-Elemente angewendet werden (fällt mir schwer, das besser auszudrücken). Im Prinzip kommt es dem, was die Funktion zip des Modul:Text kann, schon ziemlich nahe. Ich mache das mal an einem Beispiel klar:

• Es gebe zwei Listen, eine enthält a;b;c, die andere x;y;z. Sollte aber, falls einfach möglich, mit einer unendlichen Anzahl Listen funktionieren.
• Und es gebe das Muster: blubb_%s_blubb_%s_blubb
• Das Ergebnis wäre dann: blubb_a_blubb_x_blubbblubb_b_blubb_y_blubbblubb_c_blubb_z_blubb.

Nach meiner unmaßgeblichen Vorstellung müsste das durch eine Abwandlung der zip-Funktion recht leicht zu erstellen sein. Oder gibt es soetwas sogar schon und ich habe es bloß nicht gefunden? Vielen Dank schonmal, Grüße, Yellowcard (D.) 01:39, 2. Okt. 2015 (CEST)

Hallo, ich habe eine solche Funktion mit dem Namen listToFormat heute erstellt und dem Modul:Text hinzugefügt.

• Es können unendlich viele Listen in Form von Strings als unbenannte Parameter übergeben werden.
• Der Separator muss einheitlich sein, standardmäßig ist es ein Semikolon, er kann durch den Parameter sep aber spezifiziert werden.
• Das Format wird über den Parameter format angegeben, wobei ein %s als jeweilige Variable verwendet wird. Dies entspricht nicht der Funktionalität der Funktionalität aus C, sondern ist eine konstante Variable. Flags oder andere Angaben funktionieren genausowenig wie andere conversion-Buchstaben außer s. Es wird also lediglich das nächste Auftreten des Strings %s gesucht und durch das nächste Listenelement ersetzt.

Ich bitte um Code-Review (ist die erste Lua-Funktion, die ich jemals erstellt habe) und Anmerkungen. Falls das in Ordnung geht, übernehme ich in den nächsten Tagen die Dokumentation auf WP:Lua/Modul/Text. Grüße, Yellowcard (D.) 13:54, 5. Okt. 2015 (CEST)

• Willkommen im Club!
• Syntaktisch offenkundig okay.
  • Ich würde grundsätzlich alle local am Beginn des jeweiligen Blockes zusammenziehen; das hat die gleiche Wirkung, gibt aber einen schnelleren Überblick über alle mit Auswirkung auf diesen Block (=function) deklarierten Symbole.
• Es empfiehlt sich, in den jeweilgen Seitenbereichen die Funktionen alphabetisch nach Name zu sortieren.
• Auf Wikipedia:Lua/Modul/Text/Test kannst du deinen Review und die Anwendungsbeispiele schon gleich selbst erledigen; interessant sind hier auch die Grenzfälle, etwa nicht oder leer oder nur durch Leerzeichen oder ungültig angegebene Parameter und den resultierenden Effekt.

LG --PerfektesChaos 14:23, 5. Okt. 2015 (CEST)

Alles klar, Wikipedia:Lua/Modul/Text/Test sieht sinnvoll aus. Habe aber offenbar schon einen Grenzfall erwischt, bei dem die Funktion versagt (muss es noch weiter testen). Ich melde mich ggf. nochmal. Grüße, Yellowcard (D.) 14:33, 5. Okt. 2015 (CEST)

Ich habe zunächst mal ein anderes Problem. Ich möchte als Parameter format= eine Vorlage übergeben, die dann mit den jeweiligen Listeninhalten dupliziert und gefüllt wird. Beispiel:

Vorlage: {{Testvorlage|1=foo|2=bar}}

Ich möchte die Parameter 1 und 2 mit Listen füllen. Da würde ich Folgendes aufrufen:

{{#invoke:Text|listToFormat|format={{Testvorlage|1=%s|2=%s}}|1=liste1|2=liste2}}

Das Problem sind die Pipes. Wenn ich das so aufrufe wie oben, schlägt der Aufruf natürlich fehl, weil das Pipe im format-Parameter vermuten lässt, dass anschließend der nächste Parameter für den Lua-Aufruf folgt. Mit {{!}} anstelle der Pipes geht es auch nicht; dann funktioniert zwar der Lua-Funktionsaufruf, die Vorlage wird aber schließlich nicht ausgewertet. Gibt es hier irgendwie Abhilfe? Zum Beispiel würde helfen, den String des format-Parameters als solchen zu kennzeichnen oder die Pipes irgendwie anders zu escapen, sodass sie anschließend trotzdem noch bei der Vorlagenauswertung als Pipes erkannt werden ... Danke, Yellowcard (D.) 19:06, 5. Okt. 2015 (CEST)

Ist das ein Testergebnis? Das sollte immer von innen nach außen ausgewertet werden. Lua sieht also für den Parameter "format" die Rückgabe der Vorlage:Testvorlage. --mfb (Diskussion) 22:03, 5. Okt. 2015 (CEST)

Okay, das verändert die Sachlage, macht sie aber nicht unbedingt besser. Gibt es eine Möglichkeit, die entscheidenden Zeichen (also wohl geschweifte Klammern und Pipes) zu escapen, dass ich diesen String als uninterpretierten Parameter an Lua übergeben kann? Yellowcard (D.) 00:33, 6. Okt. 2015 (CEST)

Ja, eben mit {{!}}. Dann sieht Lua eine Pipe als Teil des Parameterwertes. Auch <nowiki> um die betroffenen Zeichen herum sollte klappen. --mfb (Diskussion) 11:00, 6. Okt. 2015 (CEST)

@Mfb: Wenn ich {{!}} verwende, verhält sich der Lua-Funktionsaufruf zwar korrekt und erstellt auch die Zeichenketten wie erwartet, nur wird dann der entstehende String – eigentlich korrekte Vorlageneinbindungen – nicht mehr ausgewertet. Falls es Deine Zeit zulässt, würde ich mich freuen, wenn Du mal hier schauen könntest (feel free to edit). Danke und Gruß, Yellowcard (D.) 12:17, 6. Okt. 2015 (CEST)

"Lua-Modul gibt String in Form von Vorlageneinbindungen zurück, Parser soll Vorlagen-Einbindungen anschließend interpretieren" - das geht nicht. Der Parser liest erst die Struktur ein und ersetzt dann von innen nach außen (wobei in den Vorlagen wiederum das gleiche gemacht wird). Was von Vorlagen oder Modulen zurückgegeben wird, ist immer Text (kann noch Textauszeichnung haben, aber keine vorlagenrelevanten Sonderzeichen). Natürlich kann man in Lua den String wieder parsen und dann an Vorlagen als Argumente übergeben, aber das klingt unsinnig.

Das wird zur X-Y-Frage. Was ist dein eigentliches Ziel? --mfb (Diskussion) 16:18, 6. Okt. 2015 (CEST)

Ich möchte im Wesentlichen Daten aus Wikidata auslesen und in Tabellenform darstellen. Dabei ist die Zahl der Daten, die der Eigenschaft sind, im Vorhinein unbekannt (es handelt es im konkreten Fall um Vereinsstationen von Fußballspielern, aber da sind vielfältige Anwendungen denkbar). Für jeden Datensatz (einzelne Vereinsstation) wird die Vorlage {{Team-Station}} aufgerufen. Fällt Dir da eine andere Vorgehensweise ein? Gruß, Yellowcard (D.) 16:23, 6. Okt. 2015 (CEST)

Sofern man die Logik mit der Ausleihe irgendwie anders lösen kann, könnte man die Tabellensyntax direkt in den String setzen, sodass das Lua-Modul den fertigen Code liefert. Ich weiß nicht, ob Lua eine spezielle Funktion hat um Vorlagenaufrufe auszulösen. Wenn ja, wäre das wohl die sinnvollste Lösung. --mfb (Diskussion) 18:27, 6. Okt. 2015 (CEST)

• Lua-Parameter verhalten sich genauso wie Vorlagenparameter; nur gibt es zusätzliche Möglichkeiten zur Unterscheidung von leeren Werten und nicht angegebenen Werten.
• Es gibt eine eigentlich schon wieder weiterentwickelte Version http://de.wikipedia.beta.wmflabs.org/wiki/Modul:Text zum Ausprobieren, statt hier auf der Produktivversion.
• Dort gibt es auch http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Lua/Modul/Text/Test zum Entwickeln auch der Robustheit bei Grenzfällen.
• Schließlich gibt es http://de.wikipedia.beta.wmflabs.org/wiki/Modul:Text/test zum Auswerten von Testbeispielen.
• Die grundsätzliche Idee ist eigentlich, dass auf BETA bis zum Ende entwickelt wird, und hinterher das Modul auf die echte WP kopiert wird und danach auch die erweiterte Testseite auf die echte WP. Damit werden die echten Artikel nicht gefährdet und die Serverlast wird minimiert.
• Wenn das irgendwas mit Vorlagen und Parametern wird, dann ist das nichts mehr für die allgemeinverwendbare Bibliothek Text zu universell und kontextunabhängig einsetzbaren elementaren Textfunktionen. Das muss dann in einem eigenen Modul gelöst werden.

LG --PerfektesChaos 22:39, 6. Okt. 2015 (CEST)

Die Unterscheidung gibt es auch bei normalen Vorlagen: {{{Name}}} ist sichtbar wenn der Parameter nicht definiert wurde, und leer wenn er als leer definiert wurde. --mfb (Diskussion) 00:06, 7. Okt. 2015 (CEST)

Vielen Dank für eure Infos und Hilfestellung.

@PerfektesChaos: Die Funktion listToFormat im Modul:Text ist produktiv und robust. Das Problem liegt an anderer Stelle. Das Herumspielen in meinem Benutzernamensraum mit dem Modul sollte die Server nicht merklich belasten. Die Diskussion hier hat aber gezeigt, dass ich mit dem generalistisch gehaltenen Modul:Text wider Erwarten nicht zum Ziel komme und ein (dann sehr spezifisches) Modul wohl die einzige Lösung ist. Gibt es da irgendwelche Spezifikationen zur Benennung und zum Ort? Ich werde die Entwicklung mal auf meine Agenda schreiben und hoffe, dass ich es hinbekomme; ich werde das dann im verlinkten Beta-Wiki machen. Grüße, Yellowcard (D.) 00:49, 7. Okt. 2015 (CEST)

Wenn es eine Art Vorlage oder Pseudovorlage wird, dann würde sich Modul:Vorlage: anbieten, die dann wie eine Vorlage dokumentiert werden kann und deren Vorlagenprogrammierung aus einer Zeile plus Doku-Aufruf bestünde: Vorlage:Phab und die Namensgebung der Vorlage dann selbsterklärend nach Zweck und Funktion wie dort üblich.

--PerfektesChaos 01:03, 7. Okt. 2015 (CEST)

Das hilft weiter, danke! Grüße, Yellowcard (D.) 01:08, 7. Okt. 2015 (CEST)

Noch’n Tipp: Im Modul:Vorlage:MachTabellenDingens benötigst du statt frame.args wie bislang frame:getParent().args – das sind die Parameter der umhüllenden Vorlageneinbindung. Allgemein: Hilfe:Lua/Modul im Wiki mit diversen Infos. LG --PerfektesChaos 01:21, 7. Okt. 2015 (CEST)

Alles klar, nochmals danke. Ich werde mich da mit einigen Aspekten beschäftigen müssen, idealerweise binde ich ja die Module Modul:Wikidata und Modul:Text in das neue Modul ein und nutze deren Funktionen. Das muss ich mir im Detail aber nochmal anschauen; die Hilfeseiten sind aber sehr angenehm und hilfreich, finde ich. Es wird sicherlich den ein oder anderen Aspekt geben, an dem ich stecken bleiben werde; dann melde ich mich hier. Vorlage:Smiley/Wartung/;)  Grüße, Yellowcard (D.) 01:26, 7. Okt. 2015 (CEST)

Unbegrenzte Zeilenanzahl

Hallo, da das Problem immer häufiger auftritt, wollte ich nochmal nachfragen, ob jemand helfen kann! PerfektesChaos hatte mal in Aussicht gestellt, dass man mittels Lua die Vorlage:Charteintrag auf eine unbegrenzte Anzahl von Zeilen erweitern könnte (bis jetzt ist die Grenze bei sechs). Ich hatte anfangs keine Anwendungsfälle gesehen, inzwischen sind mir aber schon zwei (von sicher vielen weiteren) begegnet, nämlich in Justin Bieber/Diskografie#Singles und in Vasco Rossi/Diskografie#Singles (Auswahl), wo jeweils einmal elf Zeilen benötigt würden (hab ich bei letzterem vorerst mit zwei getrennten Einträgen umgesetzt, was aber eine unlogische Dopplung von „2011“ zur Folge hat). In diesem Sinne halte ich eine dahingehende Verbesserung der Vorlage mittels Lua für sinnvoll und wohl auch notwendig. Gilt analog auch für Vorlage:Charteintrag2. Gruß--XanonymusX (Diskussion) 11:31, 7. Okt. 2015 (CEST)