Wikivoyage:Lounge/Archiv 2017-01-07

Dieser Artikel ist Teil unseres Archivs. Den aktuellen Artikel findest Du unter Wikivoyage:Lounge.

---

---

---

In der Quickbar etwas unterdrücken.

Ich habe mal testweise eine Möglichkeit eingebaut, in der Ortsquickbar die Einwohnerzahl zu unterdücken. Ich werde das vielleicht auf alle Parameter ausdehnen. Ich selbst brauchte es in Neu-Seeland, da der Artikel hier nicht nur die gleichnamige Gemeinde sondern auch etwas mehr abdeckt. Wikidata-Angaben führen zu falschen Angaben und selbst ermitteln ist auch schwer, wenn man noch paar Dörfer mit abdeckt. Manch einer nutzt das Ding vielleicht auch für einen Artikel über einen See. Daher erschien es mir sinnvoll, wenn man es abschalten kann... Einfach Einwohner=nein/no/n oder false angeben... -- DerFussi 13:33, 4. Nov. 2016 (CET)

Das von dir angesprochene Problem existiert schon von Anfang an. Neben den Einwohnern betrifft dies TouriInfoWeb und TouriInfoTel, im Prinzip könnte dies auf fast alle Parameter zutreffen. Ich habe mich bisher so beholfen, dass ich {{Quickbar Ort}} mit leeren Paramenetern wie Einwohner = befüllt habe. Das hat aber den Nachteil, dass der Visual Editor (VE) oder der Vorlagenmeister (VM) diese Parameter entfernt. Ich schlage die Einführung eines oder zweier neuer Parameter vor: (1) Zeige/Mit bewirkt, dass zusätzlich zu den manuell vorgegebenen Parametern weitere aus WD angezeigt werden. Beispiel: Zeige = einwohner, provinz, touriinfotel. (2) Ohne: Behandel Quickbar wie auto, lässt aber Parameter aus. Beispiel: Man könnte Ohne = einwohner, touriinfotel Man käme vielleicht sogar nur mit dem zweiten Parameter aus. --RolandUnger (Diskussion) 06:53, 5. Nov. 2016 (CET)

Als Trenner kommen Leerraum und Kommas in Frage. Evtl. eine Wartungskategorie einführen, wenn ein Schreibfehler vorliegt. Vielleicht lässt sich die Ausschrift "Fehler im Modul Quickbar Ort: Unbekannte(r) Parameter: xxx (über Vorlage)" gleich mitbenutzen. --RolandUnger (Diskussion) 07:33, 5. Nov. 2016 (CET)

Die Ausdehnung auf alle anderen Parameter mache ich sowieso noch. Ansonsten wäre wichtig, dass es keine Änderung an bestehenden Artikeln geben darf, also dass jetzt niemand bestehende Artikel anfassen muss. Haben wir mit der individuellen Abschaltung nicht alle Fälle abgedeckt? Zusätzliche Parameter verwirren noch mehr. Wie soll eine Dopplung behandelt werden? Wenn |Einwohner=Foo und |Zeige=Einwohner oder |Einwohner=Foo und |ohne=Einwohner gleichzeitig angegeben werden. Es erschwert auch das Editieren der Quickbar für ungeübte, wenn sie manuelle Einträge angeben wollen, ebenso schwierig wird es für die Wikidatatools. Das Löschen der Einträge durch den VE kann man man doch bei Entwicklerteam/Phabricator ansprechen, ebenso das mit dem VM. -- DerFussi 09:43, 5. Nov. 2016 (CET)

Oder kann man über Templatedata den Parameter required das Löschen im VM verhindern? -- DerFussi 09:58, 5. Nov. 2016 (CET)

ICh werde mich demnächst auch der Touriinfo annehmen, die man ja nun auch auf WD angeben kann. -- DerFussi 10:02, 5. Nov. 2016 (CET)

Ich bin erst einmal froh, dass die Diskussion noch einmal aufgekommen ist, auch weil du sie selbst angestoßen hast. Und es ehrt dich, dass du unnötige Arbeit verhindern möchtest.

Aber zuerst zu den Vorlagen und ihre Handhabung: Ich weiß, dass wir uns häufig Gedanken machen mussten, wie man ein fehlendes und ein leeres Argument möglichst in einem Schritt behandeln kann. Beides ist für die Nutzung im Wiki dasselbe: ein nicht vorgegebener Parameter. Deshalb wird er sowohl vom VE als auch vom VM gelöscht. Da dies in der gesamten Wikimedia-Welt das erwartete Verhalten ist, wird es eine Änderung durch das Entwicklerteam nicht geben. Ganz abgesehen davon, dass dies Monate oder Jahre dauern kann. Nur Katastrophen werden sofort behandelt. Allenfalls gibt es den Hinweis, dass ein Vorlagenprogrammierer doch mit fehlenden Parametern umgehen kann. Mit dem Parameter required fordern wir eine unbedingte Angabe an, also irgendetwas, was nicht leer oder nil ist.

Die Quickbar Ort/Quickbar Region können nur mit den beiden Grenzfällen alle Daten aus Wikidata (WD) oder keine Daten aus WD richtig umgehen. Dafür gibt es den Parameter all, der standardmäßig nicht gesetzt ist. Wenn man von diesen Grenzfällen absieht, muss man die Quickbar entweder anweisen, zusätzliche Parameter aus WD hinzuzufügen oder auszulassen. Hierfür fehlt uns in beiden Fällen eine Syntax. Die Nutzung eines Parameters ohne Wert zum Hinzufügen eines WD-Wertes ist ein Workaround, aber keine Lösung. Wie gesagt, er wird einfach entfernt. Und im worst case bekommen die Autoren eine Löschung auch nicht mit. Wie man es realisiert, dass ein QB-Parameter aus Wikidata definitiv unterdrückt oder verwendet wird, ist dann zweitrangig. Aber mit einem wertlosen Parameter schaffen wir es nicht.

Der Workaround Parameter ohne Wert wird tausendfach verwendet. Es ist eine Illusion zu glauben, dass eine Umstellung ohne manuelle Nacharbeit vonstatten geht. Hilfreich wäre hier eine Wartungskategorie. -- RolandUnger (Diskussion) 11:29, 5. Nov. 2016 (CET)

Und warum kommt diese Argumentation in dieser erst jetzt, nach Jahren, wo alles bei uns fertig ist? Diese Variante war selbst vor dem neuen Quickbar-Modul in den alten Quickbar-Vorlagen gängige Praxis und akzeptiert. Auch als einzige Lösung, um den Forderungen von Autoren gerecht zu werden, die kein Wikidata wollen. Leere Parameter sind gängige Praxis ([1]. Ich kann mir nicht vorstellen, dass jemand in der Wikipedia möchte, dass die rausfallen. Das Feedback, das eine Lösung nicht gewollt ist oder Jahre dauern kann, würde ich von den VE-Entwicklern gerne selbst hören, das ist bisher nur Spekulation. Das tut mit leid, aber eine grundlegende Änderung der Quickbar und Module, jetzt hinterher, jetzt wo alles rund läuft, und jetzt wo die Community alles beackert hat, könnt ihr, kannst du gerne machen, aber ohne mich. -- DerFussi 12:36, 5. Nov. 2016 (CET)

Habe es schon mal auf Höhe und Provinz erweitert. Um noch mal auf oben zurückzukommen. Das Problem ist, wir haben einen allgemein akzeptierten und funktionierenden Stand. Seit gefühlt drei Jahren liefern wir kaum neue Inhalte (bis auf ein paar Autoren) sondern sind nur mit uns selbst beschäftigt. Themennamensraum abschaffen, neue Quickbar, Verwandte Sites abschaffen, Abschnitte umbenennen. Wenn wir jetzt nochmal die Ortsquickbars anfassen wollen, jagt man uns berechtigterweise vom Hof. Und auch ich fasse mich langsam an den Kopf. Um nochmal technisch zu werden. Eine kommaseparierte Liste von Parametern ist ebensowenig Wikistandard und wird auch vom VE nicht unterstützt, der hierfür eigentlich eine Checkbox-Liste generieren müsste, sollte es für Autoren komfortabel sein. Und es kompliziert das Handling selbst für gestandene Wikiautoren unnötig, wenn man über einen komplexen Parameter andere Parameter steuert, abgesehen vom Handling mehrfacher Einträge. Ich weiß nicht, wie andere es sehen. die bisherige Variante hatte bis jetzt keine Widersprüche. Und die Priorität bei den VE-Entwicklern ist da, schließlich wollen auch die WP-Autoren nicht, dass ihre leeren Parameter verschwinden , sie sollen ja von anderen Autoren befüllt werden, ohne dass sie erst die Hilfe lesen müssen. -- DerFussi 20:55, 8. Nov. 2016 (CET)

Dass wir uns nicht ständig mit Verwaltungskram beschäftigen sollten, liegt auf der Hand. Wenigstens ist es und schon mal gelungen, einen Bot mit derartigen Aufgaben zu betrauen.

Zur Liste: Wenn es bei den Parametern möglich ist, ein "nein" hineinzuschreiben, dann sollte dies auch mit "ja" möglich sein. Es passiert zwar genau dasselbe wie ein leerer Parameter, der Parameter wird dann aber nicht von den Editoren gelöscht. Ich werde ein vergleichbares Vorgehen auch bei der vCard implementieren. Das bedeutet keinen Aufwand für die Autoren.

Unabhängig von der QB: Auswahllisten (Einfach- und Mehrfachauswahlfelder oder checkboxes/radio buttons) wäre ein guter Vorschlag für den VE. Denn das Problem von Textfeldern mit kommaseparierten Werten werden wir bei der vCard mehrfach haben (Email, Telefon, Kreditkarten, Ausstattung). Zum einen soll alles so bleiben wie gehabt. Zum anderen bringt es wenig, für jedes Feature einen eigenen Parameter zu haben. --RolandUnger (Diskussion) 07:15, 9. Nov. 2016 (CET)

Das "ja" zu implementieren sollte nicht das Problem sein, das geht fix. Merke es mir vor. -- DerFussi 13:45, 9. Nov. 2016 (CET)

Habe es testweise bei den Einwohnern implementiert Einwohner=ja/j/yes/y oder true holt Daten von WD. -- DerFussi 16:16, 9. Nov. 2016 (CET)

Ich habe es schon mal an einem Beispiel ausprobiert. Es macht das, was ich mir vorgestellt habe. --RolandUnger (Diskussion) 18:46, 10. Nov. 2016 (CET)

Es geht doch mit dem VE. Der VE ist sogar in der Lage leere Parameter zu erzeugen. Setzt man bei einem Parameter die Eigenschaft suggested auf true erzeugt der VE leere Parameter, wenn man beim Editieren eine neue Vorlage anlegt. Das "j" wird zwar nun von der Quickbar unterstützt, ich sehe aber keinen Grund mehr die Nutzer damit zu belästigen. -- DerFussi 12:32, 8. Dez. 2016 (CET)

Neuigkeiten vCard

In Vorbereitung zur Neugestaltung der {{vCard}} habe ich mehrere Module neu geschrieben. Das betrifft zum einen die Koordinaten (Modul:Coordinates, Modul:GeoData) und zum anderen die Verlinkung von Telefonnummern mit Modul:LinkPhone.

Bei den Koordinaten gibt es kaum sichtbare Änderungen, bei den Telefonnummern schon: Wenn eine Telefonnummer (phone, mobile) in der vCard als formal richtig erkannt wird, wird sie verlinkt und man kann sie gleich vom einem Smartphone anwählen. Faxnummern werden nicht verlinkt. Telefonnummern können Zusätze wie Apparatenummern und Erläuterungen in Klammern enthalten. Etwas problematisch sind Schrägstriche, die eigentlich nicht in eine Telefonnummer gehören. Im deutschen Sprachumfeld wird der Schrägstrich meist als Trenner zwischen Vorwahl und Telefonnummer eingesetzt. Meist. Es gibt auch Fälle, in denen er zur Trennung unterschiedlicher Telefonnummern gilt. In Ortsartikel braucht man keine Landesvorwahl mitzuschreiben, die Telefonnummer muss dann aber mit der Vorwahl-Null beginnen. Die Ländervorwahl wird aus Wikidata geholt.

Beispiele:

• Aus {{#invoke:Phone|linkPhone|(0)123 2 56 78 90 (Lobby Bar), +49 (0)123 2 56 78 91 (Oasis Restaurant)}} wird (0)123 2 56 78 90 (Lobby Bar), +49 (0)123 2 56 78 91 (Oasis Restaurant)
• Aus {{#invoke:Phone|linkPhone|(0)123 VOYAGE App. 1 (Direktor)}} wird (0)123 VOYAGE App. 1 (Direktor).
• Mit Fehler: aus {{#invoke:Phone|linkPhone|(0)123 86 92 43 App. 1 Direktor}} wird (0)123 86 92 43 App. 1 Direktor.

-- RolandUnger (Diskussion) 07:33, 5. Nov. 2016 (CET)

Heisst das nun, dass ich in der vCard auf das Einsetzen von |intl-area-code= verzichten kann und die Nummer wieder wie ich es früher gemacht habe, mit einer führenden in Klammer gesetzten Null einsetzen kann? Ich hatte mich doch so schön bemüht, jedesmal den intl-area-code einzutragen... - lieber Gruss Martin - Mboesch (Diskussion) 07:24, 18. Nov. 2016 (CET)

Bitte setzen Sie ihr Passwort zurück

Wir haben ein Problem mit Angreifern, die Wiki-Benutzerkonten mit priviligierten Nutzerrechten übernehmen (beispielsweise Admins, Bürokraten, Aufpasser, Checkuser). Ursache sind anscheinend schwache oder wiederverwendete Passwörter.

Mitglieder der Community arbeiten zusammen mit Mitgliedern mehrerer Teams der Stiftung zusammen, um dieses Problem zu beheben.

In der Zwischenzeit fordern wir jeden dazu auf, einmal die Passwörter seiner Wiki-Benutzerkonten unter die Lupe zu nehmen. Wenn ein schwaches Passwort gewählt wurde oder ein Passwort, das noch irgendwo anders benutzt wird, sollte dieses geändert werden.

Es sind starke Passwörter zu wählen -- acht Zeichen oder länger, bestehend aus Buchstaben, Zahlen und Sonderzeichen. Joe Sutherland (Diskussion) / MediaWiki message delivery (Diskussion) 00:23, 14. Nov. 2016 (CET)

Umgestaltung der vCard

In den letzten Wochen habe ich Vorbereitungen zum Ersatz der Vorlage {{vCard}} getroffen und sie in der Programmiersprache Lua neu geschrieben. Teile wie die Verlinkung von Telefonnummern und Emailadressen waren ja schon aktiv. Es gibt einige Neuerungen: show = poi ist jetzt der Standard, die Subtypes bekommen nun eine Funktion, es können Daten aus Wikidata bezogen werden, und es gibt nun viel mehr Fehlermeldungen. Im Nachfolgenden mal drei Beispiele:

1. 52.514413.3896Deutschland 1 Ein Hotel, Hauptstraße 1 (Abzweig von der Nebenstraße). Tel.: +49 (0)30 2345 1234, (0)176 345 1234, Fax: +49 (0)30 2345 9876, E-Mail: info@hotel.de, Skype: nutzer.name. Das in der Innenstadt gelegene Hotel besitzt großzügige Räume, bietet aber nur ÜF. Merkmale: WLAN, Bar, Schwimmbecken. Geöffnet: 7/24. Check-in: ab 14 Uhr. Check-out: bis 12 Uhr. Akzeptierte Zahlungsarten: Visa, Master, AmEx, Maestro. (52° 30′ 52″ N 13° 23′ 23″ O)letzte Änderung: Nov. 2016 (Angaben möglicherweise veraltet)
2. 49.252972224.035444441 Carnegie-Bibliothek (bibliothèque Carnegie), 2 Place Carnegie, 51100 Reims. Tel.: +33 (0)3 26 77 81 41, E-Mail: carnegie@bm-reims.fr ​ .letzte Änderung: keine Angabe
3. 30.04777831.2333331 Ägyptisches Museum (‏المتحف المصري‎, ​al-Matḥaf al-Miṣrī, ​Egyptian Museum, ​auch Nationalmuseum), Mīdān et-Taḥrīr, ​‏ميدان التحرير‎ (im Stadtzentrum, ​‏بوسط البلد‎). Tel.: +20 (0)2 2579 6948, E-Mail: egyptianmuseum@moantiq.gov.eg ​ . Geöffnet: täglich 9:00–17:00, 9:00–16:00 (Ramadan). Preis: LE 30 (Araber*innen), LE 10 (arabische Studierende), kostenlos (bis 5 Jahre; Araber*innen, ab 61 Jahre), LE 550 (Ausländer*innen), LE 275 (ausländische Studierende); Stand 11/2024. (30° 2′ 52″ N 31° 14′ 0″ O)letzte Änderung: Jan. 2024

Beispiel 1 zeigt die klassische Nutzung, Beispiel 2 den vollständigen Bezug aus Wikidata ({{vCard | d = Q257342 | auto = j }}) und Beispiel 3 den gemischten Einsatz (weitere Beispiele unter Modul:VCard). Bei den Ausstattungsmerkmalen sollen mal Piktogramme zum Einsatz kommen, deshalb wird dieses Feature erst zukünftig standardmäßig aktiviert sein.

Bevor es zur Umstellung kommt, möchte ich hier zur Diskussion anregen, um insbesondere die Darstellung zu verbessern. In den Artikeln muss natürlich keine Umstellung vorgenommen werden. --RolandUnger (Diskussion) 16:57, 16. Nov. 2016 (CET)

Über die Darstellung der Features und Sterne sollten wir uns Gedanken machen. Ideal wäre Symbole in einem Corporate Design. Auch die Kreditkarten sollten als Symbole kommen (wenn man sie benutzen darf)-- DerFussi 18:56, 16. Nov. 2016 (CET)

Für viele Bilder in der VCard ist die Texthöhe fast zu klein. Vielleicht sollten die Sterne, Features und Kreditkarten dann in eine neue Zeile und die ganzen VCards etwas Abstand zueinander haben. Vielleicht sollte man dann auch auf die Anwendung im Fließtext verzichten bzw. in diesem Fall die Ausgabe von Grafiken verzichten. Das ganze würde die Lesbarkeit der VCArd erleichtern und auch für mobile Geräte etwas optimierter sein. Als Inspiration dient mal die Ergebnisliste bei Hotelsuchmaschinen und usw. sollte etwas weniger pompös sein, aber schon im Artikel abgegrenzt erkennbar sein. -- DerFussi 19:06, 16. Nov. 2016 (CET)

Vielen Dank. Ich strebe auch Symbole an, um die Informationen kompakter darstellen zu können. Aber es sind viele, ungefähr 70. Bei den Kreditkarten müssen wir generell noch etwas Hand anlegen, aber es sind nur etwa hundert Artikel zum bearbeiten.

Ich habe etwas Bauchschmerzen mit der Rechenzeit, denn die Vorlage wird teilweise hundertfach eingesetzt. In Artikeln wie Bremen, Würzburg und Halle (Saale) habe ich schon die Ausschrift gesehen, dass nicht genug Rechenzeit zur Verfügung stand. Deshalb möchte ich die serverseitigen Berechnungen so gering wie möglich halten und alles andere in clientseitige Stilvorlagen und Skripte packen. Dafür gibt es schon eine ganze Reihe von Klassenangaben. Dann dürfte das Schickmachen ein geringeres Problem sein.

Ich habe schon einige Ideen, wie man weitere Informationen in einem einblendbaren Zusatzfenster anzeigen könnte. Dazu würde ich gern eine Expedition eröffnen, wo man dies diskutieren kann. --RolandUnger (Diskussion) 07:45, 17. Nov. 2016 (CET)

Das sieht alles ja recht kompliziert aus. Hoffentlich versteht das auch jeder und trägt zur Akzeptanz der vCard bei (PoI + freier Text ist einfacher für den Ungeübten!). Daher von mir 2 Vorschläge:
1. Die Erfassung der vielen Daten einer vCard könnte man vereinfachen, indem man diese mit Hilfe einer Tabelle erfasst. Linke Spalte: Feldbezeichnung, rechte Spalte Inhalt, mit "Return" springt man von Zeile zu Zeile, am Ende ein Button "Fertig" überträgt dann alles. Wie man das programmiert, weiß ich allerdings nicht.
2. Zur Darstellung und Lesbarkeit habe ich in der Vergangenheit einen kleinen Trick angewandt: Die Daten der vCard habe ich als solche unangetastet gelassen, auf die "descrition" innerhalb der vCard aber verzichtet, stattdessen dann nach einem Zeilenumbruch eine Beschreibung angehängt. Die Beschreibung ist dadurch deutlich von den Daten abgegrenzt. Das erleichtert m. E. die Lesbarkeit und Übersichtlichkeit erheblich.--Eduard47 (Diskussion) 21:03, 16. Nov. 2016 (CET)

Die Parameter sind dieselben wie bisher. Der Visual Editor und der Vorlagenmaster unterstützen die Eingabe der Daten in einfacher Form in Formularen. Der vorgenannt Trick ist wenig optimal, denn dann braucht man keine Vorlage vCard. Eine Unterscheidung zwischen reinen Listen und der Beschreibung von Sehenswürdigkeiten ist wohl sinnvoll und bereits angedacht. Zum anderen sind Änderungen an einem Lua-Script einacher vornzunehmen als bei der Vorlagenprogrammierung. --RolandUnger (Diskussion) 07:25, 17. Nov. 2016 (CET)

Zukünftig sollen die (technischen) Daten aus Wikidata geholt werden, wenn sie schon verfügbar sind. Dann ist auch die Vorlage deutlich einfacher zu bestücken. Aber nur Daten, die sich bereits fehlerfrei in der vCard befinden, lassen sich dann maschinell nach Wikidata transferieren. So haben wir zum Beispiel in knapp 1.300 syntaktisch fehlerhafte Telefonnummern und in 1.500 Artikeln Telefonnummern mit Schrägstrichen, die wir nur im deutschen Wikivoyage behandeln können. --RolandUnger (Diskussion) 07:37, 17. Nov. 2016 (CET)

Das die Beschreibung nun in Schriftfarbe Grau ist und sich leicht abhebt finde ich sehr gelungen. Grüße -- Feuermond16 (Diskussion) 21:07, 16. Nov. 2016 (CET)

@Eduard47. Du solltest unbedingt die Beschreibung in die VCArd als description packen. Die optische Verbesserung sollte dann die Vorlage selbst übernehmen. Dazu besprechen wir das hier. Formulareingabe gibt es auch jetzt schon, auch für den VCArd (sihe Vorlageneingabe mit Formularen), oder den Visual Editor) -- DerFussi 08:02, 17. Nov. 2016 (CET)

Ich habe mal die Expedition 'vCard' eröffnet, um einen Designvorschlag für ein Popup-Fenster insbesondere für den Einsatz in Smartphones vorzustellen. --RolandUnger (Diskussion) 16:33, 17. Nov. 2016 (CET)

Die TAXI-Taste wie bei Agoda... hahahaha ... sehr gut. Hätte ich schon öfter gebrauchen können. Sieht bei mir (Edge-Browser) etwas verschoben aus. -- DerFussi 17:19, 17. Nov. 2016 (CET)

Ich habe noch etwas gestrickt, so dass es jetzt auch im Edge geht. Da gibt es noch einen Bug im Kartographer. Aber es soll in erster Linie ja eine Designstudie sein. Man könnte dann für Smartphones per CSS auch den Inhalt kürzen. --RolandUnger (Diskussion) 18:11, 17. Nov. 2016 (CET)

Aus meiner Sicht würde ich es bei den Kreditkartenanbietern nicht auf die Spitze treiben, ob mit Nennung der Firmen oder des Logos, evtl. einfach erwähnen, dass Kreditkarte geht oder evtl. sogar umkehren, dass Kreditkarten nicht akzeptiert werden. Welche KK in einem Land üblicherweise akzeptiert sind, könnte man ja im Länderartikel ausführen. Ich sehe schon grossen Aufwand auf uns zukommen, wenn KK-Firmen schliessen (nicht so wahrscheinlich) oder fusionieren und unter einem neuen Namen auftreten, wess hierzulande bei Telekomanbietern die Regel ist. Vor allem bei der Kreditkarte kann es ja von Jaher zu Jahr Änderungen gebe, von der ich als Gast gar nichts mitbekomme, wenn meine Kreditkarte jedesmal geht, und ich setze geringe Hoffnung darin, dass Besucher sich die Liste akzeptierter Karten geben lassen und sie bei ambulanter Bearbeitung einfügen (vielleicht ja schon...). Ähnlich ist es auch bei Bankautomaten und Tankstellen, auch bei der Autovermietung, mal geht die EC-Karte, die eine oder andere Kreditkarte, unsere Schweizer Postfinancekarte mit dem Plus-Logo, das man kaum kennt, aber die Karte geht sehr oft... - das alles zu erfassen, erscheint mir ein zu grosser Aufwand, auch wenn es für den einen oder andern Reisenden hilfreich wäre. Bei Interesse an einer Hotelbuchung für eine längere kann man sich die Website des Hauses anschauen oder eine mail schicken. lieber Gruss Martin - Mboesch (Diskussion) 07:34, 18. Nov. 2016 (CET)

Problematisch sind unabhängig vom notwendigen Erhebungs-Arbeitsaufwand die Parameter credit-cards, hours, aber auch alt und price. In allen Fällen handelt es sich bisher um frei nutzbare Eingabezeilen, und es wird in der neuen vCard-Variante auch erst einmal auch so bleiben. Und es besteht auch keine Pflicht, diese Felder zu befüllen. Aus technischer Sicht wäre eine Liste von Kreditkarten schön. Die könnte man in einer (noch nicht bestehenden) Auswahlliste abhaken. Momentan sehe ich nur die Möglichkeit, die Kreditkartenbezeichner durch Logos zu ersetzen. Andererseits wurden Kreditkartenangaben bisher auch nur selten eingetragen.

Wir werden um den manuellen Eintrag auf lange Zeit nicht umhinkommen, denn die angegebenen Parameter sind auch in Wikidata kaum vorhanden oder gar nicht vorgesehen. Bei der Behandlung gibt es zudem Schwierigkeiten. Bei price habe ich damit zu rechnen, dass man zum Beispiel die Kosten für das gesamte Museumsgebäude in Erfahrung bringen kann, aber nicht weiß, ob es Ermäßigungen bei den Eintrittspreisen gibt. Bei hours gibt es mit der schwer zu behandelnden Eigenschaft P3025 zwar eine Lösung, die sich aber von der Variante bei Open Street Map unterscheidet. Letztere wäre intuitiver. Und leider sind beide Varianten nur mit erheblichen Aufwand ineinander zu überführen. --RolandUnger (Diskussion) 10:23, 19. Nov. 2016 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Für die hiesige Erhebung stellen sich für mich folgende Punkte als vorrangig heraus:

• Dies ist die Reihenfolge der Elemente, denn die lässt sich mit technischen Hilfsmitteln wie Stilvorlagen kaum ändern und muss „hart“ kodiert werden. Eine Anpassung im Skript ist aber mit überschaubaren Aufwand machbar.
• Möglicherweise sollte man für Sehenswürdigkeiten (type: see) eine andere Anordnung/Ansicht erarbeiten als für die anderen Elemente. Dies betrifft zum einen die Reihenfolge, aber auch die Frage, ob eine Kürzung z.B. im Fall von Smartphones sinnvoll ist.
• Wurde etwas vergessen oder übersehen?

Die optische Realisierung einschließlich der Ausblendung einzelner Bestandteile lässt sich mit Stilvorlagen, die Nutzer für sich auch umdefinieren können, einfach lösen.

Die Nutzung von subtype ist erst einmal eine Zukunftsoption und soll vorerst nicht standardmäßig angezeigt werden. Hier steht aber eigentlich nur die Aufgabe, Icons zu erstellen.

Auch wenn es technisch bereits vorbereitet wurde, wird man auf Wikidata-Informationen nur in wenigen Fällen zurückgreifen können. --RolandUnger (Diskussion) 10:23, 19. Nov. 2016 (CET)

Ich habe mittlerweile auch eine Lösung für Skype gefunden. Hier steht hauptsächlich die Frage vor oder hinter die Email anordnen. --RolandUnger (Diskussion) 13:09, 20. Nov. 2016 (CET)

Den Vorschlag mit der Popup-Ansicht finde ich genial.
Andererseits bin ich – wie vielleicht schon bei früheren Diskussionen deutlich geworden ist – kein Fan von sogenanntem "Klickibunti". In der klassischen Ansicht (ich verstehe den Vorschlag so, dass die vCards im Artikel zunächst "klassisch" wie bisher ausgegeben werden und sich nur bei Anklicken zusätzlich die Popup-Ansich öffnet, richtig?) würde ich daher bei einer "textlastigen" Darstellung bleiben und auf Piktogramme und Logos lieber verzichten. Die Verwendung von Logos der Kreditkartengesellschaften und sozialen Netzwerke kommt mir ein bisschen wie Werbung daher. So finde ich beispielsweise den schlichten Schriftzug "Mastercard" immer noch besser erkennbar und aussagekräftiger als das Logo mit den zwei Kreisen (das sicher sehr bekannt ist, und wer eine Mastercard besitzt, wird es sicher erkennen, aber ich sehe keinen Gewinn gegenüber dem schlichten Schriftzug). Auch sind Piktogramme nicht immer allgemeinverständlich (universell verständliche Piktogramme zu entwickeln, ist eine eigene Wissenschaft) und sehe angesichts der Alphabetisierungsrate im deutschsprachigen Raum auch keinen Vorteil gegenüber Schrift. Um sie leicht erkennbar zu machen, müssten die Piktogramme zudem so groß sein, dass sie weit über die normale Zeilenhöhe hinausragen würden.
In der ohnehin viel stärker graphisch aufgebauten Popup-Ansicht hätte ich hingegen nichts gegen Piktogramme einzuwenden. Hier kann man sie groß genug darstellen, möglichst mit einer Legende hinterlegt (sodass also beim Darüberhalten des Mauszeigers die Bedeutung des Piktogramms noch einmal als Text ausgegeben wird) und sie haben den Vorteil, dass man zum Beispiel bei einer Unterkunft auf einen Blick checklistenartig die Ausstattungsmerkmale abgleichen kann. Auch wenn es viele Details gibt, an denen man noch feilen kann, sehe ich den Vorschlag insgesamt als dramatischen Schritt in Richtung größere Benutzerfreundlichkeit und würde mich sehr freuen, wenn er umgesetzt würde.
Wird denn die Erneuerung der vCard auch mit dem Angebot einer formularartig ausfüllbaren Eingabemaske einhergehen (die sich im Idealfall sogar mit dem Visual Editor kombinieren ließe)? Das würde, denke ich, die Bearbeitung für unerfahrene Benutzer stark vereinfachen und die Schwelle zum Mitmachen deutlich senken. Die Gewinnung neuer Kontributoren (und seien sie auch nur sporadisch aktiv) sehe ich als die größte Aufgabe für die Zukunft von Wikivoyage an. --Bujo (Diskussion) 11:37, 21. Nov. 2016 (CET)

Sprachführer Spanisch

Nachdem die Seitensperre abgelaufen ist, ist der uneinsichtige Bearbeitungskrieger wieder aufgeschlagen (zur selben Zeit auch auf en-WV). Ich bin mir nicht sicher, wie aktuell das Prozedere zur Benutzersperrung ist (ich erinnere mich vage, dass es vor ein paar Monaten aus gleichem Anlass eine Diskussion dazu gab). Ich habe angesichts der Vorgeschichte ehrlich gesagt keine Hoffnung mehr, dass von diesem Benutzer irgendwelche konstruktiven Beiträge kommen können. Eine Seitensperre finde ich eigentlich unfair gegenüber potentiellen unbescholtenen Benutzern, die den Artikel bearbeiten wollen, zumal die Störung hier klar nur von einem einzigen Benutzer ausgeht. Andererseits kann dieser natürlich immer wieder ein neues Konto anlegen. Wie sollten wir vorgehen? Beste Grüße, --Bujo (Diskussion) 11:09, 21. Nov. 2016 (CET)

Habe es nochmal zurückgesetzt und um Statement gebeten (allerdings sind die Hälfte der Änderungen auch nicht wirklich sinnlos). Beim nächsten mal wäre durch das Regelwerk eine Sperre gerechtfertigt, denke ich (am besten durch einen bisher unbeteiligten Admin). Beim Verdacht auf Sockenpuppen hilft nur der Weg über die Stewards. -- DerFussi 22:13, 21. Nov. 2016 (CET)

Wenig sinnvoll wenn Sterlabot (NeoMaps...) den Sprachführer de-es bearbeitet, und er die deutsche Sprache nicht kennt. Ein neuer Abschnitt mit den Unterschieden der Spanischen Sprache (Mexico, Peru...) wäre wohl sinnvoll, dazu fehlem ihm aber die Sprachkenntnisse. Werde ein Auge darauf haben... --Bernello (Diskussion) 23:21, 21. Nov. 2016 (CET)

Von Spanisch hat der keine Ahnung, ist ein alter Bekannter, und jetzt gesperrt. --Bernello (Diskussion) 00:54, 22. Nov. 2016 (CET)

Habe ihn auch im schwedischen WV gesperrt. Sah so aus, als ob er jetzt global gebannt ist. -- DerFussi 15:46, 22. Nov. 2016 (CET)

=>Global lock für Sterlabot: [2] --Bernello (Diskussion) 22:36, 22. Nov. 2016 (CET)

Ich finde man sollte auf regionale Unterschiede und Slang vor allem in Länderartikeln hinweisen. en-WV hat zwei Sprachführer für Spanisch, aber so wirklich glücklich bin ich mit der Lösung ehrlich gesagt auch nicht. So ziemlich das einzige was in ganz Lateinamerika gleich ist und sich von dem was in ganz Spanien gleich ist unterscheidet ist die Sache mit dem z bzw. ce und ci. Und dafür braucht man keine zwei getrennten Sprachführer. Alles weitere unterscheidet sich zu sehr von Land zu Land oder von Region zu Region als dass man da verallgemeinern könnte. Hobbitschuster (Diskussion) 20:50, 22. Nov. 2016 (CET)

Quickbar Ort

Kurze Info, bin etwas in Zeitnot. Die Touriinfo wird bei Verfügbarkeit jetzt auch von Wikidata geholt (Bsp.: Cottbus) Ich schreibe noch was auf die Doku-Seite (welche Eigenschaften auf WD dazu nötig sind). -- DerFussi 15:45, 22. Nov. 2016 (CET)

Give-aways für 2017

WMDE plant neue Give-aways für 2017 für Wikipedia und die Schwesterprojekte anzufertigen. Wir freuen uns auf eure Vorschläge, Präferenzen und Ideen bis 4. Dezember 2016 auf dieser Planungsseite. --Nicolas Rück (WMDE) (Diskussion) 16:56, 25 November 2016 (UTC)

10. Geburtstag und erste Geschenke

Am 10. Dezember 2016 feiern wir den 10. Jahrestag unserer Abspaltung von Wikitravel. Und natürlich können wir Geburtstagsgeschenke gebrauchen:

• Yuri Astrakhan und sein Team arbeiten daran, immer neue Features dem Kartenwerkzeug Kartographer hinzuzufügen. Mittlerweile können auch Kartenformen, -masken und Linienzüge aus OpenStreetMap mit eingebunden werden. Wrh2 hat gleich die Vorlage {{Mapshape}} geschrieben, die jetzt auch im deutschen Wikivoyage verfügbar ist.

• Es kann sich nur noch um Stunden handeln, dass die neue Sprachversion Finnisch aus dem Ei schlüpft. Finnisch ist dann die 18. Sprache in Wikivoyage.

• Die Neufassung der Vorlage {{vCard}} ist (fast) fertig. Zu den neuen Features gehören der Datenbezug aus Wikidata und eine umfangreichere Parameterprüfung. Einen Wermutstropfen gibt es auch: viel Arbeit bietet nun die neue Wartungskategorie Wartung vCard.

Am 10. Dezember 2016 treffen wir uns in Berlin in der Geschäftsstelle von Wikimedia Deutschland, Tempelhofer Ufer 23/24, 10963 Berlin. Ab 10 Uhr beginnt unser Community-Treffen, wo über Vieles diskutiert werden soll. Themen sind u.a. Wikidata und OpenStreetMap. Um 15 Uhr soll die Feier starten.

Auch in Wien wird Wikivoyage aktiv sein: der altehrwürdige Wiener WikiDienstag fällt nun auf das Wochenende vom 3./4. Dezember 2016 und widmet sich dem Thema Wikivoyage. --RolandUnger (Diskussion) 14:30, 27. Nov. 2016 (CET)

Programm zum WikiDienstag am 3./4. Dezember 2016 in Wien

Der lange WikiDienstag in Wien steht diesmal ganz unter dem Motto „Wikivoyage“. Das Programm steht in Grundzügen fest:

Programm Samstag

11:00 bis 13:00	Vorstellen und Editieren von Wikivoyage für Einsteiger Vorschläge (auch andere Themen sind je nach Interesse möglich!): https://en.wikivoyage.org/wiki/Vienna/Outer_South und https://de.wikivoyage.org/wiki/Wien/Simmering Hintergrund: Österreich ist nächstes Jahr Gastgeber des Wikimedia Hackathon 2017, der in diesem Stadtteil stattfindet.
13:00 bis 14:00	Mittagspause
14:00 bis 15:30	Editieren von Wikivoyage für Einsteiger Vorschläge (auch andere Themen sind je nach Interesse möglich!): https://en.wikivoyage.org/wiki/Vienna/Outer_South und https://de.wikivoyage.org/wiki/Wien/Simmering Hintergrund: Österreich ist nächstes Jahr Gastgeber des Wikimedia Hackathon 2017, der in diesem Stadtteil stattfindet.
15:30 bis 17:00	Vorstellen und erste Erfahrungen mit Kartographer
17:00 bis 20:00	Kleine Feier zu 10 Jahre Wikivoyage mit Buffet einschließlich Vortrag Westliche Wüste Ägyptens

Programm Sonntag

10:00 bis 11:00	Editieren von Wikivoyage für Einsteiger Vorschläge (auch andere Themen sind je nach Interesse möglich!): https://en.wikivoyage.org/wiki/Vienna/Outer_South und https://de.wikivoyage.org/wiki/Wien/Simmering Hintergrund: Österreich ist nächstes Jahr Gastgeber des Wikimedia Hackathon 2017, der in diesem Stadtteil stattfindet.
11:00 bis 12:00	Responsibles Design am Beispiel Wikivoyage
12:00 bis 13:00	Mobiler Einsatz von Wikivoyage

Wahrscheinlich werden die Sonntagsprogrammpunkte und der Kartographer noch ausgetauscht.

Ort: Geschäftsstelle von Wikimedia Österreich, Siebensterngasse 25/15, A-1070 Wien (Stadtteil Neubau, unmittelbar nördlich von Mariahilf).

Wie man sieht, sollen insbesondere die südlichen Wiener Stadtteile verbessert werden. Denn Wien ist Gastgeber für den Wikimedia Hackathon vom 19. – 21. Mai 2017.

Wer also in der Nähe ist, sei herzlichst eingeladen. --RolandUnger (Diskussion) 07:04, 30. Nov. 2016 (CET)

Vorabankündigung Wikivoyage-Community-Treffen am 10. Dezember 2016

Es ist geplant, am 10. Dezember 2016 in Berlin ein Wikivoyage-Community-Treffen anlässlich des 10. Geburtstages des Wikivoyage-Forks zu veranstalten.

Wo: Geschäftsstelle des Wikimedia Deutschland, Tempelhofer Ufer 23/24, 10963 Berlin

Wann: 13–19 Uhr

Folgendes Programm ist geplant:

• 13:00 Uhr: Eröffnung und Begrüßung
• 13:15 Uhr: Vortrag: Kartendarstellung mit dem Kartographer (Roland Unger)
• 14:00 Uhr: Vortrag: OpenStreetMap, Waymarked Trails (Sarah Hoffmann)
• 14:45 Uhr: Vortrag: Wikidata, Massendaten nach Wikidata (Geolines, Geoshapes, Klimadaten, Lydia Pintscher)

• Ab etwa 15:30 Uhr: Offene Diskussion, Zukunftsdiskussion: um was sollte Wikivoyage zukünftig erweitert werden?

• Etwa 17 – ca. 19 Uhr: kleine Feier zum 10. Geburtstag.

Momentan plane ich eine finanzielle Unterstützung durch den Wikimedia Deutschland e.V. Eine offizielle Bestätigung seitens Wikimedia Deutschland liegt aber noch nicht vor.

--RolandUnger (Diskussion) 16:52, 1. Dez. 2016 (CET)

Ich komme mal "rüber"..... Hoffentlich ist es nicht zu kurzfristig und es können ein paar vorbeikommen. See ya. -- DerFussi 17:18, 1. Dez. 2016 (CET)

ich werde noch verschiedene Leute direkt anschreiben. Hansm und Elelicht wollen auch kommen. --RolandUnger (Diskussion) 06:45, 2. Dez. 2016 (CET)

Das Community-Treffen wird von Wikimedia Deutschland gefördert. Wir können somit Reisekosten und zum Teil Übernachtungskosten übernehmen. --RolandUnger (Diskussion) 18:28, 6. Dez. 2016 (CET)

Reisekostenerstattung geschieht im Nachhinein? Tickets hatte ich nämlich schon vor knapp 90 Tagen gebucht... Wäre cool, aber nicht notwendig, wenn das möglich wäre! --Timmaexx (Diskussion) 00:10, 7. Dez. 2016 (CET)

Wir haben eine Reisekostenrückerstattung für 15 Personen geplant. Vor der Veranstaltung kurz eine Email an Wikimedia Deutschland senden und Belege innerhalb eines Monats bei WMDE einreichen. --RolandUnger (Diskussion) 07:51, 7. Dez. 2016 (CET)

Wikivoyage auf Finnisch

Seit dem 1. Dezember 2016 gibt es nun auch die finnische Version von Wikivoyage. --RolandUnger (Diskussion) 07:37, 2. Dez. 2016 (CET)

Help test offline Wikipedia

Hello! The Reading team at the Foundation is looking to support readers who want to take articles offline to read and share later on their phones - a use case we learned about from deep research earlier this year. We’ve built a few prototypes and are looking for people who would be interested in testing them. If you’d like to learn more and give us feedback, check out the page on Meta! (I apologise that this message is only available in English.) Joe Sutherland (WMF) (talk) 01:32, 3. Dez. 2016 (CET)