Zum Inhalt springen

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

Links hinzufügen
Aus Wikivoyage
Dieser Artikel ist Teil unseres Archivs der Vorlagenwerkstatt.
<<
>>
Archiv vom 31. Dezember 2021

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]


Abgerufen von „https://de.wikivoyage.org/w/index.php?title=Wikivoyage:Vorlagen/Werkstatt/Archiv_2021-12-31&oldid=1643113“