Wikivoyage talk:Listings/Archive 2016–2017

Again address and hCard microformat

Similarly as it was pointed out at #More on addresses and hcard microformats, but slightly different: currently an address parameter of Template:Listing is rendered as:

<span class="label listing-address">1 Place Gambetta</span>

While as per hCard spec it should be rendered to adr structure, something like:

<span class="adr listing-address"><span class="street-address">1 Place Gambetta</span></span>

I wonder if former is done due to some specific requirement or rather the template could be amended to produce adr kind of markup --Vadim Shlyakhov (talk) 16:57, 18 January 2016 (UTC)

Label is available, per the hCard spec, for cases where the specific sub-parameters for ADR cannot be used, because we don't know whether the content will take the form "1 Place Gambetta" or "1 Place Gambetta, Rome" or "Rome, Italy". However, if (as suggested in 2006(!)) the intention is only to mark up street addresses, then your suggestion is correct. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:23, 25 January 2016 (UTC)

It looks like vCard's label is for printed mailing labels. It needs to be formatted and contain a full address. In this case though the address contains only a street component Wikivoyage:Listings#Template parameters --Vadim Shlyakhov (talk) 08:45, 26 January 2016 (UTC)

Implemented --Vadim Shlyakhov (talk) 21:57, 4 February 2016 (UTC)

Should we or shouldn't we avoid having duplicated points of interests in both the region articles + articles about the cities within those regions?

Swept in from the pub

Although I have been editing content here for several years... it isn't quite clear to me yet what the consensus is among the English Wikivoyage community about having or avoiding having duplicated points of interests in both the region articles + articles about the cities within those regions.

On the one hand, logically I tend to prefer having a "See section" within articles about regions contain only THE most prominent attractions in that part of the country ... for example, having the Île-de-France article contain an Eiffel Tower listing in it's "See" section even though it is already mentioned in the Paris Paris/7th arrondissement article (I assume that most of you tend to intuitively think that this would be the ideal thing to do at first too).... NEVERTHELESS, from my experience there are two additional important factors that should be taken into account as well:

• There are many many many tourist attractions outside of the cities which have their own articles (you'll be able to easily locate many of them using TripAdvisor or Google Earth/Maps), and in many instances the region articles are the only place in Wikivoyage in which we could mention the tourist attractions which aren't located within the cities that have their own articles and sub articles. If we won't insist that the "See" sections of the region articles would ONLY contain points of interest that AREN'T already presented in the city article, there is a good chance that a lot of interesting places outside of the cities would either not make the cut (because there are a lot more prominent places within the cities than outside of the cities) or otherwise, most people might overlook good points of interest outside of the cities if the "See" section of the region article would be "flooded" with A LOT of points of interests that include both places within the cities and outside of the cities.
• it seems redundant to me to have duplicated points of interests in both the region articles + articles about the cities within those regions.

In order to better understand the consensus about this issue, please indicate which of the following two options you prefer:

1. Ideally, we should have the "See" section in the region articles contain around 10 to 15 of the most visited, popular and prominent points of interest within that region WHICH IN MANY INSTANCES MIGHT ALREADY BE MENTIONED in the articles about the prominent cities within those regions.
2. Ideally, we should have the "See" section in the region articles contain around 10 to 15 of the most visited, popular and prominent points of interest within that region WHICH AREN'T ALREADY MENTIONED in the articles about the prominent cities within those regions?

ויקיג'אנקי (talk) 15:02, 25 February 2016 (UTC)

The "See" section of region articles should briefly mention the most prominent attractions within that region — but, and this is the most important part, not in the form of listings. Additionally, if there are any prominent attractions mentioned in this way that are located in cities that don't yet have their own articles, we should consider those city articles to be a high priority for creation. -- AndreCarrotflower (talk) 15:06, 25 February 2016 (UTC)

AndreCarrotflower, so if there is a certain prominent tourist attraction, shopping center, night club, restaurant, etc which aren't located within the articles of the cities with their own articles, where would those places be mentioned if not as a listing in the region article? ויקיג'אנקי (talk) 15:28, 25 February 2016 (UTC)

In all cases, the region article should briefly mention the prominent destinations within the region, but again, not as listings. There obviously should be a proper listing for each destination in the city it belongs whenever we have an article for that city. If we don't, we should prioritize the creation of that city article, but in the meantime we should follow the same procedure for the region article - give it no more than a brief mention in non-listingified prose. (See Gaspé Peninsula#See for an example - only about two-thirds of the attractions mentioned there are located in cities for which we have an article; I'm hard at work on the remainder.) -- AndreCarrotflower (talk) 15:48, 25 February 2016 (UTC)

In a few cases, an article about a town or small city - something like Miami (Oklahoma) or Napanee or Cobourg - contains not only the town itself but a wide rural area ending where the next city with an article begins (so Cobourg ends where Port Hope or Trenton (Ontario) begin). Anticosti is an example of this, one pop-250 village and a hundred miles of provincial parkland. Thousand Islands is also about fifty miles and two countries with only a couple of pop-1000 villages at most on the actual islands. K7L (talk) 16:30, 25 February 2016 (UTC)

AndreCarrotflower and K7L - if for example, I want to add a certain prominent tourist attraction, shopping center, night club, restaurant, etc that is located in the region of the Galilee in Israel, but which isn't located in or near any city that got an article.... where would you suggest that information should be stored? would I only be allowed to add that information if I create a relevant city/village article for that establishment? (this is very confusing to me, I guess because I originate from a rural area, so I know that many popular attractions in the world aren't anywhere near cities). ויקיג'אנקי (talk) 20:59, 25 February 2016 (UTC)

You can create a city article (do not take the name too literally) for a rural area. Maybe in Israel use a local council or regional council as a definition of a rural area. City article just means it is bottom level article. Alternatively place the listing in the closest city/town article; think would people drive from that town to visit the attraction or restaurant (if not maybe it is not worth listing). --Traveler100 (talk) 21:15, 25 February 2016 (UTC)

Traveler100, Okay... I understand now that what you all are trying to explain to me is that the existence of a "bottom level article" is necessary for additional non-city attractions or businesses to be added to WV (and I guess, that if there aren't a lot of places to write about in a certain non-city region, one isn't allowed to create the "bottom level article" for only several prominent places. If that's the case, I guess that in addition to the bottom level city articles you can say that Region articles, and Park articles can also serve for this purpose as "bottom level articles", right? ויקיג'אנקי (talk) 03:33, 26 February 2016 (UTC)

There is nothing stopping you adding a location (city article) for a rural area with only a few listings. In fact some argue it is fine to create a page with no listings. --Traveler100 (talk) 06:29, 26 February 2016 (UTC)

postal codes (April 2016)

Arpil 2016: when adding my first listings, before knowing about the postal code conventions I thought about advantages/disadvantages. Similar to the (older) discussion on UK, in some places postal codes are very specific (e.g. in Singapore they denote blocks). Furthermore, in some cities in Germany (e.g. Berlin and Cologne street names may exist several times, e.g. Berliner Straße in Cologne). In such cities, in my view postal codes are required. Furthermore, as to my knowlegde, quite some navigation systems work better if you feed full addresses in. That cannot be done without the postal code. Therefore, I personally have a slight preference to add the full address. What do you tink about that? As another thougt: if we do not want the full address to be shown, wouldn't HTML allow a kind of hover/alternative text which gives access to the full address when placing the mouse over the shortened street+house number address? Buan~dewiki (talk) 09:22, 9 April 2016 (UTC)

We end up with silliness like Watertown (New York) where the postal code for an entire city and town (about 30000 people) is 13601. The whole city. Conversely, one side of one block is the typical postcode size in most Canadian cities - with a huge exception for tiny villages where all inbound mail goes to PO boxes at the main village post office. Then there's the UK, where seemingly everyone knows SW19 is London/Wimbledon and tennis. We don't have one consistent policy worldwide because the codes are more useful in some places than others. K7L (talk) 13:14, 9 April 2016 (UTC)

I strongly agree that postcodes should always be included (whatever the country). Simplification of the address causes ambiguity (just look at the grief that Apple MapKit can cause!). Omitting postcodes limits utility of the address. If you are only ever going to use it from within WikiVoyage then fine, it can be redundant. But cut and past into a SatNav or other app and you end-up having to manually edit (or even add info you don't have!) to get it to the right place (just as editing out the town, might abbreviate but makes the address useless outside WikiVoyage!). I would hope that the community it trying to provide maximum usefulness even it it means a few more characters (and lets be honest, being brief is not what people are worried about given some of the changes others have made to my own texts, lengthening without adding clarity!). In my (strong) opinion an address given should be complete and stand alone allowing maximum usefulness. And having just spent a fair time helping one of the major calendar app developers for Apple platforms sort out their address processing through the grief of MapKit API, every time you omit part of an address limits long term usefulness.PsamatheM (talk) 22:09, 22 March 2017 (UTC)

Also in some countries, not all postcodes are organised what some might consider "sensibly" and borders to run through things. e.g. in France your postcode depends on your department so a "place de la republique 72123" and "place de la republique 49456" (made-up addresses) might be close geographically be different places. So remove the postcode and you've destroyed the address (i.e. no longer specifies somewhere_PsamatheM (talk) 23:33, 22 March 2017 (UTC)

Wait: Whatever the country? What adverse consequence befalls a person who doesn't know the zip code of an address in the U.S.? You don't need that for Google Maps. Ikan Kekek (talk) 02:57, 23 March 2017 (UTC)

For Finnish villages I have often added the postal code to the Connect section, as it generally does not vary in that kind of area. For cities I haven't, as a number covers some random part of the city and is not used for navigation (it should be used for snail mail, though – should we give postal addresses?). A thing that could be important is the municipality: addresses are guaranteed to be unique in a municipality (since 112 was centralized such that they do not have local knowledge any more) and the name is therefore used in many applications. The municipality is usually mentioned somewhere in the article, but not necessarily consistently, and sometimes only implicitly. --LPfi (talk) 15:55, 23 March 2017 (UTC)

For some places an address without a postcode (or with a partial postcode) and you might end-up at the wrong place. Even in a small city e.g. place d l'eglise, Alencon and you have a 50:50 chance of ending-up in the wrong place!. Gets a lot worse in some other areas. Much worse in some rural areas. It can vary by country (I don't know the US), but just because you maybe don't need one in the US does not mean the same applies to other countries and you'd end-up with different practices in different countries or different areas ... and it is not a question of the size of a postcode area as whatever the size there will always be something close to the boundaries.PsamatheM (talk) 13:19, 24 March 2017 (UTC)

Wikidata item number ?

To be able to use data from Wikidata, we might want to add a field for the listing's Wikidata item (QID) to the template.

For the sample "Palace of Culture and Science" this would be "item=Q167566". See d:Q167566. Jura1 (talk) 11:19, 14 May 2016 (UTC)

Support. –T.seppelt (talk) 11:56, 17 May 2016 (UTC)

Support; fr: and de: already have this as wikidata= or d=. I'd prefer to name this wikidata= instead of item= so that its purpose is clear. K7L (talk) 12:20, 17 May 2016 (UTC)

Template listing documentation already has this field: "| wikidata=WIKIDATA QID IDENTIFIER OF THE LISTING" -- this isn't in documentation for See, Buy templates etc. but is probably implied -- in similar fashion "image" is an allowed field; though not mentioned, it is used as well for POI's on maps - Matroc (talk) 14:53, 17 May 2016 (UTC)

Sounds good. I see it's present in the French version of the listing editor, but not here.

BTW, we are trying to sort out some of the missing properties: d:Wikidata:Property_proposal/Sister_projects#Wikivoyage. Input from Wikivoyage contributors is valuable. Jura1 (talk) 11:03, 22 May 2016 (UTC)

This change could display an icon for such listings. Jura1 (talk) 20:21, 16 June 2016 (UTC)

Need for "connection" and "event" item types in Wikivoyage + semantic wikivoyage

Swept in from the pub

For Wikivoyage in general I totally recommend using new items:

1. Connection describes the two locations and the properties of the connection. Makes sense to link 2x instructions on "get to the port/station" and "get from the port/station but write these only once and maintain the master link at Municipality#Getting to and from the bus/train station Can be natural connection i.e. border crossing to neighboring entity via road or highway in car or man made: airplane, ferry, train, bus etc.
2. Event describes a thing to do with a start timedate and end timedate plus the rest of {{do}}, {{eat}} and {{buy}} have. Then when added Semantic database consisting among other thigns of subject-predicate-object w:Triplestore would be possible to compile calendars like

• "Get all me events sorted chronologically form this and all neighboring entities (and optionally also their neighbours) for some timeframe."
• "Find me all the events in places east of 24° 00,0’E that are in Finland and have a guest marina."
• "Make me a calendar of events in Finland where type=Film festival."
• etc.etc.

Read more:

• w:Triplestore
• w:List of subject-predicate-object databases can be built as triplestore from ground-up or on top of RDBMS. Matter of taste I perceive.
• w:SPARQL query language enables semantic queries
• w:NoSQL

ps. Coming up is a post on description of transport networks as directed graph networks derived from sets of semantic descriptions. Instead of mentioning a permutation of times "there is bus/train/air/sea/road link to Y" in X and likewise. You just define possible nodes in (navigator that is road intersections) and make a linked list which is then incorporated into the directed graph network representation. Jukeboksi (talk) 10:12, 28 April 2016 (UTC)

I am a bit sceptical about the Connection type of item. (Although I'm not quite sure I understand correctly what you describe) This presumes that the information on both article is identical, but this is not always the case. For instance let's say we have a connection between a big city Paris#By_train and a small city Rennes. In the Paris article, there are so many connection, that it would be bothersome to have details to all of them, it would make the section very long and hard to navigate. On the Rennes article however you would have more space and it would make sense to put in things like travel time, ticket prices etc. Drat70 (talk) 00:55, 29 April 2016 (UTC)

To show how to get from A to B in article B, which I think you are trying to address with the connect idea, then consider the {{Routebox}} template which is near the bottom of many pages. Can show not just roads but also bus, train and ship routes. Advantage is that in one line it show next and previous destination and first and last destination on a route, which is more useful than just A to B. As for {{event}}, the template already exists. At the moment only a couple of hundred pages use this, would be great if you could expand its uses. My intention was that once widely used we could investigate how to make a database from the content and create calendar and search tools. If you know some good ways to achieve that please set up some test pages. --Traveler100 (talk) 06:11, 29 April 2016 (UTC)

I've been trying to match Wikidata properties to fields in the most common Wikivoyage templates. I don't see a good {{routebox}} equivalent there; d:P197 lists the "next station" on a rail line, but that's not necessarily the next city or next Wikivoyage destination - often, it returns a suburban commuter train station in the same city. For roads, the choices are even more limited; d:P1302 is just a list of cities in no particular order or position. Most of our local events are in {{do}} listings, often as an ===Events=== subsection of ==Do==. The {{event}} template only differs from other {{listing}} types by specifying event dates - the rest of the fields are the same as any other activity listing. You may want to look at d:Wikidata:Wikivoyage/Resources and the discussions currently open on d:Wikidata:Property proposal/Sister projects‎ as the task of fitting the existing (at best, partially-structured) Wikivoyage template data into any sort of semantic data structure still poses a few obstacles - {{quickbar}} and its counterparts in other languages are fairly straightforward (except for the bits on language and religion) but the hours and prices in {{listing}} are proving awkward and a structured approach has not yet been decided. K7L (talk) 16:24, 21 May 2016 (UTC)

Add a what3words address parameter?

It was reported earlier this summer that Mongolia's postal service is implementing what3words addresses as the country's postal address system. These addresses were devised by a UK company as a universal coordinate system, identifying any precise location on the globe (within a 9 m² area) with a simple, easy-to-remember, and unique string of three words.

I think it would make a lot of sense to add a what3words parameter to the listings templates, mainly to accommodate listings in travel guides for Mongolia, although this is useful outside of Mongolia too. What3words has an app letting travelers look up these coordinates offline so they can navigate even without mobile phone service. Printing a what3words coordinate in each listing will really help travelers visiting Mongolia.

With the help of a bot, these coordinates can be easily added automatically to listings that already specify a lat/long coordinate. And likewise, any time a what3words coordinate is added by an editor, the lat/long conversion can be automatically inserted.

— Athelwulf ^[T]/_[C] 09:54, 3 September 2016 (UTC)

The three words can go in the Address field for Mongolian listings. Elsewhere in the world, I don't think the concept has nearly enough currency to be worth adding them everywhere. We already have the traditional geocoords; what does what3words add to that? Powers ^(talk) 22:40, 4 September 2016 (UTC)

Add hotel stars to the sleep listing.

Have the amount of stars for a hotel listing built-in to the listing itself. For example:

* {{sleep | name= | alt= | url= | email= | address= | lat= | long= | directions= | phone= | tollfree= | fax= | checkin= | checkout= | price= | stars=5 | lastedit=2016-10-08 | content= }}

Use the Unicode symbol (★) U+2605 or something similar after the number.

So for the example it would render as ★★★★★.

I think such formatting would make it look cleaner and more clear to readers.

Inferno986return (talk) 23:13, 8 October 2016 (UTC)

An interesting idea but whose start rating should be used in each country? --Traveler100 (talk) 23:20, 8 October 2016 (UTC)

Exactly. I oppose this proposal and believe that the star rating, if meaningful, should be mentioned in the description ("content"). Ikan Kekek (talk) 05:00, 9 October 2016 (UTC)

Are there meaningful star ratings given by some impartial institution in any country? And if so, should their definition be mentioned in the sleep section of the highest level to which they apply? Also, what about "garni" which is apparently some kind of standard for hotels in some places? Hobbitschuster (talk) 15:26, 9 October 2016 (UTC)

Yes, absolutely. It makes perfect sense and is a service to the traveler to explain star systems in the "Sleep" sections of country articles. Ikan Kekek (talk) 09:51, 10 October 2016 (UTC)

I agree with Ikan and oppose the suggestion since there is no clear general standard for what the ratings mean. See Rating_systems#Understand for discussion. For example, one Chinese town I lived in had a well-known "five star", but a friend who had managed hotels in New Zealand reckoned it was about 3.5 by NZ standards.

Where there is a clear national or regional standard, mention the rating in text. Pashley (talk) 17:05, 9 October 2016 (UTC)

Listings with same name in same article

Swept in from the pub

• Brooklyn/Bedford-Stuyvesant and Flatbush has 14 different listings named "Brooklyn Public Library"
• Buffalo/East Side has 11 different listings named "Family Dollar"
• 2531 similar cases, 95% of them with just 2 occurrences

Is it considered OK? Syced (talk) 07:53, 30 May 2016 (UTC)

Absolutely yes on "Brooklyn Public Library", which is the name of the entire public library system in Brooklyn that has numerous branches. Every branch is useful to travelers because of the free computer time you can use there, as well as other services. I'll let someone else address "Family Dollar". Ikan Kekek (talk) 07:59, 30 May 2016 (UTC)

This looks to be finding duplication of the same listing into multiple sections. For instance, "Sportsman Inn" and "Killarney Mountain Lodge" each appear in at least three sections of Killarney (Ontario) ("eat", "drink", "sleep") while some pizza joint in Kabankalan has listed itself once in "eat" (fair enough) and twice in "sleep" (which is spam in a can, really, can you sleep there?). We do need to distinguish between multiple locations in a chain (which may be legit) vs. duplicate listings for the same location (such as the same motel location listed in three different parts of town, or a hotel arbitrarily listed again for its restaurant and bar). There's also the question of when these become boring and repetitive - do we need every McDonald's? every grocer in a chain? every dollar store? McDrivel usually has wi-fi, but they look a lot alike after a while. K7L (talk) 15:44, 30 May 2016 (UTC)

In a place like the East Side of Buffalo, it's an unfortunate reality that dollar stores fill a niche left empty by an absence of other places to buy food. More importantly, I have to ask what is the pressing need to upset the apple cart. Duplicate listings don't, for example, cause any problems with the dynamic map; there've been no examples cited of unrelated businesses with the same name that may be confusing for travellers; listing multiple locations of the same chain gives travellers options to choose from in determining what fits best with their itinerary. The question of "do we need to list every McDonald's" has been posed, but no examples have been given of an article where every McDonald's is listed. So, is there an actual, specific problem with the status quo, or are we seeking one out that doesn't necessarily exist? Do we need to overlegislate and overregulate every aspect of this site, or can we just leave certain things be? -- AndreCarrotflower (talk) 16:45, 30 May 2016 (UTC)

I think arguably if there are more than 8 or 9 listings in a single article for the same chain, it's worth looking at to see if we can just say "there are a bunch of Chain X outlets around" or something similar. If there's that many of them, they can't be hard to find. Powers ^(talk) 18:09, 30 May 2016 (UTC)

Yes, but this whole thread strikes me as meddling for its own sake. We're still talking about duplicate listings as an overall concept rather than real-world manifestations of why they are a problem that needs fixing. One of the things that I like about Wikivoyage as opposed to Wikipedia - and I know I'm not alone on this - is that on this site there aren't pages upon pages and reams upon reams of policies and regulations governing every word and paragraph we write. At Wikivoyage, there are certain common-sense parameters within which we work - there are standard section headings, for example, and a manual of style that serves as a good solid framework without being overbearing - but in general the author of a given article has free rein to develop it mostly as he or she sees fit. And I can't help but get a bad taste in my mouth every once in a while when some user comes in the Pub talking about a phenomenon he or she seemingly chose at random, apropos of nothing, with the assumption that it's a big issue that merits our attention. In my opinion, either show me a specific article where not only do duplicate listings exist, but their presence negatively affects the article from a user's perspective - or better yet, show me a widespread pattern of articles where that's the case - or else it's a nonissue that doesn't merit being worried about. And in my opinion, you can substitute for "duplicate listings" any other concept or phenomenon that might conceivably become a problem. -- AndreCarrotflower (talk) 19:59, 30 May 2016 (UTC)

The duplicate list is useful as it can be used as a starting point for some tidying up. In some cases the duplication is fine and in other cases they can be merged into one listing. One example is the Wrolen Pin Cafe in Hodgenville which could be merged into one listing. Otherwise, what's the point in having any of the maintenance categories? -- WOSlinker (talk) 20:16, 30 May 2016 (UTC)

Exactly, my intent was not to launch a witch hunt. I was just playing with the database trying to find interesting facts about it, and this one stroke me as something that might catch someone's interest. The statu quo is fine for me, and by the way there is no special technological reason which would require uniqueness, don't worry. If we have real (unintended) duplicates, they are in this list. Syced (talk) 04:50, 31 May 2016 (UTC)

Listing syntax change - minor edits needed

Swept in from the pub

Requesting a little assistance to tidy up image parameter of listings. The command no longer requires or will accept the full Commons address of the image, just the image name. Also the type File: is not required or accepted any more. This is an improvement but has broken the link of a number of the references to images created. I think it best to fix the link name than change the listing code. See Category:Pages with broken file links for list; best to go into edit mode and search for text string image to find the culprits. --Traveler100 (talk) 05:24, 17 June 2016 (UTC)

• Fixed one - in processing of checking more -- finding names of images that do not exist in Commons at this time. I think that is yet another case for red link -- Matroc (talk) 05:56, 17 June 2016 (UTC)

• Is see what you mean, fixing the syntax only solves some of the image issues. Looks like the change to the code also means these image references are also been checked, which is good. Another positive is that the the use of images in listings are now showing up in the File Usage list on the image page.--Traveler100 (talk) 06:48, 17 June 2016 (UTC)

• In a Sandbox, I scan an article page with a Module and produce a gallery of images (.jpg,.svg,.tif and .png) (about 95+% accurate) -- generally those names that do not produce an image are evidently not in Commons (names of images not found appear in gallery which has been helpful!) - I have been removing those that do not have a match in Commons after checking them a second time and fixing those that I can by editing the image name. - List of pages is now down to about 62 from 120 something. -- Matroc (talk) 04:03, 18 June 2016 (UTC)
• Down to 18 articles that need to be checked - some errors also include: image=image= image=File: no extension on image name - recently added .tif images to check and broke apart the routebox template to get images found there... Also some of the images can be found in Wikipedia but not in Commons - That's it for me at this moment -- Matroc (talk) 05:39, 22 June 2016 (UTC)

• great, thanks. --Traveler100 (talk) 07:07, 18 June 2016 (UTC)

It is a little difficult to find the listing with a broken image link in an article, is there a way to have it highlighted the same way we have done with url dead links and phone format with the ErrorHighlighter preference? --Traveler100 (talk) 07:34, 18 June 2016 (UTC)

• Not all articles with listing redlinked images appear in the Pages with broken file links -- came accross 1 article with 3 such images -- (maybe because they havn't been touched since various changes in maps? -- Matroc (talk) 19:12, 20 June 2016 (UTC)
• Completed except for several User pages and 1 talk page - Matroc (talk) 04:52, 23 June 2016 (UTC)

NOCC tag

Swept in from the pub

I'm sure this is a silly question, but what does the NOCC tag in listings mean? Some pages have a whole bunch of those bright yellow tags, but it's not easy to fix if you're not sure what it is... JuliasTravels (talk) 11:14, 28 July 2016 (UTC)

I think it means that the phone number is not in the 'correct' format, mostly by the country code (+44, +49 etc) being absent. --Andrewssi2 (talk) 12:25, 28 July 2016 (UTC)

Yes it means "no country code" and means the number is either formatted incorrectly (e.g. 1 - whatever instead of +1 - whatever) or totally lacks a country code. Given that WV is a global project, this should of course not stay this way. Unfortunately I sometimes find myself with places where I don't know the country code or how to fix the formatting Hobbitschuster (talk) 14:09, 28 July 2016 (UTC)

Well, of course it's good to tag incorrect numbers for fixing... but is there any way we can improve the functionality of the tag? Make it more understandable perhaps, ideally with a reference to how to fix the phone number? Those bright yellow tags in capitals are quite huge and ugly (imho), so at least they should come with the benefit of providing information to a large audience. JuliasTravels (talk) 21:37, 28 July 2016 (UTC)

One problem is phone numbers which cannot be dialled from outside the country. The listings template has a "tollfree" field, but not a way of handling non-free domestic only numbers. For example Birmingham (England) has three NOCC numbers, but these are number ranges which often don't work from outside the UK. (see w:Non-geographic telephone numbers in the United Kingdom.) AlasdairW (talk) 22:08, 28 July 2016 (UTC)

I see; that complicates things even further, indeed. But first, is there a way to change the displayed name and remove the all-caps? Instead of NOCC, could it say something like "wrong format" (or a better version of that), and is it in any way possible to make that a link to instructions? The "dead link" tag is less intrusive because it is smaller, for example. JuliasTravels (talk) 09:13, 29 July 2016 (UTC)

I agree that the wording could be improved, but these tags should only seen by logged in users who have the Gadgets - Experimental- ErrorHighlighter preference set. AlasdairW (talk) 22:00, 30 July 2016 (UTC)

Ah - I didn't know that :) Thanks, AlasdairW. That takes away most of my doubts about the tag, although indeed the wording could better. I don't know how to change that, though. JuliasTravels (talk) 19:17, 31 July 2016 (UTC)

I've added more descriptive text which you'll see when you leave your mouse pointer hovered over the text. NOCC -- WOSlinker (talk) 20:18, 31 July 2016 (UTC)

Perfect. Thanks, WOSlinker JuliasTravels (talk) 21:00, 1 August 2016 (UTC)

When is it okay to leave bulleted lists untemplated?

I was looking at Pittsburgh/Downtown#Festivals and events after a couple of items were converted to use the listing template and I'm not satisfied with it. The listing template doesn't allow for good prose, and these specific listings have no information except a URL. We can easily represent these events in prose with a simple external link, which allows us to incorporate the names into the prose instead having them standing starkly before it.

For example, instead of what's there now, we could have:

• The world's largest furry convention, Anthrocon, has been held in Pittsburgh since 2006. Over 5,000 people attend each year, and over 1,000 of them are costumed mascots and fursuiters. The all-ages event is held in late June or early July each year; admission is charged.

This seems preferable to me so long as we don't need the other fields in Template:Listing. Powers ^(talk) 14:08, 3 November 2016 (UTC)

In general I'd prefer to see listing templates used unless there is a compelling reason not to use them (one example of when the listing template may not be appropriate: Wikivoyage:Listings#Complex attractions). The three main downsides I see to using prose instead of a structured template are:

1. The listing editor is a much, much easier way for casual editors to contribute, and that tool is not available unless the listing template is used.
2. Prose dissuades someone who wants to add a data field other than URL, since there is no obvious way to include that information. For events like the one in your example, sister project data might be relevant, there could be a phone number to call for tickets, the event might be at a specific venue that warrants including address or lat/long coordinates, etc.
3. If the listing template isn't used, we lose the structured data format that the template provides. That structured data has advantages for search, allows users to make a phone call by clicking on a phone number, etc.

-- Ryan • (talk) • 15:26, 3 November 2016 (UTC)

Then I would suggest that we find a different way to provide structured data that fits the way we naturally want to write about things, especially in cases where we don't need to format a lot of different data about the item. Our standard listing format was designed to present those data in a consistent format; where items don't have those data, there's no need for the consistent format. Powers ^(talk) 19:22, 4 November 2016 (UTC)

I think we have a disconnect on the "fits the way we naturally want to write about things" part. If someone is using a bullet list to highlight an attraction, business or event I'm not clear on why something other than a structured listing would be encouraged. Prose makes sense in a paragraph, where there shouldn't be too much detail on any one business, but in a bullet list I don't see any compelling reason to use prose over a more structured format. -- Ryan • (talk) • 21:11, 4 November 2016 (UTC)

Yes, there is a disconnect, then. There are any number of uses for bulleted sentences that don't necessarily start with the subject as the very first word. Bulleted lists existed as a standard part of typesetting long before Wikivoyage developed listing templates. Note, for example, the last two bullets in the Pittsburgh section; you have not converted those to use a listing template. They work just fine without a template. Walt Disney World#Security is another example of a bulleted list with full sentences instead of structured data. Using prose in a bulleted list is a stylistic choice that I don't see any reason to deprecate. Powers ^(talk) 14:26, 7 November 2016 (UTC)

Country codes

Swept in from the pub

Hi

I am not sure whether all who will read this are aware, but all phone numbers are supposed to include country codes preceded by the "+" symbol. (e.g. +49 (area code without zero) (local number) for Germany). While I am trying to fix those where I am able to, it is a task that looks like a bot could better do it.

Are there any possibilities to either create a bot or make it inherent in the listing editor that it adds the country code of the country (as per the breadcrumbs) if no country code is found? With some way to turn it off for false positives?

I am sorry if the question is stupid, I am not exactly a coding expert... Hobbitschuster (talk) 01:58, 23 September 2016 (UTC)

I did create a AutoWikiBrowser script under User:Traveler100bot to do this but was not 100% reliable so had to run in semi-auto mode checking each update. Have not run for a while, maybe time to do another scan through pages (may be a couple of week before can get round to it as on the road at the moment). --Traveler100 (talk) 04:16, 23 September 2016 (UTC)

Hobbitschuster, Traveler100, days ago I've proposed the introduction of this new property in wikidata. It's necessary to clean the data stored in Wikidata and in all the projects that use them. Once implemented, can be easily created a local category to check the correctness of all the numbers stored in the listings. I suggest to support to speed up its implementation (creation & population via bot). --Andyrom75 (talk) 17:53, 24 September 2016 (UTC)

Help needed: Malformed coordinates, URLs, emails

Swept in from the pub

Here are a few spooky things that might need to be fixed: http://wvpoi.batalex.ru/download/listings/wikivoyage-listings-en-latest.validation-report.html

You can uncheck categories at the top, to not show email for instance. This page is updated every 2 weeks.

Thanks a lot! Syced (talk) 08:01, 5 September 2016 (UTC)

Syced, is it possible to have it for all languages? --Andyrom75 (talk) 07:44, 6 September 2016 (UTC)

It is also available for Russian, French, German: http://wvpoi.batalex.ru . If you want to add more languages, please post an issue at https://github.com/baturin/wikivoyage-listings/issues thanks! :-) Syced (talk) 10:33, 6 September 2016 (UTC)

If it's not a big effort you can add all the languages, otherwise it doesn't matter. The request is just to give to all the admins or users in general the chance to use a new tool (regardless of the nature of the tool) :-) --Andyrom75 (talk) 16:58, 6 September 2016 (UTC)

I don't see a way to remove or mark those that I have fixed - thus others are going to end up checking them again? -- Matroc (talk) 03:23, 8 September 2016 (UTC)

Indeed that's a known problem with this tool: There is no way to "mark as fixed". On the positive side, the list is shown in random order so that you have less chances of checking the same items as someone else, and it is updated every 2 weeks, which is much more frequent than the previous tool I was maintaining. If the randomization is bothering you, please remove the "this.shuffleIssues();" line from the HTML. Thanks a lot! Syced (talk) 07:56, 12 September 2016 (UTC)

Temporary closures

Swept in from the pub

I've been wondering what to do with listings for places that have closed temporarily, renovations, or any other reasons? The establishments are still there, the contact info remains unchanged, of course. L. Challenger (talk) 11:47, 28 September 2016 (UTC)

When I encounter this, I usually comment the listing out, then when it's back in action, it's easy to restore. Drat70 (talk) 13:22, 28 September 2016 (UTC)

My preference is generally to note the closure in the listing description, that way readers can see "expected re-opening January 2015" and if they are reading it today they will know that the place is probably open again and the listing is just out of date. Commenting out the listing would also work, although that approach means that if the original editor forgets to uncomment it then it's likely to remain hidden for longer than necessary. -- Ryan • (talk) • 14:36, 28 September 2016 (UTC)

A note is better than commenting out. Absence of info tells the traveller nothing. A note saying that a place is closed may avoid disappointment, especially for those who would turn up based on info found elsewhere and without booking or enquiring ahead (been there, done that). Nurg (talk) 10:25, 29 September 2016 (UTC)

On it:voy we are use to insert these kind of "temporary information" through a dedicated template that tracks trough categories all the information that after a certain date should be revised. --Andyrom75 (talk) 23:49, 29 September 2016 (UTC)

what do u guys think about revamping the listing editor design?

Swept in from the pub

here it is

I've created a new css for the listing editor, it is still in draft stage so I would like to know if any of you have any opinion on how to improve it or maybe what do you want to add etc. Thanks! Gabrielchihonglee (talk) 11:31, 18 January 2017 (UTC)

Hi, Gabrielchihonglee, welcome to Wikivoyage. Perhaps you'd like to explain what changes you've made, and how your version is better than the current listing editor we have? Best wishes, --ThunderingTyphoons! (talk) 12:25, 18 January 2017 (UTC)

Hi, ThunderingTyphoons!, thank you for replying. What I've done is i've updated the colors and made some changes to the layout. As you can see, mediawiki is actually trying to develop a standardized design guidelines, here are some samples: https://trello.com/b/EXtVT....... So, my design have adapted their style. For input boxes, I've changed their look to make sure that it matches the simple and plain feel of the whole form. Gabrielchihonglee (talk) 12:34, 18 January 2017 (UTC)

Please also have a look at this: THISSSSSS Gabrielchihonglee (talk) 12:36, 18 January 2017 (UTC)

Welcome, Gabrielchihonglee! Thanks for taking an interest. In principle, I like clean and standardized designs. In this particular case, however, I can't say your suggested version seems better than the current one. Tastes in colour may differ, but the oversized, bright blue banner at the top is more distracting than modern, to me. The font seems less easy to read and in this draft, the "cleaner" feel through the single lines instead of the boxes seems less clear, especially for the "content" part. It should be obvious to new users that content can (and often should) be more than just one line. Also the explanation of the content field ("description of place") is not obvious enough now, as it's stuck to the line above while all the other explanations are on the lines of the relevant fields. JuliasTravels (talk) 13:27, 18 January 2017 (UTC)

I see, I'll explore how to improve that then, thanks for your opinion :) Gabrielchihonglee (talk) 13:40, 18 January 2017 (UTC)

Thanks for clarifying, Gabriel. If I were to change one aspect of both the current design and your version, it would be to increase the size of some of the boxes. Directions, hours and prices in particular can contain a lot of information and it's often necessary to write more than can fit into view at any one time, which (for me at least) make the whole process of transcribing complex opening times and tariff boards longer and more frustrating than it need be. --ThunderingTyphoons! (talk) 13:45, 18 January 2017 (UTC)

Got it, thank you! :) Gabrielchihonglee (talk) 14:04, 18 January 2017 (UTC)

As the primary maintainer of the listing editor I'd love to see more discussion about improving usability, although I'm wary of a UI revamp simply for the sake of doing something different. My concerns about the proposed UI is that it uses different styles and colors than the rest of the site, and increases the header height for an interface that is already limited by the vertical space available, without providing obvious usability improvements. It may make more sense to focus on specific usability and related issues like those that ThunderingTyphoons! has described, and then figure out what UI changes would best address those problems. -- Ryan • (talk) • 17:33, 18 January 2017 (UTC)

Are you familiar with the current advice on interface design (e.g., use of colors, etc.)? WhatamIdoing (talk) 17:16, 18 January 2017 (UTC)

Is there a way to demarcate "special" listings?

Swept in from the pub

Hello! I was wondering if there was a way to visually set certain listings a bit apart from the others? If there is a list of 9 restaurants for example, and they are all very nice, but maybe one is a little better, and we'd like to communicate this is the one worth checking out if you've only got time for one stop. Maybe a checkmark, or heart, or star or something? I'm imagining adding a "notable" checkbox in the listings editor under "status" section. I'm noticing most "See" and some "Do" listings I enter get WP or WD icons/links appended to the end of the blurbs. I could see a little heart or something working down there pretty easily. I'm guessing we don't do this already because (if implemented), sooner or later everything will have a heart next to it, rendering its distinction moot. I do think this could be avoided with judicious use however. Thank you! --ButteBag (talk) 00:13, 7 February 2017 (UTC)

There's a big (potential) problem there: Who decides which listings get whichever we implement? We have a lot of problems with touts as is. Hobbitschuster (talk) 00:26, 7 February 2017 (UTC)

I could possibly get behind a 'star attraction' label for a 'see' or 'do' listing (even then I'd have reservations), but I would not support its use for restaurants. Firstly, it's too subjective (different travellers like different cuisines, styles of restaurant, speed of service...) and secondly it's not very fair to the other restaurants in town. Couple that with the touting issue Hobbitschuster points out, and it doesn't seem workable. If you really think a particular restaurant is head and shoulders above the others, there's no reason you can't say so in its blurb, but to actually mark it with some sort of symbol would be a step too far, in my opinion. --ThunderingTyphoons! (talk) 00:30, 7 February 2017 (UTC)

Exactly. Just say it's a particularly great restaurant and maybe give some examples of particularly delicious dishes. Ikan Kekek (talk) 00:44, 7 February 2017 (UTC)

HS, TT and IK have raised excellent points. I think you would need to address these before you'll get consensus to proceed. Ground Zero (talk) 01:26, 7 February 2017 (UTC)

Well, it's kind of arbitrarily "fair" if a restaurant is included in a WV article in the first place, no? Well anyway, you all make good points and I don't like my idea anymore. Specifically, I wanted a way to show here that Wally's Cafe is more "notable" than the other places in the list. (assuming the rest of the listings had blurbs, lol) But, what I really should do, is write in the "Drink" section of the parent page about the relative "notableness" of that particular venue. Kind of like the "Other Destinations" section/list on other pages.

I do wish there was some kind of indicator that says "this is pretty cool" for readers skimming long lists. I feel like no one is going to sit down and read an entire article anymore, with all the ways our attention is fragmented nowadays. Maybe this ties into the idea someone else had about an "I've been here" button. Then once X number of WV'ers click a certain listing it becomes "pretty cool". But then you run into the same issue above with touts, spammers n' scammers. BUMMER. I can't think of a way around this right now. Maybe only users of a certain privilege level can use it? It would definitely have to be used sparingly to have any efficacy at all. --ButteBag (talk) 02:10, 7 February 2017 (UTC)

There really are good ways to handle this. Look at Manhattan/East Village#Drink for how I handle McSorley's Old Ale House: an alphabetical listing plus a photo, and I even use their own slogan as the caption, because it's a good one, apt and funny. Ikan Kekek (talk) 02:14, 7 February 2017 (UTC)

Ha, nice! And it looks like I have basically already inadvertently done that in JP. There shouldn't be more than one "notable" thing per section anyway. Thank you all! --ButteBag (talk) 02:19, 7 February 2017 (UTC)

Dang, Ikan Kekek, how is that East Village article not a star??? Nice job regardless! --ButteBag (talk) 02:30, 7 February 2017 (UTC)

Thanks, but it's not complete. I was just thinking of another bar I should add a listing for. The East Village is filled to the brim with bars and restaurants, and it's impossible for any one person to know all of even the notable ones. Plus, the neighborhood has very rapid turnover because of excessive rents, nowadays. Ikan Kekek (talk) 02:33, 7 February 2017 (UTC)

Another way to highlight a listing and draw attention is to bold an important word or two but as others have said, it should be done with the traveller in mind and not in a touting way. Gizza ^(roam) 11:00, 7 February 2017 (UTC)

Thank you!

Outcome: Just use a picture of the "notable" thing. Skimmers will notice it because it's a picture, and the location will be made "notable" because there is now a picture of it. Duh. --ButteBag (talk) 14:59, 7 February 2017 (UTC)

Maybe it is not related, but perhaps could be added a parameter to denote the "official stars" of the restaurant or hotel:

• Dumbledore Pub (★★★). Boston Ave. 230. Irish food and a variety of beers.

What do you think? --Zerabat (talk) 16:48, 7 February 2017 (UTC)

Who gives out those stars and on what basis? And what do they mean? There may be a handful of countries where official definitions of stars for hotels (not restaurants, though) exist, but even there, media are full of stories about them not being checked nearly often enough to be accurate. Hobbitschuster (talk) 17:17, 7 February 2017 (UTC)

I don't think there is any such thing as "official" stars. Governments tend not to regulate such things. I think we'd want to indicate the source of the stars to show that they are not WV stars. It also lets the reader decide whether to take them seriously -- Michelin stars are one thing, the Boston Advertise/Pennysaver is another. I'm sure there are lots of free papers that are happy to give out stars to their advertisers. Also some use a 5-star scale, others, like Michelin, use a 3-star scale. Ground Zero (talk) 17:20, 7 February 2017 (UTC)

I think current policy is to mention stars where they are meaningful (though never as part of the name) and this would certainly apply for Michelin Stars. However, I don't know any given restaurant with Michelin Stars or where they would be listed. Hobbitschuster (talk) 17:37, 7 February 2017 (UTC)

Seems like a perfect use case for the low tech "use a picture" idea. Getting a Michelin star is very difficult. If a restaurant has one, just take its picture and use it in the "Eat" section. Done, perfect, no stars to police. --ButteBag (talk) 17:40, 7 February 2017 (UTC)

This discussion appears to be muddling two completely unrelated concepts. The automobile associations print guidebooks which use the term "star attraction" to indicate the few best-known things to see or do at one individual destination (Paris is known for the ☆ Louvre museum and the ☆ Tour Eiffel, Sydney is known for its ☆ opera house, Quebec City is famous for its ☆ 1608 old town...). Attractions, not hotels and restaurants. This isn't a rating system and doesn't award multiple stars to a venue; it just indicates what to see first.

That's entirely separate from the hotel-style ratings, where extra stars ★★☆ (or diamonds, or sunshine) indicate extra amenities or luxuries that aren't at the ★ property - maybe an indoor pool or fitness centre, meeting and convention space, restaurant, lounge, room service - whatever.

The restaurant/hotel star ratings are meaningless unless there's some indication of who issued them under what criteria. A ★★★ Canada Select B&B provides full (not continental) breakfast, hotel-style rooms (en-suite bath and TV's, locks on individual doors...) and a few personal touches while a Michelin ★★★ restaurant is one of the best worldwide.

I'm tempted to suggest that "Understand" be one of the required sections (it's currently optional) and any statements like "Oswego, home of historic Fort Ontario, is notable for its front-line role in the War of 1812" be made there (preferably before promoting the page to 'usable' or higher) to point out why one would go to the city. There's a Best Western? That's nice, but everything is built on one or a few 'star attractions' - things to see or do that are the voyager's reason for visiting. If "terrorise the local wildlife" is the only thing to see or do in tiny Relais-Gabriel, say so. K7L (talk) 17:28, 8 February 2017 (UTC)

Should {{eatpricerange}} and {{sleeppricerange}} be merged?

Swept in from the pub

These two templates are basically the same in code except by a minor and default text, which is replaced when is used parameter {{{4}}}. Should these templates be merged into {{Pricerange}}? The difference in default text can be solved by adding an additional parameter. --Zerabat (talk) 20:50, 22 February 2017 (UTC)

You could merge the code but leave the templates as wrappers. Otherwise it requires changing every single use of the templates and that's not worth the trouble. Powers ^(talk) 02:32, 25 February 2017 (UTC)

List formatting

Swept in from the pub

In response to Hobbitschuster's suggestion above, I started copyediting Breweries in Franconia. Every list item was separated by a blank line, which produces a bad HTML and therefore a horrible experience for people using screen reading software (which typically reads not just the "* Content of the listing here" that most of us see, but also a statement such as "List of one item" before it, and "End of list" after it. So w:en:LISTGAPs are bad; we should avoid them.

This problem also seems to be fairly common here, and it's pretty tedious/carpal-tunnel-problems-inducing to clean them up manually. One of my friends at enwiki has a bot that could fix this for us. I'm willing to ask him to do this here, if you all would like to have this work all done at once. The main downside is that, with the proportion of articles that have this problem, the bot will flood your watchlist for a day, if you have your watchlist settings to show bot edits. What do you think? WhatamIdoing (talk) 21:55, 23 February 2017 (UTC)

I didn't realize the blank lines were a problem. I'd say sure, why not? Ikan Kekek (talk) 22:05, 23 February 2017 (UTC)

Unless the bot produces cleanup work to do by hand afterwards, sure go for it. It might even bring some edits to long forgotten articles, who knows? Hobbitschuster (talk) 22:11, 23 February 2017 (UTC)

The code for this is very conservative. I think we can confidently expect zero pages requiring cleanup as a result. WhatamIdoing (talk) 04:38, 24 February 2017 (UTC)

Go for it. Hobbitschuster (talk) 15:53, 24 February 2017 (UTC)

Where is the policy on car rental listings?

Swept in from the pub

Re: User talk:180.253.220.86, I recall an agreement that when there are numerous car rental agencies operating somewhere, none are listed. However, there sure isn't an obvious place to find the statement. I didn't find it using keyword searching of WV:Listings or WV:Avoid long lists. So where is the policy, and shouldn't we put it somewhere where it's easy to remember and link to? Ikan Kekek (talk) 14:09, 1 March 2017 (UTC)

I remember this discussion at Talk:Dallas/Fort Worth International Airport. --Traveler100 (talk) 21:26, 1 March 2017 (UTC)

Also, it`s mentioned in Wikivoyage:External_links that we don`t link to an car rentals if there`s more than 10 in a city. It also says we typically don`t provide details of national rental chains in local guides. JakeOregon (talk) 04:02, 2 March 2017 (UTC)

Thanks. But I wonder whether it's worth mentioning in WV:Listings, as well, since car rental agencies are not necessarily just links but can be listings. Ikan Kekek (talk) 08:24, 2 March 2017 (UTC)

Yes; WV:XL isn't where I'd think to look for it. Powers ^(talk) 00:53, 3 March 2017 (UTC)

Is there a way to identify "dead email addresses" other than by hand?

Swept in from the pub

I am asking because we have a way to detect dead weblinks with reasonable accuracy but even those email addresses where an automatic "could not deliver message" reply comes cannot be weeded out. Or am I mistaken? Hobbitschuster (talk) 20:44, 2 March 2017 (UTC)

Good news: there are data cleansing companies that will accept a list of email addresses and return you the updated or inactive state of each address. Bad news is that the service costs a significant amount of $$$. Andrewssi2 (talk) 21:07, 2 March 2017 (UTC)

Mh. That's bad. What we could do, however is put a reminder behind the email address of a listing when the website is dead. Sometimes the website is info@exact-same-website.com when the listing is www.exact-same-website.com; now it's pretty likely that the new email won't be the same when the new website is www.totally-different-address.org and usually the website will contain the email address somewhere (though our editors would of course have to look) Hobbitschuster (talk) 21:11, 2 March 2017 (UTC)

I note that in our budget listings, email addresses tend to be 'throw away' hotmail accounts and such. Perhaps we could address 'budget', 'mid range' and 'high end' in different ways? Andrewssi2 (talk) 21:31, 2 March 2017 (UTC)

I'm not quite sure I follow. Hobbitschuster (talk) 21:33, 2 March 2017 (UTC)

Different categories of accomodation will have different types of email patterns. i.e. budget = hotmail.com, yahoo.com etc, mid/high range will have hilidayinn.com, westin.com etc. Therefore applying rules to higher quality accomodation may be easier than budget. Andrewssi2 (talk) 21:58, 2 March 2017 (UTC)

It would need to be a moderately complex bit of software. Suppose the address is someone@example.com.

First test is DNS lookups to validate the stuff to the right of the @ sign. Check whether example.com exists; also look for MX (Mail eXchange) DNS records pointing to other servers that accept mail for example.com & check whether they exist. If you find one or more servers, check if port 25 (SMTP mail) is open.

Looking to the left of the @, some addresses may need to be truncated. It is legal to use an address like someone+wikivoyage@; this should be delivered to someone@ though not all mail servers get this right. This can be useful to sort mail or to tell where a spammer got your address. We just need to check someone@ in such cases.

Assuming you get that far, check if the server will accept mail for someone@. Pashley (talk) 22:38, 2 March 2017 (UTC)

Technically that would work in theory, although I suspect that probing all the servers referred to in our listings would look like suspicious activity and get blocked, possibly providing many false negative results. Not my expert area so I might be wrong.... Andrewssi2 (talk) 22:58, 2 March 2017 (UTC)

So in short: bad idea. Hobbitschuster (talk) 23:02, 2 March 2017 (UTC)

Well, put it this way, the idea definitely has merit, but even our URL checker has a good deal of false negative results. Maybe it is worthing going up to the WikiMedia group to ask if there are any experts? Andrewssi2 (talk) 23:19, 2 March 2017 (UTC)

The DNS lookups are not suspicious or very likely to be blocked.

Probing port 25 to see if there is a mail server running certainly is; spammers might do that. Also, a fairly common way to break into a system is to do that probe, which tells you which server software is running & which version, look the software up on vulnerability list sites, and exploit any hole you find. Pashley (talk) 23:35, 2 March 2017 (UTC)

(edit conflict) By the way, there is interest over on de-WV to have the URL checker there as well. Hobbitschuster (talk) 23:38, 2 March 2017 (UTC)

Checking whether mail servers are running would be suspicious indeed, but connecting to a server to deliver e-mail is not, even if the session is aborted. So if done in low enough intensity, probes should not be problematic. I do not know how many listings we have and what realistic thresholds for servers to react could be (a few hits a day on a server responsible for multiple domains is hardly a problem, while a thousand could certainly be). This cannot be done from home accounts, where the smtp port is often blocked, and one should be careful also with things like greylisting (where the server pretends having temporary problems when connected to from an unknown host; spammers seldom bother to try again but we should).

What about real test e-mail messages with valid sender and reply-to fields, telling about the business being listed here, that we are verifying the address, that they need to do nothing, but are welcome to check info too? Would a listed business be upset about getting such email?

--LPfi (talk) 07:06, 3 March 2017 (UTC)

Actually, we could just send a one time 'Hello from Wikivoyage' message to every listing, informing them that their establishment is listed on Wikivoyage and inviting them to check it out. At the same time any bouncebacks from those emails could be registered and those establishments in the Wikivoyage article updated by a <Dead Email> note.

That said the effort required to set this up is not insignificant, but ultimately probably worthwhile. We might even get some decent new contributors out of it. Andrewssi2 (talk) 07:24, 3 March 2017 (UTC)

A few decent contributors perhaps, but surely a huge amount of touts too ;-) If we ever consider actively emailing companies, we should be ready to deal with lots of business representatives who were never aware of WV and will then suddenly start "improving" their listings. Checking the emailadresses when the weblinks are dead is a good idea straight away (you have to check the company page anyway). I must admit I didn't, in most cases when I replaced dead links. I wonder how big this problem is. Considering the large amount for dead weblinks, I'm guessing not very small. JuliasTravels (talk) 12:34, 3 March 2017 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ How many e-mail addresses are we talking about? And are there other methods of verifying them, e.g., first checking to see whether the e-mail address is still published on their website?

I kind of like LPfi's 'advertisement' model, but it would probably need to be done v-e-r-y slowly. (I might specifically ask them to add something about a different business in the area, e.g., ask the hotels to add or update a listing for a sight-seeing opportunity that they often recommend to guests, and ask the local restaurants to recommend a hotel.) WhatamIdoing (talk) 16:51, 3 March 2017 (UTC)

Touts can be reverted if need be, I think our WV:welcome business owners was written in a spirit that is easily lost after the fifty millionth tout (especially if their English is not as good as they think it is), but the spirit is still worthwhile and valid: People who work in tourism know a lot of sites and stuff and it would be great to use their expertise and better coverage will bring more guests, so it ends up being a win win in the best case. Hobbitschuster (talk) 17:06, 3 March 2017 (UTC)

The problem with WV:welcome, business owners and WV:welcome, tourism professionals is that many folks who come here just to add their one business or one town aren't going to make the effort to adapt their content to fit our WV:Manual of style. They're not wiki-aware, they don't know how things work here and they really don't want to dedicate a whole lot of time to figuring this whole thing out. They might even be surprised that one can edit Wikivoyage, so they just dump the same blurb that they've been sending everyone else "Anyville's delicious and mouthwatering restaurants, sparkling beaches, beautiful sunsets and well-appointed, luxurious inns are fun for the whole family, ideal for business and leisure travellers and great for getaways..." and walk away. Wrong WV:Tone, long on promotion, short on actual info, incurs a yuge SEO penalty as duplicate content and might not even comply with our free licence. Ugh. Unfortunately, that is the tone they need everywhere else they're submitting advertisements, it's just not what we need here.

That's not to say that they couldn't contribute usefully to Wikivoyage, were they to take the time to figure how this darned thing works. I just don't see why they'd want to spend the time to do things our way if they're here just to dump a brief, one-time update to one article without becoming part of the community or devoting effort to understanding Wikivoyage or adapting content to Wikivoyage tone and format. We're just one of a million other sites out there. K7L (talk) 18:04, 3 March 2017 (UTC)

True, but is there anything we could do to make them more inclined to stick around? After all, some tourism businesses have social media presences that aren't just "we're the luvvy duvvy bestest place for getaways" Hobbitschuster (talk) 18:10, 3 March 2017 (UTC)

Aside from the usual efforts to welcome and collaborate with people, I wonder if the content of an e-mail message could encourage the 'right' kind of contributor? "We don't want puffy advertisements. Instead, help us say something funny or add a listing for a quirky local place." WhatamIdoing (talk) 21:11, 5 March 2017 (UTC)

Hm, that might work. Another issue entirely is whether the person who reads the mail will be able to speak enough English to grasp the content of the mail and/or collaborate. Not all of our language versions necessarily have an article for the city in which their listing is located... Hobbitschuster (talk) 21:14, 5 March 2017 (UTC)

"recommend listing" function

Swept in from the pub

Would you think it a good idea to give signed in users (we might want to request autoconfirmed or something, but that's details) the ability to "recommend" any given listing and that to then show up (with some hover-over or whatnot) when people read the article? Of course sad recommendation can always be withdrawn by the initial recommender and we might also wish to timestamp it.

What do you think? Hobbitschuster (talk) 00:49, 18 March 2017 (UTC)

This is similar to a suggestion made in February that went nowhere. See Wikivoyage talk:Listings#Is there a way to demarcate "special" listings?. Ground Zero (talk)

It's not. I know of this discussion, but we would not do an "editorial" thing á la "Wikivoyage thinks this is the best pizza place in New York" but rather a "Wikivoyage User A, B and C think this is a pretty decent place to go". I think that makes a world of difference. Hobbitschuster (talk) 01:11, 18 March 2017 (UTC)

Isn't that what Tripadvisor is for? I can't help thinking an article could get jumbled with recommendations pretty fast. Also, the very fact that we list places is itself a recommendation, since we don't list every single possible listing in a given location, and the 'avoid negative listings' guideline pretty much precludes us from listing something we wouldn't personally recommend. --ThunderingTyphoons! (talk) 02:36, 18 March 2017 (UTC)

Why would we want our readers to any other site? And why would something like "3 recommendations" behind the "last edited" clutter up the site? You can then make the three clickable where it says which users and when... Or something. Hobbitschuster (talk) 03:00, 18 March 2017 (UTC)

My two cents: at the Hebrew Wikivoyage we have discussed the issues related to letting anyone include random listings to the Wikivoyage articles quite a lot, and we have tried to find an ideal solution to overcome the inherent flaws. The main problem as we see it, is that any collection of listings might eventually be flawed and it is hard to determine if it is, unless one unaffiliated person we trust actually goes to all places and rates them all (what I hope is indeed what happens in the case of Lonely Planet recommendations). The worst case scenario with this flaw could even be that some businesses which give really bad services and charge too much would add listings of their "tourist traps" to our articles, presenting themselves in a positive light, for the purpose of increasing profits (and in the example given above, the tourist trap business owner could for example try to get in our favor so that he/she would be considered the Wikivoyage "local ambassador" of his/her region, in order for him/her to make sure his/her business remains the one that seems like the ideal choice to the Wikivoyage readers).

The only solution we have found so far is that each article with listings would also have little Thumbs Up icons in it, and each one of those icons would appear in the top TripAdvisor listing of each category (sleep, eat, drink, etc) so that at the very least our readers would be able to immediately identify which listing in each category is the top recommended one by a wide group of people/opinions (would adding indicators that shows only what the the top listings on TripAdvisor are be allowed in regards to copyrights?). ויקיג'אנקי (talk) 03:21, 18 March 2017 (UTC)

Although in principle I like the idea, in fact I use it on Trip Advisor and Google Maps, I do not think there is the volume of traffic on this site for it to work correctly. Better to concentrate first on improving the mobile user input to get contributions up. --Traveler100 (talk) 07:10, 18 March 2017 (UTC)

I think if we always assume there to be few contributors, we might just create a self-fulfilling prophecy on that one... Hobbitschuster (talk) 17:03, 18 March 2017 (UTC)

That worries me, too. Some sort of very simple contribution system could be a way to get someone started. "Thumbs up" or "I've been there!" might be viable options.

ויקיג'אנקי, I'd worry about one person rating everything. The restaurant closest to me at the moment is a great place if you like beef or pork, but AFAICT its four-page menu contains exactly one vegetarian entree and one fish entree. Sincere, unbiased people on different diets would probably come to very different conclusions about whether to rate that restaurant favorably. WhatamIdoing (talk) 23:30, 18 March 2017 (UTC)

WhatamIdoing, it seems you misunderstood me... my main point was that just like you, I too think that we can't eventually determine quality based on one person's preference (although, in the case of professional widely publicized travel book guides I really hope that they base their recommendation on the opinion/s of their employees actually going to all those businesses) AND therefore, in my opinion, the only option that seems to makes sense for Wikivoyage is to at the very least include "Thumbs Up" icons next to the top sleep/eat/etc locations according to a reliable external source that takes into account the opinions of many people. ויקיג'אנקי (talk) 04:15, 19 March 2017 (UTC)

Small Towns & Boring Places

Swept in from the pub

(New member) but I was wondering about small towns & villages and boring places (like a supermarket). Looked at from a e.g. backpackers they would be dull and useless entries. But looked at from e.g. somebody on a (bi)cycle or walking tour and they are just what you need; does that village have any bars for lunch (and where) or when I arrive at a town, is there a supermarket I can quickly stock-up at. An e.g. bicycle tourist or walker at the end of a long day does not want to be hunting round a town for a supermarket.

Not suggesting the destination pages should become a listing of shops, bars, etc., but maybe at least a couple of convenient bars and a significant supermarket - which ones not important, just one (or maybe one each side of a larger town) and knowing where it is can be a massive help.

I've added a coupe of places that I thought would be useful but probably meet the "boring places" definition's I've read but would be useful to some types of traveller. So am I interpreting the guidelines correctly as most destinations (I've seen) are major cities or tourism centres and there are other types of traveller? Or do the guidelines include for they e.g. significant supermarket, bars, etc. (not as a listings site but for somebody that wants anywhere without hunting around). —The preceding comment was added by PsamatheM (talk • contribs)

On the face of it, it sounds like you are doing exactly the right thing. In a small town, where the supermarket is and what products they carry can be important; in a big city, there are likely to be dozens of supermarkets and convenience stores, so it's unnecessary to list them. (Also, please sign your posts on talk pages - type 4 tildes [~] in a row at the end of each post.) Ikan Kekek (talk) 17:49, 22 March 2017 (UTC)

Welcome, PsamatheM! We're glad to have you. I really appreciate you updating those listings.

I like the idea of a supermarket (or similar place). IMO the best choice would be either a convenient store (e.g., near a bike trail or just off the highway) or something characteristic of the area (e.g., a locally owned grocery store or an open-air market).

I could also see some value in a brief mention of such places as part of another listing:

• Local Restaurant, 100 Main Street, +1 555 555-1234. Open for breakfast and lunch. Be sure to ask for the cinnamon bread at breakfast. There's a laundromat next door, and you can leave your clothes in the washing machine while you eat.
• Farmer's Market, corner of Main and Maple Streets. Open Friday, Saturday, and Sunday mornings. Bakery, drug store, and bank with 24-hour ATM access across the street.

WhatamIdoing (talk) 01:11, 23 March 2017 (UTC)

I would say as a rule of thumb the smaller the amount of choice becomes the more places we wouldn't otherwise list should we list. For example a town the size of San Carlos (Nicaragua) did not have a supermarket until quite recently, so it becomes rather important to mention whether it now has one and where the next one would be in such a case. And we have had a lot of talk about Outports with only one hotel that we would otherwise not list, but it being the only option what are we going to do? Hobbitschuster (talk) 12:46, 23 March 2017 (UTC)

An article on Cooking while traveling might be a fun travel topic, too. We have Outdoor cooking but nothing for cooking in a hotel room. WhatamIdoing (talk) 20:30, 23 March 2017 (UTC)

Is there so much to say that isn't WV:Obvious about cooking while traveling that is unrelated or not analoguous to either outdoor cooking or cooking at home? Hobbitschuster (talk) 20:33, 23 March 2017 (UTC)

Hobbischuster, you seem to discount the possibilities of cooking over a lightbulb or on a hotel iron -- things you wouldn't normally do at home. ;-) Ground Zero (talk) 20:46, 23 March 2017 (UTC)

Who does that? Oh and I am sure there are celebrity chefs who know 100 stunning recipes with electric kettles ;-) Hobbitschuster (talk) 21:01, 23 March 2017 (UTC)

Even if a steak can be cooked on an iron, I have doubts about the safety etc. I have used a kettle to made noodles in a hotel room, but I wouldn't go any further. A more likely form of Cooking while traveling is in a Hostel, and I have just added an eat section to that article - please expand this. AlasdairW (talk) 22:57, 23 March 2017 (UTC)

When I posted that idea, I was mostly thinking about regional issues with ingredients. I have a recipe allegedly from Yehudi Menhuin for a one-pot pasta dish that he could make almost anywhere in the world (pasta, broccoli, tomatoes, and Parmesan cheese, if memory serves). Cheese and flour vary significantly by country, then there are the odd things: it's easier to find fruit than vegetables in Colombia, don't even bother looking for pre-made salad dressing in Italy, some Germans find themselves on a holy quest to locate the one American grocery store that carries soured butter, and German grocery stores don't sell unsweetened chocolate, molasses (aka dark treacle), or four of the nine ingredients for American-style chocolate chip cookies, but you can get really large jars of Nutella at a great (by US standards) price.

There are some planning considerations: if you are cooking for yourself for a week, then you can plan a menu to work together: eggs at breakfast and also in pasta carbonara; ham on a sandwich and also in an omelette, etc. Surely I am not the only person who has packed a spoonful of a favorite spice rather than buying a whole jar at my destination (and a wooden spoon, which "fully equipped kitchens" never seem to have).

I've nothing against a suggestion about how to make a simple quesadilla with a hotel iron or to boil water in a coffee pot, but there are many people traveling in RVs, renting homes, or staying in hotel suites that include a kitchenette and who will therefore have refrigerators, stoves, ovens, and/or microwaves available to them.

Also, I added a paragraph about engine block cooking to Outdoor cooking yesterday, but it's not really an "outdoor" form of cooking. It would be better off in a more generic article. WhatamIdoing (talk) 06:14, 25 March 2017 (UTC)

Weather radio

Swept in from the pub

An edit to Syracuse (New York) reverted the inclusion of one station in the 162.4-162.55MHz band which broadcasts continuous weather. See User talk:AndreCarrotflower#NOAA Weather Radio deletionism. Syracuse isn't infamous as tornado country, but it is snow belt. If NOAA is broadcasting information on when to build an ark, isn't that something the voyager would want to know? K7L (talk) 18:19, 25 March 2017 (UTC)

The 162.4-162.55MHz band can't be picked up by most standard AM/FM radios - specialty equipment is required. Most of our readers don't own that equipment, and Syracuse (New York)#Radio isn't the proper place to inform them of where to procure it. Given the multiplicity of other ways of finding out the weather forecast (even in emergencies), it's questionable whether such a little-known information source, that such a tiny fraction of our readers would even be able to access, warrants inclusion. -- AndreCarrotflower (talk) 19:00, 25 March 2017 (UTC)

I've added a mention of weather radio and VHF marine radio to the severe weather article, but no, these aren't specialised equipment. A quick web search finds them being listed by everyone from Best Buy and Amazon to Walmart or Walgreen's (and I'm sure in 1985 you can buy plutonium in any corner drug store, but...). K7L (talk) 19:28, 25 March 2017 (UTC)

By virtue of having to seek out equipment that will allow you to specifically pick up VHF bands is basically.. well... the definition of specialized.

If only there was some other real time communication mechanism that most most travelers could pick up important notifications on any mobile device. Yep, definitely invest in VHF equipment to lug around on your next visit to New York. --Andrewssi2 (talk) 23:26, 25 March 2017 (UTC)

That depends on your audience; voyagers cruising on small craft may well be carrying a boatload of this stuff already and they are travellers. K7L (talk) 11:54, 26 March 2017 (UTC)

Pocket travel radios are common enough to be their own consumer product category and are referenced elsewhere on the wiki. Just because you don't personally use a technology doesn't mean it doesn't have value to others. There are already instructions for users who don't have a car, why should we presume they also have mobile internet access? 74.111.42.191 17:44, 9 July 2017 (UTC)

Changing our policy on directions

Swept in from the pub

Have a look at Villingen-Schwenningen - the hotel listings were copied out of de-WV where the name of the town and the ZIP code is commonly included. As you can see there, some articles are by nature and necessity consolidated over quite some large areas (as is the town V-S itself) and thus the postcode which is finer grained can give a good first idea where exactly a place is, even in the absence of geo-coordinates. Plus, when has allowing more information last harmed us?

It's just a thought, though. Hobbitschuster (talk) 13:09, 3 April 2017 (UTC)

There is no such thing as a European "ZIP code" as ZIP, ZIP+4 and "Zone Improvement Program" are/were US Postal Service trademarks.

We seem to treat postcodes as useful in London (where SW19 is Wimbledon, for instance) but a US-sized ZIP code can be an entire pop-25000 city.

There are plenty of municipalities where governments have arbitrarily, haphazardly consolidated multiple distinct communities for administrative purposes. Kenora (Keewatin, Norman, Rat Portage), Miramichi (Chatham, Newcastle) are a few; many others come to mind. For these, we would prefer to know which of the individual communities contains each listing. Telling someone "Gatineau" for something that's actually in Aylmer is imprecise and confusing, even if a 2002 forced municipal amalgamation lumped them together arbitrarily.

We're a travel guide. We can't presume the reader knows the area or is familiar with the local postal code system. 75 is Paris, 90210 is Beverly Hills but does anyone know where in Hull to look for J8X unless they're from Ottawa? K7L (talk) 14:47, 3 April 2017 (UTC)

Maybe we want to consider exceptions to the general rule on a country-by-country basis. "More information" is clutter if it's not useful. Readers don't want to wade through clutter to get to the info they are looking for. US ZIP codes and Canadian postal codes do not provide useful directions. UK postcodes, on the other hand, do seem to, at least in London. Do people in Germany refer to parts of a municipality by the postcode? If so, maybe we want to make an explicit exception to the general rule. For my part, I'd purge fax numbers from our listings. It's 2017. Even if a traveller were to want to make bookings by fax, I would bet that a lot of them have been disconnected, and I wouldn't volunteer to test all of our fax numbers to see what bounces back. Ground Zero (talk) 15:18, 3 April 2017 (UTC)

I find postcodes, PLZ or what ever each country calls the code useful when entering in addresses in a SatNav and sometimes into Google Maps. It saves a lot a typing, removes mistakes with language spellings I am not familiar with and makes sure you drive to the correct Newport in the UK or the right Neustadt or Rüdesheim in Germany. (A mistake I know some people have made, trusting too much to computers without double checking the map). --Traveler100 (talk) 15:20, 3 April 2017 (UTC)

Well at the very least in Berlin-Kreuzberg people to this day still use four digit post codes to refer to the two parts of the old district (it's now merged with Friedrichshain, east of the former wall) that haven't been official in over two decades. And yes, I have seen stuff like "pick up xyz in 12345" in Facebook "for sale" groups or the likes. And for cities like Wuppertal or Villingen-Schwenningen the names of former communities that were merged are still often used and are sometimes the basis for post code boundaries, so locals and (some) visitors will be familiar with them and after all, it's useful to be able to ask locals where something is. Hobbitschuster (talk) 15:57, 3 April 2017 (UTC)

• I would have no idea where J8X is (although I wouldn't be able to place most non-major cities or neighbourhoods on the map either) but if I enter "Canada J8X" into Google Maps, it will show exactly where that district is, and if I enter a full postal code (for example "Canada J8X1A1") then Google Maps will show an area along a single street about 150 m long with only 5 houses in that area. That's very precise. Of course, in this case, if I write "7 Rue Bériault, Gatineau, QC, Canada" then it will narrow it down to a single house, but Google seems to know the exact house numbers better in Canada than it does in a lot of countries. --Vagabond turtle (talk) 20:09, 4 December 2017 (UTC)

• Just for the record, in Brazil the zip codes, which we call CEP (Postal Addressing Code) have not-so-recently been upgraded to eight digits; speaking about Brasília where I live, the accuracy is consistently about one apartment block inside a supersquare - thus VERY accurate. They have, after this upgrade, become very popular and useful, on Google Maps and navigation systems, and I can testify on their usefulness when road-tripping on my region with Google Maps navigation; postal codes maybe deserve to be recorded and featured on every Brazilian listing whatsoever. Perhaps the case is to become so in France - last week on copyediting on Lhomme I got complains when deleting the postal codes, for this very reason. Having said all that, I believe that, at this moment of the development of the whole shabang, geocoords are the most useful and important parameters on a listing for localization purposes. Ibaman (talk) 18:23, 3 April 2017 (UTC)

Yes. I think that it would be good to include the postal code (CEP) for places in Brazil because it is often easier to do a Google Map search for the CEP than to search for the street address, particularly in large cities which might have the same street name used in different areas of the city. You can usually give a taxi driver the CEP and they'll use it to look for the destination (hotel, restaurant, etc.) and if Google Maps doesn't list the hotel or restaurant or other, they can at least use the CEP to get close enough that you can usually see the place that you are going to. --Vagabond turtle (talk) 17:54, 4 December 2017 (UTC)

To give a bit of an idea about the size of PLZ (the German shorthand for postal code) areas, here is a map of Dresden, a city of some 500 000, and here is one of Frankfurt am Main. Another idea we might wish to explore (but this might be less useful and more controversial) is to give a "district/town" field with the information ("when different from article name") for cases when our article covers more than one settlement and/or pre-annexation names are still used and/or when people commonly say stuff like "Kreuzberg" instead of "Berlin" when asked where something is. Hobbitschuster (talk) 19:19, 3 April 2017 (UTC)

A lot would depend not only on the size of the postcode area but on street naming practice. For example, pl de la Republique in France or "The Street" or "Brick Kiln Lane" in Norfolk, UK and whatever postcode areas you can quickly get ambiguity and need postcodes to create a usable address. A practice of specifying a town/district "where it is different from the article name" would quickly create further ambiguity as exactly what district somewhere might be in could be subject to opinion or common use often wrong. e.g. a given listing may be considered by many to be in Chateau du Loir, Vouvray sur Loir or Montval sur Loir and all are "correct" and often people will just use "Chateau du Loir" as it is the common use (though maybe not 100% correct).

Then add a complexity where two town lie adjacent and are covered by a single destination page (as they are effectively one town) but later split into two pages (or two pages merged into one when both look a bit empty).

And these days people often want to cut and paste and address from e.g. WV in their web browser into their mapping/directions app. Removing address elements means they cannot do this and/or have to start cutting and pasting the listing address, then cutting and pasting the destination page title into the correct bit of the address or try and manually edit and type the address without spelling errors ... a complete mess. To same a few characters you are losing a lot of usefulness of the whole project. Maybe in the past where all people would do is read the address it was an OK practice but these days with sophisticated mapping and routing on even low end smartphones listing information will be used beyond the WV database. Lat and long is NOT enough (and does not export easily anyway). PsamatheM (talk) 18:35, 14 April 2017 (UTC)

Idea: Make postal code an opt-in feature

Now the following comes with the explicit disclaimer that I do not know the technological details behind my proposal.

That said, what about the following: We add "postal code" as a field for listings, which can be filled out and is only displayed if the user explicitly opts in in the "gadget" tab (similar to how we currently do for NOCC and "dead link"). That way people who consider postal codes, ZIP codes and whatnot clutter won't have to see them (and in fact IP users and "greenhorns" who don't know about the "gadgets" tab aren't bothered at all by them) but users who think of them as a useful tool can have them.

What do you think? Hobbitschuster (talk) 19:12, 3 April 2017 (UTC)

I think that's overkill. I'm in the US, home of a ZIP code that is significantly larger than Israel, and a couple whose population exceeds that of several other countries. So I get the "uselessness" argument, but I don't think that we should over-engineer this. It should always be okay to include postal codes (sometimes it helps a lot, even in the US, especially if city streets are confusingly named), and it should be encouraged when the postal code is a common way for locals to identify the correct location. I suspect that the number of people who are actively annoyed by postal codes these days is very small. (Also, I've had to complete reservations by mailing a paper check to my destination, so a true, complete mailing address may actually be necessary in a few cases.) WhatamIdoing (talk) 04:11, 4 April 2017 (UTC)

I agree that we should retain postal codes and encourage their use--this will be extremely valuable in machine reading for making a Wikivoyage app. (E.g. it can run queries like "cheap restaurants in within [x] km of [location]" or help plan an itinerary--food at this ZIP code, rest stop in between this one and this one, cheap hotel in this one, etc.) —Justin (koavf)❤T☮C☺M☯ 06:57, 4 April 2017 (UTC)

Well the argument that postal codes add clutter was specifically mentioned, so having them not visible by default would reduce the clutter (it would however, arguably, still induce a level of clutter when editing) Hobbitschuster (talk) 13:49, 4 April 2017 (UTC)

If we decide to make postal codes the default everywhere, are we also going to stop editing out repetitive, superfluous default info like City, State/Province? It would save a lot of editors' time, but it arguably looks silly to include that. On the other hand, those things are often included in addresses in articles about places in the UK. Ikan Kekek (talk) 18:25, 4 April 2017 (UTC)

I feel postcodes can be critical even in areas where postcode areas are large. e.g. in France, in some cities give an address without a postcode and it can be ambiguous (due to common street names). Also, e.g. use of SatNavs and similar routing or mapping apps (on GPS or SmartPhone) the postcode can become critical. To do anything to avoid collecting the postcode would severely limit the usefulness of the wiki. In fact I consider the common practice of abbreviating addresses can cause ambiguity and is not "good practice". I've written (a probably too long) thoughts as to why addresses should never be abbreviated User_talk:PsamatheM#Listings_and_postal_codes. The practice is made worse because the original author might enter all necessary details yet others without local knowledge come along and edit-out crucial elements to the information! Best time to collect complete information is when it is 1st entered by the author with the local knowledge - losing it them might mean it never gets completed as needed. Far better to have a full address with maybe an extra few characters than a worthless unusable address that is a few characters shorter.PsamatheM (talk) 17:21, 8 April 2017 (UTC)

Broken Image highlight

We have highlighting (under preference) of bad links and phone format, would it be possible to have one for broken image in listings too? In a large article with many listings using the image= parameter it can take a long time to find the one that is referencing a deleted image. --Traveler100 (talk) 06:39, 16 April 2017 (UTC)

I've had a look but haven't spotted anything. Perhaps someone else can see something that can be done. -- WOSlinker (talk) 08:30, 16 April 2017 (UTC)

Practice of Address Abbreviation/Element Removal/Shortening - And The Shortsightedness of Doing This

An address should be self contained as nobody knows how any user of the data might present the information at some point in the future. As an information resource, needing to take elements of information from different (and unstructured) places to try and reform and build a valid address, and even then have components missing severely limits utility of the dataset.

Use of various SatNavs, phone route planning and mapping apps, etc. - all these apps require a complete address NOT just a street name. The more complete the address the better. So shortening the address and removing everything other than street means that the address cannot be used in SatNavs, phone mapping systems, etc. or at best the address needs manual editing (but probably just wont work).

The listings entry field if for an address NOT a street/number and an address should include all elements in order that somebody can find the location.

My (limited) experience of WikiVoyage is that it is very city orientated. Being a contributor driven project I would guess this is because of the interests and experience of the contributors and thus as the city oriented nature grows, so further users and contributors are more city oriented (if you travel rural areas you would be less likely to use WikiVoyage (not much info) and thus be less likely to become a contributor - so it sets-up a self perpetuating "specialisation". But there are loads of travellers out there visiting and interested in rural areas, visiting and small towns e.g. the large numbers of cycle tourists, sail cruising (mainly visiting and staying in small costal village ports, etc.), walkers, kayak touring, etc., etc. Removing address elements is less crucial in cities (though can still cause grief that traveller e.g. "Great Bar @ place de l'eglise, Alencon" and without a postcode you'd stand a 50:50 of ending up at the wrong place. This illustrates why complete addresses are crucial.

A rural area I know well is 3 villages Aslacton, Tibbenham and Great Moulton (each a few km apart). There are two recreational airfields. So, somebody wanting to get to Tibbenham Airfield after WikiVoyage has removed "Tibbenham" from the listing address would end-up at the wrong place because Tibbenham Airfield is in Aslacton and the airfield in Tibbenham has a different name (and flies different aircraft). Aslacton Village Hall happens to be in Great Moulton NOT Aslacton. Tas Valley Vineyard is administratively in Great Moulton though is only connected to that village by a long strip of territory only a few meters wide and in fact in in another village called Fornsett. These are rural examples from one small locality and all illustrate how incomplete addresses or addresses requiring assumption of elements from e.g. page title will get you to the wrong place. When I lived in France the boundary between to administrative areas passed straight through the middle of my house - in the kitchen I'd be in one area and walk to a sitting room and I'd be in a different one (and it was not a natural boundary but actually deviated from the natural path in order to go through the middle of my house, the house having been built decades before the boundary was moved!).

Mapping is something WikiVoyage is already making use of but it is such a broad area that WikiVoyage can/will never provide a complete solution. There are too many specialisations for people who are travelling. e.g. cycle touring routing is a popular way to visit places/countries (just look at how busy La Vélodyssée or the Danube Cycle Paths get in summer). Yet cycle tourists will use specialised routing systems e.g. http://cycle.travel that place greater emphasis on quieter roads, and lower altitude ascent (fewer hills!) and will provide different information (e.g. altitude plots) - something WikiVoyage will never be doing for the range of different activities. So people are always going to be using external systems to make use of WikiVoyage data and thus in order to be useable that information must be complete (and cannot rely on "common sense" to sometimes add elements from a page title to an address (and then have nowhere to get a postcode from, etc.).

As a collaborative work, different contributors edit and contribute to the same e.g. destination. So the practice of address element removal (shortening) is a disaster as the original author who has specific knowledge enters a complete address and then somebody else without local knowledge comes along and implements WikiVoyage "best practice" or guidelines and removes elements and destroys the previously entered information. Thus the practice should be that addresses should be complete (or as complete as possible) and specify an address without requiring "common sense" additions from other page elements or text. Only that way can the information be of widest use and also be reliable.

Use of Lat and Long coordinates for a listing is excellent and does increase the utility of the data for app systems that import directly from WikiVoyage (e.g. PocketEarth) but for a contributor, finding the Lat/Long coordinates is a bit of a fiddle (no way round that) so I suspect that for accurate locations a full address it the most valuable common easily entered data. Also, offline use (pre downloaded WikiVoyage information) introduces further issues where incomplete address information available.

As more and more people make use of mobile data systems (GPSs, smartphones, smart watches, etc.) and as these systems become increasingly sophisticated, so the useless addresses information (elements removed/shortened) from WikiVoyage will make the resource less and less useful. Current practice seems entirely oriented for the information to be read and used by a human, reading a page of text and any significant project needs to think beyond that (as use of technology has already moved things beyond that).

The practice off shortening and incomplete addresses makes the address only useful where people are reading the address from WV - very limited and shortsighted. PsamatheM (talk) 15:26, 2 May 2017 (UTC)

We only omit the city name in individual listings if it matches the article's title. We do have rural destinations (like Rural Montgomery County), or small towns surrounded by tiny rural destinations, where we may have listings that are out of town in places too small for their own article - for instance Napanee#Nearby sidetracks to at least one tiny hamlet with nothing to see but the local cheese factory. Then there are the municipalities which were arbitrarily created as a merger of multiple towns, Kenora style. If physically the destination is a group of multiple, distinct communities we need to say so (Kenora = Keewatin, Norman, Rat Portage). Conversely, do we need to repeat in every Manhattan listing that the venue is in New York? K7L (talk) 17:10, 2 May 2017 (UTC)

Which means if you cut and past an address into e.g. a navigation app you have to cut and paste the shortened address and then cut and past the article title (maybe having to cut out the (...) clarifying which destination the page applies to, then past that into the correct place in the previously cut and pasted address. There is one mainstream navigation app (very mainstream) where miss an element out of the address and it will happily mark and navigate to a destination - a destination between 2 and 8 miles away from the actual destination!! (2-8 miles are the range of test places where I've found and used for testing). And how many are going to bother with all that cutting and pasting from different places into the right part of the address. In removing an element WV is only considering eyeballs reading the displayed page. There are far more ways to use addresses these days and failing to capture (or subsequently deleting out) complete information severely limits the usefulness of the data. PsamatheM (talk) 18:24, 2 May 2017 (UTC)

(edit conflict) What's more, UK listing addresses include postcodes, as they are incredibly useful in finding a specific location to within a couple of house numbers, and are used in SatNavs, Google Maps etc. In other countries, postcodes may only narrow a place down to being somewhere in a specific town or region, so we don't tend to use postcodes in addresses for listings outside the UK. Generally for France, the street number / name and commune should be sufficient, though sometimes the place may be in a hamlet separate from the main centre of the commune, or in the case of a really large city there may be more than one street with the same name. Then we can use the postcode, or if possible the arrondissement.

The point being, we are geographically flexible when it comes to these things. It is absolutely alright to include the name of the village in a rural address if that village is different to the name of the article's titular place. Any more complex directions can be given in the directions tab, e.g. "Tibbenham Airfield is in Aslacton and the airfield in Tibbenham has a different name (and flies different aircraft)"

Other than that, I have to admit I don't really understand what you're getting at with "The practice of shortening and incomplete addresses makes the address only useful where people are reading the address from WV." Travellers will be reading our listings on the Wikivoyage app or website. What is the issue, as you see it? --ThunderingTyphoons! (talk) 18:37, 2 May 2017 (UTC)

In response to your last comment, exactly how hard is it to type the name of the town or village after the copy-pasted address? :-) --ThunderingTyphoons! (talk) 18:40, 2 May 2017 (UTC)

Can be a complete pain on e.g. an iPhone as you have to put the missing element in the middle of the address e.g. 12 The Street, NR12 3YZ - you have to put the insert tool bit in the middle, type in the page title (excluding and e.g (<county>)), spell it right (given you might be from a country that des not use a Roman alphabet visiting a country using a Roman alphabet and are unfamiliar with spelling of place names ... And if you don't bother some navigation apps will not complain, will mark a point, navigate to that point except it will be the wrong place. why make things harder for users? I appreciate that the site does not like "clutter" but having a valid address is hardly clutter.

The size of a postcode area does not affect ambiguity, it's just a question of the frequency of that ambiguity. e.g. outside the UK (in France) for some places an address without a postcode (or with a partial postcode) and you might end-up at the wrong place. Even in a small city e.g. place d l'eglise, Alencon without postcode and you have a 50:50 chance of ending-up in the wrong place!. Gets a lot worse in some other areas. Much worse in some rural areas. In the UK for some mapping/navigation apps Postcode or postcode and 1st line of the address is not enough and can send you to the wrong place - hence to be reliable you need the complete address but you only find that out when you arrive at the wrong place!. There are many different ways of using addresses outside WV and they have different constraints and the only way of being safe is to provide a complete address. And can you imagine how a user will feel about WV when they use the presented address and they get sent to several miles to the wrong place and all because somebody decided to remove an address element. And having to add instructions to make up for somebody removing address elements is more than messy. PsamatheM (talk) 19:21, 2 May 2017 (UTC)

We simply cannot expand our articles enough to include full address information for every single listing. Many of our articles are too long as they are. Adding "Manhattan, New York, USA" and a zip code to every listing in Manhattan/Midtown is not practical or useful. Powers ^(talk) 20:02, 2 May 2017 (UTC)

So you'd rather see a user end-up at the wrong place than provide an address where you provide an address (but actually don't). There is no reason why the site can't. Better a longer article that gives the user information they want rather than something that just does not work properly. If brevity is more important that accuracy or usefulness then the project is truly doomed. And note that I'm not saying you need the country, nor the county - external apps do not in practice seem to need such info whereas some can need the town/village/city for some addresses in order to work properly. My problem with the current practice is that it causes problems - based on my experience and the effort I've been putting in elsewhere to resolve the issues it causes. Detailed requirements will depend on country but with people going round e.g. removing French postcodes they can be introducing ambiguity (and users can end-up at the wrong place) - what does that say about WV policies to people standing several miles from where they want to be. UK similar issues with removal of city/ton/village for some addresses. I don't know about US, Iceland, Sweden, Fiji, etc. but removing elements could end-up causing problems and what does that say about what WV thinks about it's users (when they have spent real money and time getting to the wrong place). PsamatheM (talk) 20:18, 2 May 2017 (UTC)

A̶l̶e̶n̶ç̶o̶n̶,̶ ̶l̶i̶k̶e̶ ̶t̶h̶e̶ ̶h̶u̶g̶e̶ ̶m̶a̶j̶o̶r̶i̶t̶y̶ ̶o̶f̶ ̶F̶r̶e̶n̶c̶h̶ ̶c̶o̶m̶m̶u̶n̶e̶s̶,̶ ̶h̶a̶s̶ ̶o̶n̶l̶y̶ ̶o̶n̶e̶ ̶p̶o̶s̶t̶c̶o̶d̶e̶.̶ ̶O̶n̶l̶y̶ ̶a̶ ̶c̶o̶u̶p̶l̶e̶ ̶o̶f̶ ̶d̶o̶z̶e̶n̶ ̶l̶a̶r̶g̶e̶ ̶c̶i̶t̶i̶e̶s̶ ̶h̶a̶v̶e̶ ̶m̶o̶r̶e̶ ̶t̶h̶a̶n̶ ̶o̶n̶e̶. If there are indeed two places de l'Eglise in that town (I can't find either on Google maps, which may perhaps prove your point!), including the 61000 post code in the address doesn't help matters at all. But in cases like this, where there is possible ambiguity, there is nothing in site policy forbidding us from putting in more detail to the address, or from filling in the 'directions' box in the listing (e.g. "this place de l'Eglise is opposite the railway station; ignore directions taking you across the river") Indeed, I would encourage everyone to do so.

On the other hand, Wikivoyage likes to assume its readers have a certain level of intelligence, which is why we have Wikivoyage:No advice from Captain Obvious. Frankly, writing the town name (or postcode) when it's the same for every listing in the article (and indeed the same as the title of the article) is an example of this - treating our readers like idiots. --ThunderingTyphoons! (talk) 20:39, 2 May 2017 (UTC)

That would mean the contributor would have to know the full details and restrictions of addressing in the particular town. Most likely the contributor would e.g. take the address from the establishment web site (which would include the postcode and be correct) unaware there was potential ambiguity, then a bit later somebody else comes along, implements "site policy" and makes the address ambiguous and a user ends-up being sent to the wrong place. I checked through the Alencon example some time ago - not going to bother again. It all comes down to common street names close to postcode boundaries.

The "No advice from captain obvious" assumes the only way an address would be used is by being read by eye from the site. Addressees these days have far wider uses and are moved between different places/apps/mapping systems. A mapping app cannot know the page title the address was copied from where a human eyeball can. Removing address components means addresses from the site can only be used within the page by a human reading. Other uses become unreliable at best, sending potentially sending people to the wrong place. A significant proportion of people wont bother to read the address themselves, they'll just cut and paste it into their mapping/navigation app and follow the instructions that gives them-> potential disaster (and long term people starting to question the reliability of WV information).

I'm raising this because of real world experience I have with mapping apps, not from some personal aesthetic opinion. There seems a strong opinion "it's site policy ... end of" even when the shortcomings of that are pointed out. I get the feeling I wasting my time and the WV is happy to present unreliable data and that I'd be wasting my time contributing to the project further (I not prepared to spend significant time entering information that is subsequently corrupted to be incomplete, ambiguous and can misdirect users). PsamatheM (talk) 22:55, 2 May 2017 (UTC)

While I'd be against applying this policy in all cases across the board, I think it's perfectly sensible to allow the inclusion of postcodes and other such address elements where, and to the degree that, they are necessary as disambiguators. -- AndreCarrotflower (talk) 23:33, 2 May 2017 (UTC)

The difficulty is knowing of the potential ambiguity. A contributor might take an address (with postcode) from a providers (e.g. bar) website as in it's full form there is no ambiguity and the WV contributor does not know all details of the locality. Then a few days later somebody else comes along, removed the postcode "because it's site policy" and you've damaged your own data and provided bad info to users. Addressing and use of addresses is a big issue - users spend time and money getting to places and the least WV can do is provide complete information. And postcodes it "the tip of the iceberg" as removing village/town/city can cause mapping/navigation apps to send you to the wrong place. It's more than ambiguity, it's about how some mapping/navigation apps work in the real world. PsamatheM (talk) 23:39, 2 May 2017 (UTC)

You seem to be conflating two different issues. There's no issue with resolving truly ambiguous addresses so that they are not ambiguous. The problem occurs when you have little village or mid-sized city articles where the name of the village or city repeated in every.single.listing, even though the name of the city is quite clear from the article title. Powers ^(talk) 19:24, 3 May 2017 (UTC)

@PsamatheM: There are multiple perspectives to look at this from.

From a "data science" point of view, I agree with you completely. It would be ideal if every listing included the full address (street, city, state, and country), and a "display" address that only shows the necessary details, and lat/long. You'd use different ones in different circumstances. (Displaying a web page, or especially displaying listings in a WV smartphone app? Use the short "display" address. Copying to the clipboard? Use the full address. Sending to a navigation app? Use the lat/long, or the full address.)

Unfortunately, that ship has sailed. WV derives from WT with more than a decade of history and some millions of listings, and it's infeasible to go back and retroactively add "full" addresses to all of them now.

The reason that short truncated addresses are preferred is simply for brevity. It's the same reason abbreviations are used in addresses in listings: it takes up too much space on the screen or page to say "Wednesday" or "Boulevard" compared to "W" or "Blvd". Adding "Manhattan, New York, NY, USA" to every single listing would just clutter up the screen.

You're right that truncated addresses can be ambiguous. And if that's the case, there's nothing in our policy that disallows adding more information to the address in order to disambiguate it. Perhaps we need to edit this page to make that more clear.

I think you're a little too hung up on a very uncommon scenario. Entering the city is not very onerous; the user ought to already know that they're reading an article on Manhattan or NYC, and know to type that in themselves. Moreover, most satnavs or online maps I've used don't require it every single time; either there's a "recently used cities" list to pick from with a single click, or it's smart enough to search by proximity.

If you're worried about other editors removing details that were added to disambiguate an address, put an HTML comment in the address explaining why the extra parts of the address are necessary. Or, as someone else suggested, put that information in the "directions" field for users to see, since users might also get misled unless they're made aware of the problem.

But if you're suggesting that we should change WV policy and insist that every listing on all of WV be changed to include more parts of the address than the minimum necessary, I have to oppose that. Doing that would be very harmful to the appearance and readability of articles, and would have extremely limited benefits, whereas including lat/longs in every address solves the same problem much more effectively. --Bigpeteb (talk) 20:16, 3 May 2017 (UTC)

@Bigpeteb: Some mapping/navigation apps will take a partial address with components missing and happily mark/navigate to the wrong place - no warning, nothing untoward just you arrive at the wrong place (and this is from very mainstream providers and something I have personal experience of). Not suggesting that people go back and update every existing listing (impractical) but at least that new listings keep entered data and have a safe useable address. People will only add back the page title to the middle of a cut and pasted address if they are aware of the requirement and the mapping/navgation app I'm thinking about wont warn the user.

The difficult is knowing when ambiguity can happen as I expect many addresses are harvested from web sites (cut and paste) and will include the e.g. city, maybe for good reason. So the person harvesting the address will probably not be aware of the ambiguity that removing a component can introduce, so cannot add comment or directions and policy is then damaging good data. This is illustrated above where a contributor could not find the example I gave so how would they manage to realise the ambiguity when they can even find one instance of the street.

My suggestion is that where the page name in included in the address that others leave it there rather than have people with no local knowledge spend their time going round removing entered data (address vandalism). Also that the site policy reflect this (i.e. don't say it should be removed). So no "insist" but start be preventing the vandalism done in the excuse of "site policy". Accuracy is more important then brevity. People need to be considering the users and how they might be using the data. What this policy is considering is placing page appearance ahead of user interests. One significant use of WV is 3rd parties taking the data and using it within their own apps (i.e. outside the www.wikivoyage ... browser page display). Long term the data has far broader use that online web browser display. The project needs to think long term and the best time to collect complete data is on initial entry - otherwise WV will never change anything (any aspect) because of historical "too much work to go back and change everything ...". If I spend time entering information now I would expect it to be useful for many many years so the more complete it is, the greater its longevity and the broader its use. Just thinking about online www.wikivoyage ... page layout as a determinant of what data is collected is a "very poor" way to collect data. PsamatheM (talk) 21:16, 3 May 2017 (UTC)

@Powers: The issues arise when the data is used outside WV online www.wikivoyage ... web browser display. e.g. when an address is cut and pasted from WV into an external mapping/navigation app and that is where problems can occur where components are missing. And when they do, they can occur without error or warning messages from the navigation/mapping app - they just take you to the wrong place. In real world test cases I've been using helping another developer resolve these issues (caused by the platform provider API removing address elements) the place it navigates you to is between 2 and 8 miles from the true location. WV needs to thing of the information as data and ww.wikivoyage... online web browser is just one of many ways to use that data e.g. offline viewers (e.g. Kiwix, within mapping apps (e.g. PocketEarth). PsamatheM (talk) 21:16, 3 May 2017 (UTC)

All you're doing is repeating yourself. You're not actually addressing our arguments. You are completely ignoring cases where there is no problem cutting and pasting addresses. Powers ^(talk) 01:43, 5 May 2017 (UTC)

@PowersHow will people know when there is a potential ambiguity or incorrect location from address component removal? I've seen one case of address vandalism recently where the vandal clearly did not know the area concerned, removed a component and the address "suffered" (though probably not impactive navigators, just unclear to users because of common naming practice in the area). How does an address vandal know what certain navigation systems require in order to correctly locate a destination. Do they bother checking or do they just launch in and damage data entered by others. I know of specific test cases I've identified working on issues caused by component abbreviation/removal in one (mainstream) navigator (and they do not have the same issues in other navigation systems). I can't say that removing any component from any address is safe without making extensive tests. Brevity is clearly not the reason as I randomly checked a case of address vandalism done in the last few days and the town was removed but the 1st address line still read along the lines of 12 xyz Road" (i.e. "Road" rather than "Rd").

For example, on a page titled "Caister" and an address "12 The Street, Caister, Norwich" What would the address be shortened to under site policy? (given how address vandals seem to have absolutely no appreciation of local constraints). And putting in an HTML comment - I've spent significant time contributing and I don't know how to and a casual traveller adding/updating a listing whilst on their travels would not even appreciate the need let along know about the need ('cos it's a well weird practice) PsamatheM (talk) 14:20, 5 May 2017 (UTC)

n.b. Is there a good practice way to "maintain the responding indentation practice and "reset" the indentation otherwise we'll soon be down to a 1cm wide column hardly wide enough for longer words and many feet long (vertically). I figure just jumping back left will imply the response being related to a differnet previous comment. Any arrow symbols, or anything ? PsamatheM (talk) 14:20, 5 May 2017 (UTC)

Another concern is that the practice seems to be diverting contributors to spending time doing nothing more than adjusting this "debatable" practice. I've been contributing for a short time (in days) but been spending significant time adding a fair amount of content, mainly because in the geographical areas I know I was quite horrified by the gaps, missing destination pages, poor and missing content in other pages and despite having created/updated a fair number of pages outline->usable still have a pretty daunting list of further work that is really needed (and that's for a pretty localised area). When there is so much poor/missing content, if people are prepared to spend time working on the site would it not be far better that they add real content that can be used by real travellers. As a traveller I'd rather see info about somewhere I want to visit rather than worrying about an extra space in a phone number and having a invite to create a page for where I'm going next! The pre-occupation with spending effort on minor issues is detracting from what should be the main purpose - for the traveller/user. Things like abbreviating addresses, removing an extra space from a phone number should be of 2ndry importance once the destination and information coverage is adequate (which certainly for some areas it isn't).

And the reason I'm going on arguing this is that I have this rather long and daunting list of quite major holes in destinations and it's growing and I'm not happy about the idea of spending all that time and effort for a project I believe has major shortcomings (and the address issue is a very major shortcoming based on my personal real world experience). So important for me it's deciding whether to spend my time doing other things or to contribute here; hence my pursuing this. The project could be of real value to travellers but the data must be valid (e.g. why listings have a "last updated date"). PsamatheM (talk) 14:46, 5 May 2017 (UTC)

Complaining about us "wasting time" debating this is an odd thing to say, since you're the one who raised the question to begin with.

Yet I agree with you: this is not the best way to spend time contributing to WV. If you want to have the maximum impact, you should:

• Continue to add listings in places that don't have sufficient coverage (which is enough to keep us all busy for many years to come)
• Tag listings with lat/long. That is the most unambiguous and most helpful way to tag listings for both editors and readers.
• Tag listing addresses as you see fit. You presumably know the specific geographic areas better than we do, so we'll trust your judgment. If you say an address is ambiguous without including the city, then include the city. Preferably leave an HTML comment (using <!-- -->) to explain to other editors why the city should not be removed.
• Accept that WV is a wiki with many editors. Yes, someone might change content you added. That happens. Nobody "owns" a page on a wiki. If you want to use your watchlist to patrol pages looking for detrimental changes to addresses and undo them, go ahead. If it continues to be a problem, use the Talk page to address it. That's all that you can really accomplish immediately. Changing WV's style for addresses would mean changing all existing pages and would probably require some rather difficult development of a bot to automate the process... that's a long, drawn-out process that isn't going to happen in just a week or two.

I'm still not convinced that you're right. You seem to be editing mostly pages in the UK, where there are extremely fine-grained post codes in use. The policy on this page specifically calls those out, because the post code is much more specific than even a village/town/city name. And since you're including post codes anyway, I don't understand why the less-specific town or city name would be necessary.

But I'd much rather have you contributing than not! WV has huge gaps in its content as soon as you get outside of major cities, so the work you're doing is definitely appreciated. I'd rather have a few pages with addresses that may or may not be formatted ideally than pages with no content at all. --Bigpeteb (talk) 17:58, 9 May 2017 (UTC)

@Bigpeteb"I'm still not convinced that you're right. You seem to be editing mostly pages in the UK, where there are extremely fine-grained post codes in use." The problem relates to how some navigation apps use that postcode. For the UK Royal Mail (post service) the postcode does provide a very localised location. However, many navigation and mapping apps are not developed in the UK and don't include specific UK considerations and don't place the same importance on the postcode - resulting in one I'm aware of requiring the full address (including the town/city) to get you to the correct place (as described above). e.g. where I currently live my postcode does help the Royal Mail (main letter post service in UK) deliver my mail but also often misdirects courier delivery vehicles to the wrong place (real world experience). PsamatheM (talk) 12:01, 12 May 2017 (UTC)

In effect the address is a description describing helping the user find the desired place. The better the description the easier to find the correct place (and thus the better for the user). Different boundaries are not all given equal prominence. So a destination page for a destination will not be constrained to the postal boundary for that place (e.g. Great Yarmouth as a destination page in practice includes Great Yarmouth and Gorleston whereas a postal address will distinguish between the two places (I don't think the page should be "Great Yarmouth & Gorleston" as in common usage the "Great Yarmouth" is what is used, addressing being more specific. Some addresses include more "elements" than others (depending on the particular place) and a visitor may easily not be aware of the need for additional "elements" to be added to an address for it to provide a adequate description. PsamatheM (talk) 12:01, 12 May 2017 (UTC)

@Bigpeteb (on a more personal note/response to your comment) "But I'd much rather have you contributing than not! WV has huge gaps in its content as soon as you get outside of major cities, so the work you're doing is definitely appreciated. I'd rather have a few pages with addresses that may or may not be formatted ideally than pages with no content at all". I suppose that's why I'm hanging on (putting off contributing, not completely walking away). I was shocked by the "holes" or "gaps" in the site for areas I knew about. I don't contribute to OpenStreet Map because areas I know about are close on 100%. I felt I should contribute to WV because of the (shockingly) poor coverage of areas I know about as I see it as a potential fabulous resource. But it takes significant time to contribute and to do that one has to believe in the project and with the issue being discussed is of such importance and has caused me such grief (outside of WV) and time it more than seriously impacts my belief in the project (with current site policies). Where you mention the gaps being worse outside cities, from my own experience the addressing issue is worse in more rural areas and I wonder if it has not come up because because WV does seem more "city centric" (not deliberate). There are so many other forms of travel WV could help. PsamatheM (talk) 12:01, 12 May 2017 (UTC)

@Bigpeteb (responding to an earlier aspect you raised) From a data science point of view, I agree with you completely. It would be ideal if every listing included the full address (street, city, state, and country), and a display address that only shows the necessary details, and lat/long. Youd use different ones in different circumstances. (Displaying a web page, or especially displaying listings in a WV smartphone app? Use the short display address. Copying to the clipboard? Use the full address. Sending to a navigation app? Use the lat/long, or the full address.) Unfortunately, that ship has sailed. WV derives from WT with more than a decade of history and some millions of listings, and its infeasible to go back and retroactively add full addresses to all of them now. I appreciate that changes to the system are not 30 second tasks but the longer the current system is continued the worse the correction will be. As far as "too late", I'd suggest the code change/listing editor change would be to be to provide two address fields "short address" and "full address" and where only one was provided the "submit" would copy the one provided into the other (i.e. make them the same. On this introduction a full dataset sweep would be made and all listings would have their existing address (effectively the "short address") copied into the full address. But I appreciate that requires a code change which is undoubtedly not something easily initiated. I would agree that the dual address system would work and is something I would full support (as addressing my concerns and those of others seeking brevity). PsamatheM (talk) 12:01, 12 May 2017 (UTC)

@Bigpeteb Please don't take my multiple responses to your comment as any form of rudeness or defensiveness on my part, just I felt it best to reference each point I was responding to for clarity. I fully accept (and welcome) the site being collaborative and fully accept on occasions that means others will make changes to content I added that I may not agree with (it is one of the great strengths of such projects and particularly important for WV as it will always be an ongoing work updating to changes in the real world). My issue comes with on-mass weakening of information that would help travellers/users from those without local knowledge and solely for reasons of "site policy" (hence my raising this to get site policy changed). PsamatheM (talk) 12:01, 12 May 2017 (UTC)

Commenting Question (@Bigpeteb said) Tag listing addresses as you see fit. You presumably know the specific geographic areas better than we do, so we'll trust your judgment. If you say an address is ambiguous without including the city, then include the city. Preferably leave an HTML comment (using <!-- -->) to explain to other editors why the city should not be removed. Through some experimentation I've found a way to get the comment not to display is the user viewable page but don't want to do many in case I'm doing it wrong. Through experimentation I've found I need to use the less that character (not the ampersand form) !-- then comment then the greater than character (not the ampersand form). My "test" example for checking is Great Yarmouth#Get in on the train station address. Is this the way to do it correctly ? Using the HTML code tags seems to cause everything to be displayed (I'd hate to add loads only to then have it pointed out they are all done wrong! Also, I've added a long reason or should I just say Leave city with no explanation ? PsamatheM (talk) 10:27, 13 May 2017 (UTC)

Yes, the way you did it in the last version is the way to insert HTML comments. One should use them sparingly as you say. In this case the comment could be added to the first paragraph of the article, perhaps: "... in the United Kingdom. This article includes also the neighbouring ..." --LPfi (talk) 11:57, 13 May 2017 (UTC)

My concern (and hence adding to listing address) was that for others to notice it using the listing editor it has to be in the listing. PsamatheM (talk) 14:22, 13 May 2017 (UTC)

The wording used does not tell me anything about what I should or shouldn't do while editing the listing – probably because I don't know the format of UK addresses. Perhaps something about the station in fact being in NR (whatever that stands for) and not in Great Yarmouth proper is what is hinted on and could be told in plain text. On the other hand I think it is useful for any reader to know when a destination guide is about an area differing from the area with the name used as article heading. --LPfi (talk) 17:06, 13 May 2017 (UTC)

How to deal with multiple phone numbers?

I'm noticing that a lot of listings are having people force two different phone numbers into the 'Phone' field ( e.g. "+972 8 6588047, +972 52 8977010/1" which causes a validation error. I'm guessing that this is because most business owners want to be contacted on both landline and mobile these days. (See the Alpaca farm in Mitzpe_Ramon)

To resolve this issue we can delete the second number, but I feel that this is losing some valuable data just for the sake of conformance.

At the same time we have 'fax' and 'toll free' fields which are almost completely redundant in this day and age (Please no sanctimonious comments about third world situations; it is very rare these days that a toll free number is on genuine help to a traveler anywhere in the world).

The way we could resolve is to:

1. Remove the second number (no change required) - OR
2. Add a 'mobile' field to the listings

--Andrewssi2 (talk) 23:46, 10 May 2017 (UTC)

I would support adding a "mobile" field. Ikan Kekek (talk) 23:50, 10 May 2017 (UTC)

It was the fact the listing was using the / to show a 3rd number that was giving the validation error. Fix. --Traveler100 (talk) 01:56, 11 May 2017 (UTC)

We occasionally get weird 'hybrid' listings where a venue contains a shop or restaurant with a separate number:

• Persian Golf, ☏ +98 123456 (pro shop), +98 00000 (clubhouse). Hotel on golf course, the 19th Hole restaurant at the clubhouse is worth a visit. Beware of the sand traps. 

Even if we add a "mobile" field (which would fit mostly small, B&B-style businesses) the occasional special case with multiple numbers will arise.

I'm not sure what to make of fax and toll-free. I still list them because the properties themselves are still listing them on their primary websites. My own workplace no longer publishes a fax number due to widespread abuse (Canada lacks a junk-fax ban with any teeth) but the same questions could just as easily be raised for e-mail and other media (create an e-mail address, use it to register a domain, expect two spam messages in the first forty-eight hours). I hesitate to include e-mail addresses (for spambots to harvest) if a venue has any other Internet presence. Nonetheless, if some restaurant is masochistic enough to publish a fax number knowing that it will only receive spam and no legit traffic, their call.

The local and freephone numbers for a hotel may actually point to different places - most often in chain properties where the local number reaches one hotel directly and +1-800-whatever is the franchise national reservation service. K7L (talk) 14:05, 11 May 2017 (UTC)

Not for nothing, but we did used to have a phoneextra field in our listings for just this reason. Powers ^(talk) 23:43, 11 May 2017 (UTC)

I have on a number of occasions wanted a "mobile phone" listing field. In fact, through the documentation I found there was such a parameter and added it manually but it did not display as part of the listing. I felt it relevant because some listings I added only provided a mobile phone contact and call charges to mobile can (in UK) be much higher than to landlines (depending on your contract/mobile/etc.). Generally when adding a mobile (the only available number) to a listing I added (mobile) after the number but felt this was not a tidy solution. In addition to mobile numbers I also found some businesses only providing "premium" numbers (often charged at higher rates or always changed whatever you contract/mobile) and similarly added (premium) after the number to indicate this. That a number is moble or premium is identifiable from the number itself (at least in the UK) but you cannot expect travellers to be aware. PsamatheM (talk) 12:11, 12 May 2017 (UTC)

My ideal solution would be to add both mobile and a premium fields to the listing editor (and the way the listings are displayed) as it is unlikely that many businesses would offer all or those that do offer e.g. landline and mobile might be harder to contact on the landline. The different types of number would need suitable indication in the displayed page listing. PsamatheM (talk) 12:11, 12 May 2017 (UTC)

I would agree about the removal of the fax number (even if only from the displayed page listing) not only because fewer companies now have such devices but I suspect fewer travellers have the capability to easily send faxes PsamatheM (talk) 12:15, 12 May 2017 (UTC)

Side point: in places like Nicaragua, businesses often have two mobile phone numbers and no landline. Why? There are two mobile operators and calling from one to the other is pretty darn expensive. Neither the current setup nor any of the proposed changes deals with this well.

Is the calling across mobile operators something that travellers/visitors to the country would (reasonably) be aware of ? If so, although messy, does it address that issue to use a mobile listing field with e.g. +xx 1234 567890 (operator 1 name) +xx 1234 098765 (operator 2 name). Messy and if a visitor/traveller would not be aware of the reason then would not help. PsamatheM (talk) 12:46, 12 May 2017 (UTC)

I'd expect numbers on different carriers which cost a different amount to call would be identifiable based on area code prefix. For instance:

• 1 Hornes' Ferry, 2262 Highway 95, Wolfe Island, ☏ +1 613-385-2402, +1 315-783-0638. seasonal, 1 May–15 October. Runs hourly from end of Ontario Highway 95 on Wolfe Island to downtown Cape Vincent NY, about 10 minutes. Privately owned. C$15/car one-way, C$2/passenger. 

Two different carriers. +1 613-385- is Bell Canada. +1 315-783- is Verizon Wireless. See what they just did? K7L (talk) 14:24, 12 May 2017 (UTC)

I think that must depend very much on the country. Although the UK does not suffer the different rates within vs between carriers, we do have number portability (you can change carrier taking your full number with you, prefix and all) so you cannot recognise the carrier from the prefix code (too complex even without number portability). Although not so brief or tidy, for a visitor maybe unfamiliar with the different carrier prefixes (and in countries where the carrier is relevant) would +1 613-385-2402 (Bell Canada), +1 315-783-0638 (Verizon) - although, not being familiar with the US/Canada contracts I have probably missed the importance of one being Canadian and one being US (or whatever the situation is). And probably having missed your point, the risk of international mobile calls must be a potential big cost (though maybe anybody with a mobile would be aware of that and where their SIM was from) PsamatheM (talk) 14:45, 12 May 2017 (UTC)

I think it would be a good idea to have mobile and premium options in the listing and some icon to show the distinction. It can make a difference on costs depending on where you are and what contract you have. My land-line is fixed fee per month for anywhere in Europe, North America and Australia to any other normal land line number, but I have been caught out a couple of times with a large bill when I have unknowingly called a UK premium number. Also in a number or counties mobile to mobile can be on fixed contract but mobile to land-line can be an extra per minute charge. I have a global roaming fixed fee contract for mobile, and even on that I think the premium gets added, but I know from other they what to know if mobile or land number is being called because of the contact they have. --Traveler100 (talk) 15:11, 12 May 2017 (UTC)

A call to +1 315-783-0638 from the ferry dock (while not a premium number) would bill the caller for long distance to Watertown. It's usually possible to guess from the first few digits whether a call is going to be flat-rated or an expensive trunk call. Yes, the ferry operator would be able to switch from Verizon to another wired or wireless carrier in-region and keep the same number, but it's still a Watertown number and would be billed accordingly. K7L (talk) 15:21, 12 May 2017 (UTC)

In Finland there is a legal obligation to give the price wherever a "premium" number is advertised (by the company). Even with quite moderate surcharges it is nice to know, and fearing outrageous prices is not nice (as you would, if recognizing a "premium" prefix), so I was always uneasy when adding such numbers. It was quite recently I learned you could have a comment in parenthesis in the phone field – the option should probably be nice to see it is clearly explained on this page, like the possibility to give more than one number in the field (is that a new feature?). --LPfi (talk) 15:40, 12 May 2017 (UTC)

Giving the cost in some countries can be complex and subject to being wrong as call charges are increased and listings not quickly updated. And you might have a connection fee and then a cost per min, and different providers/carriers might charge at different rates, some contracts might include the number for free whilst others might not ... PsamatheM (talk) 15:53, 12 May 2017 (UTC)

Given the potential complexity and that some travellers may be aware of cost constraints and the desire for brevity on e.g. mobile carrier and other not I wonder if the solution is footnotes or pop-ups. I appreciate that WV has a policy of no footnotes and I don't appreciate the background but one option might be e.g. +xx 1234 567890 (carrier 1) +xx 1234 098765 (carrier 2) ^[1]. with a footnote explaining the importance or a link to the country page Connect section (or the part explaining the reason). Ot one of those ? marks in a circle where clicking on it displays a pop-up (maybe that showing a link to the relevant explanation in the country page). No idea about how but a thought. PsamatheM (talk) 15:50, 12 May 2017 (UTC)

Free places to sleep

Swept in from the pub

Moved from Wikivoyage talk:Requests for comment:

I want to ask that i add somany thing if i add budgetery stay on sleep safe point of vrindavan then what wrong if a traveller that doesn't have money then he can get stay on that ashram if it is for promotion purpose then it is fine. I have to say that i explaining everything that have historically near by places and Ashram having Sidh Bholenath temples. Girriraj Bhawan Bengali Ashram (talk) 03:31, 11 April 2017 (UTC)

@Girriraj Bhawan Bengali Ashram: This is a good point. If you can find places to add these ashrams to Wikivoyage, that would be very helpful. —Justin (koavf)❤T☮C☺M☯ 04:02, 11 April 2017 (UTC)

It's perfectly OK to list ashrams, anyway. Just put each listing in the article for the nearest town. Ikan Kekek (talk) 07:09, 11 April 2017 (UTC)

It is possible that I was the one who reverted it because it sounded touty and contained a smiley. Hobbitschuster (talk) 21:36, 13 April 2017 (UTC)

borked "go" listings

Swept in from the pub

I have been trying to add a listing for the railway station of Romanshorn which includes the Wikipedia link. However, this only seems to work when I make it a "listing" type listing and changing it - even manually - to a "go" listing borks up the stuff somehow and the Wikipedia icon disappears. What gives? Hobbitschuster (talk) 21:17, 15 April 2017 (UTC)

• • Works as a listing -- as a listing with type=go -- and as a go template listing for me. -- Matroc (talk) 18:37, 16 April 2017 (UTC)

On a somewhat related note, why are there more listing types than can be found in the editing shortcuts and why does "do" use a bicycle as a symbol (for me at least, getting on my bike is about getting from A to B and not about sport or entertainment) Hobbitschuster (talk) 18:52, 16 April 2017 (UTC)

Doubtful establishments

Swept in from the pub

In Wikivoyage articles, I often find establishments (museums, eateries, hotels, etc.) that I suspect do not operate any more. They do not appear on Google Maps. If they appear in a Google search, the references are 10 years old. They have no website, or they have a web link to an irrelevant page. The question is: Is there a way to flag such entries as doubtful, or should I delete them? It is impractical for me to go the address to verify. Thanks. TheTrolleyPole (talk) 02:01, 15 June 2017 (UTC)

My preferred course of action is to call the phone number (either the one listed in the article or anything you can dig up on Google). Even if it's not the establishment itself that answers the phone, there's still a good chance that whoever has the number now will have fielded calls from time to time from people trying to reach the establishment, and may be able to verify for you if it's closed or even, if it does remain in existence, what the new number may be. Failing that, it's probably best to delete the listing. -- AndreCarrotflower (talk) 02:07, 15 June 2017 (UTC)

A lack of web site is in itself not an indication of a closed establishment, but if I fail to find on Google Map, with Yahoo search and sites such as TripAdvisor and Yelp have no reviews of the establishment in the last 3 to 5 years then I delete. In locations were internet usage is low I would maybe move the listing to the talk page with a comment, move back to article if anyone knows better. --Traveler100 (talk) 05:13, 15 June 2017 (UTC)

I have this problem with South Korean articles, where turnover of businesses is very high. I agree that the absence of a web site does not indicate a closed business.

Google Maps has good listings (and they actively manage them as best they can), so I often check there, but generally speaking I don't close a business unless I have first hand knowledge of the fact. --Andrewssi2 (talk) 05:29, 15 June 2017 (UTC)

Put them in hiding brackets <!-- such as this text --> until the issue is resolved. /Yvwv (talk) 05:30, 15 June 2017 (UTC)

Given that we don't actively manage these listings, I fear that using hiding brackets would be effectively the same as a deletion. --Andrewssi2 (talk) 06:22, 15 June 2017 (UTC)

I agree with Traveler100's approach. We know that there is a lot of turnover in businesses, and that we don't serve the reader well by keeping listings of closed businesses. If a business used to have a webpage, and now doesn't have one and doesn't have Trip Advisor or other reviews, it is reasonable to assume that they are gone. In cleaning up deadlinks, I have found businesses that have let their webpages expire, but continue to show up in a Google search, so I keep the listing and remove the link. Ground Zero (talk) 11:28, 15 June 2017 (UTC)

When updating sections with listings Google Maps (and Google in general) is my go-to resource. If they say it's permanently closed and it doesn't have any web presence at all (website, facebook etc.) and there aren't any reviews on sites like Tripadvisor, Yelp or such for the last year I think it's pretty safe to delete the listing. Needless to say, if their own website or fb-page say they have closed, then it's also safe to delete it. Nevertheless, if I find any "signs of life" from the last few months or so (e.g. the establishment has been mentioned in a news story), I let the listing be.

It's of course a bit harder for places with low Internet usage like Africa, but usually there is something online, at least some review or the business marked on either Google and/or Openstreetmap. If there nevertheless is nothing at all about the business and if there according to the article history have been many years since it has been added to WV, and there moreover are a lot of the same kinds of businesses in the article, I think it's safe to delete it.

I have a feeling it depends on the type of business as well, restaurants and bars are more likely to close than hotels and stores, while sights, attractions and activites are more permanent. --ϒpsilon (talk) 12:05, 15 June 2017 (UTC)

I have always assumed that for most places WV is not aiming to be a complete directory listing every establishment. Where a listing was vague (e.g. just a name) I regard it as pretty useless anyway and if no web presence found then it was not much use to people wanting to visit so no real loss. If an address was included, if the place was worthwhile often local papers will have a brief report of its closure (returned from a Google search) or an address search sometimes gives a property website "for sale" listing. Where it looks likely it's gone and if no comment about it being "the best, not to be missed" (i.e. just another e.g. bar) I'll try and replace it with something similar nearby. I have found that some pubs/restaurants drop their web site and switch to only Facebook and that Google does not always list their Facebook page in their 1st page search results so I also always do a search on establishment name and "Facebook" and that has shown some to still be operating. PsamatheM (talk) 12:28, 15 June 2017 (UTC)

These comments feel like a consensus is emerging that would be useful to incorporate into Wikivoyage:Listings as a guideline for deleting listings. Agree/disagree? Ground Zero (talk) 12:36, 15 June 2017 (UTC)

Likely Wikivoyage:Listings is the wrong place for this. There is no one single "right" method to spotting venues which have closed. This sort of suggestion might be appropriate for a task description in a Wikiproject-style expedition, but it's not hard and fast policy. An approach which works in a destination with cheap Internet telephony and widespread Internet access to every tiny mum-and-pop corner store may break down in a country which charges painful premiums for inbound international calls. In a war zone? Everything falls apart and it's very difficult to know if any of the listed POI's still exist. We must adapt to the situation on the ground. All we know about Aleppo might be what we read in a newspaper, or whatever passes for a virtual newspaper this week. K7L (talk) 18:05, 15 June 2017 (UTC)

"There is no one single "right" method to spotting venues which have closed." -- Yes, that would be the difference between a policy and a guideline. I am proposing a guideline to help editors decide, not a policy to which they must adhere. I see that WV:Listings is a policy page, but that would be the place that people would look for advice on how to handle this, so we would have to be clear that it is a guideline, especially for people who may read the page too quickly and jump to the wrong conclusion. Ground Zero (talk) 19:34, 15 June 2017 (UTC)

I think Traveler100 suggested moving doubtful listings to the article's talk page. So, I could add a "Doubtful establishments" section to the article's talk page, and move the listing there giving a reason. Would there be any objection to doing this? I think a better solution would be to create a special template to flag a listing as doubtful within the article giving the reason for flagging (e.g. {{doubt|address not found on Google/Bing maps|June 2017}} ). I think half the eateries in the article for Saint-Pierre (south of Newfoundland) are doubtful.TheTrolleyPole (talk) 20:09, 15 June 2017 (UTC)

Maybe one needs to think about it from a users/travellers perspective. Would you want a guide book where half the listings were marked as "doubtful"; how long would you bother to wait for a reply to an e-mail to a "dubious" listing (would you bother to even send one); how far would you walk to a "dubious" listing ?, etc. Listings will never be 100% but my personal opinion is when reviewing/updating a page one should make as sure as possible that it is accurate. Would listings marked as "dubious" add to the quality or usefulness of the site ? Maybe look at questionable listings in the light of whether you'd add them as a new listing. PsamatheM (talk) 20:21, 15 June 2017 (UTC)

I think that a lot depends on the listing. If a city has 10 places to eat and I have doubts that one is still open, I would generally remove it without delay. The case of a village with only one place to eat is more difficult, and I would spend more time researching, and in this case expressing doubt may be useful.

However I am more inclined to leave a see or do listing in place. A park, monument or volunteer run museum may not have much presence online. In these cases adding a note about the doubt may be worthwhile - I might not walk far to such a dubious listing, but I would ask locally. If significant see listings have definitely closed it may also be worth saying so in the article, as travellers may have heard about the sight elsewhere, and assume that we have just missed it out. AlasdairW (talk) 22:23, 15 June 2017 (UTC)

I like AlasdairW's suggestion to express doubt as a comment in a listing if after research there is still doubt. On the other hand, I found another tool to resolve doubt: even a remote location such as Saint-Pierre et Miquelon has an online phone directory to look up establishment names or their telehone numbers. If the establishment is not listed there or in recent Google search entries or on Google maps, it is probably closed. TheTrolleyPole (talk) 03:03, 16 June 2017 (UTC)

With respect to the discussion about how to determine whether to delete a doubtful listing, I have started a discussion at Wikivoyage_talk:Listings#Doubtful_listings with a proposal to capture the key points discussed above. The purpose of this is to provide useful guidance to editors. Ground Zero (talk) 22:04, 28 June 2017 (UTC)

I think that we should separate the updating the listing which belongs in Wikivoyage:Listings, but details of researching doesn't. I think that we could have a travel topic e.g. Researching a destination, which would cover the research in a way that would be useful both to editors and also to readers who want to confirm information on a city that they are either found here, in a printed guide, or that they know from an earlier visit ("is that great restaurant still there five years on?"). AlasdairW (talk) 22:26, 28 June 2017 (UTC)

Doubtful listings

Further to this discussion in the pub, I propose to add some discussion to the "Usage guidelines" section of the page to assist editors in determining how to handle doubtful listing. (The key here is the word guideline, which means it isn't a hard-and-fast policy.) Here is a start - it's only a start, so I'm looking for suggestions for improvement:

If you come across a listing in Wikivoyage for an establishment that may have closed, you may consider deleting it. For example, if Google Map flags an establishment as "Permanently closed", it makes sense to delete it. If there is no Google Map listing, you can check other sources like Yahoo search, TripAdvisor and Yelp. If these have no reviews of the establishment in the last 3 to 5 years then it may be appropriate to delete the listing. Facebook automatically generates pages for some establishments. You can check these to see if anyone has posted a comment recently. If possible, call the establishment to see if the telephone number still works. Some establishments do not have websites or allow their websites to lapse, so the absence of a website is not enough to conclude that an establishment has closed. Discretion should be exercised in dealing with establishments in countries with less Internet access or availability. In deciding whether to delete a listing, consideration should also be given to whether the article has a lot of other "live" establishments or not. Or it doesn't, a doubtful listing adds little value. If it has few other listings, there is more value in leaving it in.

Comments? Ground Zero (talk) 11:27, 28 June 2017 (UTC)

The Facebook "unofficial page" for anything is utterly worthless; we shouldn't link to these and we certainly shouldn't cite any of them as evidence of anything. The only point at which I'd ever consider even looking at FB is if a page is controlled by the business, is that business' only known web presence and is being actively maintained or updated. If a web link breaks, first try a web search to see if they have online presence anywhere else. If not, try a telephone call (one minute of Internet telephony to most Western landlines costs a penny or two); if they answer, ask if they have a web site. If they answer as some different company name (for instance, a Knights Inn is now a Days Inn) update the info; if the number is residential or outright disconnected, remove the outdated listing.

Rarely, an establishment may be listed as "permanently closed" on another website (such as Yelp) or, if it was notable in its day, its demise might have obtained a mention in a local newspaper. These will be the minority; most go out not with a bang but a whimper.

I'm hesitant about the term "doubtful listing" as that could just as easily infer an establishment which does exist but is marginal for inclusion under Wikivoyage:Avoid negative reviews. Nine out of ten cockroaches say the motel's a dump? It's doubtful we'd list it... unless it's the only one for a hundred miles.

If the Cartwright Hotel is the only hotel in Cartwright (Labrador) but it burned down in 2013? No point in listing it. If the venue is gone, a "doubtful" listing doesn't add value - regardless of what else is or isn't listed for a destination.

I don't want to create policies or "guidelines" for this as there is no one single 'correct' way to carry out this task. Occasionally a non-standard approach works for one destination - for instance, a provincial restaurant inspection list might be a clue that an eatery was open long enough to survive this year's inspection, or an e-mail to a destination marketing organisation or the operator of some other non-competing business in the same village might yield useful info. For instance, after the train wreck at Lac-Mégantic an e-mail to the local travel info office yielded info as to what was still open (or still standing); what little we know about sleeping in Cartwright (Labrador) was obtained by sending an enquiry to Experience Labrador, a tour operator which doesn't run a motel themselves but would know if one is still operational and usable in the same village. One uses whatever information is available. War zones are the worst; we have no way to know if any of the listed venues are still standing. Natural disasters are also awkward - news reports might tell us something's gone, but usually aren't specific enough. K7L (talk) 03:06, 29 June 2017 (UTC)

"The Facebook "unofficial page" for anything is utterly worthless; we shouldn't link to these and we certainly shouldn't cite any of them as evidence of anything." Who suggested linking to them? Not me, that's for sure. But if an unofficial FB page exists, and people are still commenting on it, then I'm not going to delete a listing for that establishment, because it seems to still exist.

I stayed in a hotel in Indonesia where 9 out of 10 cockroaches would agree it was a dump, but there wasn't another hotel. Would you delete that listing on the basis that you'd rather sleeping the street? If there were other hotels listed, I'd agree with a deletion.

I understand that you are opposed to creating a policy. I have not proposed creating a policy. No-one is proposing creating a policy. Sometimes I think you don't read things you are responding to.

If we know a hotel is gone, we delete it. If we can't find evidence that it still exists, but we have no evidence that it is closed, what do we do? The above is an attempt to offer editors some guidance to help them, without restricting them. That's why it is a proposed guideline.

Are you opposed to helping editors? What I have proposed above explicitly says that discretion should be exercised in deciding what to do. That is exactly because "there is no one single 'correct' way to carry out this task".

I come across a lot of deadlinks in my wanderings through WV, and I try not to leave a page without resolving deadlinks that I find. When I started doing this work, I looked for guidance on what to do in these situations, and I found none. So I made up my own approach, but reading discussions in the pub, I have learned some tricks from other people that will help me do this better. That's what I proposed the above so that other editors can learn from the collective wisdom.

As I wrote at the beginning, this was only proposed as a start, and that I would welcome any suggestions for improvement. Ground Zero (talk) 18:33, 1 July 2017 (UTC)

I find that Openstreetmap is a good source. I update a lof of listing with latitude and longitude. I do this by finding it on OSM, and if it is not on OSM it add it there first. If a place is not on OSM, there is no address in the listing, nothing shows up on search engines, and it not page for a small town (where e.g. "by the church" could do for directions), then I delete on the ground that a traveller could not find it even if it existed. If the listing has an address, I search for in yellow page directories, search engines, etc. If I find a restaurant/pub/cafe with another name on the same address, I conclude that is has probably replaced the one in WV. Sometimes you get a result searching for "restarantname closed". Openstreetmap has almost all restaurant and cafes in Denmark. I have made a tool to syncronize with the health inspection reports . We could make a tool that finds restaurants that have been deleted in OSM, but is still in WV. Elgaard (talk) 16:39, 25 July 2017 (UTC)

Top Sights

Swept in from the pub

One thing I would like to see on Wikivoyage is a section in the article called Top sights, Not to miss or similar, which summarize places, that should be visited if nothing else. For example the Paris article we could add the Eiffel Tower, Arc de Triomphe, Versailles Castle, Louvre, etc to that section. I personally find some articles on Wikivoyage overwhelmingly detailled and sometimes it is hard to see the wood for the trees. What do you think? I think some old-school travel guides like Lonely Planet have something similar.--Renek78 (talk) 19:23, 22 June 2017 (UTC)

I'd have thought that what constitutes a "Top Sight" or "Not To Be Missed" depends on the particular interests of the reader/traveller. List a fabulous club every 18-20 yr old visits and you natural history traveller or a family with kids will wonder what's going on when they visit it. For some, a forest with zip-line is heaven whilst of others it's nightmare with screaming people on their descent scare away all the wildlife ... So what would be in the sections comes down to the author's interest rather than the readers. For me the project needs to consider as wide a user base as possible. PsamatheM (talk) 19:31, 22 June 2017 (UTC)

If there is something special worth highlighting, as well as been in the See or Do listings it should be mentioned in the Understand section at the top of the article.--Traveler100 (talk) 20:07, 22 June 2017 (UTC)

Or even in the introduction, which I'd say should usually mention the main reasons people go there. Versailles might be mentioned in Paris#Go next, country articles could link to the relevant section of the UNESCO articles, some articles will have itineraries or travel topics, perhaps Paris with children, Gay Paree, etc.

I'm not convinced this sort of section is necessary. Would anyone care to construct a sample in their user space? That might convince me & perhaps others. Or not, of course. Pashley (talk) 21:23, 22 June 2017 (UTC)

I think it's a lot harder to do this in big cities with a huge number of amazing sights, but look at Siena#See. In Siena, there's been a wide consensus for years on what the top sights are, so I think this is a pretty uncontroversial and also definitely a helpful way to organize things. I don't think this style should be copied in every article, though. Let's take New York City. Which are the top sights from among the following: The Empire State Building, the Statue of Liberty, the Brooklyn Bridge, the Metropolitan Museum, MoMA, the Whitney, the Natural History Museum, the Bronx Zoo, Yankee Stadium, Radio City Music Hall, Rockefeller Center, whatever they're calling the replacement for the World Trade Center now, the Smithsonian Museum of the American Indian, the Holocaust Memorial museum in the Battery, Lincoln Center, Times Square, and I could go on. Do you really want to pick between that list and spoon-feed people? I would definitely leave off some of those, but you might leave off others, and there are plenty of other attractions that could be added (for example, Central Park, the Jewish Museum, the Guggenheim, the Frick Collection - just where do "top sights" leave off?) Ikan Kekek (talk) 23:15, 22 June 2017 (UTC)

Understand your points. It is more complex than I initially thought :) --Renek78 (talk) 12:11, 25 June 2017 (UTC)

Listings Data

Swept in from the pub

How do I enter a post code/ zip code seperately, so it can be used to fill in other stuff automatically? (like lat/long for map generation) ShakespeareFan00 (talk) 16:53, 26 June 2017 (UTC)

I'd be careful of postcode to Lat/Long conversion as postcodes are not very precise (in fact they can be very misleading!). Best to find the place on the map and take the lat/long from that (better to take a little longer than send somebody to the wrong place!). Apart from the area covered by a postcode being very variable, even within a town taking the centre of the postcode area as the position for something can easily put the marker e.g. in the wrong street. And you see a surprising number of "directions" saying "out address ... AB1 2CD" but "find us use postcode AB1 2EF". The number of restaurants whose own website map just marks on the postcode and you spot that their map marks the wrong street, check on other mapping and their own map is badly wrong (and a traveller would be cursing by that point)! It takes work and time but is worth getting right. Couriers delivering to my own house who use the postcode end-up in the wrong street all the time (because the postcode marker misleads); they then have a 3 minute walk to get to me when somebody points out their error. PsamatheM (talk) 17:08, 26 June 2017 (UTC)

I tend to use the OSM POI, I KNOW that's been surveyed personally by an OSM contributor. ;) ShakespeareFan00 (talk) 18:06, 26 June 2017 (UTC)

How to evaluate hotels for inclusion under sleep ?

Swept in from the pub

Whilst attempting to slowly draft something, I noted the site for The Ridgeway national trail listed some Hotel links. Are there criteria for evaluating what gets included on Wikivoyage? I don't want to include something if it would violate policy. ShakespeareFan00 (talk) 10:47, 28 June 2017 (UTC)

Having some Sleep listing for every night is definitively helpful, unless it is to be spent at a destination the article of which provides those listings, or one can assume and write that there are enough options that no booking or checking is needed. Also in these cases an accommodation close to the path or suitable for the theme or spirit of the itinerary is worthwhile.

The only problem to be aware of is if the site can be believed to list hotels that would not be the prime options, e.g. because they are the ones that paid for being listed. Still, a listing believed to be as good as any is usually better than none. In such cases one could indicate that there are alternatives (at my first visit to the Alps any web search showed the same five guesthouses, while there probably were tens of them in the village – if I knew that I would probably have called the local tourist office).

We try to list a few good ones suitable for different tastes and wallets, but without personal experience it is often difficult to know which ones to list. And even having been there, few have experience of all options, so the selections is somewhat random anyway. One "rule" except the obvious, is that we prefer places with some local touch to those uniform across the globe.

--LPfi (talk) 12:09, 28 June 2017 (UTC)

Check out the hike specific web pages for hotels that welcome walker, that is do not complain too much about muddy boots and are dog friendly. Two key points to look for. Some hotels in tourist areas do not like single night bookings, only take full weekends or 5-7 days, these are not of interest for long distance hikers. Also look for for hotels that provide luggage trasfer services, taking your things by car from last nights hotel to the next days while you walk between them. --Traveler100 (talk) 18:43, 28 June 2017 (UTC)

The ADFC (German cyclists' club) has a program to certify "bike friendly" hotels; some of those points are the same for cyclists and hikers. Hobbitschuster (talk) 21:06, 29 June 2017 (UTC)

What happened to the "vCards"?

Swept in from the pub

The Edit button for listings disappeared. Is there a bug?--Renek78 (talk) 07:41, 6 July 2017 (UTC)

Our listings are not vcards. And sometimes the dit buttons take a bit to load. Does the problem persist even after reloading and on a different browser? Hobbitschuster (talk) 10:51, 6 July 2017 (UTC)

I tried Chrome and Edge to no avail. Started like 3-4 days ago. I even tried it at work. Same situation. Am I really the only one?--Renek78 (talk) 20:02, 6 July 2017 (UTC)

I suspected my change on Template:Listing, but it persisted after reverting it. Maybe the one before? Jura1 (talk) 20:07, 6 July 2017 (UTC)

I had that problem earlier today too, but it seems to be fixed now (at least for me). —Granger (talk · contribs) 00:29, 7 July 2017 (UTC)

User Verdy fixed the code: User talk:Verdy p--Renek78 (talk) 06:05, 7 July 2017 (UTC)

@Hobbitschuster Your Listings and our VCards are the same, they just have a different name in the language versions. BTW. Your listing editor is implemented on WV/de as well and works fine with our templates. Roalnd has improved it with more WD features and he is trying to make it available on the mobile version as well. It's available for testing. -- DerFussi 10:59, 7 July 2017 (UTC)

That's nice to hear. Now mobile is the next frontier ;-) Hobbitschuster (talk) 12:19, 7 July 2017 (UTC)

Roland works on it. Check it out over there. You can apply it for testing. One big difference: Wikidata information are not copied from Wikidata. They are shown in the listing editor in different style but not saved. Our listings always fetch the information directly from WD. In best case it contains description and WD-ID only. -- DerFussi 07:38, 10 July 2017 (UTC)

What counts as a "sight"?

Swept in from the pub

Have a look at Zittau which was recently created as a 1:1 translation from de-WV. Am I totally wrong in thinking there are "sights" listed there that very few people care the least bit about? Should we remove (some of) them? Are our policies clear enough, are they in need of revision? Hobbitschuster (talk) 13:25, 7 July 2017 (UTC)

At the moment the See listings need some work on formatting, adding addresses and hours etc. However I don't think that there is anything wrong with listing 4 churches, especially if there are open during the week for visiting. The 3 museums are also worth listing, and the two park listings might be combined into one. The "Streets and squares" section is probably useful but needs some more descriptive text. The "Buildings" section is probably redundant as these seem to be the museum and church buildings. AlasdairW (talk) 14:22, 7 July 2017 (UTC)

It's all relative. I wouldn't normally be interested in attending a sitting of a subnational legislature, especially if I were in Munich or Edinburgh, but there's so little to do in Fredericton that I ended up doing just that. Zittau only has 12 things to see listed, which isn't too many. Readers who are not interested in churches don't have to go just because we list them. I agree that there's not much value in listing them with no information. I'd delete those. Ground Zero (talk) 14:40, 7 July 2017 (UTC)

Al I know is that for "not that interesting a place" the counter on de-WV went over 99... And we are debating on what to cut from the USA article. Hobbitschuster (talk) 15:38, 7 July 2017 (UTC)

Smaller places rarely have much to see, therefore the bar for what's worth listing should be much lower than for large cities. In other words, we can keep the churches in Zittau but the subheadings aren't necessary for that small number of sights. ϒpsilon (talk) 07:08, 8 July 2017 (UTC)

In source editor, I had to manually add "vCard | type ="

when pasting these examples into any listing, the result shows no text but only "template=see" or similar. Do I need to switch interpretation(?) of source code from vcard to listing in order to use the template text of this site? I workaround by writing *

• Type: what is the preferred way?
• name: {{{name}}}
• address: {{{address}}}
• phone = {{{phone}}}
• email:
• fax: {{{fax}}}
• url: {{{url}}}
• hours: {{{hours}}}
• price: {{{price}}}
• lat: {{{lat}}}
• long: {{{long}}}
• lastedit: {{{lastedit}}}
• description = {{{description}}}‎ —The preceding comment was added by Dnaiel (talk • contribs)

First of all, please sign your contributions to talk pages (like this one) by typing "~" four times in a row, like this: ~~~~. Second of all, we don't use the vCard Template, instead we use the listing template. Hobbitschuster (talk) 23:01, 29 August 2017 (UTC)

adding "wikidata=" to listings

Swept in from the pub

If there is interest, I could try to find a way to add "wikidata=" based on "wikipedia=" to all listings. What do you think ? Jura1 (talk) 08:19, 15 July 2017 (UTC)

I would like that, but I can't judge the risks and problems this might bring. Hobbitschuster (talk) 14:02, 15 July 2017 (UTC)

Sounds like a fine idea to me, but much better done by a bot than manually. If that is how you want to do it, discussion should continue at Wikivoyage:Script nominations.

If you propose to do it manually, I'd like some explanation here. It looks to me like it would be a huge amount of work & quite error-prone. Pashley (talk) 22:39, 16 July 2017 (UTC)

No, bot should be fine. It should be fairly straightforward. If needed, Wikidata:Bot requests might be a place to find a Wikidata-proficient operator.

I just did a few manually to get an idea of the listings available (mostly lighthouses and film festivals). It lead to the creation of a few missing Wikidata items for such entries and complete existing items (lighthouses were found to be difficult to search for at Wikidata). Jura1 (talk) 12:14, 17 July 2017 (UTC)

I left a note at d:Wikidata:Bot_requests#Adding_items_to_Wikivoyage_listings. Jura1 (talk) 18:28, 23 July 2017 (UTC)

There are no "add listing" links in sections like See and Do for the page Zeeland

Swept in from the pub

This problem occurs at Zeeland, but not at (most?) other pages, like Middelburg (Zeeland). In nl:WV there is the same problem, see: nl:Zeeland and nl:Middelburg, where the last does have "item toevoegen" links. --FredTC (talk) 12:09, 25 July 2017 (UTC)

I think there are no "add listing" links because Zeeland is a region, not a city. This seems like a feature to me, not a problem, because regions aren't usually supposed to have individual listings, and the lack of a link discourages users from adding them. —Granger (talk · contribs) 11:46, 26 July 2017 (UTC)

Yes, I noticed more regions that don't have them. However another Dutch province, Flevoland, does have them. So I cannot see what makes the difference. --FredTC (talk) 13:53, 26 July 2017 (UTC)

You're right, Flevoland has them. I'm guessing that's because it has the heading "Municipalities" instead of "Cities"—when I changed the heading, the links disappeared. —Granger (talk · contribs) 21:04, 26 July 2017 (UTC)

The cause is very simple. AddListing is working. You can learn it for instance from North Brabant. The Listings have an edit button. But there is a stupid code line in MediaWiki:Gadget-ListingEditor.js

var DISALLOW_ADD_LISTING_IF_PRESENT = ['#Cities', '#Other_destinations', '#Islands', '#print-districts' ];

If you study the code you will learn that articles which contain one of these four headers (Cities, etc.) will not get an "add listing" to the section headers but only to the listings. --RolandUnger (talk) 09:40, 28 July 2017 (UTC)

I think it is intended to have no "add listing" links in region articles, see Wikivoyage:Manual of style, too. Because nobody should add such listings, they must be stored in site articles. Unfortunately software cannot distinguish between a region and a city article. That's why the editor is checking for subheaders which can only occur in region articles. --RolandUnger (talk) 08:23, 29 July 2017 (UTC)

Open or Closed Days

Swept in from the pub

These [edit notes https://en.wikivoyage.org/w/index.php?title=Kurashiki&diff=prev&oldid=3270067] state: "it probably makes more sense to shows the hours and days something is open, rather than the hours it is open and the days it is closed." but I disagree. As a traveler, I don't want to waste my time trying to figure out that it's closed on Mondays with "Open Tues-Sun". It's much more traveler-friendly to simply say "Closed Mon". It's to the point and doesn't require ANY thinking on my part. And there's no confusion to say "Hours: 9AM-5PM (Closed Mon)." I can't imagine anyone thinking that 9AM-5PM is a listing of closed hours just because we state succinctly the day it's closed. To me, it overcomplicates the straight-forward "closed Mon" to say "Open Tues-Sun" and make me "do the math" to find the missing day. Is that policy or is it something that differs depending on the author? ChubbyWimbus (talk) 11:02, 2 September 2017 (UTC)

I agree with you. Ikan Kekek (talk) 12:13, 2 September 2017 (UTC)

Me too. Pashley (talk) 12:34, 2 September 2017 (UTC)

I think the "(Closed Mon)" format is better. When something's only closed one day of the week, or on weekends: The "Open Tues-Sun" format is overkill, it just makes things more confusing. Emmette Hernandez Coleman (talk) 12:41, 2 September 2017 (UTC)

WV:tdf does not address the issue directly, but I've been thinking of proposing something there to make it explicit. The one example that provides any guidance is "When combining days with time, put the days first: M–F 10AM–2PM, not 10AM–2PM M–F." Note that it does not suggest using "closed Sa Su" instead of "M-F".

All of our formatting is about the open times. Why make an exception where it is closed one day, but not two, three, etc.? I do not think that "Tu-Su" is more complicated as it tells me when I can go, not when I can't go. Just as we wouldn't say "closed 10PM-7AM". Ground Zero (talk) 13:12, 2 September 2017 (UTC)

A good rule of thumb to follow is that ttcf supersedes all other policies, and I think a case like this clearly falls into those parameters. I would stop short of establishing a policy that says we must speak in terms of when a place is closed rather than open depending on how many days of the week it's open, etc., but I think it's fine to do so in this case, and to tweak listings appropriately when it makes sense to do so. -- AndreCarrotflower (talk) 13:18, 2 September 2017 (UTC)

Of course the traveller must always come first, and that has to be the basis of our policies. In this case, the policy is not clear, which means different people are taking different approaches. Inconsistency only makes Wikivoyage harder to read. No traveller wants to go to a restaurant or a museum when it is closed, so I think that putting the traveller first means telling them when it is open instead of telling them when they can't go and making them do the math to figure out when they can go. So:

Tell the reader what days and hours a place is open.

Instead of:

Tell the reader what days and hours a place is open, unless it is closed one day a week, then tell the reader what day it is closed and what hours it is open.

Ground Zero (talk) 18:33, 2 September 2017 (UTC)

This of course would be especially helpful in cases where a culture has a clearly-defined weekend and a business is closed thru the standard work week. Maybe the standard format for hours but at the end (Closed Mon.)? —Justin (koavf)❤T☮C☺M☯ 18:39, 2 September 2017 (UTC)

Coloured text doesn't meet accessibility standards - I think it may screw up readers, and it certainty causes problems for people with partial colour-blindness. As far as cultures with standard work weeks, then I guess we have to indicate what those work weeks are then identify the exception, or just go with Tu-Su, which seems pretty straightforward. Ground Zero (talk) 18:58, 2 September 2017 (UTC)

Which is why it is not only colored but also strong text. Accessibility just requires that you don't only use color but it doesn't prohibit the use of color. Also, no one is black–red colorblind. —Justin (koavf)❤T☮C☺M☯ 19:18, 2 September 2017 (UTC)

But will anyone not understand "Tu-Su" when we list opening days and hours? I really fail to see the problem here. Our readers aren't stupid. Do we need to shout at them with colours and boldfacing? Ground Zero (talk) 19:23, 2 September 2017 (UTC)

I agree that the bold red text would be too attention-grabbing. I think it would make the information stand out as the most prominent part of each listing when readers are scrolling down the page, but it's really not the most important thing about a POI. —Granger (talk · contribs) 19:40, 2 September 2017 (UTC)

The use of colour would be excessive and detract visually from the page. As for black-red colourblind? I have a monochrome laser printer which resembles that remark, and our Wikivoyage:Goals and non-goals do hold that the print version matters. On "closed days" in general? Note them if they're scheduled in time slots where the venue would reasonably be expected by the voyager to be open. A bank or credit union being closed on Sunday is too common to be notable, while, for most churches, being closed on Sunday would be exceptional. K7L (talk) 23:10, 2 September 2017 (UTC)

No colors or boldface, but mentioning what day(s) something is closed is natural and helpful. I see no reason whatsoever to limit it to one day. "Closed Sun-Mon" is a perfectly reasonable statement. Ikan Kekek (talk) 00:58, 3 September 2017 (UTC)

I'm not anywhere near as convinced as Ground Zero seems to be that strict consistency from page to page is a vitally important issue, but I suppose that's a discussion for another time. -- AndreCarrotflower (talk) 02:34, 3 September 2017 (UTC)

It is why we have a style guide in the first place. If we think it's okay to let a thousand flowers bloom, them we can do away with the style guide, article templates, are other organizational aids. I think that having as much consistency as possible in a cross-border project makes it easier for travellers to find their way around our guide in the spirit of ttcf. Ground Zero (talk) 02:46, 3 September 2017 (UTC)

I don't see it as a black-and-white thing. As I see it, the style guide is a set of suggestions or guidelines rather than rules, and is (and should be) intentionally vague to allow writers plenty of room to craft articles that are, to a certain extent, tailored both to their own writing style and what makes sense for the individual destinations. Frankly, I think that hyperstandardizing all of our content into a rigid template could only be detrimental to the project. The last thing we should want to be is a McTravelGuide. -- AndreCarrotflower (talk) 20:16, 3 September 2017 (UTC)

Abbreviations for days of the week

An aside I find interesting is that most people in this discussion are using three-letter abbreviations (or even four), as in "Open Tues-Sun" and "closed Mon", not the one or two-letter format our policy at Wikivoyage:Time_and_date_formats#Days_of_the_week currently mandates.

It has always seemed obvious to me that the three-letter forms are more readable & should be used everywhere. Is it time to re-open discussion at Wikivoyage_talk:Time_and_date_formats#Days_of_the_Week? Pashley (talk) 15:42, 2 September 2017 (UTC)

Agree that using 3 letters for days would make reading easier. Open up a new discussion if you think it is worth the effort. I assume we have few readers still using analog modems. --Traveler100 (talk) 18:47, 2 September 2017 (UTC)

See Wikivoyage_talk:Time_and_date_formats#Expanded_short_names_for_days_of_the_week. —Justin (koavf)❤T☮C☺M☯ 19:07, 2 September 2017 (UTC)

Proposal for "dual purpose" listings

Please see Talk:Biel for how I arrived at the following:

“ In the case of districted cities, a listing that is relevant for whole city (an embassy, train station etc.) should be in the main article with its primary function and may be in the district article with its secondary function of "prettiness". In the case of non-districted cities, the secondary function should be mentioned in the single listing in the section according to the primary function. ”

What do you think? Hobbitschuster (talk) 15:37, 27 November 2017 (UTC)

Only one listing, i.e. primary function but should also be mentioned in the introduction text of the secondary function. In the case of train station that is architecturally interesting all information is in the Get in section but is mentioned in the starter sentence(s) of the See section. In case of a hotel with a good restaurant or a pub that serves good meals then only one listing in Eat/Sleep/Drink and a mention in text in the other section. --Traveler100 (talk) 17:14, 27 November 2017 (UTC)

I'm not sure I fully understand what you're saying. Hobbitschuster (talk) 19:50, 27 November 2017 (UTC)

Something like this. --Traveler100 (talk) 21:43, 27 November 2017 (UTC)

Simply mentioning the item is fine for establishments where the duplication is Buy/Eat/Drink/Sleep. But in the case of embassies and train stations, I think it's valuable to have "duplicate" listings. The listings serve different purposes in those cases, and touting isn't an issue. Powers ^(talk) 22:14, 27 November 2017 (UTC)

In the linked talk page thread, I said I felt the suggestion was sensible, but I'm now thinking it may depend somewhat on how long the article is. In the case of Biel, since the article is so short, I would suggest having the train station be a "Get in" listing, with information about it as a sight at the end of the listing. I'm not sure we couldn't find a non-districted city that had an embassy or train station that also needed to be listed or at least mentioned separately in the "See" section, so that readers wouldn't miss that it's a major sight. Ikan Kekek (talk) 12:19, 28 November 2017 (UTC)

But which sights are not mentioned in the district articles? Is there an embassy that is really in that A-List of A-Lists? Hobbitschuster (talk) 12:34, 28 November 2017 (UTC)

Some very large cities, such as Karachi, are not districted. There might be a consulate in Karachi that's also a major sight; I have no idea, but I'm saying that this kind of thing is quite imaginable. Ikan Kekek (talk) 12:50, 28 November 2017 (UTC)

Barbers and salons etc

Do we add them as full-blown listings, or is it just better to mention them in passing, either by name but without contact info, or more generally as in "there are a lot of good salons in neighbourhood x"? My hesitancy over this is that they are clearly not traveller-specific, but may well be useful for travellers, so a listing with contact details is clearly helpful.

But obviously hairdressers are everywhere and come in so many different varieties that if we do add them as listings, where does it stop? If we put in a couple of salons here, a dash of hipstery "gentlemen's barbers" there, include the inevitable Turkish contingent, and make sure to list those that specialise in African and other ethnicities' hair types, then the 'Buy' section would quickly become a sea of hairdressers. If we restrict to just the sort of venue people will travel to visit, then the vast majority of city articles won't have any hair salons at all.

I know we want to avoid turning Wikivoyage into the yellow pages, and adding ten-a-penny businesses like this seems to be a fasttrack way of doing that, but you equally can't deny that the information would be useful for our readership. Any ideas? --ThunderingTyphoons! (talk) 19:00, 30 November 2017 (UTC)

Generally I would restrict listings to either salons of special interest, or those that are particularly useful for travellers. In the first group might go salons that are historic, such as a barber in Edinburgh which was started in 1890 and whose salon shows some of this age. The second group would be salons where the staff speak foreign languages and know about foreign styles - eg a salon with European staff in Tokyo, or with Japanese staff in New York. Generally I expect that travellers wanting a haircut will ask locals (eg their hotel reception) for recommendations. AlasdairW (talk) 21:56, 30 November 2017 (UTC)

Those look like good benchmarks. Unless something extraordinary jumps out, I will keep info on such places in Sheffield brief and general, and carry forward the same principles to other articles in the future. Thanks for answering, Alasdair. --ThunderingTyphoons! (talk) 00:42, 1 December 2017 (UTC)

I can only think of one barber worth listing, namely Angel Delgadillo of Seligman (Arizona). Even then, he's notable more as a source of history about some highway that hasn't existed since 1985 than anything else. K7L (talk) 02:31, 1 December 2017 (UTC)

I have a barbershop listed in Walt Disney World/Magic Kingdom (though it's under See and Do!). But in general, I would only list a salon if it's the only game in town (or otherwise notable). Powers ^(talk) 02:56, 1 December 2017 (UTC)

Listing editor: Autofill from Wikidata

Swept in from the pub

German Wikivoyage listing editor filling fields automatically (in yellow) using Wikidata

The German Wikivoyage listing editor fills fields automatically (in yellow) using Wikidata. No need to press a button, and it does not overwrite any existing data, so it is faster and safer. Could we have this too? :-) Syced (talk) 04:43, 12 October 2017 (UTC)

I'm very wary of ceding control of our content to Wikidata to that degree. -- AndreCarrotflower (talk) 05:02, 12 October 2017 (UTC)

I can only see benefits to adding an image from Wikidata to a listing that has no image. Same for the other details. Once again, it does not overwrite anything. Syced (talk) 06:55, 13 October 2017 (UTC)

I like the fact that it doesn't overwrite existing data. That's something which I really don't like from the current method in our listing editor, which will overwrite manually added coordinates etc. Drat70 (talk) 07:15, 13 October 2017 (UTC)

Syced, Drat70 - the discussion below about Commons deleting dynamic district overview maps is a perfect example of what can happen when we cede too much control over our content to another project. -- AndreCarrotflower (talk) 23:59, 14 October 2017 (UTC)

AndreCarrotflower: Keep that argument for when we move all of our listing details to Wikidata ;-) For the time being, it is about importing public domain data into our English Wikivoyage, and as you know public domain data present in our English Wikivoyage can only be deleted by us. Cheers! Syced (talk) 02:37, 15 October 2017 (UTC)

At the German Wikivoyage we programmed our listing template completely anew. This was necessary to support data import from Wikidata. There are now more than 20 parameters which are supported. Nevertheless, authors can keep full control of the data: they can decide if and which data should be imported and they can manually overwrite all data. Storing data at Wikidata gives authors of our smaller Wikivoyages the opportunity to use these data more easily. The easiest way to prevent data deletion is to use them. Instead of images and map data, there are usually no problems with copyright, and you can watch data change in the same way as we did it in this wiki. To have an imagination what can be stored and used already today please have a view to Dorint Charlottenhof Halle (Saale) hotel. --RolandUnger (talk) 13:50, 15 October 2017 (UTC)

By the way, the automatic filling is not done by the listing editor but by the listing template. The editor only shows which data are available. So you can overwrite them if necessary. --RolandUnger (talk) 14:07, 15 October 2017 (UTC)

I think filling in stuff from commons or wikidata should always be done by hand and not automatically. Hobbitschuster (talk) 12:42, 16 October 2017 (UTC)

Copying around listings coordinates/images/etc between Wikivoyages is not the best use of our limited manpower, I believe. Syced (talk) 14:44, 17 October 2017 (UTC)

Listing editor won't let me save

Swept in from the pub

A few minutes ago I tried to use the listing editor to fix the dead link for the United States embassy in Montevideo. But when I clicked "Submit", I got a pop-up message saying "Please ensure the email address is valid". As far as I can tell, the listing editor won't let me save my changes unless I do something to fix the email field. I don't know what the best way to fix the email field is, and I would guess I'm not the only one, so I think this feature may discourage people from editing listings (especially new users). If a user is trying to use the listing editor to make a change to a listing, and the listing has some problem (like a misformatted email field) that's unrelated to the change they're trying to make, I think they should be able to save the change without fixing the problem that they may well not know how best to fix. —Granger (talk · contribs) 17:34, 12 October 2017 (UTC)

Just fix in the page source, not the listing editor :)

Although looking t that example, we should list 3 different email addressed (which is the cause of the validation issue). I have no idea which email I should use and therefore the content is nearly useless. Andrewssi2 (talk) 21:47, 12 October 2017 (UTC)

Yeah, I did finally switch to the page source. My concern is that new editors may just give up instead of trying to figure out if there's another way to edit the listing. I don't know, maybe most of our new editors come from Wikipedia, in which case it wouldn't really matter. But if we want to attract new editors who aren't already familiar with editing wikis, I think it would be good to adjust this feature. —Granger (talk · contribs) 01:04, 13 October 2017 (UTC)

The problem described is not only a problem of the listing editor. Both the editor and the listing template accept only one email address: please check the email addresses in the article of Montevideo carefully. All three email addresses are linked with the same. In case of the template, this cannot be easily solved. That's why we programmed a module at the German Wikivoyage to handle more than one email address. In case of the Listing editor script you have to change the VALID_EMAIL_REGEX regular expression. --RolandUnger (talk) 13:35, 15 October 2017 (UTC)

Why would any listing need more than one E-Mail Address? Hobbitschuster (talk) 12:43, 16 October 2017 (UTC)

It's the same why we need more than one phone number: maybe one for general inquiries, one for reservation, and so on. --RolandUnger (talk) 06:29, 17 October 2017 (UTC)

As I understand it the problem is not the listing template being able to handle just one e-mail address, but the listing editor requiring a random user to solve this problem before being able to save his or her contribution. The editor should verify only the changed data. Alerts for bad data should be done by visually flagging them (for opt-in i.e. experienced users) and by maintenance categories. --LPfi (talk) 14:55, 16 October 2017 (UTC)

Exactly, that's the point I was trying to make. —Granger (talk · contribs) 15:16, 16 October 2017 (UTC)

Flagging bad data is necessary [unfortunately not done now] but should not be the only solution: a random user can solve the problem himself if anybody will tell him that only one email address is allowed. --RolandUnger (talk) 06:29, 17 October 2017 (UTC)

Even if the random user somehow knows the problem is that only one email address is allowed, it's not obvious which of the email addresses should be kept, at least not without further research. Anyway, I think it's inherently discouraging if you try to make an edit and the interface tells you, "You can't save the edit unless you fix this completely unrelated problem." —Granger (talk · contribs) 13:09, 17 October 2017 (UTC)

Usefulness of sleep/eat/drink in big articles

Swept in from the pub

I am wondering, what's the point of having those sections in the likes of Chiang Mai, Havana or Prague/East bank of Vltava ? Of course, a few notable objects should be there (like some famous/old hotels or coffee places, where you can feel "genius loci"). But while I hope wikivoyage will be The source of travel info one day, for backpackers and such, I don't think it will ever replace tripadvisor or hotel booking services - because there's no references here, nor photos or prices. And in this day and age, ain't nobody is going to write emails asking for free room in a hotel.

I'm not sure what I'm proposing, removing the information completely is probably not good idea - and it should be left in cities where 3-5 hotels are available, and of course remote places where 1 room in whole village is for rental.

What if e.g. online wikivoyage had instead links to some relevant booking services (and, God-forbid, earned some money for that .-) ) instead? I reckon that would be far more useful for quick usage. Of course, for offline versions, probably providing at least some list of hotels is a good thing (perhaps such list could be received from the booker pages in exchange). Andree.sk (talk) 13:02, 25 October 2017 (UTC)

To be blunt, those kinds of suggestions are not going to be received warmly here. Internet Brands' efforts to monetize Wikitravel are a huge part of why we left there, and perhaps more importantly, would be a direct affront to WMF policy. -- AndreCarrotflower (talk) 13:10, 25 October 2017 (UTC)

I'm aware, but that was not the main point... But I'd really like to know who is the target audience of such listings, and if we could make it more useful - because I know I would never search for a big-city-hotel via travel guide (not even the printed ones)... Andree.sk (talk) 14:27, 25 October 2017 (UTC)

So you're suggesting that because you personally would rather use a booking service than Wikivoyage, we should eliminate huge chunks of our own content and simply direct our readers to the competition? What's the point of Wikivoyage, then? -- AndreCarrotflower (talk) 16:24, 25 October 2017 (UTC)

There might be some useful nugget of insight here. I think we can all probably agree that we shouldn't get rid of the Sleep section or start monetizing Wikivoyage, but I think Andree.sk has a point, in the sense that while sections like Get in, Get around, See, and Stay safe are useful to a lot of travellers (and often much better than our competition), the Sleep section often functions as a less-good version of, say, Trip Advisor (at least that's how it seems from my perspective in many city articles). Maybe there's nothing to be done about that, but I think it's worth considering whether there's some way we can adjust the Sleep section to make it more useful to more travellers. —Granger (talk · contribs) 16:38, 25 October 2017 (UTC)

What listings in Wikivoyage gives me that other sites do not is a good indication of what hotels are near good eating places and which sites of interest are near each other. This can only be done with booking sites and a lot of cross typing in Google Maps. --Traveler100 (talk) 17:16, 25 October 2017 (UTC)

So how do you know, with 50 listings, which are really good, and which were only added by the owner to be on the list? Often I can't even evaluate such thing via webs with ratings (e.g. because most of the good hotels are booked completely anyway)... And in the end e.g. low-cost-travellers rarely search for accommodation near the attractions... Andree.sk (talk) 17:28, 25 October 2017 (UTC)

Yep, it's basically why I started this thread, to have a discussion. I don't really have a solution - and don't think it should be done for me, nor that the hotel lists should be pruned to zero immediately. But if there are enough similar opinions, perhaps there is something that could be done to make the site more attractive to travellers in this regard. The do/see/understand sections often a better source of info than a list of attractions from tripadvisor-like-webs. But there are limits of what such a wiki can do....... On the other hand, of course, there's Wikivoyage:External_links. Which should IMO be (partly) reconsidered, since it's 10+ year old now, and things changed a bit since. Andree.sk (talk) 17:28, 25 October 2017 (UTC)

I think it is definitely worth having some overall orientation/guidance info in high-level articles. Examples include hotel info in Metro_Cebu#Understand and Downtown_Shanghai#Sleep. I wrote both of those & am definitely of the opinion that they are worth keeping; so are lots of similar things in other articles.

As for actual listings, policy is that those go in lower level articles. A few really important ones -- perhaps Grand old hotels or ones that are landmarks -- may need links from higher-level articles, but those should be few & far between. Pashley (talk) 18:08, 25 October 2017 (UTC)

I think there are a few things to keep in mind here. First of all, not everything is online. Not even these days. So having a phone number and directions for that hotel in San Juan del Norte may be a godsend. Second, we want to be usable offline. A link to TripAdvisor is not that. Third, we have to be consistent. If we don't allow listings in the districts of Prague but do allow them in Wuppertal, something's just not right. And lastly we want to be the first and last resource needed for as many trips as possible. That's our unique selling point Hobbitschuster (talk) 20:25, 25 October 2017 (UTC)

Also, Andree.sk says "I don't think it will ever replace tripadvisor or hotel booking services - because there's no references here, nor photos or prices." Photos would be against policy & I think that is a good policy with a few exceptions for landmark hotels or places like Japanese w:capsule hotels where a reader might have no idea what to expect.

As for prices, links to the hotel website & geo co-ordinates, those are important. What should we be doing to ensure more listings have those? Start a collaboration of the month? Delete listings without them? Require those before an article can be Guide, Star or DotM? Something else? Pashley (talk) 22:41, 25 October 2017 (UTC)

Another point I'm surprised hasn't been made yet: it's an open secret that Yelp, TripAdvisor, et al. will suppress bad reviews for businesses that advertise with them or otherwise pay for premium services (and, for that matter, stories of writers for big-name paper travel guides accepting bribes from business owners in exchange for a positive review also abound). On the other hand, Wikivoyage's noncommercial status as part of the WMF family, and our intolerance of touting and other such conduct from contributors who may have vested interests, means readers can expect fair coverage at all times.

Zooming out: as I see it, there's nothing wrong with our "Sleep", "Eat", "Buy", or any other section that can't be solved in the same way that we've always improved our content. If listings are dry and boring, spice up the prose. If information is incomplete, complete it. If there are too many listings in a given article, that's a sign that it may be ripe for districtification. It's really not any more complicated than that.

-- AndreCarrotflower (talk) 00:49, 26 October 2017 (UTC)

I don't think it's that simple, because when a listing is posted by the owner or someone employed by a hotel to tout it and it's detouted, it's still a listing posted by a self-interested party. I've said before and would repeat that I don't trust hotel listings on this site for that reason. Ikan Kekek (talk) 03:56, 26 October 2017 (UTC)

Exactly - not accepting touting is ok, but either way, you end up with 50 listings "clean room and good breakfast". There's no way to use such wall of listings reasonably... At least online you'll have hotel with 10 vs hotel with 1000 positive ratings, and no negative ones - still quite easy to pick one... And e.g. the uberused Airbnb will even show bad ratings. Andree.sk (talk) 05:02, 26 October 2017 (UTC)

I know the target is to have WV like Hitchhikers guide to galaxy, with all knowledge needed inside. But do you really think few individual editors can keep these 3 listing sections remotely relevant compared to current online services? Note that I don't argue that they are great resource in less touristy areas. 99% the listings will stay for the time being. Would it make sense to, additionally, have something like what wikipedia has for geo coordinates - the page with links to different online maps? OFC in Cuba, hotels.com is hardly useful, compared to other local services. Andree.sk (talk) 05:02, 26 October 2017 (UTC)

There was an idea some time back to enable a feature for registered users to "recommend" listings. This seems to have gone nowhere, though I don't remember all the issues brought up in that discussion. Hobbitschuster (talk) 09:55, 26 October 2017 (UTC)

I think they are mostly-useless, and occupy an inordinate amount of housekeeping for a not very valuable list. I think we should keep the sections, but push for more prose over listings. We could say, for example, in the article for Springfield. Springfield has three motels just off the interstate, with nothing much to distinguish them, although the Motel 16 does fresh waffles. There is one hostel in town, but if you're looking for 5 star you'll have to venture to nearby Shelbyville. We then might just put in the motel listings, if we feel like it. This is how we're going to add more value than booking.com. We should delete all hotel listings added on mass. These are wasting our time, and deceiving our readers. Similarly for Eat. Point out the Eat Streets, the local specialities and where to find them. A listing for the local coffee shop or Pizza restaurant in the suburbs? Waste of space and time. Inas (talk) 22:25, 26 October 2017 (UTC)

This is crazy talk. We're actually discussing changes of this magnitude to solve a problem this minor and this easily addressable using the policy tools we already have? -- AndreCarrotflower (talk) 00:38, 27 October 2017 (UTC)

That the sleep section of 99% of articles is totally useless? Or that it takes so much time to curate the spam that's added there? What's your solution within existing policy? --Inas (talk) 02:14, 27 October 2017 (UTC)

First off, claiming that "the sleep section of 99% of articles is totally useless" is an exaggeration so gross that it frankly makes it difficult to take the concerns expressed in this thread seriously. Second: we're a travel guide. Part of the deal is that our audience has to be willing to actually read our content, and to make decisions based on the information we give them. In the vast majority of our articles, there's not reams and reams of information to sift through, so it's not as if this is some huge effort we're asking them to expend. In the case of people who are too lazy to read, there's not much we (or any travel guide) can do for them.

Secondly, we have enough hands on deck in Recent Changes patrol that most touting ends up getting reverted anyway, and I don't know what makes people think the "Sleep" section is any more of a spam magnet than any of our other sections. That hasn't been my experience as an editor and de-touter.

I already stated my solution within existing policy above: continue to improve the quality of our content, to revert spam and touting, and for that small minority of articles where there really is too much information, don't be afraid to districtify. Again, people who don't want to invest the minimal amount of time and effort to engage in those simple actions should really think twice about whether this project is for them. If you want to work on writing a travel guide, be prepared to work on writing a travel guide.

-- AndreCarrotflower (talk) 02:51, 27 October 2017 (UTC)

I'd say 99% is actually an under-estimate. I'd be surprised if in this day and age more than a handful of our tens of thousands of sleep listings has even been relied upon. Personally, I totally ignore the sleep section. I do use tripadvisor, booking.com, etc for hotel reviews info. I'd be surprised if anyone uses it.

And with due respect to our hardworking de-touting taskforce, they make the problem worse - by changing the text of a listing that is obviously unreliable to one that may appear to the reader to be reliable. It's misleading.

IMO working on a travel guide comment is about curating quality information for travellers. I don't think it's about taking an ad posted by the hotel owner and removing the flowery language. I don't think the wiki format can compete with those other sites. So, I think we should broaden our focus to include more overview information for a town that's missing from those other sites. Inas (talk) 05:07, 27 October 2017 (UTC)

It would be nice to have some figures on this (which I assume is impossible, but what do I know?), because currently you're making the claim that just because you don't use the Sleep section, that must mean nobody does.

The fact we include a link to a hotel's website / social media presence should be enough to demonstrate that we don't expect anyone to rely 100% on what Wikivoyage says. Travellers can read our listings, decide which one(s) appeal most to them, and then pursue the booking elsewhere, or else find out more information on the establishment's website. Wikivoyage has played its role in getting the traveller to that point where they're considering making a booking, which is all we can do.

Regarding de-touting listings, I do tend to agree with the above, however. Unless there is a serious lack of listings of the same category in a given article, I revert a tout listing on site and don't replace it with anything 'de-touted'. It doesn't matter if you de-tout, as the listing was put there in the first place as an advert, and not on the merits of the establishment in question. I agree that keeping the listing would be misleading. --ThunderingTyphoons! (talk) 09:16, 27 October 2017 (UTC)

I have used Wikivoyage's Sleep section (in its listing format) as a starting point in deciding which hotel to book a fair few times. I guess I must be in the 1%. Gizza ^(roam) 11:13, 27 October 2017 (UTC)

As a member of the 1%, I'm genuinely interested. Why did you choose WV over another site that contains far more information, detailed property facts and detailed reviews? Are you familiar with other sites that will enumerate every feature of a property? Give photos inside and out? Give a rating? Give a location? Have a number of user reviews, and up to date and comparative prices for the dates of your stay? Enforce reviews only by people who've stayed. And let you know if the place is actually still there! Were you looking for another travellers recommendation? If so, did you think you got it? Did you book? What did WV offer? Inas (talk) 11:51, 27 October 2017 (UTC)

I think you give insultingly little credit to the work that people (self included) do on the listings of this site - not only removing flowery language and touting but also verifying the continued existence of places and the accuracy of the information. Of course not every piece of information on this site is 100% accurate, but by the same token, the same is true of websites like Yelp, Tripadvisor, booking.com (see my comments above, or Google, on how a little bit of money tends to make bad reviews on those sites disappear) or paper travel guides, which languish for years between updates (and if Lonely Planet's coverage of Buffalo is any indication, oftentimes outdated information has to wait several successive new editions before being caught and corrected). When you hold Wikivoyage to an impossible standard, sure it looks like a failure by comparison.

As for curation, there's something to be said for not blasting our readers with a firehose of information, but simply removing all hotel listings as you suggested is a ridiculous overreaction in the other direction. Our hotel listing sections may not be gripping reading, but it's information travellers need.

-- AndreCarrotflower (talk) 15:42, 27 October 2017 (UTC)

Guys, IMO this is going in a wrong direction, no need for insults. Perhaps there is really the 1% that will trust WV enough to use it in a big city. To me it is clear there's no substitution for this info esp. in places like Seda_(Sichuan). I created a quick&dirty copy of Havana - User:Andree.sk/Havana-hotels, just to show what we could do. It's not too pleasing, but perhaps a good discussion point. Let's say 50% people use booking services instead of WV - wouldn't be a clickable list of local booking services (e.g. in 3rd world countries, booking.com may be far from the best page) at least as useful as those listings we have currently? As I said previously, wikipedia has links to online sources, e.g. maps (like this, which obviously make some money from the traffic in the end), so... Andree.sk (talk) 17:41, 27 October 2017 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Andree.sk, could you explain why you keep mentioning money? Your very first comment seems to indicate that you believe Wikivoyage needs money, and now you bring it up again in connection with tools.wmflabs.org. What's your point? WhatamIdoing (talk) 03:00, 28 October 2017 (UTC)

First time the point was really that wv could get some additional benefits from the cooperation. This time it was only to show that having such links to commercial services probably doesn't offend the rules to much? Andree.sk (talk) 04:27, 28 October 2017 (UTC)

What makes you believe that Wikivoyage needs or wants any more money than it already has? WhatamIdoing (talk) 18:05, 28 October 2017 (UTC)

That's a silly question... Here's a possible motivation, and I imagine more resources is always better than less. But again, not the point, let's assume I never wrote it... Andree.sk (talk) 18:37, 28 October 2017 (UTC)

Wikivoyage wouldn't see any money from such links. The money would go to the Wikimedia Foundation, which would allocate spending according to their priorities. (As you note via your link to a prior discussion, the priorities for one team in a non-technical department do not currently include Wikivoyage.)

I asked about this because it is the clearest example of why I think your proposal addresses "average website" problems rather than our specific situation. WhatamIdoing (talk) 02:53, 30 October 2017 (UTC)

I tried to write a piece on aggregators in my userspace but have not worked on it in months... Hobbitschuster (talk) 18:22, 27 October 2017 (UTC)

IMO,that's the ultimate solution: A curated article about hotel booking services, specifying what their strengths and weaknesses are. Ikan Kekek (talk) 01:08, 28 October 2017 (UTC)

How would you make such article useful for e.g. Germany, Africa, Iraq and easten Cuba at the same time? And not bloated... Maybe with some filtering in place? Andree.sk (talk) 04:27, 28 October 2017 (UTC)

I often use this site to find hotels. Names, links to official sites, and pricing are usually enough for me to decide. If the description says something notable, that's cool, but overall "clean and comfortable" is not inaccurate for many hotels. Most hotels don't have anything particularly noteworthy on the positive or negative sides. In reading this thread, aside from deleting all listings outside of "See" and "Do", the suggestion to add a paragraph at the beginning seems fine and it's not something that's ever been disallowed. We already do that in many "Eat" sections with mentioning local specialties. We could do it for other sections, particularly when there are many options to highlight the most noteworthy listings. ChubbyWimbus (talk) 15:18, 28 October 2017 (UTC)

I am definitely against removing listings. One of our goals is to make sure that individuals can contribute knowledge that might not be readily available at commercial webpage. A reason I contribute is that I do find Wikivoyage useful when I travel. As someone mentioned before, we already do have flavor text such as "many hotels are clustered along highway I-86, there are unforunly no downtown hotels" and then adding important listings. I think this is an useful compromise. We are here to create an free alternative to commercial travel pages, that includes listings. --Jonte-- (talk) 16:04, 30 October 2017 (UTC)

@AndreCarrotflower. I'm not insulting anyone. But I do understand why someone who spends much time detouting listings, may find it offensive for someone to say there is negative value in the work they do. It's my observation, not an insult. And it's coming from someone who has spent many hours, and thousands of edits doing just that. And as for checking Sleep listings for currency, I'd say it's a hopeless cause. And I'd even ask the question why in 2017 is manually updating prices on listings a valuable activity when prices for intended stay dates can be so easily checked? I kinda agree with ChubbyWimbus that when you just want a bed, that a few names and links may be sufficient. But I still feel bad that the organisation that's paid for their listings to be added to our free site gets their business. Inas (talk) 21:56, 30 October 2017 (UTC)

Use of "alt" in listings

Swept in from the pub

It seems that the "alt" field in listings is now being strictly enforced as an alternative name for an establishment. Previously over many many many entries, where appropriate I've used it as a sensible indication as to what the establishment is. e.g. In a "Do" section listing "Monezuma" and then use "alt" to say "Kids Adventure Playground" (i.e. not a museum, not a golf club, etc.). Seems good to have what the place is near the beginning rather than buried in the "content" section. Allows a reader to quickly skip listings that do not interest them.

Same for "Eat" section" e.g. "Roberto", traveller goes there to sit down and finds it's a take-away or even delivery only! so briefly add "Restaurant & Takeaway" or "Restaurant", maybe even adding type of food e.g. "Chapiro" and alt="Chinese Restaurant".

All seems to help the user but apparently over the last few months this is not longer allowed. Why? Very few places have two names!

Surely we should be considering the users (particularly given how difficult it is to get changes made to the listing system). PsamatheM (talk) 14:36, 9 November 2017 (UTC)

Good point, & I can see Alt being used as you suggest in some cases. It might also be interesting to look at some sort of tagging system that let readers find e.g. all the Mexican restaurants in town, though I'm not sure how that might work.

However, there are also lots of places with two names when language is taken into account. e.g. For many establishments in China, one needs the Chinese name, including its hanzi (Chinese character) form, because taxi drivers don't speak English & may not understand any attempt a visitor might make at pronouncing the name. In places there may be more than two names; see the infobox at Tibet#Regions. I am not certain to what extent this might apply for European languages, but my guess is it would apply for several other than Chinese. Pashley (talk) 15:22, 9 November 2017 (UTC)

(edit conflict) Unless there are other editors involved with this, you seem to be characterising one edit made by me as "strict enforcement", which is not the case.

So, let's go over that edit. The alt for "Theatre on the Hill" read "Performance Arts Venue (Amersham & Wycombe College)". I removed the "Performance Arts Venue" bit, because the word theatre is in the name of the listing, so it's obvious. Now if the listing had been called something like "STAGE!", there is no way the average person is going to realise that is a theatre, so the alt info would be helpful. Regarding the "(Amersham & Wycombe College)" bit, I updated and moved the college details to directions, which is a more appropriate place for that info. As for the Chiltern Heritage Trail listing, information such as "25 mile circular cycle route" always goes in content.

By the way, alt is also used to translate the actual name of a listing into English, so to give a dull example, a listing called "Jardim Botânico" will normally have an alt that reads "botanical garden". --ThunderingTyphoons! (talk) 15:33, 9 November 2017 (UTC)

I would (generally) agree. I'm not "taking offence" at changes you made (I've been away for a few months so have not caught up on policy changes whilst I've been away and it's not related to the addressing we're discussing elsewhere and I'd not seen (all of) the changes to ALt's you may have made. My concern, uncertainty was in the Summary of a change where you said "Alt" is supposed to be for alternative names. In the broadest context as a policy discussion I'd argue that "Alt" should be used for useful moderately brief alternate text the traveller might find useful. For non-English speaking countries that might be the establishment name translated into English (so traveller has the text as it would be written on a sign in e.g. Russia as well as the "Sunday Market". In other cases "clarification" as to what the establishment is can be useful (as exampled above).

In the past I've treated the Alt as brief clarification where the establishment name does not describe the services offered and the Content to be an often lengthier set of notes. When scanning e.g. a list of Do's and See's immediately after the establishment name is far clearer than in lengthier unstructured text at the end. Many different types of Eat's as well (Restaurant, Takeaway, Delivery, Street food, Bar snacks, etc.)

It was your summary comment that made me raise this topic rather than specific changes you made. PsamatheM (talk) 15:51, 9 November 2017 (UTC)

I wasn't thinking you had taken offence, but appreciate the explanation anyhow :-)

The summary comment does refer to policy, but that's a policy which has been the same for years, so is not something that's been brought in while you've been away.

With regard to your policy proposal (if that's what it is), it looks like a good idea for longer listings with names that don't inform the reader automatically what they're looking at. Where the listing isn't actually very long, then the info should, IMO, still go in 'content'. --ThunderingTyphoons! (talk) 16:57, 9 November 2017 (UTC)

I had thought that the use of Alt for brief "clarification" and/or translation and/or "used to be known as" and/or "commonly referred to as" was common accepted practice (whatever the policy - I'd generally thought common accepted practice was in many ways policy). I'm happy to start a "policy" discussion if appropriate or if the above is contrary to policy (if I could be pointed to the most appropriate section for such policy discussion) (who actually starts any policy discussion is not important).

My personal preference would be for such use to always be in the Lt rather than varying between "Alt" and "Content" depending on length of text in content - mainly because the two sections are presented differently and for consistency i.e. user gets used to e.g. type of "Eat" (restaurant, takeaway, delivery, street food, Oriental/Italian/etc.) in italics after name rather than sometimes in italics after name, sometimes in normal text at end of listing. PsamatheM (talk) 17:08, 9 November 2017 (UTC)

I notice that in certain articles, there's a practice of putting the type of food a restaurant serves in the "alt" tab. If that's an article-wide practice, I leave it alone, but I think that "alt" really should be reserved only for alternate names or names in non-Roman writing, and any kind of description should be in the "content" tab. Ikan Kekek (talk) 00:27, 10 November 2017 (UTC)

I agree with Ikan Kekek. A type of food or style of service is not an alternative name for a restaurant. IMO "alt" should normally be an alternative name, not a key factoid. WhatamIdoing (talk) 06:35, 10 November 2017 (UTC)

So what do either of you say in response to having a "key factoid" that is visible at the top of a rather long listing alongside its name? That strikes me as a good reason to widen the scope of "alt" in some cases. --ThunderingTyphoons! (talk) 10:25, 10 November 2017 (UTC)

I say that if a list is long, it should be subdivided into subcategories, as per Wikivoyage:Avoid long lists. Ikan Kekek (talk) 10:31, 10 November 2017 (UTC)

I agree with that, but the issue is long listings :-) --ThunderingTyphoons! (talk) 10:33, 10 November 2017 (UTC)

I can appreciate that technically "Alt" is for an alternate name and that in an ideal world I think there would be a strong case of a "Type" field in listings (for e.g. type of food, type of service, type of establishment e.g. traditional pub vs dance club, etc. But I remember there being a discussion about adding mobile pone field to the listings with a strong consensus that it should be added - but getting changes made to the listing system seems "difficult" even when there is consensus. And given (personal opinion) the priority should be getting information to the traveller/user, then the "Alt" seems the most appropriate alternative. PsamatheM (talk) 12:04, 10 November 2017 (UTC)

Typhoons, I think that having a "key factoid" right after the name is unimportant. It can be the very first words of the content section instead.

The reason I think it's unimportant is that I can't imagine myself (and by extension, anyone else) actually using that keyword in a well-constructed list to find an entry. I'm probably going to look for restaurants by location or by price, and this helps with finding neither of the things that I care about. If I want to find a particular kind of food, I'll use ⌘F. Or, perhaps more realistically, if I'm seriously determined to find that particular kind of food in a given city, I'll probably ask my favorite web search engine, because the odds are high that the Wikivoyage article will contain only one listing (if that many) for the kind of restaurant that I'm looking for.

Similarly, to use the example in the diff given above, I don't think that anyone really needs the "key factoid" of how long the bike path is. If you're interested in biking, then you'll read the whole listing anyway. "25-mile long circular bike path" could just as effectively be the first words of the regular description. WhatamIdoing (talk) 16:39, 10 November 2017 (UTC)

For me I can see how your search in the "Eat" section might find a restaurant and when you travel there to find it's actually not a restaurant but a take-away/delivery operation ...

One of the advantages of the "listing" is that it is structured data. The address could be included in the Content section, the phone number, web site, etc. and the listing becomes little more than a bit of geo-located free text. My thought is that "type" (or "Alt") only becomes relevant for certain listings where the name is not indicative (or is even misleading). And I feel it is important to remember WV is not just a web site but is a data source. For city dwellers it's easy to "rely on Google Search", but us more rural dwellers appreciate that a data connection is not always available and thus the offline versions of WV have tremendous potential (e.g. Kiwix, PocketEarth, etc.) PsamatheM (talk) 16:58, 10 November 2017 (UTC)

Why would you expect me to travel all the way to a restaurant, but refuse to read the couple of sentences describing it? I don't need "take-away" to be in the alt section, because I'm always going to read the content section (and I'm probably look it up on restaurant review sites, too: very few people use just one website). WhatamIdoing (talk) 06:28, 11 November 2017 (UTC)

[unindent] ThunderingTyphoons!, why do you want to write long listings? On the other hand, if you think a restaurant is worth a long listing, adding a word like "Italian" is not going to make it appreciably longer. Ikan Kekek (talk) 07:02, 11 November 2017 (UTC)

The advantage of putting clarifying information in the "alt" field is that it appears before all of the other data, like address and hours. See, for example, Rochester (New York)#Spectator sports. Powers ^(talk) 20:28, 12 November 2017 (UTC)

Ikan Kekek: There's been a misunderstanding here. I don't "want to write long listings", I am saying that where there are long listings with a non-obvious name, maybe a clarifier in the alt wouldn't be a bad thing. The link that Powers has provided demonstrates exactly that. --ThunderingTyphoons! (talk) 12:20, 13 November 2017 (UTC)

I don't agree with him, either, and I'm surprised someone who's such a Wikivoyage (and before that, Wikitravel) longtimer wants to deviate from the consensus that alt means "alternate name", period. I strongly object to using that tab for any other purpose. As I said, if the sections become too long, they can be subdivided. Otherwise, if there's a concern that the style of food will be lost in a long description, either the description should be shortened or, more obviously, the style of food should be indicated at the beginning of "content". Ikan Kekek (talk) 16:43, 13 November 2017 (UTC)

I would ask you to please note that I did not express a direct opinion on the use of the alt field. I was merely pointing out that particular use cases are not satisfactorily covered by placing descriptors in the content field. I admit I'm stretching the use of the "alt" field in the case I linked, but it was out of necessity, not a philosophical opinion on the meaning of the "alt" field. If we need another field to cover this use case, I'm all for it, but for the time being "alt" is all we have. Powers ^(talk) 02:44, 14 November 2017 (UTC)

There is no "necessity" here. Descriptors in the content field would be perfectly valid. K7L (talk) 15:02, 14 November 2017 (UTC)

But not nearly as useful. Why force a reader to wade through phone numbers and hours of operation before discovering that the Rochester Rhinos are a soccer team? Powers ^(talk) 18:03, 14 November 2017 (UTC)

What makes you so sure a casual reader who's unsure how interested he is in a particular listing will "wade through phone numbers and hours of operation", etc., rather the glossing over that stuff and skipping straight ahead to the meat of the listing? That's what I do in that case, and I suspect the same is true of most others. I think the status quo works fine, but if others disagree, I'd sooner move contact information and the like to the end of each listing than abuse the "alt=" argument. -- AndreCarrotflower (talk) 15:33, 15 November 2017 (UTC)

In the case of a long list of sports teams, (a) I won't be reading any of it, because I'm not interested in spectator sports, but (b) why not change the name itself to a more complete name, i.e., "Rochester Rhinos Soccer"? WhatamIdoing (talk) 16:33, 15 November 2017 (UTC)

Tangentially, I miss when all data except the content was formatted in italics. Then there was no need to "wade through" a large block of text; you could visually skip over all the italics (which had the address, directions, hours, and phone numbers) and see where the content started, and the description of "what is this thing" would usually be apparent within the first few words. --Bigpeteb (talk) 17:21, 15 November 2017 (UTC)

Regardless whether we add a "one-word-description"-field, I believe that we should think twice before using the "alt"-field in this way. In non-anglophone destinations "alternative name"-fields are often needed. Many list-items have one name which is commonly used in English and another which is used locally. The first name is the one a reader will look for when trying to find the list-item in our article, while the latter one is more likely to be added to signposts at the location. Both are crucial to a traveler. If we adopted a policy according to which the "alt"-field could either be used for alternative names or one word descriptions, I believe that it in practice would end up being an "alternative name"-field for non-anglophone destinations and a "one-word-description"-field for anglophone destinations (since it would be impossible, or at least aesthetically unpleasing, to write both an alternative name and one-word-description in the alt-field). But using different practices for anglophone and non-anglophone destinations seems like a very bad idea, and if "one-word-description"-fields are truly usable it should surely be possible to use them in non-anglophone destinations as well. MartinJacobson (talk) 22:52, 15 November 2017 (UTC)

In the case of the Rochester sports venues, I think that it would be far better to use the alt field to give the stadium name rather than the sport. If you want to draw attention to the sport then it can be put in bold, as has been done for some of the stadium names. I don't often go to sports stadia, but all my recent visits have been to seen other events held in the stadium - in several cases athletics events and ceremonies held in football stadia. If I was wanting to see the Rochester Red Wings play at home, then I would ask for directions to Frontier Field. I think that this also is a more standard use of the field. AlasdairW (talk) 23:35, 15 November 2017 (UTC)

Sure, it's not ideal to overload the the "alt" field (though as I said, it's more of a stretch than a violation, as the sport itself is part of the attraction; thus WhatamIdoing's suggestion of adding it to the name field). But I'm not keen on the offered alternatives, either. It's well enough to skip the contact info but it's nice to have the information all in roughly the same place in each listing; it's easily findable right after the bold name. The question of venue versus team is fraught as well; technically the venue is the attraction, and it should only be listed once, not multiple times for each team that plays there, but that's not really how people look for information on sports. Or concert venues. Powers ^(talk) 01:29, 17 November 2017 (UTC)

The "go" template

Swept in from the pub

Apparently you can make a "go" listing in two different ways. One is to use a "listing" template and the "type=go" parameter, the other is to use "go" analogous to "see" or "do". However, this produces a listing which won't work with the listing editor. Can whatever is causing this be fixed? Hobbitschuster (talk) 21:38, 26 November 2017 (UTC)

Another technical question

Swept in from the pub

Is there any way of knowing the exact amount of individual listings that exist in each Wikivoyage edition? ויקיג'אנקי (talk) 19:02, 8 December 2017 (UTC)

Probably not as some "listings" are merely one word and some do not use proper format. Hobbitschuster (talk) 00:11, 9 December 2017 (UTC)

Yes, the easiest way to get statistics about the number of formatted listings is to run a pivot (using LibreOffice for instance) on the CSV file of your choice at https://github.com/baturin/wikivoyage-listings You will notice that Hebrew is not present, would you be interested in adding it? :-) Syced (talk) 03:59, 9 December 2017 (UTC)

Yes, Definitely. ויקיג'אנקי (talk) 05:58, 10 December 2017 (UTC)

This could be useful. Would it be possible to add the event template to this? --Traveler100 (talk) 07:34, 9 December 2017 (UTC)