Zum Inhalt springen

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

Aus Wikivoyage
Dieser Artikel ist Teil unseres Archivs der Vorlagenwerkstatt.
Archiv vom 31. Dezember 2019

Preisangaben

[Bearbeiten]

{{Preis}}

[Bearbeiten]

Ausgangslage

Bei der Nennung von Geldbeträgen werden unterschiedliche Schreibweisen verwendet.

Vorschläge

Vorschlag einer Vorlage zur Vereinheitlichung, gerade für weniger übliche/bekannte Länder und Währungen. Z. B. bzgl. Indonesien:

{{Preis|id|10000}}   -> ergibt: "10.000 Rp"
{{Preis|id|10000|€}} -> ergibt: "10.000 Rp (0,60 €)"

Diskussion

Eigentlich ist es geregelt. Dort steht es leider nicht aktuell, weil wieder mal niemand nach der letzten Diskussion (ich finde sie gerade nicht) den Regelartikel angepasst hat. In diesem Fall wäre ich aber ausnahmsweise mal gegen eine Vorlage

  1. Den Umrechnungskurs wird/kann niemand laufend halten (wenn wir nicht Bots haben, die freie Quellen abgrasen und ein Modul befüllen - ich habe bereits mal darüber nachgedacht, aber ist auch viel Arbeit).
  2. Wir benötigen Preisangaben auch in der VCard (hauptsächlich). Innerhalb des VCard-Editors sollten keine weiteren Vorlagen benutzt werden. Zum anderen ist der VCard-Editor ein tolles Werkzeug für Leute, die sich mit Wiki-Markup nicht auskennen und im Urlaub eben mal schnell ein Objekt nachtragen/aktualisieren wollen - sich sonst aber mit Wikis nicht auskennen. Ihnen sollte man kein Vorlagen-Markup zumuten.

Wir sollten bei den Preisen in den sauren Apfel beißen, und hinterherräumen. Und so schlimm ist es nicht, wenn es mal falsch formatiert ist. -- DerFussi 16:52, 16. Sep. 2018 (CEST)[Beantworten]

Ich hatte mir schon vor längerer Zeit Gedanken gemacht, ob derartige Vorlagen hilfreich sind. Für Gelegenheitsautoren nicht: sie wissen nicht, was Vorlagen und welche Parameter erforderlich sind. Für ein oder zwei Zeichen der Währungsangabe ist das auch mit zu viel Tipperei verbunden. Der vCard-Editor bietet die im Land gängigen Währungsangaben als Vorgaben hinter dem Preis-Eingabefeld mit an, so dass man sie schnell einfügen kann.
Für Umrechnungskurse haben wir noch kein geeignetes Werkzeug. Ich denke, man muss auch nicht überall den Euro-Wert mit angeben. Einmal im Länderartikel genügt sicher. --RolandUnger (Diskussion) 09:06, 17. Sep. 2018 (CEST)[Beantworten]
Ja, es sollten z. B. nicht zu jedem Unterkunfts-Preis mehrere Währungen eingetragen sein. Aber an ausgewählten Stellen (Eintrittspreis ca. 1,- € oder ca. 10,- €?, Bootsüberfahrt ca. 2,- € oder ca. 10,- ?, …) wäre eine Zusatzinfo hilfreich. Diese muß auch nicht hochpräzise sein.
Der Euro-Umrechnungskurs ließe sich über in Wikidata abgelegte Dollar-Kurse ermitteln, z. B. 
{{Wikidata|id=Q4916|p=P2284}} USD/EUR / {{Wikidata|id=Q41588|p=P2284}} USD/IDR -> 15.000 IDR/EUR.
--theway (Diskussion) 00:02, 26. Okt. 2018 (CEST)[Beantworten]
Trotzdem müssen bei Preisen mindestens die doppelte Anzahl Zeichen getippt werden, wenn man sie in Vorlagen packt. Und gerade der VCard-Editor (dort werden fast alle Preisangaben eingegeben) soll zielgerichtet auch Gelegenheitsautoren ansprechen, die sonst im Wiki nicht viel oder gar nichts machen, die vielleicht auch mobil vor Ort unterwegs sind. Diese wissen nicht mal, dass es Vorlagen gibt, und wenn, wissen sie nicht, welche sie benutzen müssen. Und ich glaube jeder, der ein Land gerade bereist und es bereisen will, informiert sich erstmal über die Kurse (bei uns im Länderartikel oder anderswo) Auch bei Eintrittspreisen sehe ich kein Grund, den Euro-Wert anzugeben. Vorlagen halte ich nur sinnvoll für wichtige und komplizierte Designelemente. Nutzer für banale Informationen damit zu belasten für abschreckend. -- DerFussi 07:43, 26. Okt. 2018 (CEST)[Beantworten]
  • Bei dem Beispiel ganz oben müssten wenige Zeichen (4) zusätzlich, einschließlich Umrechnung einige Zeichen weniger eingetippt werden. Tipparbeit ist hier nicht wirklich ein Kriterium.
  • Egal ob Eintrittspreis oder nicht, es gibt Interessen, Kosten auch in Euro anzugeben. (Beispiele: Ko_Tao, Goldenes_Dreieck, Ko_Pha-ngan)
  • Es gibt keinen Grund, eine Vorlage nicht innerhalb einer anderen Vorlage zu verwenden.
  • Die Vorlage kann - muss aber nicht - genutzt werden.
--theway (Diskussion) 23:35, 1. Nov. 2018 (CET)[Beantworten]
Es gibt natürlich keinen technischen Grund, Vorlagen nicht in Vorlagen zu verwenden - aber einen rein praktischen. Im Gegensatz zur Wikipedia darf sich unsere Autorenschaft nicht auf eine Gruppe von Leuten beschränken, die 1. am Desktop sitzen und nicht mobil arbeiten, 2. zuhause mit einer deutschen Tatsatur arbeiten (die geschweiften Klammern also nicht suchen müssen) und 3. mit Wiki-Syntax vertraut sind. Und diese ganzen, ich nenne sie mal "nicht-wiki-vertrauten" (Gelegenheits-)Autoren, wissen nicht, dass es Vorlagen gibt, geschweige denn, dass sie wissen, welche sie denn benutzen müssten. Und im umgekehrte Fall verwirrt es die Gelegenheitsautoren, wenn in einer vorhanden VCard (de eh' schon kompliziert genug ist) auch noch die Preise kryptisch abgelegt sind. "Die Vorlage kann - muss aber nicht - genutzt werden." ist auch nicht zielführend. Wenn man für einen Zweck eine Vorlage anlegt ist es im Sinne einer wikiweiten einheitlichen Handhabe aber erstrebenswert, sie für ihren Zweck auch konsequent zu benutzen. Eine Vorlage, die dann nur als Spielerei einzelner benutzt wird, ist nicht zielführend - und verwirrt auch wieder die Gelegenheitsautoren - besonders an den so essentiellen Stellen, wie der VCard. Wer einen Euro-Richtwert dazuschreiben will, kann es natürlich tun, das ist aber etwas unfair, unser Wikivoyage wird auch von Schweizern gelesen. Und wenn irgendwer in einem Artikel auch mal etwas geschrieben hat, heißt es noch nicht, dass es den Vorgaben des Projekts/Wünschen der Community entspricht. Ich glaube, bei Währungen haben wir es nicht festgezurrt, bei Maßanagben steht aber "ortsübliche Einheiten". -- DerFussi 08:59, 2. Nov. 2018 (CET)[Beantworten]
Ich selbst bin mit Sicherheit sehr interessiert an technischen Lösungen, ich bin pingelig und programmiere gerne und spiele herum. Wenn das mein Wiki wäre, gäbe es wahrscheinlich auch Währungsvorlagen (die gäbe es mit Sicherheit). Trotzdem bin ich überzeugt, dass es eine Grenze für dieses Wiki gibt und Vorlagen selbst für einfache Zahlenanagaben wie Währungen oder Öffnungzeiten liegen für mich auf der anderen Seite der Grenze. Wenn ich auf Hilfeseiten, Vorlagendokus usw. Vorlagen verschachtle und mit Parserfunktionen, HTML-Entities und Unicode herumhantiere ist das egal, die editiert keiner der meisten Artikelautoren. Im normalen Artikelbetrieb sollten die häufig benutzten Vorlagen ausreichen. Für DIE Vorlage, die VCard, gibt es einen eigenen Editor und weiter Vorlagen sollten darin nicht vorkommen. -- DerFussi 09:35, 2. Nov. 2018 (CET)[Beantworten]
Was man machen könnte, wäre im Länderartikel in der Länderquickbar neben der Währung den Kurs mit anzugeben, wenn verfügbar aktuell über Wikidata bezogen und berechnet. -- DerFussi 09:37, 2. Nov. 2018 (CET)[Beantworten]
Ich denke, wir sollten die Diskussion hier abschließen. Der Bedarf für eine derartige Vorlage ist äußerst gering, die Anwendung für Nichteingeweihte erklärungsbedürftig, der Aufwand für die Aktualisierung der Währungskurse jedoch immens. Wir haben hierfür nicht die Manpower. Ich mache es nicht, und DerFussi wohl auch nicht. --RolandUnger (Diskussion) 10:21, 3. Nov. 2018 (CET)[Beantworten]
Auch wenn das „Ergebnis: abgelehnt“ bereits (innerhalb 1 Minute) hier eingetippt wurde, kann diese Begründung so nicht stehen bleiben. Was äußerst gering ist, wurde garnicht besprochen. 5 Anwendungen, 10 Anwendungen, ist es überhaupt absehbar? Es gibt Literatur-Vorlagen mit deutlich geringerer Nutzung. Und siehe u.a. 1, 2, 3, 4, 5, 6, 7, 8, 9, …. Bei Bekanntheit wird eine Vorlage ggf. noch häufiger genutzt. Die Anwendung wurde garnicht besprochen, was ich in der Werkstatt eigentlich erwartet hatte. Aufwand immens - ist auch garnicht besprochen. Bei ca.-Werten muss es keine Tages-Aktualität geben, und es gibt weitere Ideen hierzu. Ja, und "ich mache es nicht" ist ein ungewohntes Ausschlusskriterium. --theway (Diskussion) 19:54, 3. Nov. 2018 (CET)[Beantworten]
Ließe sich ein solcher Umrechner eventuell als Skript realisieren, der mittels Pattern-Matching alle Geldbeträge (als erste Idee: \b(\.|\d)*(,\d{0,2}) (€|EUR)) aus dem Artikel ausfiltert, wobei die Währungszeichen wie im vCard-Editor abgerufen werden, und beispielsweise ein Tooltip generiert oder den berechneten Wert nach dem Betrag injiziert - ggf. auch erst nach Anklicken einer Schaltfläche oder eines Links? --Naseweis520 (Diskussion) 16:42, 5. Jan. 2019 (CET)[Beantworten]
Mit Sicherheit. Das Skript hätte auch den Charme, dass die Schweizer nicht ausgeschlossen werden, die bekämen ihre Währung angezeigt. Und als Skript belastet es auch nicht den Artikeltext, da die Funktionalität komplett ausgelagert wird. Nicht zuletzt auch bezüglich Performance die bessere Variante. Allein die VCards belasten jetzt schon reichlich die Performance für eine Seite. Wenn jetzt für jede Preisangabe in einem Artikel zwei Wikidata-Abrufe ausgeführt werden, nicht auszudenken. Das Skript braucht sich die Umrechnungsdaten nur einmal holen (wenn man sie nicht sowieso fest einstellt und ab und zu aktualisiert). -- DerFussi 16:07, 20. Jan. 2019 (CET)[Beantworten]
Ich habe mich mal ein bisschen dran versucht. Das größte Problem ist wohl, die umgewandelten Preisangaben an der richtigen Stelle einzufügen. Bei meinem aktuellen Ansatz wird bei einem Klick der Absatz auf Preisangaben überprüft, die Zeichenpositionen dieser gemerkt und die Zeichenposition des Klicks mit den gemerkten verglichen. So wird erkannt ob und welche Preisangabe angeklickt wurde. Da die Preisangaben aber frei im Fließtext stehen können (außer bei vCards), habe ich bisher keine Möglichkeit gefunden diese hinter den Preisangaben einzufügen, ohne andere Skripte eventuell kaputtzumachen (beispielsweise, wenn es Links im Absatz gibt). --Naseweis520 (Diskussion) 20:05, 20. Jan. 2019 (CET)[Beantworten]
Klingt spannend. Wenn du die Preistexte erfasst, kann man sie dann mit einem span-tag wrappen? Sind sie dann im DOM sichtbar und erfassbar? Dann hätte man besseren Zugriff. Die Frage ist auch, welche Funktionalität gewollt ist. Dass hinter allen Preisen automatisch eine Euro-Angabe steht? Ich muss aber jetzt schlafen gehen. Morgen ist ein langer Tag mit ganz ähnlich gearteten Probleme - nur halt auf Arbeit. :) -- DerFussi 20:54, 20. Jan. 2019 (CET)[Beantworten]
Ich muss noch die Frage klären, wie ich Inhalt frei in einem Fließtext injizieren kann. Anders formuliert möchte ich bei <p>Lorem ipsum dolor 2,00 € sit <a href="#">amet</a>, consectetuer...</p> den Text in p manipulieren können. Stumpfes Ersetzen fällt weg, da dadurch auch der a-Tag "neueingefügt" wird und bestehende EventHandler für diesen verloren gehen, wie sie bspw. die Navigations-Popups setzen. Daher kann ich auch nicht ohne weiteres ein span um Preisangaben packen. Bei vCards ist das kein Problem sein, da es die Klasse .listing-price gibt und ich recht stark davon ausgehe, dass dort wirklich nur Text drin steht.
Was die Funktionalität angeht, ließe sich das m.E. am besten mit CSS lösen. Man könnte die Umrechnung hinten dran packen und mit einer Klasse ein- und ausblenden oder sie als zusätzliches Attribut in den span setzen um bspw. beim Überfahren ein Tootip o.ä. anzuzeigen. Aber momentan strebe ich vorerst nur an das irgendwie - wenn auch vorerst schmutzig - zum Laufen zu kriegen. Stellte sich wegen dem Injizieren-Problem schon als kniffliger als erwartet heraus :D  --Naseweis520 (Diskussion) 23:23, 20. Jan. 2019 (CET)[Beantworten]
Einfach den Text selbst manipulieren und pauschal den Preis dahinter schreiben (ohne Link und alles)? Wäre das was? Da ändert sich laufend die Textlänge, aber da kann man ja mitrechnen. Zwei Punkte gibt es da. Dann wenn andere Skripte wie möglicherweise der Listing-Editor auch mit dem Text hantieren (ihn beim Aufruf beispielsweise einlesen). Diese müssten zwei Dinge beachten. Das sollten sie vielleicht prinzipiell auch ander User könnten eigene Skripte implementieren. Das ist ja unabhängig von deinem. 1. Der Originaltext müsste zusätzlich gespeichert werden. Das geht mit einem data-Attribut. Dieser wird dann beim Aufruf genutzt. und 2. Sie müssten ein Event auslösen, wenn der Textinhalt eines Tags geändert wurden. Die VCard z. B. ein "vcardSaved" oder so. Dann kann dein Skript wieder drauf anspringen und den Preis ergänzen. Ansonsten hilft nur, die Seite neu laden zu lassen (das ist aber blöd). -- DerFussi 06:26, 21. Jan. 2019 (CET)[Beantworten]
Der Ansatz über die Textlänge ist nur ein Versuch nicht den Inhalt manipulieren zu müssen. Könnte ich das, könnnen mir die Textlängen so ziemlich egal sein. Problem ist aber, dass ich keine Möglichkeit kenne, wie man hinter einem Wort innerhalb eines Tags (also hier der Preisangabe) etwas einfügen kann. Nach meinem Wissensstand ist die einzige Möglichkeit, den gesamten Inhalt des beinhaltenden Elements als String zu lesen, diesen zu bearbeiten und dann den Inhalt wieder zu diesem (bearbeiteten) String zu setzen. Wie schon gesagt, zerstört das EventHandler innerhalb des beinhaltenden Elements; so zum Beispiel bei Links, sodass die Navigations-Popups nicht mehr aufploppen. Bei vCards sollte das kein Problem sein, da die Preisangaben typischerweise reiner Text sind (ich habe das Script aktuell auf diesen Anwendungsfall eingeschränkt). 1. Ließe sich schnell einrichten. Beim Testen mit dem vCard-Editor waren die Felder im Editor, trotz Anwenden meines Skripts und somit auch Manipulation der Werte, davon unbeeinflusst. Ich weiß noch nicht ganz, ob das nur daran liegt, dass der vCard-Editor vor meinem Script ausgeführt wurde. Das müsste ich noch überprüfen. --Naseweis520 (Diskussion) 19:57, 21. Jan. 2019 (CET)[Beantworten]
Kann man recht gut im Artikel zu Hanoi testen. F12-Konsole öffnen und importScript("Benutzer:Naseweis520/currencyConverter.js"); eingeben. --Naseweis520 (Diskussion) 21:12, 21. Jan. 2019 (CET)[Beantworten]
Ich versuche, die Woche mal ne halbe Stunde Zeit zu finden. Bei mir ist gerade Land unter. Schaffe nur in der Frühstückspause paar Edits. Ich gucke mal... -- DerFussi 22:08, 21. Jan. 2019 (CET)[Beantworten]
Habe nur mal schnell geguckt. Hat ja teilweise schon funktioniert. Super. Knackig sind ja die Von-Bis-Preise sowie die mit dem "/". Das kann fummelig werden. Da könnten wir aber auch Vorgaben machen, wie das künftig zu erfassen ist. Das mit dem "/" geht wahrscheinlich noch, wenn man bei beiden Angaben ein Währungsssymbol nutzt. Man kann sich ja langsam rantasten -- DerFussi 08:07, 22. Jan. 2019 (CET)[Beantworten]

Neue Vorlage für Symbole

[Bearbeiten]

Ausgangslage

[Bearbeiten]

Auf einigen Seiten werden kleine Bilder als Symbole verwendet. Dabei werden teilweise unterschiedliche Größen und Ausrichtungen verwendet oder Angaben vergessen. Mit Blick auf die vor kurzem zu einigen Vorlagen hinzugefügte CSS-Klasse "noviewer" sehe ich das Problem, dass solche Änderungen mangels Zentralisierung nur schwer überall durchzusetzen sind.

Vorschläge

[Bearbeiten]

Ich würde eine neue Vorlage auf Basis von {{Flagicon}} für Symbole vorschlagen, die die typischen Parameter für Symbole als Standard vorgibt, aber Änderungen dieser erlaubt. Mein Vorschlag, wie das aussehen könnte ist hier. Parameter, die ich als wichtig erachte sind: Bild-Pfad, Größe, Beschreibung, Rahmen, CSS-Klassen, Link, Vertikale Ausrichtung

Sollte diese Vorlage zustande kommen, könnte man auch Vorlagen, wie {{Rolli}} oder die Kategorie Symbole für Fließtext auf diese zurückgeführt werden. --Naseweis520 (Diskussion) 20:45, 12. Jan. 2019 (CET)[Beantworten]

Diskussion

[Bearbeiten]

Pro Macht durchaus Sinn. -- DerFussi 23:25, 12. Jan. 2019 (CET)[Beantworten]

Ausgangslage

[Bearbeiten]

Die Vorlage zeigt Straßensymbole mit Nummern an. Besonders bei Häufung im Text empfinde ich die Symbole im Fließtext als störend und optisch ausgesprochen unschön - kurzum diese Absätze sehen schrecklich aus. Ein andere Nutzer nannte es in Diskussionen "Klicki-Bunti". Seine Art der Kommunikation war etwas unglücklich, was er aber als störend empfand, sprach mir aus dem Herzen. Das ist sicher eine rein persönlich Einschätzung. Wenn ich damit relativ allein stehe, können wir das sofort wieder schließen. Das lohnt den ganzen Aufwand nicht. Wenn es anderen auch so geht, könnte man über eine Lösung nachdenken. -- DerFussi 15:17, 19. Jan. 2019 (CET)[Beantworten]

Beispiele: A14), A13, Bonn, Bodensee

Vorschläge

[Bearbeiten]

Eine Lösung könnte sein, die Symbole in ein spezifisches Tag zu packen, das immer sichtbar ist. Dies ist derzeit auch der Fall. Zusätzlich wird die Straßennumer (ggf. mit Link) in einem unsichtbaren Tag im Klartext ausgegeben (A7, B169 usw.). Wer möchte könnte sich dann über ein Helferlein einstellen, ob er gerne lieber die Textvariante anstatt der Bilder sehen möchte. Wird ein Symbol auch mal als Listenpunkt oder in Tabellen genutzt, würde das auch umgestellt werden, obwohl es in den Sonderfällen vielleicht ausnahmsweise angebracht wäre. Das könnte man vielleicht mit geeschicken Styles noch abfangen. Oder amn erzwingt die Darstellung per Parameter in der Vorlage, das sollte dann aber mit Bedacht eingesetzt werden. -- DerFussi 15:18, 19. Jan. 2019 (CET)[Beantworten]

Diskussion

[Bearbeiten]
  • Ich würde zustimmen, dass zu viel Einsatz von RSIGN störend ist. Persönlich bin ich aber der Meinung, dass mindestens für Autobahnen die erste Nennung im Abschnitt als RSIGN sinnvoll ist, da so zusätzlich erkennbar ist, wie in welchem Land Autobahnen ausgeschildert sind und welches Land welche Nummerierung hat. --Naseweis520 (Diskussion) 19:48, 19. Jan. 2019 (CET)[Beantworten]
  • Ja, ein angenehmer Lesefluss wird gestört: Farbwechsel im Zeichensatz und Farbwechsel im Hintergrund. Vielleicht lassen sich ähnlich den Abfahrten – Symbol: AS 23 Avignon Nord – einfache vorangestellte und weniger aufdringliche Symbole finden. --theway (Diskussion) 00:21, 20. Jan. 2019 (CET)[Beantworten]
  • Straßensysteme, Netz und ihre Beschilderung kann in den Länderrtikeln ausführlich beschrieben werden. Am Anfang eines Stichpunktes wie z. B. im Spremberger Stausee finde ich Symbole schon ok. Im Text selber dagegen nicht. Bei uns kommt noch dazu, dass die Symbole größer als die Schrift sind. Mr würde da eine minimal andere Formatierung (fett? hmm... Andere Schriftart, etwas andere dunkle Farbe fast reichen). Stimmt, die Ausfahrt ist relativ unaufdringlich. -- DerFussi 08:04, 20. Jan. 2019 (CET)[Beantworten]
  • Ich bin kein Fan der RSIGN-Vorlage (könnte sein, dass das "Klickibunti"-Zitat oben von mir stammt; tut mir leid, wenn ich damit jemandem auf den Schlips getreten bin – ich habe es eigentlich nur scherzhaft und nicht abwertend gemeint). Ich persönlich setze die Vorlage nie ein und freue mich auch nicht besonders, wenn sie nachträglich in von mir erstellten Texten eingefügt wird. Da es in erster Linie eine Geschmacksfrage ist und keine inhaltliche Frage, wäre die Möglichkeit einer benutzerdefininierten Einstellung, ob das bunte Bildchen (nicht böse gemeint!) eingeblendet wird oder nur Text, sicher eine Lösung. Aber: Was ist mit den passiven Nutzern? Wer sagt uns, ob nicht angemeldete Benutzer die Ansicht mit Bildchen bevorzugen oder den reinen Text? Wegen des bereits angesprochenen Problems mit dem Zeilenabstand sollte die RSIGN-Vorlage jedenfalls nicht im Fließtext eingesetzt werden, sondern allenfalls in stichpunktartigen Aufzählungen. Die Frage, welche Straßentypen es gibt und in welcher Farbe sie ausgeschildert sind (z. B. in Deutschland Autobahnen blau, Bundesstraßen gelb), gehört m. E. wirklich in die Länderartikel und muss dann nicht in jedem einzelnen Ortsartikel thematisiert werden. --Bujo (Diskussion) 22:26, 25. Jan. 2019 (CET)[Beantworten]
@Bujo:. Nein. Das warst nicht du. Alles gut. Wenn kein anderes Feedback kommt, könnte man wirklich über eine Vorgabe nachdenken, die Vorlage nicht im Fließtext, sondern nur als Stichpunkt und in Übersichtdtabellen oder ähnlichem benutzen. -- DerFussi 08:37, 26. Jan. 2019 (CET)[Beantworten]
Ich habe mal einen Hinweis in den Artikelvorgaben ergänzt: [1]. In einem künftigen Hilfeartikel Hilfe:Symbole kann ich noch mal drauf eingehen. Wenn das auf Zustimmung stößt, könnte man das Thema archivieren. -- DerFussi 12:31, 22. Mär. 2019 (CET)[Beantworten]
  • sorry, ich habe die bunten Symbole gern: zumindest in den Abschnitten zur Anfahrt und Wegbeschreibungen finde ich sie praktisch, da man sofort die Farbe der Autobahnbezeichnung und Wegweisung erkennt - natürlich brauche ich sie in meinem Heimatland auch nicht, wenn man in Italien aber mehr als einmal ein kleines grünes Täfelchen mit einer A19 - CT übersehen hat und die Zufahrt zur Autobahn übersieht und stattdessen eine gemütliche einstündige Stadtrundfahrt machen darf, um aus der Stadt herauszukommen, ist man vielleicht eines Bessern belehrt. Strassen- / Autobahnbezeichnungen etc. sind für mich neutrale Symbole, und nicht firmen-eigen, wie Symbole von Kreditkartengesellschaften oder Webportalen, da ärgere ich mich viel mehr über jedes Facebook-Logo, +1 oder ähnliches, welches hie und da auftaucht und meinen Lesefluss auf einer Website echt stört und als Werbung nichts als nervt. Only my five cents martin - Mboesch (Diskussion) 17:19, 28. Mai 2019 (CEST)[Beantworten]

Erweiterung der Vorlage {{Ausfahrt}}, {{A-Kreuz}}

[Bearbeiten]

Ausgangslage

Ausfahrtsnummern werden als Teil des ersten Parameters (dem Namen) vorangestellt. In Artikeln wird öfters der eigentliche Ausfahrtsname nicht in die Vorlage mit eingeschlossen, oder Nummer und Name im ersten Parameter mit unterschiedlichen Trennzeichen getrennt.

Vorschläge

Ich würde gerne vorschlagen, dass Ausfahrtsnummern in einem neuen Parameter separat eingetragen werden. Dies soll verdeutlichen, dass sowohl Name als auch Nummer Teil der Vorlage sind und erzwingt eine einheitliche Darstellung. Ferner ließe sich durch die nun vorhandene Trennung die Nummer separat formatieren. Um kompatibel zur bisherigen Vorlage zu sein, sollte m.E. die Nummer der zweite Parameter werden, sodass sich {{Ausfahrt|Beispieldorf|1}} ergibt. Analog dazu wäre die Erweiterung der Vorlage {{A-Kreuz}}.

(Ich hatte etwas voreilig die Änderung bei Ausfahrt bereits durchgeführt. Sollte der Vorschlag abgelehnt werden, kann ich meine Änderungen revertieren.) --Naseweis520 (Diskussion) 19:37, 19. Jan. 2019 (CET)[Beantworten]

Diskussion

  • @Naseweis520: Klingt vernünftig. Sorry, ich habe es einfach vergessen. Ich sehe da keine Bedenken. Wenn man die Vorlage sowieso benutzt, kann man auch beides sauber reinpacken. Anwender, die Symbole und Nummern nicht wollen, können per CSS ihre Wunschformatierung vornehmen. Auch ein Gadget wäre dann möglich. -- DerFussi 17:18, 25. Jan. 2019 (CET)[Beantworten]


Nochmal: Währungskurse automatisch

[Bearbeiten]

Die Diskussion zur Übernahme der WP-Vorlage Infobox Währungsvorlage scheint mit der Archivierung eingeschlafen zu sein. Ich hielte sie gerade hinsichtlich der Aktualität für sehr sinnvoll. Schnittstellen und was weiß ich was es da noch braucht sollten sich ja aus der WP übernehmen lassen. --Zenwort (Diskussion) 23:09, 25. Mär. 2019 (CET)[Beantworten]

Schnittstellen gibt es eben keine. Wie man sieht scheinen die mir händisch geplegt zu werden. Dafür habe wir keine Manpower. Eine Notlösung wäre es, wenn sich regelmäßig jemand mit Importrechten erbarmt, und die Basisvorlage mit den Kursen erneut rüberholt. Wikidata hat wohl auch Kurse. Da könnte man vielleicht ein Modul programmieren. Ich wollte mal einen Bot schreiben, der paar Internetseiten abgrast und so eine Vorlage befüllt - aber leider fehlt mir da die Zeit (und mittlerweile auch die Lust). Die aktuellen Kurse im Länderartikel und einigen weiteren geeigneten Stellen anzugeben ist sicher sinnvoll. An jeder Preisangabe würde ich es nicht verwenden (siehe Diskussion wieter oben). -- DerFussi 07:06, 26. Mär. 2019 (CET)[Beantworten]

Hebräisch

[Bearbeiten]

Ist jemand so nett und bastelt mir jemand eine Sprachvorlage „Hebräisch” nach dem üblichen Muster {{HeS|w=}} (am besten gleich noch mit Redirect für den alten ISO-Code „il“). Als nicht-lateinische Schrift ist die Markierung für auch für screenreader wichtig. Schon Mal Danke --Zenwort (Diskussion) 12:24, 30. Jun. 2019 (CEST)[Beantworten]

@RolandUnger: Danke. Das war super schnell. --Zenwort (Diskussion) 13:53, 30. Jun. 2019 (CEST)[Beantworten]
Ich bin mir nicht so sicher, ob es früher auch den ISO-Code „il“ gegeben hat. Die deutsche und die englische Wikipedia erwähnen leider nichts dazu. Als Ländercode gibt es ihn natürlich. Beim Beispiel musste ich mich etwas zurückhalten, weil ich fast keine Hebräisch-Kenntnisse habe. --RolandUnger (Diskussion) 14:07, 30. Jun. 2019 (CEST)[Beantworten]

Textbausteine als Ersatz der Tabellen in „Feiertage“ von Länderartikeln

[Bearbeiten]

Wie in der Diskussion zur Darstellung auf Mobilgeräten Wikivoyage:Lounge#Anregungen zu Artikelvorgaben richtig angemerkt worden ist, sind Tabellen ohne Scrollen auf Mobilgeräten schlech darstellbar, in den meisten Webseiten sind sie auch ersetzt worden durch Nutzung von grid oder flexbox, etwas,dass die Wiki-Software z.Zt. noch nicht hergibt.

Eine häufig vorkommende Tabelle ist in der Vorlage:Land die im Abschnitt „Feiertage“ bisher:

 == Feiertage ==
 {{Feiertage Anfang}}
 {{Feiertag|<Termin>|<Feiertag>|<Bemerkung>}}
 {{Feiertage Ende}}

Das betrifft gut 200 existierende Seiten (Nationen und Bundesstaaten). Ich habe daher versucht, aus bestehenden Vorlagen für flexible Feste mehrere Textbausteine entsprechend unterschiedlichen Hintergründen zu kombinieren, um besagte Tabelle schneller ersetzen zu können.

Das ist ein erster Entwurf und ich bitte darum, wer kann, dies in den nächsten 14 Tagen in ein kohärenteres Ganzes umzubauen und entsprechende Vorlagenverknüpfungen aufzulösen. Ob es sinnvoll ist die entsprechenden DATUM-Variablen durch zu erstellende Vorlagen zu ersetzen muß ich anderen überlassen. In jedem Fall bräuchten wir CHINESISCH-NEUJAHR, ORTHODOXES-WEIHNACHTEN und ORTHODOXES-OSTERN.

Bausteine

[Bearbeiten]
Staatliche Feiertage (europäische Tradition)

Hier aus den existierenden Tabellen zu ergänzen sein dürften in der Regel ein Nationalfeiertag und ein Unabhängigkeitstag. (Codeschnipsel der Übersichtlichkeit ohne <br />, aber LF im Quelltext, die Darstellung erfolgt als ein Absatz.)

In XYZ werden folgende staatlichen Feiertage begangen: 1. Jan. Neujahr; 8. März, internationaler Frauentag; 1. Mai, Tag der Arbeit; 8. Mai, Ende des zweiten Weltkriegs 11. Nov., Ende des ersten Weltkriegs

Staatliche Feiertage (britische Tradition)

In XYZ werden folgende staatlichen Feiertage begangen: 1. Jan., Neujahr; DATUM, Bank Holiday; DATUM, Queen's Birthday, zweiter Samstag im Juni; DATUM, Bank Holiday, erster Montag im August; DATUM, Labour Day (Tag der Arbeit).

Religiöse Feiertage (muslimisch)

Basierend auf dem muslimischen Mondkalender begeht man das Neujahrsfest 08. Juli 2024 am 1. Muharram; Ashura am 10. Muharram (17. Juli 2024); Mohammeds Geburtstag am 15. September 2024, den ersten Tag im Fastenmonat Ramadan dieses Jahr am 10. März 2024 sowie dessen Ende mit dem mehrtägigen ab 10. April 2024; das mehrtägige Opferfest beginnt am 16. Juni 2024, dem 10. Dhū al-Ḥiddscha.

Religiöse Feiertage (katholisch)

An religiösen Feiertagen begeht man die Osterzeit zwischen Karfreitag (29. März 2024) und Ostermontag (1. April 2024); 9. Mai 2024 Christi Himmelfahrt, 30. Mai 2024 Fronleichnam, Pfingsten inklusive dem folgenden Montag (20. Mai 2024); 15. Aug., Mariä Himmelfahrt; 1. Nov., Allerheiligen sowie Weihnachten.

Religiöse Feiertage (evangelisch)

An religiösen Feiertagen begeht man die Osterzeit zwischen Karfreitag (29. März 2024) und Ostermontag (1. April 2024); Pfingsten 19. Mai 2024 und Weihnachten.

--Zenwort (Diskussion) 18:15, 3. Aug. 2018 (CEST)[Beantworten]

Ein Anfang ist hier: Wikivoyage:Vorlagen/Feiertage. Dort gibt es auch Chinesisch Neujahr und Diwali und Vesakh. Mir ist aber noch nicht ganz klar, wie du es dir optisch und funktional vorstellst. Magst du mal was formloses auf eine Benutzerunterseite von dir bauen? Ich habe neulich auch schon drüber nachgedacht. Auf Smartphones könnte man die breite Beschreibung unterdrücken und nur ein Button einbauen, der die Beschreibung aufpoppen lässt (so wie bei der VCard-Info-Funktion). Wäre das eine Idee?-- DerFussi 20:57, 3. Aug. 2018 (CEST)[Beantworten]
@DerFussi: Ganz normaler Fließtext. So wie ich das (vor dem Entwurf der Bausteine gestern) vor ein paar Wochen bei Gambia#Feiertage umgesetzt habe. --Zenwort (Diskussion) 10:13, 4. Aug. 2018 (CEST)[Beantworten]
Bin drei Tage unterwegs.Ab Diensrag wieder im Dienst, dann schaue ich Mal -- DerFussi 13:02, 4. Aug. 2018 (CEST)[Beantworten]
Wenn es nur um die Tagesangabe im Fließtext geht, kann man doch die vorhandenen Feiertagsvorlagen nutzen, wie gesagt auch chinesisch Neujahr hatte ich damals angelegt. Ich würde es aber schon optisch etwas ansprechender machen wollen, so sieht es schon recht unübersichtlich aus. Tag und Bezeichnung sollten auch auf einem Mobiltelefon nebeneinander passen und ordentlich aussehen. Nur die Beschreibung sprengt es. Das kann man aber lösen. Mich ärgern die Feiertage schon lange, bisher fehlte die Zeit mir was einfallen zu lassen. Ich werde mal jetzt während der Heimfahrt etwas drüber grübeln und melde mich dann noch mal. -- DerFussi 09:35, 6. Aug. 2018 (CEST)[Beantworten]
Was ich völlig verwirrend finde, ist der Umstand, dass bei Gambia die Feiertagae nicht chronologisch geordnet sind. Auch wenn es bewegliche Feiertage gibt, dürfte sich die Reihenfolge nur selten ändern. Den religiösen Hintergrund und die Zuordnung könnte man auch mit einem Symbol und ein Tooltip kenntlich machen. -- DerFussi 09:40, 6. Aug. 2018 (CEST)[Beantworten]
Reine Textbausteine haben wir ja eh schon, ich würde eine Tabellen- oder Listenform schon beibehalten wollen. Vorschlag: Da eine Quickbar auch nur eine Tabelle ist und auch auf das Mobiltelefon passt, könnte man theoretisch auch die ungeliebte Tabelle behalten. Das Problem ist nämlich, dass die Informationen zeilenweise kommen, und nicht spaltenweise. Auf dem Mobiltelefon wird die Beschreibung automatisch unterdrückt. Für Datum und Name sollte das Smartphone ausreichend Platz bieten. Statt Beschreibung könnte ein Infobutton eingeblendet werden, der die Beschreibung öffnet. Die chronologische Reihenfolge über das Jahr hinweg würde ich beibehalten. Bei Religiösen Feiertagen wäre die Frage, ob, und wie man sie kennzeichnet. Die Beschreibung gibt es ja sowieso. Um Platz zu sparen, könnte man Symbole angeben, wobei mir z. B. für Hinduismus spontan keins einfällt. Einen kleinen Shiva vielleicht, obwohl wir auch an den Platz denken müssen. Darüber hinaus sollte bei beweglichen Feiertagen immer auf Vorlagen zurückgegriffen werden. -- DerFussi 07:46, 7. Aug. 2018 (CEST)[Beantworten]
Die Begeisterung für Feiertage scheint sich ja in Grenzen zu halten. Aber mich ärgern sie auch schon länger. Ich sehe zu, dass ich am Wochenende mal etwas Zeit finde. -- DerFussi 10:20, 14. Aug. 2018 (CEST)[Beantworten]
Jetzt wird es langsam Zeit. Ein Testszenario habe ich mal auf Wikivoyage:Vorlagen/Werkstatt/Feiertage (Entwurf 2018) angelegt. An der Funktionalität werde ich jetzt basteln. -- DerFussi 09:42, 1. Okt. 2018 (CEST)[Beantworten]
@Alle und @Zenwort:. Habe den Entwurf getestet. Auf dem Smartphone wird die Beschreibung unterdrückt und stattdessen ein Info-Button angezeigt. Dort passt es jetzt. Das zugehörige PopUp-Fenster wird noch gebaut. Habe mich gestern mit Roland verständigt, da ich nicht sein komplettes Listing-Pupup-kopieren will. Es wird da noch eine Modalisierung geben. Daher bitte ich um etwas Geduld. Bis das Feiertags-Beschreibungs-Popup kommt. Leider gibt es aber auch keinen weiteren Input, ob Tabelle oder Fließtext. Ich favoritisiere aufgrund der Übersichtlichkeit eindeutig die Tabelle. Die oben angesprochenen Vorlagen existieren bereits alle: {{Chinesisches Neujahrsfest}} und {{Chinesische Kalenderzyklen}} sowie {{Ostern (orthodox)}}. Orthodoxes Weihnachten ist doch immer der 7. Januar, oder? Weitere fehlende Vorlagen für bewegliche Feiertage hier bitte noch mal separat beantragen. Bei Exoten vielleicht auch eine Quelle nennen, wo man die Datumsangaben für die nächsten Jahre findet. -- DerFussi 07:57, 9. Okt. 2018 (CEST)[Beantworten]
Nachdem ich nun einige Arbeit in Feiertage in Europa investiert habe und so einige neue Tabellen geschaffen habe, bekomme ich hier den Eindruck, dass meine Arbeit für die Katz war. Was tun? Abbrechen oder zu Ende bringen? --4omni (Diskussion) 22:25, 10. Feb. 2019 (CET)[Beantworten]
@4omni: Weitermachen, aber diese Vorlagen benutzen: Vorlage:Feiertag. Die gibt es schon seit 4 Jahren. Ist wahrscheinlich etwas untergegangen. Sieht genauso aus wie die manuelle Variante aber dann bekommen wir das auch weiterentwickelt und müssen die Artikel nicht noch mal anfassen. -- DerFussi 19:58, 11. Feb. 2019 (CET)[Beantworten]

──────────────────────────────────────────────────────────────────────────────────────────────────── Liegt schon lange. Darf ich kurz rekaputulieren?

  • Inhaltlich gibt es keinen Handlungsbedarf. Wikivoyage:Vorlagen/Feiertage hat Auswahl und neue Feiertage können bei Bedarf nachgeliefrt werden.
  • Die vorhandenen Feiertagsvorlagen sollten genutzt werden, auch um auf zukünftige Entwicklungen reagieren zu können.

Wären eine ausgeblendete Beschreibungsspalte und ein Popup in der Mobilversion ok? -- DerFussi 19:31, 23. Jul. 2019 (CEST)[Beantworten] ──────────────────────────────────────────────────────────────────────────────────────────────────── Vor zweieinhalb Jahren eingeschlafen. Ichwürde das demnächst archivieren. -- DerFussi 11:54, 7. Feb. 2022 (CET)[Beantworten]

Klimavorlagen

[Bearbeiten]

Ausgangslage

In der Kategorie Vorlagen:Klima existieren mehrere Vorlagen mit ähnlicher/gleicher Funktion. Auf der Seite Wikivoyage:Expedition 'Design'/Darstellung scheinen diese Dopplungen ebenfalls erwähnt zu sein. Konkret ansprechen möchte ich:

  • {{Klimadiagr}} und {{Klimadiagramm}}
    • augenscheinlich haben beide Vorlagen die selbe Funktion, sehen aber nur leicht unterschiedlich aus
  • {{Klimatab}}, {{Klimatab-col}}, {{Klimatab-s}}
    • {{Klimatab}} verstehe ich als uneingefärbte Version von {{Klimatab-col}} (so habe ich es in der Dokumtion von Klimatab eingetragen) mit kleineren Abweichungen, wie z. B. dass Klimatab width=100% einnimmt, Klimatab-col aber so schmal wie möglich bleibt, oder, dass die Quellenangabe unterschiedlich dargestellt wird. Was {{Klimatab-s}} angeht, erkenne ich nicht deren Zweck.

Ich würde gerne anregen, dass {{Klimatab}} und {{Klimatab-col}} stärker angeglichen werden, sodass einziger Unterschied die Einfärbung ist, und klarer definitiert wird für welchen Zweck welche Vorlage einzusetzen ist. Für {{Klimatab-s}} möchte ich anregen, dass diese entweder mit Klimatab zusammengeführt wird, oder die Unterschiede und Einsatzfälle abgrenzend zu Klimatab dargestellt werden.

Für {{Klimadiagr}} und {{Klimadiagramm}} möchte ich anregen, dass diese Vorlagen entweder zusammengeführt werden oder klarer definitiert wird für welchen Zweck welche Vorlage einzusetzen ist. --Naseweis520 (Diskussion) 19:54, 4. Jan. 2019 (CET)[Beantworten]

Vorschläge

Diskussion

Schön, dass du es ansprichst. Aufgrund einiger Edits neulich viel mir auch wieder diese BAustelle ein. Ich wäre dafür eine einheitliche Regelung zu schaffen und nur eine Form der Darstellung zu benutzen und alle anderen Varianten zu entfernen. Aufgrund der Smartphones fällt die Klimatabelle aus meiner Sicht weg. Dort gibt es auch das Problem mit den nicht druckbaren Hintergrundfarben in der Druckversion (was man aber im Browser mittlerweile sicher einstellen kann). Bleibt nur eine Variante mit einem schicken smarthphonetauglichem Diagramm. Ich wäre für eine komplette Neuentwicklung. Sinnvollerweise mit der Extension Graph die wir zur Verfügung haben, anstatt mit CSS und HTML irgendwas haarsträubendes zu basteln. Auch SVG+CSS wäre eine Variante. Alle bestehenden Varianten sollten dann weg. -- DerFussi 20:14, 4. Jan. 2019 (CET)[Beantworten]

Bei Verwendung der Graph:*-Vorlagen sehe ich keine Möglichkeit Wasserdiagramme(?) zu erstellen, sodass wahrscheinlich Vega eingesetzt werden muss. Dies hat auch den Vorteil, dass sich damit dynamische Diagramme erstellen lassen. Anscheinend verwendet die Erweiterung Vega v2 statt das aktuelle v4. Ich kenne nicht die Pläne von Wikimedia, aber sollte die Version geupgradet werden, so wird wahrscheinlich eine manuelle Portierung notwendig.
--Naseweis520 (Diskussion) 16:12, 5. Jan. 2019 (CET)[Beantworten]
Ich hatte bei der letzten Wikicon das Problem bei den Wikidata-Leuten angesprochen. Bisher ist nämlich überhaupt nicht klar, wo und wie Klimadaten zukünftig gespeichert werden sollen (Wikidata oder Commons) und wie man an die Daten herankommt (im Fall von Commons). In keinem Fall sollen sie wie bisher in den Artikeln gespeichert werden. Alles andere (Tabellen und/oder Diagramm) ist dann nachgeordnet. Ohne die Klärung des Frage der Speicherung sollten wir hier nur das unbedingt Nötige tun, auch deshalb, weil dies im gesamten Wikiversum benötigt wird. Ich denke, wir sollten nur noch jeweils eine Variante für Tabelle und Diagramm benutzen und beide letztendlich zusammenführen. Wie bereits angesprochen, führt an der Verwendung von <graph> (nutzt Vega) und Lua für Diagramme kein Weg vorbei. --RolandUnger (Diskussion) 17:31, 5. Jan. 2019 (CET)[Beantworten]
Sicherlich ist <graph>...</graph> ein ordentliches Werkzeug, obwohl ich die SVG+CSS-Variante sehr charmant finde, obwohl etwas aufwändiger. Die könnte man dann sogar responsive machen. Responsive SVG mit unterschiedlichen Darstellungen, abhängig von Zoomstufe und Endgerät ist ne hohe Kunst, aber machbar, denke ich (man muss nur aufpassen: das CSS für SVG bezieht sich in den Dimensionen nicht auf die Webseite, sondern die Grafik). Und mittlerweile kann man ja SVG direkt auf einer Webseite einbetten. Das sollte jeder Browser verstehen. Aber wieso ist die Speicherung der Daten dafür so wichtig? Man kann doch trotzdem ein Modul entwickeln. Wo die 24 Temperaturangaben dafür herkommen ist doch dem Modul erstmal egal. Das Auslesen der Daten (momentan aus den Vorlagenparametern) kann doch ein Submodul machen, welches dann nur getauscht wird. Unabhängig von dem späteren Ort der Speicherung dürfte das nächste Problem sein, freie Klimadaten für einen größeren Import zu bekommen.
Variante 2: Wir lassen alles, wie es ist und warten ab, bis eine Wikipedia was gescheites programnmiert hat und importieren es dann. Habe heute mal gestöbert, aber auch WP/en hat ihre ollen Tabellen und die HTML-Diagramme. -- DerFussi 18:19, 5. Jan. 2019 (CET)[Beantworten]
Ich denke, es wird sich kaum jemand finden, etwas neu zu programmieren, wenn es nur eine Zwischenlösung ist (auch nicht WP/en). Deshalb auch die Forderung, an alles, also auch gleich an die Speicherung zu denken – und natürlich eine Quelle für freie Klimadaten zu finden. Ich selbst habe nicht die Zeit hierfür und hoffe, dass das Ganze von jemand anderen bearbeitet wird, weil es ja in allen Wikimedia-Projekten verwendet werden könnte. Das Verfahren zur Darstellung (graph oder SVG) ist dabei zweitrangig, die SVG-Variante aber deutlich aufwändiger. --RolandUnger (Diskussion) 18:42, 5. Jan. 2019 (CET)[Beantworten]

──────────────────────────────────────────────────────────────────────────────────────────────────── Diese Diskussion ist liegen geblieben. Die angesprochenen ursprünglichen Punkte sind berechtigt. Alles weitere Angesprochene - dafür besteht offensichtlich derzeit kein Bedarf. Mag sich jemand um @Nw520: seine ursprünglichen Vorschläge kümmern? Er selbst vielleicht? Ich habe keine EInwände. Ansonsten würde ich bei fehlenden Antworten das Ding in einiger Zeit archivieren. -- DerFussi 19:35, 23. Jul. 2019 (CEST)[Beantworten]

Hallo DerFussi, übernehmen kann ich das gerne. Jedoch müsste noch einmal klar formuliert werden, welche Vorlagen behalten werden und welche - darauf läuft es ja wahrscheinlich - hinaus, fallengelassen werden. Konkret zu klären sind also:
  • {{Klimadiagr}} oder {{Klimadiagramm}} - persönlich tendiere ich zu zweiterem. Der Name ist sinniger, der Kontrast angenehmer, es hat eine WD-ID und wird öfter (auf niedrigem Niveau) verwendet
    • Hier müssten zwei Einbindungen von Klimadiagr migriert werden und wenige Seiten im WV-Namespace abgeändert werden
  • {{Klimatab}}, {{Klimatab-col}}, {{Klimatab-s}}: {{Klimatab}} und {{Klimatab-s}} haben soweit ich sehe keine Einbindungen und könnten m.E. als Veraltet markiert werden und ggf. Löschantrage eröffnet werden, nachdem sie aus Artikeln im WV-Namespace entfernt wurden. Ich persönlich sehe auch keine Notwendigkeit dem Autor die Entscheidung zu überlassen, ob die Tabelle nun bunt oder nicht zu sein hat, da das m.E. im gesamten Wiki einheitlich sein sollte.
@Nw520: Komplette Zustimmung. So machen wir das {{Klimadiagr}} entsorgen wir. {{Klimatab}} und {{Klimatab-s}} bekommen auch einen Löschantrag. Alles andere wird die Zukunft irgendwann bringen. -- DerFussi 21:44, 24. Jul. 2019 (CEST)[Beantworten]
Erledigt Einbindungen und Erwähnungen in Expedition wurden entfernt. Vorlagen als veraltet markiert und drei Löschanträge eröffnet. --Nw520 (Diskussion) 22:23, 24. Jul. 2019 (CEST)[Beantworten]
PS: Übrigens, da {{Banner}} ja auch veraltet ist, könnte man es eigentlich aus der Expedition Design entfernen. --Nw520 (Diskussion) 22:24, 24. Jul. 2019 (CEST)[Beantworten]
Vielen Dank. Da hast du recht, Wie so vieles ist auch diese Baustelle mal liegen geblieben. -- DerFussi 07:28, 25. Jul. 2019 (CEST)[Beantworten]

Artikelvorlage „Insel“

[Bearbeiten]

Ich habe zunächst einmal für den Eigengebrauch einen Textbaustein/Artikelvorlage zusammengebastelt, der sich an der Vorlage für neue Artikel „Stadt“ anlehnt (Strände gibt's ja auch). Weil das Ganze eher ein Rohentwurf ist, zunächst auf einer privaten Unterseite. Benutzer:Zenwort/Vorlagen-alpha Vorschläge und Anregungen (auch hinsichtlich Notwendigkeit überhaupt) würden mich freuen.

@Zenwort:: kleine Bitte: Statt Überschrift "Segelyachten" vielleicht etwas allgemeiner "Sportboote" oder "Sportschiffe" verwenden? Gruß --Eduard47 (Diskussion) 15:06, 15. Mär. 2019 (CET)[Beantworten]
Gute Idee, danke. --Zenwort (Diskussion) 23:10, 25. Mär. 2019 (CET)[Beantworten]
@Zenwort:: Noch 'ne Idee: Du hast in mehreren Abschnitten vCards beispielhaft vorgesehen. Insbesondere beim Flughafen solltest du diese vCard auf WD-Daten (inkl. auto=yes) reduzieren (zzgl. name/hours/description), da fast jeder Flughafen inzwischen einen WD-Eintrag hat. Auch kann man dann hervorragend diese vCard für andere Artikel verwenden. Bei der Anreise bitte unbedingt "Auf der Straße" oder "Mit dem Auto" mit aufnehmen, da gerade bei Inseln das häufig problematisch sein kann. Bei der Unterkunft sollte man evtl. "Camping" (für Camping- und Wohnmobilstellplätze) als zusätzlichen Unterabschnitt mit aufnehmen? Gruß --Eduard47 (Diskussion) 11:41, 26. Mär. 2019 (CET)[Beantworten]
@Eduard47: Der springende Punkt einer Insel ist eben,dass keine Straße hinführt. Und jedesmal zu schreiben „es gibt keine Straße, weil es eine Insel ist,“ ist nicht einmal dem DAU zuzumuten. Bei den Flüghäfen ist wikidata sicher sinnvoll, es muß aber noch Platz für Beschreibungen bleiben (wo sind Schließfächer usw.) --Zenwort (Diskussion) 12:20, 30. Jun. 2019 (CEST)[Beantworten]
@Zenwort:: Noch 'mal zur Anreise "auf der Straße": Auch wenn es eine autofreie Insel ist, so erfolgt häufig die Anreise zur Insel mit dem Auto. Die Fahrt endet dann zwangsläufig in einem Fährhafen, dort muss dann geparkt werden. Die Angaben zum Fährhafen (ggf. Link wenn eigener Artikel vorhanden), Parkmöglichkeiten dort usw. wären hier doch sinnvoll untergebracht. Die Unterschiede kommen bei den Ostfriesischen Inseln sehr gut zur Geltung, oder auch bei der Anreise zur Insel Amrum. Die "Vorlage:Insel" sollte sich eben nicht nur auf kleine Überseeinseln beschränken. Bei der mit dem Auto befahrbaren Insel Sylt gibt es 2 Varianten der Anreise mit dem Auto (Hindenburgdamm und Fähre vom dänischen Rømø). Alles dieses könnte im Abschnitt "Auf der Straße" oder "Mit dem Auto" untergebracht werden. Was auf der Insel passiert, ist dann im Abschnitt "Mobilität" zu finden. --Eduard47 (Diskussion) 09:34, 17. Jul. 2019 (CEST)[Beantworten]

Fahrgastzahl für Flughäfen von Wikidata

[Bearbeiten]

Hallo, ist es möglich Modul:Quickbar Ort so abzuändern, dass es P3872 für den Passagier-Wert nimmt? Leider sehe ich nicht die Möglichkeit das auszuprobieren, ohne direkt Änderungen im Modul machen zu müssen und diese abzuspeichern. --Nw520 (Diskussion) 23:49, 17. Nov. 2019 (CET)[Beantworten]

Das sollte möglich sein. @Nw520: Man kann übrigens Testen. Kopiere den Quellcode des Moduls nach Modul:Quickbar Ort/Test, markiere in der Doku, dass du gerade dran arbeitest. Deinen Code Testen kannst du auf der {{Testvorlage}} mit einem manuellen {{#invoke:Quickbar Ort/Test|Funktion|Parameter 1|...}}. Es gibt auch ein Modul:Testmodul welches man nutzen kann. -- DerFussi 20:05, 18. Nov. 2019 (CET)[Beantworten]
Erledigt --Nw520 (Diskussion) 21:51, 1. Dez. 2019 (CET)[Beantworten]