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.

• 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]

• @Qualitätssicherung: Ich nehme Interesse an der Angelegenheit an. --Nw520 (Diskussion) 21:53, 21. Nov. 2023 (CET)[Beantworten]

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]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Wenn ich das richtig mitbekommen habe, hat sich das Verhalten jetzt so geändert, dass die Region List nun neben die Quickbar rutscht - wenn kein Bild/Karte eingebunden ist. Ich werde mir trotzdem noch mal Gedanken über eine Quer-Quickbar machen. -- DerFussi 16:39, 14. Sep. 2024 (CEST)[Beantworten]

Um auch auf Mobilgeräten eine ordentliche Ansicht hinzubekommen müssten wir eigentlich sämtliche Tabellen im gesamten Wiki loswerden. Eine, die in jedem Länderartikel auftaucht ist die Feiertagstabelle. Eventuell kann man ja mit ihr anfangen. Gerne mal auf allen euren Geräten mittesten. Hier drunter ist eine Feiertagstabelle, die sich umorganisieren sollte, wenn man das Browserfenster weit zusammenschiebt. Das technische dahinter ist sicher eher was für Nerds. Aber Testergebnisse und Feedback natürlich gerne. -- DerFussi 23:42, 12. Apr. 2024 (CEST)[Beantworten]

@RolandUnger, Nw520: Ich gebe zu, ich habe mich erst heute mit den grid-Properties beschäftigt. Momentan hat die Tabelle immer 100% Breite. Wenn ich das ändere, sieht sie aus wie wir es kennen, aber lange Texte werden nicht umgebrochen. Gibt vielleicht einen Trick, aber ich bin durch für heute. Aber als Basis, um unsere Feiertage zu optimieren geht es vielleicht. Habe auch noch nicht getestet, welche Breiten wir in den Mediaqueries nehmen sollten und ob wir eine dritte Stufe brauchen. Hier das CSS: Vorlage:Feiertag/test.css -- DerFussi 23:42, 12. Apr. 2024 (CEST)[Beantworten]

Das Ganze geht auch mit richtigen Tabellen und viel weniger Schreiberei: -- RolandUnger (Diskussion) 15:20, 13. Apr. 2024 (CEST)[Beantworten]

• Wie gezeigt, geht das Ganze auch mit "richtigen" Tabellen und viel weniger Schreiberei. Eine Tabelle kann auch ein Grid sein. -- RolandUnger (Diskussion) 15:20, 13. Apr. 2024 (CEST)[Beantworten]

  Auf die Idee bin ich nicht gekommen. Habe das Verhalten, dass ich als Idee hatte, ab einer Breite von 1000px eingebaut. -- DerFussi 09:21, 14. Apr. 2024 (CEST)[Beantworten]

• @RolandUnger, Nw520: Bisher erfolgte keine Rückmeldung. Ich würde in einem ersten Schritt einer "Mobilmachung unserer Tabellen" die Feiertage umstellen. Habe mich selbst noch nicht so intensiv mit der Mobilerkennung beschäftigt. Welche Mediaquery mit welchen Angaben würdet zum switchen auf die schmale Darstellung empfehlen? -- DerFussi 12:41, 1. Aug. 2024 (CEST)[Beantworten]

Neben den Feiertagen sind Anpassungen für ähnliche, weitere Vorlagen notwendig: {{Skipiste}}, {{TK-Radweg}}, {{TK-Autobahn}}, {{TK-Welterbe}}. Zusätzlich wäre es hilfreich, ein paar Klassen zu definieren, die Autoren in manuell erstellte Tabellen setzen können, um sie mobiltauglich zu machen. -- DerFussi 13:41, 14. Apr. 2024 (CEST)[Beantworten]

Man könnte einen Satz Klassen definieren, die Tabellen dazu veranlassen, zwischen vorgebenen Spalten umzubrechen, wenn Browserfenster schmal werden. Je nach zu erwartender Breite einzelner Spalten können Benutzer dann die Position vordefinieren.

• Beispiel: voy-grid-12-3 veranlasst die Tabelle, die dritte Spalte bei Bedarf in eine neue Zeile zu packen. Das Minus zwischen den Zahlen gibt jeweils die Sollbruchstelle(n) an. Die Möglichkeiten sind natürlich limitiert. Da es ein grid ist, können die Spaltengrenzen natürlich nicht springen. Bei fünf Spalten bräuchte man eine Syntax, die angibt, welche Spalte die zwei über ihr liegenden überspannt voy-grid-123-45. Habe gerade nicht auf dem Schirm, welche Zeichen noch so erlaubt sind.
• Eine Reduzierung der Spaltenzahl benötigt eine visuelle Information, was eigentlich zusammengehört, da die Informationen nicht mehr in einer Zeile stehen. Bei meinem Feiertagsvorschlag habe ich mich für gepunktete Linien innerhalb einer "Box" entschieden. Das erfordert aber einiges an Style-Angaben. Wenn wir davon ausgehen, dass wir in diesem Wiki eigentlich immer die Klasse prettytable in den Tabellen verwenden, könnten die mitgeliefert werden. Oder man schafft zwei Sets an Klassen z. B. voy-grid-12-3 und voy-grid-pretty-12-3, einmal ohne einmal mit Design.
• Evtl. gibt es noch andere Designansätze neben dem Umbruch. Möglich wären "Ausklappfunktionen". Die würden aber JavaScript erfordern, mit dem üblichen Pflegeaufwand.

Das wäre vielleicht ein praktikabler Ansatz. Gibt es noch völlig andere Ideen wie wir Tabellen handhaben, die auf dem Mobilgerät möglicherweise wegen ihrer Breite schwer zu handhaben sind oder unerwünschte Effekte erzeugen? -- DerFussi 13:42, 14. Apr. 2024 (CEST)[Beantworten]

Es gibt wie verschiedene Designs bei den Welterbelisten und beide enthalten viel manuellen Code. Besser wäre eine (responsive) Liste mit Tabellen.

Ziel wäre ein Paket von drei Vorlagen, wie bei den Feiertagen:

• {{Welterbe Anfang}}
• {{Welterbe}}
• {{Welterbe Ende}}

Das wäre ein Design wie bei Welterbe in Deutschland. Es ist responsiv. Zum Testen mal das Browserfenster eng zusammenschieben:

	Aachener Dom	1978 als Weltkulturerbe Nr. 3 eingetragen. Modifikation 2013.	1 Aachen Cathedral ​ . Erbaut zur Zeit des Kaisers Karl des Großen, über mehrere Jahrhunderte Krönungskirche deutscher Könige. Die Pfalzkapelle ist Kernstück des Domes, sie ist das erste Gebäude mit Gewölbe nördlich der Alpen. Der Dom erhielt seine heutige Gestalt im Lauf von mehr als 1200 Jahren. Das überragende Hauptwerk der karolingischen Architektur ist heute eines der bedeutendsten Kulturdenkmäler von europäischem Rang. Als erstes deutsches Denkmal wurde der Aachener Dom 1978 in die Liste des UNESCO-Weltkulturerbes aufgenommen. Preis: kostenlos. letzte Änderung: keine Angabe50.774756.0839222222222	Zum Kaiserthron und Karlsschrein gelangt man nur mit einer Führung, aber nicht während eines Gottesdienstes. Dies bedeutet, dass an kirchlichen Feiertagen ebenfalls keine Führung stattfindet. Karten für Domführungen kann man an der Dominformation gegenüber der Domschatzkammer lösen.
	Dom zu Speyer	1981 als Weltkulturerbe Nr. 168 eingetragen.	2 Speyer Cathedral (offizieller Name: Domkirche St. Maria und St. Stephan) ​ . Größte erhaltene romanische Kirche. Die Speyerer Kathedrale mit vier Türmen und zwei Kuppeln wurde 1030 von Konrad II. gegründet und Ende des 11. Jahrhunderts umgebaut. Es ist eines der wichtigsten romanischen Denkmäler aus der Zeit des Heiligen Römischen Reiches. Der Dom war fast 300 Jahre lang die Grabstätte der deutschen Kaiser. letzte Änderung: keine Angabe49.3172228.4425	Die dreischiffige Gewölbebasilika ist das größte romanische Bauwerk in Deutschland, sie war Grablege der Salierkaiser.
	Würzburger Residenz und Hofgarten	1981 als Weltkulturerbe Nr. 169 eingetragen.	3 Würzburg Residence with the Court Gardens and Residence Square, Residenzplatz 2, 97070 Würzburg ​ . Die Würzburger Residenz, zusammen mit dem hinter ihr liegenden Hofgarten und dem vor ihr liegenden Residenzplatz, ist ein bedeutendes Zeugnis des europäischen Barocks. Das prächtige Schloss ist eines der größten und schönsten in Deutschland und ist umgeben von wunderschönen Gärten.letzte Änderung: keine Angabe49.792797617479.9388890432453	Unter der Schirmherrschaft der Fürstbischöfe Lothar Franz und Friedrich Carl von Schönborn wurde es im 18. Jahrhundert von einem internationalen Team von Architekten, Malern (einschließlich Tiepolo), Bildhauern und Stuckarbeitern unter der Leitung von Balthasar Neumann erbaut und dekoriert.

• Ich habe prinzipiell nichts dagegen. Ich würde zum einen einen helleren Hintergrund wählen und die Tabellenreihen durch flex-divs ersetzen, um leichter Responsive Design zu realisieren. Theoretischerweise könnte man dann auch echte Listen realisieren. --RolandUnger (Diskussion) 06:46, 27. Jun. 2024 (CEST)[Beantworten]

• Sowohl mobil wie auch auf dem Desktop sieht das gut aus, gefällt mir. Ich frage mich allerdings, warum in der vCard die „description“ von einer weitergehenden Beschreibung/Erklärung getrennt ist. Vielmehr würde ich bevorzugen, wenn die vCard ohne „description“ verwendet würde (somit hätte sie eine eigene Zeile, also als Marker), der restliche Text dann separat darunter angeordnet würde, gern auch mit Zeilenumbrüchen. Aber das ist nur meine persönliche, nicht maßgebende Ansicht, sagt --Eduard47 (Diskussion) 10:23, 27. Jun. 2024 (CEST)[Beantworten]

• Ja, Das mit dem Grid war nur für den Start zum Gucken. Wichtig wäre erstmal wie es generell aussehen soll, gerade bezüglich der unterschiedlichen Inhalte in den einzelnen Welterbe-Artikeln. Die Tabellen hatte ich wegen des putzigen Effekts genutzt, dass die erste Spalte nicht immer gleich breit war (obwohl eine Bildbreite angegeben war), und weil das Wiki-Markup bereits vorhanden war. Alle Konzepte haben ja da ihre Eigenheiten. -- DerFussi 13:10, 27. Jun. 2024 (CEST)[Beantworten]

• Alle Meinungen sind maßgebend. Hoffen wir auf ein paar Rückmeldungen -- DerFussi 13:11, 27. Jun. 2024 (CEST)[Beantworten]

• Bei Verwendung des Markers anstelle der vCard würden auch die hier überflüssigen subtypes und Adressen vermieden. Eduard47 (Diskussion) 08:48, 28. Jun. 2024 (CEST)[Beantworten]

• Macht Sinn. Sollten wir dann in die Vorlagen-Doku bei den Anwendungshinweisen schreiben.
• Ich mache in den nächsten Wochen mal einen weiteren Entwurf der eigentlichen Vorlagen mit etwas anderem HTML (Listen sind auch vom Inhalt her die richtigeren Tags) als Ausgabe und binde auch mal die Typen (H,K,D) und die Jahreszahl als eigene Option mit ein. Das stellt auch etwas Einheitlichkeit sicher. -- DerFussi 09:06, 28. Jun. 2024 (CEST)[Beantworten]

Bitte alle öffentlichen Verkehrsmittel an einer Location. Ein Bahnhof darf dazu keine Voraussetzung sein. Bus muss reichen. Beispiel Gstadt am Chiemsee. Die IBNR lautet hier 844004. Was wollt ihr noch wissen, um das Projekt nach vorne zu bringen? --ChiemseeTraunstein (Diskussion) 09:50, 29. Jul. 2024 (CEST)[Beantworten]

Vorlage {{RailQuery}}

Man kann auch eine Haltestelle auf Wikidata erfassen, es muss kein Bahnhof sein. Die Frage ist, ob wir das im Artikel haben wollen, und wieviel. Wir können ja nicht in einem Artikel alle Bushaltestellen einer Stadt auflisten. Wikivoyage ist keine Fahrplanauskunft. -- DerFussi 11:10, 29. Jul. 2024 (CEST)[Beantworten]

Wen meinst du mit "wir"? Wird hier auch abgestimmt, oder was? Wer entscheidet das. Also mir ist das zu suspekt, ich lösche diese Anfrage in Kürze. Tschüss--ChiemseeTraunstein (Diskussion) 20:49, 29. Jul. 2024 (CEST)[Beantworten]

Mit "wir" meine ich die Wikivoyage-Community. Hier an dieser Stelle tauschen wir uns aus und versuchen einen Konsens zu finden. Also erstmal läuft hier ne Weile eine Diskussion, in der man alles auslotet und versucht, sich auf etwas zu einigen. Klappt das nicht, und es gibt keinen Konsens, wird abgestimmt, aber so weit sind wir ja noch nicht. Siehe Entscheidungsfindung. -- DerFussi 20:51, 29. Jul. 2024 (CEST)[Beantworten]

Allerdings wage ich von einer Tendenz zu sprechen -- DerFussi 20:59, 29. Jul. 2024 (CEST)[Beantworten]

Solche Pläne sind nicht aktuell zu halten, es pflegt ja schon kaum jemand die Aktualität von gefühlt 90% der Artikel. --Qualitätssicherung (Diskussion) 11:27, 20. Aug. 2024 (CEST)[Beantworten]

@ChiemseeTraunstein: bindet ja öfter Liniennetzpläne in Artikeln ein. Nun gab es dazu ein bissel Hin- und Her. Ich habe den Aktualitätsstand entfernt, da man den nicht manuell laufend halten kann und man beides nicht mitbekommt, sowohl wenn auf Commons eine neue Karte zur Verfügung gestellt wird oder die vorhandene geupdatet wird. Aber eigentlich steht alles auf Wikidata und dort ist die Community größer, das aktuell zu halten. Beispiel Straßenbahn Cottbus. Wir sollten Netzpläne generell von Wikidata beziehen.

Eine Vorlage {{Netzplan}} zeigt die Karte an. Optionale Parameter erlauben die Angabe der Symbole für Bus oder Bahn. Beispiel: {{Netzplan|Q150012|tram|bus}} Das würde die Karte für die Cottbusser Straßenbahnen einblenden, mit den Symbolen für Bus und Bahn und den Aktualitätsstand dazuschreiben (im Beispiel wäre das 2019). Baut jemand eine neue Karte und aktualisiert Wikidata müssen wir gar nichts tun und unsere Artikel sind immer aktuell.

Natürlich kann man sowas auch manuell einbinden. Mir geht es hauptsächlich um Einheitlichkeit und minimalen künftigen Pflegeaufwand. Fehlen eine Karte und ein Aktualitätsstand auf Wikidata, wäre es besser, dort die Daten zu pflegen, anstatt hier manuell etwas einzubauen. -- DerFussi 11:01, 15. Aug. 2024 (CEST)[Beantworten]

Danke, dass du das hier bringst. Es ist nicht von der Hand zu weisen. Und wie benutzt man deine Vorlage "Netzplan"? Bei mir kommt der folgende, absolut geile Text, obwohl das Erstellen doch verboten ist: "Diese Seite enthält momentan noch keinen Text. Du kannst sie erstellen, ihren Titel auf anderen Seiten suchen oder die zugehörigen Logbücher betrachten.". (In München will ich außer Tram und Bus noch mehr dabei haben. Bei dem geilen Plan von denen. Der sucht seinesgleichen.) --ChiemseeTraunstein (Diskussion) 14:42, 15. Aug. 2024 (CEST)[Beantworten]

Natürlich gibt es die Vorlage noch nicht. Das ist doch erstmal ein Vorschlag. Steht ja auch so drüber. Und natürlich soll die Vorlage dann mehr als nur Bus und Bahn als Symbol können. Wie man sie dann benutzt? Wie im Beispiel. Wenn hier in ein paar Tagen keiner was da gegen und/oder zusätzliche Ideen/Weinwände hat, baue ich die Vorlage und erweitere das Wikidata-Modul und dann - erst dann passiert auch was, wenn man sie benutzt. -- DerFussi 14:49, 15. Aug. 2024 (CEST)[Beantworten]

Jetzt waren wir gleichzeitig zugange. Woher hast du das "#P5555"? --ChiemseeTraunstein (Diskussion) 14:52, 15. Aug. 2024 (CEST)[Beantworten]

Ich verstehe deine Frage nicht. P5555 ist die Wikidata-Eigenschaft für den Netzplan. -- DerFussi 14:55, 15. Aug. 2024 (CEST)[Beantworten]

Ich verstehe deine Antwort nicht. Was soll ich überhaupt fragen. Wer definiert diese Eigenschaften und welche Eigenschaften sind das. Bitte mal für Ungebildete, ohne Abitur und so. Und wer vergibt die Nummern? Ich kann mir die viermalige fünf nicht aus dem Hut zaubern. Ist das fortlaufend wie diese Zettelchen vor dem Bahnschalter, wenn man in die Schlange will? --ChiemseeTraunstein (Diskussion) 14:51, 16. Aug. 2024 (CEST)[Beantworten]

Wikidata ist eines unserer Schwesterprojekte und dient dazu Daten strukturiert und maschinenlesbar abzuspeichern. Dazu werden Aussagen in der Form ⟨Subjekt⟩ ⟨Prädikat⟩ ⟨Objekt⟩ gespeichert; als Beispiel Cottbus ist Stadt. Für das Prädikat werden Eigenschaften verwendet; diese werden gemeinschaftlich in Wikidata abgestimmt und bekommen bei Annahme eine laufende Nummer mit vorangestelltem P. P5555 steht hierbei für die Eigenschaft „schematische Darstellung“.
Siehe auch Wikivoyage:Wikidata.

Als frischer Beitragender zur Wikivoyage muss man das eigentlich nicht wissen; diese ganzen Technikalitäten werden nämlich in Vorlagen verpackt und versteckt. --Nw520 (Diskussion) 17:00, 17. Aug. 2024 (CEST)[Beantworten]

Sieht super aus! Natürlich wäre noch Kleinkram wie Alttext für die Symbole nett, aber das sollte ja klar sein.
@ChiemseeTraunstein: Aus lizenzrechtlichen Gründen dürfen wir nicht einfach Netzpläne aus dem Internet herunterladen und ohne explizite Erlaubnis des Urhebers bei uns einbinden; Detailfragen kann unser Schwesterprojekt Wikimedia Commons beantworten, von dem wir den überwiegenden Teil unserer Bilder beziehen. Ich befürchte, dass das Einbinden des offiziellen Netzplans für München daher nicht klappen wird; es gibt jedoch diesen von Freiwilligen erstellten Plan. --Nw520 (Diskussion) 22:17, 15. Aug. 2024 (CEST)[Beantworten]

Das sieht gut aus! Bleibt nur zu hoffen, dass es Benutzer gibt, die dann auch auf WD die notwendigen Erfassungen machen und hier in WV auch diese nutzen. Die aktuelle Praxis sieht da leider nicht so rosig aus, meint Eduard47 (Diskussion) 22:48, 15. Aug. 2024 (CEST)[Beantworten]

Genau den Plan meine ich. Der übertrifft den offiziellen bei Weitem. Vermutlich hält der Autor auch das Münchenwiki aktuell und erstellte außerdem den Plan für Frankfurt am Main, den ich da hineingestellt habe. --ChiemseeTraunstein (Diskussion) 05:48, 16. Aug. 2024 (CEST)[Beantworten]

Ich habe mal fix was zusammengezimmert. Siehe {{Netzplan}}. Die Angabe von Wikidata als erster Parameter ist Pflicht. Ich habe erstmal auf mögliche manuelle Angaben von Dateien verzichtet. Ebenso auf benannte Parameter. Schreibt einfach hinten ran, welche Symbole ihr wollt. Groß-und Kleinschreibung ist auch egal. Was ich noch nicht eingebaut habe, ist die Unterstützung der Symbole über Wikidata. Ich habe es mal bei München gemacht, wie ich mir das vorstellen könnte. Ich weiß nicht, ob das im Sinne der Wikidata-Erfinder ist. Ich kann es aber noch ins Modul einbauen. Dann kann man auch auf die manuelle Angabe der Symbole verzichten. Jetzt aber erstmal Frühstück. -- DerFussi 10:45, 18. Aug. 2024 (CEST)[Beantworten]

Zwischenruf! So gut das aussehen mag, wie aktuell bleibt wikidata? Wir hatten ja das Problem bei den Wechselkursen (Die Vorlage Wecselkurs (Bsp. {{Wechselkurs|BETRAG-leer-bei1|EUR|USD|zeige=alle}}) hat ja deshalb nie richtig funktioniert). Die Daten müßten über APISs von den jeweiligen Unternehmen abgegriffen werden, um aktuell zu sein. Da scheint mir aber wiederum für WV wenig sinnvoll. --Qualitätssicherung (Diskussion) 11:33, 20. Aug. 2024 (CEST)[Beantworten]

So aktuell wie die gesamte Wikimedia-Community. Hier handelt es sich ja um selbst gezeichnete Karten, nichts was man mit einer API irgendwo abrufen kann. Daher ist es weniger ein Problem von Wikidata als von den engagierten Leuten, die die Karten auf Commons aktualisieren. Der Vorteil für uns ist, dass wir nicht die Karten auf Commons überwachen müssen, ob es irgendwo eine neue gibt. Wenn die Bahn-/ÖPNV-Community auf den Wikipedias die Netzpläne aktualisiert werden wir automatisch geupdatet. Wir sollten alles automatisieren was geht, um zumindest vom Engagement der restlichen Wikis irgendwie zu partizpieren. Selbst wenn das 5 Jahre alt is, ist es immer noch neuer als mancher Inhalt bei uns.

Bei den Wechselkursen ist es doch so. Sobald sich jemand erbarmt, und den Bot wieder in Betrieb nimmt. Sind auch wir wieder aktuell, ohne etwas tun zu müssen. Gleiches gilt für Klimadaten, Routen usw... nichts davon gehört manuell in unsere Artikel gebastelt. Aktualisiert keiner jemals wieder - keiner von uns handvoll WVer. -- DerFussi 11:49, 20. Aug. 2024 (CEST)[Beantworten]

q.e.d., Danke --Qualitätssicherung (Diskussion) 11:57, 20. Aug. 2024 (CEST)[Beantworten]

Derzeit wird, besonders auf dem dem nordamerikanischen Kontinent viel an Nationalparks gearbeitet. In vielen findet sich eine derzeit noch manuell gebastelte Infobox. Das ist fehleranfällig, aufwändig und für Neulinge auch schlecht lesbar. Ich würde dafür gern eine eigene Vorlage anbieten wollen, die sich darüber hinaus auch bei Wikidata bedient. Manuelle Angaben von Logos, Karten, Größen usw. sind nicht erforderlich. Habe mir zum Basteln mal den Zion National Park vorgenommen. Warum dort auch eine Ortsquickbar drin steht erschließt sich mir nicht, wahrscheinlich eine Altlast.

Ein paar generelle Dinge würde ich vorausschicken.

• Keine explizite Breitenangabe wie in Zion National Park. Persönliche Einstellungen haben auf der Wikiseite im Regelfall nichts zu suchen. Bei meinem Bildschirm ist sie halt zu schmal. Außerdem kann die Seite nur ohne fixe Angaben ordentlich für alle Anwendungen bis hin zu Mobilgeräten konfiguriert werden. Wenn jemand die Quickbar schmaler haben will geht das über die persönliche CSS-Datei (ist leider etwas nerdig) oder wir könnten Helferlein anbieten.
• Die Flächenangabe steht in einer Überschriftszeile. Das entspricht nicht unserem Look and Feel bei Orten und Regionen
• Bei Orten und Regionen nutzen wir Bilder und Positions- bzw. Lagekarten, keine Detailkarten. Die sind im Regel im Artikel positioniert.

Hier mal zwei Schnellschüsse als Diskussionsgrundlage:

Zion-Nationalpark
Fläche	596 km²
Webseite	www.nps.gov
Social Media

Das entspricht der derzeitigen Version in den nordamerikanischen Nationalparks unter Berücksichtigung der obigen Punkte.

Zion-Nationalpark
Fläche	596 km²
Webseite	www.nps.gov
Social Media

Entspricht eher unserer Regionenquickbar.

Beide Beispiel hier drüber beziehen alles aus Wikidata. Nichts ist manuell angegeben. Es sollte ein {{Quickbar Nationalpark}} reichen. Wie üblich sind manuelle Angaben natürlich möglich. Ist das Logo der nationalen Nationalparkverwaltung gewünscht, sollte man länderspezifische Infoboxen ableiten, wenn es viele Nationalparks gibt (z. B. {{Quickbar Nationalpark USA}}). Dann muss man nicht alle Artikel nochmal anfassen, sollte sich das Logo mal ändern. Ich habe auch hier WD genutzt ({{Wikidata|Q308439|P154}}). Dann passt sich das Logo auch bei uns automatisch an. Was machen wir bei Ländern, wo es kein Nationalparkverwaltungs-Logo gibt?

Die Vorlage beherrscht auch schon die Angabe eine Touristeninfo (wie bei den Ortsquikbar) -- DerFussi 17:26, 8. Feb. 2025 (CET)[Beantworten]

Ich finde die untere schöner. DocWoKav (Diskussion) 17:57, 8. Feb. 2025 (CET)[Beantworten]

Schließe mich DocWoKav an. Danke an DerFussi für die Initiative! Nw520 (Diskussion) 20:33, 9. Feb. 2025 (CET)[Beantworten]

Auch ich bin für die untere Variante, Eduard47 (Diskussion) 21:42, 9. Feb. 2025 (CET)[Beantworten]

Zunächst vielen Dank an @DerFussi: für Deine vorbildlichen Aktivitäten. Die bisherigen Diskussionsteilnehmer haben sich offensichtlich von eher optischen Eindrücken leiten lassen. Ich habe die neue „Quickbar Nationalparks“ im Artikel Death-Valley-Nationalpark getestet, ohne sie zu speichern (Vorschau). Der NP gehört länderübergreifend zu Kalifornien UND Nevada. Diese unterschiedliche Lokalisierung misslingt in Wikivoyage bei der „Quickbar Nationalparks“, da das zuliefernde Schwesterprojekt Wikidata mit seinen dort abgelegten Koordinaten eine nicht hinreichende Trennschärfe aufweist, die zu unbefriedigenden Ergebnissen führt. Der NP wurde bei meinen Tests allein als zu Kalifornien gehörig ausgewiesen, was nicht den Tatsachen entspricht. Das liegt daran, dass Wikidata ihn mit Koordinaten verortet, die zu Kalifornien gehören. Die Koordinaten manuell auf die Grenze zwischen Kalifornien und Nevada zu legen, führt nicht weiter, da es trigonometrisch-geografisch kein „Niemandsland“ („Kalifornien UND Nevada“) gibt, sondern nur „Kalifornien ODER Nevada“. Letzteres würde in Wikidata zwei Einträge für dasselbe Objekt erfordern, was unzulässig ist. Insgesamt gibt es in den USA 4 und in Kanada einen NP, die zu zwei Bundesstaaten/Provinzen gehören. Hier versagt die „Quickbar Nationalparks“. Ganz kompliziert wird es beispielsweise in Österreich, das sich je einen NP mit Ungarn und einen mit Tschechien sogar staatsübergreifend teilt. Eine geplante „Quickbar Reiserouten“ wird aus diesen Gründen ebenfalls versagen: Beispielsweise sind beim Trans-Canada Highway in Wikidata - aus gutem Grund - gar keine Koordinaten hinterlegt, so dass eine Verortung in einer Quickbar ohne manuelle Korrektur nicht möglich ist. Ein weiterer Kritikpunkt sind die in Version 2 wegfallenden Logos für USA/Kanada, da die dortigen NP ein Markenzeichen darstellen, das mit dem NP unzertrennlich verbunden ist. Diese Logos müssen allein aus diesem Grund erhalten bleiben. In vielen Staaten außerhalb der USA und Kanadas – wo ich auch NP durchfahren habe – gibt es keine Logos; die NP sind oft dem Innen-, Landwirtschafts-, Forstwirtschafts- oder Umweltministerium unterstellt, wodurch der Staat die Überwachung des Naturschutzes in seinen NP selbst gewährleisten muss. Aus diesen Gründen bevorzuge ich die erste Lösung. Grüße: --Wowo2024 (Diskussion) 11:11, 11. Feb. 2025 (CET)[Beantworten]

Death-Valley-Nationalpark
Fläche	13.650 km²
Webseite	nps.gov
Social Media

@Wowo2024: Da hast du was missverstanden. Wie hast du die "Quickbar Nationalpark" getestet? Die gibt es doch noch gar nicht. Ich habe bisher lediglich ein Modul geschrieben und hier drüber zwei möglichen Anwendungen dargestellt. Du meinst sicherlich die {{Quickbar Ort}} die du in vielen Nationalparks und Reiserouten vorgefunden hast. Und genau aus deinen hier angeführten Gründen finde auch ich, dass die Ortsquickbar für diese Zwecke völlig ungeeignet ist. Daher auch meine Initiative hier eine eigene Quickbarvorlage für Nationalparks zu schaffen. Weder ein Nationalpark noch eine Reiseroute sind Punktobjekte.

Die zweite Variante hier drüber enthält eine Lagekarte (Eigenachaft P242). Und das ist ein Bild. Dass der „Zeichner“ der Karte lediglich einen roten Punkt ins Bild gemalt hat, ist wahrlich dürftig. Hier nebenan beim Death Valley gibt es eine bessere Karte, da ist eine Fläche dargestellt. Das ist nun eine Aufgabe der Wikimedia-Community, hier bessere Lagekarten zur Verfügung zu stellen. Und wie du hier drüber in meinen zwei Beispielen siehst, habe ich auch ganz bewusst die Angabe von Bundesstaat oder Staat weggelassen. ich sehen nur gerade, meine Flächenumrechnung passt nicht. Da muss ich wohl mal ran.

Die Frage nach dem Logo ist eine rein pragmatische - ungeachtet der länderspezifischen Verhältnisse. Wenn wir uns für die Darstellung des Logos entscheiden, was soll dann in die Quickbar an der Stelle rein, wenn es keins gibt? Nichts darstellen? Oder ein Hauptbild?

PS: Bei Reiserouten ist es dann ähnlich. die Eigenschaft Verlaufsübersichtskarte (P15) ist ja nur ein Bild und kann auch Polylinien enthalten, wie bei der Route 66. PS: Reiseroutan kann man auch als Polylinie in unserem Mapframe darstellen, wenn auf WD die OSM-Relation hinterlegt ist. -- DerFussi 20:32, 11. Feb. 2025 (CET)[Beantworten]

PS2: Ich habe den Umrechnungsfaktor gefixt. Jetzt sollte die Fläche passen. Die Quickbar kann nämlich Flächen und Längen automatisch umrechnen, sollten auf WD nur Quadratmeilen angegeben sein. DerFussi 20:50, 11. Feb. 2025 (CET)[Beantworten]

Meine Replik betraf die obigen, von Dir vorgeschlagenen Module, die ich beim Death Valley NP getestet hatte und die dabei auch die verwirrenden Flächenzahlen wiedergaben. Wie ich sehe, ist die Darstellung nunmehr verbessert, da die US-Karte bei genauem Hinschauen zeigt, dass dieser NP teilweise auch im benachbarten Nevada liegt. Allerdings bevorzuge ich nach wie vor die erste Version, weil der Reisewillige weniger an der Webseite des NPs oder dem Auftritt in den sozialen Medien interessiert ist als vielmehr an einer konkreten Orientierungskarte, die potenzielle Detail-Reiseziele im NP anzeigt. „Look and Feel“ dürfen bei der Beurteilung keine Rolle spielen, sondern das Wikivoyage-Corporate Design, das in diesem Fall aber lückenhaft ist und deswegen durch – temporäre – Improvisation ausgefüllt werden muss, bis die Lücke systematisch geschlossen worden ist. Daran fehlt es noch, denn auf mein staatenübergreifendes Gegenargument bist Du nicht eingegangen, weshalb ich hier konkreter werde: Der Nationalpark Thayatal gehört zu Österreich UND Tschechien, was in WD – wie ich vorausgesagt hatte – nicht durch eine einheitliche ID gelöst werden kann. WD hält daher zwei IDs vor, für Österreich (Q612901) und für Tschechien (Q2006345). Diese Problematik lässt sich nur über manuell eingefügte Koordinaten, die optisch genau auf der Staatsgrenze liegen, lösen, denn Q612901 ist in WD koordinatenmäßig in Österreich verortet, Q2006345 (Podyjí National Park) fehlerhaft aber auch. Grüße:--Wowo2024 (Diskussion) 09:35, 17. Feb. 2025 (CET)[Beantworten]

@Wowo2024: Das verstehe ich nicht. Ich konnte nicht darauf eingehen. Die hier vorgeschlagene Quickbar Nationalpark benutzt doch gar keine Koordinaten. Nichts an der Funktionalität benötigt irgendeine Koordinate. Vielleicht könntest du mich erstmal aufschlauen, wozu du eine Koordinate benötigst. Übrigens halte ich, wenn es so ist wie du sagt, die Erfassung auf Wikidata für falsch. Dann fehlt nämlich auf Wikidata ein Datenobjekt für den länderübergreifenden Nationalpark. In ihm gibt es dann über die Eigenschaft "besteht aus" die Verbindung zu den beiden bestehenden nationalen Nationalparkobjekten, (welche dann wiederum über "ist Bestandteil von" rückverlinkt sind). Unser Artikel ist dann mit dem länderübergreifenden Nationalpark verlinkt, nicht mit einem von beiden, wie es derzeit der Fall ist. Also aus meiner Sicht liegen hier zwei Fehler vor – falsche Modellierung auf Wikidata und falsche Zuordnung von Wikivoyage-Artikel mit Wikidata. Beides kann auf Wikidata gefixt werden.

Woran die Reisewilligen wirklich interessiert sind entzieht sich unserer Kenntnis. Wir haben dazu keine Auswertung, ob die Reisenden Homepage und Social Media auch nutzen. Da aber aus fast allen Bereichen des täglichen Lebens Social Media nicht mehr wegzudenken ist, sollten wir es wenigstens auch anbieten und uns nicht von persönlichen Vorlieben leiten lassen.

Die Darstellung des Nationalparks hat sich auch nicht verbessert, weil ich etwas an der Quickbar-Vorlage geändert habe. Ich habe auf Commons nach einer besseren Karte gesucht und diese auf Wikidata hinterlegt. Die Qualität der Quickbar hängt von den Daten auf Wikidata und der Kartenqualität auf Commons ab. -- DerFussi 11:34, 17. Feb. 2025 (CET)[Beantworten]

Etwas zum "Aufschlauen": Dein obiger Vorschlag zur Quickbar NP enthält den Parameter "|ID= Q205325", der auf den Zion NP verknüpft ist. Dieser WD-Eintrag wiederum ist mit Koordinaten verknüpft (wie fast alle geografischen Objekte), die erst eine Verortung in Landkarten usw. ermöglichen. Wenn diese Koordinaten jedoch nicht exakt sind, funktioniert auch - wie Du richtig sagst - die Kartenqualität nicht. Deshalb sind wir hier einer Meinung, dass die Qualität der Quickbar von der Qualität der WD-Daten (eben auch Koordinaten) abhängt. In diesem Kontext ist mein Argument Österreich-Tschechien zu sehen, wobei die "ID= Q2006345" - obwohl ein tschechischer NP - mit einer in Österreich liegenden Koordinate verknüpft ist. Genau das führt dann zu fehlerhaften Anzeigen in darauf aufbauenden Wiki-Vorlagen. Abschließend noch etwas zu sozialen Medien wie "Facebook" und "X": Das sind keine seriösen Quellen (auch nicht in Wikipedia), weil sie auf subjektiven Beobachtungen (bei denen die selektive Wahrnehmung zu Beurteilungsfehlern führen kann) und Meinungen (die sich oft auf eine nicht intersubjektiv nachprüfbare Geschmacksfrage reduzieren) beruhen und deshalb - auch und gerade - bei Reisethemen die erforderliche Objektivität vermissen lassen. Zu viele Gerichtsurteile haben weltweit zu kaum noch zählbaren Löschungsverfügungen bei beiden geführt. Grüße:--Wowo2024 (Diskussion) 12:18, 21. Feb. 2025 (CET)[Beantworten]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Wowo2024: Tut mir leid. Ich verstehe es nicht. Die Koordinate (egal wo sie herkommt) wird doch weder von der Quickbar selbst noch von den angezeigten Karten benutzt. Insofern verstehe ich nicht, wies sich eine richtige oder falsche Koordinate auf diese Nationalparks-Quickbar auswirken soll. An der angezeigten Quickbar ändert sich nichts, wenn jemand die Koordinate auf Wikidata ändert.

Die Links zu den Sozialen Medien in der Quickbar sind KEINE Quellenangaben, diese stehen am Artikelende. Die Quickbars verweisen lediglich auf die die offiziellen Social-Media-Auftritte der Nationalparks selbst - für die natürlich die Nationalparks selbst verantwortlich sind, niemand anders. Darin unterscheiden sie sich nicht von den offiziellen Homepages. -- DerFussi 13:31, 21. Feb. 2025 (CET)[Beantworten]

Zion-Nationalpark
Fläche	596 km²
Webseite	www.nps.gov
Social Media

PS: Der Parameter |ID=Q205325 dient doch nur dazu, um hier beispielhaft die gewünschten Daten des Zion-NP anzuzeigen – das Bild, die Karte und die Fläche. Später im Artikel zum Zion NP ist die natürlich nicht vonnöten. Nochmal. Dass geografische Objekte auf Wikidata im Regelfall eine Koordinate hinterlegt haben ist doch normal, die Quickbar benutzt sie nur nicht. Nebenbei bemerkt, wenn dir die auf Wikidata hinterlegte Lagekarte nicht gefällt, kannst du natürlich im Artikel in der Quickbar eine eigene Karte angeben. Das nebenstehene Ergebnis bekommst du dann mit folgender Syntax: {{Quickbar Nationalpark|Lagekarte=File:Zion national park relief.png}} anstatt mit dem noch einfacheren {{Quickbar Nationalpark}}, was das obige Ergebnis gebracht hätte. -- DerFussi 22:53, 21. Feb. 2025 (CET)[Beantworten]

PS2:Momentan geht in der Umfrage oben die Tendenz zur Variante mit Bild und Lagekarte. Du kannst natürlich wie gezeigt eine eigene Karte als Lagekarte angeben. Unabhängig davon kannst du die Detailkarte auch einfach im Artikeltext angeben, in dem du im Artikel {{Detailkarte}} schreibst. Habe die Vorlage gerade angelegt, da wir sowas in der Art schon für Netzpläne haben. -- DerFussi 23:06, 21. Feb. 2025 (CET)[Beantworten]

Zum Schluss meine eigene Meinung. Auch ich tendiere, obwohl relativ schmerzfrei, zur zweiten Variante mit Bild und Lagekarte. Es entspricht sowohl im Design als auch Inhalt unserer Regionen-Quickbar. Ich habe die Vorlage mal umgesetzt und im Zion National Park exemplarisch eingebaut. Schauen wir mal, ob es weitere Beiträge gibt. -- DerFussi

Hallo @DerFussi: Der Zion NP ist nicht kritisch. Ich bin nach wie vor nicht glücklich über die – auch noch zu prominente – Platzierung der Social Media, die übrigens keinen Informationsmehrwert zum Artikel bringen. Probiere es mal mit dem Death-Valley-Nationalpark aus, der zu Kalifornien UND Nevada gehört.

Beim “Reisethema des Monats” Blue Train und unter anderem im Artikel Yoho National Park taucht der Hinweis `UNIQ--templatestyles-0000003E-QINU` bzw. `UNIQ--templatestyles-000000AB-QINU` noch über der Überschrift auf. In anderen Artikeln, wo das von mir leicht variierte Template der „Ouickbar“ ebenfalls eingebaut ist, dagegen nicht (unter anderem Badlands-Nationalpark, Canyonlands National Park, Carlsbad Caverns-Nationalpark). Der zeitliche Zusammenhang mit den von Dir angelegten „Schnellschüssen“ ist unverkennbar: Die bisherige „Quickbar“ – die mit dem Namen, der Fläche und der Übersichtskarte einen Schnellüberblick verschaffen sollte – wird wahrscheinlich durch Deine neuen Vorlagen beeinflusst. Der technisch laienhafte Leser wird durch diesen Hinweis irritiert. Ich habe einige fertig konzipierte Artikel in der Pipeline: bei der geplanten Erweiterung zum Etosha Nationalpark (auch hier war ich mit Mietwagen selbst unterwegs) habe ich über eine halbe Stunde Deine erste Version in allen möglichen Varianten getestet (ohne zu speichern): das Logo funktioniert einfach nicht (Datei:Logo Namibia Wildlife Resorts.jpg oder ID=Q1964300). Das Thema wird ja auch in  Wikivoyage:Lounge#Sinnlose templatestyle-Ausschriften behandelt. Ich habe von der Löschung der Datei "File:Parks Canada logo" als Erster erfahren, weil ich sie selbst in Commons eingebracht habe und mich deshalb in der Diskussion mit einem Benutzer befinde, der keine Ahnung von Urheberrecht und Logos hat. Da die technische Qualität der betroffenen Artikel durch den Template-Hinweis leidet und die Funktionalität bisheriger Quickbars (auch möglicherweise bei Etosha) ungewiss ist, gibt es sofortigen Handlungsbedarf. Grüße:--Wowo2024 (Diskussion) 17:45, 4. Mär. 2025 (CET)[Beantworten]

Die Ausschriften wie `UNIQ--templatestyles-0000003E-QINU` haben nichts mit Wikivoyage und seinen Programmierern zu tun. Es handelt sich um einen ernsten Fehler des Mediawiki-Programmiererteams. Die Priorität ist hoch, und ich hoffe, dass die Reparatur nicht so lange dauert. --RolandUnger (Diskussion) 18:02, 4. Mär. 2025 (CET)[Beantworten]

@Wowo2024:. So ganz verstehe ich dein Problem nicht. Ich habe es mit dem Death-Valley-Nationalpark probiert und es funktioniert. Habe dir gleich zwei Quickbars reingebaut. Kannst dir eine aussuchen. Die erste wie von der Community hier präferiert, aber du kannst natürlich auch deine Karten und Bilder angeben (Variante 2). Die Social Media Links sind bei uns Standard. Also wirst du damit leben müssen. Damit haben wir auch ein Corporate Design für alles: Orte, Regionen und Nationalparks. -- DerFussi 20:45, 4. Mär. 2025 (CET)[Beantworten]

Auf alle Fälle sollte es das Ziel sein, eine einheitliche Vorlage zu benutzen und keinem Autoren den manuellen Aufbau einer Quickbar zuzumuten. -- DerFussi 20:49, 4. Mär. 2025 (CET)[Beantworten]

Wie Roland schon anmerkte, hat der Ausgabefehler nichts mit "meinen" Vorlagen oder irgendwelchen Schnellschüssen zu tun. Sie dienen lediglich einer einheitlichen, vereinfachten Einbindung und Formatierung der entweder auf Wikidata hinterlegten oder lokal angegebenen Informationen. -- DerFussi 23:59, 4. Mär. 2025 (CET)[Beantworten]

PS: Wenn du in einem Artikel probieren willst, wie im Etoscha-Nationalpark, wird das schwierig. Diese Diskussion hier und die kryptischen Muster dienen lediglich der Diskussion über Funktion und Design. Erst danach wird die endgültige Vorlage implementiert. Hier geht es darum: Wozu dient die besprochene Vorlage, was soll sie tun und wie soll es aussehen? Sie dient nicht dazu, Testimplementationen in echten Artikel zu benutzen. Da ich das Gefühl hatte, dass wir hier aneinander vorbeireden, habe ich mal die Vorlage {{Quickbar Nationalpark}} anhand der bisherigen Meinungen implementiert. Dann benutze bitte diese zum testen. -- DerFussi 00:09, 5. Mär. 2025 (CET)[Beantworten]

Hallo @DerFussi: Leider funktioniert Deine Vorlage im Artikel Death Valley-NP immer noch nicht. Die Flächenangabe lautet auf „13.650.302 km²“ anstatt auf „13.650 km²“, 13,6 Millionen km² wäre größer als Europa. Für Testimplementierungen fehlt mir jegliches Verständnis. Ich bin Führungskraft auf höherer Ebene im Bankwesen und kenne die EDV-Welt bei Unternehmen. Hier gibt es die Anforderung, dass neue Programme/Programmänderungen beim „Go Live“ bereits perfekt sein müssen, um ein Informations- oder Produktrisiko zu vermeiden; diesen Anspruch stelle ich für ein Rollout auch hier. Denn wie man bei der Flächenangabe sieht, wird der Leser momentan mit einer falschen Größenangabe versorgt. Die richtige Angabe im Text führt dann zu vermeidbaren Irritationen. Grüße:--Wowo2024 (Diskussion) 11:35, 5. Mär. 2025 (CET)[Beantworten]

Genau dafür gibt es diese Vorlagenwerkstatt - damit du eben nicht diese Testimplementierungen selbst versuchen sollst. Deshalb habe ich die Vorlage nur zur Veranschaulichung vorimplementiert und mal in einem Artikel eingebunden. Die falsche Flächenumrechnung lag an einem Bug in einem verwendeten Drittmodul. Dieser angegebene Umrechnungsfaktor wurde hier noch nicht aktiv benötigt. HAt also bisher keiner bemerkt. Ich arbeite in der EDV-Welt. Und glaube mir. Nichts ist perfekt. Ich schreibe hier gerade selbst den halben Tag lang Tickets für freigegebene ("perfekte") Software. Darüber hinaus ist das hier ein Community-Projekt mit Freiwilligen wie mir, die hier ihre Freizeit opfern. Hier gibt es auch keine Führungskräfte. Manche Dinge kann man nicht voraussehen, manche Dinge entstehen erst spät, wenn die zugrunde liegende (Wiki)Software geändert wird. Manche Phänomene haben einfach nichts miteinander zu tun, wie diese Ausschriften da oben, nichts mit der Quickbar zu tun haben. Also entspanne dich, wer Fehler findet meldet sie in der Lounge, dann wird sich schon jemand kümmern. PS: Die Flächenangabe stimmt jetzt hoffentlich. -- DerFussi 12:10, 5. Mär. 2025 (CET)[Beantworten]

PS: Softwareentwickler benötigen übrigens gute Zuarbeit. Wenn du behauptest, im Etosha-Nationalpark funktioniert es nicht, dann stelle bitte deinen verwendeten Wiki-Code hier ein. Dann kann man das auch prüfen und analysieren. Ich habe jedenfalls eine Quickbar dort reingesetzt und sie funktioniert. Wenn du auf Commons noch eine Lagekarte findest und diese auf Wikidata hinterlegst, wird sie hier auch automatisch mit angezeigt. -- DerFussi 13:34, 5. Mär. 2025 (CET)[Beantworten]

PS2: Auf das Problem mit Nationalparks in mehreren (Bundes)staaten gehe ich jetzt nicht mehr ein, da es diese Infobox-Vorlage nicht betrifft oder beeinflusst. Das kannst du dann unabhängig davon auf Wikidata richtig modellieren. -- DerFussi 13:55, 5. Mär. 2025 (CET)[Beantworten]

Hallo @DerFussi: Du hast nach meiner Ankündigung, dass ich den Artikel über den Etosha-NP erweitern werde, dort Deine neue „Quickbar Nationalpark“ eingebaut. Diese Quickbar enthält mit dem Foto von Zebras nicht gerade eine den Etosha-NP charakterisierende Individualität; die gestreiften Pferde kommen bekanntlich in allen Nationalparks südlich der Sahara vor. Namibias Nationalparks haben ein einheitliches Logo (wie die NPs in den USA und Kanada), das hier individueller wäre. Doch ist dieses Logo (Datei:Logo Namibia Wildlife Resorts.jpg) für mich momentan der einzige „job-stopper” bei der Erweiterung des Artikels, weil es aus Commons nicht übernommen wird wie das US-Logo. Kannst Du aushelfen? Grüße:--Wowo2024 (Diskussion) 14:22, 1. Apr. 2025 (CEST)[Beantworten]

@Wowo2024: Natürlich kannst du in der Quickbar mit |Bild= und der Angabe eines Bildes ein anderes Bild im Artikel angeben, welches dann angezeigt wird. Siehe auch die Doku zur Vorlage (leider noch unvollendet). Wenn du ein aussagekräftigeres Bild auf Commons findest als die Zebras, kannst du es natürlich auch auf Wikidata als Hauptbild für den Etosha-NP hinterlegen. Dann wird es auch automatisch angezeigt.

Im Regelfall benutzen wir in unseren Artikeln Bilder anstatt Logos. Ich, aber das ist eine persönliche Meinung, finde im Falle von Nationalparks ein Logo noch weniger individuell und aussagekräftig als die Zebras. Auch die "Umfrage" (wenn auch mit wenig Beteiligung) lieferte die Variante mit Bild anstatt einem Logo.

Die von dir angegebene Datei mit dem Logo konnte ich nirgendwo finden. Evtl. hast du dich vertippt. Dein angegebener Link funktioniert jedenfalls nicht. Grüße -- DerFussi 18:07, 1. Apr. 2025 (CEST)[Beantworten]

Es gibt natürlich Ausnahmen. Bei Fluggesellschaften und -häfen haben wir auch Logos, aber zusätzliche zum Bild. Wirklich konsequent Bilderlos sind eigentlich nur die Länderartikel. -- DerFussi 18:24, 1. Apr. 2025 (CEST)[Beantworten]

Hallo @DerFussi: Versuch es mal mit diesem link. Bezüglich der Logos möchte ich meine apodiktische Argumentation nicht wiederholen, es handelt sich um Markenrechte des jeweiligen Staates an seinen Nationalparks mit Namensschutz des Park-Namens. Individueller geht es nicht. P.S. Wie gerade sehe, funktioniert dieser Link auch nicht. Er wird u.a. verwendet unter w:Fort Namutoni#Gästebetrieb. Grüße:--Wowo2024 (Diskussion) 13:34, 2. Apr. 2025 (CEST)[Beantworten]

@Wowo2024: Verstehe ich nicht im Falle eines solchen Logos ist es doch nur individuell für einen Staat. Wenn in allen Nationalparks eines Staates das selbe Logo hinterlegt ist, zeigt es doch nichts individuelles für den, in dem Falle, Etosha Nationalpark. Ich halte nach wie vor ein für den Etosha Nationalpark typisches Bild für aussagekräftiger als ein Logo. Das Wort apodiktisch ignoriere ich einfach mal (siehe 4:1 in der Umfrage oben).

Das von dir angegeben Logo unterliegt Markenrechten und ist deshalb nicht auf Commons verfügbar und kann daher auch nicht hier verwendet werde, wenn die Genehmigung des Rechteinhabers nicht vorliegt. Da solltest du ein OTRS-Ticket aufmachen, wenn dir die Genehmigung vorliegt. Wobei ich mich frage, ob wir in Artikeln von Namibias Nationalparks das Logo einer (wenn offensichtlich auch staatlichen) Hotelkette hinterlegen sollten. -- DerFussi 14:38, 2. Apr. 2025 (CEST)[Beantworten]

Nachtrag: @Wowo2024:. Unabhängig von unseren unterschiedlichen Meinungen für die Grafik am Anfang des Artikels. Ich habe dir die Anleitung genannt, wie du ein abweichendes Bild in der Quickbar angeben kannst (und damit auch ein Logo). Sie dir aber bewusst, dass dies ein Wiki ist. Es kann jederzeit irgend jemand vorbeikommen, und das Logo wieder rausschmeißen. Damit musst du rechnen. Das ist keine Drohung meinerseits. Ich habe besseres zu tun. Du solltest dir nur dessen bewusst sein. -- DerFussi 15:05, 2. Apr. 2025 (CEST)[Beantworten]

Hallo @DerFussi: Danke für Deinen Hinweis, war mir aber klar. Dass Du das Logo nicht rausschmeißt, obwohl Du anderer Meinung bist, ist mir auch klar, denn ich schätze Dich als einen fairen und integren Benutzer ein. Der momentane Artikel über den Etosha-NP krankt mehr an substanziellen Lücken als ausgerechnet an einem fehlenden Logo. Grüße:--Wowo2024 (Diskussion) 15:29, 2. Apr. 2025 (CEST)[Beantworten]

Für Reiserouten (Radwege, Bahnstrecken) gibt es keine einheitliche Infobox. Oft findet man in den Artikel eine Ortsquickbar, die dafür aber völlig ungeeignet ist und durch die implementierte Provinzsuche auch Fehlerkategorien füllt.

Ich habe die die Vorlage analog der hier auch länger diskutierten Vorlage für Nationalparks gleich mal erstellt. Eine testweise Nutzung findet ihr in der Andenbahn. Inspiriert ist sie von den Nationalparks und Fluggesellschaften. Sie beinhaltet:

• Logo, wenn verfügbar (wird dann bei BAhnstrecken usw. mit angezeigt)
• Bild
• Länge, Webseite, Social Media
• Karte. Dabei wird auf die Wikidata-Eigenschaft Verlaufsübersichtskarte zurückgegriffen (P15)

Beim Artikel Nationalparks ist mir aufgefallen, das Marker und vCards in der Nummerierung auf 100 begrenzt sind. Werden also in einem Artikel < 100 Marker oder vCards verwendet, bleibt die automatische Nummerierung bei 100 stehen: Ab 101 wird weiter mit 100 nummeriert usw., was dem Leser die Orientierung in Karten unmöglich macht. Daraus kann gefolgert werden, dass bei Artikeln mit mehr als 100 geografischen Objekten/Sehenswürdigkeiten usw. die Nummerierung weiter mit „100“ erfolgt. Dieser technischen Limitierung bin ich im Artikel über Nationalparks dadurch begegnet, dass ich landesbezogene Ausgliederungen vorgenommen habe (die auch vorher schon bei Nationalparks in Namibia usw. von anderen Benutzern praktiziert wurden). Beispiel ist Nationalparks in den Vereinigten Staaten, die alleine 62 Marker benötigen. Momentan habe ich den Artikel Pazifischer Nordwesten in der Pipeline, wo - allein wegen der Größe der Region - mehr als 100 Marker und vCards erforderlich sind.

Kann jemand - ich habe dabei an @DerFussi: gedacht - in den Vorlagen diese Begrenzung auf 100 aufheben und vielleicht auf 500 erhöhen? Außerdem schlage ich vor, das Satzzeichen "Punkt" am Ende der Vorlagen ersatzlos zu streichen, um diese Vorlagen im Kontext flexibler zu machen. Grüße:--Wowo2024 (Diskussion) 10:09, 4. Apr. 2025 (CEST)[Beantworten]

Da kennt sich @RolandUnger: besser aus. Die 100 ist wohl wikitechnisch bedingt und kann von uns nicht beeinflusst werden, nur von den WMF Programmierern, wenn ich nicht ganz falsch liege. Roland weiß da sicher mehr. Den Punkt kann man mit |show=noperiod unterdrücken, wenn man beispielsweise drch |before= die Vorlage in einem Satz benutzt. -- DerFussi 10:28, 4. Apr. 2025 (CEST)[Beantworten]

Unabhängig davon muss man solche Artikelmonster wie Nationalparks, die am Ende eh nur eine dumme Liste ohne Backgroundinfo darstellen, aus meiner persönlichen Sicht nicht vorhalten. Länderartikel wie Nationalparks in Namibia sind ausreichend und darüber hinaus viel informativer. Einfache Listen kann man auch über Kategorien abbilden - in dem Fall kann man evtl. sogar doppelt kategorisieren, falls jemand eine weltweite Liste und Länderlisten haben will. Oder man verzichtet auf die Kartendarstellung, wenn es doch in den länderspezifischen Nationalparkartikeln eh' eine gibt. -- DerFussi 12:14, 4. Apr. 2025 (CEST)[Beantworten]

Trotzdem hoffen wir auf eine Lösung der 99er-Beschränkung durch die Wikibetreibenden. Die Wikipedianer*innen sind mit ihren Denkmallisten und sowas sicher auch betroffen. -- DerFussi 12:14, 4. Apr. 2025 (CEST)[Beantworten]

Wie Fussi richtig ausgeführt hat, gibt es die technische Begrenzung bei 99 Einträgen. Dies ist ein Uraltproblem, das auch nicht mehr von den Mediawiki-Programmieren abgeändert wird/werden kann, und uns damit auch die Hände gebunden sind. Die Gründe sind banal: der Platz auf dem Pushpin reicht nicht, und der GeoJSON-Standard sieht nur einen einzelnen Buchstaben/Ziffer maximal vor. Mit den Zahlen bis 99 am Standard vorbei wurde schon alles ausgereizt. Die Wikipedias sind hiervon nicht betroffen, weil dort nicht automatisch nummeriert wird.

Man kann sich hier nur mit unterschiedlichen Gruppen/Farben behelfen. Es wird auch noch ein weiteres Limit geben: die maximale Anzahl aufrufbarer Wikidata-Einträge. Bisher haben wir nur Erfahrungen bis etwa 250 Aufrufen, mehr als 400 geht in jedem Fall nicht. Dass diese 400 Aufrufe wohl nicht erreichbar sind, hängt mit der hierfür benötigten Rechenzeit zusammen.

Es erscheint mir hier sinnvoll, die Nationalparkliste auf einen einzelnen Kontinent zu beschränken.

Der Punkt muss bleiben. Wir haben auf etwa 15.000 Seiten die vCard im Einsatz, die man schon deshalb nicht mehr ändern kann. Es gibt zwei Alternativen: (1) Es werden Marker eingesetzt, oder (2) der Punkt wird mit show = noperiod ausgeblendet. Es sei hier auch noch darauf hingewiesen, dass die vCards nie für den Einsatz in Fließtext vorgesehen waren und immer einen gesamten Absatz z. B. in einer Liste bilden sollen. Für alles andere sind die Marker vorgesehen, die (weitgehend) dieselbe Syntax wie die vCards nutzen. --RolandUnger (Diskussion) 15:41, 4. Apr. 2025 (CEST)[Beantworten]

@Wowo2024: Schau doch mals hier. Schon im Januar hatte ich Dir Lösungsmöglichkeiten aufgezeigt, leider blieb mein Tipp unbeachtet und auch unbeantwortet. Eduard47 (Diskussion) 22:22, 4. Apr. 2025 (CEST)[Beantworten]

Hallo @DerFussi: und @RolandUnger: Danke für Eure konstruktiven Repliken. Aus diesen entnehme ich, dass uns bei dem Verfassen von Artikeln beim Einsatz der Marker/vCards unabänderlich die maximale Anzahl von 99 Vorlagen pro Artikel zur Verfügung steht und dass es Möglichkeiten gibt, wie man unter 100 Vorlagen pro Artikel bleiben kann. Die Vorschläge mit dem „Punkt“ sind ebenfalls hilfreich. Anderer Auffassung bin ich beim Artikel „Nationalparks“, den ich keineswegs als „dumme Liste ohne Backgroundinfo“ klassifizieren kann. Nationalparks können ein eigenständiges Reiseziel darstellen und haben bereits deshalb lexikalische Relevanz. Bei dem zwangsläufig hohen Abstraktionsgrad eines solchen Artikels darf der Leser lexikalisch jedoch keine umfangreiche Backgroundinfo erwarten; er ist ein Übersichtsartikel, der durch Blaulinks zu detailreicheren Artikeln über Nationalparks in Staaten oder einzelnen Nationalparks verweist. Diese Funktion als Übersichtsartikel erfüllen auch größere geografische Regionen (Kontinente wie Südamerika, geografische Objekte wie Anden, politische Gliederungen wie Peru, Peru/Südliche Sierra, Cusco (Region)). In „abnehmender Abstraktion“ verweisen diese auf konkretere Reiseziele wie Machu Picchu, wo der Leser entsprechend detailfreudig informiert wird. Hierbei kann sich der Benutzer wissenschaftlich durch die deduktive Methode von abstrakten Gebilden auf konkrete „herunterarbeiten“, wozu sich Wikivoyage hervorragend eignet. Leider muss ich immer wieder feststellen, dass gerade diese Übersichtsartikel zu oft mit „Class-1/2“ inhaltlich vernachlässigt sind, was selbst ich mit meiner hohen Arbeitsmotivation aus zeitlichen Gründen nicht werde optimieren können.

@Eduard47: Deinen Beitrag in Diskussion:Nationalparks habe ich gelesen; er zielte jedoch nicht darauf ab, dass ich hätte antworten sollen. Reagiert habe ich darauf sehr wohl zwei Stunden nach Deinem Beitrag, indem ich den Artikel „Nationalparks in den Vereinigten Staaten“ angelegt und aus dem Artikel „Nationalparks“ ausgegliedert hatte mit dem edit-Kommentar „USA-Nationalparks ausgegliedert in eigenen Artikel, da die vCards nur bis 99 zählen“. Grüße:--Wowo2024 (Diskussion) 10:07, 7. Apr. 2025 (CEST)[Beantworten]

@Wowo2024:. Lexikalische Relevanz von Nationalparks ist unbestritten. Aber wir sind auch nicht die Wikipedia. Wir sind ein Reiseführer. Der Organisation unserer Artikel liegt daher eine reiserelevante Struktur zugrunde. Wenn ich mich informieren will und oder einfach nur im Rahmen einer Reisevorbereitung stöbern will, erschließt sich mir der praktische Zweck einer weltweiten Nationalparkliste nicht. Kontinentweise Übersichten oder gar Länderartikel sollten als Einstieg völlig ausreichen. Zumal der Artikel Nationalparks und ein möglicher Nationalparks in Afrika sowie ein Nationalparks in Namibia innerhalb eines Landes wahrscheinlich identischen Inhalt besitzen, nämlich eine gewisse Anzahl VCards mit etwas Beschreibung und eine Karte. Das bedeutet aber für Autoren einen unnötigen mehrfachen Pflegeaufwand und Redundanz, was man über Einblendefunktionen evtl. noch reduzieren könnte. Oberstes Gebot sollten das Motto „Für die Reisenden“ gefolgt von „Habt Erbarmen mit den Autorinnen und Autoren“ sein. Daher auch meine Einschätzung, dass für einen Artikel Nationalparks Hintergrundinfos reichen, aber nicht jeder Nationalpark jedes Landes aufgelistet werden sollte. Da hätte ich lieber einen Abschnitt zu Afrika, und welche Nationalparks in Afrika die beliebtesten/wichtigsten sind, falls ich eine Mehrländertour plane. Alle Nationalparks Namibias auflisten kann man Nationalparks in Afrika oder besser in Nationalparks in Namibia. Wir sind kein Lexikon, wir müssen die Reisenden durch unsere Inhalte leiten. -- DerFussi 11:38, 7. Apr. 2025 (CEST)[Beantworten]

Das Feriengebiet Insel Rügen umfasst diverse Orte und ergänzende Artikel. Eine Navigationsleiste würde die Übersicht wesentlich vereinfachen.

Ich habe einen Vorschlag erstellt und vorübergehend auf meiner Benutzerseite (ggf. als Kopiervorlage) gespeichert. Wenn diese so okay sein sollte, wäre ich dankbar, wenn jemand sie vervollständigen und die notwendigen weiteren Schritte unternehmen würde. --Eduard47 (Diskussion) 18:56, 2. Mai 2025 (CEST)[Beantworten]