This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

• 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)[reply]

• 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)[reply]
• 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)[reply]

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

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)[reply]

• 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)[reply]
• Completed except for several User pages and 1 talk page - Matroc (talk) 04:52, 23 June 2016 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Swept in from the pub

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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 [email protected] 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)[reply]

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)[reply]

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

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)[reply]

It would need to be a moderately complex bit of software. Suppose the address is [email protected].

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

• 44.1355-76.3541 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

• • 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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 g