Wikivoyage talk:Listings

This article was the Collaboration of the month for May 2019.

Swept in from the pub

writing these can be a time consuming activity. actually ChatGPT is quite good in doing it with this query:

give me a short description about this list of restaurants in [[*CITY NAME*]]. write it in a neutral way without using words like "ideal". the descriptions are for a travel guide. Focus on specific savory food, don't write anything about drinks or sweet food. Write a bit about the style of the restaurant. Don't say anything about food delivery. Please no bla bla sentences like "A convenient stop for a quick and satisfying bite."

for a better processing, the list should only include the names of the restaurants without "updated December 2017" and so on. 2A01:599:214:306:1493:C1E1:20A4:5294 14:06, 2 February 2025 (UTC)Reply

Chatbots risk violating copyright, but the other issue is relying on them without doing some human editing. You can use them as a tool, but don't post unedited chatbot text. Ikan Kekek (talk) 14:55, 2 February 2025 (UTC)Reply

yeah, the produced text needs some checking and editing. 2A01:599:214:306:1493:C1E1:20A4:5294 16:16, 2 February 2025 (UTC)Reply

• Adamantly Oppose! We want input from humans, mainly travellers, not from computer programs. I can think of only one clearly legitimate use of AI in creating WV pages; translating from other WV languages. It is conceivable that, as Ikan suggests, there might be other uses, but I am far from convinced of that. Pashley (talk) 15:34, 2 February 2025 (UTC)Reply

  "''adamantly'' oppose" ...

  ChatGPT gets the information from reviews, which are written by humans. the produced text is just a summary. of course the produced text needs some checking and editing. also for improving the query. 2A01:599:214:306:1493:C1E1:20A4:5294 16:19, 2 February 2025 (UTC)Reply

  If you've checked everything for accuracy and edited the text such that no-one could tell what tools you used, you're good. Ikan Kekek (talk) 16:39, 2 February 2025 (UTC)Reply

  "Reviews, which are written by humans"? The year is 2025, reviews are often astroturfed or AI generated, and if they are not, they soon will be. Daggerstab (talk) 14:09, 3 February 2025 (UTC)Reply

• I too Oppose the use of AI to write listings due to the tendency toward hallucination of such tools, which tend to fabricate obscure details and facts. --Comment by Selfie City (talk) (contributions) 16:28, 2 February 2025 (UTC)Reply

  As do I. I don't mind having a tool actually write the description, if the result is good, but all facts (including subjective descriptions) need to be verified by the person adding them (either from personal experience or through checking the sources for trustworthiness of each individual claim). –LPfi (talk) 18:53, 2 February 2025 (UTC)Reply

  Agreed. I recognize that some people use AI tools to polish their grammar and spelling, and I don't see an issue with that. --Comment by Selfie City (talk) (contributions) 03:04, 3 February 2025 (UTC)Reply

• Yes, the reviews the chatbot is using might be written by real people, or then not - who knows if some of them are AI generated in the first place. However even if those reviews would be truthful (not always the case), the AI can still fumble up the information as SelfieCity pointed out. Therefore we shouldn't be using such services to create WV content. --Ypsilon (talk) 19:04, 2 February 2025 (UTC)Reply
• Strong oppose – a hard no. AI chatbots are useless at this kind of thing, not to mention the countless other problems that would arise. --shb (t | c | m) 21:14, 2 February 2025 (UTC)Reply

  While I have a lot of sympathy with this, when someone starts off by saying that they're finding that a tool "is quite good in doing it", it's not very convincing to just tell them that they're wrong. If it's working for them, it's "useful". I think the opposition should focus on other things, e.g., the fact that it's risky (might hallucinate false information) and not our goal (we want to be unique).

  Of course, if someone were to use such a tool in the way that Ikan and others suggest, you wouldn't be able to tell the difference. WhatamIdoing (talk) 02:10, 3 February 2025 (UTC)Reply

A similar conversation is ongoing at our sister project Wikinews (and that conversation references similar such conversations at other sister projects): n:en:Wikinews:Water_cooler/assistance#ChatGPT. I am generally opposed to these for various reasons, but we don't have a local policy here and at the bare minimum, if you are using an AI tool to generate new material (but not, e.g. fixing spelling or suggesting ways to improve your vocabulary), then it needs to be disclosed which tool you used, which prompts you used, and when you made the request. —Justin (koavf)❤T☮C☺M☯ 21:18, 2 February 2025 (UTC)Reply

There is a similarly heavy policy proposal at the English Wikibooks (where you have not answered a question you were asked, BTW). I don't think that's either feasible or helpful. I think it could also create unexpected problems. Imagine if the prompt is:

"Hey AI, here's the long post from my blog about this restaurant. Please summarize it in two sentences, without giving any identifying information about me <pastes long text>".

Posting that prompt would mean disclosing your real-world identity, because anyone could use the prompt to find your blog. WhatamIdoing (talk) 02:56, 3 February 2025 (UTC)Reply

There may be similar problems, but in the given example, you could just give the blog post without telling it was yours. Then of course, you would be accused of a copyvio, so you would need to get your permission to use that post ("Hi. Your blog post so well described what also was my experience. May I use it in summarised form on Wikivoyage?"). I think there needs to be a practice developed for such situations, which aren't restricted to AI (how did you get that photo, on private property?).

On the other hand, already a long time ago you could be identified from your writing style. The study I vaguely remember said that analysing 40kB (?) of yours (emails? Usenet posts?) was enough to identify posts from you among a closed sample of people (a few thousand?). Using a spell checker, the needed text body was somewhat bigger, but still easy to collect.

–LPfi (talk) 08:26, 3 February 2025 (UTC)Reply

Per the above and per relevant discussions at our sister projects, we should have a local policy on the use of generative AI/LLM tools. As I've written here and elsewhere, I think at a bare minimum that for any of these creating new content, users must disclose which tool was used, which prompt(s) it was given, and when the request was made. If others agree that we should get out ahead of this, I propose that we begin drafting at Wikivoyage:Artificial intelligence (WV:AI) sooner rather than later. —Justin (koavf)❤T☮C☺M☯ 21:20, 2 February 2025 (UTC)Reply

We've had a discussion on this before and WhatamIdoing raised some good points before that having a specific policy on AI doesn't do any good but we could lose potentially good contributors over this. I can't find the specific comment, I still agree with her sentiment and would prefer having no AI policy. //shb (t | c | m) 21:28, 2 February 2025 (UTC)Reply

Huh, I'd be motivated to understand that argument. Thanks. I hope WIAD decides to chime in and educate me. —Justin (koavf)❤T☮C☺M☯ 22:49, 2 February 2025 (UTC)Reply

It basically comes down to two problems:

• A rule against AI is unenforceable. We don't know where/how contributors are getting the text they post. It is, as a matter of principle, a bad idea to have rules that you cannot enforce. (You can have unenforceable non-rules, such as "We're in favor of peace and love and harmony" or Wikivoyage:The traveller comes first or even Wikivoyage:Keep Wikivoyage fun, but you shouldn't have unenforceable rules.)
• A rule against AI will result in false accusations. False accusations will harm the accused person and, to a lesser extent, the bystanders who see acrimonious accusations. There is no effective way to defend yourself against false accusations. If you write personally something that someone says 'sounds like' AI, or that gets flagged by 'AI detectors', then there's nothing you can do except tell the truth, which your accuser is unlikely to believe. And if you did use AI, then you could lie about that and say you didn't, and there's nothing that anyone else can do to prove your lie wrong. I've seen AI "detectors" that flag some of my Wikipedia articles as probably being AI generated. I know that's not true. Also, most of them require a minimum amount of text (e.g., 100 words), and most individual listings are shorter than that.

Instead of trying to ban a "method", I think we should focus on the outcomes we want, which are:

• unique content
• accurate content
• from your own personal experiences (whenever possible) or from multiple trustworthy sources
• posted in a volume/at a speed that gives the rest of the community plenty of time to take a look at your work

and so forth. Then we sidestep the "you horrible user of horrible AI" and instead say: It doesn't matter whether AI hallucinated the detail about the old church being blue vs you got it confused with a different place. Errors aren't wanted, and if you make enough errors, then we'll block you. WhatamIdoing (talk) 02:50, 3 February 2025 (UTC)Reply

I think you are right. There may still be a need for advice and rules prompted by the availability of LLM and similar technologies. A fast rule on keeping volume down to a human speed could be helpful, and we certainly want advice directed at good-faith users. The discussion SHB referred to made clear that some valuable contributors want to be able to use AI, and used in good ways those uses won't harm. The advice needs to identify ways to use AI that can be tempting but that we don't want – sv-wp had a lot of that discussion about bot-writing (without AI). –LPfi (talk) 08:43, 3 February 2025 (UTC)Reply

I wouldn't be opposed to creating an infomation-style page of the use of AI, explicitly stating that there is no official policy on the use of AI. There are reasonable use-cases of AI and I wouldn't want the lack of a page to imply that such use cases aren't permitted. //shb (t | c | m) 03:14, 7 February 2025 (UTC)Reply

Folk are rightly concerned about veracity and copyright, I'd like to focus on time input. Anything that boosts contributors' work per given time is welcome, because pages look to be going out of date faster than they're maintained. For instance I'm embarked on an upgrade of parts of Spain that on present progress will take until Sept 2027, and that will be just one portion of a single large country. Thus for restaurants in Santiago de Compostela:

- the refresh of an existing WV-EN entry (considering customer reviews etc) took me 5 minutes.

- a new entry suggested by Lonely Planet took 7 minutes.

- the first suggestion by Chatbot was blatant cut & paste from publicity blurb so I barge-poled it. The second looked like a genuine quality find, so after due checking yadda yah the new entry took 7 minutes.

Other contributors no doubt work faster but might find that their time-saving is minimal. Grahamsands (talk) 15:23, 7 February 2025 (UTC)Reply

In some of our articles, contributors will add a list of names of restaurants, bars, shops and hotels with no additional information. These really are of no use to travellers. If I am visiting Cityville, how does it help me to know that, at one time in Wikivoyage's history, there was a bar called "Nightlife"?

This template page, however, advises that:

"The following template parameters are used with the listing templates. No parameter is required, but some are recommended to make a listing at all useful."

I think that for Eat, Drink, Buy, and Sleep listings, we should set the bar higher. At a minimum, the listings should include an address or directions on how to find the place. Otherwise, editors should remove the names. Comments? Ground Zero (talk) 16:17, 5 May 2025 (UTC)Reply

I agree, but map co-ordinates should also be enough to keep. Pashley (talk) 18:38, 5 May 2025 (UTC)Reply

[edit conflict] Listings with just the name are usually useless. However, in the case of small villages, a restaurant is easily findable by asking for directions locally. There may be no street names and you may not have a GPS. However, even in that case, there needs to be some information about why one would like to visit the place. If it is the only restaurant in town, one doesn't need the name to ask for directions.

I think there needs to be some piece of information in addition to the name. This may be the address or coordinates, a phone number, email address or web address, or a description (the content parameter). The section intro should in most cases explain why the section has such rudimentary listings, unless it is told in the individual listings.

If there are many listings in any section, I'd remove those that don't have adequate information (and don't seem especially interesting based on what there is).

–LPfi (talk) 18:40, 5 May 2025 (UTC)Reply

There are also Philippine destinations (Dumaguete, Alona Beach) where we just say something like "There are about twenty restaurants and bars along the sea front" then give a list. Elsewhere it might be "around the cathedral square" or along some street. I do not think entries on such a list need an address or directions, but am not certain what this policy ought to say about that. Pashley (talk) 19:02, 5 May 2025 (UTC)Reply

I agree that coordinates should be sufficient as well. "Along the sea front" or "around the cathedral square" would be the sort of directions that help a traveller, if the town is small enough for that to make sense. (For Rio de Janeiro, it wouldn't be helpful.) Ground Zero (talk) 19:56, 5 May 2025 (UTC)Reply

Such statements are useful, but I don't think a list of names of restaurants at that place help. Just state it in the section lead. If you want to recommend some of the restaurants, add listings for them, with more info than just the name. –LPfi (talk) 20:28, 5 May 2025 (UTC)Reply

It is better to add listings giving the just the name of cafes that are introduced as being on Main Square, as then we know when it was added/updated (we have the location, but not strictly in the listing). In Leicestershire#Eat an Eat listing is used for types of food in the county, enabling a Wikipedia link in addition to a description of the type of cheese etc. Maybe this is abusing an eat listing, but I think it is useful in this case, and we know when it was updated. However this is very much an exception, and normally location information is required. AlasdairW (talk) 21:55, 5 May 2025 (UTC)Reply

The following template parameters are used with the listing templates. No parameter is required, but some are recommended to make a listing at all useful. In the case of Eat, Drink, Buy, and Sleep listings, some information must be provided to help the reader find the business, e.g., address, directions, or coordinates.

Ground Zero (talk) 19:59, 5 May 2025 (UTC)Reply

I support this. I'd add a phone number. Ikan Kekek (talk) 22:55, 5 May 2025 (UTC)Reply

I too support; in addition to phone number, I'd also add website/FB page. //shb (t | c | m) 23:03, 5 May 2025 (UTC)Reply

Some places have neither. Ikan Kekek (talk) 00:46, 6 May 2025 (UTC)Reply

Maybe "e.g., address, directions, or coordinates – and if possible, phone number and website/Facebook page". (maybe it's just me or my generation...but calling I find has become a bit old fashioned) //shb (t | c | m) 09:58, 7 May 2025 (UTC)Reply

"No specific parameter is required, but for the listing to be useful, there needs to be some information. In the case of Eat, Drink, Buy, and Sleep listings, address, coordinates, or directions must be given, to allow finding the business. If possible, also give at least a short description, phone number and web address."

A phone call is the only way to quickly find out that the place really is there and is open, while a web address – be it their own site or Facebook – often gives valuable additional information. However, in destinations with more than one restaurant (or whatever), the most important information, in addition to the location, is the description.

–LPfi (talk) 10:23, 7 May 2025 (UTC)Reply

I think that a travel guide should tell a reader how to find a restaurant, bar or hotel, rather than just tell them how they can go somewhere else to find information. A phone or website doesn't get you to the business; it takes you out of Wikivoyage. I don't think that asking contributors to provide an address or general directions or coordinates is too much. I think that is the minimum of information that a travel guide should provide. Ground Zero (talk) 22:08, 6 May 2025 (UTC)Reply

Contact information is a bonus, but not needed for a listing to be useful. Requiring one of the three parameters as in the suggested wording allows for "to find the place, ask any local", which may be OK, e.g., for some places in Greenland, and shows, unless inserted en masse, that the user adding the listing has at least considered the issue.

The problem that sparked this discussion, I suppose, was some users adding lots of places with no info. If somebody adds ten listings to an article, each with "ask any local", I'd still revert with "please provide some useful information on the places".

–LPfi (talk) 09:08, 7 May 2025 (UTC)Reply

The proposed wording doesn't preclude "ask a local" sort of wording. "Address, directions, or coordinates" are listed as examples, not requirements. To clarify, this we can change "e.g.," to "for example":

The following template parameters are used with the listing templates. No parameter is required, but some are recommended to make a listing at all useful. In the case of Eat, Drink, Buy, and Sleep listings, some information must be provided to help the reader find the business, for example: address, directions, and/or coordinates.

Ground Zero (talk) 13:30, 25 May 2025 (UTC)Reply

If there is no further discussion, I will implement this change. Ground Zero (talk) 11:19, 17 June 2025 (UTC)Reply

One minor suggestion: or → and/or -- 78.151.51.152 11:33, 17 June 2025 (UTC)Reply

Change made. Ground Zero (talk) 12:16, 17 June 2025 (UTC)Reply

I'd say feel free to go ahead. //shb (t | c | m) 13:11, 17 June 2025 (UTC)Reply

Agreed, and thanks! Ikan Kekek (talk) 15:40, 17 June 2025 (UTC)Reply

Implemented. Ground Zero (talk) 10:54, 19 June 2025 (UTC)Reply

Swept in from the pub

Forgetting about AI for a second: SingyeDzong asked me where the buttons are to add blank listing templates in articles from an iPhone. I checked several articles and couldn't find an easy way to do this (I was thinking I'd have to resort to copying an existing templated listing and then changing all the contents of every tab, which would be a huge pain!). Why is there no "Add a listing" button in sections of articles in Wikivoyage mobile, and what can be done to make this process a lot simpler? Ikan Kekek (talk) 15:01, 23 April 2025 (UTC)Reply

You can see the absence of the links by clicking this link: https://en.wikivoyage.org/wiki/Pella_(Iowa)?useskin=minerva There is no [add listing] button, and there are no little edit buttons at the end of each listing. The listing editor doesn't appear to load at all in that skin. WhatamIdoing (talk) 16:43, 23 April 2025 (UTC)Reply

Seems the listing editor only works on Vector? //shb (t | c | m) 23:56, 23 April 2025 (UTC)Reply

Seems to be the other way around, rather. Line 28 in MediaWiki:Gadget-ListingEditor.js explicitly forbids the extension from running on Minerva. That line was added following this discussion from almost two years ago.
― Wauteurz (talk) 00:21, 24 April 2025 (UTC)Reply

We really need to improve the mobile experience. We should assume substantial number of our readers and editors to be reading or editing while on the road. OhanaUnited^{Talk page} 13:34, 24 April 2025 (UTC)Reply

I am a bit confused as I added the listing editing on mobile beta a few months ago and was waiting for feedback which I never got.

I see it on https://en.m.wikivoyage.org/wiki/Ikoma for example when I expand a section. It appears as an icon next to the edit link.

If the beta one looks good then with at least 2-3 people's support I can turn it on. Jdlrobson (talk) 15:55, 24 April 2025 (UTC)Reply

screenshot: https://phabricator.wikimedia.org/F59381242 Jdlrobson (talk) 15:57, 24 April 2025 (UTC)Reply

This looks promising. Does it only show the item that you click on the edit button on mobile? OhanaUnited^{Talk page} 14:04, 28 April 2025 (UTC)Reply

[edit conflict]

There is a really simple cause why the listing editor is not available for mobile versions: it uses the jQuery library jquery.ui which provides the dialog-elements support which is not available on mobile devices (better: on Minerva skins). Of course you can change the skin on mobile devices but this would not be a real helpful tool on mobile devices.

For my opinion, their is no simple replacement the jQuery library. The tool has to be reprogrammed from scratch which would be a comprehensive project, and I do not know who should do it. When the old tool was created there was no alternative like OOjs which is, moreover, more difficult to use than jQuery.ui. --RolandUnger (talk) 16:07, 24 April 2025 (UTC)Reply

Swept in from the pub

As part of the few discussions we've had above for possibly modernising this site, something I experimented using the {{listing}} template was adding a direct link to OSM directions if a listing has coordinates (both the lat and the long fields need to be filled in). It's not Google Maps, Waze or Apple Maps by any means and I'm not sure how many people (if any) actually use OSM's directions feature, but it is something.

Unfortunately, the nature of the sandbox templates (which is in a half-broken state) meant that I found it far easier to just use the main template itself, but that does mean that you can see this change directly for yourself on any listing template. From what I've been able to find using OSM help pages, the way I've written the URL tries to ensure it uses your device's current location in the from field. It can be manually turned off using |osm=no if needed (see Canberra/Acton#See for an example) and you can change the default mode of transport and the routing application it uses.

There is a bit more that needs to be done to fully implement this, but I would ideally want to hold off from doing it until there's sufficient consensus. However, most of what readers will potentially find useful has already been implemented and you should be able to see this change on any listing with coordinates.

//shb (t | c | m) 01:07, 7 September 2025 (UTC)Reply

This sounds like a really interesting idea. I think I'd like to see a mockup first, if that's possible, such as an experimental template and start with that. But it would be some great progress. --Comment by Selfie City (talk) (contributions) 02:25, 7 September 2025 (UTC)Reply

@SelfieCity: I couldn't do a mockup because the sandbox templates are half broken (and {{marker/sandbox}}, which all the sandbox templates rely on, was deleted) – but you should be able to see it in action on any page with listings if you purge your cache. //shb (t | c | m) 04:02, 7 September 2025 (UTC)Reply

Oh, okay. I see now. A couple things: first, the concept is indeed excellent. That said Google Maps might be a good idea because (and maybe it's just me) as soon as I click to go to OSM, the map is inundated with those red "needs fixing" markers. (And I'm logged out.) I think the markers would be extremely confusing to users who aren't familiar with OSM.

Second, I'm not sure people will realize what the button is for. I think (Directions) or (Get directions) might be better because it was only obvious to me because the button is new and I had read this discussion. I doubt most casual readers click those buttons because, for a start, the Wikidata link would be remarkably confusing to a non-wiki editor and is listed before the new link to directions. --Comment by Selfie City (talk) (contributions) 14:23, 7 September 2025 (UTC)Reply

About the red flags on the map. You can see them because you opt-in . Probably by clicking on the "add a note to de map" button. You can turn off the red flags by clicking on the layers button , scrolling down the right bar and un-selecting the "map notes" button. Mmorell (talk) 07:59, 9 September 2025 (UTC)Reply

This would pretty OK, but I'd say the main missing feature (here and in the normal dynamic map) is that it doesn't show/use the current user position... -- andree 10:15, 7 September 2025 (UTC)Reply

Yeah, the main downside of OSM is that it does require user input for their own location. I would kinda prefer to do it with Google Maps (which can also be very reasonably implemented), but I'm on two fronts with Google Maps (which does show your own location): travellers are far more likely to find that useful so per WV:TTCF, it would be the more logical choice; however, it somewhat feels a bit odd to pick out just one mapping service, though I suppose it can be justified considering that it's not possible to have direct links with Apple Maps or Waze. //shb (t | c | m) 10:45, 7 September 2025 (UTC)Reply

I honestly don't think it's a huge problem. It's clear from the text "from" that it's where you type in a start location, and while that isn't on the cutting edge of GPS technology, it's a still a major improvement over us providing no directions at all. --Comment by Selfie City (talk) (contributions) 14:26, 7 September 2025 (UTC)Reply

Shb, how are you thinking of using Google Maps? Ikan Kekek (talk) 15:30, 7 September 2025 (UTC)Reply

Similar to how the OSM button currently works, except using Google Maps instead (and your location would be determined using your device settings – which depends on how you use Google Maps IRL). //shb (t | c | m) 19:43, 7 September 2025 (UTC)Reply

Also I am well aware that this will also be a change to our external links policy...but there are always exceptions to everything (which are needed if we want to modernise our site). //shb (t | c | m) 19:46, 7 September 2025 (UTC)Reply

I'm less concerned about that than whether we'd cause some problems for ourselves by relying on a monopolistic corporation that's been heavily fined in Europe and might run afoul of who knows who. Ikan Kekek (talk) 00:37, 8 September 2025 (UTC)Reply

@Ikan Kekek: It's a question I had too, also because I have a reputation IRL for never using Google Maps because they keep breaking perfectly fine things, so I end up using Waze when driving, Apple Maps when walking and NextThere for public transit (it's a niche Australian public transit app). That said, Google Maps remains the most popular mapping app in most countries so I do think it makes the most sense per WV:TTCF, no matter how shady or monopolistic they can be – and I suppose we can still maintain the OSM link for those who aren't a fan of Google (also sorry for late response, I was interstate all week). //shb (t | c | m) 23:41, 11 September 2025 (UTC)Reply

I just added Google Maps directions as well, adjacent to OSM directions. I'm not sure how effectively it works on all devices, but you should be able to see "OSM directions" or "Google Maps directions" in the hoverover – do you also see what I'm seeing on my end? I'll upload screenshots in a moment. (cc SelfieCity and andree.sk) //shb (t | c | m) 00:34, 14 September 2025 (UTC)Reply

Hi. I tried this feature with my cell phone , and showed directions from my current position to the place I picked in wikivoyage. I only had to allow the app to use my positioning.

I'm worried by the fact that if you include lat=,Long= it works fine , but if the item is positioned by adding the wikidata code it DOES NOT WORK. And I try position places using wikidata as much as possible, even editing OSM to add the wikidata code to a place, in order to use it in the listing I'm creating at that moment. Mmorell (talk) 07:48, 9 September 2025 (UTC)Reply

It's designed to only display when the lat and long fields are explicitly filled in – unfortunately, I'm not that well-versed with Wikidata properties to know how to fetch coords from Wikidata. :( //shb (t | c | m) 10:05, 13 September 2025 (UTC)Reply

It’s working! --Comment by Selfie City (talk) (contributions) 02:40, 14 September 2025 (UTC)Reply

I just tested it with Apple CarPlay (even though I don't normally use Google Maps) and goodness does it feel very seamless! If only we had a mobile app, would've been even more seamless. //shb (t | c | m) 03:02, 14 September 2025 (UTC)Reply

Google Maps icons are now showing up in listings for destinations in China, where Google Maps is almost completely useless. I do not think this is a good idea. —Granger (talk · contribs) 03:42, 14 September 2025 (UTC)Reply

You can still use the OSM link for China, though (same goes with South Korea) – it's not a forced choice. //shb (t | c | m) 03:49, 14 September 2025 (UTC)Reply

To be clear, I like the new OSM links, but Google Maps links are useless and confusing clutter for destinations in China. Even in other articles, I think it's questionable to indiscriminately promote a proprietary, for-profit mapping service in every listing, but for China articles I think there's no question this is a mistake. —Granger (talk · contribs) 03:51, 14 September 2025 (UTC)Reply

An alternative solution could be to turn Google Maps directions by default off (while OSM directions are on by default) – that would solve both those issues while still allowing the use of what is the most popular navigation app in most of the world. //shb (t | c | m) 04:05, 14 September 2025 (UTC)Reply

Hmm actually I think I might have a way to disable it on all China/SK pages by default – it would require using the page's Wikidata item to supress all Google Maps links but I think it can be done. Give me a few days. //shb (t | c | m) 04:34, 14 September 2025 (UTC)Reply

It seems to bump "last updated date" to a new line, instead of immediately right after the map links. Can this be fixed? OhanaUnited^{Talk page} 04:54, 14 September 2025 (UTC)Reply

Done, should be fixed (you might need to clear your cache). //shb (t | c | m) 04:58, 14 September 2025 (UTC)Reply

I've now fixed it for China and South Korea (which should work so long as the Wikidata item has P17 defined). I do get your reservations (especially as someone who does not like Google Maps), but statistically more travellers are likely to use Google Maps than any other mapping service (and there is no possible way to link Apple Maps, Citymapper or Flitsmeister); in my view, it's a necessary evil we have to make if we want to effectively compete with Expedia, LonelyPlanet or Tripadvisor (and an issue that was raised here). //shb (t | c | m) 06:54, 14 September 2025 (UTC)Reply

Google Maps icons are still showing up in many of the listings in the first article I checked, Shenzhen/Center. —Granger (talk · contribs) 18:16, 14 September 2025 (UTC)Reply

Seems the issue with that article is it's not connected to a Wikidata item at all. //shb (t | c | m) 22:26, 14 September 2025 (UTC)Reply

It was worse: all Shenzhen district articles had this issue for this reason. I tried to connect them to the largest district articles but I do not know Shenzhen. It's not a fault with the module in this case because generally all Wikivoyage articles should be connected to a Wikidata item. //shb (t | c | m) 23:07, 14 September 2025 (UTC)Reply

I've removed three of the Wikidata connections, which were incorrect. The "East", "West", and "Center" districts are Wikivoyage's invention, made by combining multiple administrative districts, so there are probably no existing Wikidata items for them. —Granger (talk · contribs) 13:55, 15 September 2025 (UTC)Reply

If there is no existing Wikidata item, you have to create them – however, it's very standard to connect them to the largest and/or most relevant district (I went by area) such that it appears on the sidebar on sister projects. The practice is not "incorrect" as you claim, though. //shb (t | c | m) 14:05, 15 September 2025 (UTC)Reply

Works for me too, but I have a feeling some people will have a problem with too many icons (perhaps a drop-down could be used).... :) It'd be great if e.g. on android, there could be some URL that user can redirect to any app (OsmAnd/Mapy.com/Organic maps etc.), but I can't find a way to do that. Perhaps would be doable using the special app, though. -- andree 19:11, 14 September 2025 (UTC)Reply

I'd be good with a dropdown – but I'm not sure how that could be implemented or even if it can be implemented in the first place. //shb (t | c | m) 14:06, 15 September 2025 (UTC)Reply

I think that, ultimately, we need to commit to either OSM or Google Maps. Likewise, I think Wikidata shouldn't be visible to those logged out. It's really an internal tool, and removing it for logged out users would reduce the clutter. --Comment by Selfie City (talk) (contributions) 18:44, 15 September 2025 (UTC)Reply

I think the issue we'd run into by committing to either one is we're always going to have people who will take issue with the use of Google Maps (even in a majority of the world where Google Maps remains the most popular navigation app) and OSM isn't of much help to most travellers (no specific app, no seamless integration with Apple CarPlay/Android Auto, cannot be downloaded offline), and providing both is the only way to give users a choice. //shb (t | c | m) 12:13, 16 September 2025 (UTC)Reply

Good point. Is there any way to track how much those links are used &mdash; to be clear, not to track who is using them but just how much they are used? --Comment by Selfie City (talk) (contributions) 01:27, 22 September 2025 (UTC)Reply

I don't believe so, at least not to my knowledge. :( //shb (t | c | m) 02:25, 28 September 2025 (UTC)Reply

@andree.sk, SelfieCity: So turns out there's now a new beta feature that Apple seems to be trying with their web version, making it possible to display such links in the same way Google does (and suppress for China/SK). I do wonder if it'll genuinely be possible to create a dropdown and make it not suck on mobile. I think 3 would be pushing the limits and wanted more opinions before testing it. Maybe possible tweaking the site's css/js such that it's only a hoverover dropdown on desktop? //shb (t | c | m) 07:29, 28 September 2025 (UTC)Reply

I think that would be a good idea. --Comment by Selfie City (talk) (contributions) 13:49, 28 September 2025 (UTC)Reply

I think for the timebeing I'll have to place Apple markers as an icon similar to Google and OSM for now – but when I get some more time maybe I'll get the dropdown menu working. //shb (t | c | m) 22:40, 6 October 2025 (UTC)Reply

I looked back several years into the archives and don't see where we discussed this problem before, but here is the latest place it's come up: User talk:ANormalWikiEditor#Some formatting advice for you:

"I just noticed that because I usually use the visual editor, some templates don't come with all the possible fields listed and is probably the reason I am deleting unused fields."

What are we going to do about this, considering that we have a policy of not deleting unused fields but when people use the visual editor, they cannot see that they are doing that? Ikan Kekek (talk) 10:27, 17 December 2025 (UTC)Reply

Why is no-one reading this page, seemingly? See another example here. Are we giving up on having all regular fields in listings? If so, I don't give a damn and will stop patrolling for it. Ikan Kekek (talk) 17:47, 5 January 2026 (UTC)Reply

This should still be addressed. Ikan Kekek (talk) 14:09, 7 July 2026 (UTC)Reply

I assumed that the visual editor uses "TemplateData" to get the information on what fields to add or leave alone. However, the quoted phrasing isn't clear: "the reason I am deleting" suggests that ANormalWikiEditor actively deletes those fields. If visual editor works as it should, I assume it should show/add/whatever the required and suggested fields, but not the optional ones. I also assumed the listing editor agrees with the TemplateData on which fields to suggest, but that might not be the case (see ). The edits linked in the linked thread shows the terse style I have been wondering about. These listings at least get the parameters in the right order. It seems the TemplateData isn't consistent across see, do etc. – should be checked. –LPfi (talk) 22:17, 7 July 2026 (UTC)Reply

Swept in from the pub

After 13 years, many Wikivoyage listings are still in plain text, rather than templates. This means they can't have coordinates, they're often badly formatted because they don't use our templates (Eat, Drink, Sleep, See, etc.), and they don't have a lastedit parameter so the date of information is unclear allowing them to become out of date. I try to fix these manually, but in some cases (Amandola) the task is just too daunting. I bet that half of the businesses listed there are defunct. without templates

I think we used to have a bot that did just this. Could we create a new one? Listings would still need to be checked, but this could save a lot of time and make our listings more time-relevant, the biggest critique of our website from outside of Wikivoyage. --Comment by Selfie City (talk) (contributions) 14:52, 4 February 2026 (UTC)Reply

That sounds like a great idea, but I would ask that the bot not fill in the lastedit field, but leave it blank. We would not want a bunch of listings imported from Wikitravel to be automatically converted to templates indicating that the listing was last updated on 4 Feb 2026 (for example). I have been trying to apply templates to new listings without templates that have been added to a couple of England articles (by an experienced editor). It's a job and a half. Ground Zero (talk) 22:06, 4 February 2026 (UTC)Reply

I agree. I should've clarified that I mean the lastedit parameter should be created empty, so that editors can make edits and fill it in. --Comment by Selfie City (talk) (contributions) 22:59, 4 February 2026 (UTC)Reply

Do you have some representative list of such pages? A bot is not a problem to make, but to make it reliable and not do breaking edits is something different... -- andree 22:06, 4 February 2026 (UTC)Reply

• Amandola
• Gilbertsville
• Ilhéus
• Neuss

--Comment by Selfie City (talk) (contributions) 23:02, 4 February 2026 (UTC)Reply

Listings are often but not automatically a good way to convey info, so unleashing a bot will generate text that only a bot will ever want to read (and perhaps that day is dawning). As the experienced editor that GZ just had a little poke at, I'm bound to observe that the System Architects of WV have endowed us with half a dozen different formats for presenting info. It is not for us mere mortals to know their sublime intent, but I suggest we should continue to make use of them all. Grahamsands (talk) 22:54, 5 February 2026 (UTC)Reply

Lists of untemplated restaurants, bars and hotels look like the stuff that was imported from Wikitravel in 2007. When I use Wikivoyage for travelling, I ignore undated entries because they are usually outdated cruft. I think Wikivoyage should be doing better than that in 2026. Ground Zero (talk) 02:49, 6 February 2026 (UTC)Reply

Agreed. They also just look pure messy (esp markers) and my mind often just glosses right by. //shb (t | c | m) 03:16, 6 February 2026 (UTC)Reply

I understand, but I think that for the sake of creating a bot, we shouldn't let ourselves be sidetracked by that concern. We have articles and business listings from 2007 that actually are unchanged. That's the main problem my proposal is attempting to fix. --Comment by Selfie City (talk) (contributions) 13:55, 6 February 2026 (UTC)Reply

Oh ftr I support – listings should be the norm sitewide. //shb (t | c | m) 21:42, 6 February 2026 (UTC)Reply

I think in some cases, it's fine to list POIs as markers or simply in bold — I've noticed you do this in articles, and personally I don't have a problem with that. My concern is more with articles pulled from WikiTravel which use their old format. These are the "dinosaur" articles rather than the newer drafts. --Comment by Selfie City (talk) (contributions) 22:57, 5 February 2026 (UTC)Reply

I'm not overly concerned by it. Yellowknife's See section is a mix of bulleted items, templates and nested templates. And that doesn't bother me. OhanaUnited^{Talk page} 14:10, 6 February 2026 (UTC)Reply

The only bulleted items in Yellowknife#See are the Aurora Borealis, and the Great Slave Lake. If someone did assign coordinates to the aurora, they would be wrong. As the lake covers an area larger than Wales, coordinates would not be useful. Ground Zero (talk) 14:25, 6 February 2026 (UTC)Reply

There's also "buy" in Yellowknife which is a mixture of bulleted items and templates. OhanaUnited^{Talk page} 15:05, 6 February 2026 (UTC)Reply

All of the stores listed in Buy are templated. The bulleted items are things that you might consider buying, like Caribou-skin mittens, so they would not have a template with coordinates, date, address, telephone. It would be a problem for a bot, but the concern I am raising is about businesses that are listed without dates. Ground Zero (talk) 17:19, 6 February 2026 (UTC)Reply

I'm imagining a bot that is applied on a case by case basis, not sitewide. I don't think it would need to be used on decent articles like Yellowknife, where minor fixes if needed could be made by a human. --Comment by Selfie City (talk) (contributions) 13:36, 9 February 2026 (UTC)Reply

Non-decent articles probably need more than bot-tidying. A human should make the major fixes. Of course, if they want a tool to do some of the work automatically, I don't object, but listifying should not be the only thing done. Most restaurant and hotel listings not edited since 2013 should probably be removed rather than listingified, unless they can be at least tentatively verified. –LPfi (talk) 14:00, 9 February 2026 (UTC)Reply

I agree, but listifying is a tool that would make the human updates (checking businesses' status, etc.) quicker. --Comment by Selfie City (talk) (contributions) 16:08, 9 February 2026 (UTC)Reply

Just run that by me again. The problem is that we have far more outdated entries than editorial input to update them. Many are not time-stamped: you and I would know that these are especially likely to be outdated but the casual reader is left guessing. The proposed solution is to deploy a bot that would fix none of them but create far more, as it would listify entries that are fairly recent and those that are not time-sensitive, such as landmarks. That's the idea, right? Grahamsands (talk) 19:43, 10 February 2026 (UTC)Reply

We have two separate issues here. One is listings that are not dated. That's a problem, but it needs to be fixed with user input.

I'm talking about entries that were imported from WikiTravel and aren't even in a listing template. Should we just leave them as timeless messes? At least if they're in the template, they can be updated more easily... --Comment by Selfie City (talk) (contributions) 20:52, 10 February 2026 (UTC)Reply

Indeed – there is nothing saying that a bot has to fill in the lastedit field. //shb (t | c | m) 23:08, 10 February 2026 (UTC)Reply

Any such bot IMO should skip the |lastedit= field, and it could even add a |bot=yes field. Since unknown parameters are usually ignored, that shouldn't even require any changes to the templates. WhatamIdoing (talk) 19:27, 11 February 2026 (UTC)Reply

I am not sure that unknown parameters are ignored in listing fields as I have recently seen errors being flagged up for twitter and facebook fields which I think were a brief experiment.

I do think that converting suitable text to listings by a human controlled bot is a good idea. Having a listing with its "edit" link at the end encourages users to make minor updates. I was disappointed to see that a bot recently converted a few inline listings to markers, for example on Benešov, but this was only on a very few pages. AlasdairW (talk) 21:33, 11 February 2026 (UTC)Reply

See listing template discussion -- andree 16:54, 12 February 2026 (UTC)Reply

Good idea regarding the bot parameter – I think the default listing template you see at the source header would need to be changed; I'm not sure how this can be done, but I'm sure there is a way. //shb (t | c | m) 21:46, 11 February 2026 (UTC)Reply

I believe the warning for unknown parameters is shown only for those who have enabled such warnings, i.e. people who in this case indeed should see it (and remove the parameter if the listing is OK). If the template were edited, what would you like it to do when that parameter is set? Perhaps have it show a warning :-)

–LPfi (talk) 09:36, 12 February 2026 (UTC)Reply

Oh I see what you mean. //shb (t | c | m) 09:57, 12 February 2026 (UTC)Reply

I think that converting a templated listing for a restaurant to ordinary text is a bad idea. In addition to removing the date stamp that tells the reader how current the information is, it removes the coordinates, and in this case the phone number. Ground Zero (talk) 12:03, 23 March 2026 (UTC)Reply

Agreed; it also makes the article in general look a lot less organized and tidy, and is against current site consensus anyway. //shb (t | c | m) 12:16, 23 March 2026 (UTC)Reply

Agreed. -- andree 11:05, 9 July 2026 (UTC)Reply

I made a helper tool you can try -> User:Andree.sk/Listinger.dev.js, add it by adding it into your common.js, like I did.

After that, in the source editor you should see group "transform". You can select the text you want to convert, and it will convert it to the listings of the chosen type, if all goes well. It can also do multiple lines at once. If it works well, we could probably merge it with the current (more limited) listing creation button... -- andree 20:46, 9 July 2026 (UTC)Reply

@Andree.sk: – just tried this on Ambalangoda and this is great! One small thing, though, is this deliberate? The icons all seem to appear thrice. //shb (t | c | m) 23:25, 9 July 2026 (UTC)Reply

It's not deliberate :-D I see it only once, nevertheless I think it's superfluous to have it separate - so I'd merge it back to the "normal buttons" as I wrote above (the original functionality would be untouched anyway)... after a bit more testing. -- andree 07:22, 10 July 2026 (UTC)Reply

haha yeah fair enough – take your time, but I love the functionality of it even as it stands. //shb (t | c | m) 08:03, 11 July 2026 (UTC)Reply

Swept in from the pub

What are the criteria for choosing one or the other? I'd consider listings the default & would certainly use them whenever creating a list, & markers only when mentioning a place in running text.

I cannot think of a case where I'd want to have:

• {{marker | name= ...

However, others obviously feel differently. For example Himalayas#Destinations has multiple lists done with markers. Pashley (talk) 10:29, 18 March 2026 (UTC)Reply

I tend to use markers to list cities and other destinations, as well as adding coordinates for places mentioned in running texts. Otherwise, I use listings. However, I do think we should use listings for cities and other destinations as well, and reserve markers for places mentioned in running texts. Sbb1413 (he) (talk • contribs) 11:04, 18 March 2026 (UTC)Reply

@Ground Zero: I see you converting listings to markers in Western Sahara. Why? Pashley (talk) 12:45, 31 March 2026 (UTC)Reply

Regarding these edits, it is our standard formatting to use markers for cities and other destinations in region articles, and to use listing templates for See, Do, etc. listings. Why would this article be different? A city doesn't need address, phone, price, hours information, unlike a museum or restaurant. Ground Zero (talk) 12:55, 31 March 2026 (UTC)Reply

Thank you. That does make sense. Pashley (talk) 13:17, 31 March 2026 (UTC)Reply

I went looking for a policy on this, and I couldn't find one. This is just one of those unwritten conventions. that trip people up. I think it would be a good idea to formalize this. Thoughts? Ground Zero (talk) 20:05, 31 March 2026 (UTC)Reply

Yes, it should be formalized, just like how the U.S. formalized the two-term presidency after FDR assuming more than two terms during the war, because the two-term presidency was an unwritten convention before FDR. Sbb1413 (he) (talk • contribs) 14:18, 7 July 2026 (UTC)Reply

Honestly, I'd prefer listings also for cities, because then (at least in theory) we could in future sync+reuse the short description of cities in multiple articles referring to them (e.g. by putting/getting it from WD). If it's just a marker, it's forever doomed to be maintained manually across all levels of regions. People around here prefer the manual way, it seems, though :) :( I can live with both... My 2c. -- andree 11:04, 9 July 2026 (UTC)Reply

tbh I wouldn't mind listings for cities if there were a way to get rid of the edit button when listed under Cities or Other destinations. //shb (t | c | m) 04:37, 12 July 2026 (UTC)Reply

@Andree.sk, SHB2000: Maybe we should upgrade {{marker}} to have functionality like fetching short description from WD. We can follow w:Template:Annotated link (or its pre-2020 version) as the model for fetching short description from WD. Sbb1413 (he) (talk • contribs) 04:51, 12 July 2026 (UTC)Reply

{{marker}} is mostly for contexts where the standard format isn't suitable. It should not have a footprint larger than the marker, name and a short parenthesis. Perhaps, on hovering, it could show the full listing with the appropriate clickable and copyable links. –LPfi (talk) 11:33, 12 July 2026 (UTC)Reply

I don't think we should make a habit of reusing the same one-liner descriptions across multiple articles. The right way to describe a city depends on the context in which it's being described. The United States article appropriately highlights that Miami "attracts sun-seeking Northerners". But that would be a silly thing to mention in the one-liner for Miami in the Miami-Dade County article, because it's true of the rest of the county and indeed the rest of the state. It would also be a little boring to see the same description of a city again and again when browsing articles at multiple levels of the hierarchy. —Granger (talk · contribs) 19:35, 12 July 2026 (UTC)Reply

Obviously we are not talking about the high-profile articles and regions here, where people fight over each other to write something clever about the area... This is about the regions where last comprehensive edits were done 5-10 years ago, like West Coast (Finland) (no insult intended).

Of course if the only highlight of cities like Fargo is that it's the largest city of North Dakota, it can't be reused higher up :-) OTOH, e.g. Poprad description could be reused in Slovakia, Eastern Slovakia and Spiš.

If you use WV in a printed form, it wouldn't make sense to repeat the same stuff - but I reckon that's like 0.02% of WV readers. Most of them will land at random region article via google. And since we don't have nearly enough editors to maintain regions - I suppose the next best option is this. You could always override the generic short text. -- andree 07:17, 14 July 2026 (UTC)Reply

Hi, everyone. I've been under the impression for a long time that all tour listings must include the address of the headquarters and be listed in the city where the headquarters are only, but I don't see anything like that on this page. How should we handle these things? Ikan Kekek (talk) 14:07, 7 July 2026 (UTC)Reply

It says the operator must have an office with phone number and address, but it doesn't say those must be included in the listing. I think that checking it has an office but not telling the address is odd (in places where there addresses are used, otherwise there should at least be directions). For the headquarters location, I think there are tour operators that do tours in a national park but has the office in a nearby city. In that case I think the listing should be with the park. If they do tours all around the region, listing them in the city makes sense (although in that case, the office might be just a booking centre). –LPfi (talk) 22:34, 7 July 2026 (UTC)Reply

Also, how do we normally handle tours of operators based in another city? (like a Cairo-based tour operator giving tours in Luxor). This is something I rarely get involved in so I'm not actually sure what our practice for this is. //shb (t | c | m) 22:50, 7 July 2026 (UTC)Reply

If the tours start with a bus from Cairo, why would we want them to be able to list it in Luxor? Same with a tour of a park that starts in a nearby city. Ikan Kekek (talk) 01:19, 8 July 2026 (UTC)Reply

Yes, if the tour starts in the city. If, on the other hand, the tour starts at the gates of the national park, then the location of the headquarters is less relevant. We want the operator to have a physical presence also between the tours, but the tours may still be bookable by phone or web. –LPfi (talk) 06:19, 8 July 2026 (UTC)Reply

Forgive me if I'm mistaken, since I really haven't booked all that many tours before, but I was thinking something more like the tour is entirely based in a different city with none of the tour involving going to the headquarters. I guess maybe LPfi has already explained it since most of the tours I've booked are in national parks. //shb (t | c | m) 07:50, 8 July 2026 (UTC)Reply

Just so I'm clear, is the purpose of 'The operator must have a "real world" office' so that we have an objective bar to screen out informal drivers and other spammy listings? Because the location of an operator's "headquarters" is less useful to the traveller than knowing where the tour starts and where the tour goes. The listing should be based on wherever is most useful, either the "ticket office", the "meeting point" or "pickup area", or the primary destination.

I ran into a "headquarters" problem while sorting the elephant tours in Chiang Mai; half the operators listed their address as a ticket office in the city center, while the other half listed the park in the countryside. Splitting them up based on that would be needlessly arbitrary, and "headquarters" to me was ambiguous for this purpose. (Moving the listings to the countryside seemed right at the time, but I'm open to the central ticket offices as long as the policy is clearly for one or the other.)

For outlying destinations like Luxor and Teotihuacan, where it's possible to arrange independent transportation from the city but many travellers won't want to, I would find tour operator listings most useful in [Outlying destination]#Get in. Is taking a tour bus or private driver to Luxor different enough from taking a public bus or taxi to Luxor? If that would open the floodgates to spammy listings then the "headquarters" policy might be necessary as a compromise, but it would make the desirable listings harder to find. Gerode (talk) 21:37, 9 July 2026 (UTC)Reply

A current instance of this problem is at User talk:Renoir.au. The last comment there was addressed to me but I am not certain how to respond. Would anyone else care to? Pashley (talk) 23:28, 9 July 2026 (UTC)Reply

Clearly, it can't be listed in both articles, but based on this discussion, I have no idea what Wikivoyage guidelines are now in regard to which article it should be listed in. Therefore, I may have to bow out of policing tour listings except for obvious touting. Ikan Kekek (talk) 02:14, 10 July 2026 (UTC)Reply

The listing should usually be where most travellers would look for it. If the tours go to a less visited place and most tour operators are based in a nearby big city, listings in that city are lost among all other Do listings, and for districted cities, the tours might not even deserve a listing on the main city page. Those interested in the tour destination would read its article, so the listing should go there. The tour destination could be mentioned as a Go next in the big city article if it is (or should be) popular. Where the destination is among the main reasons to go to the nearby city, such as in the Cairo/Giza case, the destination could be mentioned also in Understand or even in the lead. I think the listings are still best placed in the tour destination article – they are easily found through the links in Understand and Go next. For tours from Cairo to Luxor, I would put listings for one-way tours in Luxor#Get in; Cairo#Go next would be an alternative (and perhaps the place for round-trip itineraries), but we usually don't put listings there.

I don't see a point in listing tour headquarters in articles for which the tours are marginal, and I don't really see a problem in listing them in the tour destination article instead. Tours from unrelated places should probably not be listed at all.

For the Renoir.au case, the listing tells about a live-aboard with multiple-day itineraries, not really a cruise, and I think it should be listed only as an activity in Port Ghalib. I might be mistaken.

Cruises could have a mention in the destination's Get in, linking to the main listing, which probably would be in the departures city (I assume the headquarters or at least a ticket office is there). Whether or not to list them in the destination articles depends on how useful they are for getting there. A round-trip cruise allowing only a short visit should – in most cases – not be listed, but if cruises are a thing in the region, a one-way cruises should probably be mentioned even when it is slow and expensive (cf the Finnish lakes and archipelagos).

One problem I have, however, is what to do with a tour operator offering tours in a wide region. Should it be listed in the region or even country article? Or in an arbitrary city where it happens to be headquartered? I think the multiple-listings rule is in Don't tout, not in Listings, which might allow independent parties to list a tour business in several places, in the case where there is no local competition and the listing clearly serves travellers. Usually, a link to the main listing, perhaps in the arbitrary headquarters' city, would suffice – but if the tours aren't generic ("camel tours"), but different in each destination (a four-day tour visiting X, Y and Z), a local listing is probably better.

Another problem is to distinguish operators offering tours in an area from aggregators selling such tours without operating them. They often do their best to hide the fact and the operators themselves may not have a visible presence.

–LPfi (talk) 09:45, 10 July 2026 (UTC)Reply

Swept in from the pub

When I see an edit like this, I wonder how users are finding out-of-date templates. In this case, an eat template was added with a fax number field, and without the lastedit field. I doubt that the user has manually changed the template. Does anyone know where these templates might exist so that we can update them? Ground Zero (talk) 16:24, 20 June 2026 (UTC)Reply

Sorry but I'm not following. This edit used an instance of {{eat}} in the article Görlitz. If you need to edit the template directly, it exists at Template:Eat. If you need to edit some information in that particular instance of the usage of the template, you can do it at the article. Forgive me if I'm too slow here, but that's where all the content exists. ―Justin (koavf)❤T☮C☺M☯ 17:49, 20 June 2026 (UTC)Reply

So the answer to GZ is "They might use the template documentation". GZ wondered because the field doesn't get inserted by the listing editor unless you provide a value, and here it was empty. –LPfi (talk) 17:55, 20 June 2026 (UTC)Reply

But here the lastedit field was missing, and it isn't in the template documentation. That hints on them having found the old version (from before 22 February 2015! the user started editing 2018) somewhere. –LPfi (talk) 18:05, 20 June 2026 (UTC)Reply

I think that they may have simply copied one of the existing listings and then edited it, as the other eat listings have the fax number field. AlasdairW (talk) 20:29, 20 June 2026 (UTC)Reply

That sounds right to me. Ikan Kekek (talk) 12:52, 22 June 2026 (UTC)Reply

I too think this is the most probable reason. //shb (t | c | m) 01:08, 23 June 2026 (UTC)Reply

Swept in from the pub

There are a couple of threads there that need attention and participation, and I know from sad experience not to count on anybody paying any attention to that page. Ikan Kekek (talk) 14:10, 7 July 2026 (UTC)Reply

...after a short discussion above, the default editor listing buttons functionality was extended. By selecting a text that resembles legacy-style listings (e.g. See section of Amandola), and clicking the respective button, the listings will be automagically created. If you see some regressions, please report :) -- andree 20:01, 16 July 2026 (UTC)Reply

I don't know if it's a regression, but it's certainly wonkyː when I click the button to create a Sleep listing it includes the "checkin" and "checkout" fields, as expected, but also an irrelevant "hours" field (more appropriate to a Buy or Eat listing). Cheersǃ Mrkstvns (talk) 21:01, 16 July 2026 (UTC)Reply

I sometimes use the hours field for restaurant and front desk opening hours. Checkin and checkout are more important, but I don't see a big problem in it keeping that field (but it isn't among the suggested fields). –LPfi (talk) 22:10, 16 July 2026 (UTC)Reply

I occasionally use the hours field for places that are only open for part of the year, for example a campsite which only opens in the summer. AlasdairW (talk) 22:54, 16 July 2026 (UTC)Reply

Swept in from the pub

It seems that at least in Europe, the overtourism is dealt with e.g. by requiring booking entrance time upfront, often sold out for days prior, and no on-premises tickets even. I got bitten by this a few times in the past weeks already, including listings that seem quite mundane. e.g. today after a 40m drive, it was a bit surreal to be left outside with 20 other people before middle-of-nowhere ruins, with next entry 5h later :) ... It was definitely my fault for not checking upfront, but...

I think some kind of icon "booking required" would help, and could be also used for Trip Planner, for example. One can easily overlook this requirement in a wall of text. Any other ideas/suggestions? I see now e.g. google maps has this "better to book upfront" recommendation in place... -- andree 18:29, 13 August 2026 (UTC)Reply

I don't know whether a symbol is practical, but it definitely should be emphasized in any listing in which it's relevant! I'm sorry that happened to you! Ikan Kekek (talk) 19:33, 13 August 2026 (UTC)Reply

I did a Googlesearch of "Booking needed icon" and looking at the various icons that came up, it seemed to me that the most appropriate woudl be a stylised clip-board. As a guide, Wikipedia flag icons are 23 x 15 pixels with a one pixel border. Martinvl (talk) 21:40, 13 August 2026 (UTC)Reply

wow that's great awesome 👌 ~2026-53122-59 (talk) 21:55, 2 October 2026 (UTC)Reply

Some major tourist attractions in China require advance booking as well (although sometimes if you are a foreigner you can beg and cry and they'll let you in). E.g. Tiananmen Square (they did not let me in). Brycehughes (talk) 10:26, 15 August 2026 (UTC)Reply

I support such an icon to be added in listings. Plenty of places I've come across in Paris and Barcelona that required bookings during peak holiday season that I think a visual identifier would be immensely useful for such attractions. //shb (t | c | m) 11:22, 15 August 2026 (UTC)Reply

I doubt an icon will work well since readers may not be aware of its meaning, so I'd prefer bolded text. Perhaps make a template for it?

Are there more complicated situations? I remember reading of a case where a Londoner could not get tickets to a popular West End show because seats were all sold months in advance to tour companies, but an American had no trouble booking tickets via a US travel agency. That was in fiction; is it realistic? Would something similar apply for Broadway shows in New York, Vienna opera, Nashville, ...? Pashley (talk) 12:36, 15 August 2026 (UTC)Reply

This is absolutely the case in China. Chinese citizens must make advance bookings (typically via a WeChat mini-program) for many attractions while foreigners are given a lot of leeway, and can often just show up and present their passports. This brings up a case that we might need handle: locals are required to book in advance but foreigners are not. Brycehughes (talk) 12:58, 15 August 2026 (UTC)Reply

It isn't too hard to write "Reservation required for locals/foreigners". Wouldn't that be enough for the simple cases? Add a "if tickets are sold out, you may still get them from tour companies" if relevant. While this is probably a new phenomenon, long queues have been a fact of life at many places, hopefully noted in the listings, and some restaurants require booking weeks in advance, also hopefully noted. We haven't used bold text for these, but I don't oppose bold-text warnings, as long as only the key words are in bold. –LPfi (talk) 14:15, 15 August 2026 (UTC)Reply

Yeah, still stinging off my Tiananmen Square experience I'd love a simple checkbox in the form indicating advanced registration is required (converting into whatever text) but given the local/foreigner dichotomy plus other potential edge cases it does seem like just indicating this in the content text is the most helpful/robust path. Brycehughes (talk) 14:41, 15 August 2026 (UTC)Reply

I have prepared an icon which shows a clipvboard: . This still needs a wrapper artound it, but before I go any further, what do people think? It should display the text "Booking Requreid" if the user hovers over it, but I still have to sort that out. Martinvl (talk) 15:54, 15 August 2026 (UTC)Reply

Before the icon we need to decide whether this makes sense, which I think it does not, currently. Brycehughes (talk) 15:59, 15 August 2026 (UTC)Reply

I think I'd prefer a clock symbol. There are many clock icons on Commons, such as or .

However, overall, I think that text would be more useful than an icon. WhatamIdoing (talk) 20:58, 15 August 2026 (UTC)Reply

I think text is better. There isn't a standard icon that everybody recognises, and in many cases extra text is useful. For instance in the original example, booking may be required in August, but not needed in November. In many cases the text could provide a booking link, and in most cases it is useful to say how far in advance booking may be necessary - "during the school summer holidays book 4 weeks ahead, in winter same day bookings may be possible". AlasdairW (talk) 22:14, 15 August 2026 (UTC)Reply

I would argue we need both for that exact reason – the unfortunate reality with using plain text is it can easily be glossed over; much harder to gloss over an icon, though. //shb (t | c | m) 22:19, 15 August 2026 (UTC)Reply

I agree with AlasdairW. Bolding the text is fine, but I don't see how an icon will be clearer. People always miss stuff. It's not our responsibility to use symbols for everything. Ikan Kekek (talk) 22:41, 15 August 2026 (UTC)Reply

As others have stated, I agree that a bolded text string is best. Icons are clutter when they aren't obvious, used often, and used consistently. Bold text is simple and stands out. Mrkstvns (talk) 22:39, 15 August 2026 (UTC)Reply

I'm fine with either, but would much prefer to make this a checkbox (and add further explanation e.g. in the "price" field) of the listing template, to make this useful for scripts. Indeed there are different venues, some only require it in peak season etc., or you can come anytime and wait 2h ... -- andree 09:26, 16 August 2026 (UTC)Reply

One way to get consistency is to write a set of booking templates. A suggested list is:

• {{booking needed}} which would produce:

Booking mandatory.

• {{booking advised}} which would produce:

Booking advised.

• • {{booking peak}} which would produce

Booking advised (peak periods).

• plus others as needed. We could have one which has the icon with a red cross on it which for "No bookings taken", but I would advise against having a template for "Bookings not needed" as ths would cause clutter and would also require us to chase up information that might be difficult to find and liable to change.

Martinvl (talk) 13:35, 16 August 2026 (UTC)Reply

andree, could you specify which attractions caused your disappointment? That would reveal whether insufficient info in the listings was the cause or, duh, sometimes it helps to read what's written. Grahamsands (talk) 20:53, 16 August 2026 (UTC)Reply

my growing list contains: Belchite (ghost town), Gaztelugatxe, Zaragoza castle, Grotte de Niaux, Altamira cave (this one was great - you wait in line for 1h, and they give you a ticket with the slot for another 3h later)... -- andree 05:13, 20 August 2026 (UTC)Reply

I think those icons are far too large and eye-catching. If you use our guide to find info on the place, you should indeed notice bold text in the "content". Normally we don't even use bold for things directed at those that read a paragraph anyway. For scripts, a invisible note is enough. –LPfi (talk) 08:56, 17 August 2026 (UTC)Reply

A set of multiple templates is much too complicated. Remember, templates are difficult for newcomers. WhatamIdoing (talk) 16:27, 17 August 2026 (UTC)Reply

Ignoring the icon bit...is there still support for including bookings required as a separate parameter on {{listing}}? //shb (t | c | m) 09:29, 17 August 2026 (UTC)Reply

For ordinary users, it is superfluous – the free-text details are what they need – and an additional parameter means one more thing to think about when creating or editing a listing. Scripts benefit from a formalised note, such as through a parameter, but what scripts need it? There needs to be a serious need to justify the added editor effort. –LPfi (talk) 09:40, 17 August 2026 (UTC)Reply

Wouldn't it technically be easier for new users if it's a separate box on the listing editor? (genuine question btw) //shb (t | c | m) 10:23, 17 August 2026 (UTC)Reply

Perhaps, but not for those editing the wikitext. Also, having a checkbox may disincentivise editors from adding more detailed free-text information. If the checkbox adds text, it might not agree with the actual situation. Trying to catch some edge cases in the checkbox interface, it is easy to get into the weeds. –LPfi (talk) 11:30, 17 August 2026 (UTC)Reply

And if we have "advance booking required", someone will want "advance booking recommended", and someone else a different variation, and then we've got a complex interface that's no longer "easier". Typing ordinary words is already easy. WhatamIdoing (talk) 16:29, 17 August 2026 (UTC)Reply

Moreover a text explanation is needed if it's not obvious why booking's required. For instance "Booking is essential -

- as they only lay on enough food and staff for booked guests, and can’t cater for walk-ins."

- as the chapel is tiny, with footfall restricted to preserve the frescos."

- for the royal apartments, then you tour the rest of the palace at your own pace."

- as the fort is within the military zone, and you need to show ID."

and so on. Everyone in this discussion understands the term "booking essential" and its equivalents, so why suppose our readers cannot? They're independent-minded travellers, and shouldn't be treated as post-literate flea-brains who can only be engaged via icons, emojis, cartoons and flashing lights. Grahamsands (talk) 12:50, 18 August 2026 (UTC)Reply

Indeed, my point is to avoid getting to the venue and finding out you drove 2h with your family to see closed doors... The reasons for mandatory booking are various and mostly understandable, and I personally don't mind missing out stuff - the frustrating part is when your plan disintegrates due to not remembering to check everything upfront. Because of honest "who would have thought <this particular thing> requires booking?". It doesn't matter in the end why - maybe other people are more clever, or 3/4 of the tickets are pre-reserved by group tours... -- andree 05:37, 20 August 2026 (UTC)Reply

We could have prefilled options: mandatory booking (otherwise there's noone to guide/open the venue; or because they don't sell tickets locally), mandatory booking in high seasons, recommended booking (to not wait in queue for 3h), custom text/nothing...

I tried using Trip Planner for my vacation/roadtrip and apart from ideas for that tool, I think being able to see highlighted what needs special attention beforehand (booking) would have saved me lots of headache.

Without this, basically I need to cross-check everything with google maps/trip advisor... I'd really love it, if WV headed towards becoming a 1-stop guide - not just data source for other webpages. -- andree 05:25, 20 August 2026 (UTC)Reply

We cannot ensure there won't be such problems: the traveller who added the listing might have been there in low season (and if you are there in low season, it might be open just some days, while the listing was added in high season), the place might just be closed for repairs the particular day you get there, or whatever. But off course, we should strive for having such info included (although I don't bother telling a place is closed in Midsummer and around Christmas – visitors at such dates should check for themselves). –LPfi (talk) 08:08, 20 August 2026 (UTC)Reply

yep, my primary motivation is really to indicate somehow that one has to plan for the venue days/weeks/months ahead... We can leave the details to the reader. -- andree 20:00, 20 August 2026 (UTC)Reply

(#Today I learned that places close for Midsummer in Finland.) WhatamIdoing (talk) 21:23, 20 August 2026 (UTC)Reply

-)

The warning should be in Finland#Holidays, which currently says:

'[…] Most shops and offices are closed on most of these holidays (even 24-hr-daily venues on some of them)'

We should perhaps add some language on museums and the like, which don't follow the hours of offices and shops. I'll try to do something about it.

–LPfi (talk) 06:22, 21 August 2026 (UTC)Reply

Done. Might have missed something. –LPfi (talk) 07:04, 21 August 2026 (UTC)Reply

---

There was no big push-back against some form of this. Could you, @Andyrom75:, adapt listing the editor and renderer to include this field? I can do it too in Module:Listing, but you'll have to then sync it etc. anyway :) I'd suggest a drop-down box with allowed edit and some predefined values ("Mandatory booking", "Advance booking highly recommended in high season", "Booking will save you hours of waiting"). I'd say if the value is non-empty, it should be highlighted with bold and put right before "price" field in the render. We can evaluate use of this field e.g. in a year and if it's not used, we can drop it. We can consider icons if text will look strange/insufficient. Sounds ok to everyone?

Where do you see a consensus for a symbol or special field for this? Lots of great points have been made in opposition, and I for one continue to oppose the idea and support the use of ordinary text for this purpose. Ikan Kekek (talk) 13:33, 28 August 2026 (UTC)Reply

I reread the thread and would say that there clearly is no consensus for anything other than text. ---- Ikan Kekek (talk) 13:36, 28 August 2026 (UTC)Reply

Yep, I myself am fine with that honestly (from my side it's plenty enough that the template will signify 'attention needed' with non-empty parameter). Thus "We can consider icons if..." :) -- andree 17:50, 28 August 2026 (UTC)Reply

How about icon with mouse over pop up? Travel Doc James (talk · contribs · email) 14:03, 7 September 2026 (UTC)Reply

Swept in from the pub

I propose removing the marker types listing and around.

listing is redundant with other, and type=listing is not very meaningful when used in listings. around appears redundant with go; access points typically use type=go, while other destinations and itineraries use vicinity.

If the queries are correct, usage is fairly limited:

• insource:/\{\{ *(marker|listing)[^{]*\| *type *= *around([ |}\n])/i — 211 results
• insource:/\{\{ *(marker|listing)[^{]*\| *type *= *listing([ |}\n])/i — 677 results
• insource:/\{\{ *(marker|listing)[^{]*\| *type *= *other([ |}\n])/i — 375 results
• insource:/\{\{ *(marker|listing)[^{]*\| *type *= *view([ |}\n])/i — 11 results

Compared to vicinity:

• insource:/\{\{ *(marker|listing)[^{]*\| *type *= *vicinity([ |}\n])/i — 1,368 results

Waysi41 (talk) 11:50, 19 September 2026 (UTC)Reply

type=view gives me just 19 pages Waysi41 (talk) 12:01, 19 September 2026 (UTC)Reply

I assume you mean replacing, rather than removing. Why should anyone bother doing that? WhatamIdoing (talk) 17:52, 19 September 2026 (UTC)Reply

Replacing, then removing the options from markers. Clarity mainly, aligning listing types with marker types would be more consistent as well. It would help new users, as well as improving readability over different guides. Waysi41 (talk) 18:05, 19 September 2026 (UTC)Reply

marker type listing is used by the listing template/module as default value... -- andree 06:46, 20 September 2026 (UTC)Reply

It could be done the other way around as well. There are 375 results for other (deprecate other in favor of listing). Either way, they seem to be redundant? Waysi41 (talk) 11:23, 20 September 2026 (UTC)Reply

I think I understand type=view, type=around and type=vicinity better now. view is different from see: see is something to look at, while view is somewhere to look out from. Likewise, around can cover things used for getting around (used in "Get around"), such as car rental, without being a transport hub or access point itself, which seems to be what go is used for, in either "Get in" or "Get around". vicinity is used in "Go next", destinations in the vicinity that are worthwhile visiting. This is guessing intent, though. In reality, around only has a few rental places, and mostly overlaps with go. type=view mostly overlaps with type=see. I've corrected some of the type=view markers, but that mostly leaves us with a classification based on what type of entity something is (it's a viewpoint), rather than being more conceptual.

That leaves other and listing. Those still look redundant to me: both seem to function as the generic fallback when no more specific type applies. Would it make sense to collapse those into a single type? Waysi41 (talk) 14:00, 20 September 2026 (UTC)Reply

I don't see any benefit in changing these. Around and vicinity are subtly different colours. Each type of marker has a separate counter and the numbering doesn't work above 99; this is not an issue in most articles but it does apply to a few, and these apparently similar markers could be used there. As the type of marker is often typed in by the editor, changing may cause confusion. AlasdairW (talk) 12:01, 21 September 2026 (UTC)Reply

Regardless, all marker types with an established meaning should be documented, and other types should be used only when there are special needs. Where is the canonical documentation? Wikivoyage:Listings doesn't mention "about" or "vicinity", Template:Marker/doc only mentions them, with no guidance; "view isn't even mentioned in them. –LPfi (talk) 12:24, 21 September 2026 (UTC)Reply

I agree that we need some brief documentation on what you can use the niche marker types for. This discussion is answering some questions I've had about them. Gerode (talk) 15:57, 23 September 2026 (UTC)Reply

Fair point about the numbering. I think around is purple, which is different from dark red (vicinity). I haven't figured out what the difference is between listing and other, they are the same color, and seem redundant. Waysi41 (talk) 13:02, 21 September 2026 (UTC)Reply

In practice, since listing is a default when unspecified, other could indicate that someone reviewed the unspecified type and determined that no other type was preferable. WhatamIdoing (talk) 23:23, 21 September 2026 (UTC)Reply

Do you think that's how it's currently used? I would prefer the advice given for listings to extend to markers as well:

If the listing doesn't fit into one of the above categories, you can use the "listing" tag without a type for a generic one. Waysi41 (talk) 07:24, 22 September 2026 (UTC)Reply

I think I'd prefer to keep listing, just for consistency in lists where the default needs to be kept as-is. //shb (t | c | m) 13:30, 21 September 2026 (UTC)Reply

That makes sense, it would also result in fewer edits.

I've looked more closely into usage of view, around and vicinity. I've replaced several instances where view was actually see (museums, etc.). Which leaves just 11 results, where it is used as a classification of what something is (a viewpoint), similar to "instance of" on wikidata. It seems around actually has approximately the same usage as go. There are a few rental places as well, which don't neatly fit, the rest are bus stops, stations, etc. vicinity is used in "Go next", destinations in the vicinity that are worthwhile visiting.

Things to consider:

We could create a rent type instead, and classify most of the around markers as go.

If the only usage of view is as a classification of what something is, maybe we can drop if for see. Waysi41 (talk) 17:41, 21 September 2026 (UTC)Reply

Just how much benefit do users get from the time you're spending changing the type of marker, when you could be spending the time adding information, updating information, or copy editing? Ikan Kekek (talk) 18:03, 21 September 2026 (UTC)Reply

What's the point of copy editing without a style guide?

I think this is similar. Clarifying what the marker types are supposed to mean makes future editing more consistent and avoids having several types that overlap or are used unpredictably.

I also don't think replacing these necessarily needs to take much time, especially if we can identify them with a search query. I'd imagine there are tools for doing replacements as well, although I'm not sure what the best option is on Wikivoyage.

There are only around 16 entries where around is being used for a rental place. We could probably just change those to go rather than inventing a new type. Waysi41 (talk) 18:10, 21 September 2026 (UTC)Reply

This discussion has itself taken a bunch of time, and there's a reason Wikivoyage doesn't go into so much detail in its style guide: we don't want to be Wikipedia. Ikan Kekek (talk) 14:46, 22 September 2026 (UTC)Reply

I generally don't mind if people want to "waste" their own time; maybe it doesn't feel wasteful to them. But I would object to having a bunch of detailed style rules here, in exactly the same way that I object to having thousands of templates here. We should have what we actually, provably need, and no more. WhatamIdoing (talk) 16:29, 22 September 2026 (UTC)Reply

What I'm trying to figure out, is what we provably need. Do we need these types? If so, what for? If we don't, why not remove them?

I don't think that's a waste of time. As a minimum, we can get a justification for why we have these types, and offer guidance to users.

Isn't having many different marker types, for which the justification is unclear, quite similar to having many different templates? Waysi41 (talk) 19:14, 22 September 2026 (UTC)Reply

I think that having location and other, which look the same to the end user, is more like having an alias for a parameter in a template: It doesn't actually matter if they exist, and cleaning it up can generate pointless edits. WhatamIdoing (talk) 19:56, 22 September 2026 (UTC)Reply

Oppose. Don't remove around please. It's a perfect fit for the Harar article for example. Using go there for city gates alongside bus stations, etc., is a bizarre categorisation. Brycehughes (talk) 13:35, 22 September 2026 (UTC)Reply

Would you say that a description for "around" should be access points for which "go" doesn't fit? Waysi41 (talk) 19:10, 22 September 2026 (UTC)Reply

Go works well with the Get in section. Around works well with the Get around section. Let's not overthink things. Brycehughes (talk) 00:42, 23 September 2026 (UTC)Reply

Is that where around is currently used? Waysi41 (talk) 06:42, 23 September 2026 (UTC)Reply

I started seeing "round" quite recently (a few years), mostly introduced by a user (several accounts + IP edits, but I suspect they are the same user) who rarely discusses what they are doing, so I never understood what it was about (no pun). Could those regulars who use this type tell how they use it? Is there a practice along the lines outlined above? –LPfi (talk) 10:11, 23 September 2026 (UTC)Reply