Wikivoyage talk:Listings

Archived discussions 2006–13 2014–15 2016–17 2018 2019 2020 2021 2022 2023 2024 View archive links

restaurant descriptions

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)

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)

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

• 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)

  "''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)

  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)

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

• 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)

  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)

  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)

• 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)
• 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)

  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)

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)

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)

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)

We should have a local AI policy

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)

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)

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)

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)

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)

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)

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)

Name-only listings

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)

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

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

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)

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)

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)

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)

Proposed wording

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)

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

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)

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

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)

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

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)

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)

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)

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

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

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

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

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

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

Adding listing templates in the mobile version

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)

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)

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

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)

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)

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)

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

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)

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

OSM directions in listings

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)

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)

@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)

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)

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)

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)

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)

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)

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

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)

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)

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)

@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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

@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)

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

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)