Wikipedia:Lua/Werkstatt/Archiv/2015

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Nur eine Idee

Hallo, ich schraub gerade mal wieder an meinem Modul herum, wobei ich mir folgende Frage stellte: Ist es möglich mit Lua den Wiki-Quelltext einer bestimmten Seite auszulesen? sollte das klappen wäre mir die Idee gekommen, dass man Vorlagen wie Vorlage:Navigationsleiste Kader des FC Bayern München oder auch Vorlage:Navigationsleiste Die zehn bestplatzierten deutschen Tennisspielerinnen (WTA) bei der Einbindung auf eine Seite überprüfen kann ob die Seite in der Navileiste verlinkt ist und dann dementsprechend die Leiste anzeigt oder ausblendet. Geht das mit dem auslesen? Wenn ja, frage ich mal beim Portal:Sport nach ob sie so etwas brauchen können. Gruß, Korrektor123 (Diskussion) 17:42, 28. Apr. 2015 (CEST)

Ist möglich, klingt aber sehr aufwendig (für die Hamster, nicht unbedingt für die Implementation). Die Navileiste für die 10 besten ist bestenfalls fragwürdig. --mfb (Diskussion) 21:57, 28. Apr. 2015 (CEST)
Was meinst du mit für die Hamster? --Korrektor123 (Diskussion) 14:43, 30. Apr. 2015 (CEST)
Wikipedia:Hamster – SCNR --PerfektesChaos 14:53, 30. Apr. 2015 (CEST)
Gut, ich kenne mich mit den "Hamstern" nicht so gut aus um zu sagen ob sie das vertragen oder nicht. Ich glaube aber, dass es nicht ganz so aufwändig für sie ist, da das Modul nicht ständig durchlaufen wird, sondern nur wenn eine Seite mit entsprechender Vorlageneinbindung bearbeitet oder das Cache geleert wird. Vielleicht kann man ja noch etwas zur Erleichterung einbauen: Bei den Tennisspielern ist das zumindest so, dass eine entsprechende Einbindung nicht abgefragt werden muss, wenn ein Spieler Inaktiv ist. Außerdem müsste das Modul ja aus dem Navileisten-Quelltext nur herausfinden ob [[SEITENNAME| oder [[SEITENNAME]] vorhanden ist und dementsprechend 1 oder 0 zurückgeben. --Korrektor123 (Diskussion) 16:15, 30. Apr. 2015 (CEST)
Aber woher soll Seite A wissen, wann der Cache geleert werden sollte, ohne die Seite erneut zu parsen um die nichttriviale Abhängigkeit zu finden? Was einfacher ginge, wäre, eine Artikelliste in der Navileiste zu führen, getrennt vom normalen Inhalt der Navileiste. {{#switch:{{PAGENAME}}|Artikel1|Artikel2=eigentliche Navileiste fuer diese Artikel|#default=ggf. Inhalt fuer andere Artikel}} --mfb (Diskussion) 16:29, 30. Apr. 2015 (CEST)
Die oben vorgeschlagene Systematik klingt mir sehr konfus.
Das würde bedeuten, dass man bei 100 Tennisspielern oder 10000 Fußballspielern auf Verdacht die Vorlage für die TopTen oder alle Kader von Bayern, BVB, Hertha, Werder, Manu, Real, Ajax, Rot-Weiß Erfurt, Olympiakos Piräus, … einbindet; und immer dann, wenn die zufällig in die TopTen oder in den jeweiligen Kader geraten oder wieder wechseln, blenden sich die jeweiligen Navileisten ein oder aus?
Das würde auch bedeuten, dass in Tausenden von Spielerartikeln ständig Dutzende von Navileisten analysiert werden müssen, ob der jeweilige grad drin verlinkt ist oder nicht.
Wir machen das eigentlich anders: Wenn jemand zu St.Pauli wechselt, wird die Navileiste aktualisiert und bei dem Spieler reingesetzt, vermutlich eine andere dafür entfernt; wenn er da wieder rausgeht oder ins Gras beißt, wird die Navileiste aktualisiert und bei dem Spieler entfernt.
VG --PerfektesChaos 17:25, 30. Apr. 2015 (CEST)
Auf Verdacht bei allen wird das sicher nichts, ich vermute das ist für spezielle Bereiche gedacht bei denen sich die Zugehörigkeit schneller ändert. Aber ob dort die Navileiste wichtig ist, ist auch fraglich. --mfb (Diskussion) 17:41, 30. Apr. 2015 (CEST)

Also. Erstens, das mit dem Cache leeren muss man noch manuell machen. Zweitens, mit der Vorlageneinbindung: Ich hatte da die Idee, dass man zumindest beim Tennis mehrere Vorlagen kombinieren könnte. So sind z. B. die Vorlagen ITF und WTA oder ATP bei jedem Tennisspieler drin. Diese würde ich zu einer Vorlage zusammenfassen, welche noch einen Extraparameter mit dem Lemma der Navileiste hat; bei deutschen Tennisspielerinnen wäre das dann die oben genannte. Meiner Vorstellung nach sollte das so gehen, dass man die Navileiste per Hand aktualisiert und anschließend nur einmal das Cache einer neu in die Navileiste eingetragenen Seite leeren muss, damit die Leiste in dem entsprechenden Artikel auftaucht. Gut beim Fußball ändert sich der Kader nicht ganz so oft, dass so ein Modul eine Arbeitsersparnis brächte. --Korrektor123 (Diskussion) 17:49, 30. Apr. 2015 (CEST)

Die Technik ist ja nur sinnvoll, wenn ausnahmslos alle in Betracht kommenden Personen schon die schlummernde Vorlage enthalten. Aber sobald so ein Ereignis stattfindet, ändert sich ja auch der allgemeine Text des Artikels: Am x. Februar gelang ihr der Einzug in die TopTen der Weltrangliste … am y. November wechselte er gegen eine Ablöse von 100 Millionen Euro vom HSV zu den Grashoppers … und dann wird sowieso mitsamt Textbearbeitung die Navileiste ausgetauscht. LG --PerfektesChaos 17:56, 30. Apr. 2015 (CEST)
Das mag sein, dass der eigentliche Artikel auch bearbeitet wird wenn ein spieler zum ersten mal in seiner Karriere in die TopTen der Welt einzieht. Es gibt aber auch die Navileisten für die 10 bestplatzierten des jeweiligen Landes und da wird nicht jedesmal der ganze Artikel bearbeitet. Außerdem ist es möglich das ein Spieler aus den TopTen heraus fällt und ein paar Wochen später wieder drin ist. Auch solche Fälle werden nicht jedes mal im Artikel "eingetextet". Des weiteren frag ich wie oben schon erwähnt eh noch im Portal:Sport nach wer noch interesse daran hat. Fürs Tennis wäre eine solche Vorlage IMO auf jeden Fall eine Erleichterung. --Korrektor123 (Diskussion) 18:22, 30. Apr. 2015 (CEST)
Nun, die Navileiste muss ja eh geändert werden, andernfalls geschieht gar nichts. Dazu muss man sowieso schauen, ob der neue Spieler nun zum ersten Mal in den Top10 ist (und somit ggf. die Navileiste noch nicht hat, und vielleicht auch eine Erwähnung im Fließtext bekommen sollte). So viel Arbeitsersparnis sehe ich da nicht. Für die Top10 vielleicht per switch vorstellbar, dann wird das Bearbeiten der Navileiste etwas aufwendiger, dafür fallen gelegentlich Artikeledits weg. Aber der Sinn der Top10-Navileiste erschließt sich mir auch nicht (das ist eher ein Fall für einen Listenartikel). --mfb (Diskussion) 18:50, 5. Mai 2015 (CEST)

Nachdem ich auf meine Anfrage keine Antwort erhalten habe bin ich wohl der einzige der so etwas für nützlich hält. Für mich hat sich die Sache also erledigt. --Korrektor123 (Diskussion) 12:25, 1. Jun. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Korrektor123 (Diskussion) 12:25, 1. Jun. 2015 (CEST)

Unbegrenzte Zeilenanzahl

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

+1, bin ebenfalls heute auf selbe Problematik gestoßen, Taylor Swift/Diskografie#Singles benötigt bis zu 15 Zeilen, wenn man die Vorlage:Charttabelle verwenden möchte. lg--Tkkrd (Diskussion) 11:38, 7. Okt. 2015 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: ist praktisch gelöst --XanonymusX (Diskussion) 13:11, 24. Sep. 2017 (CEST)

Performance

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

Nein, das kann die Parserfunktion sofort direkt schneller beantworten, als wenn sie erst noch Lua-Code ggf. byte-kompilieren, laden und ausführen müsste.
Allgemein müsste (zumindest in dewiki) die Performance-Verbesserung schon signifikant sein, oder eine klassisch nicht erreichbare Funktionalität hergestellt werden, damit Lua eingesetzt würde. Die Zahl der Leute, die Lua-Code ändern könnten, ist wesentlich kleiner als die der potentiellen Vorlagenprogrammierer. Heißt: wenn Lua, dann kommen die Normalos nicht mehr dran; und wohl fast alle Admins stünden außen vor.
LG --PerfektesChaos 13:34, 8. Feb. 2015 (CET)
Ach* danke für dein informatives Resume. Habe umseitig den Abschnitt Performance-Messungen „Gerade gesehen: en:User:Dragons flight/Lua performance mit sehr interessanten Messungen, um wieviel schneller Lua sein kann. (Raymond)“ Deine Aussage könnte/sollte man doch irgendwie auf Hilfe Lua unterbringen!? PS: Ich habe gerade den Code der verlinkten Vorlage geändert, da würde mich jetzt so eine Performance-Messung auch interessieren! Ist bestimmt aufwendig oder ist da was zum Testen bekannt? ↔ Benutzer: Perhelion  14:43, 8. Feb. 2015 (CET)
  • Naja, eine allgemeine Aussage steht da ja: Hilfe:Lua #Begrenzungen.
    • Performance-Messung ist relativ: Wenn man eine komplexe Vorlagenprogrammierung mit Untervorlagen und Parserfunktionen komplett ersetzen kann, bringt es was, sonst kaum. Ist aber schwer allgemein zu fassen.
  • Du müsstest 400 Einbindungen hü oder hott abarbeiten und mittels Hilfe:Vorlagenbeschränkungen vergleichen.
LG --PerfektesChaos 15:34, 8. Feb. 2015 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:27, 30. Apr. 2018 (CEST)

Vorlagenverkleinerung

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

Das mag sein, dass sich das mit Lua anders lösen ließe.
  • Bei einem schnellen Drübergucken sehe ich allerdings nichts, was Lua zwingend angeraten sein ließe: Keine Berechnungen, keine Analysen von Zeichenketten, einfach nur klassische Formatierung.
  • Das ist mit konventioneller Vorlagenprogrammierung zu leisten. Die hat den Vorteil, dass es dazu Hunderte von Programmierern gibt, die sich weiter darum kümmern könnten; zu Lua nur eine Handvoll, von denen wohl die meisten sehr gut ausgelastet sind.
  • Hundertfach eingebunden und Performance-Problem sehe ich grad nicht; die Gesamt-Tabelle gibt es offenbar nur einmal pro Artikel, und dann kommen halt Zeilen pro Jahr; mit mehreren Titeln im Jahr. Naja, das machen wir von Denkmal über Bahnstrecke bis NSG routinemäßig.
    • Nur das Arbeiten mit unbegrenzt vielen Songs innerhalb eines Jahres wäre mit Lua offener zu gestalten; geht aber auch erträglich und schrankenlos ohne Lua, jedoch weniger elegant. Es wird auch kaum eine Band 150 Platten in einem Kalenderjahr herausgebracht haben.
  • Hingegen habe ich mit der Konzeption dieser Vorlage mehrere massive Bauchsmerzen:
    • Es scheint mir auf den ersten Blick der gleiche Nutzinhalt zu sein, der auch in der bereits 7854× eingebundenen Vorlage:Infobox Chartplatzierungen kompakt und übersichtlich und flexibel dargestellt wird; bloß auf der zwanzigfachen Bildschirmfläche ausgewalzt.
    • Die angestrebte Vorlage ist statisch und sklavisch an genau fünf Länder gebunden; D-A-CH + UK/US.
      • Wenn das Herkunftsland des Songs nun aber Finnland oder Island oder Italien ist, dann tauchen im Unterschied zur bisherigen Infobox die Charts im Ursprungsland nicht auf. Irgendwie habe ich die Richtlinien für Chartplatzierungen anders im Hinterkopf, aber damit wenig zu tun.
      • Wenn das Stück oder der Interpret nun aber nur im deutschsprachigen Raum aktiv war/ist, und es nie oder nur einmal einen Übersee-Erfolg wie mit Nena oder Falco gab, dann stehen dort die nie oder fast nie genutzten Spalten herum. Oder Schweizer, die außerhalb der Schweiz nur selten wahrgenommen wurden?
    • Soll die beabsichtigte neue Tabellenvorlage die Einbindung der bestehenden Vorlage:Infobox Chartplatzierungen denn ersetzen, oder sollen beide gleichzeitig im Artikel vorkommen, oder was?
  • Persönlich habe ich ungeachtet technisch-konzeptioneller Auskünfte den Eindruck, dass Verkaufszahlen wenig über die Qualität eines Kunstwerks aussagen. Acht Wochen auf Platz 1 oder in den Top Ten sind sicher enzyklopädisch relevant; aber von 26 Stücken in den USA eines mal für zwei Wochen auf Platz 67? Was sagt mir das? WP ist keine Datenbank. Vielleicht eher irgendwann mal auf Wikidata zu dokumentieren, nachdem dort Vandalismusschutz und Datenpflege geklärt wurden.
VG --PerfektesChaos 12:13, 14. Mär. 2015 (CET)
Danke für deine Stellungnahme! Allerdings hast du dich zuletzt mehr inhaltlich gegen die Wikipedia:Formatvorlage Charts ausgesprochen (oder zumindest Zweifel daran geäußert), wozu aber nicht hier, sondern wenn schon in der Wikipedia:Redaktion Musik der richtige Ort wäre. Ich darf dir aber verraten, dass das schon unzählige Male durchdiskutiert wurde und der Einsatz der Charttabelle im Musikbereich eigentlich unstrittig ist (und in praktisch jeder einzelnen der Kategorie:Diskografie zum Einsatz kommt, nur eben ohne Vorlage); somit etabliert die Vorlage nicht etwa etwas Neues. Und ja, letztlich ersetzt die Charttabelle die Infobox, aber auch das war schon bislang so vorgesehen. Die Fixierung auf DACHUKUS ist im Übrigen gar nicht so streng; auch so etwas ist kein Problem; vielleicht hast du die Funktionalitäten noch nicht so genau angeschaut?
Wenn du aber technisch keine Probleme siehst, bin ich beruhigt. Vielleicht magst du dich ja in dieser Diskussion dazu äußern? Andere sind der Meinung, dass die Vorlage so nicht verwendet werden kann. Übrigens: Einmal pro Seite stimmt so nicht, in den Diskografien wird zumindest nach Singles und Alben, häufig aber auch nach Studioalben, Livealben, EPs, … unterteilt; da kommt schon was zusammen. Grüße, XanonymusX (Diskussion) 12:27, 14. Mär. 2015 (CET)
Können wir die Diskussion bitte an einer Stelle führen und nicht an fünf? --mfb (Diskussion) 18:26, 14. Mär. 2015 (CET)
Ja, klar, das war auch der Plan (wobei ich meine Diskussionsseite eigentlich nicht für den geeigneten Ort halte). @PerfektesChaos: Also weiter wie verlinkt! ein lächelnder Smiley  --XanonymusX (Diskussion) 13:20, 15. Mär. 2015 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:27, 30. Apr. 2018 (CEST)

Problem mit mw.language.fetchLanguageNames

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

  • Wo exakt die wirksame Definition steht, müsste ich erst suchen; ist aber erstmal egal.
    • Irgendwo in MW/* – darunter languages/Names.php und irgendwo anders.
    • translatewiki kann aber daran beteiligt sein; im Sinne von Upstream – Bots spielen translatewiki-Infos in die Software ein.
    • translatewiki:CLDR ist eine der wesentlichen Quellen.
  • phab:T39704 beschäftigt sich bereits mit dieser Angelegenheit.
  • Es gibt eine Matrix 555×555 Zuordnungen.
    • Von denen ist der englischsprachige und der Sprachname in der eigenen Sprache selbst recht zuverlässig besetzt.
    • Der Rest kommt anscheinend teils aus ISO-Datenbanken (ISO 639 / SIL), anderen heruntergeladenen Listen und der Sachkunde irgendwelcher muttersprachelnden Programmierer, die das im vergangenen Jahrzehnt bei den zu ihrer Zeit bekannten Definitionen reingeschrieben haben.
    • Das ist also etwas Glückssache. Wo nichts anderes bekannt ist, fällt die Matrix auf englisch zurück; insbesondere bei erst in den letzten Jahren neu entstandenen Wikipedien, die dann zwangsläufig etwas exotischer sind als die alteingesessenen Wikis, und die zwischenzeitlich noch keiner eingedeutscht hatte. Wenn ein neuer Sprachname hinzugefügt wird, bekommt er zunächst nur autochthon und englisch.
  • Mit mw.language.fetchLanguageNames("eo","all") bekommst du eine table und kannst das leichter durchgehen; einfach eine Testseite mit einer wikitable daraus generieren.
  • Wenn du eine maschinenlesbare Wiki-Tabelle aufmachst mit insgesamt 50 oder 100 besseren Bezeichnungen in eo, dsb, hsb, de – dann wird sich auch sicher der Weg finden lassen, an welcher Stelle das in die Wiki-Programmierung eingespeist werden kann. Für immer 2 oder 3 Sprachnamen einzeln anzudackeln ist weniger aussichtsreich.
  • Es könnte sein, dass deine Einspeisung dem Common Locale Data Repository zugute käme; und damit allen Internetnutzern über die Wikis hinaus.
  • Der genaue Weg der Cross-Übersetzungen in das Wiki ist mir auch nicht so ganz klar.
LG --PerfektesChaos 13:36, 13. Apr. 2015 (CEST)
Nachtrag:
  • Deine Mühen um bessere Übersetzungen wären jedenfalls nicht umsonst.
  • Ich könnte die Bibliothek Multilingual ergänzen um eine Funktion fetchLanguageName().
    • Dann würde man statt mw.language.fetchLanguageName() aufrufen: Multilingual.fetchLanguageName().
    • Das würde auf einem noch zu erstellenden Modul:Multilingual/names beruhen.
    • Modul:Multilingual/codes gibt es bereits in gleicher Art; ist zurzeit ohne Verwendung, weil später mw.language verfügbar wurde und jenes das vermutlich abdeckt.
    • Ein Modul:Multilingual/names wäre eine Tabelle, bei der ein Rückgabewert aussehen würde wie
      tNames.eo.en = "angle"
    • In Modul:Multilingual/names würden alle Namensübersetzungen festgehalten, bei denen du besser als mw.language bist.
    • Die neue Funktion Multilingual.fetchLanguageName() würde zuerst versuchen, in einem Modul:Multilingual/names etwas Besseres zu finden; wenn das nicht gelingt, dann erst den Wert von mw.language.fetchLanguageName() zurückgeben.
    • Damit wäre man schneller als der große Dienstweg.
  • Der Inhalt dieses Untermoduls kann gleichzeitig als Anregung für translatewiki, MW und CLDR aufbereitet werden; auf dass die sich bessern mögen.
    • Wenn das soweit wäre, können die von oben dazugelernten Einträge wieder entfernt werden.
Gxis --PerfektesChaos 14:18, 13. Apr. 2015 (CEST)
@PerfektesChaos: Esperanto funktioniert mit der Funktion mw.language.fetchLanguageName() ziemlich bescheiden. Guck dir mal {{#invoke:Lingvonomo|list}} auf der Seite Vorlage expandieren auf der Esperantowikipedia an. Wie kann ich die ausgegebene Tabelle eventuell sortieren? Gruß --Tlustulimu (Diskussion) 15:04, 13. Apr. 2015 (CEST)
Aus Names.php kommen nur die Eigennamen, alle anderen Namen zu den Sprachen kommen aus CLDR (über mw:Extension:cldr). Eine eigene Tabelle für die Sprachennamen würde ich nicht aufmachen, auch wenn die Aktualisierung über CLDR etwas dauern mag, das sind OpenData die auch in anderen Bereichen einfließen, beispielsweise die ToolTipps bei "In anderen Sprachen" oder sogar in Programmiersprachen wie Java oder so. mw.language.fetchLanguageName nutzt die gleichen Daten wie die #language Parser-Funktion (эсперанто). Falls du also nur einen Wert für eine Sprache an einer Stelle brauchst, braucht es dafür kein Modul, sondern es geht einfacher. Ob es eine performante stabile Sortierroutine in lua gibt, kann ich nicht sagen, ein "sortable" hilft aber erstmal für die Übersicht ;-) Der Umherirrende 20:11, 13. Apr. 2015 (CEST)

@Tlu:

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

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

@PerfektesChaos: languages = table.sort(languages) hat leider gar nicht funktioniert. Ich habe es aber geschafft, den Kram zu sortieren. :-) Der Kode sieht so aus:
-- list returns all language from the function mw.language.fetchLanguageNames in a wikitable
function _list (args)
	local r = '{| class="wikitable sortable"\n'
	r = r .. "|-\n" .. "! Kodo !! Nomo\n" -- head of the table
	local languages = mw.language.fetchLanguageNames("eo","all")
	local a = {}
	for n in pairs(languages) do a[#a + 1] = n end
	table.sort(a)
	for index, code in pairs(a) do
		local name = ""
		for c, n in pairs(languages) do
			if (c == code) then 
				name = n
				break
			end
		end
		r = r .. "|-\n" .. "| " .. code .. " || " .. name .. "\n"
	end
	r = r .. "|}\n"
	return r
end
Das Ergebnis der Sortierung ist in der Moduldokumentation schön zu sehen. Gruß --Tlustulimu (Diskussion) 11:34, 14. Apr. 2015 (CEST)
  • Sortierung
    • Ah, mein Fehler, das war die Sortierung einer sequence gewesen, also einem Array vergleichbar.
    • Hier geht es ja um ein Objekt, und da läuft das etwas anders:
      1. Hilfsarray = sequence aus den Schlüsseln bilden
      2. Dieses Hilfsarray wie beschrieben sortieren
      3. Anschließend die Auswertung in der Reihe des Hilfsarrays vornehmen, und über dieses auf die Objektkomponenten vornehmen.
    • Bei einem Objekt ist es (in praktisch jeder Programmiersprache) beliebig, in welcher Reihenfolge die Komponenten zurückgegeben würden, wenn man eine Schleife über alle Komponenten bildet. Das darf das Systemfrei entscheiden, und richtet sich nach der Reservierung von Speicherplatzvorrat und freien internen Prozeduren.
    • Heute Abend müsste ich auf WP:BETA ein Modul:Multilingual/maintain haben, in dem als fetchLanguageNames auch so eine Tabelle auftaucht; da kannst du ja dann mal die unterschiedlichen Lösungsvarianten vergleichen.
  • Vorhandene Definitionen:
  • Man kann zum CLDR beitragen, aber das sollte die WMF als Ganzes tun und eher nicht jeder User einzeln.
    • Die WMF ist bereits Unicode Consortium Liaison Member und müsste daher auch schon einen Contributor Account zum CLDR haben; ihn ansonsten mit Leichtigkeit bekommen können.
    • Wenn MW nicht willig ist, das gebündelt zu übernehmen und zuvor in den Wikis einen Review der internen Vorschläge abzuhalten, dann kann man das natürlich auch als Einzelperson machen: Anmelden
LG --PerfektesChaos 11:52, 14. Apr. 2015 (CEST)
  • Ich habe inzwischen die Programmierung für ein Pflegesystem fertig, aber noch nicht eingerichtet oder erprobt.
  • Auf Wikipedia:BETA gibt es schon mal zwei Sprachenauflistungen
  • Du kannst dir da meinen Ansatz zur Sortierungsfrage angucken.
  • Rest heute nacht oder morgen oder so.

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

@Tlustulimu: Sodele – nunmehr sind scharf:
  • Wikipedia:Lua/Modul/Multilingual/Upstream
    • Prozess zur Verbesserung von MediaWiki und CLDR
  • fetchLanguageNames/eo
    • Übersichtsseite der bekannten Codes und momentan weltweit wirksamer Übersetzungen
  • Modul:Multilingual/names
    • Änderungswünsche.
    • Wirken sofort auf die Funktion getName.
    • Schlagen gleichzeitig im Verbesserungsprozess auf.
    • Ich habe darin Abschnitte für eo, dsb, hsb eingetragen; du hattest ja berechtigten Grund zum Meckern.
LG --PerfektesChaos 13:17, 15. Apr. 2015 (CEST)
Linkfixe:
Enjoy --PerfektesChaos 18:13, 19. Apr. 2015 (CEST)
@OT: wikitable/Wiki-Syntax, da möchte ich (als Lua-Neuling) nur nebenbei etwas einwenden: ist es nicht so, dass diese nur für den Endnutzer ist!? Also eher für sehr technische Sachen wie Vorlagen der nativere HTML-Code zu verwenden ist (davon abgesehen, dass diese bei aufwendigeren Vorlagen übersichtlicher und zuweilen auch technisch erst machbar macht)!? ↔ Benutzer: Perhelion  20:53, 19. Apr. 2015 (CEST)
Ich verstehe die Frage nicht.
Wenn du die folgenden Code-Sequenzen von oben meinen solltest:
local r = '{| class="wikitable sortable"\n'
r = r .. "|-\n" .. "! Kodo !! Nomo\n" -- head of the table
und
r = r .. "|-\n" .. "| " .. code .. " || " .. name .. "\n"
schließlich
r = r .. "|}\n"
– was stört dich denn daran, und warum soll man das in HTML schreiben müssen?
Wikisyntax ist einn vereinfachter und kurzer Zugang zu HTML, und die gleichartige Tabelle lässt sich selbstverständlich auch mit HTML-Tags generieren; bloß wird der Quellcode schon allein für die ganzen end-tags deutlich länger.
Wikisyntax verstehen schließlich alle Beteiligten, und ein Lua-Modul macht auch nichts anderes als jede Vorlage, nämlich Wikitext in die einbindende Seite einzuspeisen. Und Vorlagen programmieren wir ebenfalls in Wikisyntax und nicht in HTML.
Erstaunt --PerfektesChaos 21:09, 19. Apr. 2015 (CEST)
@PerfektesChaos/WikiSyntax: das habe ich irgendwo mal unter Optimierung gelesen, da dadurch ein Parserdurchgang gespart wird (nachprüfen kann ich dies leider auch nicht ^^). Kurzer Code hat ja nicht direkt was mit optimal zu tun (vgl. jQuery). LG ↔ Benutzer: Perhelion  21:44, 19. Apr. 2015 (CEST)
Da sehe ich grad keine Ersparnis, denn das Ergebnis der Lua-Einbindung wird ganz normal und wie jede Vorlage auch in den Wikitext der obersten Seite eingefügt, und die geht hinterher grundsätzlich und zwangsläufig durch das Parsing, für die oberste Seite halt.
Was grundsätzlich nicht mehr läuft, das ist Vorlagenexpansion, bestimmte Parserfunktionen und Extension-Tags; die waren beim Aufruf von Lua schon expandiert und ausgewertet gewesen, und in der zusammengestellten Gesamtseite würden siewie nowiki stehenbleiben.
Aber Tabellensyntax und elementares Wiki-Markup wird jetzt erst beim Verarbeiten der Gesamteite erstmals angefasst und in HTML gewandelt. Der Paser geht also sowieso drüber, und wenn er jetzt Tags findet, dann muss er sie interpretieren und nachgucken, ob sie auch brav auf der Whitelist stehen. Tabellenwiki sind hingegen keine Tags und werden jetzt in Tags umgewandelt.
LG --PerfektesChaos 22:03, 19. Apr. 2015 (CEST)

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

@Tlustulimu: Das hat offenbar vor ein paar Wochen ein gewisser Millosh mit einem pywikibot zu generieren begonnen, und seitdem wird daran manuell weitergepflegt.
Ausgangsbasis war wohl mal dieselbe Struktur auf dem Wiki-Server.
Für die oben genannte Verbesserung der Ursprungsdatenbank auf CLDR ist das nicht geeignet, aber man kann Anregungen zur Komplettierung nachlesen.
Wenn jetzt die Upstream-Datenbanken weiterentwickelt werden oder auf Wikidata mehr enzyklopädische Artikel zu bestimmten Sprachen hinzukommen, dann wird das eklig.
Ich hoffe, du kommst gelegentlich dazu, deine ersten Korrekturen für falsches eo im Modul:Multilingual/names einzupflegen.
LG --PerfektesChaos 11:19, 7. Mai 2015 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:27, 30. Apr. 2018 (CEST)

For-Schleifen in Lua-Vorlage

Aus der Vorlagenwerkstatt gekürzt übertragen

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

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

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


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

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

also dann so? 

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

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

Lua ist eine Programmiersprache, keine Auszeichnungssprache, wenn du irgendwelchen Text hinschreibst (wie {{{!}}-}) wird versucht das als Programmbefehl zu interpretieren. Code sieht eher aus wie hier oder (als Anwendungsbeispiel) hier. Ich habe mich mit Lua nicht näher beschäftigt, aber irgendwo sollten sich geeignete Beispiele finden lassen. --mfb (Diskussion) 16:35, 11. Sep. 2015 (CEST)
Ja okay, aber für for-Schleifen brauche ich ja nun eine Lua-Vorlage. In meinem Beispiel oben habe ich 17 Parameterwerte {{{s}}}, {{{z}}} und {{{1}}} bis {{{15}}}. Wie kann ich mit diesen Werten in der Lua-Vorlage dann arbeiten? Hier brauche ich wohl eine Schnittstelle zwischen Auszeichnungssprache und Programmiersprache, oder eine andere Möglichkeit, die Parameterwerte in das Lua-Script zu übergeben bzw. vice versa. – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 17:18, 11. Sep. 2015 (CEST)
ach ich hab's wohl gerade gesehen, ich müsste ein Modul mit den for-Schleifen schreiben und das wird dann per #invoke wiederum in eine Vorlage eingebunden, oder? Hab ich's jetzt? – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 17:32, 11. Sep. 2015 (CEST)
Ja. Du müsstest dich schon recht intensiv mit Hilfe:Lua und Hilfe:Lua/Modul im Wiki beschäftigen. LG --PerfektesChaos 17:35, 11. Sep. 2015 (CEST)
Jupp, danke für die Predigt ein SmileysymbolVorlage:Smiley/Wartung/;)  Eventuell könnte ich aber dennoch mit der einen oder anderen Frage kommen, denn einiges erschließt sich mir selbst durch Manual und Ausprobieren nicht immer. Auf dem zweiten Blick sieht mir die Syntax recht einfach und gut nachvollziehbar aus. Ich werde studieren und probieren, aber vielen Dank mal für die ersten ein zwei Schritte – Doc Taxon • Diskussion • Wiki-MUC • Wikiliebe?! • 18:53, 11. Sep. 2015 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:27, 30. Apr. 2018 (CEST)

Text aus Listen generieren

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

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

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

Hallo, ich habe eine solche Funktion mit dem Namen listToFormat heute erstellt und dem Modul:Text hinzugefügt.
  • Es können unendlich viele Listen in Form von Strings als unbenannte Parameter übergeben werden.
  • Der Separator muss einheitlich sein, standardmäßig ist es ein Semikolon, er kann durch den Parameter sep aber spezifiziert werden.
  • Das Format wird über den Parameter format angegeben, wobei ein %s als jeweilige Variable verwendet wird. Dies entspricht nicht der Funktionalität der Funktionalität aus C, sondern ist eine konstante Variable. Flags oder andere Angaben funktionieren genausowenig wie andere conversion-Buchstaben außer s. Es wird also lediglich das nächste Auftreten des Strings %s gesucht und durch das nächste Listenelement ersetzt.
Ich bitte um Code-Review (ist die erste Lua-Funktion, die ich jemals erstellt habe) und Anmerkungen. Falls das in Ordnung geht, übernehme ich in den nächsten Tagen die Dokumentation auf Wikipedia:Lua/Modul/Text. Grüße, Yellowcard (D.) 13:54, 5. Okt. 2015 (CEST)
  • Willkommen im Club!
  • Syntaktisch offenkundig okay.
    • Ich würde grundsätzlich alle local am Beginn des jeweiligen Blockes zusammenziehen; das hat die gleiche Wirkung, gibt aber einen schnelleren Überblick über alle mit Auswirkung auf diesen Block (=function) deklarierten Symbole.
  • Es empfiehlt sich, in den jeweilgen Seitenbereichen die Funktionen alphabetisch nach Name zu sortieren.
  • Auf Wikipedia:Lua/Modul/Text/Test kannst du deinen Review und die Anwendungsbeispiele schon gleich selbst erledigen; interessant sind hier auch die Grenzfälle, etwa nicht oder leer oder nur durch Leerzeichen oder ungültig angegebene Parameter und den resultierenden Effekt.
LG --PerfektesChaos 14:23, 5. Okt. 2015 (CEST)
Alles klar, Wikipedia:Lua/Modul/Text/Test sieht sinnvoll aus. Habe aber offenbar schon einen Grenzfall erwischt, bei dem die Funktion versagt (muss es noch weiter testen). Ich melde mich ggf. nochmal. Grüße, Yellowcard (D.) 14:33, 5. Okt. 2015 (CEST)
Ich habe zunächst mal ein anderes Problem. Ich möchte als Parameter format= eine Vorlage übergeben, die dann mit den jeweiligen Listeninhalten dupliziert und gefüllt wird. Beispiel:
Vorlage: {{Testvorlage|1=foo|2=bar}}
Ich möchte die Parameter 1 und 2 mit Listen füllen. Da würde ich Folgendes aufrufen:
{{#invoke:Text|listToFormat|format={{Testvorlage|1=%s|2=%s}}|1=liste1|2=liste2}}
Das Problem sind die Pipes. Wenn ich das so aufrufe wie oben, schlägt der Aufruf natürlich fehl, weil das Pipe im format-Parameter vermuten lässt, dass anschließend der nächste Parameter für den Lua-Aufruf folgt. Mit {{!}} anstelle der Pipes geht es auch nicht; dann funktioniert zwar der Lua-Funktionsaufruf, die Vorlage wird aber schließlich nicht ausgewertet. Gibt es hier irgendwie Abhilfe? Zum Beispiel würde helfen, den String des format-Parameters als solchen zu kennzeichnen oder die Pipes irgendwie anders zu escapen, sodass sie anschließend trotzdem noch bei der Vorlagenauswertung als Pipes erkannt werden ... Danke, Yellowcard (D.) 19:06, 5. Okt. 2015 (CEST)
Ist das ein Testergebnis? Das sollte immer von innen nach außen ausgewertet werden. Lua sieht also für den Parameter "format" die Rückgabe der Vorlage:Testvorlage. --mfb (Diskussion) 22:03, 5. Okt. 2015 (CEST)
Okay, das verändert die Sachlage, macht sie aber nicht unbedingt besser. Gibt es eine Möglichkeit, die entscheidenden Zeichen (also wohl geschweifte Klammern und Pipes) zu escapen, dass ich diesen String als uninterpretierten Parameter an Lua übergeben kann? Yellowcard (D.) 00:33, 6. Okt. 2015 (CEST)
Ja, eben mit {{!}}. Dann sieht Lua eine Pipe als Teil des Parameterwertes. Auch <nowiki> um die betroffenen Zeichen herum sollte klappen. --mfb (Diskussion) 11:00, 6. Okt. 2015 (CEST)
@Mfb: Wenn ich {{!}} verwende, verhält sich der Lua-Funktionsaufruf zwar korrekt und erstellt auch die Zeichenketten wie erwartet, nur wird dann der entstehende String – eigentlich korrekte Vorlageneinbindungen – nicht mehr ausgewertet. Falls es Deine Zeit zulässt, würde ich mich freuen, wenn Du mal hier schauen könntest (feel free to edit). Danke und Gruß, Yellowcard (D.) 12:17, 6. Okt. 2015 (CEST)
"Lua-Modul gibt String in Form von Vorlageneinbindungen zurück, Parser soll Vorlagen-Einbindungen anschließend interpretieren" - das geht nicht. Der Parser liest erst die Struktur ein und ersetzt dann von innen nach außen (wobei in den Vorlagen wiederum das gleiche gemacht wird). Was von Vorlagen oder Modulen zurückgegeben wird, ist immer Text (kann noch Textauszeichnung haben, aber keine vorlagenrelevanten Sonderzeichen). Natürlich kann man in Lua den String wieder parsen und dann an Vorlagen als Argumente übergeben, aber das klingt unsinnig.
Das wird zur X-Y-Frage. Was ist dein eigentliches Ziel? --mfb (Diskussion) 16:18, 6. Okt. 2015 (CEST)
Ich möchte im Wesentlichen Daten aus Wikidata auslesen und in Tabellenform darstellen. Dabei ist die Zahl der Daten, die der Eigenschaft sind, im Vorhinein unbekannt (es handelt es im konkreten Fall um Vereinsstationen von Fußballspielern, aber da sind vielfältige Anwendungen denkbar). Für jeden Datensatz (einzelne Vereinsstation) wird die Vorlage {{Team-Station}} aufgerufen. Fällt Dir da eine andere Vorgehensweise ein? Gruß, Yellowcard (D.) 16:23, 6. Okt. 2015 (CEST)
Sofern man die Logik mit der Ausleihe irgendwie anders lösen kann, könnte man die Tabellensyntax direkt in den String setzen, sodass das Lua-Modul den fertigen Code liefert. Ich weiß nicht, ob Lua eine spezielle Funktion hat um Vorlagenaufrufe auszulösen. Wenn ja, wäre das wohl die sinnvollste Lösung. --mfb (Diskussion) 18:27, 6. Okt. 2015 (CEST)
  • Lua-Parameter verhalten sich genauso wie Vorlagenparameter; nur gibt es zusätzliche Möglichkeiten zur Unterscheidung von leeren Werten und nicht angegebenen Werten.
  • Es gibt eine eigentlich schon wieder weiterentwickelte Version http://de.wikipedia.beta.wmflabs.org/wiki/Modul:Text zum Ausprobieren, statt hier auf der Produktivversion.
  • Dort gibt es auch http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Lua/Modul/Text/Test zum Entwickeln auch der Robustheit bei Grenzfällen.
  • Schließlich gibt es http://de.wikipedia.beta.wmflabs.org/wiki/Modul:Text/test zum Auswerten von Testbeispielen.
  • Die grundsätzliche Idee ist eigentlich, dass auf BETA bis zum Ende entwickelt wird, und hinterher das Modul auf die echte WP kopiert wird und danach auch die erweiterte Testseite auf die echte WP. Damit werden die echten Artikel nicht gefährdet und die Serverlast wird minimiert.
  • Wenn das irgendwas mit Vorlagen und Parametern wird, dann ist das nichts mehr für die allgemeinverwendbare Bibliothek Text zu universell und kontextunabhängig einsetzbaren elementaren Textfunktionen. Das muss dann in einem eigenen Modul gelöst werden.

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

Die Unterscheidung gibt es auch bei normalen Vorlagen: {{{Name}}} ist sichtbar wenn der Parameter nicht definiert wurde, und leer wenn er als leer definiert wurde. --mfb (Diskussion) 00:06, 7. Okt. 2015 (CEST)
Vielen Dank für eure Infos und Hilfestellung.
@PerfektesChaos: Die Funktion listToFormat im Modul:Text ist produktiv und robust. Das Problem liegt an anderer Stelle. Das Herumspielen in meinem Benutzernamensraum mit dem Modul sollte die Server nicht merklich belasten. Die Diskussion hier hat aber gezeigt, dass ich mit dem generalistisch gehaltenen Modul:Text wider Erwarten nicht zum Ziel komme und ein (dann sehr spezifisches) Modul wohl die einzige Lösung ist. Gibt es da irgendwelche Spezifikationen zur Benennung und zum Ort? Ich werde die Entwicklung mal auf meine Agenda schreiben und hoffe, dass ich es hinbekomme; ich werde das dann im verlinkten Beta-Wiki machen. Grüße, Yellowcard (D.) 00:49, 7. Okt. 2015 (CEST)
Wenn es eine Art Vorlage oder Pseudovorlage wird, dann würde sich Modul:Vorlage: anbieten, die dann wie eine Vorlage dokumentiert werden kann und deren Vorlagenprogrammierung aus einer Zeile plus Doku-Aufruf bestünde: Vorlage:Phab und die Namensgebung der Vorlage dann selbsterklärend nach Zweck und Funktion wie dort üblich.
--PerfektesChaos 01:03, 7. Okt. 2015 (CEST)
Das hilft weiter, danke! Grüße, Yellowcard (D.) 01:08, 7. Okt. 2015 (CEST)
Noch’n Tipp: Im Modul:Vorlage:MachTabellenDingens benötigst du statt frame.args wie bislang frame:getParent().args – das sind die Parameter der umhüllenden Vorlageneinbindung. Allgemein: Hilfe:Lua/Modul im Wiki mit diversen Infos. LG --PerfektesChaos 01:21, 7. Okt. 2015 (CEST)
Alles klar, nochmals danke. Ich werde mich da mit einigen Aspekten beschäftigen müssen, idealerweise binde ich ja die Module Modul:Wikidata und Modul:Text in das neue Modul ein und nutze deren Funktionen. Das muss ich mir im Detail aber nochmal anschauen; die Hilfeseiten sind aber sehr angenehm und hilfreich, finde ich. Es wird sicherlich den ein oder anderen Aspekt geben, an dem ich stecken bleiben werde; dann melde ich mich hier. ein SmileysymbolVorlage:Smiley/Wartung/;)  Grüße, Yellowcard (D.) 01:26, 7. Okt. 2015 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 11:27, 30. Apr. 2018 (CEST)

Modul für Bevölkerungsgrafik

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

Theoretisch schon, wobei man wohl noch an den Balkenbeschriftungen arbeiten muss (siehe hu:Cádiz#Népesség), z.B. vertikal verlaufend? --Mps、かみまみたDisk. 09:20, 14. Jun. 2015 (CEST)
  • Den Grafik-generierenden Teil könnte man sich abgucken.
  • Die Versorgung mit Eingabedaten ist nix.
    • Es wird nicht so ganz klar, aber es scheint ausschließlich darauf gesetzt zu werden, dass alles und nur nach Jahren granuliert auf Wikidata vorhanden sei.
    • Wir haben aber auch eigene und vandalismusgeschützte Metadaten.
    • Für die Darstellung von enzyklopädischen Informationen aus Wikidata wird ein Herkunftsnachweis gefordert; das wird hier nicht überprüft und bedenkenlos alles angezeigt, was irgendwer auf dem Planeten mal als angeblichen Zahlenwert hineingeschrieben hatte.
  • Die Formatierung der Ausgabe müsste, wie Mps schon andeutete, besser konfigurierbar gemacht werden.
    • Beschriftungsformat, Gestaltung, Konfiguration gibt es nicht.
    • Es müsste schon ansatzweise an Hilfe:Zeitleisten heranreichen.
  • Völlig undokumentiert; im gegenwärtigen Zustand unbrauchbar.
  • Strukturell müsste zwischen Gewinnung der Anwendungsdaten, ihrer Ausgabe und der optischen Gestaltung sauberer getrennt und dies flexibler gemacht werden.
LG --PerfektesChaos 10:59, 14. Jun. 2015 (CEST)
Hmm, ok. Also meine Intention mit dem Modul wäre sowieso, nicht Einwohnerzahlen zu visualisieren, sondern Elo-Zahlen, z. B. so. Da wären einige der aufgezählten Probleme nicht vorhanden (Quellenlage, Granulierung der Intervalle). Könnte man für dieses Einsatzgebiet ein Modul bauen? 85.212.62.122 12:44, 14. Jun. 2015 (CEST)
Im Prinzip ja, aber erwarte es nicht für 2015. Vor dir stehen die Wahlergebnisse in der Schlange.
Was dir vorschwebt, steht in Kategorie:Vorlage:Zeitleiste.
  • Das wäre also schon in den letzten Jahren gegangen.
  • Zeitleiste ist aber ein halbtoter Gaul, in den keine Arbeit mehr investiert werden soll; sondern der irgendwann in allen Ehren zu beerdigen wäre.
  • Die Aufgabe lautet jetzt, eine kluge und zukunftsfähige Struktur zu finden, die:
    • In einem Zweig Balkendiagramme als Nachfolger der Zeitleiste generiert,
    • flexibel in der Versorgung mit Eingabedaten aller Genauigkeit (Monate, Jahre, Tage, Quartale) ist
      • (ich kann mir JSON-Formate in einem Vorlagenparameter vorstellen)
      • und auch aus den gleichen Eingabedaten Teilmengen nimmt (nur eine Säule pro Jahr, nur eine Säule pro Jahrzehnt) sowie
    • flexibel in der Präsentation (Farben, Dichte, hoch/quer, Beschriftungen) ist.
      • Bei Wahlergebnissen gibt es eine Säule pro Partei mit dem aktuellen Ergebnis, aber dahinter noch eine zweite mit dem von der letzten Wahl.
Da sollte man auch international gucken, was für intelligente oder auch unbrauchbare Konzepte auf den Tisch kommen. Die ungarische Lösung war ein Gehversuch; wir selbst sind aber sehr mager mit konzeptionell fähigen Lua-Programmierern ausgestattet und brauchen noch einige Zeit. Eilt aber nicht.
LG --PerfektesChaos 13:07, 14. Jun. 2015 (CEST)
Naja, du beschreibst hier die eierlegende Wollmilchsau. Was ich brauche ist aber lediglich ein Modul, das die Einträge eines Properties in Wikidata als XY-Werte einliest und daraus ein Balken- oder Punktdiagramm generiert. 85.212.22.136 09:16, 15. Jun. 2015 (CEST)
  • Es wird aber kein Modul „lediglich Elo-Zahlen“ für die Schachspieler, ein weiteres für Badminton-Spieler, ein Modul für die Geschwindigkeit von Diesellokomotiven, eines für die Länge sibirischer Flüsse und 734 weitere geben.
  • Es wird für Grafiken dauerhaft nur ein einziges Modul als Bibliothek geben, wohl mit mehreren spezifischen internen Untermodulen, optimal ein einziges Paket weltweit über alle Wikis zentral gewartet und weiterentwickelt.
  • Es gibt bei uns potenziell Tausend Autoren, die mit rudimentären Kenntnissen der Vorlagenprogrammierung ihre fachspezifischen Vorlagen selbst schreiben und pflegen können, und notfalls Hilfe aus der Vorlagenwerksttatt bekämen. Es gibt hier perspektivisch ein Dutzend Leutchen, vielleicht auch zwei, die Lua einigermaßen robust programmieren könnten, darunter zurzeit null Admins. Es ist ein Holzweg zu glauben, dass die Artikelinhalte verfügbar bleiben, wenn man dauernd bei fremden Leuten anklopfen muss, und eine Handvoll Benutzer dann rund um die Uhr damit beschäftigt werden, fremde Probleme zu lösen. Und das wird auch nicht dadurch zu lösen sein, dass WMDE aus der Außenwelt für ein halbes Jahr IT-Experten anheuert, die das überhaupt erstmal IT-fachlich können müssten, aber von Wikis und Community und Artikelinhalten null Ahnung haben.
  • Die Schachspieler waren ja schon mit uralter klassischer Vorlagenprogrammierung für ihre Infobox überfordert und hatten kürzlich auf mich zurückgegriffen. Wenn ihr euch jetzt noch auf Lua-Module kapriziert, kommt ihr alleine überhaupt nicht mehr mit euren Artikeln zurecht.
  • Dein Balkendiagramm kannst du dir selbst seit Jahren mit Zeitleisten bauen; wiewohl dies veraltet ist.
  • Nebenbei bemerkt eignen sich Balkendiagramme nur für in der Regel gleichabständige Angaben, etwa pro Jahrzehnt oder bei meist regelmäßigen Wahlperioden oder ohne eine Zeitachse; bei unregelmäßigen Zeitabständen sind Punktdiagramme besser. Ein intelligent konzipiertes Modul kann mit einem winzigen Edit zwischen beiden Darstellungsarten umschalten.
VG --PerfektesChaos 10:47, 15. Jun. 2015 (CEST)
Das Balkendiagramm kann ich mir zwar mit Vorlagenprogrammierung bauen, aber damit komm ich doch nicht an Daten auf Wikdata ran, oder? Diese Daten müssten dann lokal im Artikel stehen, oder? 85.212.44.46 17:29, 15. Jun. 2015 (CEST)
Vorlagen, Artikel, Module - alle können auf die gleiche Art und Weise auf Wikidata zugreifen (spielt keine Rolle wo das geschieht). --mfb (Diskussion) 17:35, 15. Jun. 2015 (CEST)

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

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.
Einwohnerentwicklung von
@Atlasowa: Es gibt jetzt in dieser Vorlage die experimentelle Möglichkeit, Einwohnerdiagramme aus Wikidata-Einwohnerzahlen zu generieren (siehe nebenstehendes Beispiel für Zürich). Ist erst mal nur ein Versuch und noch nicht ausgereift, daher bitte nicht in Artikeln einbauen. Der Parameter ist auch bewusst noch nicht dokumentiert. -- hgzh 19:57, 23. Sep. 2015 (CEST)
@hgzh sehr sehr schick! Und ermöglicht eine schön kompakte Darstellung! Zu der grundsätzlichen wikidata/Wartungsfrage: Wäre es möglich, die Diagrammdaten in bspw. Vorlage:Einwohnerdiagramm/Daten/Dresden vorläufig mit wikidata abzugleichen? In dem Sinne dass die Einwohnerzahlen auf wikidata hochgeladen werden (aber nicht in dewiki Artikeln verwendet werden) und beobachtet werden kann, ob die Einwohnerzahlen in der Diagrammdaten-Vorlage mit diesen übereinstimmen - oder ob wikidata vandaliert wird, ob solcher wikidata-vandalismus revertiert wird, oder ob wikidata vielleicht eher noch irgendwas verbessert. Damit hätte man erstmals eine Möglichkeit, die Datenzuverlässigkeit/qualität/risiken bei wikidata einzuschätzen (was ja laut dem MB ein entscheidender Faktor ist). --Atlasowa (Diskussion) 10:55, 25. Sep. 2015 (CEST)
Auch diese Vorlage hat wieder das Problem, das ich oft bei Bevölkerungsgrafiken sehen: Bevölkerungszahlen sind keine kontinuierlichen Werte, sondern liegen lediglich zu diskreten Zeitpunkten vor. Es ist deshalb Humbug, mittels durchgezogener Linie eine bekannte Einwohnerzahl zu jedem Zeitpunkt zwischen zwei bekannten Werten zu suggerieren. Die annährend konstante Interpolation der Einwohnerzahl in der nebenstehenden Grafik ist für 1500 bis 1800 reine Theorefindung, für diesen Zeitraum ist die Einwohnerzahl nämlich lediglich für 8 Zeitpunkte bekannt! Diese "Einebnung" der Grafik lässt einschneidende Ereignisse völlig außer Acht, z.B. wenn die Einwohnerzahl über ein paar Jahrzehnte (ohne Einwohnerzählung) deutlich anstieg, dann aber durch Pest o.ä. wieder auf den Ausgangsstand reduziert wurde. Für Bevölkerungszahlen sind Balken- oder Punktdiagramme das Mittel der Wahl! 92.74.67.59 15:19, 30. Jan. 2016 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:30, 5. Mai 2018 (CEST)

Vorlage:GraphChart: Flexiblere Eingabeformate für Zeiten

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

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

  • Das zweite Format: Theoretisch ja.
  • Das erste ist mit 01-04-2014 kein zulässiges Format, weil auch nicht eindeutig (US-Amerikaner schreiben das gelegentlich und meinen mm-dd-yyyy und Briten schreiben es auch und meinen damit dd-mm-yyyy).
  • Es gibt aber ein massives Performance-Problem, wenn erstmal für jede einzelne von Hunderten Stützstellen ein Datumsinterpretierer aufgerufen werden soll, der zu erraten versucht, welches Datum gemeint ist. Wenn schon Grafikdaten vorbereitet werden, dann sollen sie gefälligst sauber kodiert werden.
LG --PerfektesChaos 16:54, 1. Aug. 2015 (CEST)
Das steht bei mir auf der Liste: entweder werde ich das explizit als weitere zulässige Ordinalskala einbauen (wenn dann aber im alleinigen Format JJJJ-MM-TT, aus von PerfektesChaos genanntem Grund) oder implizit als Teil meines Vorhabens Nominalskalen zu unterstützen. --Mps、かみまみたDisk. 11:58, 2. Aug. 2015 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 20:30, 5. Mai 2018 (CEST)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Lua/Werkstatt/Archiv/2015&oldid=224904429“