Wikivoyage:Vorlagen/Werkstatt/Archiv 2022-12-31

Dieser Artikel ist Teil unseres Archivs der Vorlagenwerkstatt.

<<

>>

Archiv vom 31. Dezember 2022

Bewegliche Feiertage ohne hinterlegte Formel

Ausgangslage

In der Vorlage einiger beweglicher Feiertage ist nicht die Formel zur Berechnung des Feiertagsdatums hinterlegt, sondern eine Datumsliste nach Kalenderjahren. Die ist begrenzt und endet irgendwann. Danach gibt die Vorlage munter weiter Feiertagsdaten aus, die aber frei phantasiert sind (Datum des heutigen Tages?). Eine Warnung im Reiseführer erfolgt nicht. Beispiel: Die Vesakh-Termine in Malaysia. In der Vorlage sind die Vesakh-Termine nur bis 2020 hinterlegt. Das Problem betrifft aber prinzipiell alle listenmässigen Feiertagsvorlagen.

Vorschläge

Zwei Optionen:

• Formel zur Berechnung des Feiertagsdatums in die Vorlage einbauen
• Warnungen einbauen
  • Warnung bei undefinierten Terminen auf Reiseführerseiten
  • Warnung für Admins bei Zeitablauf der hinterlegten Daten

--4omni (Diskussion) 09:11, 24. Jan. 2022 (CET)

Diskussion

Sehr gerne. Da die Berechnung oft kompliziert ist, muss das sicher im Lua erfolgen. Als ich damals (ist schon paar Jahre her) genau wegen Malaysia mal recherchiert habe, wurde es schon schwierig. Zuerst habe ich bei den Wikipedias gespickt und habe ich nicht mal für Chinesisches Neujahr ein nutzbares Modul gefunden. Geschweige den für Vesakh, Diwali, Thaipusam, weitere islamische Feiertage usw. Ramadan und Chinesisch Neujahr werden wir irgendwo herbekommen. Chinesisches Mondfest usw... Hmmm. Für unser Ostern haben wir wahrscheinlich schon was. Am Ende habe ich aufgegeben, und nur notgedrungen die hart codierten Listen hinterlegt. Mittlerweile könnte man noch mal forschen, ob es schon nutzbare Lua-Module gibt. Im Regelfall schaue ich als erstes auf WP/en nach. Aufgrund der Internationalität könnte auch auf meta mal geschaut werden. Am Ende sollten hier mal alle Formeln/Regeln für alle Feiertage zusammengetragen werden (bzw. ein Link auf irgendeine Formel im Internet). Bzw. auch ein Verweis auf unser Modul/Vorlage, sollten wir doch schon was haben. Ich selbst habe keinen Überblick mehr.

Wenn wir eine Formel haben, sollte der Zeitablauf kein Problem mehr darstellen. Da die Namensräume für jedermann beschreibbar sind sollte man Warnungen nicht auf Admins beschränken. Datenaktualisierung ist was für jedermann. Das ist keine Admintätigkeit.

Wie stellst du dir Warnungen generell vor? Mit normalen Wikimitteln gibt es nur Kategorien. Ansonsten könnte man über die Vorlagen noch irgendwelche Tags mit Warninfos mitgeben. Ein Helferlein könnte die in irgendeiner Form sichtbar machen. -- DerFussi 11:07, 24. Jan. 2022 (CET)

PS: Weiß jemand, ob die Daten für künftige Feiertage auf Wikidata abgelegt sind? Das wäre auch ein Variante. Da ist die Community größer, die das Zeug einpflegt. Als Ausweichvariante gänge das auch. -- DerFussi 11:57, 24. Jan. 2022 (CET)

Ich gehe recht stark davon aus, dass man die Termine leider nicht aus Wikidata herausziehen kann. Generell klingt der ganze Themenkomplex der Berechnung von Feiertagen nach einer Aufgabe, die ideal für Wikifunctions wäre. Aber wann das startet und wie zeitnah man es nutzen kann,… keine Ahnung. --Nw520 (Diskussion) 14:05, 24. Jan. 2022 (CET)

Da hast du recht. Auf Wikifunctions hoffe ich auch bezüglich meiner Provinzsuche. Aber wahrscheinlich muss ich es doch selber machen. Allerdings gehe ich auch nicht davon aus, dass wir die Feiertage hier so kurzfristig implementiert bekommen werden. Ich gehe davon aus, dass es etwas dauert. -- DerFussi 15:26, 24. Jan. 2022 (CET)

Und dann müssen wir nur noch jemanden akquirieren, der alles programmiert.   -- DerFussi 13:44, 24. Jan. 2022 (CET)

Datumsberechnungen sind alles andere als trivial, nicht nur „eine Formel“. Und ich bin mir recht sicher, dass dies wohl niemand für uns macht. Fürs erste ist es wohl sinnvoll, die nötigen Daten in die Feiertagsvorlagen zu packen, so wie ich das für die islamischen Feiertage gemacht habe. Irgendwann wird es eine Lösung für den islamischen Kalender geben, allerdings hat dies eine sehr geringe Priorität (bis 2030 habe ich Zeit…)

Nebenbei: wir sind schon an den Grenzen des Möglichen angekommen, was Programmierungen anbetrifft. Neue Projekte sind kaum noch möglich. --RolandUnger (Diskussion) 14:43, 29. Jan. 2022 (CET)

Ich wollte gerade mal bei Vesakh schauen, ob ich was nachtragen kann, und habe festgestellt, dass bei diesem Feiertag wohl nichts berechnet werden kann. Wie man in der Malaiischen Wikipedia sieht (z. B. 2007), sind die Feiertage in einzelnen Ländern auch noch unterschiedlich, auch wenn ein Tag meistens vorherrscht. Mittlerweile tendiere ich bei Vesakh sogar dazu, die Vorlage zu löschen und in den Länderartikeln nur den Monat anzugeben, gefolgt einem Einzelnachweis, wie in der malaiischen Wikipedia gemacht. Im Falle von Indonesien habe ich das gerade mal gemacht. Ich denke mittlerweile auch: In der Zeit, die wir hier in der Werkstatt über das Thema jetzt schon geschrieben haben, haben wir auch die nächsten 15 Jahre fix nachgetragen. Das sollte für eine Weile reichen. -- DerFussi 09:59, 30. Jan. 2022 (CET)

@RolandUnger: Offensichtlich sogar Islamisch Neujahr. Stimmt das?

Einige Feiertage scheinen auch durch das Jahr zu wandern, was einen Vollautomatismus auch unmöglich macht. Zumindest die Reihenfolge in der Tabelle muss immer mal händisch gefixt werden. Offensicht wird die Feiertagstabelle von den Autoren einfach in einigen Ländern immer mal editiert werden müssen. -- DerFussi 10:11, 30. Jan. 2022 (CET)

Seiten wie officeholidays.com haben vielleicht eine API, sodass mit JavaScript was möglich wäre, aber das dürfte im Regelfall bei den Nutzungsbedingungen schwierig werden, zum anderen am Umstand, dass auf Wikiseiten keine externen Infos eingebunden werden dürfen. Am besten man schaut dort nach und füllt fix die Vorlagen auf. -- DerFussi 10:28, 30. Jan. 2022 (CET)

Für Feiertage, die abgesehen vom zugrunde liegenden Kalender, in einzelnen Ländern unterscheiden, könnte man die Liste als Unterseite des Landes manuell pflegen. Als Fallback wird einfach der Monat ausgegeben. Ich habe das mal mit Malaysia/Wesak beispielhaft getan. Dies erscheint mir momentan als der beste Weg. Da es ja immer nur für ein Land gilt und nur einmal eingebunden ist, ist es aus meiner Sicht besser, als die Feiertagsvorlage mit Länderparametern zu fluten. Der Fallback stellt sicher, das immerhin noch der Monat angegeben ist. Die Einzelnachweise geben den Lesern die Chance auch ohne Update schnell das nächste Datum herauszufinden. Man könnte auch noch eine Wartungskategorie in den Fallback schreiben. Abgelaufene Listen könnten so von engagierten Autoren gefunden werden. -- DerFussi 13:40, 30. Jan. 2022 (CET)

Es wird noch etwas gemeiner beim chinesischen Kalender. Habe gestern mit meinen vietnamesischen Freunden anlässlich des Neujahrsfestes geredet. Die haben zwar den selben Kalender, streng genommen sind aber nicht alle Tierkreiszeichen gleich, die Vorlage {{Chinesische Kalenderzyklen}} kann man also nicht unbedingt auch in Vietnam benutzen. Was in China das Jahr des Hasen ist, ist in Vietnam die Katze. Der Rest ist fast gleich. Lediglich Der Wasserbüffel kommt noch anstatt des Ochsen. Das ließe sich aber abfangen, wenn man die Vorlage in ein Modul auslagert. -- DerFussi 07:57, 4. Feb. 2022 (CET)

Zitat aus w:chinesische Astrologie: "Dass aus einem Hasen auch eine Katze (貓, māo) werden kann, ist höchstwahrscheinlich ein Irrtum, der möglicherweise auf die ähnliche Aussprache des Tiers Katze (māo) und des Hase-Erdzweigs (mǎo) zurückzuführen ist." Im selben Lemma sind auch andere Varianten (Schaf/Ziege, Büffel/Rind etc.) erläutert. Hilft das? --4omni (Diskussion) 14:09, 4. Feb. 2022 (CET)

Nee hilft nicht. Ich weiß von meinen (chinesischen) Ex, dass Schaf und Ziege bei denen vom Wort her gleich sind. Das Problem ist doch hier, dass die Vorlage in allen vietnamesischen Artikeln "Katze" ausgeben muss, während in den chinesischen Artikeln "Hase" stehen muss, wenn es im nächsten Jahr 2023 wieder so weit ist.-- DerFussi 15:09, 4. Feb. 2022 (CET)

Warum das so ist, ist ja dabei unwichtig. Am Ende lässt es sich wirklich nur über ein Modul lösen. Wikidata liefert ja das Land zu einem Artikel. -- DerFussi 15:16, 4. Feb. 2022 (CET)

Ich habe mal eine Wartungskategorie angelegt: Vorlagen:Feiertage, die aktualisiert werden müssen. Die fälschlicherweise drin liegenden Seiten sind bereits wegparametriert. Die Vorlagen schlagen ein Jahr vor Ablauf dort auf. -- DerFussi 08:25, 4. Feb. 2022 (CET)

Links auf diese vCard

Ausgangslage

Jede {{VCard}} setzt auch einen Anker, auf den mittels [[<Seite>#vCard <Name_der_vCard>]] verlinkt werden kann. Ändert ein User den Namen einer vCard, brechen alle Links auf den Anker.

Vorschläge

1. Analog zum Werkzeug Links auf diese Seite wünsche ich mir die Möglichkeit, unkompliziert Links auf diese vCard abzufragen.
2. Zusätzlich könnten Autoren bei einer Namensänderung der vCard darauf hingewiesen werden, dass die Links auf diese vCard nachgeführt werden müssen.
3. Zerbrochene Links müssen gesucht werden können.

Diskussion

Eine ausgiebige Nutzung (Beispiel) dieser vCard-Anker ist ohne die beschriebene Funktionalität kaum möglich, da die Wartung nicht gewährleistet werden kann. --4omni (Diskussion) 08:49, 28. Jan. 2022 (CET)

Mit meinem nicht vollständigen Netzverständnis kann ich Folgendes anmerken: Das Problem dabei ist, dass rein technisch der Link nicht wirklich kaputt ist. Ein Link verweist im Internet immer erstmal auf eine Seite, der Anker wird nur vom Browser nach dem Seitenaufruf gesucht. Das heißt man kann zwar prüfen, ob eine Seite existiert (mit WikiMarkup über eine Parserfunktion, per JavaScript über die API des Wikis), aber erstmal nicht, ob der Anker existiert - zumindest nicht ohne die Seite einzulesen und zu durchsuchen. In dem Fall befindet man sich ja noch auf der Zielseite und muss eigentlich eine Rückwärtssuche machen. Helfen würde es, wenn die Anker in der Datenbank stehen und über die API abrufbar wären. @RolandUnger, Nw520: Sind sie das? Ich hätte gedacht, nicht. Am Ende ist es das selbe Problem wie alle externen Links hier auf Wikivoyage, die auf Unterseiten eines Webauftritts verweisen. Sie können jederzeit kaputtgehen, ohne, dass man etwas merkt.

Man könnte sicher ein Tool schreiben, das man auf der Seite ausführt. Das fragt über die API Links auf diese Seite ab und scannt diese dann. Aber eine Art Spezialseite, die solche Dinger für das Wiki auflistet? Da könnte man höchstens einen (langsamen) Bot schreiben, der permanent durch das Wiki rammelt und sowas ausführt.

Also außer einem pauschalen Warnhinweis im VCard Editor kann ich mir das nur mit immensem Aufwand vorstellen. -- DerFussi 10:54, 28. Jan. 2022 (CET)

Eine Warnung in der VCard ist auch sehr unglücklich. Wir Wikiautoren können damit was anfangen. Man muss aber davon ausgehen, das auch anonyme Reisende vor Ort irgendwo die Seite aufgerufen haben und eine VCard editieren (in dem sie sie direkt bearbeiten). Die wissen gar nicht worum es geht. Die wissen vielleicht nicht mal wie man in einem Wiki Artikel bearbeitet. In dem Moment, in dem man öffenliche Features auf das Wiki draufprogrammiert, muss man dort auch jeglichen Wiki-Kram vom Benutzer fernhalten, erst recht Warnungen, dass man irgendwo im Wiki was fixen soll. -- DerFussi 11:16, 28. Jan. 2022 (CET)

Eine API-Funktion, um auf Abschnitte eines Artikels zuzugreifen, existiert nach meiner Kenntnis nicht. Auch im Datenbankschema erkenne ich keine Tabelle, in der der Anker (bzw. fragments) abgespeichert werden. Die Tabelle pagelinks war für mich ein Kandidat, aber in Quarry lieferte die Abfrage SELECT * FROM pagelinks WHERE pl_title LIKE '%#%' 0 Treffer, weshalb ich folgere, dass Anker hier nicht abgespeichert werden. Als Fazit schließe ich, dass kein Index an Anker-Verlinkungen existiert, was eine effiziente Auflistung ausschließt.

Meine Idee für eine Funktion à la Links auf diese vCard wäre eine Suche mit CirrusSearch und Regex der Form /\[\[⟨Artikelname⟩\]\]#vCard[ _]⟨vCard-Name, bei dem Leerzeichen zusätzlich auch Underscores matchen⟩/i (fehlend: verlinkende Bilder (einfach), Sprungmarken im gleichen Artikel (schwierig, wahrscheinlich separate CirrusSearch-Suche)), was rechnerisch teuer wäre, aber für die Abfrage für eine geringe Anzahl an vCards (mehrere durch Ver-oder-ung der Regexes und Filtern als Postprocessing) sicherlich praktikabel. Beim naiven Ansatz würde ich einen API-Aufruf mit Dauer >1 Sekunde für die Suche veranschlagen. Wenn man den Fall berücksichtigen möchte, dass ein Artikel mehrfach vCard-Anker auf die zu prüfende vCard beinhaltet, müsste für jeden CirrusSearch-Treffer zusätzlich noch das Markup oder das HTML angefordert werden.

Autoren bei einer Namensänderung auf kaputte Anker hinweisen hängt vom vorherigen Punkt ab, ist aber in meinen Augen ferner nur im ListingEditor praktikabel. Zudem, wie auch DerFussi darstellte, kann ich mir vorstellen, dass durch die höhere Anzahl an Schritten Spontanedits am Wiki abgeschreckt werden könnten. Abhilfen für letzteres wären: Opt-In oder der Hinweis ist an Mitautoren gerichtet (z. B. Hinweis in Änderungszusammenfassung).

Zerbrochene Links finden: Ich denke hier wäre der einzige Weg, wie DerFussi beschrieb, ein Bot, der sich durchs Wiki fräst und seine Funde sammelt. Mit meinen Vorschlag ist nur eine Suche ausgehend von einer (oder wenigen) vCard(s) möglich. Für eine allgemeine Suche, habe ich keinen Ansatz.

Eine anderer Ansatz an das Problem wäre, dass man versucht vCard-Verlinkungen stabiler zu machen und nicht mehr (ausschließlich) den Namen als Identifikator zu nutzen. Vielleicht könnte die Wikidata-ID hier Abhilfe schaffen.
Das Problem der „toten Anker“ ist ja nicht spezifisch für Wikivoyage, gibt es vielleicht bereits Lösungen bei Wikipedia? --Nw520 (Diskussion) 18:08, 28. Jan. 2022 (CET)

Zu ergänzenden Aufklärung: Mit dem "langsamen" Bot meinte ich nicht den Umstand, dass sowas performancemäßig dauert. Solche Bots sollten programmseitig einfach gezwungen werden, nicht einfach so schnell, wie es das Programm hergibt, durch das Wiki zu ackern. Ständige Anfragen von der selben IP im Millisekundentakt sollten und müssen einfach von den WMF-Servern geblockt werden. Ich bin kein Bot-Insider, um hier eine Zahl anzugeben, aber man sollte seine Scan-Bots ausbremsen. Also, sollte man den Aufwand tätigen, sowas per Bot zu prüfen und irgendeine Kategorie oder Liste zu pflegen, muss man davon ausgehen, dass die Aktualität sicher bei Wochen, wenn nicht Monaten liegt. Wie oft darf ein Bot eine Anfrage stellen, ohne als Hackerangriff gewertet zu werden? Ich kann mir 2 oder 3 Sekunden vorstellen, allein bei einer Anfrage pro 3 Sekunden, nur um erstmal ein Was linkt hier abzufragen... Und da es um Rückwärtssuchen geht, bei dem man pro Artikel noch mehrere Seiten scannen muss... Ich denke, bei allem Verständnis für die Anforderung, das Problem ist absolut nachvollziehbar, ich denke, dass wir mit dem Dilemma leben müssen. Wenn jemand merkt, dass so ein Ding aufgrund Namensänderung kaputt ist, soll er*sie es halt fixen, wenn er*sie in der Lage ist. -- DerFussi 21:39, 28. Jan. 2022 (CET)

Ich musste mir das Problem über Nacht erst einmal überdenken. Und ich bin ganz froh, dass NW520s Vorschläge in dieselbe Richtung gehen.

Es ist richtig: Anker werden grundsätzlich nicht abgespeichert, und fehlerhafte Anker werden vom Webserver einfach ignoriert. Damit sind Lösungen mit (einfachen) Werkzeugen der Mediawiki-Software nicht möglich. Wahrscheinlich muss man auf zwei Wegen vorgehen: Der erste Weg, nämlich einen Bot einzusetzen, ist unbedingt nötig: für die Altlasten und die Änderungen direkt im Quelltext. Der zweite Weg ist, im Listing-Editor zu prüfen, ob es auf den bisherigen Namen einen oder mehrere Links gab und im Falle der Namensänderung eine Fehlerkategorie an den Kommentar anzuhängen. Mit API-Aufrufen, die im Quelltext suchen, wie insource:/\#vCard[_ ]/ erhält man eine Liste der Artikel, in denen auf VCards verlinkt wird. Es sind momentan 382 Artikel. So etwas ließe sich in allen Programmiersprachen machen. Das Problem der Bot-Lösung ist, dass ich gegenwärtig niemanden kenne, der dies umsetzen kann. Im Listing-Editor eine Fehlerkategorie zu setzen (eine Warnung bringt für den Autoren wohl nicht viel), halte ich für ein lösbares Problem.

Natürlich sind WD-Ids stabiler als Namen und als Linkziel besser geeignet. Dies würde ich unterstützen und lässt sich einfach umsetzen. Aber ohne einen Bot, der die Fehler sucht, besteht die Gefahr, dass funktionierende Links plötzlich nicht mehr funktionieren und unerkannt bleiben.

Zerbrochene Links gibt es an verschiedenen Stellen, darunter sind auch Links zu Schwesterprojekten dabei. Auch hier hilft nur ein Bot. Bei einigen dieser Probleme hat Achim55 schon Vorarbeit geleistet, wie die Liste Bad links to other wikis zeigt. Es sind aber zahlreiche Fehler manuell zu bearbeiten, was nicht auf den Schultern eines einzelnen lasten sollte. Aber vielleicht könnte uns Achim 55 hilfen, einen geeigneten Bot aufzusetzen. --RolandUnger (Diskussion) 11:37, 29. Jan. 2022 (CET)

Leider musste ich die Sache aufgeben, weil die Wiki-Obrigkeit beschlossen hatte, Abfragen von Tabellen, die aus mehr als einer DB stammen (z. B. wp und Commons), nicht mehr zuzulassen. Daher können jetzt Abfragen wie quarry:query/9688 in den Mülleimer und müssten komplett neu geschrieben werden. Schade eigentlich.

Wenn ich das jetzt richtig sehe, ist das o. g. Problem ein wikiinternes und müsste machbar sein. Ich denk mal drüber nach, vielleicht kann ich eine ToFix-Liste generieren, zu mehr reicht's bei mir nicht. Gruß, Achim55 (Diskussion) 14:03, 29. Jan. 2022 (CET)

In diesem Zusammenhang nicht uninteressant: m:Community Wishlist Survey 2022/Miscellaneous/Include section links in WhatLinksHere --Nw520 (Diskussion) 00:44, 30. Jan. 2022 (CET)

Guter Hinweis, danke schön! Ich habe dort auf unsere hiesige Diskussion hingewiesen und für dieses Thema abgestimmt. Hinweise zur Verbesserung meiner englischen Formulierungen sind willkommen. Ich hoffe, dass ihr auch für dieses Thema voten werdet. --4omni (Diskussion) 14:38, 30. Jan. 2022 (CET)

Ich habe mich mal gerade ans Schreiben eines Gadgets gesetzt, das für einen Artikel die ausgehenden Verlinkungen auf Sektionen (und sonstige IDs) auf Existenz überprüft. Alles noch sehr roh und ungetestet, ablegt unter m:User:Nw520/HashCheck.js. Zum Testen mw.loader.load( '//meta.wikimedia.org/w/index.php?title=User:Nw520/HashCheck.js&action=raw&ctype=text/javascript' ); in die commons.js packen. Im Bereich „Wikiwerkzeuge“ taucht dann eine neue Option auf. Links werden nach der Prüfung mit einem Symbol versehen und bei Nicht-Funden wird eine Warnbox am Anfang des Artikels eingefügt. Eine sofortige Ausführung beim Aufruf eines Artikels geht mit mw.hook( 'ext.hashCheck.loaded' ).add( function ( hashCheck ) { hashCheck.scan(); } );, wobei ich momentan davon abrate, da das zu viele Anfragen (bei jedem Aufruf des Artikels) verursacht. Anschlagen sollte der Spaß beispielsweise hier. --Nw520 (Diskussion) 00:13, 31. Mai 2022 (CEST)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Unabhängig vom Namen-Anker gibt es jetzt, wenn eine Wikidata-Id bekannt ist, im {{Marker}} und {{vCard}} einen zweiten Anker in der Form id="vCard_Q1234567". Die sind stabiler als die Namen in den genannten Vorlagen. --RolandUnger (Diskussion) 07:09, 10. Jun. 2022 (CEST)

Abweichende Termine für Feiertage

Ausgangslage

Mehrere bedeutende Feiertage verschiedener Religionen sind vom Mondstand abhängig. Dabei ergeben sich in manchen Jahren Unterschiede von einem Tag zwischen verschiedenen Ländern oder bei großen Ländern sogar innerhalb eines Landes.

Daneben gibt es z. T. unterschiedliche Traditionen, zu welchem Datum ein Feiertag zelebriert wird.

Wie geht Wikivoyage mit solch abweichenden Terminen um? --4omni (Diskussion) 12:46, 30. Jan. 2022 (CET)

Diskussion

Ich könnte mir vorstellen, das von den UN praktizierte Datum zu nehmen. Leider habe ich beim Beispiel Vesak(h) dort keine Liste für mehrere Jahre, sondern nur ein Datum für's laufende Jahr gefunden. --4omni (Diskussion) 13:40, 30. Jan. 2022 (CET)

Bei {{Ostern}} kann man Tage addieren/subtrahieren. Geht das bei anderen Feiertagen auch? Dann könnte man landesspezifische Abweichungen (vom UN-Datum oder einem anderen "Standard") darüber berücksichtigen. --4omni (Diskussion) 13:47, 30. Jan. 2022 (CET)

Den Mondstand kann niemand berücksichtigen. Bei mehreren Vorlagen wie {{1. Ramadan}} kann man mit dem Parameter diff einen Versatz eintragen, wenn er stabil ist. Die Umrechnung von Datumsangaben anhand von astronomischen Begebenheiten ist immer nur als Prognose zu verstehen. Man sollte dies im Text dazuschreiben.

Im Falle des islamischen Kalenders sind mir mindestens vier unterschiedliche Modelle bekannt, wie man die Schalttage einfügen kann. Wahrscheinlich werde ich nicht umhinkommen, alle zu implementieren. Für die Wahl eines bestimmten Modells müssen die Erfahrung bzw. evtl. gegebene rechtliche Bestimmungen herhalten. Evtl. hilft ein Kontakt zu astronomischen Instituten in den einzelnen Ländern. --RolandUnger (Diskussion) 13:54, 30. Jan. 2022 (CET)

Graphiken bei {{rint}} fehlen

Ausgangslage

In Lainzer Tiergarten sieht man beim Nikolaitor und Pulverstampftor (verlinkte) weiße Stellen. Dort hätten die Symbole für verschiedene S-Bahnen stehen sollen. Fehlt bei {{rint|vienna}} ein Update oder ist der Import unvollständig? Oder liegt die Ursache woanders?

Hier eine Liste der Symbole: https://en.wikipedia.org/wiki/Template:Rail-interchange/doc/AT --4omni (Diskussion) 13:00, 30. Jan. 2022 (CET)

Diskussion

• Erledigt Das Problem wurde mit Anlegen von Vorlage:VUB color behoben. Danke RolandUnger. --Nw520 (Diskussion) 12:54, 7. Feb. 2022 (CET)

Leider noch nicht erledigt: Die Flecken sind nicht mehr weiß, sondern bunt, aber leider entspricht die Farb-/Symbolwahl weder der oben verlinkten Liste noch der Farbwahl in der App der Wiener Linien. Die Symbole/Farben in VUB-color werden Touristen vor Ort nicht finden. --4omni (Diskussion) 15:20, 7. Feb. 2022 (CET)

Das ist natürlich suboptimal. In der enWikipedia-Rint werden Bilder von Commons genutzt, in Rint hierzuwiki Text mit Hintergrund. Stellt sich die Frage, ob auch hier Symbole sinnvoll wären. Dem Netzplan entnehme ich folgende Farben:

•        – S1, S2, S3, S4, S7, S40, S50, S60, S80
•        – S45

Bei den sonstigen Linien finde ich gerade keine Quelle für Farben bzw. weiß nicht, worauf sich die Linienbezeichnung bezieht. --Nw520 (Diskussion) 15:41, 7. Feb. 2022 (CET)

In Wien werden die S-Bahn-Liniennummern mit und ohne das Wiener Donau-S verwendet. Eine Lösung a la w:Vorlage:Bahnlinie mit Textfarbe, Rahmenfarbe und Hintergrundfarbe wäre daher neben einer graphischen Lösung ebenfalls denkbar. Hauptsache, Reisende haben einen Wiedererkennungseffekt vor Ort. --4omni (Diskussion) 16:49, 7. Feb. 2022 (CET)

• Für die Wiener S-Bahnlinien ist das Problem behoben, es kann aber für andere Städte immer wieder vorkommen. Die Ursache ist, dass die Vorlagensuite nie vollständig importiert wurde und sich auch nur mit großem Aufwand pflegen lässt. --RolandUnger (Diskussion) 15:58, 7. Feb. 2022 (CET)

Danke! --4omni (Diskussion) 16:49, 7. Feb. 2022 (CET)

{{Feiertag}}

Ausgangslage

Für mich gibt es zwei Komplexe, die mit dieser Frage in der Vorlagenwerkstatt geklärt werden sollen:

Welches Datumsformat soll einheitlich für die Angabe des Datums in {{Feiertag}} genutzt werden?

In der derzeitigen Dokumentation von {{Feiertag}} wird hauptsächlich das Format j. M genutzt (bspw. 1. Jan.), abweichend davon finde ich aber in vielen Feiertags-Übersichten in Länder-Reiseführern das Format l, j. F Y (bspw. Montag, 1. Januar 2000), manchmal auch ohne Wochentag. Auch in der Dokumentation findet sich eine Abweichung vom Format j. M: Für Karfreitag, als beweglicher Feiertag, wird zusätzlich das Jahr angezeigt. Dies führt zu unterschiedlichen Datumsformaten in ein und derselben Tabelle (=unschön).

Im Reiseführer zu Polen wurde dieses Format kürzlich umgestellt auf D, j. M Y (bspw. Mo, 1. Jan 2000), mit dem Hinweis, dass auf Mobilgeräten dieses kompaktere Format besser darzustellen sei. Auf meiner Diskussionsseite sprach sich ein Autor mal für Wochentage aus.

Soll eine Möglichkeit geschaffen werden, die verschachtelte Verwendung von {{Nächster Termin nach Datum}} in {{Feiertag}} zu vereinfachen?

Beim Migrieren von Feiertags-Tabellen zur Verwendung vom Feiertags-Vorlagen-Trio ist mir aufgefallen, dass bei Verwendung des Formats mit Wochentag/Jahreszahl enorm viel Syntax anfällt und viele Parameter zwischen Terminen identisch sind. Dies erschwert die Verständlichkeit des Markups und steht einheitlichen Änderungen (bspw. Datumsformat ändern) entgegen.

Vorschläge

1. Alle Datumsangaben sollen mit einem einheitlichen Format angegeben werden. Damit sinnvolle Angaben für bewegliche Feiertage möglich sind, soll daher die Jahreszahl ebenfalls immer angegeben werden. Infrage kämen die Formate

• Mit Wochentag:
  • D, j. M Y (bspw. Mo, 1. Jan 2000)
  • l, j. F Y (bspw. Montag, 1. Januar 2000)
• Ohne Wochentag:
  • j. M Y (bspw. 1. Jan 2000)
  • j. F Y (bspw. 1. Januar 2000)

Persönlich bevorzuge ich das erste Format.

• +1 - Ich würde auch das erste Format bevorzugen -- DerFussi 17:13, 1. Mär. 2022 (CET) - PS: Nicht nur in Polen, auch bei allen anderen kürzlichen Länder-Vorgabe-Anpassungen habe ich die kompaktere Form benutzt, nachdem ich bei Tests merkte, dass mein Telefon nicht alles anzeigen konnte. -- DerFussi 21:02, 1. Mär. 2022 (CET)

2. Die Vorlage {{Feiertag}} wird um eine Möglichkeit erweitert, direkt und ohne Hilfe weiterer Vorlagen Datumsangaben zu berechnen. Das Datumsformat und die Wartetage (vgl. {{Nächster Termin nach Datum}} werden vordefiniert und müssen dadurch nicht mehr angegeben werden. Konkret habe ich drei Aufrufmöglichkeiten für die Vorlage vor Augen:

• {{Feiertag|01.01.|Neujahr|…}} oder auch {{Feiertag | {{Nächster Termin nach Datum | Datum1= {{CURRENTYEAR}}-1-1 | Datum2= {{NextYear}}-1-1 | Format= D, j. M Y | Wartetage= 7 }} | Neujahr | … }} – Wie bisher.
• {{Feiertag|datum=01-01|Neujahr|…}} – Vereinfachte Angabe des Monats und Tags des Termins.
• {{Feiertag|datum1={{Ostern|Format=Y-m-d|diff=49}}|datum2={{Ostern|{{NextYear}}|Format=Y-m-d|diff=49}}|Pfingsten|…}} – Möglichkeit sowohl diesjähren als auch nächstjährigen Termin anzugeben. Dadurch wird die Verwendung von spezialisierten Vorlagen für Termine möglich, vorausgesetzt sie unterstützen eine Ausgabe im Format Y-m-d. Einen Vorschlag für eine solche Vorlage haben ich in der Testvorlage abgelegt. --Nw520 (Diskussion) 16:29, 1. Mär. 2022 (CET)

Diskussion

• @DerFussi:, @4omni:, da ich mal unterstelle, dass euch das Thema interessieren könnte.   --Nw520 (Diskussion) 16:29, 1. Mär. 2022 (CET)
• Technische Schwierigkeit: Bei meinem Vorschlag für die Vorlage wechseln die Parameter |1=, |2= und |3= je nach Variante ihre Bedeutung. In einer Verwendung ist |1= das Datum, in einer anderen hingegen der Name des Feiertags. Dies könnte eine Verwendung von TemplateData unmöglich machen. --Nw520 (Diskussion) 16:29, 1. Mär. 2022 (CET)

Ich muss zugeben, mir hat die formlose Angabe wie "1. Januar" auch als Reisender gereicht. Diese ganze komplizierte Syntax für einen Tag, der immer auf das selbe Datum fällt, und nur damit der Wochentag dabei steht. Hmmm. Ich habe am Ende einfach das System übernommen. Ich gebe zu, {{Nächster Termin nach Datum}} kannte ich bisvor einer Weile noch nicht mal. Ich finde diese Berechnungsvorlagen extrem kompliziert, für Nicht-Nerds unzumutbar, weswegen sogar ich bei diesen Datumsberechnungsvorlagen nur Copy-And-Paste mache - mit den üblichen unvermeidbaren Copy-And-Paste-Fehlern. Andererseits, wenn man einen beweglichen Feiertag mit Jahr generieren lässt, braucht man auch der Einheitlichkeit halber her das ganze auch bei den fixen Feiertagen. Ideal wäre wahrscheinlich ein Lua-Modul, sodass man nur noch angeben muss: {{Feiertag|feiertag=Karfreitag|Easter Friday|Beschreibung des Karfreitags}}, wobei der erste Parameter einen dem Modul bekannten Feiertagsnamen oder ein Datum in einem fixen Format angibt. Das Modul berechnet das Datum oder holt es aus einer hinterlegten Liste oder formatiert das übergebene Datum. Ist aber eine mächtige Baustelle. Ansonsten gefällt mir die Variante der schlauen Feiertagsvorlage, die fixe Einstellungen kennt und die Formatierung übernimmt (Vaiante 2). Das Problem mit den Feiertagen, die in unterschiedlichen Ländern auf unterschiedliche Tage fallen kann das Ding eh' nicht lösen, dass sind aber Spezialfälle, bei denen man den Datumsparameter mit einer spezifischen Vorlage erzeugen kann. -- DerFussi 17:13, 1. Mär. 2022 (CET)

Kurzum: Ich bin 100% bei dir und unterstütze deine Idee. Sehr gern. Für das wahrscheinlich schickere Modul fehlt uns sicher die Manpower. -- DerFussi 20:59, 1. Mär. 2022 (CET)

Erledigt Mit geringfügigen Änderungen bei der Implementierung umgesetzt. --Nw520 (Diskussion) 14:36, 15. Okt. 2022 (CEST)

@Nw520: Ich habe mal testhalber zwei bekannte Feiertage fix in der Vorlage eingetragen und in Bolivien getestet. Dann würde auch die Feiertags-Vorlagensyntax wegfallen. Zumindest sieht es im Artikel nun wirklich übersichtlich aus. Was hältst du davon? -- DerFussi 20:06, 1. Jan. 2023 (CET)

@DerFussi: Sieht gut aus, besonders schön ist natürlich die einheitliche Schnittstelle und kurze Syntax! Leichte Sorge bereitet mir, wie gut das skaliert, wenn man alle wichtigen Feiertage so bereitstellen möchte.

Lautes Überlegen: Mir sind mal die *.next-Vorlagen (bspw. Vorlage:Datum.next) aufgefallen. Die hätten den Vorteil, dass sie nicht mehr zwei (explizite) Aufrufe für dieses und nächstes Jahr brauchen und daher mit dem datum-Parameter kompatibel wären. Da dieser auch Y-m-d unterstützt, wird in diesem Fall die Formatierung trotzdem noch von Feiertag übernommen. Sonstige Parameter, insb. Wartetage, ließen sich aber nicht mehr beeinflussen und man hätte immer noch einen verschachtelten Vorlagenaufruf. Alternativ wäre eine Idee (vorausgesetzt alle Feiertagsvorlagen teilten sich format, wartetage, usw.), dass man den feiertag-Parameter als Vorlagennamen interpretiert und Feiertag die Vorlagen dann in der Form {{ {{{feiertag}}} | Format=… }} aufrufen lässt. --Frohes Neues, Nw520 (Diskussion) 01:52, 2. Jan. 2023 (CET)

@Nw520: Oje. Wieder ein paar Vorlagen, die ich noch nicht kannte. Und wohl auch kaum benutzt. Jetzt bin ich komplett verwirrt.

Die Skalierung ging mir auch durch den Kopf. Die Frage ist vielleicht auch, ob man die nächsten Feiertage auch außerhalb der Feiertagsvorlagen braucht bzw. zur Verfügung haben will. Das wäre ein Punkt für die Next-Vorlagen. Da die Anzahl der Länderartikel übersichtlich ist und die Feiertage dort selten angefasst werden, ist etwas "Rest-Wiki-Markup" dort drin vielleicht auch nicht dramatisch. Nur ein Datum zu pflegen wäre aber wirklich ein Fortschritt- -- DerFussi 11:54, 3. Jan. 2023 (CET)

@Nw520: In Burkina Faso#Feiertage habe ich mal die {{Ostern.next}} direkt verwendet. Da die Ostern-Vorlage ca. 15 Feiertage abdeckt, geht eine direkte Interpretation von feiertag als Vorlagenname irgendwie nicht. Aber direkteingebunden ist di Syntax überschaubar. Was denkst du. Mir schwirrt so der Kopf, wenn ich drüber nachdenke, mir ist fast egal, wie wir es machen.  . Ach! Frohes und friedliches Neues. -- DerFussi 11:42, 7. Jan. 2023 (CET)

Vorlage:Sicherheit im Watt

Ausgangslage

An der Nordseeküste gilt es zum Schutz der Natur und zum Eigenschutz besondere Sicherheitsregeln zu beachten. Ich habe diese bisher in Form einer Infobox in etwa 20 Artikeln eingefügt (Beispiel). Diese Infobox habe ich auf meiner Benutzerseite als Kopiervorlage gespeichert. Änderungen, Ergänzungen usw. sind so aber kaum bzw. nur großem Aufwand möglich.

Vorschläge

Sinnvoller wäre es m. E. die Infobox durch eine neue Vorlage (Name:Sicherheit im Watt) zu erzeugen. Die fertige Infobox befindet sich hier: Benutzer:Eduard47/Bearbeitungsseite#Infobox (Kopiervorlage) --Eduard47 (Diskussion) 16:19, 5. Apr. 2022 (CEST)

Diskussion

+1 Aus meiner Sicht spricht nichts dagegen. -- DerFussi 22:07, 5. Apr. 2022 (CEST)

Muss ich von meiner Seite noch irgend etwas veranlassen oder vorbereiten? ---Eduard47 (Diskussion) 21:57, 11. Apr. 2022 (CEST)

Da ich in den vergangenen 2 Wochen nichts aus der Werkstatt gehört bzw. gelesen habe, habe ich mich mal selber mit der Materie befasst und bin sang- und klanglos zusammengebrochen. Das übersteigt bei weitem mein Wissen und Können im Umgang mit der Wikisoftware. Ich wäre froh, wenn mir die Werkstatt diese Vorlage erstellen könnte. Darf ich hoffen? Schon jetzt ein dickes "DANKE" im voraus. --Eduard47 (Diskussion) 10:48, 18. Apr. 2022 (CEST)

@Eduard47: Erledigt Erstellt als {{Sicherheit im Watt}}. --Nw520 (Diskussion) 13:09, 18. Apr. 2022 (CEST)

Danke Nw520, ich bin total begeistert!!! Einfügen hätte ich es aber auch selbst gekonnt, auch dafür sei Dir gedankt! Gruß --Eduard47 (Diskussion) 13:20, 18. Apr. 2022 (CEST)

{{2 Spalten}}, {{3 Spalten}}, {{4 Spalten}}

Ausgangslage

Soweit der Bildschirm breiter als 800px ist, können die Spalten beliebig klein sein. Dies ist ein Problem, wenn beispielsweise ein Mehrspalten-Element neben einem fließenden Bild platziert ist.

Visualisierung

Ändere meine Größe mit dem Zieher in der unteren rechten Ecke. Kleinere Breite simuliert breites Bild zur rechten Seite.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.

Konkretes Beispiel: München (ggf. Fenster verkleinern zur Verdeutlichung)

Vorschläge

Die CSS-Regeln sollen um die Anweisung column-width: 200px; erweitert werden. Dies sorgt dafür, dass die Spaltenanzahl so lange reduziert wird, bis jede Spalte eine Mindestbreite von 200px hat.

Visualisierung

Visualisierung 200px

Ändere meine Größe mit dem Zieher in der unteren rechten Ecke. Kleinere Breite simuliert breites Bild zur rechten Seite.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.

Diskussion

• 200px ist nur ein Vorschlag, andere Vorschläge sind natürlich gerne willkommen. Ggf. könnte dann auch die 800px-Regel entfallen. --Nw520 (Diskussion) 16:25, 18. Mai 2022 (CEST)

• Ohne große Kommentare. Ich bin bei dir. Bei der Pixelzahl gehe ich auch mit. Da binich komplett schmerzfrei. -- DerFussi 14:07, 31. Mai 2022 (CEST)

• Erledigt --Nw520 (Diskussion) 20:43, 1. Jun. 2022 (CEST)

{{Scroll Gallery}}

Ausgangslage

Screenshot Scroll Gallery

Auf Mobilgeräten wird die Scroll Gallery auch rechtsbündig dargestellt. Daneben quetscht sich der Text. Wer sich mal diese Stelle auf dem Mobiltelefon ansieht, kann erkennen, dass der Text unter Umständen auch so schmal weitergeht, bis ein neuer Absatz kommt.

Vorschläge

Könnte man die Scroll Gallery für Smartphones so einstellen, dass sie nicht umflossen ist, und die volle Bildschirmbreite ein nimmt? Ich besitze kein Tablet um zu schauen, wie das Wiki die Seiten dort darstellt. -- DerFussi 10:28, 10. Jun. 2022 (CEST)

Diskussion

PS: Nebenbei fiel mir ein, dass ich ja auch manchmal das Tag <gallery>...</gallery> einsetze. Aber irgendwie kann ich mich nicht für eins entscheiden. Es bietet ja den Modus slideshow, was ja unserer Scroll Gallery entspricht. Hätte den Vorteil, dass man sich technisch drum kümmert, und nicht unsere Baustelle ist. Mit etwas CSS nachbehandeln kann man es ja. -- DerFussi 20:22, 12. Jun. 2022 (CEST)

Ich kümmere mich um eine Lösung. Danke für den Hinweis. --RolandUnger (Diskussion) 06:27, 15. Dez. 2022 (CET)

Ich denke, dass ich ein Lösung gefunden habe: Bilder werden auf Smartphones bis zu einer Breite von 600px nicht umflossen. --RolandUnger (Diskussion) 07:42, 15. Dez. 2022 (CET)

• Erledigt --RolandUnger (Diskussion) 07:46, 15. Dez. 2022 (CET)

{{Quickbar Bundesland Deutschland}}

Ausgangslage

Moin, die Verlinkungen der Bundesländer sind fehlerhaft, ein Klick auf Bayern bringt einen z. B. nach Hessen. Auch der Maushover zeigt jeweils das falsche Bundesland an. Zumindest passen Maushover und Klick zusammen und weichen nicht voneinander ab.

Vorschläge

Bitte korrigieren, aufgefallen ist es einem Leser, der sich ans Support-Team gewandt hat. XenonX3 (Diskussion) 19:28, 10. Aug. 2022 (CEST)

Diskussion

• Der Fehler tritt bei der Locator Map auf und ist in allen Mediawiki-Skins reproduzierbar. Liegt es an Modul:GetImage? --Nw520 (Diskussion) 02:07, 15. Dez. 2022 (CET)
  • Hmm... Habe es in anderen Ländern getestet¿da funktioniert es, auch in Theiland, wo die Lagekarte auch nicht volle Breite hat. Dann kann es auch die Imagemap von Deutschland sein, aber auf der Modulseite scheint es zu passen. Muss ich die Tage nochmal prüfen, wenn ich mal die Zeit habe. -- DerFussi 07:54, 15. Dez. 2022 (CET)
  • Scheint jetzt zu funktionieren. Die Imagemap von Deutschland war wohl nicht korrekt. Habe mal ein neue eingestellt. -- DerFussi 11:41, 15. Dez. 2022 (CET)