Wikipedia Diskussion:Lua

Dies ist eine Diskussionsseite zu Gestaltungsfragen der Vorderseite und zur allgemeinen Organisation im Projekt.

Bei konkreten Detailfragen zu einer Programmierung und Implementierungswünschen bitte die

• Lua-Werkstatt

aufsuchen.

Dokumentation/1: Platzierung der Seiten

• Die inhaltlichen Doku-Seiten und die Disku sollten unter WP:Lua/Modul/ konzentriert werden.
  • Der nächste Kandidat ist en:Special:PrefixIndex/Module:String/ – die wir brav importieren sollten, sobald sie stabil ist, und die ein /doc und /tests und /sandbox mitbringt; wenn die englischsprachige /doc fertig ist, wollen wir auch noch eine /Doku haben. Das geht im Modul-Namensraum nicht.
• Vorlage:ModuleDoc kann dahingehend erweitert werden, dass sie bei NAMESPACENUMBER 828 ein (ggf. mehrsprachiges) {{Soft redirect}} anzeigt und in den aus dem PAGENAME abgeleiteten Pfad von WP:Lua/Modul führt.
  • Die Disku zu Modul:XYZ sollte immer ein unmittelbares #redirect sein auf WD:Lua/Modul/XYZ.
  • Die Hauptfassung der Doku ist bei uns deutschsprachig. Um die Links nicht zu lang werden zu lassen, sollte diese synonym mit /de sein; letztere mag bei Bedarf eine Weiterleitung sein, während die eigentliche Inhaltsseite WP:Lua/Modul/XYZ ist.
  • Enthält die Doku WP:Lua/Modul/XYZ die Vorlage:ModuleDoc, dann kennt diese ihren Pfad und kann automatisch zu Modul:XYZ zurückverlinken. Auch das wissen NAMESPACENUMBER, PAGENAME und #titleparts.

--PerfektesChaos 10:02, 19. Mär. 2013 (CET)

• String zu importieren ist keine schlechte Idee. Allerdings ohne den sandbox-Part. Dieses System mit der Sandbox-Unterseite ist irgendwie nicht zielführend. Dort ist der Ansatz über die Vorlagenspielwiese deutlich geeigneter. Wobei es da vorteilhaft wäre, wenn man den Codeeditor und die Konsole auf einfache Art und Weise irgendwie auch im Benutzernamensraum aktivieren könnte. Wenn man letzteres nicht hinbekommt, wäre ich dafür, dass man (so wie es einige jetzt schon machen) einen Pseudo-Benutzernamensraum unterhalb von "Modul:Benutzer:" aufspannt, wo jeder machen kann, was er will. Aber eine Shared-Sandbox für jedes Modul ist nichts Halbes und nichts Ganzes. Das ist unüberlegter Murks, den wir nicht übernehmen sollten.
• Statt einer direkten Einbindung von mehrsprachigen Soft-Redirects, wäre ich dafür, eine entsprechende Sprachunterseite zu erstellen und dort dann das Soft-Redirect zu setzen, wenn man auf Dokumentation in anderssprachigen Wikis verlinken will. Das ist deutlich flexibler und insgesamt auch logischer als irgendeine Ansammlung x Soft-Redirects.
• Was die Dokumentationsunterseiten angeht: Ich sehe keinen Grund, Deutsch anders als andere Sprachen zu behandeln. Die Dokumentation in Deutsch sollte auf /de stehen, die Modulseite selbst könnte stattdessen besser eine Vorlageneinbindung dieser /de-Seite sein, so wie es jetzt schon mit der eigentlichen Moduldokumentationsseite /Doku gemacht wird. Insgesamt ist das logischer und nicht irgendein Mischmasch von diese Sprache da, jene dort... Vor allem ist auf Dauer nicht auszuschließen, dass eventuell bei einigen Übernahmen aus anderen Wikis gar keine deutsche Dokumentation zum Modul mehr erstellt wird, weil die Leute, die sich mit Modulen befassen, vermutlich Englisch können und der Rest normalerweise nur mit einer einbindenden Vorlage und nicht mit dem Modul selbst arbeiten muss. Auch könnte es sein, dass man auf der Modulseite irgendwann vielleicht noch andere Informationen als die reine Dokumentation des Moduls unterbringen will. Deshalb würde ich die Modulseite nicht für die Dokumentation vorsehen, sondern die entsprechende Sprachunterseite und somit die Modulseite zur freien Verwendung haben (sie kann die Dokumentation einbinden, aber es können dort auch andere Dinge noch untergebracht werden). --Entzücklopädie 10:53, 19. Mär. 2013 (CET)

• Ich formuliere mal, was ich als Anwender und Benutzer von den Links und der Seiten-Verortung erwarte:
  • WP:Lua/Modul/XYZ – ich komme auf die Dokumentation, die mir im ersten Hauptabschnitt erklärt, wie ich das im Detail in meine Vorlage einbinde (nach den allgemeinen Regeln). Ich werde mit den Hundert oder womöglich Tausenden von Zeilen Lua-Quellcode verschont.
  • Modul:XYZ – ich bekomme den Lua-Quellcode und will programmieren. Oben auf der Seite finde ich Verlinkungen auf Dokus und Diskus. Zum Scrollen innerhalb einer Browserseite ist mir das sowieso zuviel, um es gleichzeitig sehen zu können; ich brauche zwei Tabs oder Browserfenster nebeneinander und unabhängig für Doku und Quellcode.
  • Ich finde jegliche Diskussion zentral weitergeleitet auf WD:Lua/Modul/XYZ – völlig egal von welcher Sprache und Namensraum aus gesehen.
• Mit der Variante /de kann ich mich anfreunden; wenn die Vorlage:ModuleDoc weitere Intelligenz eingebaut bekommt:
  • Mittels {{#ifexist: lässt sich feststellen, welche Unterseiten /de /en /fr /pt jetzt im Moment existieren. Die Vorlage:ModuleDoc muss nur die Abfolge aller jemals bei uns eingerichteten Fremdsprachen (zurzeit de en) durchlaufen und bei Existenz ein fettes Link zum Lesen (und je ein kleines Link [edit] zum Doku-Bearbeiten) bereitstellen; außerdem davon abgesetzt ein fettes Link zum Quellcode (und ein kleines Link [edit] zum Quellcode-Bearbeiten), falls im Moment NAMESPACENUMBER ungleich 828. Damit entfallen Redlinks und Sprachparameter.
  • Auf der Seite WP:Lua/Modul/XYZ stünden dann nur ein bis zwei oder drei Zeilen:
    • {{ModuleDoc}} ohne Parameter
    • Die Transklusion {{{{#rel2abs:.}}/de}} – diese könnte sogar mit reichlich viel Logik von {{ModuleDoc}} automatisch mit übernommen werden; kommt drauf an, ob PAGENAME nur eine Ebene unter WP:Lua/Modul/ läge.
    • ggf. Kategorien oder Interlanguage.
• Wenn WP:Lua/Modul/XYZ/de von WP:Lua/Modul/XYZ eingebunden wird, gibt es noch einen Trick: Der gesamte Abschnitt „Interna“ kann in <noinclude> eingeschlossen werden. Das bedeutet: Wer nur in eine Vorlage einbinden möchte, sähe zunächst lediglich Einleitung und „Export“-Abschnitt; ohne Interna und ohne Lua-Quellcode. Erst bei direktem Sprung auf die Sprachversion kommt der volle Text, wie er für Programmierer in Lua interessant ist.
• Die thematische Übersicht WP:Lua/Modul verlinkt auf die WP:Lua/Modul/XYZ und zeigt die für Vorlageneinbinder notwendigen Informationen. Wer aus dem Modul-NR kommt, wäre Lua-Programmierer.
• :en:String hatte ich nur als erstes naheliegendes Beispiel genutzt, um zusätzliche Unterseiten zu demonstrieren. Es gibt noch /results und /performance und alles Mögliche. Bei :en:String ist es zufällig in Lua formatiert; die enWP ist mit Wikitext ausgewichen auf en:Module talk:String/tests – genau diesen „Missbrauch“ von Disku-Namensräumen möchte ich jedoch vermeiden.

Beste Grüße --PerfektesChaos 10:34, 20. Mär. 2013 (CET)

Halten wir mal fest:

• Modul:XYZ nur Quelltext mit Links zu Doku. OK, dürfte sinnvoll sein. Die eigentlich vorgesehene Einbindung bläht es zu sehr auf.
• Sämtliche Diskussionsseiten auf WP Diskussion:Lua/Modul/XYZ weiterleiten. OK, eine zentrale Anlaufstelle definitiv empfehlenswert. Nur muss bezüglich der Redirects daran gedacht werden, diese auch immer einzusetzen.
• WP:Lua/Modul/XYZ: Hinweise zur Verwendung (abseits der Quellcodedokumentation) definitiv sinnvoll. Was mir noch nicht so gut gefällt, ist die Einbindung der Dokumentation, indem die internen Teile mit <noinclude> ausgeblendet werden. Weil eigentlich würde ich ganz gern die Dokumentation auch unter Modul:XYZ/Doku einbinden (als zentrale Anlaufstelle für die Entwicklerdokumentation in der bevorzugten Sprache, so wie jetzt auch und so wie es eigentlich vorgesehen war) und dort wäre es natürlich kontraproduktiv, wenn diese Teile ausgeblendet sind. Auch widersprichst du dir, so dass ich momentan etwas verwirrt bin: Anfangs schreibst du, dass du dort Dokumentation für Vorlageneinbinder haben willst, später soll nur noch {{ModuleDoc}}, die Moduldokumentation und Kategorien dort stehen. Woher willst du dann die Vorlageneinbindungsdokumentation nehmen bzw., wenn du sie auch nur einbinden willst, auf welche Seite willst du die schreiben?
• Edit-Link unter Doku, wenn die Seite existiert und somit kein Create-Link angegeben ist: OK, sinnvoll. Was den Wegfall von Red-Links und des Create-Links angeht: Die sind eigentlich mit Absicht da, damit man angibt, in welcher Sprache man Dokumentation erstellen will und automatisch dafür einen Create-Link mit Preload angeboten bekommt, so dass man auf der richtigen Seite die Dokumentation anlegt und die korrekte Vorlageneinbindung dort verwendet (später wäre sicher sinnvoll eine grobe Gliederung zu ergänzen). Dein Vorschlag alle jemals angelegten Dokumentationssprachen automatisch zu durchsuchen, geht nebenbei nur eingeschränkt. Man müsste im entsprechenden Modul eine feste Suchliste einbauen. Aber dass es automatisch mitbekommt, "Dokumentation in fr, OK, suche in Zukunft immer nach fr mit", das geht nicht, weil man aus einer Vorlage oder einem Modulaufruf heraus nichts speichern kann.
• Was Modul:XYZ/tests angeht: Ich weiß momentan nicht, ob es z. B. für dessen Ergebnisse sinnvoll wäre, die Seite Modul:XYZ/tests/Doku zu verwenden. Dort bin ich unentschieden. --Entzücklopädie 11:35, 20. Mär. 2013 (CET)

• Das geht schon alles so, mit altmodischem Vorlagensyntax-Voodoo. Widersprochen habe ich mir auch nicht; es genügt, auf den fraglichen Seiten {{ModuleDoc}} parameterlos einzubinden; die bekommt Intelligenz und regelt den Rest. Weil ohnehin schon Modul:ModuleDoc existiert, kann das ggf. Hilfsdienste leisten und komplexe Logik verkürzen. {{#ifexist: ist leider noch nicht in Lua verfügbar – sollte sich aber indirekt per frame:callParserFunction() machen lassen.
• Ich möchte gern den Lua-Quellcode und die Doku in zwei unterschiedlichen Tabs oder Browser-Fenstern sehen; mit unterschiedlichen Scroll-Positionen auf die gerade interessante Stelle. Bei zwei Browser-Fenstern kann ich sie nebeneinander fokussiert auf den Bildschirm legen. Im Edit-Modus würde ich ggf. die Doku nicht sehen; bräuchte also ohnehin ein zweites Fenster. Wenn ich eine Doku lesen möchte, will ich nicht mit der Implementierung belästigt werden. Über Transklusion könnte man den Quellcode in didaktischen Fällen wie Modul:Hello ausnahmsweise einblenden.
• Ich möchte auf der Seite Modul:XYZ folgendes sehen:

Modul:XYZ

Deutsch [edit]

English [edit]

---

  local p = {}
  function p.hello(frame)
      local name = frame.args[1]

• Auf der Seite Wikipedia:Lua/Modul/XYZ möchte ich dagegen als Vorlageneinbinder folgendes sehen:

Wikipedia:Lua/Modul/XYZ

Modul

Deutsch [edit]

English [edit]

XYZ hat einen Zweck.

Funktionen zur Vorlageneinbindung

• Auf der Seite Wikipedia:Lua/Modul/XYZ/qq das Gleiche wie vor; hier wäre aber ein noinclude nicht wirksam. Dafür sollte das aktuelle Sprach-Feld farbig unterlegt sein; das Link auf die momentane Sprache entlinkt sich von selbst, das [edit] ist genauso wirksam wie das normale.
• Das Link auf die Sprachversion zeigt immer auf die vollständige Doku.
• {{#ifeq:{{#titleparts:{{PAGENAME}}|2|-2}}|Lua/Modul|Passt, bin auf der Doku für Vorlageneinbinder.}}
• Die #redirect auf den Disku haben wir bislang immer untergebracht.
  • Weil {{ModuleDoc}} ohnehin eine Intelligenzbestie ist, kann sie bei {{#ifexist:{{TALKPAGENAME}}|<!--ok-->|Diskussionsseite benötigt noch #REDIRECT [[WP:Lua/Modul/......]]}} eine Fehlermeldung zeigen. Außer natürlich bei WP:Lua/Modul/XYZ selbst (diese hat anders als alle anderen NR und Unterseiten {{#ifeq:{{#titleparts:{{PAGENAME}}|2|-3}}|Lua/Modul|<!-- -->|.....}}).
• An Mehrsprachigkeit steht einstweilen nur de/en ins Haus. Bislang hatten wir nie eine spanische Doku, aber das mag sich ja einmal perspektivisch ändern. Es ist keine dramatische Belastung, bei der Auswertung alle paar Monate mal die fehlenden Sprachen durchzugucken, die überhaupt in Frage kämen.

  {{ModuleDoc}} enthält (erst wenn es sich lohnt)

  {{ModuleDoc/lang|de|Deutsch|+}}

  {{ModuleDoc/lang|en|English|+}}

  {{ModuleDoc/lang|fr|Français}}

  {{ModuleDoc/lang|pt|Português}}

  • Mit den Parametern
    • 1=Sprachcode
    • 2=Angezeigter Sprachname
    • 3=Nicht-leer: Sprache immer anzeigen, auch wenn keine Doku-Seite existent

Beste Grüße --PerfektesChaos 14:07, 21. Mär. 2013 (CET) + 10:56, 22. Mär. 2013 (CET) + 21:37, 23. Mär. 2013 (CET), 13:28, 24. Mär. 2013 (CET)

Einschränkungen bei UnitTests

Ich hatte mit der Idee gespielt, en:Modul:UnitTests zu importieren, aber das erscheint mir nach einigen eigenen Tests nur bedingt sinnvoll. Da muss einiges gefixt werden. Dabei bin ich auch auf ein allgemeines Problem gestoßen: Auf einer einfachen Ebene können solche UnitTests funktionieren. Das gilt aber nur, solange diese Ergebnisse keinen Wiki-Syntax enthalten. Sobald Wiki-Syntax ins Spiel kommt, wird es kompliziert (und das dortige Testmodul würde Fehler anzeigen, wo keine sind oder aber Sachen als korrekt werten, die nicht korrekt sind).

Nicht nur, dass es dann eventuell lang und fehleranfällig wird, das Zielergebnis korrekt anzugeben. Das Problem ist vielmehr, dass man ggf. große Teile gar nicht vergleichen kann. Alles, was z. B. zwischen von Wikipedia interpretierten Tags wie <nowiki>, <imagemap>, <pre>, ... steht, ist nicht vergleichbar. Das liegt daran, dass wenn man derartigen Code durch den Präprozessor jagt (z. B. also auch das Ergebnis eines Invoke-Aufrufes), er alles innerhalb dieser Tags wegschneidet und durch eine Marke vom Typ "\0x7fUNIQ31ced16d346307bd-nowiki-00000000-QINU\0x7f" ersetzt. Der Inhalt wird erst wieder eingesetzt, nachdem die Modulaufrufe komplett abgeschlossen sind. Das Modul kann selbst also nicht sehen, was dort stünde und somit auch keine Fehler entdecken (andersherum wird in der englischen Wikipedia momentan auch nicht bedacht, dass diese Marken, obwohl sie gleichen Inhalt haben, unterschiedliche IDs besitzen können und somit würden Fehler angezeigt, wo keine sind - ebenfalls setzt der Parser an weiteren Stellen, wie z. B. Überschriften, solche Marken, wenn er auch dort nichts wegschneidet, und auch die können unterschiedlich sein).

Eine sinnvolle Unittest-Abdeckung wird also nur für relativ primitive Module möglich sein. Bei Modulen mit komplexeren Ausgaben ist das leider von vornherein mit doch einigen Einschränkungen verbunden, was man dort überhaupt testen kann (von der Tatsache, dass es meist schwer sein wird, den sich ergebenden Code genau anzugeben, ganz abgesehen). --Entzücklopädie 23:36, 19. Mär. 2013 (CET)

• Ich denke auch, dass für uns und unseren Kontext das Bauen solcher automatisierter Unit-Tests etwas übertrieben ist.
• Wenn es irgendwann jemand als Benutzer erprobt hatte, voll glücklich ist und das Test-Modul geschrieben hat, mag es nach konkreter erfolgreicher Bewährung importiert werden.
• Uns interessiert letztlich nur die Optik. Bereits bei guten Vorlagen-Dokus geben wir einen solchen Vergleich als Wikitext mit idealerweise drei Spalten; bei längeren Gebilden in Blöcken von drei Zeilen:
  1. nowiki-Quelltext
  2. Erwartetes Resultat, hard-coded
  3. Quelltext-Einbindung

Ob Erwartung und momentanes Resultat übereinstimmen, sieht man meist auf einen Blick. Man muss nur sicherstellen, dass nowiki-Quelltext und Quelltext-Einbindung übereinstimmen, und wenn Erwartung und Ergebnis auseinanderklaffen, wird das auch jemand merken. Optisch entspricht das en:Module talk:String/tests.

• Der Aufbau der Testsysteme ist für sich wieder arbeits- und wartungsintensiv sowie fehleranfällig. Als ein Mittel unter anderen in großen Systemen zur routinemäßigen Detektion von heimlichen Böcken in Basisfunktionen ist der Nutzen unbestritten; aber so hochdramatisch ist das in unseren Vorlagen zu erwartende Lua nun auch wieder nicht.
  • In meinem WSTM benutze ich einen Elementar-Test; so viele verschiedene Test-Kombinationen kann ich mir aber gar nicht ausdenken, wie sich Benutzer an Syntaxkonstrukten einfallen lassen.

Viele Grüße --PerfektesChaos 10:59, 20. Mär. 2013 (CET)

Code-Editor im BNR

„Wobei es da vorteilhaft wäre, wenn man den Codeeditor und die Konsole auf einfache Art und Weise irgendwie auch im Benutzernamensraum aktivieren könnte.“

• Ich habe da mal was vorbereitet: Wikipedia:Technik/Text/Edit/CodeEditor
  • Kannst es ja mal ausprobieren.
  • Wenn glücklich, kann das auf die Hilfeseite.
  • Vielleicht schreibe ich auch noch ein benutzerfreundliches Gadget dazu.
• Eine andere Geschichte ist eine Art Ausführung, Syntaxanalyse im Sinne von Fehlermeldungen, Konsole, Einbindung von Artikeln. Die kann im BNR eigentlich nicht gehen.

LG --PerfektesChaos 22:34, 20. Mär. 2013 (CET) + 10:56, 22. Mär. 2013 (CET)

• Benutzer:PerfektesChaos/js/editorContent ist einsatzbereit; einfach einbinden, kann losgehen. --PerfektesChaos 21:31, 24. Mär. 2013 (CET)

Beispiele

Die Seiten mit den Dokus im WP-NR, wie z.B. Wikipedia:Lua/Modul/TemplatePar/de sollten Beispiele enthalten. Idealerweise als Tabelle vom Typ Quelltext - Wirkung . ÅñŧóñŜûŝî (Ð) 16:36, 7. Mai 2013 (CEST)

• Die Seite, die du benannt hast, ist die für die fortgeschrittenen Lua-Programmierer. Die ist schon reichlich gefüllt bis zur Unübersichtlichkeit.
• Ich empfehle dir, erstmal mit der Seite zur Vorlagenprogrammierung anzufangen. Das ist die, die auch auf Wikipedia:Lua/Modul verlinkt ist:

  Wikipedia:Lua/Modul/TemplatePar

  • Dort gibt es einen Abschnitt

    Wikipedia:Lua/Modul/TemplatePar #Parameterprüfung (check)

    mit einem Anwendungsbeispiel für die real existierende Vorlage {{Information}}.

    Dieses wird ausgiebig diskutiert.

  • Weiter gibt es einen Abschnitt

    Wikipedia:Lua/Modul/TemplatePar #Allgemeine Hinweise zur Einbindung von Modulen

    Dort ist mit einem Beispiel die Syntax durchbuchstabiert.

  • Weiter gibt es einen Abschnitt

    Wikipedia:Lua/Modul/TemplatePar #Beispiele (Testseite)

    Folgen wir diesem Link, so kommen wir auf

    Wikipedia:Lua/Modul/TemplatePar/test

    Schauen wir uns dort den ersten Abschnitt an

    Wikipedia:Lua/Modul/TemplatePar/test #Testfälle zur Vorlageneinbindung: check

    dann sehen wir den Inhalt einer fiktiven Beispiel-Vorlage.

    Anschließend werden vier unterschiedliche Beispiel-Nutzungen dieser Beispiel-Vorlage mit ihrer Einbindung und der Wirkung dargestellt, so wie von dir gewünscht.

  • Was denn jetzt noch alles?
• Ich denke mir, nach kurzer Eingewöhnungsphase und genauerem Hinsehen wird sich das legen.

VG --PerfektesChaos 21:02, 7. Mai 2013 (CEST)

Gut. Ich Lese mir das durch. Schwieriger als Python oder C++ (okay, der letzte Vergleich hinkt, da C++ eine Hochsprache ist) kann es auch nicht sein... ÅñŧóñŜûŝî (Ð) 21:15, 7. Mai 2013 (CEST)

Nutzung der Definitionsliste in Wikipedia:Lua/Seitenorganisation und Dokumentation

Hallo PerfektesChaos, wie ich deinem Revert [1] entnehme hast du das eigentlich Problem nicht verstanden. So wie ich das sehe, wird die Definitionsliste hier als einfache Form einer Auszeichnung für eine Art Zwischenüberschrift genutzt. Dies ist gemäß Hilfe:Textgestaltung nicht gewünscht. Des Weiteren funktioniert diese Hervorhebung wie gesagt nicht zuverlässig, da sie vom verwendeten Stylesheet abhängig ist, so funktioniert diese Auszeichnung beispielsweise in der Android-Wikipedia-App nur bedingt (keine Fettschreibung). Es geht also nicht darum, dass die Tags dl dt dd erzeugt und vom Browser ausgewertet werden, sondern darum, dass die Beschreibung der "Wirkung" und der nutzbaren Parameter einer Funktion nicht in Form einer Definitionsliste dargestellt werden sollen. Statt die Definitionsliste zu nutzen, sollte die Seite besser wie üblich die Überschriften nutzen. So wird auch das TOC erzeugt, was gerade bei größeren Modulen oder Modulen mit komplexen Funktionen die Gliederung der Dokumentationsseite deutlichen verbessert. Dies wird in der Wikiepdia an vielen Stellen nicht korrekt umgesetzt, das sollten wir nicht noch weiter fördern. --Cepheiden (Diskussion) 11:09, 9. Mai 2013 (CEST)

Übrigens entspricht derzeit die Formatierung des Beispiels nicht der Kopiervorlage. --Cepheiden (Diskussion) 11:26, 9. Mai 2013 (CEST)

... in Bearbeitung ... Antwort folgt ... Überlastung mit dringlicheren Angelegenheiten ...

--PerfektesChaos 00:09, 11. Mai 2013 (CEST)

Darstellung auf Mobilgeräten: bugzilla:48352 Hotfix

• Sowas einfach mal melden; unsere Telefone sind noch mit Kurbel.

... restliche Antwort später; begrenzter Sonnenschein und Abarbeitung etlicher anderer Angelegenheiten nach Priorität ...

VG --PerfektesChaos 10:30, 11. Mai 2013 (CEST)

Toll ein Workaround für eine nicht erwünschte Nutzung der Definitionsliste als Gliederungselement. --Cepheiden (Diskussion) 10:47, 11. Mai 2013 (CEST)

Nun hetze ihn doch nicht so. Wenn du ihn hetzt, dann besteht evtl. die Gefahr, dass sein Nomen zum Omen wird ;-) Das wollen wir doch nicht, oder? ÅñŧóñŜûŝî (Ð) 12:56, 11. Mai 2013 (CEST)

Planungen

Gibt es hier irgendwo eine Roadmap für die Arbeit der nächsten Wochen ? ÅñŧóñŜûŝî (Ð) 23:51, 9. Mai 2013 (CEST)

Wir sind alle gut und reichlich beschäftigt. Was genau möchtest du denn wissen? --PerfektesChaos 00:16, 10. Mai 2013 (CEST)

Wer wann an welchem Modul arbeitet. Außerdem hast du erwähnt, dass das Modul:Str durch ein neu entwickeltes ersetzt werden soll. Das Konzept dazu würde ich gerne mal erfahren. Dann hätte ich noch ein paar Ideen, welche ich besprechen will. ÅñŧóñŜûŝî (Ð) 00:21, 10. Mai 2013 (CEST)

• Was auf WP:MOD an Modulnamen steht und nicht verlinkt ist, ist konkret in Planung und Konzeption, Arbeit, Erprobung.
• Du scheinst mich missverstanden zu haben: Nicht ein Modul Str soll verschwinden, sondern alle Vorlagen Str* aus der Vorlagenprogrammierung und schließlich aus dewki. Sie sollen vielmehr durch unmittelbare Nutzung von Modulen mit aggregierten Datentypen ersetzt werden. Das wird aber in einer ersten Phase bis Weihnachten dauern, um die Bibliotheken zu schaffen. Im Lauf des nächsten Jahres wären dann nach und nach Vorlagen zu identifizieren, die noch Str-Vorlagen verwenden, und dort geeignet zu überarbeiten. Eine Zeichenkettenverarbeitung mittels Vorlagensyntax hat keinerlei Zukuft.
  • Bei Anlage von Modul:Str hattest du die WP:MOD#Namenskonvention missachtet; der richtige Name für den anscheinend beabsichtigten Zweck wäre Modul:Vorlage:Str – der Begriff der spezifischen Einzelvorlage ist hier sinngemäß durch die Gruppe Vorlage:Str* zu ersetzen.
• Ansonsten sind wir andern noch alle in der Lernphase, sammeln Erfahrungen und machen uns zurzeit mit den Besonderheiten der Sprache vertraut.

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

(Wir haben wohl denselben Online-Rythmus ;-) )

1. Betreffs Namenskonvention: Da steht: "Module, die ausschließlich einer einzigen Vorlage zuarbeiten..." Hier ging es um mehrere Vorlagen. Von sinngemäßer Ersetzung steht da nichts. Ich halte es auch nicht für sinnvoll, Module in der Zukunft nach diesem Kriterium zu unterscheiden: Letztendlich funktionieren alle Module wie programmierte Vorlagen. Sie werden wie diese eingebunden. Eine scharfe Grenzziehung wird sich langfristig nicht durchsetzen. Das Ganze ist m.E. aber eine Nebenfrage.
2. Die direkte Einbindung erfordert in der Tat, dass die Funktionen kompatibel sind und dass sie zuverlässig funktionieren. Ich bin auch - z.B. bei den Stringfunktionen - der Meinung, dass wir hier Vorlagen/Module nicht blind von enwiki abschreiben sollten. Das führt nur zum unüberlegten Einsatz. Es ist besser, sich den Quelltext einer Vorlage/eines Moduls anzuschauen, nachzudenken und eigene, evtl. bessere Implementierungen zu nehmen.
3. Wo man Vorschläge machen kann, hast du nicht erwähnt.

ÅñŧóñŜûŝî (Ð) 11:38, 10. Mai 2013 (CEST)

ad 3: Die Seite Wikipedia:Lua/Werkstatt hattest du bereits bearbeitet; ich ging deshalb davon aus, dass du den Einleitungsabschnitt gelesen hättest. --PerfektesChaos 11:59, 10. Mai 2013 (CEST)

Ich hatte sie gelesen, war mir aber trotzdem nicht sicher, ob ich dort richtig bin. ÅñŧóñŜûŝî (Ð) 12:21, 10. Mai 2013 (CEST)

Bitte die Module sichtbar machen

Bitte die Module sichtbar machen. Weitere Einzelheiten dazu siehe auch unter Wikipedia Diskussion:Lua/Modul/Zitation#Bitte sichtbar machen oder entbinden. MfG, 92.229.53.156 20:27, 10. Mai 2013 (MESZ)

Diese unschöne Nachricht ist angekommen; ich versuche Abhilfe zu schaffen. Liebe Grüße --PerfektesChaos 23:59, 10. Mai 2013 (CEST)

Siehe auch: Wikipedia:Fragen_zur_Wikipedia#Module_sichten --Cepheiden (Diskussion) 09:28, 11. Mai 2013 (CEST)

Anfang kommender Woche wird die Problematik weltweit angegangen und hoffentlich bald gelöst sein.

• Für Techies: gerrit:62979, gerrit:62985, bugzilla:48297.

Schönes und geduldiges Wochenende --PerfektesChaos 09:46, 11. Mai 2013 (CEST)

Ich wollte gerade erneut nachsehen, ob die Diskussion in FzW hier angekommen ist. Gut, und danke für diese Änderung in der Doku zum Modul Zitation. Bei den gerrit- und bugzilla-Teilen müsste man unter Umständen aber noch mal nachhaken, ich kann als non-Techie dort nicht erkennen, dass das zwingend schon Anfang kommender Woche gefixt wird. Weiter eher auf FzW? Ich bin finster entschlossen ;-), den Thread dort nicht im Archiv versinken zu lassen, bis der Fix durch ist. --Ivla^Disk. 15:03, 12. Mai 2013 (CEST)

62985 ist live, und der Umherirrende hat bereits die wichtigsten Module gesichtet. Der Hinweis in der Doku zu Zitation kann dann ja abgeändert werden. Zum Text habe ich noch eine Frage: "zwingt die Server zum Purgen aller dieser Seiten". Da werden wirklich jedesmal alle Seiten gepurgt? --Ivla^Disk. 20:16, 13. Mai 2013 (CEST)

„Purgen“ ist nicht der korrekte Fachausdruck, aber allgemeinverständlicher. Präziser wäre „werden ungültig“ (invalidate) und aus dem Cache entfernt.

• Wenn sich der Quelltext einer Vorlage oder eines Moduls verändert hat, weil eine neue Seitenversion gespeichert wurde, muss das System davon ausgehen, dass ab jetzt eine veränderte Zeichenkette als Ergebnis geliefert wird.
• Damit werden alle Cache-Schnipsel der Vorlagen-Einbindungen, #invoke und der daraus zusammengestellten Seiten wertlos und zur Entfernung markiert.
• Damit der Server weiß, welche Seiten davon betroffen wären, merkt er sich das für jeden Artikel und listet es dort bei den verwendeten Vorlagen sowie den „Links auf diese Seite“ unter „Vorlageneinbindung“ auf.
• Damit das System und seine Bezüge (Kategorien, Einbindungen) wieder aktuell werden, baut der Server nach einer Änderung alle Seiten nach und nach im Cache neu auf, sobald er Langeweile hat.

Liebe Grüße --PerfektesChaos 09:43, 14. Mai 2013 (CEST)

Danke für die gründliche Erklärung. Vielleicht lieber Aktualisieren statt Purgen, letzteres hat ja für uns die Bedeutung, dass der Cache sofort geleert/erneuert wird. Der Hinweis in Modul:Zitation/Doku bleibt demanch auch nach Beheben der Sichtungsproblematik sinnvoll, vermutlich? Das mit den Artikelnachsichtungen stimmt so aber nicht mehr, da jetzt dort gesichtet werden kann. Gruß, --Ivla^Disk. 00:47, 17. Mai 2013 (CEST)

Jein.

„Purge“ ist die manuelle Auslösung des Ungültigmachens eines Cache-Eintrags, Änderung einer eingebundenen Seite ist die automatische Auslösung. Ungültig und zur Löschung markiert wird der Cache-Schnipsel in beiden Fällen und sofort; später auch physisch gelöscht.

Die Datenbanken liegen auf unterschiedlichen Servern; die Seiteninhalte sind wichtig und es wird auf sicherem Weg versucht, nichts zu vergessen. Die Cache sind temporär und vergänglich; wenn bei der Kommunikation zwischen den Servern was schiefgeht, bekommt der Cache ab und zu einen Edit und seine Auswirkungen nicht ganz mit und man kann mit einem Purge Nachdruck verleihen.

Ich habe /Doku aktualisiert.

LG --PerfektesChaos 09:34, 17. Mai 2013 (CEST)

Modul LuaDokumentation

Hallo,

auf Wikibooks haben wir das Modul Modul:LuaDokumentation geschrieben, mit dem automatisch Lua-Dokumentationen erzeugt werden können (siehe am Beispiel des Moduls Modul:HalloWelt). Wenn Interesse besteht, kann ich gerne das Modul hierhin übertragen. Grüße Stephan Kulla (Diskussion) 18:02, 19. Mai 2013 (CEST)

Hallo, Stephan. Ich glaube nicht, daß Bedarf dafür besteht. Hier gibt es schon das Modul Modul:Vorlage:LuaModuleDoc, daß zusammen mit der Vorlage {{LuaModuleDoc}} die entsprechenden Seiten organisieren hilft. Außerdem liegen hier die eigentlichen Dokumentationsseiten in einem anderen Namensraum. Siehe Wikipedia:Lua/Seitenorganisation und Dokumentation. Gruß --Tlustulimu (Diskussion) 19:28, 19. Mai 2013 (CEST)

Vielen Dank für das freundliche Angebot.

• Ich hatte mir den Code schon neulich durchgelesen, als ich kurz auf der Projektseite mit der Ankündigung zugange war.
• Leider halte ich die Methodik der Code-integrierten Dokumentation nicht für Wiki-geeignet; aus folgenden Einzelgründen:
  • Jede Veränderung (Tippfehlerkorrektur) zieht einen Neuaufbau von möglicherweise Hunderttausenden von Seiten nach sich, in die das dokumentierte Modul eingebunden sein kann.
  • Häufig eingebundene Module sind aus diesem Grund auch regelmäßig gesperrt. Um einen Tippfehler zu berichtigen, wäre dann eine Admin-Anfrage für eine temporäre Entsperrung und anschließend eine erneute Sperrung erforderlich, während die Server alle abhängigen Seiten neu aufbauen.
  • Das von dir erstellte Modul geht zwangsläufig davon aus, dass es eine und nur eine Seitenversion gibt, und die live sichtbare Dokumentation ist immer nur die aus dem wirksamen Modul und nie eine andere. Das halte ich aus den vorstehenden Gründen nicht für praktikabel. Wenn schon aus dem Code generierte Dokumentation, dann muss sie offline extrahiert werden und danach als separate, editierbare Wikitext-Seite zur Verfügung stehen. Bei größeren Überarbeitungen des Moduls könnte man dann eine aktualisierte Fassung des Lua-Moduls als Grundlage für einen frischen Wikitext nehmen und umgekehrt die in der Zwischenzeit bekanntgewordenen Verfeinerungen der Dokumentation in den Quellcode der künftigen Produktivversion eingearbeitet haben.
• Im speziellen Fall des Wikitextes im Lua-Kommentar wäre ich auch mit dem entstehenden Text nicht glücklich:
  • Eine extrahierte Dokumentation eignet sich nur für Einzeiler; also einen guten Satz zur Funktionsweise, und dann für jeden Aufrufparameter und den Rückgabewert eine Zeile, und mehr kommt nicht.
  • Man will aber oft in der Dokumentation etwas mehr als den einen Satz haben: Nähere Erläuterungen, ein Beispiel, allerlei Wikilinks, eine Wikitable. Das ist technisch möglich, und wer die Wikisyntax sicher beherrscht, bekommt es auch ohne Vorschaumöglichkeit hin, innerhalb des Lua-Kommentars den richtigen Text zu schreiben; vielleicht auf der Spielwiese zu erproben.
  • Gleichwohl führt jede Formulierungsänderung am Wikitext der Dokumentation dann zum Sperrmanöver, zum Neuaufbau aller abhängigen Seiten und zu einem Eintrag in der Versionsgeschichte. Auch wenn man dort reinschreiben kann K und „nur Doku“, wäre ich nicht amüsiert, die wirksamen Code-Änderungen dazwischen herausfischen zu müssen.
• Ich habe nichts gegen eine Code-integrierten Dokumentation. In diesem Fall habe ich aus diesem JavaScript offline diese Doku extrahiert und in die eigentliche Doku eingebunden.
  • Allerdings habe ich auch beruflich mit dem Zeugs zu tun; und da jede Änderung an einem Komma einen Review-Prozess nach dem Acht-Augen-Prinzip nach sich zöge, hat man die Inline-Doku auch schon weitgehend eingedämmt und verfährt anders damit:
    • Aus der Entwicklerversion im AlphaPlus-Stadium wird einmalig extrahiert und dann gesondert textstrukturmäßig nachgearbeitet. Von da an geht das (HTML-)Dokument seine eigenen Wege bis zum nächsten Release.
    • Eine Live-Doku der jetzt gerade live aktiven Version ist nicht akzeptabel; wegen Review-Prozess.
    • Es werden nur die Kurzbeschreibungs-Schnipsel erstellt; etwa pro Methode, Eigenschaft oder Objekt. Diese werden dann als Insert in die eigentlichen Dokumentationstexte eingebettet. Damit kann jeder abgleichen, ob der ausführliche Text noch aktuell ist oder ob sich Inkonsistenzen auftun. Hat man Schnipsel übrig, die nicht in das Gesamt-Dokument passen, muss man irgendwo aktualisieren.
  • Ein Problem bei der Inline-Doku ist die fehlende Mehrsprachigkeit. Auch die kann man natürlich durch Markierungen in den Kommentarzeilen sicherstellen. Dann bekommt man allerdings auf drei Zeilen Methoden-Code Hundert Zeilen Dokumentationssystem, der Code ist nicht mehr lesbar, und alle sprachkundigen Bearbeiter bekämen Schreibzugrff auf die Software. Deshalb werden hier die englisch geschriebenen extrahierten Schnipsel in jede Sprachversion eingebettet und können auch ein- und ausgeblendet werden.

Aber eine schöne Übung im Lua-Schreiben war das auf jeden Fall.

Besten Dank nochmal und schönen Feiertag heute und morgen --PerfektesChaos 20:11, 19. Mai 2013 (CEST)

Vielen Dank für euer Feedback! Ihr habt mich überzeugt, dass Dokumentation und Sourcecode getrennt werden sollte. Auf Wikibooks Diskussion:Lua habe ich einen entsprechenden Eintrag hinterlassen. Grüße und euch auch schöne Feiertage Stephan Kulla (Diskussion) 22:18, 19. Mai 2013 (CEST)

Modul:Citation/CS1 & Modul:Citation/CS1/Configuration

Nachdem nun Vorlage:citation wegen Übersetzungsmängeln gelöscht wurde, stellt sich die Frage, wie mit diesem Modulen umzugehen ist. Wenn sie erhalten bleiben sollen, müssen sie jedenfalls hinsichtlich der Ausgabesprache und der Formatierung (vgl. WP:ZR) angepasst werden. --Cepheiden (Diskussion) 19:17, 3. Okt. 2013 (CEST)

Wenn der Code für sonstiges genutzt werden soll, dann ist das sinnvoll. Was ist denn mit den "Cite"-Vorlagen? Das sind wahre Wiki-monster, welche eine Lua-Umsetzung gut gebrauchen könnten. ÅñŧóñŜûŝî (Ð) 19:35, 3. Okt. 2013 (CEST)

Ja, das gilt aber für alle Zitiervorlagen und eine Sammlung der Rahmenbedingungen wird gerade unter Wikipedia:Lua/Werkstatt/Zitation zusammengestellt. Die Einzelvorlagen sollen dann bestimmte Sachen zusammenfassen und dann die neue "Universal-Zitierfunktion in Lua" nutzen. Denn da wir in der de-Wiki ein anderes Format haben sollten wir hier nicht einfach nur Copy&Paste machen. Des Weiteren haben die en-Wiki-Vorlagen so viel Firlefanz den kein Mensch braucht und der einem einheitlichen Format nur entgegenstehen, z.B. andere Trennzeichen usw. Unter Modul:Zitation gibt es auch schon eine Lua-Umsetzung für , die einige Vorteile bietet. Aber es wurde gewünscht eine Universal-Funktion zu basteln. Je schneller wir alle Rahmenbedingungen sinnvolle Parameter und ggf. Korrekturfunktionen, desto schneller gibt es was brauchbares. --Cepheiden (Diskussion) 21:02, 3. Okt. 2013 (CEST)

Hinsichtlich der Eingangsfrage: Als LA-Steller sich direkt an den löschenden Admin wenden und die Dinger als eine Art Untervorlagen deklarieren. Schönen Brückentag --PerfektesChaos 21:51, 3. Okt. 2013 (CEST)

„unverständlich“

Anders als im Bausteintext vom 2013-09-22, 17:47:34 behauptet, ist hier auf dieser Disku keinerlei Abschnitt verfasst worden und die Beschwerde auch nicht konkretisiert worden.

• Insofern kann dem behaupteten Mangel auch nicht abgeholfen werden.
• Wie dargelegt, sind die Grundkenntnisse auf Hilfe:Lua zu erwerben. Grundvoraussetzung für das Arbeiten mit Lua ist außerdem sichere Beherrschung der Vorlagenprogrammierung.
• Wenn das nicht vorliegt und auch kein konkretes Problem beanstandet wird, und sich noch nicht mal die Mühe gemacht wird, über das Bausteinreinrotzen hinaus irgendwas zu schreiben, dann muss man als Außenstehender die hier thematisierten Organisationsfragen auch nicht begreifen.

--PerfektesChaos 11:10, 29. Mär. 2014 (CET)

Feedback zur Verbesserung von Lua-Funktionen benötigt

Hallo,

wer regelmäßig Lua-Module verwendet, sie erstellt und verbessert, wird hiermit um Mithilfe gebeten:

Das Wikidata-Entwicklungsteam möchte mehr Lua-Funktionen zur Verfügung stellen, um die Erfahrung derer zu verbessern, die Lua-Skripte zur Wiederverwendung von Wikidata-Daten in Wikimedia-Projekten schreiben. Das Ziel ist es, die in den verschiedenen Wikiprojekten existierenden Module zu harmonisieren, die Lua-Programmierung für die Communitys zu vereinfachen und die Performance dieser Sprache zu verbessern.

Das Team möchte gerne mehr darüber erfahren, welche Gewohnheiten und Bedürfnisse Lua-Programmierer haben und was hilfreich für sie wäre. Dazu gibt es ein paar Fragen auf dieser Seite. Die Seite ist auf Englisch, aber es kann gerne auch auf Deutsch geantwortet werden.

Vielen Dank, Lea Lacroix (WMDE) (Diskussion) 10:46, 27. Mär. 2018 (CEST)

Kategorie:Modul:Vorlage:BAnz:Wartung

(Möglicherweise hier falsch, dann gern verschieben bzw. auf richtigen Diskussionsort verweisen.) Ich bin gerade zufällig über die Auto-Vervollständigen-Funktion auf die Kategorie:Modul:Vorlage:BAnz:Wartung gestoßen, die in dieser Nomenklatur einmalig ist und auch nicht weiter kategorisiert ist. Wo gehört eine solche Vorlage hin (vermutlich irgendwo unterhalb Kategorie:Wikipedia:? Ggf. unterhalb von Kategorie:Wikipedia:Lua/Modul?), was wäre der korrekte Name? Wenn sich jemand auskennt, gern auch direkt aktiv werden. Gruß Yellowcard (D.) 13:17, 24. Jan. 2023 (CET)

Aus den Bruchstücken Wartung und Vorlage:BAnz reime ich mir zusammen, dass es auf Kategorie:Wikipedia:Vorlagenfehler/Vorlage:BAnz abzielen müsste.

Die gibt es ja auch schon.

Kann auch eine Unterseite dieser Kategorie werden; siehe: Kategorie:Wikipedia:Vorlagenfehler/Vorlage:DNB-Portal/ohne GND

Module haben keine eigenen Wartungskats, sondern entweder die relevanten Vorlagen oder aber universelle Parameterformate.

Adressat ist Maintainer von Modul, Vorlage und bisheriger Kat.

Programmtechnische Realisierung müsste entsprechend angepasst werden.

VG --PerfektesChaos 17:21, 24. Jan. 2023 (CET)

Lua Fehlermeldung - zuwenig Speicher

Am 15. Mai 2023 sah ich im Abschnitt Einzelnachweise des Artikels COVID-19-Pandemie in Indien viele Fehlermeldungen von Lua. Es sei nicht genug Memory vorhanden. Ich habe versucht den Fehler einzugrenzen indem ich zwei Einzelnachweise auskommentiert habe bei denen ich den Fehler verortete (die Einzelnachweise darüber wurden fehlerfrei angezeigt). Ohne Erfolg.

Bei absolut gleichem Inhalt gibt es heute (drei Tage später) keine Fehlermeldung.

Auf Diskussion:COVID-19-Pandemie in Indien#LUA-Skriptfehler beschreiben Benutzer:VECTRONATOR und Benutzer:Gustav-Karl Neue ähnliche Fehlermeldungen. --TapTun (Diskussion) 21:38, 18. Mai 2023 (CEST)

PS: sehe gerade, dass es in der vorletzten Version (meine Versuch mit zwei auskommentierten Einzelnachweisen) wieder massenweise Fehlermeldungen gibt. --TapTun (Diskussion) 21:44, 18. Mai 2023 (CEST)

Add und Randhinweis dazu: Ist mir vor einiger Zeit auch im Artikel COVID-19-Pandemie in Österreich auch aufgefallen, siehe Special:Diff/240663764. Die Änderung <references responsive /> auf <references /> vermied wohl nur zufällig die Fehlermeldungen - die erwähnte LUA-Fehlermeldung tritt (zufällig) in beiden Reference-Varianten auf. Einziges Muster was mir bekannt ist: Es braucht, wie in diesem (ehemaligen) Newsticker-Artikel mit deutlicher Überlänge, eine größere Menge an Einzelnachweisen. Was auch immer die konkrete Anzahl bei "größer" sein mag.--wdwd (Diskussion) 10:55, 27. Jan. 2024 (CET)

Es ist die Überlänge.

Übergroße Seiten reißen umschichtig mal dieses, mal jenes Limit.

• Beim Memory käme noch die Generierung von Grafiken aus Seitendaten hinzu; die sehe ich hier aber nicht.

Es gibt nichts, was zurzeit durch Änderung irgendeiner Programmierung beseitigt werden könnte.

Einziges Hilfsmittel ist Aufteilung oder Kürzung der Seite.

• Österreich ist definitiv zu groß.
• Bei Indien ist es mir nicht so restlos klar; träfe ressourcenmäßig noch nicht mein Schmerzempfinden.
• Unklar ist mir der enzyklopädische Sinn taggenauer Kopfzahlen über etliche Monate. Wochen- oder monatsweise reicht für eine Wikipedia voll aus; Tagesstatistiken mögen externe Institutionen bereitstellen. Welche Erkenntnis ziehe ich als Publikum aus dem Unterschied zwischen dem 4. und 5. September?
• Die COVID-19-Artikel sind seit entsprechenden Jahren als Dauerbrenner und übergroße Limitsprenger bekannt.

VG --PerfektesChaos 11:49, 27. Jan. 2024 (CET)

Sodele, mittlerweile hatte ich etwas Muße, um bei Indien weiter zu debuggen.

• Der Artikel ist besonders exzessiv mit der Lua-Funktion getEntity beschäftigt.
• Die gehört zu: mw.wikibase.getEntity()
• Heißt: Der Artikel ist intensiv damit beschäftigt, irgendwas aus Wikidata abzufragen.
• Sowas meinte ich oben damit, als ich generierte Grafiken erwähnte; da tritt sowas auch auf, wenn extrem viele Datenpunkte eines Diagramms einzeln aus Wikidata gelesen werden sollen.

Der Artikel ist als instabil zu betrachten; er schrammt dicht unter irgendwelchen Limits entlang und wird diese immer wieder neu reißen; je nach Serverauslastung und minimalen Veränderungen.

VG --PerfektesChaos 01:48, 28. Jan. 2024 (CET)

Ich weise hier mal noch auf die Artikeldiskussionsseite und diese Diskussion und die dort erst einmal gefundene Lösung des Problems der angesprochenen Seite hin. Warum auch immer, erschließt sich mir nicht, aber ich suche Fehler immer so, dass ich schaue, wann sie auf einer Seite zuerst aufgetreten sind. Natürlich mögen die einzelnen Einbindungen und Abfragen der Einzelbelege da einen großen Einfluss gehabt haben. Aber erst einmal lag es wohl auch mit an der →Vorlage:FormatDate, dass es zu dieser massiven Auswirkung kam. Das Ganze müsste jetzt aber noch irgendwie repariert werden, da jetzt die Fehleranalyse dort Spezial:PermaLink/218609292#Beispiele nicht mehr richtig funktioniert. Diese Vorlage ist nämlich in die Vorlage:Infobox Pandemie eingebunden und die Fehleranalyse führte scheinbar zu dem Totalabsturz. --Liebe Grüße, Lómelinde Diskussion 08:47, 28. Jan. 2024 (CET)