Wikiup:Lua/Werkstatt/Archiv/2020

aus Wikipedia, der freien Enzyklopädie

Wie übergebe ich eine Zeichenkette in #invoke als Funktionsparameter?

In Benutzer:Karl432/Tabellentest#Lua-Test sehe ich nur "Lua-Fehler in Modul:Unicodezeichen, Zeile 4: attempt to concatenate local 'codepunktpar' (a table value)" (das Modul Unicodezeichen ist mein erster Lua-Versuch).
Aufruf: {{#invoke: Unicodezeichen | Darstellung | 0190 | }}.
Aufruf mit Stringquotes: {{#invoke: Unicodezeichen | Darstellung | '0190' | }} funktioniert genausowenig. Angabe eines Wertes für den zweiten Parameter ändert auch nichs.
(Was das Ganze werden soll, sieht man hier: Vorlagenentwurf Benutzer:Karl432/ZzeileV2/Doku, vorletzter Parameter „zeichentyp“.)
Ich bin der offensichtlich irrigen Annahme, dass man Parameter mit einer C-ähnlichen Syntax übergibt, und dass man die Typen in der Funktionsdeklaration nicht angibt. Die in Hilfe:Lua angegebenen Weblinks haben mich nicht erhellt.
Was habe ich überlesen? -- Karl432 (Diskussion) 02:17, 12. Mär. 2020 (CET)

Die Parameter müssen ohne Apostrophe und Leerzeichen übergeben werden. --FriedhelmW (Diskussion) 13:40, 12. Mär. 2020 (CET)
@Karl432: Arbeite dich mal durch die relevanten Teile von Hilfe:Lua/Modul im Wiki durch.
Lua im Wiki ist trickreicher als es im ersten Moment wirkt.
Experimentier mal schön, das übt.
Ich werde mich zu gegebener Zeit einschalten und Hausaufgaben zur effektiveren produktiven Verwendung zwecks Umsetzung übermitteln.
VG --PerfektesChaos 14:14, 12. Mär. 2020 (CET)
Vielen Dank für alle Hinweise, jetzt funktioniert bei mir alles! -- Karl432 (Diskussion) 16:00, 12. Mär. 2020 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Karl432 (Diskussion) 16:00, 12. Mär. 2020 (CET)

Undokumentiertes Vorlagenlimit

Hallo! Nachdem ich weder auf Hilfe:Vorlagenbeschränkungen, noch auf dem englischen Pendant fündig geworden bin, ärgere ich mich gerade über die zwei offenbar völlig undokumentierten Vorlagenlimits (aus dem PP-Report) Unstrip recursion depth [20] und Unstrip post‐expand size [5000000 Bytes]. Hintergrund: Max Martin/Auszeichnungen für Musikverkäufe löst offenbar mit einer unstrip post-expand size von 5956095/5000000 die (rote) Kategorie:Seiten, auf denen die Unstrip-Größengrenze überschritten ist aus. Doppeltes Problem:

  1. Die Kategorie müsste blau sein, Kategorie:Wikipedia:Seiten, auf denen die Unstrip-Größengrenze überschritten ist lauten (Translatewiki) und irgendwo korrekt verlinkt und kategorisiert sein.
  2. Ich habe nicht die geringste Ahnung (ein bisschen Phabricator-Surfen war auch nicht erhellend), wo ich ansetzen soll, um den zugrundeliegenden Fehler im Modul:Musikcharts zu beheben (die Vorlage:AfM-Tabelle ist nun echt nicht so komplex).

Wer weiß Rat? Gruß--XanonymusX (Diskussion) 00:41, 5. Jan. 2020 (CET)

Eine Stringsuche auf Mediawiki, Scribunto per eigener und Google-Suche (auch im Web) ergab keine weiterführende Treffer. Muss was ganz geheimes sein ein SmileysymbolVorlage:Smiley/Wartung/:(  ÅñŧóñŜûŝî (Ð) 18:53, 5. Jan. 2020 (CET)
Einzig in phab:T189416 kommt das Limit vor. Die „Erklärungen“ lauten:
  1. „unstrip-size-warning is shown when the maximum expansion size for nested parser extension tags is exceeded. "Unstrip" refers to the internal function of the parser, called 'unstrip', which recursively puts the output of parser functions in the place of the parser function call.“ (zit. AKlapper)
  2. „There is a limit on the amount of content that can be generated by transclusions (the "unstrip post‐expand size"), and this limit is 5 000 000 bytes.“ (zit. Matmarex)
Ich kann damit leider nichts anfangen. Wo soll der Unterschied zur Post‐expand include size sein? --XanonymusX (Diskussion) 19:48, 5. Jan. 2020 (CET)
@AKlapper (WMF): Kannst du das vielleicht erklären? Wäre sehr hilfreich. Gruß--XanonymusX (Diskussion) 19:54, 5. Jan. 2020 (CET)
Die Beschränkung ist auch recht neu und wurde vermutlich erst mit Parsoid/PHP im Dezember 2019 produktiv eingeführt.
  • Glückwunsch, du hast den ersten Treffer.
Da das Byte-Limit von 5 MB recht ehrfurchtgebietend ist, gehe ich von einem endlosen Selbstaufruf aus.
Die von dir genannte Vokabel recursion ist im konkreten Fall bei 0/20 nicht betroffen, ginge jedoch in die gleiche Richtung.
Die Vokabel unstrip signalisiert, dass ein MediaWiki-Tag expandiert wurde. So lautet der Wiki-Programmierer-Jargon seit anderthalb Jahrzehnten.
  • Das mag beispielsweise <ref> sein.
  • Das könnte direkt als Wikisyntax, oder auch programmatisch als {{#tag:ref}} bzw. in Lua frame:extensionTag() verwendet worden sein.
  • Bei der Auflösung dieses Tag wurde ein erneutes aufzulösendes Tag vorgefunden; weil endlos mutmaßlich wieder derselbe Code, der erneut ein aufzulösendes Tag produziert, und wieder, und wieder.
  • Ein frame:preprocess() eines Wikitextes, der MediaWiki-Tags enthielte, hätte die analoge Wirkung.
Die einzigen MediaWiki-Tags, in denen Autoren normalerweise Inhalte darstellen würden, wären <ref> + <poem> + <pre> – würde in einem <ref> ein Gedicht als <poem> vorkommen und in diesem Schreibmaschinenschrift per <pre>, dann wäre die Verschachtelungstiefe 3. Ein <ref> darf aber kein weiteres <ref> enthalten, ein <pre> ist ein nowiki-Bereich und kann überhaupt keine expandierbare Wikisyntax mehr enthalten. Es muss schon mit {{#tag:}} gearbeitet werden, um mehr als 3 Ebenen zu erreichen.
Mit 5 MB liegt das Limit großzügig über der Beschränkung des Limits für die Nutzgröße des HTML-Inhaltsbereichs von 2 MB und kann nicht zu einem anzeigbaren HTML-Dokument führen, sondern hätte sich wohl beliebig weiter vergrößert, wenn es nicht abgebrochen worden wäre, wobei dafür bereits 6 MB generiert wurden.
Weil der größte Verbraucher, der in eine solche Richtung weist, preprocess 340 ms 20.0% ist, würde ich empfehlen, die Suche bei einem frame:preprocess() zu beginnen, wobei dies einen Wikitext mit allen implizit darin enthaltenen MediaWiki-Tags verarbeitet.
Die Verwendung von frame:preprocess() ist bekanntermaßen recht ressourcenintensiv und sollte auf absolut nicht anders zu lösende und möglichst stark auf den unvermeidlichen Kern reduzierte Fragmente von Wikitext beschränkt bleiben.
VG --PerfektesChaos 20:32, 5. Jan. 2020 (CET)
Puh, es muss in der Tat etwas mit dem Zusammentreffen von preprocess und dem TemplateStyles-Tag in Modul:Musikcharts/certifications zu tun haben (zurzeit in jeder Vorlage:AfM, die über 900 Mal auf der Seite vorkommt)! Damit kann ich arbeiten, danke! Gruß--XanonymusX (Diskussion) 20:49, 5. Jan. 2020 (CET)
@XanonymusX: Ich koennte es nicht erklaeren und haette jetzt wahrscheinlich an https://discourse-mediawiki.wmflabs.org/ oder so verwiesen. Herzlichen Dank an PerfektesChaos fuers Verstehen und Beantworten. --AKlapper (WMF) (Diskussion) 20:59, 5. Jan. 2020 (CET)
@Antonsusi: Huh? Nix Geheimes: https://codesearch.wmflabs.org/core/?q=%22Unstrip%20post-expand%20size%22&i=nope&files=&repos= und https://codesearch.wmflabs.org/core/?q=%22Unstrip%20recursion%20depth%22&i=nope&files=&repos= --AKlapper (WMF) (Diskussion) 20:59, 5. Jan. 2020 (CET)
Aha. Jetzt brauchen wir noch jemand, der dieses neue Fehler-Feature, an geeigneter Stelle in den Hilfe-Namensraum integriert. Ich würde vorschlagen, alle Begrenzungen, egal ob Extension, Vorlage, Seite, Lua etc. auf einer zentralen Seite zu sammeln. Zurzeit sind sie auf mehrere Seiten verteilt. Außerdem muss die softare die von PC heute erstellte Wartungskategorie - Kategorie:Wikipedia:Seite mit Überschreitung eines Unstrip-Limits setzen. ÅñŧóñŜûŝî (Ð) 21:18, 5. Jan. 2020 (CET)
Yay, die Seite hab ich jetzt auf 936.792 Bytes Unstrip post-expand size runterbekommen. Der Fall ist also gelöst, danke für die Mithilfe! Die Vorlagenbeschränkungen sind grundsätzlich ja schon ganz gut auf Hilfe:Vorlagenbeschränkungen zusammengefasst, da wäre das hier noch zu ergänzen. Die Kategorie funktioniert, vorhin war der Max Martin noch kurz drin. Gruß--XanonymusX (Diskussion) 21:42, 5. Jan. 2020 (CET)
Ach nee. Da haben wir eine schöne funkelnagelneue Wartungskat für zwei (!) Systemnachrichten und dann ist sie leer. Echt traurig. ein SmileysymbolVorlage:Smiley/Wartung/;-)  ÅñŧóñŜûŝî (Ð) 23:24, 5. Jan. 2020 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:54, 4. Jun. 2021 (CEST)

Categorymembers

Hallo! Ich bin auf der Suche nach einer Funktion, die analog zur API-Funktion categorymembers bei Angabe eines Kategoriennamens die in diese Kategorie eingebundenen Seiten auflistet und, idealerweise, ihre Inhalte untereinander aufführt (ggf. unter Verwendung von onlyinclude, um nur bestimmte Teile der Seiten anzuzeigen). Für das Mergen von Seiten habe ich das Modul PageUtil gefunden, für die Ausgabe der Kategorien ist CatUtil jedoch anscheinend nicht geeignet, da es, wie PagesInCategory, nur die Seiten zählt und keine Liste der Elemente zurückgibt. Gibt es solch ein Modul noch nicht?

Ich habe auch nach Alternativen geschaut und mw:Help:DPL (MediaWiki.org zur Extension) gefunden, das jedoch auf dewiki nicht aktiviert ist. Zudem würde mir ja eine Bullet-Liste nicht reichen, vermutlich auch nicht, wenn man diese Ausgabe über die allgemeine Vorlagenprogrammierung bearbeitete. Bei letzterer habe ich mich ebenfalls umgeschaut, das gewünschte Ergebnis zu produzieren, habe jedoch keine Möglichkeit gefunden. Fällt euch noch etwas ein? Besten Dank für den Rat! :-) Liebe Grüße, —Martin (WMDE) (Disk.) 18:01, 24. Jul. 2020 (CEST)

Das geht grundsätzlich mit keinerlei Funktion, weil die Einträge in einer Kategorie dem Wikitext nicht bekannt sind.
Das Maximum sind die in Hilfe:Spezialseiten/Liste mit X bei „Einbindbar“ versehenen Spezialseiten, aber auch dann erfolgt die Anzeige der Elemente nur in der zusammengestellten Seite – die aufgezählten Einträge selbst sind aus dem Wikitext heraus nicht zugänglich.
Wenn man sich überlegt, was für Konsequenzen sowas für den Cache der Wikitext-Seite hätte, wird auch schnell klar, warum sich da keiner drauf einlassen würde.
VG --PerfektesChaos 18:17, 24. Jul. 2020 (CEST)
Hm, okay, alles klar. Aber mit API-Abfragen, Skript und Bot wäre es natürlich schon möglich, da nicht live aktualisiert würde. Dann denke ich mal in diese Richtung weiter, danke. Grüße, —Martin (WMDE) (Disk.) 17:05, 27. Jul. 2020 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:52, 4. Jun. 2021 (CEST)

Ist das mit Lua besser zu machen

Hallo, es betrifft ein Modul in den commons, aber ich kann doch auch hier um einen Rat fragen? Ich will versuchen, verständlich zu formulieren um was es geht. Es geht um das, was ich topics nannte. Es handelt sich um ca. 40 codes, zu denen in möglichst allen Sprachen die entsprechenden Begriffe su finden sind. Seit längerem habe ich damit ein Problem: die zuständige Vorlage Igen/top ist inzwischen mehr als 500K mal transkludiert, so dass ich sehr zögere, eigentlich erforderliche Editierungen, Erweiterungen und Änderungen vorzunehmen. Ich suche nach einer Abhilfe, dass nicht bei jedem Edit die Server belastet werden.
Es heisst, dass Implementierungen in Lua wesentlich schneller ablaufen können. Vielleicht wäre eine Lösung mit mw.loadData am besten, besser als die Codierung in einer Vorlagensprache, aber davon weiss ich bisher noch gar nichts.

Deshalb habe ich bisher nur Variationen in Vorlagensprache untersucht. Als bisherige Idee denke ich, es wäre schon gut, wenn nicht jede kleine Editierung auf alles wirkt, weil nicht alle topics in allen Sprachen in dieser einen Vorlage eingetragen sind.

Die eine Möglichkeit, zu jeder Sprache eine Untervorlage mit jeweils allen topics zu erzeugen, scheint weniger gut; jede Arbeit an der englischen Version schlägt wieder voll durch. Da scheint die andere Möglichkeit sinnvoller, in Untervorlagen nach topic (statt nach Sprache) zu verzweigen, in denen die einzelnen Sprachübersetzungen stehen; bei den meisten Änderungen (zusätzliche Übersetzungen) bleibt das ohne Server-Auswirkungen. Nur wenn ein neuer topic-code eingeführt würde, belastet das die Hauptvorlage. Ich würde vielleicht auch die (recht stabile) englische Entschlüsselung in der Hauptvorlage lassen, und nur bei anderen Sprachen die jeweilige topic-Untervorlage ansteuern, in der alle Übersetzungen stehen.

Es könnte also im Prinzip so ähnlich aussehen: 

{{#switch:{{lc:{{{1|}}}}}
|c={{#if:{{int:lang}}|en|{{W|coat of arms}}|{{Igen/top_c}}}}
|d={{#if:{{int:lang}}|en|{{W|diagram}}     |{{Igen/top_d}}}}
|e={{#if:{{int:lang}}|en|{{W|emblem}}      |{{Igen/top_e}}}}
....

(statt {{int:lang}} würde der Parameter {{{lang}}} verwendet, der von der aufrufenden Vorlage mitgegeben wird; es gibt auch noch einen zweiten Parameter, der den Fall des Nichtfindens regelt.)

In Igen/top_c etc. sind alle Übersetzungen, mit dem nicht-verlinkten englischen Begriff als default.

Es ist noch nicht alles fertig überlegt, und vielleicht hat wer bessere Ideen; deshalb wende ich mich an dieses Forum der Lua-Experten. -- sarang♥사랑 13:04, 5. Aug. 2020 (CEST)

Bevor ich dazu im Detail Stellung nehmen würde, stellen sich mir zwei Rückfragen, da ich noch niemals was mit der inhaltlichen Angelegenheit zu tun hatte:
  1. Wie oft pro Seite kann es zu einer Einbindung kommen? Gesichert immer nur höchstens einmal, oder beliebig oft, und gebräuchlich schon mal mehr- und vielfach?
  2. Kann das ausschließlich in Commons oder auch in anderen Wikis verwendet werden?
VG --PerfektesChaos 14:21, 5. Aug. 2020 (CEST)
Es kann auch mehrmals eingebunden sein, zwar meist nur einmal, aber mit abnehmender Häufigkeit auch mehrmals; meist genau einmal, und dass es 20- bis 30mal gebraucht wird ist derart selten dass es sich kaum zu berücksichtigen lohnt - da habe ich auch keine Optimierungen überlegt. Ich schätze dass es in 98 bis 99 % der Fälle bei einem Mal bleibt.
Theoretisch könnte es überall verwendet werden, aber es wird nur mit Dateien in Commons eingesetzt, die natürlich überall angezeigt werden können.
Mir geht es um die Serverbelastung, wenn an dieser so stark frequentierten Vorlage die notwendige Wartung vorgenommen wird. Es fehlen noch eine grosse Menge Übersetzungen, und wenn einige Sprachkundige sich daranmachen so dass eine Zeitlang immer wieder neue Versionen dazukommen, sollte das bereits mit einer weniger Serverlast-kritischen Vorlage geschehen.
Wenn da als Nebenerscheinung eine elegante Lösung auch noch schneller läuft, umso besser − deswegen frage ich hier; doch ist IMHO das Zeitverhalten bei der Einbindung kein so wesentliches Kriterium. Danke -- sarang♥사랑 15:14, 5. Aug. 2020 (CEST)

Es gibt hier keine eindeutige Antwort.

  1. Nachteile – warum besser nicht nach Lua?
    • Personal: Erfahrungsgemäß gibt es in den Projekten 100× mehr Benutzer, die Vorlagensyntax beherrschen würden, als solche die Lua können.
      • Heißt: Je mehr auf Lua umgestellt ist, desto kleiner ist die Zahl der Menschen, die das noch warten und pflegen könnten, und diese kleine Gruppe ist auf ewig dafür verantwortlich, immer mehr Lua-Module zu pflegen, die ihre Vorgänger mal programmiert hatten, und diese weiterhin am Laufen zu halten und neue Anforderungen einzupflegen.
    • Migrationsaufwand
      • Es muss eine Neuprogrammierung von irgendwem geschrieben werden.
      • Hat erstmal lausig viele Parameter und Parameterwerte, die man zunächst alle verinnerlichen muss. Wahrscheinlich ist es dann, wenn man das System erstmal durchschaut hätte, gar nicht soooo schwierig, aber da muss man erstmal hinkommen.
      • Damit sowas überhaupt verantwortet werden kann, muss auf WP:BETA erstmal eine Simulation aufgebaut werden, in der alle vorstellbaren Situationen durchgespielt werden und schlauerweise automatisiert das Ergebnis gemäß bisheriger und neuer Programmierung miteinander verglichen wird.
    • If it is not broken, don’t fix it.
      • Alte Weisheit der Programmierer, hat sich bewährt.
      • Wenn es kein tatsächlich beobachtetes echtes Problem gibt, sollte man eine robust funktionierende Software nicht anfassen und sich lieber freuen, dass alles klappt.
  2. Vorteile – was spräche für Lua?
    • Übersichtlichere und hier vermutlich tatsächlich effizientere Programmierung.
      • Es ist nicht jede Umstellung auf Lua automatisch effizienter, weil der Einsatz eines Moduls erstmal Eintrittsgeld kostet, das dann zunächst mit Überschuss wieder erwirtschaftet werden muss, aber hier wäre es durch die vielen switch mit Sicherheit gegeben.
      • Die Programmierung in Lua ließe sich robuster und pflegeleichter für Erweiterungen gestalten.
    • Performance
      • Würde sich aber nur auszahlen, wenn vielfach oder auf sehr großen Seiten eingebunden.
      • Weil hier eher auf sehr kleinen Dateibeschreibungsseiten und dann eher ein einziges Mal eingebunden, hat die einzelne Dateibeschreibungsseite wenig davon.
      • In riesigen Artikeln oder Galerien mit Dutzenden von Einbindungen wäre das ein anderes Spiel. Die Dateibeschreibungsseiten stoßen sicher deswegen nicht an Limits.
    • Server-Belastung nach Änderung
      • Tja, eine schlaue Lua-Lösung könnte dem schon einen Gefallen tun, weil das Einpflegen einzelner Änderungen sich dann nicht sofort auf jede Seite auswirken und sie veralten lassen würde.
      • Gemeint wäre commons:Data:TemplateData/Soft redirect.tab, das teilweise 70 Übersetzungen kennt, aber wo eine Veränderung den Cache der einbindenden Seiten erstmal nicht beeinflussen würde.
      • Problem ist umgekehrt: Wenn nicht jede Veränderung sofort alle einbindenden Seiten (halbe Million) beeinflusst, dann bekommt die momentan gelesene das erst mit, wenn sie sowieso aus dem Cache verschwunden war und neu aufgebaut oder manuell gepurged wird.
      • Wenn es die einzelne Seite aber gar nicht interessiert, ob zu irgendeinem anderen Dateityp in irgendeiner Sprache die der momentane Leser ohnehin nicht wissen will kürzlich eine Änderung vorgenommen wurde, dann ist das auch egal.
    • Andere Projekte
      • Die eben skizzierte Internationalisierung braucht nur ein einziges Mal zentral gepflegt zu werden, wirkt sich aber auf alle WMF-Wikis aus.
      • Das hier lebt auch davon; genauso frr:Vorlage:Softredirect aber auch al dente

VG --PerfektesChaos 16:47, 5. Aug. 2020 (CEST)

Ach, und da war ja noch was ganz am Anfang:
  • „aber ich kann doch auch hier um einen Rat fragen?“
In allen Werkstätten hier, LWS, Vorlagen-WS, Technik-WS kann jeder um Rat fragen; muss noch nicht mal zu einem WMF-Wiki sein. Deutsch- oder englischsprachig wäre willkommen, ansonsten gäbe es ein Problem.
Ob jemand antworten mag, ist ja Sache der Werkstattmitarbeiter. Fragen darf jeder; wenn keiner Lust hat einem Fremdprojekt zu antworten dann halt nicht.
Commons ist aber etwas, wovon wir hier seit vielen Jahren massiv profitieren, und soweit es nur Lua-technisch ist und nicht um inhaltliche Prozeduren der Commons-Insider geht antworten wir hier halt deutschsprachig.
Generell werden alle deutschsprachigen Anfragen zu WMF-Wikis in unseren Werkstätten aber gleichrangig behandelt werden.
VG --PerfektesChaos 16:57, 5. Aug. 2020 (CEST)
Danke für die ausführlichen Antworten! Zwar habe ich es so ähnlich vermutet, nachdem ich darüber gelesen habe, aber nun habe ich es bestätigt dass in diesem einen Fall Lua zwar möglich ist, aber die ohnehin sehr einfache Struktur (fast ohne Logik) kaum übersichtlicher machen kann, und auch im Zeiterhalten eher keine Vorteile bringen wird.
Du hast zu sehr vielen Aspekten und sehr ausführlich Stellung bezogen; manches habe ich gewusst, einiges vermutet und den Rest weiss ich nun auch − oder weiss nun, wo ich nachsehen kann.
Also werde ich Lua vor allem in den Fällen einsetzen, wo es Dinge erleichtert oder überhaupt erst ermöglicht, und anderes mit konventioneller Vorlagensyntax angehen. Ich habe bereits komplexe und umfangreiche Anforderungen mit Lua erfolgreich in den Griff bekommen, das hier angesprochene Problem liegt ganz anders - nahezu keine Logik, aber grosses Datenaufkommen und vor allem die Rücksicht auf die Serverauslastung.
Also werde ich die Aufteilung in ca. 40 subtemplates weiter projektieren, und auch den mir von dir genannten Links ein Augenmerk schenken. Vielen Dank dass du dir solche Mühe gegeben hast, jedenfalls hilft es mir abzuwägen was sinnvoll ist. Und etwas zu diskutieren ist allemal besser als es einsam zu entscheiden -- sarang♥사랑 17:53, 5. Aug. 2020 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:52, 4. Jun. 2021 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Lua/Werkstatt/Archiv/2020&oldid=223332386“