Wikivoyage:Vorlagen/Werkstatt

Wikivoyage:Vorlagen

• Vorlagen-Werkstatt

Hilfreiche Links

• Wikivoyage:Vorlagen
• Übersicht
• Kategorie:Vorlagen
• Neue Vorlagen

Vorlagen-Entwicklung

• Vorlagen expandieren^?

---

{{Region List}}

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)

Diskussion

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

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)

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)

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)

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

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)

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)

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)

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)

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)

Kleiner Hinweis: Die Regionenliste steckt auch in diversen Ortsartikeln! Schönen Abend noch wünscht Eduard47 (Diskussion) 21:15, 23. Nov. 2023 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)

Feiertage responsiv

Ausgangslage

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)

Vorschläge

@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)

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

Termin	Name	Bedeutung
01.01.2024	Neujahr	Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor.
02.02.2024	Karfreitag	Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
03.03.2024	Christi Himmelfahrt	Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut.
04.04.2024	Weihnachten	Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore.

Diskussion

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

  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)

• @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)

Tabellen auf Mobilgeräten

Ausgangslage

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)

Vorschläge

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)

Welterbe

Ausgangslage

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

Vorschläge

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.	50.774756.08392222222221 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 Angabe	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.	49.3172228.44252 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 Angabe	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.	49.792797617479.93888904324533 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 Angabe	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.

Diskussion

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

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

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

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

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

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

Ankünfte und Abfahrten an Haltestellen

Ausgangslage

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)

Vorschläge

Vorlage {{RailQuery}}

Diskussion

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)

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)

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)

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

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)

Liniennetzpläne

(2019)

Ausgangslage

@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.

Vorschläge

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.

Diskussion

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)

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)

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)

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

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

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)

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)

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)

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)

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)

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)

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)

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)

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