Cowboy's Wiki:Lua/Werkstatt: Unterschied zwischen den Versionen

Aus Cowboy's Wiki
Wechseln zu: Navigation, Suche
K
K (Adressen-SortKey-Generierung)
 
Zeile 39: Zeile 39:
 
== Adressen-SortKey-Generierung ==
 
== Adressen-SortKey-Generierung ==
  
''Kopiert von Vorlagenwerkstatt.'' --[[Benutzer:PerfektesChaos|PerfektesChaos]] 21:27, 23. Mär. 2013 (CET)
+
''Kopiert von Vorlagenwerkstatt.'' --[[p:Benutzer:PerfektesChaos|PerfektesChaos]] 21:27, 23. Mär. 2013 (CET)
  
 
<div style="border: 1px solid #AAAAAA; padding: 1em;">
 
<div style="border: 1px solid #AAAAAA; padding: 1em;">
Zeile 50: Zeile 50:
 
Es wäre zudem sinnvoll, wenn Sonderzeichen ersetzt werden könnten (also Umlaute und ß sowie alle Satz- und Trennzeichen), aber bis auf die Möglichkeit, für jedes Sonderzeichen einen replace-Lauf zu starten, konnte ich ind er Dokumentation keine geeignete Lösung finden.
 
Es wäre zudem sinnvoll, wenn Sonderzeichen ersetzt werden könnten (also Umlaute und ß sowie alle Satz- und Trennzeichen), aber bis auf die Möglichkeit, für jedes Sonderzeichen einen replace-Lauf zu starten, konnte ich ind er Dokumentation keine geeignete Lösung finden.
  
Falls jemand drüberschauen könnte, wäre ich sehr dankbar!--[[Benutzer:Cirdan|Cirdan]] [[Benutzer Diskussion:Cirdan|±]] 20:48, 23. Mär. 2013 (CET)
+
Falls jemand drüberschauen könnte, wäre ich sehr dankbar!--[[p:Benutzer:Cirdan|Cirdan]] [[p:Benutzer Diskussion:Cirdan|±]] 20:48, 23. Mär. 2013 (CET)
 
</div>
 
</div>
  
 
: Zur Ersetzung von Sonderzeichen wäre der effizienteste mir bislang untergekommene Algorithmus derjenige als [[:en:User:PerfektesChaos/js/stringLib#.sortChar()|.sortChar()]] in [[:en:User:PerfektesChaos/js/stringLib/d.js|meiner stringLib]] geschriebene.
 
: Zur Ersetzung von Sonderzeichen wäre der effizienteste mir bislang untergekommene Algorithmus derjenige als [[:en:User:PerfektesChaos/js/stringLib#.sortChar()|.sortChar()]] in [[:en:User:PerfektesChaos/js/stringLib/d.js|meiner stringLib]] geschriebene.
: VG --[[Benutzer:PerfektesChaos|PerfektesChaos]] 21:50, 23. Mär. 2013 (CET)
+
: VG --[[p:Benutzer:PerfektesChaos|PerfektesChaos]] 21:50, 23. Mär. 2013 (CET)
::Ganz doofe Frage: Wie greife ich auf die StringLib zu?--[[Benutzer:Cirdan|Cirdan]] [[Benutzer Diskussion:Cirdan|±]] 12:21, 24. Mär. 2013 (CET)
+
::Ganz doofe Frage: Wie greife ich auf die StringLib zu?--[[p:Benutzer:Cirdan|Cirdan]] [[p:Benutzer Diskussion:Cirdan|±]] 12:21, 24. Mär. 2013 (CET)
  
 
:::* Ganz schlichte Antwort: Überhaupt nicht. Sie ist in JavaScript geschrieben und wäre hier nur auszubeuten.
 
:::* Ganz schlichte Antwort: Überhaupt nicht. Sie ist in JavaScript geschrieben und wäre hier nur auszubeuten.
Zeile 66: Zeile 66:
 
:::* Man beachte, dass die Sortierung einer Tabelle erst in der dargestellten HTML-Seite durch JavaScript erfolgt. Alle Betrachtungen hinsichtlich der PHP-seitigen Sortierung von Seitennamen auf dem Server greifen hier nicht.
 
:::* Man beachte, dass die Sortierung einer Tabelle erst in der dargestellten HTML-Seite durch JavaScript erfolgt. Alle Betrachtungen hinsichtlich der PHP-seitigen Sortierung von Seitennamen auf dem Server greifen hier nicht.
 
::: Insgesamt würde ich empfehlen, es hier ein paar Wochen gemütlich angehen zu lassen, bis sich die Basis-Strukturen aufgebaut haben.
 
::: Insgesamt würde ich empfehlen, es hier ein paar Wochen gemütlich angehen zu lassen, bis sich die Basis-Strukturen aufgebaut haben.
::: Schönen Sonntag --[[Benutzer:PerfektesChaos|PerfektesChaos]] 13:04, 24. Mär. 2013 (CET)
+
::: Schönen Sonntag --[[p:Benutzer:PerfektesChaos|PerfektesChaos]] 13:04, 24. Mär. 2013 (CET)
::::OK, dann lasse ich das einfach erstmal. Die Vorlage erfüllt ja weitestgehend ihren Zweck. Aber warum wurde eigentlich Lua ausgewählt? Die Programmierung ist im Vergleich zu anderen Sprachen ein echter Krampf und sehr umständlich.--[[Benutzer:Cirdan|Cirdan]] [[Benutzer Diskussion:Cirdan|±]] 13:08, 24. Mär. 2013 (CET)
+
::::OK, dann lasse ich das einfach erstmal. Die Vorlage erfüllt ja weitestgehend ihren Zweck. Aber warum wurde eigentlich Lua ausgewählt? Die Programmierung ist im Vergleich zu anderen Sprachen ein echter Krampf und sehr umständlich.--[[p:Benutzer:Cirdan|Cirdan]] [[p:Benutzer Diskussion:Cirdan|±]] 13:08, 24. Mär. 2013 (CET)
  
 
:::::* Man suchte wohl konkret schon seit 2009, und das war das Optimum und wurde 2011 ausgewählt.
 
:::::* Man suchte wohl konkret schon seit 2009, und das war das Optimum und wurde 2011 ausgewählt.
 
:::::* Die Sprache mag gewöhnungsbedürftig und in ihren syntaktischen Möglichkeiten begrenzt sein. Gegenüber Vorlagensyntax jedoch ein deutlicher Fortschritt.
 
:::::* Die Sprache mag gewöhnungsbedürftig und in ihren syntaktischen Möglichkeiten begrenzt sein. Gegenüber Vorlagensyntax jedoch ein deutlicher Fortschritt.
 
:::::* Maßgeblich für die Entscheidung ist, wie das effizient auf unseren Server laufen mag und sich in unsere sonstigen Strukturen einfügt. Ohnehin kommt nur OpenSource in Frage, damit das Aussehen der Projektseiten nicht mittelbar von fremden Rechten abhängen kann. Vermutlich war Lua klein und schnell und robust.
 
:::::* Maßgeblich für die Entscheidung ist, wie das effizient auf unseren Server laufen mag und sich in unsere sonstigen Strukturen einfügt. Ohnehin kommt nur OpenSource in Frage, damit das Aussehen der Projektseiten nicht mittelbar von fremden Rechten abhängen kann. Vermutlich war Lua klein und schnell und robust.
::::: Deine Hausnummerei könnte eine passende Funktion in einem ''Modul:Sort'' werden und anderen Vorlagen ebenfalls zur Verfügung stehen. Bis dann --[[Benutzer:PerfektesChaos|PerfektesChaos]] 13:24, 24. Mär. 2013 (CET)
+
::::: Deine Hausnummerei könnte eine passende Funktion in einem ''Modul:Sort'' werden und anderen Vorlagen ebenfalls zur Verfügung stehen. Bis dann --[[p:Benutzer:PerfektesChaos|PerfektesChaos]] 13:24, 24. Mär. 2013 (CET)
  
 
== Modul:InfoboxImage ==
 
== Modul:InfoboxImage ==

Aktuelle Version vom 7. Oktober 2014, 20:04 Uhr

Abkürzung: CW:LUW

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:

Sachdienliche Antworten können von allen gegeben werden.

Neue Frage stellen Neue Frage stellen


Keine Skriptfehler im Projekt.
Automatische Archivierung
Auf dieser Seite werden Abschnitte automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt}} versehen sind.
Archivübersicht Archiv
Wie wird ein Archiv angelegt?

Längerfristige Baustellen

Adressen-SortKey-Generierung

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

Hallo Vorlagenwerkstatt,

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

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

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

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

Zur Ersetzung von Sonderzeichen wäre der effizienteste mir bislang untergekommene Algorithmus derjenige als .sortChar() in meiner stringLib geschriebene.
VG --PerfektesChaos 21:50, 23. Mär. 2013 (CET)
Ganz doofe Frage: Wie greife ich auf die StringLib zu?--Cirdan ± 12:21, 24. Mär. 2013 (CET)
  • Ganz schlichte Antwort: Überhaupt nicht. Sie ist in JavaScript geschrieben und wäre hier nur auszubeuten.
  • Du musst dir um Sortierungs-Optimierung keine Sorgen machen. Irgendwann wird es ein Universal-Modul:Sort geben, das dies als Bibliotheksfunktion bereitstellt und dir über require("Modul:Sort") verfügbar sein wird.
  • Unter JS wäre der obige Hinweis mit die effizienteste Form, weil der Compiler den Zugriff regelt und es klar und übersichtlich hingeschrieben werden kann.
    • Weil es bei Lua aber kein switch gibt, sondern nur if, elseif, elseif, else, sollte man eine Datentabelle anlegen und diese algorithmisch flöhen.
    • Weil es bei Lua nur ein table gibt, das primär kein sequenzielles Array ist, wäre die hier effizienteste Lösung eine Tabelle, die jedem buchstabenartigen Zeichencode >=160 den ASCII-Wert zuweist; vermutlich effizienter erstmal numerisch und ein Treffer (non-nil) hinterher in Zeichenkette per mw.ustring.char(k) / geht sogar mit string.char(k).
    • Wenn man die von mir oben verlinkte stringLib::sortChar() mit brutaler Gewalt einmal von 160 bis 9000 durchlaufen lässt, kann man JavaScript dazu bringen, den Lua-Quellcode initial zu generieren.
    • Es würde sich anbieten, diese table mit mw.loadData("Modul:Sort/Data") zu externalisieren.
  • Man beachte, dass die Sortierung einer Tabelle erst in der dargestellten HTML-Seite durch JavaScript erfolgt. Alle Betrachtungen hinsichtlich der PHP-seitigen Sortierung von Seitennamen auf dem Server greifen hier nicht.
Insgesamt würde ich empfehlen, es hier ein paar Wochen gemütlich angehen zu lassen, bis sich die Basis-Strukturen aufgebaut haben.
Schönen Sonntag --PerfektesChaos 13:04, 24. Mär. 2013 (CET)
OK, dann lasse ich das einfach erstmal. Die Vorlage erfüllt ja weitestgehend ihren Zweck. Aber warum wurde eigentlich Lua ausgewählt? Die Programmierung ist im Vergleich zu anderen Sprachen ein echter Krampf und sehr umständlich.--Cirdan ± 13:08, 24. Mär. 2013 (CET)
  • Man suchte wohl konkret schon seit 2009, und das war das Optimum und wurde 2011 ausgewählt.
  • Die Sprache mag gewöhnungsbedürftig und in ihren syntaktischen Möglichkeiten begrenzt sein. Gegenüber Vorlagensyntax jedoch ein deutlicher Fortschritt.
  • Maßgeblich für die Entscheidung ist, wie das effizient auf unseren Server laufen mag und sich in unsere sonstigen Strukturen einfügt. Ohnehin kommt nur OpenSource in Frage, damit das Aussehen der Projektseiten nicht mittelbar von fremden Rechten abhängen kann. Vermutlich war Lua klein und schnell und robust.
Deine Hausnummerei könnte eine passende Funktion in einem Modul:Sort werden und anderen Vorlagen ebenfalls zur Verfügung stehen. Bis dann --PerfektesChaos 13:24, 24. Mär. 2013 (CET)

Modul:InfoboxImage

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

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

Kara amiko!
  • Zur Import-Frage: Danke; aber ich würde damit gern abwarten, bis das in einer Vorlage hier tatsächlich produktiv benötigt wird. Ohne dir zu nahe treten zu wollen, würde ich mich dann lieber an das en-Original in der letztmöglichen Fassung halten wollen.
  • Zur Sprachanpassung:
    • Die Herrschaften auf enWP schreiben bereits in der einzigen Weltsprache und haben es in der Regel nicht nötig, in ihrem Zeugs irgendwelche sonstigen Spezialitäten vorzusehen.
    • Wenn man eine geschlossene Software-Einheit wie diese Module auf Anpassungen vorbereitet (die „Internationalisierung“), dann geht man wie folgt vor:
      • Alle konfigurationsspezifischen Angaben werden am Anfang in einem geschlossenen Block gesammelt. Das betrifft Meldungstexte, Schlüsselnummern, URL, Dateinamen usw.
      • Im Verlauf des Programms wird ausschließlich auf diesen Block zugegriffen und nichts direkt angefasst („hard-coded“).
      • Wer anpasst („lokalisiert“), ändert dann nur übersichtlich und nachvollziehbar in diesem Block und muss nicht tief in den Innereien herumwurschteln und Fehler verursachen, oder irgendwas übersehen.
      • Selbst-anpassende vielsprachige Module können eine Fallunterscheidung vornehmen mittels: mw.language.getContentLanguage()
      • Im konkreten Fall:
local l10n = {}
   l10n.nsFiles  = "|file|image|datei|bild|dosiero|fichier|"  -- ASCII
   l10n.patSpace = "^(%a+:)"  -- ASCII, single word
   l10n.maintCat = "Kategorio:Paĝoj uzantaj informkestojn kun etaj bildoj"
-- l10n.noFile   = "File not found"
   l10n.noFile   = "Datei nicht gefunden"
und später müsste es (ungetestet freihändig) etwa so gehen:
function stripNamespaceFilePrefix( access )
   -- access -- file name
   -- Returns file name without any leading namespace prefix
   local strip = access
   local space = mw.ustring.match( access, l10n.patSpace )
   if space then
      if mw.ustring.find( "|" .. mw.ustring.lower( space ) .. "|", l10n.nsFiles ) then
         strip = mw.ustring.sub( access, mw.ustring.len( space ) )
      end
   end
   return strip
end   -- stripNamespaceprefix()
Frohe Ostern --PerfektesChaos 10:56, 28. Mär. 2013 (CET)

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)

Mehrzeilige Lua-Kommentare

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

Das ist syntaktisch okay, bloß ein Darstellungsproblem. Der Syntaxhighlighter erwartet deine Wikilink-Klammern nicht. Tatsächlich ist es so, dass auch das Innere eines mehrzeiligen Kommentars noch als Lua-Syntax gilt; zumindest was die Suche nach schließenden Klammern angeht. Und die muss auch der Syntaxhighlighter finden. Vielleicht verbessert das mal jemand; wir sind nicht die ersten und ich habe keine Lust.
Hilfe:Lua/Modul im Wiki: Wo genau dort? Ich seh nix, außer dem Üblichen halt.
VG --PerfektesChaos 12:10, 17. Mai 2013 (CEST)
Hallo, PerfektesChaos. Eine eigentlich falsche Darstellung findest du unter Funktionen nur für Vorlagen, sowie innere Hilfsfunktionen, gleich am Anfang.
--[=[ DiesesBeispiel 2013-05-07
Dieser und jener Zweck
* service
]=]
Richtig sieht es nämlich erst ohne = aus, also alles in Hellgrau und kursiv:
--[[ DiesesBeispiel 2013-05-07
Dieser und jener Zweck
* service
]]
Weißt du jetzt, wie ich es meine? Gruß --Tlustulimu (Diskussion) 22:27, 17. Mai 2013 (CEST)
  • Es ist mir schon durchaus klar, was du meinst. Ich guck seit Januar den enWP-Kollegen beim Entwickeln zu, und da ist das laufend so.
  • Es sollte also schon seit einem halben Jahr den Zuständigen aufgefallen sein. Weil das 600X WIKIPEDIA LOGO.svgGeSHi des syntaxhighlight ein externes Produkt ist, kann es eine Weile dauern, bis jemand Lust hat, das nach oben zu melden und danach richtig auf MediaWiki zu aktualisieren.
  • Die fehlerhafte Definition steht hier
    'COMMENT_MULTI' => array('--[[' => ']]'),
    'COMMENT_REGEXP' => array(2 => '/\[(=*)\[.*?\]\1\]/s'),
  • Es muss also bei COMMENT_MULTI die gleiche Paaruung (=*) und \1 stehen. Weil das ein Paar von Ausdrücken im array ist, braucht man möglicherweise für jede Anzahl von Gleichheitszeichen einen eigenen Ausdruck. Vielleicht geht aber in GeSHi nur einer.
  • Da ich keinen Bugzilla-Account habe, habe ich auch keine Lust, dem hinterherzurennen. Irgendwann schleicht sich das ganz von selbst ein.
Gute Nacht --PerfektesChaos 00:12, 18. Mai 2013 (CEST)
Hallo, PerfektesChaos. Das Problem ist sogar größer als oben von mir beschrieben. Wenn man sich ein Lua-Modul unangemeldet anschaut, wird das Sytaxhighlighting sogar teilweise total verhauen. Es ist also wohl doch ein richtiger Bug. Aber warum wird die Darstellung unangemeldet sogar eher verstümmelt als angemeldet? Das ist doch irgendwie seltsam. Wo meldet man so etwas am besten, damit es doch noch dieses Jahr behoben wird? Seltsam ist aber, daß en:Module:Listify/sandbox und en:Module:Age in der englischen Wikipedia unangemeldet nicht falsch dargestellt werden. Das gleiche passiert bei fr:Module:Hello in der französischen Wikipedia. Vielleicht ist es ja doch irgend eine seltsame Nebenwirkung von Modul:Vorlage:LuaModuleDoc und Vorlage:LuaModuleDoc oder irgendwelchen Formaten im MediaWiki-Namensraum. Soll ich mal nachschauen? Gruß --Tlustulimu (Diskussion) 23:36, 19. Mai 2013 (CEST)
An en:Module:Listify/sandbox und en:Module:Age und fr:Module:Hello sehe ich weder angemeldet noch unangemeldet etwas Böses.
Bei uns ist irgendwas im Gange, was irgendwie auf das Sytaxhighlighting Einfluss hat. Ich sehe die Modulseiten nie unangemeldet.
Vorlage:LuaModuleDoc kann nichts tun, was außerhalb der Box irgendeine Auswirkung hat. Wenn das jemand zaubert, hätte er so einiges geknackt. Siehe Modul:AdressenSort zum Vergleich.
MediaWiki:Common.css und MediaWiki:Common.js sehen beide gut aus. Sie haben einen Einleitungssatz.
Was ganz offensichtlich fehlt, ist die Einbindung von /Doku, wie sich beim Vergleich der beiden Varianten von Modul:AdressenSort sehen lässt. Damit wird dann auch der Quellcode nicht richtig in den Highlighter geschoben, und er erkennt erste und letzte Zeile schon mal gar nicht.
Mit dem oben eröffnenden Mehrzeilige-Kommentare-Problem hat das hier nichts zu tun.
Schöen Feiertag --PerfektesChaos 00:09, 20. Mai 2013 (CEST)
  1. Cowboy's Wiki:Technik/Skin/Werkstatt#Lokales Wiki und etwas PHP-RegExp-Spielerei benötigt
  2. Hast du inzwischen diskutiert bei BD:Raymond #Geshi funktioniert unangemeldet nicht im Modulnamensraum.
Saluton --PerfektesChaos 22:49, 21. Mai 2013 (CEST)

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 389 17:08, 2. Jun. 2013 (CEST)
Erstmal revert. --Steef 389 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 389 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 389 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 Cowboy's Wiki: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 389 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:Cowboy's Wiki: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
  • 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 CW: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 389 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)

Modul für Datum und Zeit

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

Notwendig ist dies allemal; siehe Wikipedia:Lua/Modul #Basis-Datentypen (Zeichenkette, Zahl, Zeit)
Weiter oben ist bereits eine Baustelle als redlink vermerkt: /Datum und Uhrzeit.
  • Den Text habe ich halbfertig auf der Festplatte in Warteschleife; beim nächsten Regenguss kann ich ihn zu Ende bauen.
  • Vorab soviel: Allgemeine Bibliothek mit Basisfunktionen; alle sowohl von Vorlage=#invoke wie auch von anderem Lua-Modul aus nutzbar; alle zweifelsfreien Datumsformate für den deutsch- und englischsprachigen Raum bei der Eingabe zu unterstützen: 15. Februar 2013; 15.2.2013; 15.02.13; 14.8.98; 2013-06-12; 3. Jänner 2012; 5 Mar 2011; December 9, 2010; 1. Apr. 2012. Ausgabe in einigen wesentlichen deutschsprachigen Standardformen + ISO. Mit Uhrzeit ähnlich, aber weniger Varianten möglich. Fehlerbehandlung für Wartungskats.
  • Auf der Baustelle wäre über die Liste der Funktionen zu diskutieren.
Geschrieben habe ich dazu bislang nicht eine Zeile in Lua.
Bis demnächst --PerfektesChaos 15:28, 12. Jun. 2013 (CEST)
  • Ich würde da noch ein paar Features, welche hier in WP dauerhaft genutzt werden, ergänzen. Insbesondere ein paar Funktionen für das in der Astronomie genutzte Julianische Datum.
  • Wichtig ist auch die Festlegung, wie fehlertolerant wir das Modul gestalten. Je penibler wir Fehlermeldungen platzieren, umso schlechter kann man später Erweiterungen vornehmen, denn viele Aufrufe nehmen keinen eigenen Paratest vor und "verlassen" sich später (mittels #iferror) auf die Fehlermeldung.
  • Bei englischen Eingabeformaten habe ich bedenken. Es ist nicht unterscheidbar, ob z.B. das Datum des Attentats auf das World Trade Center als "11.9.2001" (dt.) oder "9.11.2001" (en) übergeben wurde. Außerdem fördert das die blinde Abkopiererei von En-WP.
ÅñŧóñŜûŝî (Ð) 16:29, 12. Jun. 2013 (CEST)
Es gibt kein englisches Format "11.9.2001" (dt.) oder "9.11.2001" (en); es gibt keine Punkte im Englischen, sondern Schrägstrich oder Bindestrich. Alle europäischen Sprachen mit Punkt verwenden Tag.Monat.Jahr. Was es gibt, ist 09/11/2001 oder 09-11-2001 (US) und 11/09/2001 (sehr selten 11-09-2001) in UK; see en:Date and time notation in the United States. Eindeutig ist hingegen ISO: 2001-09-11. Punkte sind in vielen Tabellen und Vorlagen der deWP üblich.
Appetithäppchen von meiner Festplatte zum Selberformatieren; jul ist inklusive:
=== Daten ===
==== Eingabe ====
Abfangen aller &nbsp; \U+00A0 "  " "" bei der Eingabe. Interpretieren jedes eindeutigen Formats.
20141007200458 {{REVISIONTIMESTAMP}}
==== Neutrales Datenformat ====
table
year, month (1–12), dom, week (ISO), hour, min, sec, msec, zone, jul, bc, leap
==== spec ====
"T. Monat JJJJ", "dewiki", nil, false || 12.&nbsp;Juni 2013
"T. Monat JJJJ Z"                     || 12.&nbsp;Juni 2013 (CEST)
"T. Mon JJJJ"                         || 12.&nbsp;Jun. 2013
"T.Mon JJJJ"                          || 12. Jun. 2013
"TT.MM.JJJJ"                          || 12.06.2013
"T.M.JJJJ"                            || 12.6.2013
"ISO"                                 || 2013-06-12
"timestamp"                           || 20130612165733
usw. usw. mit Uhrzeit
=== Funktionen ===
Alle Lua-zugänglich. Jede story und spec ignoriert Whitespace drumrum, story ist die Zeichenkette mit zu interpretierender Eingabe.
; factory( story, lethal )
: Nur Lua-intern; insbesondere Eigenbedarf
: Liefert neutrale table, oder string mit Fehlermeldung
: throws error if lethal
; form( t, spec )
: Nur Lua-intern; insbesondere Eigenbedarf
: t ist neutrale table
; format( story, spec )
: auch für Vorlagen
: Rufe factory() auf und mit deren Ergebnis form()
; isValid( story, light )
: auch für Vorlagen
: light: erlaube leeren Wert
: Rufe factory() auf; true wenn diese eine table liefert
; isPretty( story, spec, light )
: auch für Vorlagen
: light: erlaube leeren Wert
: Rufe format() auf; true wenn dies identisch story liefert
Hilfsfunktionen; Ersatz/Service Julgreg-Vorlage
Rest später mal auf der Baustelle --PerfektesChaos 16:59, 12. Jun. 2013 (CEST)
Übrigens: Warum sieht das hier plötzlich so komisch überlappend aus? --PerfektesChaos 17:14, 12. Jun. 2013 (CEST)
Das überlappt sich, weil die Schrift, und damit auch die Zeilenhöhe im Span-Tag 150% hat und außerhalb des Span-Tags normale Zeilenhöhe (100%) gilt. Beides befindet sich aber in der gleichen Fließtextzeile. Darüber hinaus gibt es ein padding von 1em. Wenn du einen Rand definierst, dann fällt das auf, denn ein Browser berücksichtigt bei border das padding, ein Absatz entsteht aber nur bei einer Leerzeile im Quelltext und dessen Abstand hängt auch von den Grundeinstellungen ab. M.E. fehlt ein rahmenloses umhüllendes Div-Tag mit gegebener relativer Breite. Ich hab das mal umgesetzt. ÅñŧóñŜûŝî (Ð) 20:45, 12. Jun. 2013 (CEST)
  • Mit „Überlappen“ hatte ich eigentlich diese Version gemeint. Warum ist die Schrift jetzt eigentlich nicht mehr grün? Und warum klemmt das jetzt so eingezwängt zwischen Inhaltsverzeichnis und folgender Box?
  • Back to reality: /Datum und Uhrzeit
--PerfektesChaos 11:36, 13. Jun. 2013 (CEST)

Wikipedia:Lua/Werkstatt/Geo

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

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

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

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

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

Hallo, Antonsusi. Schade, daß du dich durch die Kritisierer hast entmutigen lassen.
Ich habe am 27. Juni angefangen ein Modul dafür in der Esperantowikipedia zu erstellen: eo:Modulo:Coordinates. Es basiert auf der französischen und der spanischen Fassung des Moduls. Von der französischen Version stammt die Unterstützung für die Trennung der Parameter durch /. Von der spanischen Version stammt die Unterstützung für das Dezimalkomma, wobei der im Englischen übliche Dezimalpunkt ebenfalls unterstützt wird.
Allerdings ist mir beim Testen aufgefallen, daß alle Versionen einige Bugs haben. Diese sind in der Esperantoversion behoben.
  • Sie geben nichts zurück, wenn bei den Paramtern format und/oder display unsinnige Werte angegeben werden. Ich lasse das Esperantomodul einfach auf die jeweilige Defaultwerte zurückfallen, obwohl ja auch der Einbau einer Wartungskategorie denkbar ist.
  • Die Funktion dms2dec läuft nicht richtig, denn sie unterscheidet nicht zwischen Nord und Süd bzw. Ost und West. Sie gibt also immer negative Werte zurück. (In der englischen Version ebenfalls behoben, und zwar nach meinem Hinweis.)
Gruß --Tlustulimu (Diskussion) 11:21, 30. Jun. 2013 (CEST)
Die extreme "Zerfledderung", der teilweise grottenschlechte Code (bei dem jedes Leerzeichen stört), die vielen nicht dokumentierten Erweiterungen und das Fehlen wichtiger ehem. Autoren macht es m.E. unmöglich, hier zuverlässig eine exakte 1:1-Kopie hinzubekommen. Außerdem ist es auch nicht unbedingt sinnvoll. Es gibt garantiert redundanten Code und die Vorlage müsste dringend gestrafft werden. Es ist einfach zuviel hineingepackt worden. Zusammen mit dem Zoff, der hier schon wegen zwei Stunden fehlender Funktion in Artikeln gemacht wurde, ist es nur konsequent, das Thema zu lassen. Der von (teilweise besserwisserischen und unverschämten) Usern erhobene Anspruch, direkt eine perfekte Umstellung zu aktivieren, ist nicht zu erfüllen, denn diese Vorlage kann ohne "online zu gehen" nur zum Teil getestet werden. Dafür sind es zu viele Zweige und z. B. auch zu viele Einbindungen, welche sich auf Fehlermeldungen verlassen. Ich wünsche dir viel Glück. ÅñŧóñŜûŝî (Ð) 11:36, 30. Jun. 2013 (CEST)
Hallo, Antonsusi. Heute habe ich mich an die Vorlage Coordinates in der Esperantowikipedia getraut. Allerdings bearbeite ich sie nicht direkt, sondern habe erst mal eine Testversion erstellt: eo:Ŝablono:Koordinato/provejo. Dort funktioniert bereits ein Teil der Koordinatenfunktionen (NS, EW, teilweise auch text, type, region, name, dim). Ich muß noch Überprüfungen auf sinnvolle Werte und den Kartenteil mit Lua ausstatten. Das dürfte sicher noch komplizierter sein als die Koordinaten. Ich habe für den Koordinatenkram der Vorlage ein neues Lua-Modul eo:Modulo:Coordinates2/provejo erstellt, damit in dem bereits länger vorhandenen Modul der Überblick nicht so schnell verloren geht. Einen Teil des Codes habe ich in der spanischen Wikipedia entdeckt, denn ich kann mir nicht alles alleine ausdenken.
Außerdem muß ich mir noch etwas einfallen lassen, wie ich die Fehlermeldung in eo:Ŝablono:Koordinato/provejo so anpassen kann, daß sie wie bei der bisherigen Vorlage aussieht. Gruß --Tlustulimu (Diskussion) 20:59, 3. Jul. 2013 (CEST)
Hallo, Antonsusi. Die Entwicklung macht Fortschritte. Der erzeugte HTML-Code vom genannten Modul sieht schon ziemlich so aus wie der von der bisherigen Vorlage (eo:Ŝablono:Koordinato/+. Die eo:Ŝablono:Koordinato lokalisiert nur die Parameter.), wobei sogar die Mikroformate funktionieren. Das Verstecken der Nichtstandardausgabe (also "geo-nondefault") habe ich entsorgt, weil damit unnötig der Server beschäftigt wird und der Quelltext unnötig verkompliziert wurde. Jetzt fehlen noch einige Dinge:
Gruß --Tlustulimu (Diskussion) 21:05, 9. Jul. 2013 (CEST)
Hallo, Antonsusi. Ich habe gerade deine Funktion"WGS84toCH1903" von deiner Testseite Benutzer:Antonsusi/Spielwiese/Modul:Coordinate für die Schweizer Landeskoordinaten in eo:Modulo:Coordinates/provejo eingebaut, allerdings umbenannt in convert_dec2ch1903 und etwas angepaßt. Die ersten Tests liefen nämlich nicht. Aktuelle Ergebnisse sind auf meiner Benutzerunterseite für Lua zu sehen. Ich habe noch ein Problem mit dem Parameter prec, der der Funktion übergeben wird. Welche Werte kann er haben? Wie könnte ein Skript für die Umwandlung von dms in ch1903 aussehen? Gruß --Tlustulimu (Diskussion) 21:39, 10. Jul. 2013 (CEST)
Du kannst sowas nicht leicht herausfinden. Großflächige Objekte wie z.B. Kanton Glarus haben zwar gerundete Gradwerte, aber keine gröber gerundete Angaben in CH1903. Bisher habe ich auch nur ganze Zahlen gesehen und keine stark gerundeten. Nimm einfach eine feste Rundung auf Einer vor. Wenn's nicht gefällt gibt's von den Besserwissern hier in der WP die oben erwähnte verbale Prügel. Man verlangt genaugenommen, dass man sowas mit großem Aufwand ermittelt. Über die ganze Aufgabe hochgerechnet sind das etliche Stunden. Das ist genau einer der Gründe, warum ich das nicht mehr weitermachen will. Ich empfehle dir folgendes:
  • Versuche durchzusetzen, dass nach der Umstellung zumindest anfangs nicht die exakte Funktionalität 100%ig gleich sein muss und du die diversen Extrafeatures nach und nach einbauen darfst. Wenn das auf Missfallen stößt, dann lass das ganze Thema.
  • Wenn du es umsetzt, dann organisiere ein System für Fehlerrückmeldungen, damit du der Sache nachgehen kannst.
  • Als Drittes kannst du Sachfragen klären. Du kannst auch versuchern, von Benutzer:Cactus26 das Leseskript für Vorlagenparameter zu bekommen. Dann kannst du dir die Aufrufe als Tabelle zeigen lassen. Die Vorlagen findest du übrigens hier.
Gruß von ÅñŧóñŜûŝî (Ð) 18:36, 11. Jul. 2013 (CEST)
Hallo, Antonsusi. Danke für deine Hinweise.
Ist es möglich auch die Formeln aus Vorlage:Coordinate/to UTM in Lua zu "übersetzen", und zwar so ähnlich wie beim CH1903-Format? Gruß --Tlustulimu (Diskussion) 19:34, 7. Aug. 2013 (CEST)
Hallo. Sogar die Vorlage {{Coordinate/to UTM}} ist in Lua portierbar. Ich habe den nötigen Code dafür heute in einem Testmodul der Esperantowikipedia entwickelt. Ein Anwendungsbeispiel steht auf meiner Benutzerunterseite über Lua. Ich muß nur noch das Ganze so einbinden, daß es auch als Ausgabeformat nutzbar wird. --Tlustulimu (Diskussion) 19:23, 9. Aug. 2013 (CEST)
Hallo. Das UTM-Format ist jetzt ins Modul Coordinates in der Esperantowikipedia eingebaut. Mal sehen, was ich so als nächstes ergänze. --Tlustulimu (Diskussion) 20:00, 10. Aug. 2013 (CEST)

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 {{Vorlage: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:''' &nbsp;
        }}
  • 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  +


  • @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;
}
GroVorlage:SS-Klein-Deutsch-Englisch nach Belieben
Wenn man sch eines Tages entschlieVorlage:SSt, 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)

Parameter muss eine natürliche Zahl sein

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

  • Der Vorlagendoku nach kannst du nur 1 meinen.
  • Das scheint ein Pflichtparameter zu sein. Auch wenn es nicht klar dokumentiert ist, ergäbe dies sonst keinen Sinn.
  • Dafür sieht die Tabelle N>0 vor; käme noch drauf an, ob führende Nullen möglich oder ausgeschlossen sein sollen.
VG --PerfektesChaos 20:58, 5. Sep. 2013 (CEST)
Als Pflichtparameter habe ich Parameter 1 gesetzt. Wie die Prüfung auf eine natürliche Zahl (es scheinen keine führenden Nullen vorzukommen) habe ich noch nicht verstanden.
Dafür ist mir aufgefallen, dass der Vorlagenname mit [[]] umschlossen werden kann, was die Wartung für Dritte erleichtern dürfte. --Leyo 21:51, 5. Sep. 2013 (CEST)
  1. Die Prüfung ergibt sich aus folgendem Code:
    {{#invoke:TemplatePar|valid|1|N>0}}
    • Das Ergebnis ist zunächst mal eine rote Fehlermeldung, oder nix.
    • Kann auch ergänzt werden durch cat= und löst im Fehlerfall die Wartungskat aus; diese hat nichts mit der Sichtbarkeit zu tun.
  2. editoronly gefällt mir nicht; siehe MediaWiki Diskussion:Common.css‎ #‎Parameterfehlermeldungen per Default ausblenden
  3. Das display:none sollte mit Produktionsreife zentral auf MediaWiki:Common.css‎ passieren, während genau dieses danach durch die Gruppenzugehörigkeit wieder aufgehoben wird.
    • Somit stünde dann nur noch in der Vorlage:
      <span class="wp_editoronly">{{#invoke:TemplatePar|
  4. Nicht verstanden habe ich, was gemeint ist mit: Dafür ist mir aufgefallen, dass der Vorlagenname mit [[]] umschlossen werden kann, was die Wartung für Dritte erleichtern dürfte.
    • Die Doku schreibt zum Parameter template: „Ein Wikilink ist darin ebenfalls möglich; etwa auf eine bestimmte Doku-, Hilfe- oder Projektseite.“
  5. „HLS“ gefällt mir auch nicht so ganz, selbst bei 10200 Einbindungen; Vorlage:HistLexBay und Vorlage:HistOrtsLexÖ sind da sprechendere Namen. Drei oder gar nur zwei Buchstaben für eng umgrenzte Spezialgebiete sind schwer verständlich und sollten eher Flagicons sein. ADB und NDB werden wenigstens projektweit benutzt.
Schönen Abend noch --PerfektesChaos 23:03, 5. Sep. 2013 (CEST)
Lässt sich alles in einer Einbindung machen – etwa so:
{{#invoke:TemplatePar|valid|1|N>0
|check
|all= 1=
|opt= 2= Autor=
|cat= Wikipedia:Vorlagen-Parameterfehler
|template= [[Vorlage:HLS]]
}}
oder muss dein obiger Code eigenständig eingebunden werden?
Bezüglich display:none sollte die Diskussion wohl am besten unter MediaWiki Diskussion:Common.css‎ stattfinden. --Leyo 00:03, 6. Sep. 2013 (CEST)
Nein; es sind zwei grundverschedene Funktionen; check und valid.
  • Von check kann es nur einen für die ganze Vorlage geben; odersollte nur einen geben.
  • Die valid kann es beliebig oft geben; für jeden Parameter einen mit einer spezifischen Regel und ggf. auch eine spezifische Wartungskat.
Wenn du übrigens 1 auf nicht-leere Zahl abfragst, solltest du es in check von |all= nach |opt= verschieben; sonst gibt es beim Fehlen des Parameters zwei Fehlermeldungen: Eine, dass es keine gültige Zahl ist, und eine, dass der Parameter fehlt.
Gute Nacht --PerfektesChaos 00:17, 6. Sep. 2013 (CEST)
Hm, mit {{#invoke:TemplatePar|valid|1|N>0}} von oben kriege ich in der Vorschau, beispielsweise bei Jean-Marie Ellenberger, die Fehlermeldung „#invoke:TemplatePar Parameter nicht angegeben“. Das sollte wohl nicht so (kryptisch) sein, oder? --Leyo 00:55, 6. Sep. 2013 (CEST)
Irgendwas spinnt da bei unbenannten Parametern.
  • Unbenannte werden mit numerischem Zugriff 1 verwaltet, was sich unterscheidet vom Zugriff über die Zeichenkette "1" oder "Autor" – taucht leider bisher nicht in den Testfällen auf.
  • Mit benannten geht es.
Muss ich am nahen Wochenende mal auseinanderklamüsern und eine weitere Testvorlage für unbenannten Parameter erschaffen.
Bis dann --PerfektesChaos 10:25, 6. Sep. 2013 (CEST)
Es ist so wie vorstehend vermutet.
Fix ist auf beta-wiki live.
Bevor ich das hier aufspiele, muss ich aber noch die Testseite ergänzen, und mir die Änderungen der letzten zwei Monate durchgucken; und vorsorglich über zusätzliche Pattern sinnieren.
Bei 192011 Einbindungen ist mir der Flurschaden zu heikel.
Eher Sonntag.
Wenn fertig, wäre es Zeit für einen sysop-Vollschutz.
Schönes Wochenende --PerfektesChaos 23:11, 6. Sep. 2013 (CEST)
Danke. Der dieser hohen Zahl an Einbindungen lohnt sich ein sorgfältiges Testen. --Leyo 00:24, 7. Sep. 2013 (CEST)
Update ist seit 24 Stunden scharf; ohne Fehlerkat oder aufgelaufene Beschwerden.
  • Vollschutz wäre dann fällig; die Programmierung ist ja relativ robust, wie die vergangenen zwei Monate bis vorgestern zeigten.
  • Das Lexikon sollte einen ähnlichen Hinweis {{Lua-Vorlage}} bekommen wie bei Vorlage:MwGit.
  • Mit min= und max= kannst du den Gültigkeitsbereich weiter einschränken, etwa auf 5- bis 8-stellige Zahlen.
VG --PerfektesChaos 23:54, 8. Sep. 2013 (CEST)
Vielen Dank! Vollschutz ist aktiv.
Betreffend Hinweis: Kommt dieser analog zu Vorlage:MwGit/Meta auf Vorlage:HLS/Meta?
Die min. und max. Stellen ist mir nicht bekannt. Von daher lasse ich es lieber. --Leyo 00:07, 9. Sep. 2013 (CEST)
  • Das
{{Lua-Vorlage|TemplatePar}}
kann auch ganz am Schluss von /Doku in <includeonly> eingeschlossen werden. Es sollte möglichst weit hinten stehen, weil für den Anwender der Vorlage völlig unwichtig: Hilfe:Vorlagendokumentation #Lua.
  • Gemäß Hilfe:Vorlagendokumentation #Meta-Daten kann das /Meta auch allmählich aufgelöst werden, wenn du sowieso schon dran bist und selbst löschen kannst. Es ist nicht mehr erforderlich und verkompliziert die Angelegenheiten nur noch unnötig.
Grüsse --PerfektesChaos 10:07, 9. Sep. 2013 (CEST)
Ich hab's in der Vorlage und der Doku eingebaut. Kategorie:Wikipedia:Vorlagen-Parameterfehler ist nun wieder gut gefüllt… --Leyo 15:40, 9. Sep. 2013 (CEST)

Defekte Vorlageneinbindungen finden

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

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

Modul:Vorlage:Flagicon

Ich habe mal (eher aus Langeweile) einen Anfang gemacht, die Flaggenvorlagen auf Lua umzustellen. Ein paar Anmerkungen mit Bitte auf Reaktionen:

  • Das Modul kümmert sich nur um die Vorlage an sich, nicht um die Dokumentation. Diese muss beim gegenwärtigen Ansatz weiterhin so eingebunden werden wie bisher. Das halte ich für die im Augenblick vernünftigere Lösung, zumal die Kategorisierung nicht einheitlich ist, und ich im Test eine hübsche Endlosschleife (Dokumentation bindet wieder Vorlage ein) hatte. Dass man innerhalb der Dokumentation die eine eigentlich parameterlose Einbindung durch einen Dummy-Parameter ergänzt, halte ich für extrem verwirrend.
  • Im Augenblick kennt das Modul alle offiziell anerkannten Länder, weitere kann man natürlich jederzeit (auch nachträglich) einbauen.

Der Vorlagencode wird durch das Modul vereinfacht zu {{#invoke:Vorlage:Flagicon|f|DEU}}, wobei DEU der jeweilige Code ist. Folgende Änderungen sind beabsichtigt:

  • Die Flagge hat immer das gleiches Linkziel wie der Text und verlinkt nicht mehr (wie noch bei einer Reihe von Flaggen) die Dateibeschreibungsseite.
  • Bei den meisten Einbindungen ohne Text wird auf den versteckten Sortierschlüssel verzichtet, die Sortierfunktion schaut inzwischen nämlich bei Bildern auf das alt-Attribut, sodass er in den meisten Fällen überflüssig ist. Nur bei Einbindungen mit Text oder wenn der Sortierschlüssel vom alt-Attribut abweichen soll, wird weiterhin ein versteckter Text verwendet. Zudem sind inzwischen auch Umlaute im Sortierschlüssel kein Problem mehr und werden beibehalten.
  • Bei Einbindungen mit Text wird explizit ein leeres alt-Attribut gesetzt, bisher kommt es zu äußerst unschönen Duplikaten.

Ich habe mal Versionen von DEU, KOR und STP mit diesem Modul erstellt, und auf Benutzer:Schnark/Flaggen getestet. In meinem Offline-Wiki war ich mutiger und habe dort Vorlage:DEU direkt umgestellt, ohne erkennbare Probleme. Trotzdem kann ich bei fast 200 Vorlagen mit unzähligen Einbindungen natürlich nicht sicher sein, dass es nicht doch noch Probleme gibt. Insbesondere: Das Modul bekommt sämtliche Whitespaces in den Parametern. Die sollten zwar eigentlich nicht schaden, aber schaden sie tatsächlich nicht? Ich brauche also noch mindestens ein zweites Paar Augen, das sich den (eigentlich ziemlich trivialen) Code anschaut, und einen Mutigen, der einfach mal ein paar Flaggenvorlagen umstellt. --Schnark 09:58, 23. Sep. 2013 (CEST)

Ja, da schau her! Hübsch. Und das ist dein Erstling?
  • Einen ersten Tipp hätte ich: Trennung von Programm und Daten.
  • Als Tabelle würde ich eine sequence pro Land nehmen (Array statt Objekt), also etwas wie
    "BLR" = {"Flag of Belarus.svg", "Weißrussland", true},
    und das Ganze nach Art eines Objekts in eine große Klammer
    return { "AFG" = {...}, "AGO" = {...}, ...};
  • Ein weiterer Parameter müsste ein "GER" für Deutschland sein, also ein Alias, der in den bisherigen Weiterleitungen die Definition von "DEU" ausnutzt.
  • Doku: Der Inhalt der Dokuseite sollte normaler Wikitext sein, aber mit Parametern aufgerufen werden (nämlich der gerade angekuckten Flagge, ihres Kürzels, Ländernamens und Icons) und statt Einheitsbrei genau die jetzt angeguckte Einzelvorlage dokumentieren. Ansonsten der Text der bisherigen Doku, vermehrt um spezifisches TemplateData per #tag:. Einen Parameter extra bräuchte es vielleicht noch, um die von dir gemutmaßte Endlosschleife zu verhindern; es gibt aber im Vorlagen-NR auch eine andere Lösung: Sich den Quelltext der obersten einbindenden Seite anzugucken, und wenn der anfängt mit {{#invoke:Vorlage:Flagicon wie bei Benutzer:Schnark/Flaggen/DEU, dann bin ich im Doku-Modus.
  • Details der Einzelfunktionen hatte ich mir noch nicht angeguckt.
  • Möglichst vielfache Olympia-Seite suchen und dort Performance messen; bzw. Dummy mit entsprechender Anzahl generieren.
  • Für eine Fortsetzung der Disku würde ich vorschlagen: /Flagicons.
Liebe Grüße und eine schöne Woche --PerfektesChaos 11:00, 23. Sep. 2013 (CEST)
  • Dass das Modul auf einer einzigen Seite untergebracht ist, hat etwas mit meinem Offline-Testprozess zu tun, WP:XOWA kann keine neuen Seiten erstellen, nur vorhandene ändern, und da es nur ein entbehrliches Modul:Spielwiese gibt, konnte ich auch nur ein Modul verwenden.
    • Eventuell sollte man sogar drei Daten-Untermodule verwenden: Eines für Codes ohne Bindestrich, eines für Codes mit Bindestrich und einer Zahl am Ende (historische Flaggen) und eines für Codes mit Bindestrich ohne Zahl.
  • Sehe ich anders. Bei border = true weiß jeder, was das true bedeutet, bei deiner Variante nicht, dazu kommen noch Parameter für abweichendem Text oder abweichendem Sortierschlüssel, die man dann beide angeben müsste und trotzdem nicht gleich wüsste, was sie bedeuten.
  • Solange Vorlage:GER eine Weiterleitung bleibt (und es gibt keinen Grund, warum sie das nicht bleiben sollte), sind die Aliase im Modul überflüssig.
  • Vorlage:DEU hat eine zusätzliche Kategorie, Vorlage:VAT nicht. Solange da nicht aufgeräumt und vereinheitlicht wird, ist jeder Versuch die Dokumentation automatisch zu erstellen, ein Hack.
  • Da ich Diskussionen grundsätzlich im Quelltext lese und zu antworten beginne, bevor ich sie ganz durchgelesen habe, antworte ich hier, wenn du verschieben willst, dann verschiebe.
--Schnark 11:18, 23. Sep. 2013 (CEST)
  • Drei Daten-Untermodule wären arg verwirrend für das Pflegepersonal, auch wenn Programmierer damit effizienter umgehen könnten. Weil das Programm-Modul irgendwann vollgeschützt wäre, die Datentabelle nur halb, soll ja jeder analog zu anderen Einträgen neue Flaggen hinzufügen können. Als Pfleger würde ich auch Volltextsuche einsetzen wollen: Welchem Code ist Datei XY.svg zugeordnet; gleiches Bildchen für unterschiedliche Namen wird wann verwendet? Müsste schon auf einer Seite beisammen sein.
  • Mal die sonstigen in Frage kommenden Parameter zusammentragen und gucken.
  • Ein Grund wäre, dass unterschiedliche Anzeigecodes benutzt werden: Verwende DEU für den Zugriff auf die Definition, aber GER für die optische Darstellung. Ein anderer wäre Performance für das Folgen der WL, aber das machen wir durch aufwändigere Progammierung schon wieder kaputt.
    • Wobei man darüber nachdenken kann, die Aliasse in die zentrale Datentabelle aufzunehmen, und wenn deren Wert kein table sondern string ist, dann ist es ein redirect. Dann hätte man sämtliche gültigen Codes auf einer Seite zusammen und kann daraus durch separates Modul eine Wartungstabelle aller Codes und aller Icons und aller Seiten generieren.
  • Das Aufräumen mit überkommenem Kategorienchaos wäre Nebeneffekt einer solchen Aktion; ich hatte mich damit noch nicht näher beschäftigt. Vielleicht ist es aber kein Chaos, sondern eine Systematik dahinter. Vielleicht genügt ein Flag, um den bekannten Landesnamen zur Generierung einer Zweitkategorie für aktuelle Staaten zu benutzen. Wobei Vatikanstaat ein aktueller Staat ist. Müsste sich ein Flaggensystematiker zu äußern.
    • Die Extra-Kats können sogar außerhalb der Doku direkt in der klassischen Vorlagenseite ins noinclude und müssen nicht von der eingebundenen Wikitext-Doku generiert werden.
    • Spezifische Doku-Generierung einschließlich spezifischem TemplateData müsste schon in eine Konzeption aufgenommen werden, um langfristig einen Mehrwert zu erhalten.
  • Was primär wichtig wäre, sind Hilfe:Vorlagenbeschränkungen: Bei einer unserer Olympia-Seiten mit allen Leichtathletik-Ergebnissen kommen wie viele Flagicons vor? Wenn man in dieser Anzahl zwei Dummies generiert, wie schrammen Luas CPU-Sekunden gegen Nodecount usw. im Verhältnis zum Maximum?
  • Verschieben der Disku hat Zeit; passiert dann gelegentlich. Aber dortige WD zur Kenntnis nehmen.
LG --PerfektesChaos 12:20, 23. Sep. 2013 (CEST) (nach BK)
Die jetzige Lösung bewirkt, dass sämtliche Änderungen und Erweiterungen dazu führen, dass das Modul neu gerendert und alle Seiten mit Flagicons ungültig werden. Es kommen immer wieder mal Vorlagen zu historischen Flaggen dazu. Das sollte auch ohne Eingriff ins Modul möglich sein, denn das schränkt die autorenfreiheit stark ein. ÅñŧóñŜûŝî (Ð) 12:29, 23. Sep. 2013 (CEST)
Ich bin für eine zentrale Vorlage für die Gestaltung der Flaggenvorlagen, aber für eine dezentrale Haltung der notwendigen Informationen, bei der alten Flagicons Vorlage ist es auch zeitlang gut gegangen, bis jemand alle möglichen Kombinationen eingetragen hat und die Aufrufzeiten explodiert sind, wird hier wohl weniger sein, aber ein rerendern wird es wohl auch geben, wenn etwas hinzugefügt wird, siehe auch Wikipedia Diskussion:Lua/Werkstatt/Flagicons. Der Umherirrende 18:18, 23. Sep. 2013 (CEST)
Anzahl Untermodule
  • Zwar bin ich Fan eines einzigen Untermoduls, könnte mich jedoch pragmatisch zu einer Zweiteilung hinreißen lassen:
    1. /base enthält alle Codes, deren Länge in Bytes [sic!] genau 3 beträgt.
    2. /plus enthält alle anderen Codes mit deren Zuweisung.
  • Das erste Untermodul deckt alle zeitgenössischen Codes (einschließlich DDR usw.) ab.
    • Hier ändert sich nur sehr selten was.
    • Das Untermodul kann nach einer Weile Erprobungszeit auch vollgeschützt werden, wenn alle Codes eingesammelt und richtig zugeordnet wurden.
    • Die allermeisten Seiten betreffen Wettbewerbe usw. nur mit solchen zeitgenössischen Staaten.
  • Das andere Untermodul enthält historische und Sonderformen.
    • Hier kommt sicher mal irgendein historischer Wimpel dazu.
    • Betroffen sind aber zahlenmäßig wenige Schlachten und Kolonien und olle Segler.
    • Halbschutz sollte reichen, der Flurschaden bleibt fünfstellig.
  • Für das Pflegepersonal ist die Unterscheidung zwischen den beiden Untermodulen simpel: Entweder es sind drei Buchstaben, dann muss ich für das ggf. vollgeschützte /base Entsperrung oder Admin-Edit beantragen, oder es ist irgendwas anderes, dann kann ich selbst das andere Untermodul bearbeiten.
@Schnark
  • Auf deiner Festplatte müsstest du das oben erwähnte Modul:Multilingual/codes haben, das kannst du schrotten. Ist nur prophylaktisch erstellt und momentan nirgendwo produktiv verwendet. Modul:Citation war nur Spaß und kann mutterseelenallein sowieso nicht funktionieren, kannst du überschreiben.
  • Eine Weiche für die lokale Erprobungsversion müsstest du mit Hilfe:Lua/Umgebung #site.server usw. einbauen können, um den Code hin und her zu schwappen.

LG --PerfektesChaos 16:03, 23. Sep. 2013 (CEST)

Ich habe nach etwas Überlegen gerade die Flagge entlinkt, wenn ohnehin ein Link folgt:
  • Da der alt-Text leer sein sollte, würde da sonst ein Link stehen, der keinerlei Text hat. Eigentlich sollten Screenreader so klug sein und erkennen, dass sie den Link dann ignorieren sollen, aber bei Screenreadern ist der Unterschied zwischen Theorie und Praxis leider oft erstaunlich groß.
  • Auch für Sehende ergaben sich bisher wiedersinnige Kombinationen, dass der Tooltip der Flagge nichts mit dem Linkziel oder der Beschriftung zu tun hatte, und somit nicht klar war, wohin der Link eigentlich führt.
Insofern ist es für alle besser, wenn die Flagge unverlinkt bleibt. Zum Vergleich: In en sind die Flaggen auch unverlinkt. --Schnark 09:55, 24. Sep. 2013 (CEST)

Zeitbedarf von Modul:Vorlage:Flagicon testen!

Habt ihr schon mal getestet, was bei 1000 Einbindungen auf einer Seite geschieht? Insbesondere der Parseraufwand ist wichtig! Die Vorlage Flagicon wurde zu gunsten einer dezentralen Lösung gelöscht, weil ihr umfangreicher Code bei 1000 Einbindungen zu langen Ladezeiten und Gateway-Timeouts führte. Bevor an diesem Modul weitergearbeitet wird, muss erst einmal getestet werden, ob es bei 1000 Einbindungen auf einer Seite keine Probleme gibt! ÅñŧóñŜûŝî (Ð) 12:05, 23. Sep. 2013 (CEST)

Benutzer:Schnark/Flaggen/1000 braucht lange, kommt aber ohne Fehler zum Ende, auch die Werte von Benutzer:Schnark/Flaggen vs. Medaillenspiegel der Olympischen Sommerspiele 2012 sehen gut aus. Hast du ein Realbeispiel mit 1000 Flaggen? --Schnark 12:16, 23. Sep. 2013 (CEST)
Zum Testen siehe auch meine Bemerkung oben 11:00: Möglichst vielfache Olympia-Seite suchen und dort Performance messen; bzw. Dummy mit entsprechender Anzahl generieren.
VG --PerfektesChaos 12:20, 23. Sep. 2013 (CEST)
Ich kan mich daran erinnern, dass ich bei der Umstellung Seiten mit mehr als 1000 Einbindungen hatte. Welche das sind, weis ich aber nicht mehr. Es waren jedenfalls Seiten in der "Sportbranche". Das Modul muss jedenfalls sehr schnell sein und alle Features der jetzigen dezentralen Lösung umsetzen. ÅñŧóñŜûŝî (Ð) 12:29, 23. Sep. 2013 (CEST)

Benutzer:Schnark/Flaggen/1000 liegt über 10 Sekunden real, müsste eigentlich angemeckert werden?

  • Die zweite Tabelle wird nicht gerendert, ist da ein Syntaxfehler oder ein Streik?
NewPP limit report
CPU time usage: 12.233 seconds
Real time usage: 14.805 seconds
Preprocessor visited node count: 37546/1000000
Preprocessor generated node count: 83529/1500000
Post‐expand include size: 952666/2048000 bytes
Template argument size: 235279/2048000 bytes
Highest expansion depth: 4/40
Expensive parser function count: 0/500
Lua time usage: 1.048s
Lua memory usage: 1.05 MB
Lua Profile:
    recursiveClone <mw.lua:109>                                      520 ms     44.8%
    [main chunk] <Modul:Vorlage:Flagicon>                            280 ms     24.1%
    Scribunto_LuaSandboxCallback::getExpandedArgument                120 ms     10.3%
    type                                                              80 ms      6.9%
    recursiveClone <mw.lua:109>                                       60 ms      5.2%
    (for generator)                                                   60 ms      5.2%
    ?                                                                 20 ms      1.7%
    [others]                                                          20 ms      1.7%

Wie zu erwarten: node counts, size, depth usw. liegen im einstelligen Prozentbereich. Harmlos.

  • Wie sieht der Report der gleichen Seite mit klassischen Vorlagen aus?

VG --PerfektesChaos 16:03, 23. Sep. 2013 (CEST)

Hallo. Die zweite Tabelle funktioniert jetzt, nachdem ich einen Zeilenumbruch davor ergänzt habe. Gruß --Tlustulimu (Diskussion) 21:03, 23. Sep. 2013 (CEST)
Ich kann mir ehrlich gesagt keine wirklich sinnvolle Seite mit deutlich mehr als 300 Einbindungen vorstellen, Wimbledon Championships 2013/Damendoppel ist das Extremste, das ich gefunden habe. --Schnark 09:55, 24. Sep. 2013 (CEST)
Ich muss auf 600 erhöhen: Liste der Weltmeister im Grasskilauf, sollte aber trotzdem kein Problem sein. --Schnark 12:19, 24. Sep. 2013 (CEST)