Vorlage Diskussion:VCard

Zweck

Dieses Template wurde entwickelt, um die mittlerweile „experimentell“ eingesetzten Listing-Tags ersetzen zu können. Es werden zwar fünf verschiedene derartige Tags eingesetzt, doch haben sie alle dieselben Parameter und Wirkung. Man ist offensichtlich auch zu der Meinung gelangt, dass es unsinning ist, für jede Art von Einrichtung derartige Tags zu definieren.

Nur VCard

Deshalb schlage ich auch vor, nur VCard (für Visitenkarte) zu benutzen und sich hierbei auf die wesentlichen Attribute zu beschränken. Alles andere, wie Beschreibung, kann als normaler Text formuliert werden.

Ein Parameter, nämlich type, hat hier eigentlich (vorläufig) keine Funktion. Er dient hier vielmehr als Kommentar für die ansonst sehr abstrakte VCard.

Ich denke du zielst auch mit auf dein anderen Vorlagen Hotel, Restaurant uns Shop ab. Ließen sich dann trotzdem einrichtungsspezifische Tags sinnvoll abdecken. Ich dachte da an solche Ideen wie z.B. Attribute wie "Küche=italienisch" die aber nun sehr spezifisch sind, und nur für Restaurants interessant sind. Habe da so an die Zukunft für spätere Auswertungen gedacht. -- (WV-de) DerFussi 09:29, 2. Nov 2006 (CET)

Ursprünglich war VCard als Ersatz für Wikitravels Listing gedacht, um sie schnell umstellen zu können. Deswegen auch dieselben Attributnamen. In der Diskussion auf wikitravel gibt es nun eine interessante Feststellung: alle Tags haben dieselben Attribute, so dass schon mal nachgefragt wurde, ob nicht einfach location reicht. Aber es verwundert eigentlich nicht, steckt doch dahinter ein php-Parser, den man nur mit begrenzter Intelligenz bestücken kann.

Aber ein zweites Phänomen gibt es: Alles, was sich nicht in die Rubriken Essen, Schlafen, Trinken stecken lässt, wird einfach in die Rubrik Sehenswürdigkeit gepackt, egal ob prähistorische Fundstätte, Synagoge oder Freizeitpark.

Wenn man Daten aber später auswerten will, dann muss man standardisieren (am besten nur wenige unterschiedliche oder nur ein Objekte), muss aber dennoch abfragbare Spezifika haben. Deswegen habe ich hier type und subtype eingebaut. Man muss sich aber bezüglich der Spezifika beschränken, weil sie irgendwann sowohl für den Suchenden als auch für die Suchwerkzeuge nicht mehr zu beherrschen sind.

Ich benutze VCard (am 19. Oktober entwickelt) bisher nicht, weil sicher noch Feinschliff nötig ist. Und ich würde mir Diskussionen wünschen. -- (WV-de) Roland 13:04, 2. Nov 2006 (CET)

Ich bin die ganze Zeit am Grübeln, ob ein sub-type reicht, oder ob es bei einem Hotel/Restaurant/Shop/Museum... mehrere geben kann. Gut, beim Restaurant ist es fast eindeutig: die angebotene Küche. Aber bei vielen Arten von Einrichtungen gibt es auch Zielgruppen: "behindertengerecht", "gay-friendly" ... Oder man schafft noch ein zusätzliches sub-tag für solche Infos. Aber selbst die beiden letzten Beispiele können sich theoretisch überschneiden. Darüber hinaus sind die letztgenannten aber auch nur Ja/Nein-Infos. Ein einfaches Flag reicht ja. Könnte man auch eine Reihe binärer Tags nutzen? So in etwa solch ein Tag: "flags=110011" könnte heißen: akzeptiert Visa, MC, keine Amex, nicht behindertengerecht, gay-friendly, nur in Begleitung Erwachsener oder sowas - Das ganze wird einmal in der Vorlage ordentlich dokumentiert. Eine Extension könnte doch dann diese Infos in Symbole oder so etwas umsetzten, wenn die Artikelseite generiert wird. -- (WV-de) DerFussi 15:11, 2. Nov 2006 (CET)

Die Idee mit den Flags ist wohl sogar realisierbar: Über den #expr-Operator lassen sich verschiedene Spezifikationen zusammensetzen.
Beispiel: {{{{#expr: {{{cdMasterCard}}} + {{{cdVisa}}} + {{{cdAmEx}}} }}, naürlich sollten {{{cdMasterCard}}} usw. vorher mit 1, 2, 4, ... belegt sein.

Mit der Modulo-Operation sollte es wieder auflösbar sein:
((Zahl mod 2^(n+1)) - (Zahl mod 2^n)) <> 0 sollte angeben, ob 2^n gesetzt ist.
Beispiel: 7, Test ob 2^2 gesetzt ist: (7 mod 8) - (7 mod 4) = 4. -- (WV-de) Roland 16:14, 2. Nov 2006 (CET)

Habe die Idee mit Attribute wie "Küche=italienisch" auch schon gehabt. aber selten (im Comments Feld) Eingetragen. Bei der rasanten Zunahme an Smartphone“ Mobilfunkgeräten, könnte man auch, wenn man den Beschreibung Text weglassen würde, überlegen ob man zukünftig ein Output eines QR Quadrats ermöglichen könnte per internem QR Code Generator. Damit man mit dem „Smartphone“ dann diese vom Bildschirm Ablesen könnte und somit die VCard im Gerät hätte. Dies setze aber voraus das man diesen dann per Javascript einbinden würde da sonst die VCards alle Mindestlängen hätten was dann die Artikel unnötig zumüllen würde. Ist nur eine Idee für das „Brainstorming“ hier betreffs VCard.--Walta (Diskussion) 19:37, 22. Sep. 2013 (CEST)

Keine Sprachverzweigung

Es erscheint mir nicht sinnvoll, eine Sprachverzweigung über ein weiteres lang-Attribut vorzunehmen. Technisch wäre es möglich. Da jedoch mit dem Aufkommen weiterer Sprachvarianten diese Vorlage immer wieder angepasst werden müsste, würde es massive Änderungen in den Artikeln hervorrufen, die diese Vorlage verwenden.

Ich schlage, so es überhaupt nötig wird, Varianten wie VCard-en etc. vor. Auf :en: würde aber sicher ohnehin nur die übersetzte VCard zu finden sein.

VCard erweitern

Ich hab di VCard jetzt zum ersten Mal benutzt. Man vermisst irgendwie die Möglichkeit Qualität, Lage und ähnliche teilweise subjektive Bemerkungen hinzuzufügen. Im normalen Text - na gut. Aber wenns denn maschinell lesbar sein soll - dann doch auch mit den zusätzlichen infos oder ?

was is mit "comment(s)"? Gibts sowas ?

ein paar Kleinigkeiten:

• Kreditkarten, könnte auch Karten heißen zBsp: für EC, Maestro, Debit-Karten, die streng genommen kein e kreditkarten sind.

• mail-adressen würd ich nich verlinken, aber auf jeden Fall den spammern zum Trotz per JS verschlüsseln - geht das?

danke

--(WV-de) SonarTom 01:32, 3. Jul. 2007 (CEST)

Hm. Das mit dem subjektiven Text kann ruhig ausgelagert bleiben. Die Idee ist auch, dass diese Informationen in anderen Sprachverisonen standardisiert ausgegeben werden können. Der beschreibende Text wird aber immer ein normaler Atikeltext bleiben. Das mit der E-Mailverschlüsselung ist vielleicht nicht soo brisnat. Die Mailadressen der der Hotels .... stehen sowieso überall im Netz (auf ihrer Homepage, bei den ganzen Buchungs seiten - gut da vielleicht weniger-, Infoseiten usw. Die müssen sich eh' um einen g'scheiten Spamschutz kümmern oder? Dass die mail-Adrese komplett mit ausgeschrieben wird hatte einen technischen Hintergrund, weiß nicht mehr welchen. -- (WV-de) DerFussi 07:13, 3. Jul. 2007 (CEST)

(Fussi war schneller)

Die Erweiterung um weitere Kreditkarten und Kommentare ist sicher möglich. Es hat hat in der Vergangenheit Vorschläge zur Erweiterung gegeben. Das Problem ist, dass die Standardisierung nötig, aber nicht einfach ist. Sicher wird man nicht alles in die Vorlage/Funktion packen können bzw. wollen, insbesondere z.B. Textkommentare, weil letztere nur in den individuellen Sprachzweigen Verwendung finden (Vcard soll auch Bestandteil der Locatiobs-Datenbank werden).

Bei Email-Adressen würde ich die Nutzbarkeit für den Anwender in den Vordergrund stellen, d.h., sie nicht zu verschlüsseln. Der einzige Schutz vor Email-Spammern ist, keine Email-Adresse zu besitzen. Ich gehe davon aus, dass jeder, der heutzutage im Internet agiert, über Spam-Schutz verfügt. Selbst Blacklist-Filter bringen schon eine vernünftige Aussonderungsquote. --(WV-de) Roland 07:24, 3. Jul. 2007 (CEST)

Vielleicht sollten wir hier einfach nochmals alles zusammentragen, welche Ergänzungen nötig erscheinen. --(WV-de) Roland 08:06, 3. Jul. 2007 (CEST)

Mir geht da nachwievor die Idee mit den Tags nicht aus dem Kopf - diese Variable mit den schlichten Ja/Nein-Funktionen. Da gäbe es wie gesagt, Informationen, die aufgenommen werde könnten. Nicht alle Tags machen bei jeder Einrichtung Sinn, aber eine Ausgabe erscheint ja eh' nur, wenn sie mit "ja" belegt sind (siehe auch Diskussion oben). Folgende Tags werden u.a. vorstellbar: behindertengerecht, nur in Begleitung Erwachsener, gayfriendly ...

Aufnahme einer Koordinate, ein kleines Symbol könnte ja dann einen Link zu Kartenwerken bzw. dem jetzigen Koordinatenziel enthalten. Die Koordinaten müssen ja nicht mit hingeschrieben werden. -- (WV-de) DerFussi 08:23, 3. Jul. 2007 (CEST)

Ich würde jetzt vorbehaltlich der Tags noch die Koordinaten hinzufügen. zBsp GPX-format-ähnlich wie hier erklärt:

• | gpx=latitude,longitude - GPX-kompatible Position. Wird zur zeit noch nicht uterstützt.

könnten dann zb für Berlin sein:

• | gpx=52.521294,13.409243 - beispielsweise mit passender Verlinkung zu

Google Maps. natürlich sind da noch mehr Vorgaben möglich.

der Rest wie oben kommentiert.

OK ?

Grüße

--(WV-de) SonarTom 21:19, 3. Jul. 2007 (CEST)

Koordinaten sind sinnvoll. Das WGS84-Format für Koordinaten (Dezimalform) reicht aber aus (ist Teilmenge von gpx). Sinnvoll erscheint auch eine Maßstabsangabe.

Bei der Schreibweise (getrennt für Länge oder Breite oder kommasepariert) bin ich mir noch nicht ganz sicher. Wir werden bei der Komplexität irgendwann auf das „klassische“ Vorlagenmodell verzichten müssen und Funktionen einsetzen müssen. Für den Anwender ergeben sich aber keine Änderungen. --(WV-de) Roland 07:02, 4. Jul. 2007 (CEST)

Wenn gerade nichts anderes anliegt, befasse ich mich ja z.Z. mit einem Prototyp für eine Location-Datenbank. In diesem Zusammenhang habe ich mir auch nochmal Gedanken über die VCard gemacht.

Type/Sub-Type: Ich habe inzwischen die Datenbankstruktur so angelegt, dass eine Mehrfach-Typisierung möglich ist. Ich glaube, es wird viele Fälle geben, wo ein Typ nicht ausreicht. Beispielsweise ein Schwimmbad mit Frei- und Hallenbad sowie Sauna und Thermalbecken. Diesem Objekt kann man sich von verschiedenen Gesichtpunkten nähern, je nachdem, was man sucht. Hier wären m.E. mehrere Kombinationen aus Typ und Sub-Typ nötig.

Preise: Aus der Sicht der Formalisierung die furchtbarste Eigenschaft. Preise für Übernachtungen für Doppel- und Einzelzimmer, Eintrittspreise mit Ermäßigungen für bestimmte Personengruppen, Getränkepreise in Kneipen, Preise für den Fahrradverleih und wer weiß was alles. Und dann auch noch die Währungsangabe. Wie soll man das alles über einen Kamm scheren? Ich bin bei meinen Basteleien diesem Problem erst mal ganz aus dem Weg gegangen und versuche es nur mit Preiskategorien von A-H.

Öffnungszeiten auch böse, aber nicht ganz zu schlimm wie Preise. Trotzdem, entweder, man lässt freien Text zu, der nicht weiter analysiert wird und einfach so wie er ist ausgegeben wird (dann aber natürlich auf Englisch) oder man muss von den Autoren ein ganz spezielles, fest definiertes Eingabeformat verlangen, das serverseitig geparst wird. Beides ist nicht richtig elegant, aber ich weiß nichts besseres.

Geo-Koordinaten können vor allem in größeren Städten tatsächlich hilfreich sein. Allerdings sollten diese Koordinaten dann natürlich recht genau sein, damit man das Objekt innerhalb einer Stadt auch tatsächlich lokalisieren kann. Diese Angaben könnte man auch für eine Umkreissuche verwenden.

Kommentare und Beschreibungen in Prosa ist sinnvoll, aber nicht formalisierbar. Wenn man so was vorsieht, müsste es eine Möglichkeit zur Lokalisierung geben, so dass jede Sprachversion, die auf eine VCard-Resource zurückgreift, die Möglichkeit hat, den Kommentar zu übersetzen und in der jeweiligen Sprache angezeigt zu bekommen. Scheint mir aber nicht ganz einfach. Deshalb würde ich ein Kommentar-Feld höchstens für die direkte Anzeige einführen, es jedoch nicht in die DB füttern.

Das größte Problem bei den VCards scheint mir das zu sein, was Tom auf Wikivoyage Diskussion:Beschreibungen von Unterkünften schon angesprochen hat: Wie bringen wir's unseren Autoren bei? Autor DAU ist damit zufrieden, wenn er einen schönen Text sieht, den er seinen Vorstellungen entsprechend formatiert. Er wird wenig Verständnis dafür haben, irgendwelche seltsamen Parameter zu befüllen, wenn die Auswirkung nicht unmittelbar sichtbar wird. Vielleicht könnte man den DAU mit netten kleinen Icons bestechen, die für jeden (Meta-)Parameter eine direkte optische Rückmeldung geben. Aber dann gibt's bestimmt wieder irgendjemanden anderes, der aus Prinzip keine Meta-Angaben macht, weil ihm die Icons nicht gefallen.

-- Hansm 17:40, 4. Jul. 2007 (CEST)

Koordinaten : ich hab mal kurz nach WGS84 gesucht (hh'mm''ss), quasi die GPS-Grundlage. Die Umrechnung von lingitude und latitude in WGS84 ist einfach - umgekehrt eher nicht. Der wichtigste Grund für mich long, lat zu nehmen wäre aber, dass yahoo und google das direkt benutzen. Wenn ich also Koordinaten für einen Ort suche kann ich das direkt bei google machen, oder auch in einer API nur drauf klicken statt danach zu suchen. Für WGS84-Koordinaten hab ich da jetzt erstmal nichts gefunden ?!

Preise : da würd ich nicht so genau sein. Die Informationen sind sowieso meist veraltet. Im Low-Budget-sektor der Unterkünfte geht die Entwicklung zu sich der Auslastung anpassenden Preisen oder man bucht gleich über Portale - und die Preise sind nochmal ganz anders. Außerdem ist es ja eine VCard, keine Verkaufsseite für das jeweilige Unternehmen. Weg damit. Kategorien find ich viel besser, sind aber vermutlich auch etwas subjektiv: die einen finden 10 € für den Museumsbesuch teuer, die anderen nicht. Kategorien für Preise eignen sich nur für vergleichbare Leistungen und ob das Pergamonmuseum in Berlin nun besser als das Jüdische Museum ist und daher beim einen 10 € in Kategorie C und beim Anderen in Kategorie B passen ist Ansichtssache. Bleibt also nur den geringsten Preis und den höchsten zu nehmen und entsprechend dazwischen einzusortieren.

Öffnungszeiten : Mich interessiert hier bei der VCard nur eine generelle Angabe. Warum also nicht vorgegebene tags benutzen wie ganzjährig, nur sommer, nur winter, zzt geschlossen, ganzjährig außer So, Feiertage, Mo, Di, Mi, Do, Fr, Sa, So geschlossen. Der Rest kann wieder nur bedingt aktuell sein. Und wenn dann passt es in der entsprechenden Sprache unter die VCard. Komplizierten Angaben wie ganzj. geschlossen 24.12., 25.12., 31.12., 1.1. usw. würd ich eh nicht vertrauen. Da muss man sich nur Bus- und Bahnfahrpläne ansehen (die lustigen kleinen Erläuterunen ganz unten). Wer denkt, dass das einer begreift, geschweige denn sich dran orientieren kann - na danke.

Prosa : Icon sind immer schön, wenn Sie unauffällig und selbsterklärend sind. Mein Lieblingsbuch dazu: Don't Think von Steve Krug. Sowas kann auch übersichtlich sein. Ich denke, dass man erstmal was anbieten muss. Scheinbar ist hier jetzt wie so oft weniger mehr. Ein Hauptkriterium mit dem viele Spielereien weggefallen ist der Übersetzungstest.

--(WV-de) SonarTom 13:04, 5. Jul. 2007 (CEST)

Realisierung

Es scheint sinnvoll, die VCard mit folgenden drei Feldern zu erweitern: Attribute (zur weiteren Charakterisierung über Typ und Subtyp hinaus), Koordinate und evtl. Kommentar. Ein Teil der Felder wie Preise und Kommentar sind Textfelder, da hier kaum eine sinnvolle Standardisierung möglich ist.

Zukünftig wir die VCard noch wie eine Vorlage aussehen, aber für ihre Realisierung eine Funktion benutzen, weil sie flexibler und leistungsfähiger als die klassische Vorlage ist. Den bisher selten oder freizügig genutzten Feldern Typ, Subtyp und Attribut kommt eine besondere Aufgabe zu: So sollen der Klassifizierung und späteren Suche dienen. Alle Felder können mehrere kommaseparierte Werte aufnehmen. Diese Werte müssen aber standardisiert werden. Ich werde in den nächsten Tagen beginnen, an dieser Stelle eine Tabelle mit diesen drei Feldern anzulegen, wo man sinnvolle Typen und Attribute eintragen kann.

Zusätzlich werde ich mir Gedanken machen, ob und wie eine formulargestützte Eingabe der VCard möglich ist, da sie letztlich sehr komplex sein wird. Zumindest in der Form wie auf Wikimedia Tools/Templator. --(WV-de) Roland 08:51, 9. Jul. 2007 (CEST)

Weitere Vorschläge für Typen

Neue Wünsche bitte hier eintragen.

Noch ein paar Vorschläge für vermisste Typen:

• Ladestationen für E-Autos, bzw. E-Bikes; --Karle3 (Diskussion) 13:50, 22. Dez. 2020 (CET)

• Berghütten als Unterkunft;

• Sportgeschäfte: Allgemein und speziell: Wintersport, Bergsport (-alpine)...

• Läden: Feinkost / Bioläden

• (Berg)Führer -guide--(WV-de) Bbb 13:39, 5. Mai 2010 (CEST)

• Transport: Schiffslinie

Habe mal was ergänzt

• alpine hut (vielleicht auch besser: mountain shelter)
• sports shop
• delicatessen shop
• guide
• shipping company

Bei Shops haben wir vielleicht ein ähnliches Problem, wie bei den Restaurants. Hier wären vielleicht Untertypen für das spezielle Angebot besser. Dies ist eigentlich analog zu den Restaurants (Western, Asian, Thai, Chinese, Italian ...). Ich tippe diese derzeit per Komma getrennt als subtype mit ein - so war damals Rolands Vorschlag. Das ist aber seeeehr ungünstig, wenn jemand später den Vorlagenmaster nutzt, killt dieser alle Einträge, die nicht in der XML definiert sind. Solange es keiner anfasst, ist es ok. Da müssen wir konzeptionell noch was tun. -- (WV-de) DerFussi

• Es gibt keine Ferienwohnung (holiday flat/vacation home [amerik.]). Gruß, (WV-de) Felix 11:39, 18. Sep. 2010 (CEST)

Vorschlag: Vorlagentyp Landmarke für die Angabe der Geokoordinaten und als Sprungadresse zum Einsatz im Fließtext z. Bsp. bei Routenbeschreibungen.--(WV-de) Bbb 13:29, 16. Jun. 2012 (CEST)

gibt es möglicherweise als Vorlage coord schon. --(WV-de) Roland 13:47, 16. Jun. 2012 (CEST)

Als Sprungadresse für internen Link? Würde gern das Windjoch in die Routenbeschreibung des Nadelgrats (gleicher Anstieg, Gabelung) einbauen, siehe hier auch den Abzweig zum Ulrichshorn.--(WV-de) Bbb 13:58, 16. Jun. 2012 (CEST)

habe landmark, mountain und summit ergänzt. Auch die Vorlage coord kann nun optional ein Sprungziel über anId= erhalten. bei vCard ging das schon immer. Und ich habe verstanden, was durch gebraucht hast. --(WV-de) Roland 14:51, 16. Jun. 2012 (CEST)

Danke, passt prima.--(WV-de) Bbb 17:07, 16. Jun. 2012 (CEST)

Typen

Im Zusammenhang mit der Erstellung der Beschreibungsseite Vorlage:VCard/XML wurden folgende Typen verwendet. Der Übersichtlichkeit halber wurden die Typen gruppiert. Die Liste lässt sich erweitern und soll der Diskussion dienen:

• accommodation
  • alpine hut
  • appartment
  • bed and bike
  • boarding house
  • campsite
  • guest house
  • holiday flat
  • hostel
  • hotel
  • hotel garni
  • pension
  • youth hostel

• activities
  • festival

• administration
  • administration
  • consulate
  • government
  • embassy
  • office
  • organisation
  • police
  • post
  • relief organisation
  • tourism authority
  • tourist information
  • town hall

• archaeological sites
  • archaeological site
  • building
  • castle
  • cemetery
  • fort
  • inscription
  • palace
  • pyramid
  • temple

• buying
  • antiquarian
  • bakery
  • bank
  • bike shop
  • book seller
  • company
  • delicatessen
  • jewellery
  • mall
  • market
  • photo store
  • shop
  • sports shop

• communication
  • internet café
  • phone

• culture
  • cinema
  • circus
  • cultural organization
  • discotheque
  • gallery
  • library
  • music
  • opera house
  • theater

• eating and drinking
  • bar
  • beer garden
  • brewery
  • cafe
  • ice cream parlor
  • pastry shop
  • pub
  • restaurant
  • restaurant and bar
  • snack bar

• health
  • clinic
  • dentistry
  • drugstore
  • hospital
  • pharmacy
  • practice
  • surgery

• learning
  • college
  • cooking class
  • kindergarten
  • library
  • nursery
  • school
  • university

• museum
  • mining museum
  • museum
  • open air museum

• nature
  • cave

• other
  • laundry
  • toilet

• parks and gardens
  • aquarium
  • botanical garden
  • cemetery
  • garden
  • park
  • plantation
  • theme park
  • zoological garden

• recreation
  • amusement park
  • ballooning
  • casino
  • club
  • lake
  • quad bike
  • swimming pool

• religious sites
  • cathedral
  • church
  • monastery
  • mosque
  • nunnery
  • pagoda
  • religious site
  • synagogue
  • temple

• sights
  • bridge
  • building
  • bunker
  • castle
  • cemetery
  • fort
  • landmark
  • memorial
  • mountain
  • palace
  • sight
  • summit
  • tour operator
  • tower

• sports and wellness
  • airport
  • dive center
  • golf
  • lake
  • massage
  • port
  • spa
  • sport
  • sports shop
  • stadium
  • stud
  • swimming pool

• transport
  • airline
  • airport
  • airport service
  • ballooning
  • bike rental
  • bridge
  • bus
  • car rental
  • car sharing
  • ferry
  • horsecar
  • port
  • public transport
  • shipping company
  • shuttle bus service
  • subway
  • taxi
  • train
  • tram

• travel
  • guide
  • travel agency

Vorschläge zur benutzerfreundlicheren Weiterentwicklung der Darstellung von "Typ"

Dieser längere Artikel beruht auf der nicht fortgesetzten Diskussion in der Wikilounge. Ich habe mich einigermaßen über xml "schlau gemacht" und nach einigen Tagen auch den fehlerhaften Link zu der xml-Beschreibung des Templates aus der Fehlermeldung heraus entecken können. Immer noch geht es mir darum, dem (evtl. neuen) Nutzer den Umgang mit den Typen zu erleichtern.

Hintergrund: Nach meiner Datenbank-basierten Denke ist das Feld "Typ" für die Bedeutung der v-card essentiell. Ortsgebundene Daten wie Länge/Breite oder die Herkunft der einzelnen v-card aus dem Namensraum geben keinen ernsthaft weiteren Nutzen her, welcher ein letztlich derart überfrachtetes und vordergründig schwerfälliges Instrument rechtfertigen würde. Die mögliche Kreuzauswertung über die Typen macht das Salz in der Suppe (Bsp.: Nenne mir alle bekannten Flohmärkte in Andalusien/alle bekannten Häfen auf Madeira). Daher bin ich der Meinung, dass auch vor einer möglichen Weiter-/Andersentwicklung in Wikimedia daran gearbeitet werden sollte.

Die aufgeführten Code-Schnipsel haben nach bestem Wissen lediglich die aktuellen Werte der Vorlage übernommen, ohne (eigentlich nötige) Weglassung oder Hinzufügung, um am Status Quo arbeiten zu können. Sie sollen nur als mögliche Vorlage für erfahrenere Nutzer/Admins dienen, denen so lästige Verwaltungs-, Übersetzungs- und Schreibarbeit abgenommen werden soll. Mangels ausreichender Erfahrung mit Templates im Wikimedia-Raum will ich nicht selbst rumpfuschen. Ich bin auch nicht beleidigt, wenn sie aus welchen Gründen auch immer, nicht realisiert werden. Ich kann halt nix auf sich beruhen lassen, was ich nicht verstehe, und jetzt verstehe ich immerhin etwas mehr.

Eindeutschen der Benennungen von "Typ"

Wäre ein erster Schritt, wie von Fussi vorgeschlagen. Hab ich mal selbst erledigt und sollte eigentlich mit der zugrunde liegenden xml-Deklaration funktionieren (Bloß die Reihenfolge wird sich vermutlich an der englischen Deklaration der values orienieren) :

Die labels (Eindeutschungen) in der vorgeschlagenen Art funktionieren natürlich nicht. Wenn überhaupt, müsste das label ins <Value>, was aber von der Software nicht unterstützt wird. --RolandUnger (Diskussion) 06:33, 10. Mai 2013 (CEST)

Der Gruppenparameter wird bereits anderweitig verwendet. --RolandUnger (Diskussion) 06:34, 10. Mai 2013 (CEST)

Das Label ist im Value, wie unschwer zu erkennen ist, das Endtag folgt erst danach. In der xml-Deklaration des Autors wird <label> auch als allgemein anwendbarer Begriff dargestellt. Vielleicht sollte man es einfach ausprobieren, nur zum Spaß. Ich habe deutlich gemacht, dass es hier ohnehin nur um die schlechteste aller nicht notwendigen Lösungen geht. Ich habe auch nichts dagegen, wenn jemand die Übersetzungen angemessen korrigiert. Der Gruppenparameter wird nach meiner unwissenden Einschätzung doch ganz offensichtlich im Skript des Autors lediglich dazu verwendet, einzelne Abschnitte in der Vorlage des VM zu schaffen, zu was anderem ist er ja ohnehin auch nicht gedacht.--Gastromartini (Diskussion) 04:39, 11. Mai 2013 (CEST)

<Group name="Art der Einrichtung">
  <Parameter name="type" label="Typ" length="50">
   <Help>Typ der Einrichtung</Help>
   <Value>restaurant</Value>
   <Value>bar label="Bar"</Value>
   <Value>cafe label="Cafe Kaffehaus"</Value>
   <Value>snack bar label="Snack Bar Kiosk"</Value>
   <Value>hotel label="Hotel"</Value>
   <Value>pension label="Pension"</Value>
   <Value>appartment label="Appartments"</Value>
   <Value>administration label="Verwaltung(sgebäude)"</Value>
   <Value>airline label="Fluggesellschaft"</Value>
   <Value>airport label="Flughafen"</Value>
   <Value>airport service label="Flughafendienste"</Value>
   <Value>alpine hut label="Berghütte"</Value>
   <Value>amusement park label="Vergnügungspark"</Value>
   <Value>antiquarian label="Antiquitäten"</Value>
   <Value>aquarium label="Unterwasserwelt"</Value>
   <Value>archaeological site label="Ausgrabungsstätte"</Value>
   <Value>bakery label="Bäckerei"</Value>
   <Value>ballooning label="Ballonfahren"</Value>
   <Value>bank label="Bank/Geldwesen"</Value>
   <Value>bed and bike label=""</Value>
   <Value>beer garden label="Biergarten"</Value>
   <Value>bike rental label="Fahrrad-/Motorradverleih"</Value>
   <Value>bike shop label=""</Value>
   <Value>boarding house label="Gasthaus"</Value>
   <Value>book seller label="Buchladen Landkarten"</Value>
   <Value>botanical garden label="Gartenanlage"</Value>
   <Value>bridge label="Brücke"</Value>
   <Value>building label="(hist.) Gebäude"</Value>
   <Value>bunker label="Bunker"</Value>
   <Value>bus label="Busgesellschaft"</Value>
   <Value>campsite label="Campingplatz"</Value>
   <Value>car rental label="Mietwagen"</Value>
   <Value>car sharing label="Car Sharing"</Value>
   <Value>castle label="Schloß"</Value>
   <Value>cathedral label="Kathedrale"</Value>
   <Value>cave label="Höhle"</Value>
   <Value>cemetery label="Friedhof"</Value>
   <Value>church label="Kirche"</Value>
   <Value>cinema label="Kino"</Value>
   <Value>circus label="Zirkus"</Value>
   <Value>clinic label="Gesundheitszentrum"</Value>
   <Value>club label="Club"</Value>
   <Value>college label="Hochschule"</Value>
   <Value>company label="Unternehmen"</Value>
   <Value>consulate label="Konsulat"</Value>
   <Value>cooking class label="Kochkurse"</Value>
   <Value>cultural organization label="Kulturorganisation"</Value>
   <Value>delicatessen label="Spezialitätengeschäft"</Value>
   <Value>dentistry label="Zahnarzt"</Value>
   <Value>discotheque label="Diskothek"</Value>
   <Value>dive center label="Tauchbasis"</Value>
   <Value>embassy label="Botschaft"</Value>
   <Value>ferry label="Fähre"</Value>
   <Value>festival label="Festival/Festspiele"</Value>
   <Value>fort label="Festung"</Value>
   <Value>gallery label="Galerie"</Value>
   <Value>garden label="Garten"</Value>
   <Value>golf label="Golfplatz"</Value>
   <Value>government label="Regierung (sgebäude)"</Value>
   <Value>guest house label="Gasthaus"</Value>
   <Value>guide label="Fremdenführer"</Value>
   <Value>holiday flat label="Ferienwohnung"</Value>
   <Value>horsecar label="Pferdewagen"</Value>
   <Value>hospital label="Krankenhaus"</Value>
   <Value>hostel label="Herberge"</Value>
   <Value>hotel garni label="Hotel Garni"</Value>
   <Value>ice cream parlor label="Eisdiele"</Value>
   <Value>internet café label="Internet café"</Value>
   <Value>jewellery label="Juweilier"</Value>
   <Value>kindergarten label="Kindergarten"</Value>
   <Value>lake label="See"</Value>
   <Value>landmark label="Wahrzeichen"</Value>
   <Value>laundry label="Wäscherei"</Value>
   <Value>library label="Bibliothek Bücherei"</Value>
   <Value>mall label="Einkaufszentrum"</Value>
   <Value>market label="Markt"</Value>
   <Value>massage label="Massagesalon"</Value>
   <Value>memorial label="Denkmal"</Value>
   <Value>mining museum label="Bergbaumuseum"</Value>
   <Value>monastery label="Kloster"</Value>
   <Value>mosque label="Moschee"</Value>
   <Value>mountain label="Berg/Gebirge"</Value>
   <Value>museum label="Museum"</Value>
   <Value>music label="Musik- /Konzerthalle"</Value>
   <Value>nunnery label="Nonnenkloster"</Value>
   <Value>nursery label="Kinderkrippe"</Value>
   <Value>office label="Büro"</Value>
   <Value>open air museum label="Fleilichtmuseum"</Value>
   <Value>opera house label="Opernhaus"</Value>
   <Value>organisation label="Organisation"</Value>
   <Value>pagoda label="Pagode"</Value>
   <Value>palace label="Palast"</Value>
   <Value>park label="Park"</Value>
   <Value>pastry shop label="Konditorei"</Value>
   <Value>pharmacy label="Apotheke"</Value>
   <Value>photo store label="Fotoladen"</Value>
   <Value>plantation label="Planzung Plantage"</Value>
   <Value>practice label="Brauchtum"</Value>
   <Value>police label="Polizei"</Value>
   <Value>port label="Hafen"</Value>
   <Value>post label="Post"</Value>
   <Value>pub label="Kneipe"</Value>
   <Value>public transport label="Öfftl. Verkehrsmittel"</Value>
   <Value>pyramid label="Pyramide"</Value>
   <Value>quad bike label="Quad-Bike"</Value>
   <Value>relief organisation label="Wohltätigkeitsorganisation"</Value>
   <Value>religious site label="Religiöse Stätte"</Value>
   <Value>restaurant and bar label="Bar und Restaurant"</Value>
   <Value>school label="Schule"</Value>
   <Value>shipping company label="Seefracht-Unternehmen"</Value>
   <Value>shop label="Geschäft"</Value>
   <Value>shuttle bus service label="Shuttlebus-Service"</Value>
   <Value>sight label="Aussichtspunkt"</Value>
   <Value>spa label="Heilbad Quellen"</Value>
   <Value>sport label="Sport"</Value>
   <Value>sports shop label="Sportgeschäft"</Value>
   <Value>stadium label="Stadion"</Value>
   <Value>stud label="Gestüt Pferdestall"</Value>
   <Value>subway label="U-Bahn"</Value>
   <Value>summit label="Gipfel"</Value>
   <Value>surgery label="Arztpraxis"</Value>
   <Value>swimming pool label="Schwimmbad"</Value>
   <Value>synagogue label="Synagoge"</Value>
   <Value>taxi label="Taxi (stand)"</Value>
   <Value>temple label="Tempel"</Value>
   <Value>theater label="Theater"</Value>
   <Value>theme park label="Themenpark"</Value>
   <Value>tour operator label="Ausflugsveranstalter"</Value>
   <Value>tourism authority label="Topurismusbehörde"</Value>
   <Value>tourist information label="Touristeninformation"</Value>
   <Value>tower label="Turm"</Value>
   <Value>town hall label="Rathaus"</Value>
   <Value>train label="Zug"</Value>
   <Value>tram label="Straßenbahn"</Value>
   <Value>travel agency label="Reisebüro"</Value>
   <Value>university label="Universität"</Value>
   <Value>waterfall label="Wasserfall"</Value>
   <Value>youth hostel label="Jugendherberge"</Value>
   <Value>zoological garden label="Tierpark"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Sinnvolle Gruppierung der Typen

Das Eindeutschen der Begriffe macht die aufgeblähte Liste nicht kürzer, für ein vernünftiges Handling sollte sie zumindest gruppiert werden, selbst im Vorgriff auf weitere Entwicklungen der Wikimedia. Meine Vorschläge dazu orientieren sich im Gegensatz zur oben dargestellten Liste an der Benennung der Kategorien unserer Grundskelette, weil ich mir davon in fernerer Zukunft zumindest die Option auf programmtechnischen Zusatznutzen verspreche. Insoweit weicht die hiesige Anordnung in Einzelfällen von der oberen ab.

Wie schon von Nati in der Lounge erwähnt, ist auch mir schon bei der Übersetzung der bisher vorhandenen Typen schlecht geworden. Ich stelle daher die einzelnen Codeschnipsel für "meine" Gruppen einzeln dar, um sie kommentieren zu können. Sie sollten aber nacheinander lauffähig sein.

Methode 1: Bilden von Untergruppen

Die folgende Methode müsste dem zugrundeliegenden xml-Skript von renvvar konform laufen. Sie bewirkt aber wohl, dass im Vorlage-Master, den sie ja programmiert, neun einzelne Blöcke vorangestellt werden. Fände ich persönlich immer noch übersichtlicher, als die ungeordnete Liste bisher und bringt den Benutzer vielleicht eher dazu, über eigene Einordnungen nachzudenken. Die ohnehin desolate Optik wird sie kaum weiter zerstören.

Nachteil ist, dass sie versehentliche Mehrfacheingaben nicht unterbinden kann. Könnte durch einen Text mit dem <help>-Tag kommentiert werden, diese werden m.E. ohnehin nicht sichtbar ausgegeben (jedenfalls habe ich die "Statusleiste" bisher übersehen). Vermutlich wird schlimmstenfalls einfach der letzte zugeordnete Inhalt des Typs <type> übernommen (hoffe ich).

Folgende Blöcke würde ich vorschlagen (entsprechen m.W. exakt der obigen Liste):

Mobilität

<Group name="Mobilität" label="Aus dem Bereich Transport/Verkehr wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
    <Value>airline label="Fluggesellschaft"</Value>
    <Value>airport label="Flughafen"</Value>
    <Value>airport service label="Flughafendienste"</Value>
    <Value>public transport label="Öfftl. Verkehrsmittel"</Value>
    <Value>bus label="Busgesellschaft"</Value>
    <Value>subway label="U-Bahn"</Value>
    <Value>car rental label="Mietwagen"</Value>
    <Value>car sharing label="Car Sharing"</Value>
    <Value>bike rental label="Fahrrad-/Motorradverleih"</Value>
    <Value>port label="Hafen"</Value>
    <Value>ferry label="Fähre"</Value>
    <Value>shipping company label="Seefracht-Unternehmen"</Value>
    <Value>taxi label="Taxi (stand)"</Value>
    <Value>train label="Zug"</Value>
    <Value>tram label="Straßenbahn"</Value>
    <Value>shuttle bus service label="Shuttlebus-Service"</Value>
  </Parameter>
   <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
</Group>

Kommentar: Flughäfen und Häfen gibt es schon, (Bus-) Bahnhöfe aber nicht. Warum Public Transport, wenn es Metro, Tram, Taxi, Zug und Bus gibt. Mir fehlt der Begriff Seilbahn/Cable Car.

Sehenswürdigkeiten

<Group name="Sehenswürdigkeiten" label="Unter touristischen Sehenswürdigkeitem wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>landmark label="Wahrzeichen"</Value>
	<Value>castle label="Schloß"</Value>	
	<Value>cathedral label="Kathedrale"</Value>
	<Value>cemetery label="Friedhof"</Value>
	<Value>church label="Kirche"</Value>
	<Value>fort label="Festung"</Value>
	<Value>garden label="Garten"</Value>
	<Value>lake label="See"</Value>
	<Value>memorial label="Denkmal"</Value>
	<Value>museum label="Museum"</Value>
	<Value>mining museum label="Bergbaumuseum"</Value>
	<Value>open air museum label="Fleilichtmuseum"</Value>
	<Value>monastery label="Kloster"</Value>
	<Value>mosque label="Moschee"</Value>
	<Value>nunnery label="Nonnenkloster"</Value>
	<Value>pagoda label="Pagode"</Value>
	<Value>palace label="Palast"</Value>
	<Value>park label="Park"</Value>
	<Value>pyramid label="Pyramide"</Value>
	<Value>religious site label="Religiöse Stätte"</Value>
	<Value>sight label="Aussichtspunkt"</Value>
	<Value>synagogue label="Synagoge"</Value>
	<Value>temple label="Tempel"</Value>
	<Value>tower label="Turm"</Value>
	<Value>waterfall label="Wasserfall"</Value>
	<Value>zoological garden label="Tierpark"</Value>
	<Value>building label="(hist.) Gebäude"</Value>
	<Value>bunker label="Bunker"</Value>
	<Value>bridge label="Brücke"</Value>
	<Value>botanical garden label="Gartenanlage"</Value>
	<Value>archaeological site label="Ausgrabungsstätte"</Value>
	<Value>aquarium label="Unterwasserwelt"</Value>
	<Value>cave label="Höhle"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
</Group>

Kommentar: Warum muss ein Bergbaumuseum extra sein, drei verschiedene Bezeichnungen für Garten/Park. Auch Denkmal, Schloß, Festung, Wahrzeichenläßt sich zusammenfassen. Eine Brücke wird auch ein Denkmal sein, wenn sie extra erwähnt wird. Was ist an einem Frauenkloster gegenüber einemKloster so besonders?

Eine schwierige Schnittstelle ist die Abgrenzung zu Aktivitäten. Ich habe mich hier von der Vorstellung einer genau definierbaren Örtlichkeit leiten lassen. (Bsp.: Eine Höhle ist ein mittels Eingang genau definierbarer Ort, der eine Sehenswürdigkeit markiert, ein Berg dagegen eine Fläche, dem man im Rahmen einer Aktivität begegnet. Bei summit=Gipfel wird es da schon schwieriger, allerdings wäre der zumindest auch ein Berg).

Aktivitäten

<Group name="Aktivitäten" label="Für Aktivitäten oder Ausflugsziele wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>cultural organization label="Kulturorganisation"</Value>
	<Value>amusement park label="Vergnügungspark"</Value>
	<Value>cinema label="Kino"</Value>
	<Value>music label="Musik- /Konzerthalle"</Value>
	<Value>opera house label="Opernhaus"</Value>
	<Value>festival label="Festival/Festspiele"</Value>
	<Value>discotheque label="Diskothek"</Value>
	<Value>club label="Club"</Value>
	<Value>theater label="Theater"</Value>
	<Value>circus label="Zirkus"</Value>
	<Value>sport label="Sport"</Value>
	<Value>ballooning label="Ballonfahren"</Value>
	<Value>dive center label="Tauchbasis"</Value>
	<Value>gallery label="Galerie"</Value>
	<Value>golf label="Golfplatz"</Value>
	<Value>quad bike label="Quad-Bike"</Value>
	<Value>stud label="Gestüt Pferdestall"</Value>
	<Value>swimming pool label="Schwimmbad"</Value>
	<Value>spa label="Heilbad Quellen"</Value>
	<Value>stadium label="Stadion"</Value>
	<Value>travel agency label="Reisebüro"</Value>
	<Value>tour operator label="Ausflugsveranstalter"</Value>
	<Value>summit label="Gipfel"</Value>
	<Value>mountain label="Berg/Gebirge"</Value>
	<Value>theme park label="Themenpark"</Value>
	<Value>practice label="Brauchtum"</Value>
	<Value>plantation label="Planzung Plantage"</Value>
	<Value>horsecar label="Pferdewagen"</Value>
	<Value>guide label="Fremdenführer"</Value>
   </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
</Group>

Kommentar: Was soll "Musik" bedeuten, wenn es Diskotheken, Clubs etc. gibt. Thematisch wäre vielleicht eine Untergruppiereung Outdoor/Indoor oder Kultur/Sport gut. natürlich ist der Liste (wie auch den anderen) anzusehen, welche speziellen Sportler an ihr herumgedoktert haben, also eben Biker.

Grundsätzliche Möglichkeit als erster Ansatz eines hierauf fokussierten Skeletts wäre m.E.

* Kultur

Lokales Brauchtum

Film/Fernsehen

Theater und Musik

* Outdoor

am Meer

an Land

* Sport

Wassersport

Luftsport

Fortbewegung

Ballsport

Einkaufen

<Group name="Einkaufen" label="Für Einkaufsmöglichkeiten wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	 <Value>shop label="Geschäft"</Value>
	<Value>mall label="Einkaufszentrum"</Value>
	<Value>market label="Markt"</Value>
	<Value>bakery label="Bäckerei"</Value>
	<Value>book seller label="Buchladen Landkarten"</Value>
	<Value>delicatessen label="Spezialitätengeschäft"</Value>
	<Value>jewellery label="Juweilier"</Value>
	<Value>antiquarian label="Antiquitäten"</Value>
	<Value>pastry shop label="Konditorei"</Value>
	<Value>photo store label="Fotoladen"</Value>
	<Value>bike shop label="Fahrradgeschäft"</Value>
	<Value>sports shop label="Sportgeschäft"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Kommentar: Shop gibt es, verschiedene Varianten von Shop auch, Supermarkt wäre für Selbstversorger vielleicht dagegen eine wichtigere Information. Ebenso die Frage nach lokalem Kunsthandwerk.

Bei Delikatessen und Märkten ist die Abgrenzung zu Küche evtl. problematisch

Küche

<Group name="Küche" label="Für Orte zum Essen und Trinken wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>restaurant</Value>
	<Value>restaurant and bar label="Bar und Restaurant"</Value>
	<Value>bar label=""</Value>
	<Value>cafe label="Cafe Kaffehaus"</Value>
	<Value>snack bar label="Snack Bar Kiosk"</Value>
	<Value>cooking class label="Kochkurse"</Value>
	<Value>ice cream parlor label="Eisdiele"</Value>
	<Value>beer garden label="Biergarten"</Value>
	<Value>pub label="Kneipe"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Kommentar: Wo ist der Unterschied zwischen Restaurant, Bar und Restaurant&Bar? Für den asiatischen Raum fände ich zumindest "food market" noch wichtig.

Unterkunft

<Group name="Unterkunft" label="Für einzelne Wohnmöglichkeiten wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>hotel label="Hotel"</Value>
	<Value>pension label="Pension"</Value>
	<Value>boarding house label="Gasthaus"</Value>
	<Value>guest house label="Gasthaus"</Value>
	<Value>hostel label="Herberge"</Value>
	<Value>hotel garni label="Hotel Garni"</Value>
	<Value>holiday flat label="Ferienwohnung"</Value>
	<Value>campsite label="Campingplatz"</Value>
	<Value>bed and bike label="B and B"</Value>
	<Value>appartment label="Appartments"</Value>
	<Value>youth hostel label="Jugendherberge"</Value>
	<Value>alpine hut label="Berghütte"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Kommentar: Zumindest nach meinem Sprachgefühl kann ich nicht zwischen Pension, Boarding House, Guest House unterscheiden, auch die Abgrenzung zum hostel wird knapp. Bed&Bike habe ich schon mit Absicht in B&B übersetzt. Neuere Formen wie Couchsurfing oder Untervermietung fehlen dagegen.

Gesundheit

<Group name="Gesund bleiben" label="Für Einrichtungen der Gesundheitsvorsorge wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>clinic label="Gesundheitszentrum"</Value>
	<Value>hospital label="Krankenhaus"</Value>
	<Value>surgery label="Arztpraxis"</Value>
	<Value>dentistry label="Zahnarzt"</Value>
	<Value>massage label="Massagesalon"</Value>
	<Value>pharmacy label="Apotheke"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Kommentar: Klinik und Hospital m.E. identisch

Praktische Hinweise

<Group name="Klarkommen" label="Für Behörden oder Hilfsinstitutionen wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>administration label="Verwaltung(sgebäude)"</Value>
	<Value>bank label="Bank/Geldwesen"</Value>
	<Value>police label="Polizei"</Value>
	<Value>post label="Post"</Value>
	<Value>organisation label="Organisation"</Value>
	<Value>tourism authority label="Topurismusbehörde"</Value>
	<Value>tourist information label="Touristeninformation"</Value>
	<Value>relief organisation label="Wohltätigkeitsorganisation"</Value>
	<Value>office label="Büro"</Value>
	<Value>library label="Bibliothek Bücherei"</Value>
	<Value>laundry label="Wäscherei"</Value>
	<Value>internet café label="Internet café"</Value>
	<Value>government label="Regierung (sgebäude)"</Value>
	<Value>embassy label="Botschaft"</Value>
	<Value>consulate label="Konsulat"</Value>
	<Value>town hall label="Rathaus"</Value>
	<Value>company label="Unternehmen"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Kommentar: Auch wieder ausufernd, aber oft wichtig. Wo will ich klarkommen: Örtliche Behörden (reichen meistens zwei, je nach Hierarchie im zugeordneten Namensraum), was soll Büro, eine Tourismusbüro-Angabe reicht wohl (auch according zur Hierarchie)

Lernen

<Group name="Lernen" label="Für Ausbildungseinrichtungen wählen Sie aus">
  <Parameter name="type" label="Typ" length="50">
	<Value>college label="Hochschule"</Value>
	<Value>university label="Universität"</Value>
	<Value>school label="Schule"</Value>
	<Value>kindergarten label="Kindergarten"</Value>
	<Value>nursery label="Kinderkrippe"</Value>
  </Parameter>
  <Parameter name="subtype" label="Untertyp" length="50">
   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
   <Value>budget</Value>
   <Value>midrange</Value>
   <Value>upmarket</Value>
  </Parameter>
 </Group>

Kommentar: Was Kindergärten/-krippen in WV suchen, ist mir unklar. Wir sind ein Reiseführer und kein Wgweiser für Aussteiger. Was eher fehlt, sind Schulen für Sprachkurse dgl. Hochschule bleibt Hochschule.

Methode 2: Verschachtelung des <group>-Tags

Ein Argument gegen Methode 1 wäre die Bildung von 9 einzelnen Blocks im VM, obwohl sie vermutlich angesichts dessen Verschachtelung kaum auffallen. Daher noch folgende Denkvariante, die aber m.E. nicht der Intention des xml-Autors entspricht und vermutlich nicht funktioniert.

Sie könnte aber der xml-Auszeichnungssprache entsprechen, daher nur kurz das Denkmuster dargestellt (muss wer anderes beurteilen). Gezeigt wird mögliches Anfang und Ende der obigen Codeschnipsel in anderem Gesicht, diese müssten also im Einzelnen korrigiert werden:

<Group name="Art der Einrichtung" label="Wählen Sie eine der folgenden Obergruppen für die Einrichtung">
  <Parameter name="Mobilität" label="Aus dem Bereich Transport/Verkehr wählen Sie aus" length="50">
	<Group name="G1" label "dieser Auswahlliste">
		<Parameter name="type" label="Typ" length="50">
			<Value>airline label="Fluggesellschaft"</Value>
			<Value>airport label="Flughafen"</Value>
			<Value>airport service label="Flughafendienste"</Value>
			<Value>public transport label="Öfftl. Verkehrsmittel"</Value>
			<Value>bus label="Busgesellschaft"</Value>
			<Value>subway label="U-Bahn"</Value>
			<Value>subway label="U-Bahn"</Value>
			<Value>car rental label="Mietwagen"</Value>
			<Value>car sharing label="Car Sharing"</Value>
			<Value>bike rental label="Fahrrad-/Motorradverleih"</Value>
			<Value>port label="Hafen"</Value>
			<Value>ferry label="Fähre"</Value>
			<Value>shipping company label="Seefracht-Unternehmen"</Value>
			<Value>taxi label="Taxi (stand)"</Value>
			<Value>train label="Zug"</Value>
			<Value>tram label="Straßenbahn"</Value>
			<Value>shuttle bus service label="Shuttlebus-Service"</Value>
	   </Parameter>
	   <Parameter name="subtype" label="Untertyp" length="50">
		   <Help>Untertyp der Einrichtung, mehrere Typen können mit Komma getrennt aufgeführt werden</Help>
		   <Value>budget</Value>
		   <Value>midrange</Value>
		   <Value>upmarket</Value>
	  </Parameter>
  
  (....)analog oben
  
  <Parameter name="Lernen" label="Für Ausbildungseinrichtungen wählen Sie aus" length="50">
	<Group name="G9" label "dieser Auswahlliste">
		<Parameter name="type" label="Typ" length="50">
			values der Gruppe 
	</Group>
  </Parameter>
</Group> 

Auf diese Weise könnten die oben dargestellten Gruppen in einem einzigen Block bei der Ausgabe im VM zusammengefasst werden, wenn es denn funktionieren sollte. Der optische Mehrwert ist fraglich.

Methode 3: Bildung von Reihenfolgen

Auf welcher Stufe der bisher dargestellten Wege auch immer man sich bewegen möchte, sinnvoll wäre natürlich immer, die einzelnen Typ-Items in einer sinnvollen Reihenfolge erscheinen zu lassen. Wäre das möglich, könnte man es notfalls sogar vorübergehend bei Schritt 1 (Übersetzung) belassen. Mit der Einfügung von Leerzeilen,

<Value> label="Zwischenüberschrift" </Value>

könnten sich evtl. "Not-"Überschriften einfügen lassen, die aber nach meinem Überblick im derzeitigen Schema nicht optisch besonders dargestellt werden können. Finde ich aber ungenügend.

Im Rahmen meiner Erkundungsreise bin ich aber auch auf die Wikimedia-API Seite gestoßen, von der ich nur 5% kapiert habe. Wenn ich aber das hier Wichtige richtig interpretiert habe, gibt es nur die Möglichkeit einer auf- oder absteigenden (hier alphabetischen) Ordnung oder alternativ die Möglichkeit, jedes vorhandene Item namentlich (also [1] [5] [13][7] [27]) zu benennen. Diese Möglichkeit fällt aber im Zuge zukünftiger Änderungsmöglichkeiten selbstverständlich aus, weil dann immer das Grundskript umprogrammiert werden müßte.

Sollte aber jemand eine Möglichkeit wissen, wie der Interpreter im Rahmen des vorliegenden xml-Skripts dazu gebracht werden kann, die einzelnen values des Felds "type" in derselben Reihenfolge auszulesen, wie sie im Skript stehen, könnte man einige oben dargestellte Punkte entweder einfacher oder komfortabler gestalten.

Subtypes weiter ausbauen

Aus den Kommentaren zu den vorgeschlagenen Gruppierungen wird schon deutlich, dass das Feld "type" eigentlich eine Unter-Gruppierungsmöglichkeit benötigt, die aber dem jeweiligen "type" zugeordnet sein müsste. Die in der <help>-Funktion es derzeitigen Skripts dargestellte Möglichkeit, mehrere Subtypes durch Kommasetzung anhängen zu können, verstehe ich so nicht. Ich glaube nicht, dass das Templateskript diese Möglichkeit hergibt.

Gleichwohl sollten wir darüber nachdenken, diesem Bereich zwei hierarchische Kategorien zuzuordnen. Ich würde eher dazu neigen, langfristig einen neuen Parameter <topic> in der v-card einzuführen, dem untergeordnet die vorhandenen <type> folgen können. <Topic> entspräche dann den vorhandenen Kategorien des Skelettbaums wie schon oben ausgeführt. <subtype> könnte erhalten bleiben für in der Disk schon angeregte weitere Spezifizierungen (Bsp.: Küche ital./dt./lokal/polynesisch oder Sport Wasser/Luft/Ball/Fortbewegung).

Ausblick

Ich habe die Warnungen von Roland auf unserer WikiLounge-Diskussion schon verstanden. Auch nach einem langen Text habe ich letztlich möglichst weiter verarbeitbare, kleinere Änderungen im Rahmen des bisherigen Systems vorgeschlagen. Die v-card oder eine Folge-Instanz wird zwar auch für andere Wiki-Projekte wichtig (und damit auch für uns nutzbar) sein, für uns hier in der WV kann sie aber ein Herzstück darstellen, genauso wie die oft beweinte, von mir aber nicht mehr erlebte Ortsdatenbank, die immer durch die Zeilen geistert.

Ich will mir auch nicht mehr Arbeit machen als unbedingt nötig, und der Artikel hier ist mehr meiner eigenen Ungeduld geschuldet als dem Glauben an ein offensichtlich noch nicht "marktfreifes" Produkt. Wie schon eingangs erwähnt, bin ich auch nicht böse, wenn es bei einer persönlichen Spielwiese verbleibt.

Gerade im Vorgriff auf mögliche Weiterentwicklungen bei Wikimedia oder Wikidata erscheint es mir aber umso dringlicher, eine Diskussion darüber zu führen, was für uns eine in allen Wikis einsetzbare v-card leisten soll und kann. Wie sonst soll eine darauf fußende Datenbank denn sonst geplant werden, die global einsetzbar sein soll? Dass das momentan dazu eingesetzte XML-Skript nur ein Notnagel sein kann, ist ja offensichtlich.

Daher Zusatzfragen (da hier neu eingestellt, werden sie ja vielleicht beantwortet):

• Können solche Formulare wie der VM im Rahmen der Wikpedia-Familie auch in anderen Skriptsprachen programmiert werden, z.B. php oder welche Sprachen sind zugelassen bzw. empfehlenswert (ggü. allfälligen Änderungen der API-Schnittstelle, ohne zu wissen, was das bedeutet, bin IT-teilleistungsestört).
• Wer wo beschäftigt sich wie mit Zusammenhängen der v-card bei Wikimedia. Wir sind ja ein Wiki, das muss ja irgendwo einsehbar sein.
• Was passiert in unserer vorausgreifenden Datenbank-Planung, wenn jemand in der "freien" Vorlage einfach auf Blöd „type=Siebter Himmel“ eingibt. Wird das zunächst relevant (wo) gespeichert oder nicht (entspricht ja nicht den Vorgaben für "Type")

--Gastromartini (Diskussion) 05:28, 10. Mai 2013 (CEST)

Die Vorschläge zur Eindeutschung sind technisch fehlerhaft. Innerhalb eines <Value> kann es kein label und keine Anführungszeichen geben. Und ein <Value>bus label="Busgesellschaft"</Value> ist inhaltlich was völlig anderes als <Value>bus</Value>. Gruppierungen sind in den Listen nicht vorgesehen, die Gruppen haben eine andere Funktion. Da die Untertypen, subtypes, von den Typen abhängen, müssten hier Softwareerweiterungen her, die die Listen austauschen.

PHP lässt sich nur in Erweiterungen einsetzen. Da wir den Server nicht selbst betreiben, ist dieser Weg fast aussichtslos. Die einzigen Werkzeuge, die uns zur Verfügung stehen, sind JavaScript und Lua. Bei Wikimedia beschäftigt sich niemand mit der vCard. Mit der vCard müssen wir uns selbst beschäftigen – und mit wir meine ich fast immer DerFussi und ich. Deshalb auch der Hinweis, dass wir uns mit den WikiData-Leuten zusammensetzen müssen, um zu klären, was wie möglich ist. Die sind über ein halbes Jahr in Verzug, so dass es kaum auf die Schnelle geht. Davon abgesehen, dass WikiData noch gar nicht in Wikivoyage implementiert ist.

Der 7. Himmel ist kein Problem. Nicht umsonst haben wir in der XML-Datei eine Liste möglicher Einträge vorgegeben. Bei der Übertragung in eine Datenbank werden alle Einträge auf Konsistenz geprüft. --RolandUnger (Diskussion) 07:37, 10. Mai 2013 (CEST)

Ganz ehrlich, ich verstehe diese Diskussion überhaupt nicht. Zum einen sind das Herzstück immer unsere Artikel und nicht die vCard. Zum anderen muss unser Fokus auf die Leser gerichtet sein, denen irgendwelche Untertypern relativ gleichgültig sein dürften. Außerdem versuchen wir seit Wochen, die vCard etwas populärer zu machen, aber mit dieser Diskussion vergraulen wir auch noch den letzten neuen Autor. Eine nicht-alphabetische Unordnung der Types ohne Unterteilung hilft da wirklich nicht, und ohne eine Standardisierung zusammen mit den anderen Sprachversionen wäre das in meinen Augen ohnehin nur ein zum Misserfolg führender Sonderweg, den ich mir gerne ersparen möchte. Mein Motto: Nichtstun ist besser als mit viel Mühe nichts schaffen. -- Berthold Mail Talk 08:10, 10. Mai 2013 (CEST)

Hallo, Guten Morgen, bitte mal alle schütteln

Ich habe mich mit dem Thema beschäftigt, gerade weil DerFussi und Roland offenbar die einzigen sind. Wenn das so bleiben soll, habe ich auch kein Problem damit. Ich wollte nur Verwaltungsarbeit abnehmen, die aus den dargestellten Skripts per c/p übernehmbar und korrigierbar wären, soweit für OK befunden, und nur so war es gedacht.

Dass aber ein Type "Bus" oder "Music" einfach schwach ist, weil ihn jeder so übersetzen kann, wie er gerade will, habe ich ja in meinen Kommemntaren schon zum Ausdruck gebracht. Vor allem, wenn zehn gleichlautende, andere Items existieren. Was heißt Bus denn dann: Haltestelle, Reisebus, Überlandbus, Stadtlinie, oder was? Noch schlimmer bei "Musik".

Danke an Roland, dass er zumindest die Fragen beantwortet hat. Wenn wir aber alleine bleiben werden mit der v-card, dann sollten wir uns eben auch damit beschäftigen. Muss ich aber nicht dabei sein, die Artikelbearbeitung macht mir mehr Spaß. Ich empfinde den Hintergrund der bisherigen Reaktionen jedenfalls als "eher störend".

Sinnnlos ist die Diskussion jedenfalls nicht. Jedem neuen Autor wird zu Recht die Wichtigkeit der v-cards ins Stammbuch geschrieben. Und ich betrachte mich auch als "neuen" Autor. Neue Artikel kommen aber nur von neuen Autoren, und erst danach kommt die Leserschaft. Wenn diese neuen Autoren dann aber brav versuchen sollten, die v-card zu benutzen, wird ihnen schlecht, weil sie ihre eigentlich nur einzusetzende Empfehlung unter fast hundert oft nicht nachvollziehbaren Kategorien einordnen sollen.

Aber wenn alles gut ist und jeder zufrieden, macht einfach weiter so, herzliche Grüße--Gastromartini (Diskussion) 06:01, 11. Mai 2013 (CEST)

Hallo Gastromartini. Vielleicht hast du es auch falsch verstanden. Wir können aus der VCard nicht mehr herausholen. Deine Vorschläge funktionieren leider technisch nicht. Es muss ein anderes Werkzeug als der VM her. Und wir haben keine Programmiermöglichkeiten, da uns der Server nicht gehört. Einzige Möglichkeit wäre derzeit die Programmierung eines besseren Formulars auf einem externen Server. Das könnte immerhin dann den fertigen Code in die Zwischenablage des Users kopieren. Wenn du Möglichkeiten und Kenntnisse hast, nur zu. Ich habe mir diese Aufgabe schon mal vorgemerkt, baue aber noch an den detaillierten Seitenstatistiken. -- DerFussi 09:11, 11. Mai 2013 (CEST)

Yep, alles in Ordnung. War nach einer langen Nachtschicht gestern auch selber überreizt, dann muss ich manchmal gröber auf den Putz hauen. Bis die tage, --Gastromartini (Diskussion) 04:18, 12. Mai 2013 (CEST)

Weniger ist oft mehr

Ich habe die gesamte Diskussion nur grob gesichtet. Die Details sind mir zu mühsam. Die vCard begrüße ich im Allgemeinen zur möglichst einheitlichen Darstellung der Einträge. Man sieht auch auf einen Blick, ob noch wichtige Teildaten fehlen. Sehr gut. Die endlose Liste der Typen ist aber aus meiner Sicht eine Sackgasse. Ich würde vorschlagen, auch um weitere ergebnislose Diskussionen zu vermeiden, die Typen auf die Namen der Abschnitte zu beschränken. Der Aufwand steht sonst in keinem Verhältnis zu einem eventuellen späteren Nutzen. Wie oft werden wohl Auswertungen oder Abfragen gestellt werden? Ich glaube eher selten. Man muss nicht alles machen, was möglich ist. Gute Artikel über interessante Reiseziele und Reisethemen sind viel wichtiger, als die Zeit mit solchen Dingen wie Typen (und den endlosen Diskussionen darüber) zu verschwenden. Da alle anderen Sprachversionen lediglich die Typen "see, do, buy, eat, drink und other" verwenden, würde ich vorschlagen, dass auch wir zukünftig nur diese Typen verwenden. Bei einer eventuell sinnvollen Erweiterung der Liste um möglichst wenige Typen sollte man auch an die anderen Sprachversionen denken. Der Grund ist einfach: eine Software, die auf die verschiedenen Sprachversionen zugreift (PoiMap, LocDB, ArtMap usw.) muss sonst für jede Sprachversion angepasst werden. Das ist auf Hobby-Basis kaum zu schaffen. -- Joachim Mey2008 (Diskussion) 21:07, 4. Jun. 2013 (CEST)

Ich denke, dass wir bereits jetzt soweit wie möglich differenzieren sollten. Es ist z.B. schon wichtig, ob man auf einem Zeltplatz oder in einem Hotel übernachtet. Gegenüber Wikimapia sind wir auch noch recht sparsam. Die genannten Typen see, do … usw. verlinken immer auf dieselbe Vorlage Listings. Hauptaugenmerk war sicher, dass die alten Tags möglichst maschinell in neue Vorlagen übertragen werden mussten. Ich bin erst einmal froh, dass man Vorlagen benutzt. Mehr wird sicher auch dort irgendwann folgen. --RolandUnger (Diskussion) 07:52, 5. Jun. 2013 (CEST)

(Bearbeitungskonflikt)

Einer der Hintergründe waren die Symbole für Karten, welche ja schon immer für größere Differenzierung ausgelegt waren. Spätestens wenn in der Zukunft Wikidata läuft (etwas früher) und die WMF eigene Kartendienste anbietet (etwas später), bzw. Drittanbieter auf die Daten zugreifen wollen, wird der Ruf nach der Differenzierung definitiv kommen (müssen). Dann wollen sicher Leser in der Datenbank nicht nur nach "Schlafen" suchen, sondern viele werden speziell nur Jugendherbergen oder Pensionen suchen, dann wollen Leser sicher auch zwischen Moscheen und Kirchen unterscheiden wollen. Immerhin haben wir konsequent englischsprachige Typen beutzt. Der Software sollte das eigentlich egal sein. Ich kann natürlich nur über meine gefrickelte LcDB sprechen. Der sind Sprachversionen und verwendete Schriften egal. Die frisst alles. Die muss nur wissen, wie die Vorlage, bzw. das Tag in der jeweiligen Sprachversion heißt. Für dein PoiMap Skript brauchen wir doch nur ein Mapping von Typ nach Farbe, oder? Dann reicht doch ein kleines Array im PHP-Skript, welches auf dem Kartenserver läuft. Das kann auch gleich wenn erforderlich, die russischen und griechischen Bezeichnungen aufnehmen.

// :de
$color['Kirche'] = orange;
$color['Moschee'] = orange;
$color['Jugendherberge'] = blau;

// :ru
$color['церковь'] = orange;
$color['мечеть'] = orange;

Oder wenn man die Sprachversionen individuell halten möchte halt mehrdimensional (so mache ich es). Ist auch die bessere Wahl:

// :de
$color['de']['Kirche'] = orange;
$color['de']['Moschee'] = orange;
$color['de']['Jugendherberge'] = blau;

// :ru
$color['ru']['церковь'] = orange;
$color['ru']['мечеть'] = orange;

Und mit $color[$type]] hast du immer die aktuelle Farbe im Skript zur Verfügung. Den Code mit dem Mappping-Array würde ich in eine eigene PHP-Datei auslagern und im Meta-Wiki einstellen. Dort können alle Autoren der Sprachversionen bei Bedarf selbst Typen nachtragen. Du guckst nur, ob sich was getan hast, und kopierst das aktuelle File auf den Server. Ich habe das übrigens mit den LocDB-Sprachfiles so gemacht Bsp.: für ru: ru:Участник:DerFussi/locdb. Die haben das für mich übersetzt. Daher würde ich die Type-nach-Color-Umwandlung nicht hier als komplizierte und auch Ressorcen fressende Vorlage implementieren. -- DerFussi 07:58, 5. Jun. 2013 (CEST)

@DerFussi: Die Vorlage TypeToColor habe ich nur erstellt, um eine passende Farbe im Artikeltext darstellen zu können. Eine Umsetzung der Typen auf dem Map-Server ist eine andere Sache und könnte leicht z.B. wie von dir beschrieben realisiert werden. Als Kompromiss könnte ein weiterer Parameter in die vCard eingefügt werden: Icon = (see, do, usw.). Dann könnten die Typen unverändert so bleiben. -- Mey2008 (Diskussion) 08:18, 5. Jun. 2013 (CEST)

Wenn man das über einen "icon=" Parameter regelt wäre der auch unabhängig vom "type=", imho ein Vorteil weil ich mir durchaus verschiedene icons vorstellen könnte für ein und denselben type z. B. mountain könnte als "see" oder "do" bezeichnet werden je nachdem ob man sich den anschauen will oder raufklettert. LG --Nati aus Sythen _Diskussion 09:00, 5. Jun. 2013 (CEST)

Mit dem Icon könnte man ein Symbol aus Commons nutzen, wie unsere Kartensymbole - hätte was - die gehen aber nicht so klein. Mey2008 hat natürlich recht, im Wiki hilft obiges nicht. Mir ist aber immer noch die Vorlage zu kompliziert. Was ist mit CSS-Klassen? Einfach die Typbezeichnung auch zusätzlich als Klasse (mit einem Präfix "type_" in das Tag eintragen. Die commons.css ist schnell angepasst. Frisst kein Brot und keine Performance. -- DerFussi 11:51, 5. Jun. 2013 (CEST)

Ich habe probehalber mal die Vorlage POI auf CSS umgestellt. So steht weniger Code drin, und die Vorlage zur Typkonvertierung könnte entfallen. Wenn's ok ist, trage ich die Farben für alle Typen nach. -- DerFussi 08:26, 7. Jun. 2013 (CEST)

Läuft für die im CSS erfassten Typen super. Bei fehlenden Typen (z.B. durch Tippfehler) wurde bisher "fuchsia" als default-Background ausgegeben. Vielleicht ist eine entsprechende Eintragung im CSS möglich? Die Farbnamen selbst ( red = red und andere ), die in TypeToColor aufgeführt sind, müssten aus Kompatibilitätsgründen auch eingetragen werden. Sie wurden/werden in Themenartikeln oft verwendet. Die Map-Anwendung habe ich bereits entsprechend vorbereitet und werde sie dann an die CSS-Eintragungen anpassen. -- Joachim Mey2008 (Diskussion) 09:28, 7. Jun. 2013 (CEST)

Fuchsia ist auch jetzt Standard. Sie steht drüber in der Klasse ".poi" drin und wird bei Vorhandensein von Typen bei Bedarf überschrieben. -- DerFussi 09:55, 7. Jun. 2013 (CEST)

Ein kleines Problem ist noch aufgetaucht: Die Leerzeichen in den Typen. Wir werden POI neuschreiben und komplett in Lua verfassen. Dann geht auch ein Suchen und Ersetzen des Leerzeichens. Ich werde auch separate Styles für die Druckausgabe schreiben - momentan sieht man ja nichts, weil die Hintergrundfarben nicht gedruckt werden. Ich schaue mir das gleich mal an. -- DerFussi 12:06, 7. Jun. 2013 (CEST)

Die Druckausgabe zeigt bei mir die Hintergrundfarben. Das ist abhängig von der Einstellung des eigenen Browsers: Optionen: [x] Hintergrundfarben drucken. -- Joachim Mey2008 (Diskussion) 12:35, 7. Jun. 2013 (CEST)

Nur würde ich mich ungern darauf verlassen, dass alle Browser, die die WV-Nutzer so haben, diese Funktionalität auch besitzen. Ich habe einer derartigen Knopf bei meinem Browser nicht gefunden. Der PDF-Export des Wikis bring die Hintergrundfarben auch nicht. -- DerFussi 13:03, 7. Jun. 2013 (CEST)

Hintergrund(Farben/Bilder) einschalten: MS EX / Firefox: drucken / Seite einrichten [x] Hintergr... drucken; Chrome: drucken, Optionen(unten): Hintergr... drucken, Safari: Im Druckdialog auf "Kopien und Seiten" klicken, dann fast zuunterst auf "Safari" und das Gewünschte auswählen. -- Zu PDF gleich mehr. -- Joachim Mey2008 (Diskussion) 13:35, 7. Jun. 2013 (CEST)

Und hier eine für mich perfekte [Vorlage:Mapserver/x/img/hornburg.pdf PDF-Ausgabe] mit Hintergrundfarben und ausgeblendeten Webadressen. -- Webadressen ergeben im Ausdruck keinerlei Sinn. Man kann sie nur verwenden, wenn man online ist. Dann ist es aber viel einfacher, die Wikivoyage-Seite aufzurufen und auf den entsprechende Link zu klicken als die teilweise ellenlangen Webadressen einzutippen. Die Ränder habe ich auch absichtlich weggelassen, wegen mobiler Offline-Nutzung. -- Joachim Mey2008 (Diskussion) 13:46, 7. Jun. 2013 (CEST)

Einen [Vorlage:Mapserver/x/img/hornburg-map.pdf Stadtplan] als PDF gibt's natürlich auch. -- Mey2008 (Diskussion) 13:57, 7. Jun. 2013 (CEST)

Bloss wie hast du das Dokument erzeugt? Mit deinem Rechner und einem installierten PDF-Drucker? Ich vermute, die meisten Nutzer nehmen die PDF-Export-Funktion links in der Navileiste - erst recht die Leute, die unterwegs und nicht am eigenen Rechenr sind. Oder sie nutzen die Buchfunktion, die aus mehreren Artikeln ein Buch zusammenstellt. Ich befürchte, da wird es nicht mehr funktionieren. -- DerFussi 14:18, 7. Jun. 2013 (CEST)

Leerzeichen in den Typen

Zitat: Ein kleines Problem ist noch aufgetaucht: Die Leerzeichen in den Typen. Das sehe ich nicht als großes Problem. Werte einfach nur das erste Wort der Typen als class aus. Die Worte sind bis auf wenige Ausnahmen unterschiedlich. Und die wenigen, die mit dem gleichen Wort beginnen (bike shop, bike rental u.ä.) bekommen sowieso das gleiche Icon. - Oder liege ich da falsch? -- Joachim Mey2008 (Diskussion) 14:06, 7. Jun. 2013 (CEST)

Mit dem ersten Wort kann man sicher leben. --RolandUnger (Diskussion) 14:22, 7. Jun. 2013 (CEST)

Das geht ja auch nur mit ordentlicher Stringbearbeitung und ist mit Bordmitteln nicht zu erledigen. Die (hier nicht installierten) Stringfunktionen könnten das leisten. Ich bin aber eher dafür, wenn man an komplexen Vorlagen noch mal ansetzt, gleich auf das mächtigere Lua umzusteigen, und es ein für alle mal ordentlich zu machen. -- DerFussi 14:25, 7. Jun. 2013 (CEST)

Keine Panik - es funktioniert auch so. Ich habe mal auf Hornburg beim Hornburg-Hostel "hotel garni" als Type eingetragen. Funktioniert im Artikel als "hotel", wie ich es mir auch erhofft hatte. Die Karte bring ich kurzfristig in Ordnung. -- Joachim Mey2008 (Diskussion) 18:03, 7. Jun. 2013 (CEST)

Karte funktioniert jetzt auch. Mini Tippfehler im CSS lime nicht line! -- Mey2008 (Diskussion) 19:10, 7. Jun. 2013 (CEST)

Sichtbarkeit der v-card im Fließtext

Was mich ehrlich gesagt etwas stört, ist, dass die einer v-card zugeordneten Infos wie Fließtext ausgegeben werden. Erstens sind sie für mögliche Folgenutzer schwer erkennbar (o.K., das wollen wir ja ohnehin nicht weiter forcieren), zweitens finde ich aber, dass die hier dem automatisch hervorgehobenen Hauptobjekt (type=name) zugeordneten Infos sich vom nachfolgenden Fließtext erkennbar abgrenzen sollten. Linker Hand zugeordntete Info zum Objekt, rechts folgt Textverlauf. Gerade der type descriptions am Schluss der v-card gestaltet diesen Übergang sehr fließend. Manche Autoren machen das gut, andere weniger. Die fehlende Transparenz, was ist noch v-card, was Text, stört mich in jedem Fall.

Mir ist schon bewusst, dass die Texte im Fortlauf von poi und anderen Gestaltungsformen eigentlich keine weitere grafische Unterscheidungsmöglichkeit mehr zulassen. Trotzdem fände ich eine Unterscheidungsmöglichkeit sinnvoll. Vielleicht ginge ja für die type=name untergeordneten types wenigstens eine nahe an der Textfarbe orientierte Schriftfarbe wie Dunkelgrau. LG--Gastromartini (Diskussion) 04:42, 27. Jun. 2013 (CEST)

Es gibt auch schon andere Design-Ideen. Kannst gern e mit einsteigen:

• Beispiel (ff)

Parameter „map“ liefert falsche Farbe für die Nummern

Wenn ich den (undokumentierten?) Parameter map verwende, um eine Nummer für die Karte zu generieren, dann werden die Nummern rosarot, obwohl sie in der Karte selbst dann die richtige Farbe bekommen. Zu beobachten z.B. im Artikel Lustenau. Ich finde die Integration der Poi-Vorlage in die VCard ein großartiges Feature und fände es schade, wenn es daran scheitert, die vCard-Type (museum, restaurant …) in die Poi-Type (see, eat …) umzusetzen. Notfalls vielleicht einfach einen zusätzlichen Parameter „maptype“ in die VCard-Vorlage einbauen? Ich denke aber, dass auch der schon einmal versuchte Ansatz mit der Vorlage EaseType zum Ziel führen müsste und natürlich viel eleganter wäre. --Reinhard Müller (Diskussion) 10:36, 12. Sep. 2013 (CEST)

Doku für map steht auf der to-do-Liste, aber da steht viel. Gut, rückt nach oben. Zu deiner Info: in der vCard wird der Parameter type momenan noch nicht ausgewertet, ist so ein Vorgriff auf künftige Dinge, daher etwas stiefmütterlich behandelt. Alles, was map nicht auswerten kann, erhält auf der WV-Ebene die Farbe fuchsia. Roland hat zwar daran gebastelt, die Farben für den Kartenserver zu korrigieren, aber er ist in den nächsten Tagen nur sporadisch erreichbar. Am besten ist es daher, du ersetzt vorläufig mal museum und gallery durch see. Mehr kann ich dir leider momentan nicht sagen. -- Berthold Mail Talk 10:57, 12. Sep. 2013 (CEST)

Ich hab mal kurz probiert und ich denke, dass es so wie in Benutzer:Reinhard Müller/VCard und Benutzer:Reinhard Müller/EaseType funktionieren müsste. Natürlich müsste jemand die ganzen VCard-Typen in EaseType aufnehmen und zu den passenden POI-Typen zuordnen. Wenn ich darf, kümmere ich mich gerne darum, genauso wie um die Vervollständigung der Dokumentation. --Reinhard Müller (Diskussion) 12:21, 12. Sep. 2013 (CEST)

Klar, momentan ruft vCard die Vorlage Poi auf. Du schaltest EaseType dazwischen. Ehrlich gesagt, mir hat davor gegraut. Wir sind eigentlich froh um jeden, der solche Arbeiten leisten kann. Meinetwegen darfst du das gerne vervollständigen. Bevor wir das offiziell übernehmen, sehen wir es uns nochmal an, Begründung siehe Wikivoyage:Vorlagen ändern. -- Berthold Mail Talk 12:40, 12. Sep. 2013 (CEST)

Na dann bitte ich mal um Begutachtung: Benutzer:Reinhard Müller/VCard und Benutzer:Reinhard Müller/EaseType. Aus ersteren würde ich natürlich nur den Aufruf der neuen Übersetzungs-Vorlage übernehmen, letztere könnte man z.B. auch als Vorlage:VCard/Type2PoiType oder sowas anlegen, da sie ja wirklich nur innerhalb von VCard verwendet wird. Bitte um Bescheid, sobald ich das „scharf schalten“ kann. --Reinhard Müller (Diskussion) 14:06, 12. Sep. 2013 (CEST)

Klasse gemacht. Und typisch, wie immer. "hotel" und "pension" liefern die dunkelblaue Farbe von "sleep", nur "sleep" selber natürlich nicht. Das sind Kleinigkeiten, die mir auch immer mal passieren. Deswegen erst kontrollieren, könnte sonst ärgerlich sein! Siehe Seite Benutzer:Balou46/Testseite3. Aber das hast du schnell korrigiert, dann sehen wir es nochmal an. -- Berthold Mail Talk 14:40, 12. Sep. 2013 (CEST)

Danke für das sehr schnelle Feedback! „sleep“, „go“, „see“ etc. waren nicht in der Liste der möglichen Typen für VCard (habe ich aus dem XML geholt). Aber du hast recht, sollte sicherheitshalber hinein. Habe ich jetzt nachgeholt. --Reinhard Müller (Diskussion) 14:47, 12. Sep. 2013 (CEST)

Jetzt passt es. Ich denke, jetzt kannst du es fertigstellen. -- Berthold Mail Talk 15:02, 12. Sep. 2013 (CEST)

Ist erledigt. Dokumentation habe ich auch aktualisiert. Danke für's Ergänzen der Kategorie. --Reinhard Müller (Diskussion) 15:51, 12. Sep. 2013 (CEST)

Erledigt? Bei der folgenden vCard ist die Nummernfarbe rosa und der Click auf die Nummer bringt für das Bild eine Error-Meldung. Was habe ich falsch gemacht (bin Anfänger). 50.867910.82451 Ratskeller Mühlberg, Markt 15, 99869 Drei Gleichen. Tel.: +49(0)36256 86313, Mobil: +49(0)162 9842081 . Der Ratskeller liegt am Markt im Gebäude der ehemaligen Gemeindeverwaltung. Die Küche ist bodenständig und regional ausgerichtet bei günstigen Preisen. Gastraum (50 Pl.), Saal (120 Pl.), Bauernstube (40 Pl.) Geöffnet: Mi Ruhetag. Check-in: 10 Uhr.letzte Änderung: keine Angabe --Gruß Claus (Diskussion) 16:39, 18. Aug. 2014 (CEST)

Die Farbe wird nicht durch den Parameter map festgelegt (nur die Nummer), sondern durch den Typ, z.B. type=restaurant. --RolandUnger (Diskussion) 16:58, 18. Aug. 2014 (CEST)

Danke für den Hinweis. --Gruß Claus (Diskussion) 22:45, 18. Aug. 2014 (CEST)

Es wäre ein großer Vorteil, wenn neue Typen, wie Museum, Kirche (church) und Parks eingeführt werden, die sich auch farblich unterscheiden. Ich habe mich in letzter Zeit damit beholfen, dass ich bei den Museen vor der Zahl ein m gesetzt hatte, z.B.: m1. Ich habe aber immer noch keine Lösung, wie ich das Gebäude des Museums und die Museumseinrichtung selbst in der Karte darstelle, obwohl sie die gleichen Koordinaten haben sollten, dann aber durch ein oranges Plus angezeigt werden. Bei den Zielen von Wander- und Radfahrwegspunkten mit der Sehenswürdigkeitsbeschreibung tritt die gleiche Problematik auf. Die Farben von see und buy (kaufen) kann ich nur schwer unterscheiden. ich finde es besser, see bekäme ein kräftiges rot und die Kirchen ein violet. Museen könnten die Farbe von see übernehmen und Parks bekämen ein kräftiges grün. -- Pedelecs (Diskussion) 11:17, 1. Nov. 2014 (CET)

hideCoords keine gute Idee

Der Parameter hideCoords war wohl keine gute Idee, weil sie zu kurz fasst. Als die vCard ins Leben gerufen wurde, dienten die Koordinaten nur der Anzeige. Erst viel später sind die Pois hinzugekommen. Nun muss man die Koordinaten auch angeben, wenn man sie eigentlich nicht angezeigt bekommen haben möchte. Jetzt gibt es vier verschiedene Anzeigemodi, die auseinander gehalten werden müssen: Beides anzeigen, nur Poi, nur Koordinate oder gar nichts. Bei der Überarbeitung werde ich wohl den Parameter show einführen mit den Werten all (Standard), poi, coord und none. hideCoords wird es dann nicht mehr geben bzw. hat dann keine Funktion. Deshalb sollte auf hideCoords verzichtet werden. --RolandUnger (Diskussion) 12:33, 26. Okt. 2014 (CET)

Wann kann man mit den Änderungen rechnen? Ich muß es dann wohl überall, wo ich es eingefügt hatte, wieder entfernen. Ich hatte es auch mal hier öffentlich weitergegeben, weil ich die Ausgabe der Koordinaten in den vCards wirklich störend fand. --Zaunkönig (Diskussion) 09:20, 1. Nov. 2014 (CET)

Ich werde es in den nächsten Tagen bewerkstelligen. --RolandUnger (Diskussion) 09:35, 1. Nov. 2014 (CET)

Ich finde die Ausgabe der Koordinaten auch störend und möchte vorschlagen, diese in der Grundeinstellung wegzulassen. -- Pedelecs (Diskussion) 10:51, 1. Nov. 2014 (CET)

Es wurde bereits mehrfach mitgeteilt, dass jeder mit einem Helferlein für sich die Darstellung der Koordinaten ausblenden kann. Die ursprüngliche Definition der Koordinaten in der vCard war die, sie in jedem Fall anzuzeigen, und nur dafür sollten sie angegeben werden. Daran hat sich mit der Einführung der Pois auch nichts geändert, denn wir hätten bereits zu dieser Zeit Hunderte Seiten umstellen müssen. Und eine Diskussion über die Änderung und ihre Folgen hat es nie gegeben. Jeder, der nun Koordinaten für Pois einfügt, weiß das und kann sie bei Bedarf unterdrücken. Viele Leser brauchen Koordinaten, insbesondere in Gebieten, in denen es keine anderen Orientierungsmöglichkeiten gibt. Und nur Koordinaten, die da sind, lassen sich unterdrücken. Koordinaten, die fehlen, kann man nicht herbeizaubern. D.h., die Grundeinstellung wird man so beibehalten müssen. Jetzt geht es nur noch darum, einen möglichst effizienten Weg der Implementation zu finden. Damit haben die Programmierer ausreichend zu tun.

Und es gibt noch ein anderes Problem. Wir planen zukünftig, dass Pois automatisch durchnummeriert werden können. Damit entfällt der Parameter map, und wir brauchen ein anderes Instrumentarium, um Pois anzeigen zu können. --RolandUnger (Diskussion) 18:21, 1. Nov. 2014 (CET)

Der Parameter show ist wirksam. Jetzt kümmern wir uns um die automatische Nummerierung. --RolandUnger (Diskussion) 19:47, 1. Nov. 2014 (CET)

Beschreibender Text

Um die Einrichtung ein wenig genauer zu beschreiben, kann description verwendet werden. Dieser Text erscheint im erzeugten Abschnitt jedoch leider erst ganz am Ende, nach den Öffnungszeiten, den Eintrittspreisen und den Koordinaten. Besser ist es doch aber, zuerst die kurze Beschreibung zu lesen. Danach, falls ich mich überhaupt entscheide zur Einrichtung zu gelangen, sollten die geografischen Informationen im Text stehen. Ich würde die Anordnung von description unmittelbar nach type geeigneter finden. -- theway (Diskussion) 15:35, 19. Feb. 2015 (CET)

Das klingt sinnvoll. Da dies sicher viele interessiert, schlage ich vor, dass du deine Frage in der Wikivoyage:Lounge stellst. -- FriedhelmW (Diskussion) 16:13, 19. Feb. 2015 (CET)

Die Meinungen zu dieser Problematik sind sehr geteilt, und das Problem viel zu komplex. Einige Angaben wie z. B. Angabe von Name und Adresse in nichtlateinischen Buchstaben müssen noch eingefügt werden. Es muss auf allen Geräten (Webbrowser, mobile Geräte, Druckausgabe, Kiwix) brauchbar dargestellt werden. Selbst bei kurzen Texten findet man dann im Smartphone nicht mehr die Anschrift. Zum anderen muss es technisch umgesetzt werden. Dazu muss ein Modul her, der einen Code produziert, die all die gewünschten Voraussetzungen mitbringt; von einer einfacheren Eingabemaske abgesehen. Dazu fehlt uns die Zeit und die Manpower. Und eine Erhebung zum Nutzerverhalten. In allen anderen Sprachversionen wird übrigens auch die hier verwendete Reihung verwendet: es die technischen Daten und dann die Beschreibung, die dann beliebig lang sein kann. --RolandUnger (Diskussion) 06:41, 20. Feb. 2015 (CET)

Vielleicht habe ich mich doch nicht gut ausgedrückt. Ich meine z. B.:

52.5085213.364911 Gemäldegalerie, Stauffenbergstraße 40. Tel.: +49 30-266 424 242. Die Berliner Gemäldegalerie zeigt Bestände alter europäischer Malerei vom 13. bis zum 18. Jahrhundert. Geöffnet: geöffnet: Di+Mi 10-18, Do 10-20, Fr+So 10-18 Uhr. Preis: 10 €, ermäßigt 5 €.letzte Änderung: keine Angabe

oder alternativ:

 m7  Gemäldegalerieletzte Änderung: keine Angabe - Die Berliner Gemäldegalerie zeigt Bestände alter europäischer Malerei vom 13. bis zum 18. Jahrhundert. Stauffenbergstraße 40, Tel.: +49 30-266 424 242. geöffnet: Di+Mi 10-18, Do 10-20, Fr+So 10-18 Uhr. 10 €, ermäßigt 5 €. (52.50852, 13.36491Gemäldegalerie52° 30′ 31″ N 13° 21′ 54″ O)

Das wäre doch lediglich ein Verschieben der description-Ausgabe. Nichtlateinische Buchstaben hätten hierauf doch keine Auswirkung? Also ich meine kein spezielles Eingabefenster. --theway (Diskussion) 22:57, 23. Feb. 2015 (CET)

Bug: Kein Facebook-Link bei vorhandenem leeren Parameter url

Sind in einer Vcard sowohl der Parameter facebook (mit Wert) als auch der leere (sic!) Parameter url vorhanden, wird der Facebook-Link nicht im Reiseführer angezeigt. Das ist nicht ergonomisch, da nicht erwartungskonform. --4omni (Diskussion) 08:03, 2. Dez. 2015 (CET)

Ist behoben. Danke für den Hinweis. -- FriedhelmW (Diskussion) 11:05, 2. Dez. 2015 (CET)

Danke für die schnelle Behebung. Noch ein Bug: Ein Parameter google (mit Wert) wird als Link nicht angezeigt. Gruß --4omni (Diskussion) 12:42, 2. Dez. 2015 (CET)

Und twitter und skype funktionieren auch nicht. Roland, warum hast du die in die Doku geschrieben? -- FriedhelmW (Diskussion) 15:37, 2. Dez. 2015 (CET)

Habe facebook geändert und google und twitter hinzugefügt, erstmal als Text-Link. Skype geht wohl noch nicht. -- FriedhelmW (Diskussion) 15:58, 2. Dez. 2015 (CET)

Ich hatte google und twitter erst einmal als Platzhalter eingebaut, weil ich mir noch nicht klar war, wohin damit in der Ausgabe. Das muss ich mir noch überlegen, wird sicher erst nächstes Jahr. Der facebook-Link sollte erst einmal nur dann erscheinen, wenn ein regulärer Link fehlt. Beim Rest würde ich von der Angabe im Text absehen, sieht nämlich fürchterlich aus. Das muss man sicher mit Symbolen realisieren. Was Skype anbetrifft, fehlt hier noch die Unterstützung in der Mediawiki-Software. Gegenwärtig sammle ich erst einmal Ideen für die Neugestaltung der vCard. Die Neugestaltung wird aber ohne Modul-Programmierung nicht mehr gehen. Gegenwärtig würde ich von Erweiterungen der (alten) vCard absehen. Aber ihr könnt eure Ideen gern mit in die Liste eintragen. --RolandUnger (Diskussion) 16:51, 2. Dez. 2015 (CET)

Habe die vCard auf Symbole (mit 16 Pixel) für Facebook, Google+ und Twitter umgestellt. -- FriedhelmW (Diskussion) 17:39, 2. Dez. 2015 (CET)

Wikivoyage . so sieht es aus.letzte Änderung: Dez. 2015 (Angaben möglicherweise veraltet)

Danke für deinen Einsatz. Der Parameter google scheint zu funktionieren, facebook leider nicht mehr. In deinem Beispiel wird auch twitter nicht angezeigt. Gruß --4omni (Diskussion) 19:55, 2. Dez. 2015 (CET)

Der Facebook-Link wird auf dem dunkelblauen f-Icon verlinkt, Twitter auf dem hellblauen Symbol. -- FriedhelmW (Diskussion) 20:03, 2. Dez. 2015 (CET)

Da sind (außer g+) keine Icons, in welchem Blauton auch immer. --4omni (Diskussion) 20:17, 2. Dez. 2015 (CET)

Könntest du bitte einen Screenshot machen und mir per Mail schicken? -- FriedhelmW (Diskussion) 20:24, 2. Dez. 2015 (CET)

Danke, ist angekommen. Probier doch mal die Seite neu zu laden mit angehängtem

?action=purge

Etwas ratlos -- FriedhelmW (Diskussion) 21:03, 2. Dez. 2015 (CET)

Getestet, aber ohne Erfolg. Zu sehen sind nur die Kommata ohne Icon. Es gibt auch keinen Platzhalter für eine evtl. nicht runtergeladene Datei. --4omni (Diskussion) 21:13, 2. Dez. 2015 (CET)

Das Problem besteht leider unverändert fort. --4omni (Diskussion) 08:09, 9. Dez. 2015 (CET)

Hast du einen Werbeblocker installiert? -- FriedhelmW (Diskussion) 08:14, 9. Dez. 2015 (CET)

Habe ich. Der meldete mir aber null blockierte Elemente für diese Seite. Jetzt habe ich ihn testweise dennoch für diese Seite abgeschaltet und muss feststellen, dass die beiden fehlenden Symbole nun sichtbar sind. Tja, da muss ich mal auf die Suche gehen … Danke, --4omni (Diskussion) 09:20, 9. Dez. 2015 (CET)

Fehlermeldung bei 1800... Nummern

Mir fällt auf, daß bei Angabe einer free call Nummer sowohl im Quickbar als auch von der vCard eine Fehlermeldung kommt (zur Ansicht im Artikel drin). Konkret angemotzt wird die fehlende Ländervorwahl. Das ist insofern unsinnig, als daß es meines wissen keine Telephongesellschaft gibt, die Anrufe aus dem Ausland auf free call Nummern zuläßt. --Zenwort (Diskussion) 21:38, 10. Sep. 2017 (CEST)

Die Landesvorwahl muss trotzdem davor stehen. Die Algorithmen zur Ergänzung unvollständiger Nummern haben ihre Grenzen. In Australien ist dies noch besonders gemein: Die meisten Vorwahlen besitzen eine Vornull, auf die getestet wird. Und Telefonnummern, die mit einer 1 beginnen sind nicht nur auf das Land beschränkt. Auch weiß ich nicht, ob man die Nummern nicht doch aus dem Ausland verwenden kann, aber dann z.B. kostenpflichtig. --RolandUnger (Diskussion) 07:11, 11. Sep. 2017 (CEST)

Referenzierung

Gemeldet in Phabricator (?)
Task T140092

Ist es möglich, im Artikel identische POIs zu referenzieren (z.B. Kloster ist als Sehenswürdigkeit genannt, dann in der Altstadt erwähnt, ...)? Ähnlich z.B. der Referenzierung von Quellenangaben mit ref name=… --theway (Diskussion) 11:02, 15. Sep. 2017 (CEST)

Das ist leider noch nicht möglich: dies müsste eigentlich der Kartographer unterstützen. Eine entsprechende Fehlermeldung ist schon erfolgt. Das kann aber dauern. Vielleicht fällt mir noch eine andere (JavaScript-basierte) Lösung ein. Bisher gab es die Vorlage {{Marker}}, die so etwas bewerkstelligt hatte, aber nur für die alten Karten. Da ich selbst ein Interesse daran habe, wird es nicht vergessen. --RolandUnger (Diskussion) 17:27, 15. Sep. 2017 (CEST)

Fehler beTypen

Moin, ich habe bei type= den Parameter pension eingefügt s.o. dieser hat einen Fehler "unbekannter Tpye" erzeugt, habe ihn durch den Parameter guest house ersetzt danach war es gut. --Toen96 (Diskussion) 14:53, 4. Nov. 2017 (CET)

Wir benutzen pension nicht, weil es das Wort so im Englischen nicht gibt. Die Wahl von guest house ist besser. Der Fehler wird absichtlich angezeigt, damit wir ihn auch finden. --RolandUnger (Diskussion) 19:16, 4. Nov. 2017 (CET)

Optimal wäre boarding house. Siehe auch Vorlage:VCard/XML. --RolandUnger (Diskussion) 08:33, 5. Nov. 2017 (CET)

Eingruppierung "boat rental"

Sollten Einträge des Typs "boat rental" nicht lieber der Gruppe "do" (grauer Marker) statt "go" (roter Marker) zugeordnet werden? In den allermeisten Fällen mietet man ein Boot doch zum bloßen Zeitvertreib bzw. als besondere Aktivität, und nicht um von A nach B zu kommen. Bei Fahrradvermietungen bin ich mir unsicher, die können je nach Kontext mal zu Mobilität (="go"), mal zu Aktivitäten (="do") passen. Ich tendiere aber dazu, sie bei "go" zu belassen. --Bujo (Diskussion) 19:18, 11. Jan. 2018 (CET)

Hallo @RolandUnger: Hättest du etwas dagegen, das zu ändern? Beste Grüße, --Bujo (Diskussion) 18:51, 3. Feb. 2018 (CET)

Alternativer Name

@RolandUnger:: Könnte man zukünftig auch den Alternativen Namen als Fallback von Wikidata holen - dort das "auch bekannt als"? Habe das jetzt paar mal gehabt, dass es gerade bei thailändischen Stränden und sowas einen englischen Namen und auch einen transkribierten thailändischen Namen gibt. Habe es auf WD als Alias eingetragen und würde sich hier gut als alternativen Namen machen. Spricht was dagegen? Bsp.: Bamboo Beach -- DerFussi 11:47, 2. Jul. 2018 (CEST)

Formal spräche nichts dagegen. Aus meiner Sicht ist es aber unmöglich, die Alias-Einträge zu bewerten, weil nicht zu erfahren ist, warum sie hier genannt werden. Manchmal sind es nur einfach Schreibvarianten, es gibt aber auch Übersetzungen, die eigentlich an anderer Stelle zu finden sind, frühere Namen ohne Angabe, wann sie gültig waren, fehlende Ränge etc. Diese Unterscheidungen kann Software wohl nicht leisten. --RolandUnger (Diskussion) 06:51, 3. Jul. 2018 (CEST)

Dann isses natürlich blöd. Da werde ich das lieber noch per Hand hier mit eintragen. -- DerFussi 07:14, 3. Jul. 2018 (CEST)

Typ "Schnorcheln"

@Gwadainfo: hatte hier neben Tauchen auch Schnorcheln vorgeschlagen. Wird auch oft mit eigenem Symbol dargestellt. -- DerFussi 19:01, 22. Sep. 2018 (CEST)

Schon vor Stunden erledigt. Er hat mit auch schon gedankt. --RolandUnger (Diskussion) 19:18, 22. Sep. 2018 (CEST)

Kann man diese Symbole irgendwie in die Artikel oder vCards einbinden? --Gwadainfo (Diskussion) 19:35, 22. Sep. 2018 (CEST)

Typ-Vorschläge

Soweit ich sehe gibt es keinen passenden Typen für Coworking-spaces (welche auch als empfohlen benannt sind) und Raststätten/Autohöfe, die vor allem in den BAB Artikel vorkommen und derzeit nicht richtig getypt sind. Könnten diese bitte eingeführt werden? Danke schön --Naseweis520 (Diskussion) 17:12, 6. Jan. 2019 (CET)

• type = service area für Raststätte, Autohof
• type = coworking space für Coworking Space.

Ich habe mich an den Begriffen in OpenStreetMap orientiert. --RolandUnger (Diskussion) 07:23, 9. Jan. 2019 (CET)

Keine Wikidata-Übernahme

• 52.0853335.1475972 Rietveld-Schröder-Haus (Rietveld Schröderhuis), Prins Hendriklaan 50. E-Mail: rsh@centraalmuseum.nl ​ . 1924 erbaut im Stil De Stijl. Das Rijksmonument gehört seit 2000 zum Weltkulturerbe der UNESCO. Geöffnet: Di-So 11-17 Uhr, April-Oktober Fr bis 21 Uhr. Preis: 14 €. Online-Terminreservierung erforderlich!. letzte Änderung: keine Angabe

Warum wird die Adresse nicht aus Wikidata übernommen? --4omni (Diskussion) 08:50, 26. Apr. 2019 (CEST)

Weil sie fehlt. Die VCard benutzt die Property Adresse. Dort ist die komplette Adresse einzugeben. Mehrere Einträge (bevorzugt englisch und LAndessprache) sind möglich. Deine Properties werden von der VCard nicht unterstützt. Auch aus dem Grunde, dass Straße fast nie auf WD als eigenes Objekt existieren. -- DerFussi 08:58, 26. Apr. 2019 (CEST)

Siehe auch -- DerFussi 09:03, 26. Apr. 2019 (CEST)

Wenn ich auf Wikidata wikidata:Property:P6375 eingeben will, heißt es erläuternd "[…]Verwende P669, wenn die Straße als separates Element bekannt ist". Dem bin ich gefolgt. Nur dumm, wenn andere Wikimedia-Projekte das anders sehen. Also gehe ich zurück zur lokalen Eingabe in der VCard? --4omni (Diskussion) 09:59, 26. Apr. 2019 (CEST)

Aus meiner Sicht sollte den WD-Leuten klargemacht werden, dass die wikidata:Property:P6375 zusätzlich angegeben werden sollte, d. h. dort sollte stehen "[…]Verwende AUCH die P669, wenn die Straße als separates Element bekannt ist". wikidata:Property:P6375 wurde schließlich vor kurzem erst eingeführt, um Adressen ordentlich zu erfassen. Der Nachteil der Straßenvariante ist nämlich auch die, dass man bei der Straße zwar im Label den Namen in Landessprache angeben kann, Hausnummer und PLZ aber nicht in Landessprache darstellbar sind. -- DerFussi 13:46, 26. Apr. 2019 (CEST)

Optionale Parameter

Bei den optionalen Parametern gibt es Differenzen zwischen der Quelltexterfassung, der Erfassung mittels VCard-Editor und der Erfassung über Wikidata. Beispiele:

Instagram: Quelltext:nur möglich, wenn man's weiß, VCard-Editor: Ja, WD: Ja

Google+: gibt es nicht mehr, in Vorlage aber als |google= gelistet, Erfassung im Quelltext und VCard-Editor nicht mehr möglich, WD möglich

Whatsapp: gängiges Kommunikationsmittel, nirgendwo möglich

Könnte das jemand evtl. aktualisieren, erweitern? Gruß --Eduard47 (Diskussion) 11:56, 18. Jul. 2019 (CEST)

Ich versuche, alles so aktuell wie möglich zu halten. Ich kann jedoch nicht ausschließen, dass ich etwas übersehe. vCard/Marker ist äußerst komplex geworden. Leider raubt mir das ständige Aufräumen auf Wikivoyage auch noch viel Zeit. Hinweise zur vCard kann man auch auf meine Diskussionsseite schreiben.

Ich habe die Dokumentation aktualisiert. Google+ gibt es schon lange nicht mehr, deshalb rausgenommen. Der WD-Eintrag hilft hier auch nicht weiter.

Da ich WhatsApp nicht benutze, kann ich nicht sagen, ob sich das überhaupt auf einer Internetseite unterstützen lässt. Ich kenne auch kein praktisches Beispiel. WhatsApp ist ja ein browserunabhängiger Messengerdienst. In Wikidata gibt es auch keine Property dafür, so dass ich nicht so recht weiß, was ich da einbinden soll. Bei Skype gibt es zumindest eine Internetanbindung in Form eines standardisierten Internetprotokolls. Wenn man seinen WhatsApp-Account mit einer Telefonnummer verbindet, so kann man die unter Telefonnummern eintragen. --RolandUnger (Diskussion) 17:27, 18. Jul. 2019 (CEST)

Danke Roland für's Aufräumen. Da ich WhatsApp auch nicht nutze, kann ich leider auch nicht so recht weiterhelfen. Ich weiß nur, dass das über die Mobilfunknummer läuft. Aber nicht jeder kann über seine Mobilfunknummer WhatsApp-Nachrichten empfangen, er muss angemeldet sein. Deshalb nützt die normale Angabe der Mobilfunknummer für diesen Zweck nichts. Ich bin über die Homepage der Jugendherberge Hamburg darauf gestoßen und wollte dieses in die vCard eingetragen. Ich stelle mir das wie folgt vor: In der vCard wird das WhatsApp-Symbol (z.B.: oder ) angezeigt, im Hintergrund ist die Mobilfunknummer mit der Vorlage {{LinkPhone}} hinterlegt. Dadurch könnte man vom Mobilgerät über WhatsApp mit dem anderen Partner kommunizieren. Aber das sind nur meine Vorstellungen. Ob das so machbar ist, kann ich beim besten Willen nicht beurteilen. Vielleicht weiß das ja jemand? Gruß --Eduard47 (Diskussion) 18:09, 18. Jul. 2019 (CEST)

Typo im Titel des vCard-Editors

Bitte korrigieren: "Bearbeitung einer vorhanden Visitenkarte" → "Bearbeitung einer vorhandenen Visitenkarte". Danke, --4omni (Diskussion) 11:20, 23. Apr. 2020 (CEST)

Vielen dank für den Hinweis. Ich habe es korrigiert. --RolandUnger (Diskussion) 19:02, 23. Apr. 2020 (CEST)

Geschütztes Leerzeichen

In einigen Fällen wäre die Verwendung eines geschützten Leerzeichens sinnvoll. Leider ist das nur im Quelltext möglich. Könnte man das Zeichen irgendwo als Sonderzeichen auch im vCard-Editor zur Verfügung stellen um es dann bei Bedarf einfügen zu können (bspw. bei "Preis" oder in der "Beschreibung)? --Eduard47 (Diskussion) 18:15, 12. Sep. 2020 (CEST)

Beim Preis wird das geschützte Leerzeichen bereits beim Drücken einer Währungseinheit mit eingefügt (habe noch \xA0 gegen &nbsp; ausgetauscht, damit besser sichtbar). Ich habe das Zeichen auch in die Liste der Sonderzeichen bei der Beschreibung mit eingefügt. Getestet habe ich mit dem Firefox. --RolandUnger (Diskussion) 06:55, 14. Sep. 2020 (CEST)

Bei mir (Firefox) funktioniert das geschützte Leerzeichen nicht beim Drücken einer Währungseinheit. Ideal wäre es, wenn das Zeichen (ähnlich wie bei der Beschreibung) zusätzlich auch hier separat anklickbar angeboten wäre. Dann könnte man auch bei der nachträglichen Bearbeitung von älteren vCards dieses einfügen. --Eduard47 (Diskussion) 18:37, 5. Jan. 2021 (CET)

Ich habe den Editor nochmals mit dem Firefox getestet, und es funktioniert: es steht auch im Quelltext drin. Ich habe zusätzlich &nbsp; zu den Währungen hinzugefügt. --RolandUnger (Diskussion) 06:58, 7. Jan. 2021 (CET)

In letzter Zeit stelle ich fest, dass vermehrt, auch für Preisangaben, das kurze geschützte Leerzeichen   verwendet wird. Es wird sogar in vorhandenen vCards von m. E. übereifrigen Benutzern das "normale" geschützte Leerzeichen gegen das kurze geschützte Leerzeichen ausgetauscht. In unseren Regeln finde ich dazu keine Hinweise. Im vCard-Editor wird zum Feld "Preis" das normale gesch. Leerzeichen   angeboten. Sollte man dieses weiterhin verwenden, oder wird auch an dieser Stelle zukünftig das kurze   angeboten? In der Beschreibung haben wir es ja schon. Sollte nicht auch in Hilfe:Erstellen einer VCard/Merkmale ein Hinweis dazu stehen? Schön wäre natürlich, wenn auch in Hilfe:Zeilenumbrüche steuern eine eindeutige Regelung zu finden wäre. --Eduard47 (Diskussion) 16:11, 27. Nov. 2021 (CET)

@Eduard47: Eigentlich ist der kurze geschützte Leerraum ein typografisches Luxusproblem. Diesen Leerraum kennen eigentlich nur Schriftsetzer, und er ist im Gegensatz zu   auch für die meisten eher schwer lesbar. Ich denke, dass es für die meisten genügt, den (einfachen) geschützten Leerraum und andere typografische Sonderzeichen (Anführungszeichen) setzen zu können. Wer will und das Knowhow besitzt, kann auch den schmalen Leerraum verwenden. Ansonsten sollte man diese Zeichensetzungen von Bots vornehmen lassen. --RolandUnger (Diskussion) 13:37, 28. Nov. 2021 (CET)

Ich vermute, zu den Übereifrigen zählst zu mich. Ich stimme Roland zu. Es ist ein Luxusproblem. Aber wäre es nutzen möchte, kann es aus meiner Sicht tun. Ich setze sogar häufig noch mehr. So lasse setze ich beim „z. B.“ auch noch ein normal breites geschützes Leerzeichen hintendran. Ich finde es einfach unschön im Lesefluss, wenn Abkürzungen am Zeilenede stehen. Ebenso, wenn beim „Im Jahre 2021“ der Zeilenumbruch vor der Jahreszahl kommt. Deshalb setze ich auch an weiteren anderen Stellen solche Dinger. Allerdings bin ich kein Typografie-Profi, das ist reine perönliche Ästhetik. Schwer lesbar werden Quellexte durch diese Entities allemal, egal ob schmal oder breit oder größer gleich, oder kleiner gleich. Vermeiden lassen sie sich nicht. Selbst wenn sie ein Bot setzt, stehen sie nun mal im Quelltext. Der Wikieditor mit Syntaxhighlight hilft da recht gut. Ich habe auf Hilfe:Zeilenumbrüche steuern das schmale Leerzeichen erwähnt und auch den üblichen Anwendungsfall dargestellt (fixe Abkürzungen und Maßeinheiten). Aus meiner Sicht reicht das. Es ist nicht nötig, den Leuten dass durch eine fixe Regel aufzuzwingen. Ich denke, viele Gelegeheitstipper kennen nicht mal das normale geschützte Leerzeichen. Deshalb habe ich das schmale Leerzeichen auch nie in Diskussionen erwähnt oder gar eingefordert. Ich setze es, wenn ich sowieso gerade irgendwo zugange bin. Ich betrachte es als reinen Nerd-Edit um etwas eh' schon gutes abzurunden. Daher muss es auch nicht der VCard-Editor leisten. Das verwirrt eher mehr. Ich editiere solch nerdige Sachen im Regelfall separat und dann gleich für den ganzen Artikel oder Abschnitt. Für Interessierte: Wikipedia:Technische_Wünsche/Wunschparkplatz#definierte_Bezeichnungen_vor_automatischem_Zeilenumbruch_schützen -- DerFussi 14:25, 28. Nov. 2021 (CET)

Danke Roland, danke Stefan für Eure detaillierten Antworten. Nein Stefan, Du warst nicht gemeint. Ich will hier auch niemanden anprangern, sehe das im Prinzip wie Ihr. Wundere mich nur, wenn in von mir mit dem vCard-Editor frisch erstellten vCards jemand kurze Zeit später das "normale" Leerzeichen gegen ein kurzes austauscht. Dann u. U. im gleichen Zug auch noch die Schreibweise der Preisangaben (12,- € => 12 €) und der Öffnungszeiten (12:00-20:00 => 12-20) ändert. Ich halte nach wie vor die von mir gewählten Formate für die international gebräuchlichsten und für jeden verständlich weil üblich und selbsterklärend. Das macht einfach keinen Spaß. Daher würde ich mir wünschen, dass all dieses irgendwo "geregelt" wäre. Wenn wir als WV ein Corporate Design anstreben (das sollten wir!), dann müssen wir uns auch alle an gewisse Regeln halten. Viele Grüße aus Hamburg. --Eduard47 (Diskussion) 15:52, 28. Nov. 2021 (CET)

Das mit der Uhrzeit sieht wirklich nicht nach mir aus. Da haben wir aber eine Richtlinie auf Hilfe:Angabe von Telefonnummern, Währungen und Öffnungszeiten. Mit den Preisen, nun ja. Glatte Europreise bei Eintritten schreibe ich auch gern ohne Komma und Strich, wenn es keine gemischten Angaben gibt. Wobei ich, wenn ich ein Komma benutze, die zwei Nullen anstatt des Striches präferieren würde. Die Frage ist am Ende auch folgende. Wenn wir es so genau regeln müsste man auch das wieder kontrollieren und fixen - auch Arbeit. Zum anderen muss man immer daran denken, dass es ein Wiki ist. Kein eigener Eintrag ist von Dauer. Wenn einem jemand zielgerichtet hinterhereditiert ist das aber wahrscheinlich unangenehm. Gelegenheitsautoren/Anonyme lesen unsere Regelartikel wahrscheinlich sowieso nicht. Ist es ein Stammautor, kann man sich vielleicht mal persönlich verständigen. Gibt es Stress/Editwars muss man es vielleicht doch in der Community mal regeln. Ich würde unseren derzeitigen Stand eigentlich als ausreichend beschreiben. -- DerFussi 17:12, 28. Nov. 2021 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Hallo Roland, eigentlich hatte ich dieses Thema schon längst als erledigt betrachtet. Trotzdem komme ich noch einmal mit einer Bitte: Ich verwende gerne für neue vCards wie auch für deren Änderungen den vCard-Editor. Dort wird im Feld "Preis" das normale   geschützte Leerzeichen angeboten, das ich dann auch verwende. Schon nach kurzer Zeit wird dieses dann von einem anderen Autor in ein schmales   geändert. Ich würde dieses gerne sofort in der vCard verwenden, wenn es denn im Editor bei den Preisen angeboten würde. Könntest Du dort das "normale" gegen das "schmale" austauschen? Dann würden wir dem m. E. übereifrigen Autor die Arbeit etwas erleichtern. Siehe auch oben, mein Eintrag vom 27. Nov. 2021. Danke schon mal im Voraus. --Eduard47 (Diskussion) 17:22, 15. Jul. 2022 (CEST)

Ergänzung: In Verbindung mit den vorgeschlagenen Währungszeichen wird manchmal das schmale geschützte Leerzeichen gleich mit eingefügt, aber seltsamerweise nur manchmal, meistens erscheint nur das Währungszeichen. Welche Logik dahinter steckt habe ich noch nicht feststellen können. --Eduard47 (Diskussion) 18:46, 17. Jul. 2022 (CEST)

@Eduard47: Ich habe die Leerzeichen ausgetauscht. Ein schmales Leerzeichen wird nur dann automatisch eingefügt, wenn unmittelbar vor dem Währungszeichen eine Ziffer steht. --RolandUnger (Diskussion) 19:45, 17. Jul. 2022 (CEST)

Danke RolandUnger, kein Wunder, dass es bei mir nicht funktionierte. Hatte mir angewöhnt, glatte Beträge immer wie "22,-" anzugeben, gefällt mir irgendwie besser. Gruß Eduard47 (Diskussion) 20:41, 17. Jul. 2022 (CEST)

Bug with phone numbers starting with 0

Hi:

Sorry for writing in English but I'm not sure which is the best place to report. I found what seems a bug with the tollfree parameter (in Spanish tlf_gratuito). As you can check at https://es.wikivoyage.org/wiki/Usuario:Urci_dream/Taller2#Seguridad the number 061 is written in a wrong style and the generated link is prefixed for Germany. Phone numbers starting in zero in Spain are very popular for public services (091, 092, 061, 062...). I guess this is related with template l10n in someway. Thanks. Olea (Diskussion) 13:51, 18. Mär. 2022 (CET)

@Olea: I added the exception of Spanish phone numbers. You can check it with the page of Madrid or any other Spanish sites. But in user namespace it cannot work correctly because the page does not know the country of the site which is necessary to format the phone numbers. It should work if you will move the article to the main namespace and register it in Wikidata. --RolandUnger (Diskussion) 15:20, 18. Mär. 2022 (CET)

Thanks :-) Olea (Diskussion) 19:22, 18. Mär. 2022 (CET)

UNESCO im Vereinigten Königreich

Im Artikel London wird bei Angabe einer Wikidata-ID im UNESCO-Symbol in der vCard entsprechend Modul:CountryData/Geography auf Welterbe/Europa#Vereinigtes Königreich verlinkt. Jedoch wird in der Übersicht statt Vereinigtes Königreich die Bezeichnung Großbritannien genutzt, sodass eigentlich auf Welterbe/Europa#Großbritannien verlinkt werden müsste. Gegebenenfalls könnte das auch für Modul:Unesco relevant sein. --Nw520 (Diskussion) 17:13, 27. Mär. 2022 (CEST)

Danke für den Hinweis. Ich denke, ich werde eine Lösung finden. --RolandUnger (Diskussion) 18:21, 27. Mär. 2022 (CEST)

Ich habe die Landesbezeichnungen im Welterbeartikel an den Rest angepasst. --RolandUnger (Diskussion) 08:05, 12. Apr. 2022 (CEST)

Problem with 112 emergency phone number

Hi:

Sorry for writing in English. We found in ESvoy a problem with the 112 phone number in the {{listing}} template: it output an invalid format number message. I checked in DEvoy and the problem is the same, no matter if the number is got from Wikidata or as a parameter.

Code:

{{listing | name = Emergencias | alt = 112 | type = health | wikidata = Q1061257 | auto = y | url = https://www.juntadeandalucia.es/organismos/presidenciaadministracionpublicaeinterior/areas/interior/emergencias-112/112-GREA-PC/paginas/que-es-emergencias-112-andalucia.html | tollfree = 112 | description = }}

Output:

Emergencias (112). Tel.: 112, Tel. gebührenfrei: 112 ​ .letzte Änderung: keine Angabe Typ ist Gruppenbezeichnung

Am I doing something wrong? Thanks. Olea (Diskussion) 12:08, 20. Apr. 2022 (CEST)

@Olea: Besides the phone number istself - I think, @RolandUnger:, can explain the feature thoroughly - the listings are made for geographically identifiable objects like museums, restaurants etc. not for a service or for just formatting any Wikidata item. I think, the Andalusian emergency website can be linked with the normal Wiki-Link-Markup and the 112 is valid and known within Europe anyway. Emergency calling numbers should be stated in the countries article and this should be enough. In my opinion its the wrong usage of the listing/vcard template here. -- DerFussi 12:41, 20. Apr. 2022 (CEST)

You have to remove the wikidata entry Q1061257, because it belongs to the country of Albania (the first country in the country list P17) and not to Spain. Upto now there are no phone number exceptions for Albania. --RolandUnger (Diskussion) 16:45, 20. Apr. 2022 (CEST)

I added Albania in the exceptions list. But I am not really sure if it is complete. --RolandUnger (Diskussion) 16:59, 20. Apr. 2022 (CEST)

Thanks :) Olea (Diskussion) 22:51, 20. Apr. 2022 (CEST)

ids in vCards

Momentan wird das id-Attribut von vCards jeweils mittels der Anweisung :attr( 'id', 'vCard_' .. mw.uri.anchorEncode( vp.ParMap.givenName.name ) ) erzeugt. anchorEncode hat die Eigenheit, dass es Sonderzeichen kodiert, z. B.: Lorem & Ipsum's Heißer Schwenker → <nowiki>vCard_Lorem_&amp;_Ipsum&#039;s_Heißer_Schwenker</nowiki>.

Beim Überprüfen von Fragment-Verlinkungen ist mir aufgefallen, dass bei Verlinkungen der Form <nowiki>[[Lorem Ipsum#vCard Lorem & Ipsum's Heißer Schwenker]]</nowiki> in wirklich fast allen Fällen Sonderzeichen nicht kodiert werden und daher die Links kaputt sind. Daher die Frage: Bestünde die Möglichkeit Sonderzeichen (bzw. zumindest & und ') in der id nicht zu kodieren? Dafür würde ich Code der Form :attr( 'id', 'vCard_' .. mw.uri.anchorEncode( vp.ParMap.givenName.name ):gsub( '&', '&' ):gsub( ''', "'" ) ) vorschlagen.

In HTML4 galt die Einschränkung, dass ids nur aus Buchstaben, Ziffern, (Doppel)Punkten und Unter- bzw. Bindestrichen bestehen dürfen. Dies wurde mit HTML5 aufgeweicht, wobei stellenweise eine Einschränkung auf ASCII empfohlen wird.

Nw520 (Diskussion) 13:17, 19. Jun. 2022 (CEST)

Ich habe die gsub() eingefügt und hoffe, dass es nun besser funktioniert. Das Problem liegt ja eigentlich in der Mediawiki-Software, die den Ankerteil in Links wie <nowiki>[[Lorem Ipsum#vCard Lorem & Ipsum's Heißer Schwenker]]</nowiki> encoden müsste.

Die Vorlagen {{Marker}} und {{VCard}} besitzen jetzt, wenn eine Wikidata-Id bekannt ist, einen zweiten Anker in der Form vCard_Qxxxx, was aber nur teilweise hilft. --RolandUnger (Diskussion) 14:06, 19. Jun. 2022 (CEST)

Verlinkung der Adresse zur OpenStreetMap-Suche

Wurde eine Verlinkung der Adresse zur OSM-Suche (via Nominatim) schon einmal diskutiert? (Hier finde ich nicht recht etwas. Dies ist's nicht ganz.) Eine Verlinkung ggf. auch nur für Angemeldete könnte vielleicht die tatsächliche Verwendbarkeit der angegebenen Adressen verbessern? Beste Grüße, --Marsupium (Diskussion) 03:13, 4. Aug. 2022 (CEST)

Ich werde mir das Ganze mal überdenken. Bisher gab es dies (im Prinzip) nur im vCard-Editor, um die gesuchte Koordinate zu finden. Wenn die Koordinate vorhanden ist, braucht man so einen Link ja auch nicht. Vielleicht kann man so etwas mit einem Javascript/Helferlein realisieren, weil man damit auch etwas das Problem der Datenschutzregeln umgehen kann. --RolandUnger (Diskussion) 07:10, 4. Aug. 2022 (CEST)

Lehrpfade

Hi!

Unter Hilfe:Erstellen_einer_VCard#Änderungswünsche habe ich gefunden, dass man fehlende "Typen" hier melden sollte. In der Tat vermisse ich den Typ "Lehrpfad". Oder habe ich etwas übersehen? Bebbe (Diskussion) 14:29, 7. Dez. 2022 (CET)

Lehrpfad gibt es noch nicht, lässt sich aber ergänzen. Da der Pfad meist nicht punktförmig ist, habe zumindest ich noch nicht daran gedacht. --RolandUnger (Diskussion) 16:55, 7. Dez. 2022 (CET)

Lieber RolandUnger, herzlichen Dank für Deine schnelle Rückmeldung! Noch finde ich den Lehrpfad noch nicht im Dropdown. Gibst Du hier Bescheid, wenn Du die Erweiterung durchgeführt hast? Herzlichen Dank!!! --Bebbe (Diskussion) 18:22, 7. Dez. 2022 (CET)

UNESCO in USA

Vereinigte Staaten von Amerika#vCard Q274131 verlinkt auf Welterbe/Amerika#Vereinigte Staaten. Im Welterbe-Artikel wird der Abschnitt aber als „USA“ bezeichnet, sodass die Sprungmarke nicht funktioniert. Nw520 (Diskussion) 14:01, 17. Feb. 2023 (CET)

Auf Welterbe/Asien und Ozeanien#Vereinigte Staaten heißt es dann wieder „Vereinigte Staaten“. :/ --Nw520 (Diskussion) 14:04, 17. Feb. 2023 (CET)

Ich habe die Links im Artikel Welterbe/Amerika überarbeitet. --RolandUnger (Diskussion) 13:13, 18. Feb. 2023 (CET)

Links auf Twitter

Die Links auf Twitter sind seit heute unsichtbar, also ohne Logo. Soweit ich das erkennen kann ist das Problem wohl, dass die entsprechende Datei auf Commons umbenannt wurde: commons:File:Logo of Twitter.svg. Das müsste bei uns nachgezogen werden. 2A02:908:121:6600:3096:C2A1:4CE7:781C 11:12, 24. Apr. 2023 (CEST)

Danke für den Hinweis. Das Logo wurde in den letzten Tagen mehr mehrfach umbenannt, und die letzte Umbenennung habe ich nicht mitbekommen. Das Logo sollte wieder sichtbar sein. --RolandUnger (Diskussion) 06:34, 25. Apr. 2023 (CEST)