Wikivoyage:Vorlagen/Werkstatt

Aus Wikivoyage
Vorlagenwerkstatt Willkommen in der Vorlagenwerkstatt.

Hier kannst du Fragen zu bestimmten Vorlagen stellen, dir Tipps zur Bearbeitung und Erzeugung von Vorlagen einholen oder Kommentare zu Fragen anderer abgeben.

Inhaltliche Fragen und diskussionswürdige Wünsche zu Vorlagen sollten zunächst auf der betreffenden Diskussionsseite der Vorlage oder einem fachlich zugehörigen Oberartikel besprochen werden. Hinweise dazu findest du oft auch in einer Infobox am Anfang des Vorlagenartikels. Um die technische Umsetzung kümmern sich die Mitarbeiter dieses Vorlagenprojekts anschließend gerne. Da häufig Rückfragen auftreten, beobachte bitte die Seite oder besuche sie regelmäßig, damit du schnell antworten kannst.

Entwürfe für eine Vorlage legt man am besten als Unterseite von Wikivoyage:Vorlagen/Werkstatt, unter Umständen mit dem Nutzernamen als weitere Unterseite, ab. Damit bleiben sie der Nachwelt erhalten und archivierte Diskussionen bleiben im Kontext stimmig. Nutze daher die {{Testvorlage}} nur zum kurzzeitigen Testen in der Entwicklungsphase.

Um eine möglichst rasche und detaillierte Antwort zu erhalten, ist es von Vorteil, möglichst viele der Fragen möglichst genau und detailliert bereits in der Anfrage zu berücksichtigen:

Bei Neuentwicklungen oder Erweiterungen Bei Fehlern
Archive
Archivübersicht · 2013
2014: 1. Quartal · 2. bis 4. Quartal · 2015: 2015
2016: 2016 · 2017: 2017 · 2018: 2018
2019: 2019 · 2020: 2020
  • Was – soll das Gewünschte tun?
  • Wie – soll das Gewünschte aussehen?
  • Warum – ist es hilfreich, so etwas zu haben?
  • Wer – wünscht die Umsetzung?
  • Wo – soll das umgesetzt werden?
  • Wo – findet sich ein Beispiel oder ähnlich Geartetes?
  • Browser-Cache geleert? Nein:
  • Wie – soll es tatsächlich aussehen?
  • Wie – sieht es fehlerbehaftet aus?
  • Wo – tritt das auf?
  • Wo – findet sich ein Beispiel?
  • Was – wurde schon unternommen, um den Fehler zu beheben?

Bevor du eine Vorlage vorschlägst, solltest du dich informieren, ob es möglicherweise bereits eine ähnliche Vorlage gibt, beziehungsweise nicht eine vorhandene erweitert werden kann. Auf unserer Übersichtsseite kannst du dich informieren, ob es bereits etwas passendes für dich gibt.

Bei der Erstellung von Vorlagen gibt es ein paar Dinge, welche besonders zu beachten sind:

  • Die Seiten lassen sich nicht nur am Desktop betrachten. Achte darauf, dass auch die speziell für Mobilgeräte entwickelte Anzeige funktioniert.
  • Wer in Gegenden ohne Internet unterwegs ist, kann mit Kiwix den Reiseführer komplett auf dem Laptop oder Smartphone installieren. Dessen Funktion darf nicht eingeschränkt werden.
  • Über die Browser-Funktion lassen sich die Seiten ausdrucken. Prüfe auch hier, dass es zu keinen Einschränkungen kommt.
  • Manche Informationen werden zentral auf Wikidata abgelegt. Diese Daten lassen sich auf den Artikelseiten einbinden, jedoch ist eine übermäßige Serverbelastung zu vermeiden.

Bei Bildern und Grafiken:

  • Die Größenangabe miniatur bzw. thumb muss unterstützt werden.
  • In der klassischen Desktop-Ansicht muss bei der Anordnung von Bildern auf der rechten Seite ein harmonisches Gesamtbild durch gleiche Bildbreiten erhalten bleiben.
  • In der Anzeigeversion für Mobilgeräte werden Bilder und Grafiken über die gesamte Breite dargestellt. Auch wenn Nutzer vom Standard abweichende Bildgrößen festlegen, funktioniert dies. Die Vorlage soll dies nicht ändern.
  • In der Vollbildanzeige muss das Bild identisch zu dem im Artikeltext sein.

Nachdem du die Vorlage erstellt hast, vergesse nicht, einen Hinweis auf die Vorlage in den Hilfeseiten bei Wikivoyage einzufügen und die TemplateData-Dokumentation einzufügen, um die Bearbeitung im Visual-Editor zu unterstützen.


Hilfreiche Links
Vorlagen-Entwicklung



AirportCode und das verflixte Kommata[Bearbeiten]

Ausgangslage[Bearbeiten]

Die Vorlage AirportCode zeigt je nach Kombination von Parametern und dem Vorhandensein von Daten auf Wikidata mal ein Komma zwischen IATA- und ICAO-Code an und mal nicht. Zudem wird beim Auslassen von |iata=, aber Angabe von |icao= vor ICAO ein leeres Wikidata-span angezeigt. Früher wäre auch ein Komma angezeigt worden (jenes, welches jetzt zwischen IATA und ICAO fehlt), welches aber vor "kürzerem" entfernt wurde.

Um dieses Verhalten zu korrigieren, ist meines Erachtens eine Änderung an AirportCode und Modul:Wikidata2 erforderlich; ggf. auch Modul:Check2: AirportCode verwendet mehrere #ifeq-Vergleiche um zu bestimmen, ob {{Wikidata}}, also indirekt Modul:Wikidata2#getValue eine leere Ausgabe liefert. Durch |ignore_errors=1, welches von Modul:Check2 verarbeitet wird, wird dabei unterbunden, dass Modul:Check2 Fehlermeldungen erzeugt (welche sonst dafür sorgen würden, dass die Ausgabe eben nicht mehr leer ist). Das ursächliche Problem besteht nun eben darin, dass im Fehlerfall die Ausgabe eben nicht leer ist. Modul:Wikidata2#getValue erzeugt eine Kategorie local category, welche vor die Ausgabe konkateniert wird. Dies sorgt dafür, dass der durch category .. errorStr .. check._testParams ( frame:getParent().args, cfgParams["getValue"], 'Wikidata2', 'lower' ) .. display ausgegebene Wert eben nicht leer ist (alle sonstigen Bestandteile sind tatsächlich leer), sondern den Wikitext für die Kategorie beinhalten. Beim Ausgeben der Rückgabe auf einer Seite sieht der erzeugte HTML-Quelltext leer aus, dies hängt aber damit zusammen, dass die Ausgabe bereits durch MediaWiki verarbeitet wurde. Nutzt man hingegen die Ausgabe in einem Vergleich, so besteht keine Äquivalenz zum leeren String mehr.

Die notwendigen Änderungen an AirportCode erfordern das Einfügen weiterer Bedingungen und somit {{Wikidata}}-Abfragen.

Vorschläge[Bearbeiten]

Handfeste Vorschläge habe ich nicht, sondern möchte eher eine Diskussion anstoßen, wie das behoben werden könnte und ob das überhaupt beabsichtigt ist mit Blick auf die vielen notwendigen {{Wikidata}}-Aufrufe.

Sollte beabsichtigt werden, dass bei |ignore_errors=1 weiterhin eine Kategorie hinzugefügt wird, müsste meines Erachtens nach entweder ein weiterer Wert für |ignore_errors= eingeführt werden (bspw. 0 = nein, 1 = nur Kategorien, 2 = stumm) oder ein neuer Parameter. In beiden Fällen, ließe sich die Kategorie dann einfach in Modul:Wikidata2#getValue ausfiltern.

Diskussion[Bearbeiten]

Diese üble Konstruktion von mir in der Vorlage AirportCode kann keine richtige Lösung sein. Eigentlich gehört die Vorlage komplett in ein Modul ausgelagert, das was dort jetzt drin steht ist einfach nur übel. Allerdings werde ich selbst nicht mehr im Wiki programmieren. Ich habe das Thama aus persönlichen und zeitlichen Gründen für mich abgeschlossen. Bevor man sich aber an eine Lösung wagt stellt sich mir die Frage nach dem ICAO-Code. Wer braucht den? Ich halte den für völlig überflüssig in einem Reiseführer. Selbst den IATA-Code braucht man rein praktisch kaum noch, da alle Airline-Webseiten mittlerweile ein Autocomplete haben. Aber er wird halt noch auf vielen Anzeigen benutzt. Also ohne ICAO wäre das Problem nicht mal halb so schlimm. Das sollte eigentlich die erste Entscheidung in der Diskussion sein. Vielleicht kann man das hinter einer Zwischenüberschrift separat als kleine Umfrage mal herausfinden. Zum anderen steht der Code doch im Regelfall immer hinter dem Flughafennamen selbst, oder? Kann man da nicht den Marker benutzen? Braucht man diese Vorlage denn überhaupt noch? -- DerFussi 20:51, 16. Nov. 2020 (CET)[Beantworten]
@DerFussi: Fände eine Umfrage ebenfalls gut. Ich habe jetzt einen Teil der leicht zu ersetzenden Vorkommen (AirportCode nach zugehörigem Marker) entfernt. Die verbleibenden ~270 Einbindungen sind:
  • Einbindungen hinter einem Link bzw. einer Erwähnung eines Flughafens
  • Einbindungen in einem Artikel über einen Flughafen für den Einleitungssatz
  • Einbindungen in Kombination mit einem Marker mit |type=landing site
Ersteres könnte man mit Marker und show=none ersetzen, zweiteres eigentlich restlos entfernen, da die Information ohnehin in der Quickbar steht. Drittes bräuchte meines Erachtens eine Änderung im Modul für vCards/Marker, da bei dem Typ keine Flughafencodes angezeigt werden.
Soll die Umfrage hier in die Vorlagenwerkstatt oder in die Lounge? --Nw520 (Diskussion) 12:29, 17. Nov. 2020 (CET)[Beantworten]
Nachtrag: Eine solche Migration ließe sich auch auf {{IATA}} anwenden. --Nw520 (Diskussion) 12:32, 17. Nov. 2020 (CET)[Beantworten]
Ich würde die Umfrage hier stellen aber in der Lounge einen Aufruf platzieren. Hier ist einfach der bessere Platz. In der Lounge geht irgendwann alles unter. Per Permalink könnte man in den Artikelvorgaben auf die Umfrage hier verlinken. Dass AirportCode und IATA verschwinden, hat auch den Vorteil, dass sich die Anzahl unserer Vorlagen etwas reduziert. Alles ein weiterer kleiner Schritt, das Wiki übersichtlicher für Neulinge zu machen. Wenn wir dann noch in den Artikelvorgaben und Hilfen einen Satz verlieren, wie Flughäfen anzugeben sind, sind wir wieder einen Schritt weiter. -- DerFussi 12:42, 17. Nov. 2020 (CET)[Beantworten]

Ablösen der Vorlagen AirportCode und IATA[Bearbeiten]

siehe auch archivierte Lounge-Diskussion

Problembeschreibung[Bearbeiten]

Die Vorlagen AirportCode und IATA dienen zur vorformatierten Einbindung von Flughafencodes mit Verlinkung zur IATA bzw. ICAO. Erstere Vorlage bietet dabei die Möglichkeit entweder durch Auslassen der Parameter oder durch Angabe einer Wikidata-ID die Flughafen-Codes von Wikidata zu beziehen. Dabei werden, wenn vorhanden, sowohl IATA- als auch ICAO-Code angezeigt.
Im Allgemeinen ist der IATA-Code für den touristischen und kommerziellen Flugverkehr gebräuchlicher, sodass durch die zusätzliche Angabe des ICAO-Codes für Touristen und Reisende nur seltenst ein Mehrwert entsteht.

Vorschlag[Bearbeiten]

Ich schlage vor, dass die beiden Vorlagen AirportCode und IATA als veraltet markiert werden und Einbindungen migriert werden:

  • Für Einbindungen von AirportCode im Einleitungssatz von Artikeln über Flughäfen der Form: Der Flughafen Musterstadt (IATA Code: XXX, ICAO Code: XXXX) ist…
    schlage ich vor, dass die Einbindung ersatzlos entfällt. Sowohl IATA- als auch ICAO-Code werden seit Einführung der Flughafen-Quickbar in dieser angezeigt, sodass eine — doppelte und im Fließtext meines Erachtens auch eher unschöne — Nennung nicht mehr notwendig ist.
  • Für Einbindungen in sonstigen Reiseführern hinter der Nennung des Flughafens, beispielsweise im Anreise-Abschnitt, sollen sowohl Name samt etwaiger Verlinkung als auch Einbindung von AirportCode oder IATA durch einen {{Marker}} mit |type=airport ersetzt werden unter Angabe der Wikidata-ID. Durch Angabe von |wikidata= und |type=airport wird von der Vorlage in diesem Fall der IATA-Code, soweit vergeben, angezeigt, ansonsten der ICAO-Code. Zu beachten ist, dass maximal einer der Codes angezeigt wird, wobei IATA bevorzugt wird.
    Sollte ein klickbarer Marker mitsamt Anzeige in der Karte für den Flughafen unerwünscht sein, so kann |show=none gesetzt werden, was die Anzeige von Marker-Symbol und Einfügen in der Karte unterbindet.

Diskussion[Bearbeiten]

Noch ein Hinweis: die Angabe |type=airport in der Vorlage {{Marker}} ist nicht zwingend notwendig, weil der Typ ebenfalls aus Wikidata bezogen werden kann (man spart jedoch Rechenzeit). Da (fast) alle Flughäfen in Wikidata verzeichnet sind, gibt es auch keine Möglichkeit/Notwendigkeit mehr, die Flughafencodes manuell einzupflegen. Es gibt einen Test auf den Typ airport, der aber damit zusammenhängt, dass auch andere Einrichtungen als Flughäfen IATA/ICAO-Codes nutzen können. Die Vorlage gibt absichtlich nur einen Code aus, vorzugsweise IATA, um die Informationsfülle zu begrenzen. Technisch wäre die Ausgabe beider Codes möglich. Mit dem Parameter show = noairport lässt sich die Ausgabe der Flughafencodes unterdrücken. --RolandUnger (Diskussion) 17:36, 22. Nov. 2020 (CET)[Beantworten]
@RolandUnger: Könnte die Anzeige eines Codes auch für |type=landing site aktiviert werden? Soweit ich gesehen habe werden hinter denen öfters ICAO-Codes angegeben. Eine solche Änderung scheint die Funktionsweise von airportType in Modul:Marker_utilities/i18n zu betreffen. --Nw520 (Diskussion) 18:23, 21. Dez. 2020 (CET)[Beantworten]

Stand der Dinge[Bearbeiten]

Dan können wir ja einen Löschantrag stellen. Irgendwann wird dann auch mal {{IATA}} obsolet sein. -- DerFussi 10:54, 25. Jan. 2021 (CET)[Beantworten]
Was machen wir mit dem Sonderfall EuroAirport Basel-Mulhouse-Freiburg (IATA Code: BSL, MHL, EAP) ? -- Balou46 (Diskussion) 20:36, 26. Jan. 2021 (CET)[Beantworten]
@RolandUnger: Sollten nicht automatisch alle drei Codes rausckommen, wenn die Daten von WD kommen? Vorausgesetzt, sie sind richtig erfasst. Sind die Codes gleichwertig? Was steht auf den Tickets? -- DerFussi 21:03, 26. Jan. 2021 (CET)[Beantworten]
Ja, es gibt jetzt maximal drei IATA-Codes für die Vorlagen {{Marker}} und {{vCard}}: EuroAirport Basel-Mulhouse-Freiburg (IATA: BSL, MLH, EAP) . --RolandUnger (Diskussion) 09:58, 28. Jan. 2021 (CET)[Beantworten]
Balou46 war außerordentlich fleißig und hat sich auch den {{IATA}}-Einbindungen angenommen (ich hatte mehr als 500 in Erinnerung!!). Laut Linkliste ist auch diese Vorlage vollständig abgelöst. --Nw520 (Diskussion) 23:10, 11. Mär. 2021 (CET)[Beantworten]

Import ÖPNV Hamburg[Bearbeiten]

Bitte Vorlage:ÖPNV Hamburg zur Verwendung mit {{Rint}} importieren. --Nw520 (Diskussion) 17:28, 26. Mär. 2021 (CET)[Beantworten]

Es ist erledigt: siehe Vorlage:ÖPNV Hamburg. --RolandUnger (Diskussion) 20:09, 27. Mär. 2021 (CET)[Beantworten]

Feiertagsvorlagen {{Id al-Fitr}} und {{Id al-Adha}} erweitern[Bearbeiten]

Ausgangslage

Vorschläge

Bitte diese Vorlagen um |diff= (analog Ostern) erweitern. In manchen Ländern sind diese Feste mehrtägige Feiertage. --4omni (Diskussion) 00:10, 17. Apr. 2021 (CEST)[Beantworten]

Diskussion

Erledigt --RolandUnger (Diskussion) 13:28, 21. Apr. 2021 (CEST)[Beantworten]

Danke. Die Doku habe ich noch ein bißchen ergänzt. Ein Anwendungsbeispiel für beide Feiertage kann man in diesem Artikel sehen. --4omni (Diskussion) 17:41, 21. Apr. 2021 (CEST)[Beantworten]
Anmerkung: {{Id al-Fitr}} und {{1. Ramadan}} sind bis 2035 definiert, {{Id al-Adha}} und {{30. Ramadan}} nur bis 2025. Wer die Daten für die Jahre 2026-2035 parat hat, möge sie bitte ergänzen. --4omni (Diskussion) 23:45, 21. Apr. 2021 (CEST)[Beantworten]
Erst einmal vielen Dank für die Ergänzung. Den 1. Ramadan konnte ich gleich selbst verwenden. Die fehlenden Feiertage lassen sich sicher auftreiben. Ich kümmere mich darum. --RolandUnger (Diskussion) 07:49, 22. Apr. 2021 (CEST)[Beantworten]

Vorlage „Stand“[Bearbeiten]

Ausgangslage[Bearbeiten]

In vielen Reiseführern kommen Stand-Angaben im Fließtext vor, wenn ein Einsatz von vCards nicht möglich bzw. nicht sinnvoll ist oder sich die Stand-Angabe nur auf eine Einzelinformation bezieht. Alleine eine Suche nach insource:/\(Stand 200/ liefert derzeit 63 Ergebnisse, was heißt, dass in mindestens 63 Reiseführern Angaben sind, die seit über 10 Jahren nicht mehr aktiv aktualisiert wurden. Auch insource:/\(Stand 201[0-8]/ liefert mit derzeit 377 Ergebnissen ebenfalls eine große Anzahl an Reiseführern. Aufgrund der verhältnismäßig strengen Suchvorschriften, liegen sicherlich weitere Stand-Angaben vor, die bei der Zählung nicht berücksichtigt wurden.

Momentan gibt es keine einfache Möglichkeit solche alten Stand-Angaben in Artikeln zu finden, was eine aktive Aktualisierung oder wenigstens einen Hinweis auf solche Angaben bei Aufruf des Artikels verhindert.

Vorschläge[Bearbeiten]

Es soll eine Vorlage eingeführt werden, mit der Stand-Angaben formatiert werden können. Hier könnte man sich entweder an |lastedit= von {{vCard}} oder {{Zukunft}} orientieren. Durch die Vorlage werden dann Kategorien für den Artikel gesetzt, die ein leichteres Auffinden ermöglichen und eine einheitliche Ausgabe für die Stand-Angabe erzeugt.

Fragen[Bearbeiten]

  • Wie sollen Kategorien gesetzt werden?: Reicht eine binäre Kategorie analog zu Kategorie:vCard: Angaben veraltet oder soll granulär wie bei Kategorie:Wikivoyage:Veraltet gruppiert werden?
  • Wann ist eine Standangabe veraltet?: Je nach System für die Kategorien muss eine Angabe irgendwann als veraltet deklariert werden. Soll es hierzu einen Parameter geben oder eine feste und für alle Einbindungen einheitliche Frist?
    • Für den Fall, dass es ein klares Ablaufdatum der Information gibt, würde ich vorschlagen, dass stattdessen die Nutzung von {{Zukunft}} empfohlen wird.
  • Wie soll eine Stand-Angabe formatiert werden?: In Reiseführern werden Standangaben teilweise (aber selten) in kleiner Schrift gesetzt: (Stand 2024).

--Nw520 (Diskussion) 15:18, 11. Sep. 2021 (CEST)[Beantworten]

Diskussion[Bearbeiten]

Ich hatte es an anderer Stelle bereits angedeutet. Wichtig wäre aus meiner Sicht zu klären, wer die Zielgruppe für diese Informationen ist. Wikivoyage-Autoren, die diese Wartungskategorien überhaupt kennen und wissen was sich dahinter verbirgt? Ich glaube eher nicht. Ich denke alle wir hier, die sowohl die Vorlagen kennen, als auch die genutzten Wartungskategorien, können zwar feststellen, dass unsere Infos zu alt sind - und welche es sind. Aber wir können sie nicht aktualisieren, weil wir entweder nie dort waren, oder vor etlichen Jahren. Wir wohnen entweder vor Ort (glücklicher Zufall) oder recherchieren aufwändig. Also wer kennt die aktuellen Infos, die wir für das Update brauchen? Eher die (anonymen) Leser und Nutzer, die im schlimmsten Fall noch nie was von Kategorien oder Wikis gehört haben. Ist natürlich nur eine Vermutung meinerseits. Also, zum Selbstzweck für uns Nerds - schade um die Zeit. Also zum einen geht es aus meiner Sicht um die Frage, wie präsentieren wir die Infos, dass es auch die Zielgruppe mitbekommt? Eine Wartungskategorie (in welcher Granulierung auch immer) allein reicht nicht, aus meiner Sicht. Sie kann allenfalls die Basis einer Funktionalität sein. Und zum anderen: Wie gestalten wir die Aktualisierung moglichst einfach? Der VCard-Editor ist schon cool, aber welcher VCard-Eintrag in z. B. Halle (Saale) ist den veraltet, wenn der ganze Artikel in einer Wartungskategorie liegt? Sobald man danach suchen muss, dürften die meisten schon raus sein. Wenn wir für das alles ein Konzept haben, kann man danach schauen, wie man es mit Daten füttert.

Vielleicht sowas, wie eine Meldung am Seitenanfang, dass es alte Daten gibt und die freundliche Frage, ob der Nutzer evtl. drübergucken und aktualisieren möchte. Darunter eine aufklappbare Liste mit Sprungmarken direkt an die veralteten Daten. Da die aktuellen Infos oftmals anonyme Benutzer haben, müsste es standardmäßig aktiv und damit nicht zu aufdringlich sein. Es mit Cookies zu deaktivierbar zu machen, können wir sicher nicht. usw. usw. Jetzt habe ich doch mehr geschrieben. Aus meiner Sicht sollten wir jedenfalls die Zielgruppe definieren. Nur für die WV-Autoren brauchen wir es nicht machen, denke ich. Die fahren im Regelfall nie wieder hin an den Ort, und selbst wenn, sind die so engangiert, dass sie von selbst einen Artikel aktuell halten - auch ohne Vorlagen und Kategorien. -- DerFussi 19:38, 11. Sep. 2021 (CEST)[Beantworten]

Mal umgedreht und etwas ketzerisch gefragt. Wir haben ja schon sowas. Wer von allen WV-Autoren hier kontrolliert den bisher diese Kategorien? UND hatte auch wirklich eine aktuelle Info zu irgendeinem Fall? -- DerFussi 19:43, 11. Sep. 2021 (CEST)[Beantworten]

Ergänzung: Zum anderen sollte für die Autorenschaft prinzipiell geregelt sein, wann ein Stand/Aktualitätsdatum überhaupt gesetzt werden sollte. Aus meiner Sicht nur bei (vor Ort) überprüften Angaben. Ich kann jetzt nur von mir reden. Wenn ich überhaupt an Artikeln arbeite, dann derzeit an polnischen Kleinstädten, die eine IP mal zuhauf angelegt hatte. Bis auf ein paar Restaurants und Hotels, bei denen ich wirklich mal war, ist alles was ich tue eine Internetrechereche (meist Google Maps und bei Sehenswürdigkeiten Stadthomepage und Wikipedia). Sämtliche Inhalte von mir dürften kein Aktualitätsstand bekommen, da sie selbst zum Zeitpunkt meiner Eingabe veraltet sein könnten. Das sollten wir vielleicht jetzt schon für die VCards usw. irgendwo regeln. -- DerFussi 20:03, 11. Sep. 2021 (CEST)[Beantworten]

Veraltete Angaben finden: Mit dem MediaWiki:Gadget-Zukunft.js hatte ich bereits mal einen Versuch gestartet das Auffinden veralteter Angaben — in dem Fall im Zusammenhang mit {{Zukunft}} — bei Aufruf eines Reiseführers zu vereinfachen, indem am Anfang des Artikels zum einen ein Hinweis angezeigt wird und Sprungmarken angeboten werden. Also so ziemlich wie von dir geschildert, nur eben in Form eines Opt-In-Gadgets. Ich kann mir vorstellen, dass auch veraltete Angaben aus vCards mit aufgelistet werden könnten. Eine einfache Angabe vCard: Angaben veraltet reicht aus meiner Sicht fast. Sie müsste nur umbenannt werden, wenn nicht mehr nur von der VCard befüllt.
Wer nutzt das: Ich habe das von mir oben beschriebene Gadget aktiviert und hatte dadurch vereinzelt auch spontan Angaben aktualisiert; entweder wenn ich mich ohne hin über eine Stadt schlau machte oder wenn sie nahe meines Wohnortes liegt. Daher denke ich, dass auch WV-Autoren von solchen Vorlagen profitieren können, da es oft genug vorkommt, dass man eine Information in einen Reiseführer einbringt (z. B. "geschlossen bis x") und nicht mehr daran denkt, dass sie irgendwann auch aktualisiert werden muss. Solange man nicht den Artikel ganz durchliest, fiele dies nicht auf, es sei denn man wird eben aktiv darauf hingewiesen.
Das Zukunft-Kategorien-System, sowie die vCard-Kategorie nutze ich hingegeben so gut wie gar nicht. --Nw520 (Diskussion) 19:02, 12. Sep. 2021 (CEST)[Beantworten]
Unabhängig von Zielgruppe klingt das mit dein Vorschlag vernünftig aus meiner Sicht. Mit dem anderen Konzept kam ich bekanntermaßen nicht klar. Eine Vorlage Namens „Zukunft“ befüllt eine Kategorie namens „Veraltet“, deren Beschreibungstext mit einer Vorlage namens „Zukunftskategorie“ generiert wird. Auch für Nicht-Nerds muss dass ja alles auffindbar und verständlich sein. Auch der Hilfeartikel dazu fehlt noch immer. Das mit dem "Stand" ist für mich verständlicher und wahrscheinlich auch besser einsetzbar, da man mit der veraltet-Variante ja ein Ablaufdatum kennen muss, oder? Eine Gruppierung höchstens jahresweise. Eine Einstieg in "veraltet" frühestens bei 2 Jahren, eher 3, wenn man davon ausgehen muss, dass 80% unserer Inhalte veraltet sein dürften (ich tippe auf eher mehr).
Das Tool schaue ich mir mal an um mitreden zu können. Ich habe es mir nicht eingerichtet, da ich immer davon ausgehe, die Info eh nicht zu haben. Sollten wir ein schickes Werkzeug haben, wäre wirklich die Frage, ob man es wagen sollte, sowas als Opt-Out zu implementieren und damit sogar anonymen Nutzern anzubieten. -- DerFussi 09:30, 13. Sep. 2021 (CEST)[Beantworten]
Unabhängig wäre wichtig: Eine Erklärung, wie man das System einsetzt und wie es funktioniert und eine einfache Eingabemöglichkeit. Auch wenn es nur paar Zeichen sind. Wenn ich {{Stand|2021|09}} eintippen soll, mache ich es nicht, das wäre mir zu viel und würde mich nerven. Da muss irgendwo ein Button hin. Und, wie gesagt, unter welchen Voraussetzungen setzt man es? Aus meiner Sicht nur, wenn die Angabe auch verifiziert ist. Einzelnachweis ist natürlich nicht notwendig. Es reicht ja wenn ich als Autor zu dem Zeitpunkt dort war oder es in der Zeitung stand oder ich es gesichert weiß. Aber nur weil ich heute eine Info eintrage heißt es ja nicht, dass sie zwangsweise aktuell ist (siehe mein Beispiel). Auch um zu verhindern, dass es zu exzessiv eingesetzt wird.-- DerFussi 09:39, 13. Sep. 2021 (CEST)[Beantworten]
Vielleicht noch als Ergänzung. Ich komme ja ursprünglich von der Wikipedia und nutze dort die Vorlage Zukunft recht häufig. Meines erachtens erfüllt die aber auch eine etwas anderen Anwendungsfall. Die Vorlage Zukunft setzt man ein, wenn man zum Zeitpunkt der Erstellung schon weiß, dass die Angabe zu einem klar definierten Zeitpunkt veraltet sein wird. Das ist in der Regel bei Angaben der Fall, die sich direkt auf die Zukunft beziehen. Beispiel: der Satz "Im Juli 2022 wird in Pupsbüttel die größte Kaninchenzüchtermesse der Welt stattfinden." ist ab dem August 2022 nicht mehr sinnvoll. Eine Vorlage "Stand" würde Angaben kennzeichnen, die sich auf die Gegenwart beziehen und potentiell in absehbarer Zeit veralten, bei denen aber nicht klar ist, wann genau z. B. der Preis für ein ÖPNV-Tagesticket --Trockennasenaffe (Diskussion) 08:32, 14. Sep. 2021 (CEST)[Beantworten]
Diese WP-Anwendung der Zukunftsvorlage klingt sinnvoll. Ist so ähnlich wie unsere {{Highlight}}, die ich mal aus WP/en importierte. Dabei wird eine Information nach dem Ablaufdatum gar nicht mehr angezeigt. Wirklich genutzt wird es aber auch nicht. Aber das sind weitere Baustellen. Erstmal das hier. -- DerFussi 09:38, 14. Sep. 2021 (CEST)[Beantworten]
@Nw520: Leider wie so oft wenig Beteiligung. Ich hake nochmal in der Lounge nach. Dein Gadget hatte ich mir mal angeschaut, sieht praktisch aus. Ich hatte es mir aber wieder deaktiviert wegen Inline-CSS und ich habe eine eigene CSS für einen Dark-Skin. Mittlerweile weiß ich ahber, mit welchem Trick ich mit meiner eigenen common.css trotzdem Inline-CSS überschreiben. Aber wir sind auch gerade dabei, ein paar Klassen einzurichten bzw. ein paar Dinge glattzuziehen. -- DerFussi 04:43, 13. Dez. 2021 (CET)[Beantworten]
Wir dürfen natürlich nicht nur danach fragen, wie wir das kontrollieren und ggf. aktualisieren können und wollen. Wichtig ist für mich ebenso eine für den nicht angemeldeten Benutzer erkennbare Angabe. Ich habe dazu in etwa 20 von mir bearbeiteten Artikeln die Einwohnerzahlen von Ortsteilen in Kleinschrift z. B. mit {{Einwohnerzahlen-Stand: 01.01.2021}} (Beispiel) gekennzeichnet. Ich führe darüber ein Liste und versuche, die Daten zu beschaffen. So kann der Leser sich ein Urteil über die Aktualität machen. Damit ist aber das Kategorien-Problem noch nicht gelöst. Natürlich könnte man die Angabe zusätzlich mit {{Zukunft}} kennzeichnen, das erfordert aber zusätzlichen Aufwand und wird unterbleiben. Ideal wäre m. E. eine Kombination aus für Leser sichtbare Hinweise und auswertbare Daten. Wobei natürlich nicht nur bei den vorgenannten Einwohnerzahlen das Prüfdatum schon mal mindestens 6 Monate in der Zukunft liegen müsste. Übrigens: Das von Nw520 erwähnte Gadget sind für mich böhmische Dörfer. Ich kann damit absolut nichts anfangen. Die für den angemeldeten Autor erscheinende Anzeige sollte in etwa so wie bei {{Zukunft}} erscheinen und zu der entsprechenden Stelle führen. Ich hoffe, mit einer einfachen Vorlage ließe sich das realisieren. --Eduard47 (Diskussion) 21:55, 13. Dez. 2021 (CET)[Beantworten]
Danke Eduard47, für deine Hinweise. Sichtbarkeit für angemeldete Benutzer: Mein Hauptanliegen bei diesem Werkstattvorschlag ist, eine einheitliche und maschinell auffindbare Stand-Anzeige einzuführen. Die bisherigen Standangaben in unterschiedlichen Variationen (Kleinschrift, Datumsformat) sollen nach meiner Vorstellung eins-zu-eins durch die Vorlage ersetzbar sein und somit auch, wie schon bisher, dem Lesenden angezeigt werden (zusätzlich mit CSS-Klassen, als wahrscheinlich ungenutzte Möglichkeit, sie auszublenden). Meine erste Frage, die hier in der Werkstatt geklärt werden soll, ist, ob eine solche Vorlage sinnvoll und von Autoren annehmbar wäre. Konkrete noch offene Details wie Gestaltung und Kategorie-Sytematik würden sich bei positiver Grundstimmung anschließen. Kombination mit Zukunft: Eine von Autoren verlangte Kombination mit Zukunft ist in meinen Augen nicht umsetzbar, da, wie du sagtest, zu aufwendig (und Quelltext-Überforderung). Unter der Annahme, dass man ein elaboriertes Kategoriesystem wie bei {{Zukunft}} möchte, könnte man die Parameter auch in die Stand-Vorlage reinziehen à la {{Vorlage|2021|01|ablaufjahr=2022}}. Um die Verzahnung mit Zukunft würde sich dann die Stand-Vorlage kümmern, Gadget: Das Gadget kannst du über die Einstellungen aktivieren, einen Entwurf für einen Passage in einem Hilfeartikel findet sich in meinem On-wiki-Notizbuch. Nach Aktivierung ist keine weitere Interaktion notwendig: Das Gadget wird bei Bedarf mit einer Warnbox am Reiseführeranfang auf sich aufmerksam machen und einen Sprunglink zur betroffenen Stelle anbieten (bei Timeless ist der Sprung aufgrund des Sticky-Headers leicht versetzt – ohnehin werde ich das Gadget zukünftig überarbeiten (weniger jQuery, CSS-Klassen, statt Inline)). --Nw520 (Diskussion) 15:54, 14. Dez. 2021 (CET)[Beantworten]
@Nw520, Eduard47: Also von mir aus: Feuer frei. Auch gleich {{Stand}} nennen, oder? Selbst wenn sie erstmal noch nichts weiter, als die Anzeige macht. Bin gerade erst wiede rauf eine Aktualitätsangabe gestoßen, da hat der AUtor nur einen HTML-Kommentar in den Wikitext geschrieben. CSS-Klassen und Optik betreffen, gern auch in der VCard gucken, dass es äquivalent umgesetzt ist. -- DerFussi 21:30, 18. Dez. 2021 (CET)[Beantworten]
Moin Nw520, das wird dann wohl bei Dir hängen bleiben, meine Programmierkenntnisse nähern sich der Zahl "0" (=Null). Trotzdem möchte ich helfen so gut es geht. Meine Vorstellung wäre eine neue Vorlage {{Stand}}, die genauso aufgebaut sein sollte wie {{Zukunft}} erweitert um ein zusätzliches Feld für das "Verfallsdatum". Dieses könnte dann der Autor festlegen. Die für alle sichtbare Anzeige im Artikel sollte dann (vielleicht auch in Kleinschrift) z. B. lauten: {{Stand: 31.12.2020}}. Aber das ist nur meine persönliche Meinung. Vermutlich gibt es bessere Lösungen, sie müssen aber einfach sein. Gruß --Eduard47 (Diskussion) 11:06, 19. Dez. 2021 (CET)[Beantworten]

────────────────────────────────────────────────────────────────────────────────────────────────────Habe mal einen Entwurf in der Testvorlage abgelegt. Stimmt die Richtung?
Soweit ich sehe, setzt {{vCard}} bzw. das zugehörige Modul keine HTML-Attribute für lastedit-Angaben, weshalb ich vorerst einen erfundenen Platzhalter nutze. Zudem ist die CSS-Klasse listing-lastedit in vCards scheinbar spezifisch für diese gedacht, weshalb ich hier auch eher eine neue CSS-Klasse nutzen würde. --Nw520 (Diskussion) 17:15, 20. Dez. 2021 (CET)[Beantworten]

Nicht nur die Richtung stimmt, Du bist fast schon am Ziel. --Eduard47 (Diskussion) 17:39, 20. Dez. 2021 (CET)[Beantworten]
@Nw520, Eduard47: - geht in Ordnung. -- DerFussi 12:47, 22. Dez. 2021 (CET)[Beantworten]
Ich habe die Vorlage jetzt in {{Stand}} angelegt. Ich hätte noch zwei kleinere Detailfragen und zwei große:
  • Das Ablaufdatum wird in einem Parameter im Format |ablauf=YYYY-MM angegeben, muss aber in der Vorlage wieder zerlegt werden, was einen höheren Rechenaufwand gegenüber zwei getrennten Parametern für Jahr und Monat (z. B. |ablaufY=, |ablaufM=) bedeutet. Ich habe mich der Übersichtlichkeit halber für dieses Format entschieden, ist das sinnvoll?
  • Passt das Datumsformat 1. Jan 2021? Führende Nullen beim Tag werden entfernt und der Monat mit 3 Buchstaben und ohne Punkt dahinter abgekürzt.
  • Bisher fehlen noch Kategorien. Da die Vorlage nun auf {{Zukunft}} zurückgreift, muss das System nicht mehr groß komplex sein. Sollen Kategorien pro Jahr à la Kategorie:Wikivoyage:Standangabe aus YYYY vergeben werden? Die Monate wären (nur) in der Sortierung berücksichtigt.
  • Ich fände relative Zeitangaben beim Ablaufdatum nett (um beim Aktualisieren nicht zwei Stellen bearbeiten zu müssen). Zum Beispiel |ablaufIn=1y, um auszudrücken, dass als Ablaufdatum die Standangabe plus 1 Jahr genutzt werden soll. Ich kann schwer sagen, ob das umsetzbar ist, aber wäre eine solche Möglichkeit grundsätzlich interessant? --Nw520 (Diskussion) 19:21, 22. Dez. 2021 (CET)[Beantworten]
Ich bin schlichtweg begeistert. Hier meine Meinung. Mich würde allerdings auch die Meinung anderer Autoren interessieren.
  • Zum Format Ablaufdatum: Ich würde der Einfachheit halber bei der Erfassung der Daten die Variante |ablauf=YYYY-MM bevorzugen. Das ist m. E. klarer erkennbar.
  • Das Datumsformat 1. Jan 2021 ist für mich okay.
  • Kategorien: Da enthalte ich mich, habe davon keine Ahnung.
  • Relative Zeitangaben: sind m. E. nicht notwendig, die Erfassung des Ablaufdatums wird wohl niemanden überfordern. Gruß --Eduard47 (Diskussion) 20:23, 22. Dez. 2021 (CET)[Beantworten]

Vorlage "Highlight" o.ä.[Bearbeiten]

Vorschlag

Ich könnte gut ein Bausteinchen gebrauchen, mit dem sich in längeren Artikeln vCards oder andere Textelemente akzentuieren lassen, um zu signalisieren, dass das Item ein Highlight ist, auf das der Autor der Seite besonders hinweisen möchte. Nicht nur Sehenswürdigkeiten, sondern auch z. B. das beste Restaurant in einer längeren Liste o.Ä. Ich meine etwas ganz Kleines, Parameterfreies, das keinen eigenen Absatz erzeugt, sondern in Fließtexte passt, etwa ein Sternchen, gefolgt von den Worten „Empfehlung der Redaktion“, „Highlight“ oder ähnlich, beides mit gemeinsamem farbigen Hintergrund. Gibt es so etwas schon bzw. spricht irgendetwas dagegen, so etwas zu erzeugen, und wenn nicht, wie gehe ich da vor (habe schon lange keine Vorlage mehr erstellt und bin da ein bisschen rostig)? Gruß, --Stilfehler (Diskussion) 17:35, 16. Sep. 2021 (CEST)[Beantworten]

Diskussion

Meinst Du so etwas: Top-Sehenswürdigkeit wie hier? --Eduard47 (Diskussion) 17:52, 16. Sep. 2021 (CEST)[Beantworten]

Das ist es nicht 100%, weil das Element nicht narrensicher selbsterklärend ist (für eine Erklärung muss entweder mit dem Mauszeiger darüber schweben oder in eine Legende schauen), aber ich glaube, damit kann ich schon einmal ganz gut arbeiten. Danke! --Stilfehler (Diskussion) 18:29, 16. Sep. 2021 (CEST)[Beantworten]

Bewegliche Feiertage ohne hinterlegte Formel[Bearbeiten]

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]
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)[Beantworten]

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

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)[Beantworten]
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)[Beantworten]
@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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]

Links auf diese vCard[Bearbeiten]

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)[Beantworten]

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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
In diesem Zusammenhang nicht uninteressant: m:Community Wishlist Survey 2022/Miscellaneous/Include section links in WhatLinksHere --Nw520 (Diskussion) 00:44, 30. Jan. 2022 (CET)[Beantworten]
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)[Beantworten]
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)[Beantworten]

──────────────────────────────────────────────────────────────────────────────────────────────────── 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)[Beantworten]

Abweichende Termine für Feiertage[Bearbeiten]

Ausgangslage[Bearbeiten]

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)[Beantworten]

Vorschläge[Bearbeiten]

Diskussion[Bearbeiten]

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)[Beantworten]

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)[Beantworten]
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)[Beantworten]

Graphiken bei {{rint}} fehlen[Bearbeiten]

Ausgangslage[Bearbeiten]

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)[Beantworten]

Vorschläge[Bearbeiten]

Diskussion[Bearbeiten]

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)[Beantworten]
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)[Beantworten]
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)[Beantworten]
  • 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)[Beantworten]
Danke! --4omni (Diskussion) 16:49, 7. Feb. 2022 (CET)[Beantworten]

{{Feiertag}}[Bearbeiten]

Ausgangslage[Bearbeiten]

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?[Bearbeiten]

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?[Bearbeiten]

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[Bearbeiten]

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)[Beantworten]

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)[Beantworten]

Diskussion[Bearbeiten]

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)[Beantworten]
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)[Beantworten]
Erledigt Mit geringfügigen Änderungen bei der Implementierung umgesetzt. --Nw520 (Diskussion) 14:36, 15. Okt. 2022 (CEST)[Beantworten]
@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)[Beantworten]
@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)[Beantworten]
@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)[Beantworten]

@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)[Beantworten]

Vorlage:Sicherheit im Watt[Bearbeiten]

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)[Beantworten]

Diskussion

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

Muss ich von meiner Seite noch irgend etwas veranlassen oder vorbereiten? ---Eduard47 (Diskussion) 21:57, 11. Apr. 2022 (CEST)[Beantworten]
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)[Beantworten]
@Eduard47: Erledigt Erstellt als {{Sicherheit im Watt}}. --Nw520 (Diskussion) 13:09, 18. Apr. 2022 (CEST)[Beantworten]
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)[Beantworten]

{{2 Spalten}}, {{3 Spalten}}, {{4 Spalten}}[Bearbeiten]

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

{{Scroll Gallery}}[Bearbeiten]

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)[Beantworten]

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)[Beantworten]

Ich kümmere mich um eine Lösung. Danke für den Hinweis. --RolandUnger (Diskussion) 06:27, 15. Dez. 2022 (CET)[Beantworten]
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)[Beantworten]

{{Quickbar Bundesland Deutschland}}[Bearbeiten]

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)[Beantworten]

Diskussion

Öffnungszeiten von Wikidata in {{VCard}}[Bearbeiten]

Ausgangslage

Ich habe mich heute mal wieder mit Öffnungszeiten aus Wikidata beschäftigt, und mir sind ein paar Probleme bzw Fehler aufgefallen:

  • Der erste Weihnachtsfeiertag wird mit 25.Dez ersetzt, der zweite aber nicht.
  • Rosenmontag wird durch „RosenMo“ ersetzt.
  • Für den Fettdonnerstag bzw. Weiberfastnacht gibt es keine gut Lösung. Es existiert zwar d:Q14915111 als generische Lösung, aber die Ausgabe ist da alles andere als gut. Optimal wäre natürlich, wenn man den lokal gängigen Begriff verwenden könnte, aber weiß nicht iwe das gehen soll.
  • Für den Karnevallssonntag Habe ich gar nichts gefunden.
  • Viele Elemente, wie z. B. die Tage an denen geschlossen ist, erscheinen in der Reihenfolge, wie sie in Wikidata hinterlegt sind. Diese Reihenfolge ist oft wenig sinvoll und lässt sich auch nicht nachträglich ändern. Vielleicht kann man hier jeweils eine Sortierung nach einem sinnvollen Kriterium entwickeln, z. B. bei den geschlossenen Tagen nach dem Datum.

Vorschläge

Diskussion

Das ist jetzt wahrscheinlich viel Zeug, aber vielleicht lässt sich ja etwas davon leicht lösen.--Trockennasenaffe (Diskussion) 14:18, 3. Jan. 2023 (CET)[Beantworten]

  • Die Nutzung von Öffnungszeiten ist das Aufwändigste im vCard-Modul.
  • Wir müssen für die Anzeige der Datums- und Uhrzeitangaben eine Tabelle für die Übersetzung vorhalten, um die Rechenzeit nicht ins Unermessliche steigen zu lassen: Modul:Hours/i18n. Um zu erkennen, in welchen Artikeln bisher nicht vorgesehene Übersetzungen benutzt werden, gibt es die Kategorie Kategorie:VCard: Öffnungszeit-Label aus Wikidata, die ich fast täglich auswerte. D. h., es wird immer mal vorkommen, dass neue Wikidata-Ids benutzt werden. Das ist nicht tragisch, denn als Fallback kann die Bezeichnung aus Wikidata benutzt werden (kostet aber Rechenzeit). Aber die Einträge in Wikidata von heute hätte ich erst morgen ausgewertet. Andererseits kommen einzelne Termine und Uhrzeiten mehrfach vor. Z. B. d:Q14915111 und d:Q15834118 für Weiberfastnacht. Nicht immer erwische ich gleich alles. Deshalb auch die Wartungskategorie.
  • Der Karnevallssonntag heißt Tulpensonntag.
  • Das Programm sieht in der Wikidata-Datenbank nur eine Id, weder ein Datum noch eine Uhrzeit: nur Ids. Die lassen sich nicht sinnvoll sortieren. Es ist empfehlenswert, die Einträge in Wikidata in der Reihenfolge vorzunehmen, wie sie später benötigt werden.

Erledigt --RolandUnger (Diskussion) 17:40, 3. Jan. 2023 (CET)[Beantworten]

Nach der langen Diskussion (siehe hier) im Herbst 2020 habe ich es aufgegeben, Öffnungszeiten in WD zu erfassen. Einerseits ist mir das viel zu aufwändig, teils unlogisch und unpraktisch, andererseits wird diese Daten wohl in Zukunft kaum jemand pflegen. In der vCard ist das alles viel einfacher, erst recht im vCard-Editor! Insbesondere Öffnungszeiten an besonderen Tagen sind häufig Änderungen unterworfen, niemand wird das aktualisieren, einfach auch weil man es kaum erfährt. Falsche Daten sind für den Benutzer ärgerlicher als fehlende. Wer die speziellen Termine wissen will, schaut auf der jeweiligen Website nach, und die haben wir verlinkt. Jeder Veranstalter sollte ein Interesse daran haben, seine Daten ordentlich zu präsentieren. Das können wir überhaupt nicht leisten! Eduard47 (Diskussion) 18:28, 3. Jan. 2023 (CET)[Beantworten]
Ich hab das einen etwas anderen Blickwinkel drauf. Für mich ist die deutsche Wikivoyage nur eine Anwendung von Wikidata unter vielen und der eigentlich Nutzen ist die Daten maschinenlesbar zu speichern. Das bietet keine Website. Damit kann man dann auch komplexere Fragen automatisiert beantworten wie "Hat das Museum jetzt gerade geöffnet?" oder welcher Zoo im Umkreis von 100 km ist nächsten Sonntag um 10 Uhr geöffnet. Ich denke, darin wird die Zunkunft liegen und weniger ist etwas Prosatext für spezielle Nutzergruppen, auch wenn das sicherlich noch länger eine Anwendung sein wird. Allerdings wundert es mich, das die Representation von Daten und Uhrzeiten bei Wikidata offenbar weder für Menschen noch für Maschinen wirklich gut geeignet sind wenn ich RolandUnger da richtig verstanden habe. Ob man das nicht hätte besser machen können? Trockennasenaffe (Diskussion) 19:26, 3. Jan. 2023 (CET)[Beantworten]
Vielen Dank schon mal, das ist schon sehr aufschlussreich. Also denn werde ich in Zukunft Sachen ohne Übersetzungstabelle einfach hinzufügen im Wissen, dass das dann abgearbeitet wird. Was mich noch interessieren würde: Wie kann denn eine Uhrzeit und ein Datum eine ID sein? Gibt es für alle Daten und alle Uhrzeiten eine ID? Das wären doch nicht endlich viele. Mit den Karnevalsfeiertagen ist halt das Problem, dass sie überall anders heißen. Bei und ist z. B. der Begriff Weiberfastnacht weitgehend unbekannt, da heißt das Fettdonnerstag. Aber da ist wohl wenig zu machen. d:Q15834118 wollte Wikidata übrigens an der Stelle nicht, da es nicht die richtige Oberklasse hat. "Es ist empfehlenswert, die Einträge in Wikidata in der Reihenfolge vorzunehmen, wie sie später benötigt werden". Und wenn man nachher etwas hinzufügen möchte, weil sich etwas geändert hat oder etwas vergessen worden ist? Dann muss man alles löschen und neu hinzufügen? Sehr aufwändig, zudem man auch für jede Angabe eigentlich wieder eine Quellenangabe braucht. Trockennasenaffe (Diskussion) 18:43, 3. Jan. 2023 (CET)[Beantworten]
So schlimm ist das mit Wikidata nicht. Wenn man die QuickStatements nutzt ist das schneller, als es in der VCard einzutippen, und ohne die dort möglich Tippfehler. Meine Excel-Datei kann mittlerweile mit WiFi-Ausstattung, Öffnungszeiten und all dem Kram umgehen. -- DerFussi 18:47, 3. Jan. 2023 (CET)[Beantworten]
Es ist richtig: jede Uhrzeit hat eine eigene Id, und einige sind doppelt: es sind bei Minutengenauigkeit 1440 Varianten, also noch endlich viele (verglichen mit 101 Mio Einträgen). Ich habe mir sogar schon überlegt, ob man den Wikidata-Programmierern nicht die Aufgabe stellen kann, Vergleichsoperationen zwischen gleichartigen Werten zu ermöglichen. Viel wichtiger wäre, dass man noch später Sortierungen manuell durchführen kann. Denn das mit nötigen Löschungen kann eigentlich nicht der Normalfall sein.
Unterschiedliche Begriffe kommen leider vor. Wichtig wäre, dass sie in Wikidata alle hinterlegt sind. Aber das müssen eigentlich andere machen. Aber es sind Menschen, die herausfinden müssen, dass Weiberfastnacht 52 Tage vor Ostern ist. Und ich kenne noch schmotziger Donnerstag. Im Modul Modul:Ostern habe ich mal versucht, alternative Varianten zusammenzustellen: es sind viele. --RolandUnger (Diskussion) 19:29, 3. Jan. 2023 (CET)[Beantworten]
Abfrage für Tageszeiten in Stundenpräzision, Minutenpräzision und Sekundenpräzision (86.400), die Spalte Zeitindex entspricht den Stunden/Minuten/Sekunden seit 00:00:00. Für mich ist es nur schwer begreiflich, dass man dafür keinen neuen Datentypen „Zeitstempel“ eingeführt hat. --Nw520 (Diskussion) 13:09, 4. Jan. 2023 (CET)[Beantworten]
Kleine Anmerkung was die Reihenfolge in WD angeht: Die lässt sich mittels d:Wikidata:Tools/Enhance user interface#RearrangeValues ändern. --Nw520 (Diskussion) 13:09, 4. Jan. 2023 (CET)[Beantworten]

{{Region List}}[Bearbeiten]

Ausgangslage

Die Vorgabe zu Ländern sieht momentan „Regionen“ als ersten Abschnitt vor. In diesem Abschnitt wird gerne die Vorlage {{Region List}} eingesetzt. Bei eingeklapptem Inhaltsverzeichnis in Timeless oder Vector, oder generell in Vector (2022) führt dies bei kurzem Einleitungstext aufgrund der Quickbar zu einer großen leeren Fläche zwischen Abschnittsüberschrift und Anfang der Region List. Dies ist unschön.
Grund für diese Darstellung ist, dass die Region List erzwingt, dass das rechtsbündige Bild und die Auflistung der Regionen auf einer Höhe sind, damit der Bezug erkennbar ist.

Vorschläge

  • Nicht mehr erzwingen, dass Liste und Bild auf einer Höhe sind. Dies würde aber dazu führen, dass das Bild ja nach Länge der Quickbar, Länge des Texts vor dem Vorlagenaufruf und Menge der platzierten Bilder weit von der Liste entfernt ist und somit der Bezug nicht mehr klar wird. --Nw520 (Diskussion) 21:53, 21. Nov. 2023 (CET)[Beantworten]

Diskussion

Wir hatten schon mal eine Diskussion dazu, ohne weitergekommen zu sein. @DocWoKav, Eduard47, RolandUnger: waren damals auch am Start. Ich habe neulich auch schon über eine mögliche Lösung gegrübel und festgestellt, dass auf dem Smartphone, bzw. der mobilen Ansicht das Bild über die Auflistung rutscht, wenn es schmal zugeht. Ist es technisch möglich das "diese Konstruktion" in den freien Raum zwischen Inhaltsverzeichnis und Infobox rutscht? Die auch schon mal vorgeschlagene Variante die Reihenfolge der Abschnitte in der Ländervorgabe zu ändern gefällt mir eigentlich nicht sonderlich. Wer einen großen Bildschirm hat und in seinen Wiki-Einstellungen die volle Breite auch nutzt benötigt unglaublich viel Fülltext um das auszugleichen. Praktisch gar kein Länder-Artikel bietet so viel Hintergrundtext, um das aufzufüllen. Klar, könnte man fix ChatGPT anwerfen und sich einen Aufsatz mit Hintergrundinfos generieren lassen, aber das will sicherlich auch niemand. -- DerFussi 22:26, 21. Nov. 2023 (CET)[Beantworten]
In vielen Ländern wie z.B. Deutschland, Frankreich, Österreich, Schweiz usw. stellt sich das Problem nicht, da die Regionen einfach ohne farblichen Bezug auf einer Karte aufgelistet werden. Das sieht zwar nicht schön aus, löst aber das Problem. Vielleicht ist es am einfachsten, die Artikel zu überarbeiten und den Farbbezug zu entfernen, zumindest dort, wo große Lücken auftreten. Das ist keine besonders schöne, aber eine praktische Lösung.--DocWoKav (Diskussion) 08:17, 22. Nov. 2023 (CET)[Beantworten]
Jetzt rein persönlich (weniger praktisch) fände es schöner, wenn alle Länderartikel einen einheitlichen Stil verfolgen und präferiere schon die Karten aus der Region List, zumal die Karten für viele Länder verfügbar sind (wenn man mal in die englische WV-Version) schaut. Und wenn man auf der ersten Regionenebene auch die gleiche Aufteilung benutzt fühlt man sich auch zwischen den Sprachversionen schnell zuhause. Aus der Sicht wäre es schön, wenn wir eine technische Lösung finden. -- DerFussi 08:26, 22. Nov. 2023 (CET)[Beantworten]
  • Die Fragestellung ist schon alt, auch deshalb, weil es kaum brauchbare Lösungen für die (Neu-)Gestaltung der Regionenliste gibt. Sowohl die Quickbar als auch die Regionenkarte werden umflossen, was zu Designproblemen insbesondere auf dem Desktop führt. Und richtig bekommt man die „weißen Löcher“ nicht weg, man hat herrenlose Überschriften bzw. Positionskarten bzw. quetscht den Listentext neben Quickbar und Regionenkarte mit einer weißen Lücke unterhalb der Quickbar: all das sieht nicht toll aus. Auf Smartphones ist es einfacher, weil die Quickbar die volle Breite einnimmt und die Regionenkarte meist auch: d.h., es steht ohnehin alles untereinander.
Wenn die Regionenkarte von der Regionenauflistung zu weit weg ist, verliert die ganze Regionenliste ihren Sinn.
Aus meiner Sicht stellt die „überlange“ (senkrechte) Quickbar das Hauptproblem dar. Nicht nur, dass sie eine Ursache für die „weißen Löcher“ ist, sondern auch für Positionierungsprobleme der nachfolgenden Abschnitte sorgt. Mit anderen Worten, die Quickbar muss deutlich kürzer werden, möglicherweise nur ein Bild und den/die Namen enthalten. Dies würde auch dazu führen, dass man auf dem Smartphone nicht soweit scrollen muss, bis man zum Text gelangt. Ich sehe auf die Schnelle drei Möglichkeiten, dies umzusetzen: (1) die Quickbar geht auf dem Desktop in die (volle) Breite, (2) die weiteren Quickbardaten lassen sich ein- und ausklappen oder (3) die weiteren Daten sind über ein Karussel erreichbar. Dies müsste jedoch auf der Lounge diskutiert werden. --RolandUnger (Diskussion) 09:32, 22. Nov. 2023 (CET)[Beantworten]
Das ist auch ein Ansatz. Aber das betrifft auch das Inhaltsverzeichnis, oder? Bei mir ist es ausgeklappt und damit mindestens genauso lang wie die Quickbar. Wie ist da der Standard für anonyme Leser? Ausschlaggebend für eine Designentscheidung sollte die Ansicht für nicht angemeldete Nutzer sein. -- DerFussi 11:02, 22. Nov. 2023 (CET)[Beantworten]
Ausschlaggebend für eine Designentscheidung sollte die Ansicht für nicht angemeldete Nutzer sein. Das sollte immer ein Grundsatz sein, nicht nur bei der Regionenliste. Ich verwende die vorgegebene (vermutlich auch für nicht angemeldete Nutzer geltende) Voreinstellung Vector (2022). Da ist das Inhaltsverzeichnis links in der Seitenspalte, stört also nicht den Aufbau des Artikels. Die von Roland vorgeschlagene Variante 2 ("Quickbardaten lassen sich ein- und ausklappen") gefällt mir persönlich am besten, ob das auch für nicht angemeldete Nutzer zutrifft kann ich nicht beurteilen, ebenso wenig ob damit das Problem mit der Regionenliste geklärt wird. --Eduard47 (Diskussion) 11:45, 22. Nov. 2023 (CET)[Beantworten]
Stimmt! Ich vergesse das mit dem Standard-Skin oft, da ich mich so an meine Spezialeinstellung gewöhnt habe :-)  Ich muss mir wirklich mal angewöhnen, jeden Artikel in einem anderen Browser gegenzuchecken. Also wegen mir gerne auch eine Quickbardiskussion, wenn das für viele eine gute Option ist. Wenn ein Designgerüst steht, kann man das sicher schnell im Modul implementieren. Ich selbst habe keine Design-Vorliebe, sehe lediglich Einheitlichkeit als sehr wichtig an. -- DerFussi 12:10, 22. Nov. 2023 (CET)[Beantworten]
Da ich selbst leider keine Ahnung von den Möglichkeiten der Programmierung habe, sollen von mir aus die, die es können, machen, was möglich und gut ist. Das ist etwas für Spezialisten. DocWoKav (Diskussion) 13:15, 22. Nov. 2023 (CET)[Beantworten]
Aber die Vorlagenwerkstatt ist nicht nur für die Programmierer. Es geht ja auch darum, praktische und ästhetische Aspekte mit einzubringen. Wenn ein Programmierer dann auch mal sagt „geht nicht“, sucht man halt weiter. Mir ist klar, dass es hier manchmal ermüdend sein kann, weil auch viele Dinge auf WV im Sande verlaufen. Ist leider so. Immerhin kann man hinterher sagen „Hättest du dich geäußert“, wenn jemand meckert. :) -- DerFussi 20:39, 23. Nov. 2023 (CET)[Beantworten]
Kleiner Hinweis: Die Regionenliste steckt auch in diversen Ortsartikeln! Schönen Abend noch wünscht Eduard47 (Diskussion) 21:15, 23. Nov. 2023 (CET)[Beantworten]